はじめに
概要
本書はAWSのIAMポリシーの書き方をやさしく解説します。IAMポリシーはクラウド上の操作を許可・拒否するルールです。ここでは基本的な役割、JSON形式での記述方法、作成手順、主要要素、具体例、適用方法、注意点を順を追って学べます。
対象読者
クラウド利用の管理者や開発者、これからIAMポリシーを作成する担当者向けです。初心者でも理解できるよう、専門用語は最小限にし具体例を多く示します。
本章の目的
この第1章では、本書の構成と読み進め方を示します。各章で何を学べるかを把握し、実際の作業に移る準備を整えます。
推奨される読み方
まず第2章でポリシーの概念を押さえ、その後に手順やJSONの構造（第3・第4章）を読み進めてください。第5章の例を試し、第6章で適用方法を確認すると実務に役立ちます。
前提条件
AWSアカウントとIAMの基本操作（ユーザーやグループの作成）が分かっているとスムーズです。初めての場合は手元で試しながら読み進めてください。
IAMポリシーとは
概要
IAMポリシーはAWSリソースへのアクセス権をJSONで定義する文書です。誰が何をできるか（許可/拒否）を明確に指定します。機械で判定しやすく、運用で再現性を高めます。
何を定義するか
主に以下を指定します。
– アクション（例: s3:GetObject、ec2:StopInstances）
– リソース（例: 特定のバケットやインスタンス）
– 効果（AllowかDeny）
– 条件（時間やIPで制限）
どのように使うか
ポリシーはユーザー、グループ、ロールに割り当てます。例えば「S3の特定バケットから読み取る権限のみ」を与えると、不要な操作はできなくなります。最小権限の原則に沿って設定することが重要です。
ポリシーの種類（簡単）
- マネージドポリシー：AWSや管理者が共有して使う
- インラインポリシー：特定の主体に直接紐付ける
実例（イメージ）
{
"Version":"2012-10-17",
"Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::example-bucket/*"}]
}
次章ではポリシー作成の基本手順を順を追って説明します。
IAMポリシー作成の基本手順
概要
IAMポリシーを作るときは、目的からテストまで順序よく進めると安全で分かりやすくなります。ここでは実務で使える具体的手順を丁寧に説明します。
1. ポリシーの目的を決める
何をできるようにしたいかを一文で書きます。例：「特定のS3バケットからファイルを読むだけ許可する」。目的がぶれると権限が広がりやすいです。
2. 対象リソースを特定する
どのサービス、どのリソースに対してかを明確にします。例：arn:aws:s3:::example-bucket/* のようにバケットやフォルダを限定します。
3. 実行できるアクションを定義する
最小限のアクションだけを指定します。例：s3:GetObject のみ許可。読み書き両方は不要なら付けないでください。
4. ポリシードキュメントを作成する
JSON形式で書きます。最初は管理画面のウィザードを使うと間違いが減ります。コメント欄や説明を付けて誰が何のために作ったか残します。
5. ポリシーをテストする
IAMポリシーシミュレーターやテスト用ユーザーで実際に操作を試します。期待どおり拒否されるケースも確認してください。
AWSコンソールでの作成手順（簡潔）
- AWSコンソールでIAMを開く
- 「ポリシーを作成」を選ぶ
- 対象サービスとアクション、リソースを指定する
- ポリシー名と説明を入力して作成
ポイントと注意
- 常に最小権限を心がける
- 名前と説明を分かりやすく付ける
- テストで期待通り動くかを必ず確認する
これらの手順を守れば、安全で運用しやすいポリシー作成ができます。
IAMポリシーのJSON構造と主要要素
概要
IAMポリシーはJSON形式のドキュメントです。基本は「Version」と「Statement」の二つで構成します。Statementで個々の権限定義を列挙し、Effect／Action／Resourceなどの要素で細かく指定します。
Version
ポリシーのフォーマットバージョンを示します。通常は”2012-10-17″を使います。互換性のために必ず入れてください。
Statement（配列）
複数の権限定義を並べられます。各要素はオブジェクトで記述します。
- Sid: 任意の識別子。人が識別しやすくするために使います。
- Effect: “Allow”または”Deny”。許可か拒否かを指定します。明示的なDenyが優先されます。
- Action: 許可・拒否する操作を列挙します。例: “s3:PutObject” またはワイルドカード “s3:*”。
- Resource: 操作が適用されるリソースのARNを指定します。例: “arn:aws:s3:::example-bucket/*”。
- Condition: オプションで追加の条件を指定します。IPアドレスや日時などで制限できます。
補足要素
- NotAction/NotResource: 除外指定に使います。細かい制御が可能です。
- Principal: 一般にリソースベースポリシーで使用し、対象のエンティティを指定します。
例（簡易）
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "Example",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}]
}
この構造を理解すると、意図した権限だけを明確に表現できます。具体例を作る際にも役立ちます。
具体的なポリシー記述例
S3バケットへのフルアクセス例
以下は特定バケットに対するフルアクセスを許可する最小の例です。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::example-bucket","arn:aws:s3:::example-bucket/*"]
}]
}
ポイント: バケット名を明示して許可範囲を限定します。ワイルドカードで全アカウントに許可しないでください。
EC2の参照・開始・停止を許可する例
インスタンスの作成は許可せず、参照と開始/停止のみを許可する例です。
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":["ec2:DescribeInstances","ec2:DescribeTags","ec2:StartInstances","ec2:StopInstances"],
"Resource":"*"
}]
}
ポイント: Describe系はリソース指定が難しいため*で許可する場合がありますが、開始・停止は必要なインスタンスのARNに限定すると安全です。
実務上の注意
- 必要な操作だけを明示的に指定してください。これにより不要な権限を減らします。
- 条件（IPや時間帯）を付けてさらに制限できます。テストは必ず安全な環境で行ってください。
ポリシーとロール・ユーザーの関係
ポリシーの適用先
IAMポリシーは主に「ユーザー」「ロール」「グループ」に適用します。ユーザーに直接ポリシーを付けると個別管理になります。ロールは一時的に権限を与える仕組みで、サービスや他アカウントが使う場合に向きます。グループは複数ユーザーへ同じ権限をまとめて付与するときに便利です。
グループ活用のメリット
グループに共通ポリシーを割り当てれば、ユーザー追加時に権限設定が簡単になります。例えばMarketingUsersにS3の読み書き、SalesUsersに営業関連リソース、DevelopersにVPC操作の権限を与えると管理が簡潔になります。
ロールを使う場面
ロールはEC2やLambdaなどのAWSサービスに権限を与えるとき、あるいは別アカウントや外部IDプロバイダから一時的に権限を付与するときに使います。ユーザーと異なり資格情報を持たないため、長期的な鍵管理リスクが減ります。
権限評価の流れ
実際のアクセス判断は、ユーザーに直接付与されたポリシー、ユーザーが属するグループのポリシー、アタッチされたロール（もし一時的にロールを引き受けている場合）のポリシーを総合して決まります。明示的な拒否が最優先で拒否されます。
運用のコツ
- グループで共通権限をまとめる
- ロールはサービスや一時アクセスに限定する
- 最小権限の原則でポリシーを設計する
これらを守ると、権限管理が分かりやすくなりミスを減らせます。
ポリシー作成時の注意点
説明欄（Description）について
IAMポリシーには1つだけ説明欄を設定できます。作成後は説明の変更や削除ができないため、目的や適用範囲を分かりやすく書いておきます。例：「S3バケットXの読み取り専用アクセス（開発チーム）—2025/xx作成」。短くても、誰が使うか、何のためかを明記します。
権限設定はルートで行わない
権限付与はルートユーザーではなく、管理者権限を持つIAMユーザーで行います。ルートは最小限に留め、MFAを有効にします。日常の管理は管理者IAMで行うと、ルートのセキュリティリスクを下げられます。
ポリシー記述の注意点
- ワイルドカード（”*”）を安易に使わないでください。具体的なアクションやリソースを指定します。例：S3の全操作ではなくs3:GetObjectだけを許可。
- 条件（Condition）を活用して時間帯や送信元IPで制限します。
- 名前付け規則を決め、いつ誰が作成したか分かるようにします。
運用と確認
ポリシーは適用前にテストします（ポリシーシミュレータ等）。ログやアクセス履歴を定期確認して不要な権限が付いていないか監視します。
以上を守ると、安全で管理しやすいポリシー運用につながります。
