IAM — ポリシー評価・権限境界・クロスアカウント

IAM 権限評価の全体像

AWS IAMの権限評価は、複数のポリシータイプが階層的に作用する仕組みです。ここではそのメカニズムを正確に理解することが、本試験の合格と実務での事故防止の鍵になります。

ポリシー評価エンジンの流れ

権限評価の判定フローは、以下の順序で進みます。

1. デフォルトは「明示的な拒否」
2. Organizations SCP（Service Control Policy）でチェック
3. リソースベースのポリシー（存在時）
4. Permission Boundary でチェック
5. Identity-based ポリシーでチェック
6. セッションポリシー（AssumeRole時）でチェック
7. どのポリシーにも「拒否」があれば → アクセス拒否
8. すべてを通過したら → アクセス許可

重要な原則：

• 明示的な拒否は覆らない。どのポリシーで許可されていても、1つの「Deny」ですべてがブロックされます
• 許可には複数の同意が必要。例えば Permission Boundary では「許可」していても、Identity-based で「許可」されていなければアクセス不可
• 評価順序は概ね決まっているが、実装詳細は非公開部分あり。試験では「最終的な結果」を問う問題が多い

試験で狙われるポイント：

• SCPと Identity-based の両方で Deny がある場合の結果
• Permission Boundary が有効な際の複雑な権限構成
• Cross-Account での評価順序

IAM ポリシー評価フロー図

ポリシーエディタの実際の操作画面

AWS マネジメントコンソールの IAM ポリシーエディタは以下のように表示されます。

---

ポリシーの種類と役割

1. Identity-based ポリシー

ユーザー、グループ、ロールに直接アタッチされるポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

特徴：

• 最も一般的な権限付与方式
• 複数のポリシーをアタッチ可能
• 最大管理ポリシーサイズは 10 KB（インラインポリシー）、管理ポリシーは 10 KB
• ユーザーあたりアタッチできる管理ポリシー数は最大 20 個

制約と落とし穴：

• インラインポリシーの数に上限がない（10 KB 制限内）が、数が多いと管理が破綻しやすい
• 過去に AWS ではインラインポリシー推奨から管理ポリシー推奨へシフト
• "Action": "*" と "Resource": "*" は Admin アクセスと同等（S3以外）

2. Resource-based ポリシー

S3、SNS、SQS、KMS などのリソース側に設定されるポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-B:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::bucket-a/*"
    }
  ]
}

特徴：

• Principal を指定して、「誰が」アクセスできるかを定義
• Cross-account アクセスの主要な手段
• リソース所有者が直接制御
• IAM ロールも Principal として指定可能

評価時の重要性：

• Identity-based で許可されていなくても、Resource-based で許可されていればアクセス可能（ただし同じ AWS アカウント内など条件あり）
• Cross-account の場合は、両方のアカウントで許可されている必要がある
  • アカウント A のロール：Identity-based で s3:GetObject を許可
  • アカウント B のバケット：アカウント A のロールを Principal に s3:GetObject を許可
  • この両方が必要

3. Permission Boundary（権限境界）

ユーザーまたはロールが取得できる最大権限を定義します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "logs:*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

重要な特性：

複雑な例：権限の交集合

ユーザーに以下を設定した場合：

Identity-based:

{
  "Effect": "Allow",
  "Action": ["ec2:*", "s3:*"],
  "Resource": "*"
}

Permission Boundary:

{
  "Effect": "Allow",
  "Action": ["ec2:DescribeInstances", "s3:GetObject"],
  "Resource": "*"
}

結果： ユーザーが実行できるのは ec2:DescribeInstances と s3:GetObject のみ。他の EC2 操作や S3 操作はすべてブロック。

試験で狙われるポイント：

• Boundary で “Deny” は使わない（制限しない）。必ず “Allow” で上限を定義
• Boundary の交集合を正確に計算できるか
• Boundary が設定されていない場合の挙動

Permission Boundary の交集合図

4. Organizations SCP（Service Control Policy）

組織レベルで全アカウントに対して適用される最大権限ポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "iam:DeleteUser",
      "Resource": "*"
    }
  ]
}

重要な特性：

よくある設計パターン：黒リストベース

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRole",
        "iam:DeleteRolePolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "*"
    }
  ]
}

設計パターン：白リストベース

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

制約と落とし穴：

• SCP は委任アカウント（Delegated Admin）でも管理不可。管理アカウント（Management Account）のみ
• ルートアカウントのアクセスキーは SCP の影響を受けない（IAM ユーザーのみ対象）
• SCP を無効化すると「すべてが許可される」状態になる。実装時は明示的な "Allow" を含める

試験で狙われるポイント：

• SCP が適用されないケース（ルートユーザー、ルートアカウント IAM ユーザー）
• 複数の SCP が適用される場合の評価（共通部分のみが有効）
• SCP と IAM ポリシーの評価順序

5. セッションポリシー

AssumeRole や GetSessionToken 時に、一時的に権限をさらに制限する仕組みです。

import boto3

sts = boto3.client('sts')

response = sts.assume_role(
    RoleArn='arn:aws:iam::123456789012:role/MyRole',
    RoleSessionName='session-1',
    DurationSeconds=900,
    Policy='''
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "s3:GetObject",
          "Resource": "arn:aws:s3:::my-bucket/public/*"
        }
      ]
    }
    '''
)

重要な特性：

• ロール本体の Identity-based よりも更に制限できる
• セッションポリシーなしでロールアシューム → ロール本体の権限をすべて取得
• セッションポリシーありでロールアシューム → ロール本体と セッションポリシーの交集合のみ

制約：

• セッションポリシーの最大サイズ：2048 バイト
• Deny ステートメントは無視される（制限のみ）
• 一時的なセッション中のみ有効

試験で狙われるポイント：

• AssumeRole 時のセッションポリシーの効果
• Root トークンでのセッションポリシー（IAM ユーザーのアクセスキー経由の場合）

ポリシー評価の複雑なシナリオ

シナリオ 1：Permission Boundary と Identity-based の交集合

Identity-based（ユーザーAに付与）:

{
  "Effect": "Allow",
  "Action": ["ec2:*", "s3:*"],
  "Resource": "*"
}

Permission Boundary（ユーザーAに設定）:

{
  "Effect": "Allow",
  "Action": ["ec2:DescribeInstances", "ec2:StartInstances"],
  "Resource": "*"
}

結果： ユーザーA が実行できるのは ec2:DescribeInstances と ec2:StartInstances のみ。S3 操作はすべて拒否。

シナリオ 2：SCP と Identity-based の Deny

SCP（組織ルートに適用）:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

（ここでは事実上、制限なし）

Identity-based（ユーザーに付与）:

{
  "Effect": "Deny",
  "Action": "iam:DeleteUser",
  "Resource": "*"
}

結果： ユーザーは iam:DeleteUser を実行不可。

シナリオ 3：Cross-Account + Permission Boundary

アカウント A のロール（Permission Boundary 設定）が、アカウント B のリソースにアクセスする場合：

アカウント A側（ロールの Identity-based）:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

アカウント A側（Permission Boundary）:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "*"
}

アカウント B側（S3 バケットポリシー）:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::ACCOUNT-A:role/MyRole"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket-b/*"
}

結果： ロールが実行できるのは s3:GetObject のみ。

Conditions（条件）の活用

IAM ポリシーの条件句は、権限を時間軸・ネットワーク・タグなどで動的に制限する最強ツールです。

主要な Condition キー

複雑な Condition 例：ABAC（属性ベースアクセス制御）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "${aws:username}"
        }
      }
    }
  ]
}

このポリシーは、ユーザー名と同じ値を Environment タグに持つ EC2 インスタンスにのみアクセス可能にします。例えば、ユーザー alice は Environment=alice のインスタンスにのみアクセス可能。

利点：

• ポリシー数が減少（リソースごとにポリシーを書く必要がない）
• スケーラビリティが向上（新しいリソース追加時、タグ付けのみで権限が自動適用）

試験で狙われるポイント：

• ${aws:username} などの政策変数の使用
• タグベースの Condition の評価
• AND / OR の論理評価（複数の Condition）

できないこと・制約

クォータと上限

ポリシー評価での制約

よくある落とし穴

落とし穴 1：ワイルドカード の誤解

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::bucket/*"
}

このポリシーでは、s3:GetBucketPolicy など バケット自体への操作は許可されていません。バケット操作とオブジェクト操作は ARN が異なります。

修正：

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::bucket",
    "arn:aws:s3:::bucket/*"
  ]
}

落とし穴 2：Permission Boundary で Deny を使う

// 間違い
{
  "Effect": "Deny",
  "Action": "iam:DeleteUser",
  "Resource": "*"
}

Permission Boundary は 上限を定義するものであり、制限は "Allow" で明示的に列挙します。Deny を使うと予期しない動作が発生します。

落とし穴 3：Cross-Account の片側だけ許可

アカウント A のロールが、アカウント B のバケットにアクセスする場合：

• アカウント A の Identity-based で許可 ✓
• アカウント B のバケットポリシーで許可 ✓
• 両方 必須

どちらか片方だけでは失敗します。

落とし穴 4：AssumeRole の ExternalId を無視

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::ACCOUNT-A:role/MyRole"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "unique-secret-123"
    }
  }
}

ExternalId なしでは、アカウント A のどのロールでも AssumeRole できます。本試験では セキュリティベストプラクティスとして出題される可能性が高い。

落とし穴 5：SCP がルート IAM ユーザーに効かない

• ルートアカウントの IAM ユーザー → SCP の影響を受ける
• ルートアカウント（Management Account）の IAM ユーザー → SCP の影響を受ける
• ルートアカウント認証情報（アクセスキー） → SCP の影響を受けない（ルートユーザーの API キー）

試験では「どのユーザーが SCP の影響を受けるか」を問う問題が頻出です。

クロスアカウント設計パターン

パターン 1：AssumeRole ベース（最推奨）

構成：

アカウント A（信頼元）

• ユーザー alice → ロール RoleA をアシューム

アカウント B（信頼先）

• ロール RoleB（AssumeRole 許可の信頼ポリシー）

アカウント A 側（Identity-based）:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::ACCOUNT-B:role/RoleB"
}

アカウント B 側（RoleB の信頼ポリシー）:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::ACCOUNT-A:root"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "unique-secret"
    }
  }
}

利点：

• セッション権限で一時的な制限が可能（セッションポリシー）
• CloudTrail で監査追跡が明確
• リスク分離が可能

パターン 2：リソースベースのポリシー

構成：

アカウント A

• ロール RoleA

アカウント B

• S3 バケット（バケットポリシーで RoleA を許可）

バケットポリシー:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::ACCOUNT-A:role/RoleA"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

利点：

• AssumeRole 不要（直接アクセス）
• シンプルな設定

欠点：

• 権限の一時的な制限（セッションポリシー）が使えない
• RoleA 本体の権限に依存

パターン 3：ロール チェーン（スイッチロール）

構成：

アカウント A

• ロール RoleA → AssumeRole → RoleB（アカウント B）
  • RoleB → AssumeRole → RoleC（アカウント C）

各ロールが次のロールをアシューム可能に設定します。

注意点：

• 監査が複雑になる（CloudTrail で追跡困難）
• パフォーマンス低下（複数の AssumeRole が必要）
• 試験では避けるべき設計として言及される可能性

Cross-Account アクセスの評価フロー

フェデレーション と IAM Identity Center

SAML ベースのフェデレーション

外部の IDP（IdP）から AWS へのアクセスを提供します。

フロー：

ユーザー（Okta など）

• SAML Assertion ↓ IdP
• SAML 信頼ポリシー ↓ IAM ロール
• Assume ↓ AWS リソース

IAM ロールの信頼ポリシー例：

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:saml-provider/Okta"
  },
  "Action": "sts:AssumeRoleWithSAML",
  "Condition": {
    "StringEquals": {
      "SAML:aud": "https://signin.aws.amazon.com/saml"
    }
  }
}

特徴：

• 既存の企業 IDP を統合可能（Active Directory など）
• Federation Token は最大 1 時間（更新不可）
• CloudTrail で federated principal として記録される

IAM Identity Center（IAM Identity Center）

AWS が提供するマネージドフェデレーションサービス。

構成：

IAM Identity Center

• Cloud Identity Directory（AWS が管理）
• External IDP 統合（Okta, Azure AD など） ↓ ユーザー・グループ管理 ↓ Permission Sets ↓ アカウント・ロール割り当て

Permission Sets の例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:DescribeInstances"],
      "Resource": "*"
    }
  ]
}

特徴：

• 複数アカウント管理が一元化
• セッション期限をコントロール可能
• Permission Sets は組織全体で再利用可能

Identity Center vs SAML：

試験で狙われるポイント：

• SAML Federation の信頼ポリシー
• Identity Center の Permission Sets と組織設計の関係

ABAC（属性ベースアクセス制御）

基本概念

IAM ポリシーでユーザーやリソースの属性（タグ） に基づいてアクセスを制御します。

例：

User: alice

• Tags:
  • Department=Engineering
  • Level=Senior

EC2 Instance:

• Tags:
  • Owner=alice
  • Environment=production
  • Level=Senior

ポリシー： alice が Owner タグを持つリソースにアクセス可能

ABAC のポリシー例

{
  "Effect": "Allow",
  "Action": "ec2:TerminateInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringEquals": {
      "ec2:ResourceTag/Owner": "${aws:username}",
      "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
    }
  }
}

この例：

• ユーザーが Owner タグとして自分のユーザー名を持つインスタンス
• AND ユーザーのタグ Department とリソースの Department タグが同じ
• この両方の条件を満たすインスタンスのみ終了可能

ABAC vs RBAC

ABAC 利用時のベストプラクティス：

1. タグスキーマを統一

   • 命名規則を決める（Department, Environment, Owner など）
   • チーム全体で徹底

2. タグの自動付与

   • CloudFormation や Terraform で自動化
   • Launch Template で EC2 の自動タグ付け

3. Permission Boundary + ABAC

   {
     "Effect": "Allow",
     "Action": "ec2:*",
     "Resource": "*",
     "Condition": {
       "StringEquals": {
         "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
       }
     }
   }

試験で狙われるポイント：

• 政策変数（${aws:username}, ${aws:PrincipalTag/*} など）の使用
• ABAC の限界（すべてのリソースタイプをサポートしない）

ベストプラクティス

1. 最小権限の原則（Principle of Least Privilege）

ポリシー設計の基本：

// 間違い：広すぎる
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

// 正しい：必要最小限
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/documents/*"
  ]
}

段階的なレビュー：

1. 設計段階：ユースケースを書き出す（何をするのか）
2. 実装段階：必要なアクションのみ定義
3. 監査段階：CloudTrail で実際の使用を確認、不要なアクションを削除

2. 権限の定期的な監査

CloudTrail を使った監査：

import boto3
import json

cloudtrail = boto3.client('cloudtrail')

events = cloudtrail.lookup_events(
    LookupAttributes=[
        {
            'AttributeKey': 'ResourceType',
            'AttributeValue': 's3'
        }
    ]
)

for event in events['Events']:
    print(json.dumps(json.loads(event['CloudTrailEvent']), indent=2))

Access Analyzer を使った自動分析：

• 外部アクセス可能なリソースを自動検出
• ポリシーの妥当性を検証

3. グループベースの権限管理

aws-developers グループ
├── EC2 読み取り権限
├── S3 開発環境へのアクセス
└── CloudWatch ログ読み取り

aws-admins グループ
├── IAM 全操作
├── Organization 管理
└── Billing

ポリシーアタッチ：

aws iam attach-group-policy \
  --group-name aws-developers \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

4. Service-Linked Roles の活用

AWS 一部サービスが自動作成し管理するロール。

# AWS Lambda が自動作成する実行ロール
aws iam get-role --role-name AWSLambdaBasicExecutionRole

特徴：

• 削除不可（サービスがアンリンクするまで）
• 信頼ポリシーは変更不可
• 権限は事前に定義（カスタマイズ不可）

5. MFA の強制

{
  "Effect": "Allow",
  "Action": "iam:DeleteUser",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

実装例（IAM ユーザーの管理操作時）：

{
  "Effect": "Deny",
  "Action": "iam:*",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

他サービスとの連携パターン

CloudTrail との連携

すべての IAM アクションは CloudTrail に記録されます。

{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDACKCEVSQ6C2EXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/alice",
    "accountId": "123456789012",
    "userName": "alice"
  },
  "eventTime": "2026-04-27T10:30:45Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "CreateUser",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "192.0.2.1",
  "userAgent": "aws-cli/2.10.0"
}

監査ポイント：

• eventName：何のアクションが実行されたか
• sourceIPAddress：どこから実行されたか
• requestParameters：具体的なパラメータ

AWS Config との連携

IAM 設定の変更を自動検追跡。

Rule: iam-policy-no-statements-with-admin-access
→ Admin 権限を持つポリシーを自動検出

Rule: iam-root-access-key-check
→ ルートアカウントのアクセスキー使用を検出

Organizations + SCP との連携

Organization Root
├── SCP: 組織全体で IAM 削除禁止
├── OU: Production
│   ├── SCP: EC2 削除禁止
│   └── Account A
├── OU: Development
│   ├── SCP: なし（より自由）
│   └── Account B
└── OU: Security
    ├── SCP: 厳密
    └── Account C (Delegated Admin)

AWS SSM Session Manager との連携

IAM ロールベースの EC2 へのセッションレス接続。

{
  "Effect": "Allow",
  "Action": [
    "ssm:StartSession",
    "ssm:ResumeSession",
    "ssm:TerminateSession"
  ],
  "Resource": [
    "arn:aws:ssm:*:*:session/SessionManager-*",
    "arn:aws:ec2:*:*:instance/*"
  ],
  "Condition": {
    "StringEquals": {
      "ec2:ResourceTag/Environment": "production"
    }
  }
}

試験で狙われるポイント総まとめ

---

まとめ

IAM の本質は「複数のポリシーレイヤーの交集合と AND 演算」です。

• Identity-based：基本の権限定義
• Permission Boundary：上限の定義
• SCP：組織全体の大枠
• Resource-based：リソース所有者の最終判定
• セッションポリシー：一時的な制限

この5つが各レイヤーで協調することで、スケーラブルで監査可能なアクセス制御が実現します。

試験では「複雑なシナリオで最終的なアクセス許可・拒否を判定する」問題が必出。各ポリシーの評価順序と、複数ポリシーの交集合を正確に計算できることが合格の鍵です。