自分用メモです

AWSでリソースにアクセス権限を設定する場合、IAM(Identity and Access Management) を使います。
しかし用語が多くて混乱しがち。自分用のメモとして、IAMの用語とポリシーの基本を簡単に整理します。

1. IAMポリシーの例

以下は、あるIAMポリシーのJSON例です。CloudWatchやEC2、Health APIなどの「Describe」「Get」「List」系アクションを許可しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "cloudwatch:Describe*",
                "cloudwatch:Get*",
                "cloudwatch:List*",
                "ec2:Describe*",
                "ec2:GetAllowedImagesSettings",
                "ec2:GetEbsDefaultKmsKeyId",
                "ec2:GetInstanceMetadataDefaults",
                "ec2:GetSerialConsoleAccessStatus",
                "ec2:GetSnapshotBlockPublicAccessState",
                "ec2:GetTransitGatewayPrefixListReferences",
                "ec2:SearchTransitGatewayRoutes",
                "health:DescribeAffectedEntities",
                "health:DescribeEventDetails",
                "health:DescribeEvents",
                "kinesis:Describe*",
                "tag:GetResources",
                "tag:GetTagKeys",
                "tag:GetTagValues"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

ポリシー概要

Version
日付形式のバージョン (慣例的に 2012-10-17 と書く)
Statement
実際に許可する/拒否するルールのまとまり
- Action
  許可/拒否の対象となる操作
- Effect
  Allow か Deny
- Resource
  どのリソースに対してか (ここでは * 全リソース)

このポリシーをロールやユーザーにアタッチすれば、上記のアクションが実行できるようになります。

2. IAM用語のおさらい

2-1. Principal（プリンシパル）

「AWSリソースにアクセスする主体」のこと。
具体的には、IAMユーザー、IAMロール、AWSサービス(サービスロール) などが該当。
ポリシーでは "Principal": { ... } の形で、「誰がアクセスできるか」を指定する場合がある。

2-2. User（IAMユーザー）

AWSアカウント内で作成する個別のログイン情報。
主に人間がコンソールログインする場合や、アクセスキーを発行してプログラム的アクセスをするときに利用。

2-3. Role（ロール）

一時的な権限を付与する仕組み。
EC2インスタンスやLambdaなどに割り当てて、プログラムからAWSリソースを操作する際に使われる。
AssumeRole というステップを通じて利用する。

2-4. Policy（ポリシー）

「誰が（どんなアクション）を（どのリソース）に実行できるか/できないか」を定義するJSONドキュメント。
上記の例のように Action・Effect・Resource を中心に書く。

2-5. Managed Policy / Inline Policy

Managed Policy: IAM管理ポリシー。使い回しや一括管理ができる。
Inline Policy: 特定のユーザーやロールにのみ埋め込むポリシー。一度作ると再利用しづらいが、細かい管理向けに利用される。

2-6. Action（アクション）

cloudwatch:Describe* や ec2:Get* など、AWSの各サービスが提供するAPI操作名。
Describe, Get, List は読み取り系の操作が多い。

2-7. Effect（効果）

Allow または Deny
明示的Deny があれば最優先で拒否となる。

2-8. Resource（リソース）

arn:aws:ec2:us-east-1:123456789012:instance/i-xxxxx のように、AWSリソースを一意に指定。
例のポリシーでは * なので「すべてのリソース」を対象にしている。

3. ポリシーを設定する流れ

ポリシー作成
- 管理コンソール(またはCLI)でJSONを書くか、ビジュアルエディターで設定。
ロールまたはユーザーを作成/選択
- EC2に割り当てるなら、ロールを新規作成して “EC2が使うロール” にする。
- 人間がコンソール操作やCLIを使う場合はIAMユーザーにアタッチ。
ポリシーをアタッチ
- 作成したポリシーを、該当のロール(またはユーザー)に関連づける。
実際にテスト
- CLIやコンソールから describe-instances を実行するなどして、権限が機能するか確かめる。

4. どんなポリシーが必要になるか？

この例は「監視用途の読み取り権限」を想定しています。

cloudwatch:Describe*, cloudwatch:Get*, cloudwatch:List*
- CloudWatchのメトリクスやアラーム、ロググループなどを読み取る
ec2:Describe*
- インスタンスやVPCなどEC2関連の情報取得
health:Describe*
- AWS Health APIから障害情報などを取得
tag:GetResources など
- リソースのタグ情報を一括で取得

いずれも書き込み操作は含まれていません。モニタリングツール（Datadogなど）向けに付与することが多い権限です。

5. まとめ

AWS IAMは、「誰が」「どんな操作を」「どのリソースに対して」行うかを柔軟にコントロールする仕組み。
ポリシーのJSON内では、Action・Effect・Resource が最重要要素。
今回の例のように読み取り系の操作だけを指定しておくことで、最小権限の原則に近づける。
これらを踏まえ、IAMポリシーを読んで何が許可/拒否されるのか、すぐに判断できるようになれば、AWSリソース管理のトラブルシュートもスムーズになる。