はじめに
本書の目的
本ドキュメントは、AWSのIAM（Identity and Access Management）について、初心者にも分かりやすく体系的に理解できるようにまとめています。IAMの基本的な役割、主要な構成要素、実際の使い方や運用の注意点までを順を追って説明します。
対象読者
クラウドを使い始めたばかりの方、会社でAWSを扱う担当者、セキュリティの基本を学びたいエンジニアや管理者を想定しています。専門用語は必要最小限に留め、具体例を交えて解説します。
本書の読み方
各章は独立して読めますが、順番に読むと理解が深まります。まずはIAMの役割を押さえ、その後でユーザーや権限の管理、実践的な設定例、運用のベストプラクティスへと進めてください。
注意点
実際の操作を行う際は、まずテスト環境で試してください。誤った設定はアクセス不能や情報漏えいの原因になります。図や画面は本書の後半で用いますので、手を動かしながら学ぶことをおすすめします。
AWS IAMの概要と役割
概要
AWS IAM（Identity and Access Management）は、AWS上の「誰が」「何をできるか」を管理する仕組みです。ユーザーやシステムごとに認証と認可を分けて設定でき、権限を細かく制御します。
認証と認可の違い
- 認証（Authentication）：その操作をする人やシステムが本当にその主体であるか確認します。例：ユーザー名とパスワード、MFA（ワンタイムコード）など。
- 認可（Authorization）：認証済みの主体にどの操作を許可するか決めます。例：特定のS3バケットの読み書きだけ許可する。
IAMの主な役割と具体例
- アクセス管理：ユーザーやグループ、ロールに対してポリシーを割り当てます。例：開発チームはテスト用のリソースのみ操作可能にする。
- 一時的な権限付与：ロールを使い、サービスや外部アプリに短時間だけ権限を与えます。例：自動化スクリプトがEC2を起動する際に一時的に権限を取得する。
- 多要素認証（MFA）：重要操作の安全性を高めます。管理者アカウントにMFAを必須にできます。
- 監査とログ：誰がいつ何をしたかを追跡できます。問題発生時の原因特定に役立ちます。
なぜ重要か
IAMはAWSのセキュリティの土台です。適切に設定することで、誤操作や不正アクセスのリスクを大きく下げられます。
IAMの主要な構成要素
IAMユーザー
IAMユーザーは個々の人を表します。コンソールやAPIでサインインするためのユーザー名、パスワード、アクセスキーを持てます。多要素認証（MFA）を設定すれば安全性が高まります。ユーザーごとにポリシーを付与して必要な操作だけを許可します。
IAMグループ
IAMグループは複数のユーザーをまとめて管理するための枠です。共通の権限をグループに付ければ、個別に設定する手間が減ります。たとえば「開発者」グループにS3の読み書き権限を付けると、メンバー全員が同じ権限を使えます。
IAMロール
IAMロールは人ではなく機能やサービスに割り当てる役割です。EC2やLambdaなどAWSサービスに一時的な権限を与えるときに使います。ロールはクロスアカウントアクセスにも使え、長期的なアクセスキーを持たせずに安全に自動化できます。
IAMポリシー
ポリシーは「誰が」「何を」「どのリソースで」できるかを定めるルールです。JSON形式で書き、Allow/Denyや対象のアクション、リソースを指定します。マネージドポリシー（AWS提供やカスタム）とインラインポリシーがあります。最小権限の原則に基づき、必要な権限だけを与えることが重要です。
要点の実例
- ユーザーに直接付ける代わりに、まずグループにポリシーを付ける。
- EC2にアクセスさせる処理はロールで割り当てる。
- ポリシーは具体的なアクション（例：s3:GetObject）で絞る。
これらを組み合わせて、安全で管理しやすい権限設計を行います。
IAMが必要な理由とメリット
なぜIAMが必要か
AWS環境では権限の誤設定や過剰な管理者権限が深刻な被害を招きます。たとえば、誤って重要なデータを削除したり、外部に情報を公開してしまったり、アカウントが乗っ取られて不正に操作される危険があります。IAMを使うことで、誰が何をできるかを明確に管理できます。
主なメリット
- 最小権限の実現: 必要な操作だけを許可して、不要なアクセスを防ぎます。
- 役割ごとの分離: ユーザーとサービスに応じたロールを作り、責任範囲を分けます。
- 一時的な資格情報: 長期のアクセスキーを減らし、リスクを下げます。
- コスト不要: IAM自体に追加料金は発生しません。セキュリティを高める投資効果が高いです。
- 監査と追跡: ログを使って操作履歴を確認できます。
具体例
- 開発者には開発用S3のみのアクセス、運用スタッフには監視ツールだけの権限を与えることで事故を減らせます。
- EC2やLambdaにはロールを割り当て、アプリから直接アクセスキーを持たせない設計が安全です。
今すぐできる対策
- ルートアカウントは普段使わない。MFAを有効にする。
- 管理者権限を絞る。グループやロールで細かく分ける。
- ポリシーは小さく作る（読み取り専用と書き込みを分ける等）。
- 定期的にアクセス権を見直し、未使用の資格情報を削除する。
IAMはシンプルに始められて効果が大きい施策です。まず小さなルールから整備していくことをおすすめします。
IAMの使い方と具体的な設定例
1. 基本の流れ
IAMを使うときは、まず「誰が（ユーザー/ロール）」「何に（サービス）」「何をできるか（権限）」を決めます。手順はユーザー作成→グループ化→ポリシー割当、必要ならロール作成、という流れが一般的です。
2. IAMユーザー作成とグループ化（具体例）
手順例:
– コンソールでIAM→ユーザー作成。名前を付け、コンソールアクセス・プログラムmaticアクセスを選択。
– グループを作り、業務ごとに分ける（例：開発チーム、運用チーム）。
– グループに権限を割り当て（例：開発にはS3読み書き、運用には読み取りのみ）。
例：S3の読み取り専用はAWS管理ポリシーのReadOnlyAccessを使うと簡単です。
3. IAMロールの活用（EC2/Lambda）
- EC2がS3へアクセスする場合はロールを作り、EC2サービスを選択してポリシーを付与します。インスタンスにロールを関連付ければ、鍵を直接置かずに安全にアクセスできます。
- Lambdaも同様に実行ロールを作り、必要な権限だけ付けます。
4. ポリシー設定の具体例（最小権限）
簡単なJSON例（S3特定バケットの読み取り）:
{
“Version”:”2012-10-17″,
“Statement”:[{ “Effect”:”Allow”,”Action”:[“s3:GetObject”],”Resource”:[“arn:aws:s3:::example-bucket/*”] }]
}
ビジュアルエディタで操作を絞るとミスが減ります。
5. 設定時のチェックリスト
- グループ単位で権限を管理しているか
- ロールを使い、鍵のハードコーディングを避けているか
- 最小権限の原則を守っているか
- 多要素認証（MFA）を有効にしているか
- 必要な場合はアクセスキーを定期的にローテーションしているか
上記を順に行えば、安全で管理しやすいIAM運用の土台が作れます。
IAM運用のベストプラクティス・注意点
最小権限の原則
必要な操作だけ許可する方針を徹底します。具体例：EC2にログを送るだけのアプリには「読み取り専用」や特定APIだけ許可するポリシーを割り当てます。グループやロールで共通権限を管理すると運用が楽になります。
ルートユーザーの利用制限
ルートユーザーはアカウント作成時だけ使い、日常業務では使いません。ルートにはMFAを設定して認証情報を安全に保管します。管理作業は権限を絞った管理者用IAMユーザーやロールで行います。
アクセスキーの安全管理
長期のアクセスキーは避け、可能ならロールの一時的な認証を使います。使わないキーは削除し、キーのローテーションを定期的に行います。例：90日ごとに更新し、古いキーは無効化してから削除します。
権限の定期的な見直し
ユーザーやグループ、ロール、ポリシーを定期的に点検します。不要なアカウントは削除、特権が過剰なポリシーは縮小します。オーナー情報や期限をタグに入れると管理しやすくなります。
運用上の注意点
- ロール／インスタンスプロファイルを使いアプリの権限を限定します。
- ログや監査を有効にし、異常なアクセスを検知したら速やかに権限を見直します。
- 自動化（スクリプトやテンプレート）で人的ミスを減らします。
トラブル対処の基本
権限不足の問い合わせが来たら、まず最小変更で対応して再現テストを行います。広く許可を出す前に影響範囲を確認し、変更履歴を残しておきます。
IAMの関連サービス・発展的な使い方
IAM Identity Center（旧AWS SSO）
- 複数のAWSアカウントや外部アプリへ一度のサインオンでアクセスできます。たとえば、社員が1つのポータルから開発アカウントと本番アカウントへ適切な権限で切り替えできます。
組織と連携したガバナンス
- AWS Organizationsのサービスコントロールポリシー（SCP）で上位レベルの制限をかけ、各アカウントはそれに従って権限を設計します。これにより全体の安全基準を統一できます。
発展的な権限設計
- 権限境界や一時的なロールを使って最小権限を担保します。CI/CD実行用ロールや外部サービス連携のために短時間だけ有効な認証を発行する運用が有効です。
自動監査・レポートツールの活用
- AWS ConfigやCloudTrailで変更を記録し、IAM Access Analyzerで過剰な公開やアクセスパターンを検出します。定期レポートでヒューマンエラーを早期に発見できます。
外部IdPとの連携（SAML / OIDC）
- 社内のIdPと連携して既存のアカウント基盤を利用できます。これによりパスワード管理や多要素認証を一元化できます。
ポリシー管理の自動化
- IaC（例：Terraform, CloudFormation）でポリシーをコード化し、差分管理とレビューを行います。自動化で人的ミスと運用負担を減らせます。
まとめ
AWS IAMは、クラウドで安全にシステムを運用するための基礎です。認証（だれかであることを確認する）と認可（何ができるかを決める）を分けて考え、設計と運用を続けることが重要です。
主なポイント
- 最小権限を徹底する：必要な権限だけを与えます。例：普段は管理者権限を使わず、特別な作業だけで付与します。
- ロールを使う：アプリやサービスにはロールを割り当て、アクセスキーをコードに埋め込みません。EC2やLambdaの役割付与が具体例です。
- 多要素認証（MFA）を必須にする：コンソールアクセスにはMFAを設定し、不正ログインのリスクを下げます。
- ログと監査を有効にする：CloudTrailなどで操作履歴を記録し、疑わしい動きを早く検知します。
- 定期的な見直し：不要なユーザーや古いアクセスキーを無効化し、ポリシーを定期チェックします。
- 自動化と再現性：CloudFormationやIaCで権限設定をテンプレート化し、人為的ミスを減らします。
- 教育とルール作り：運用ルールを文書化し、チームで共有します。
これらを日常の運用に落とし込めば、組織のセキュリティレベルを確実に高められます。まずは最小権限の適用とMFAの導入から始め、定期的な監査と自動化を進めてください。
