AWS IAM ポリシー評価ロジック

📌

IAMとは何か

AWS Identity and Access Management（IAM）は、AWSリソースへのアクセスを安全に制御するためのサービスです。 建物の入退室管理システムに例えると、IAM は「社員証（認証）」と「どのフロアに入れるか（認可）」を一元管理する仕組みに相当します。 「誰が」「何を」「どのリソースに」「どんな条件で」アクセスできるかを、JSONポリシー文書できめ細かく定義します。

IAM は無料で利用でき、グローバルサービス（リージョンに依存しない）として動作します。 主要なコンポーネントはユーザー（User）、グループ（Group）、ロール（Role）、ポリシー（Policy）の4つです。 これらが組み合わさって、アクセス制御の全体像が形成されます。

設計思想の中心にあるのは最小権限の原則（Least Privilege Principle）です。 必要最小限の権限だけを付与することでセキュリティリスクを最小化します。 IAM はデフォルトですべてを「拒否」しており、明示的な Allow ステートメントがある場合のみアクセスが許可されます。

🗺️

ポリシーの全体像

IAM には複数の種類のポリシーがあり、それぞれ役割が異なります。「どれがどれの一部なのか」が混乱しやすいので、まず全体の関係を整理します。

ポリシーは大きく分けて「権限を与えるもの」と「権限の上限を制限するもの」の2種類があります。これらは別々の仕組みであり、親子関係ではありません。

👤

ポリシー

正式名称はアイデンティティベースポリシー（Identity-based Policy）ですが、一般的に「IAMポリシー」や単に「ポリシー」と呼ばれます。IAM ユーザー・グループ・ロールにアタッチして、「このプリンシパルは何ができるか」を定義する最も基本的なポリシー形式です。

アイデンティティベースポリシーには管理方法の違いから3種類があります。それぞれ再利用性・柔軟性・管理コストのトレードオフが異なります。 実務ではカスタマー管理ポリシーを最小権限で作成して再利用するのがベストプラクティスとされています。 インラインポリシーは「このエンティティだけに絶対に共有させたくない」例外的なケースに限定して使うのが推奨されます。

ポリシーは JSON 形式で定義します。中心となるのは Statement 配列で、各ステートメントが「何を許可/拒否するか」を1つずつ定義します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",        // 許可 or 拒否（"Deny"）
      "Action": [              // どの操作を
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [             // どのリソースに対して
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

📦

リソースベースポリシー

リソースベースポリシー（Resource-based Policy）は、S3 バケット、SQS キュー、Lambda 関数などのリソース側に直接アタッチするポリシーです。 アイデンティティベースポリシーが「この人は何ができるか」を定義するのに対し、リソースベースポリシーは「このリソースは誰に使わせるか」を定義します。Principal フィールドで許可するユーザー・ロール・アカウントを明示します。

特に重要なのがクロスアカウントアクセスのシナリオです。同一アカウント内と異なるアカウント間とで、許可に必要なポリシーの組み合わせが変わります。この違いを正確に理解することがセキュリティ設計の要です。

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

ポリシーとの違いは Principal フィールドがあることです。「誰に」許可するかをリソース側で指定します。上の例では別アカウント（999888777666）からの S3 読み取りを許可しています。

🏢

SCP（Service Control Policies）

SCP（サービスコントロールポリシー）は、AWS Organizations で使用する組織レベルのガードレールです。 会社の就業規則に例えると、「どんな部署の社員でも、これは絶対にやってはいけない」という全社規程に相当します。 OU（Organizational Unit）またはアカウントにアタッチし、そのアカウント内のすべてのIAMエンティティが実行できる操作の「上限」を定義します。

重要な点は、SCP は権限を「与える」ものではなく「制限する」ものだということです。 SCP はあくまで「許可してよい操作の範囲」を定義するフィルターであり、SCP 単体では何も許可しません。IAM ポリシーで Allow があっても、SCP の範囲外ならアクセスは拒否されます。 また、管理アカウント（Management Account）自体には SCP は適用されません。

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

このSCPでは S3, EC2, Lambda, DynamoDB のみ許可しています。このOUのアカウントでは、IAMポリシーで iam:CreateUser を Allow にしていても、SCPの許可リストに iam:* が含まれていないため実行できません。

🔒

Permission Boundary（アクセス許可境界）

Permission Boundary（アクセス許可境界）は、IAM ユーザーやロールが持てる権限の「上限」を設定する機能です。

通常のポリシー（アイデンティティベースポリシー）は「何ができるか」を定義しますが、Permission Boundary は「何ができるかの最大範囲」を定義します。ポリシーで許可されていても、Boundary の範囲外なら拒否されます。

重要なポイントは、Boundary を設定しただけでは何も許可されないということです。ポリシーと Boundary の両方で許可されている操作だけが実行できます（積集合）。

この Boundary を付けたユーザーは、ポリシーで ec2:* を許可されていても、実行できるのは ec2:Describe* だけです。iam:* が含まれていないので、IAM 関連の操作はすべて拒否されます。

⏱️

セッションポリシー

セッションポリシー（Session Policy）は、AssumeRole や GetFederationToken を呼び出す際にインラインで渡すポリシーです。 一時認証情報のスコープをさらに絞り込む仕組みで、ロールが持つ権限を超えることは絶対にできません。 Permission Boundary と同様に「交差（AND）」ロジックで動作します。

セッションポリシーが特に有効なのはマルチテナント環境です。 同じ強力なロールを使いながらも、セッションごとに異なるテナントのリソースだけにアクセスを制限できます。 これにより、ロールを大量に作成せずとも細かいアクセス制御が実現できます。

ロールは s3:* を許可していますが、セッションポリシーで tenant-a/* に絞っています。このセッション中は tenant-b のデータにはアクセスできません。

⚡

評価の優先順位（黄金ルール）

IAM ポリシーの評価は、複数のポリシーが存在する場合でも常に決定論的なルールに従います。 最も重要な黄金ルールは「明示的 Deny は常に勝つ」です。 どんなに多くの Allow があっても、1つの Deny があれば必ず拒否されます。

IAM の評価は否定ベース（Deny-by-default）で設計されています。 何も設定されていない状態ではすべて拒否であり、明示的な Allow で初めてアクセスが可能になります。 この設計は「必要なものだけを許可する」最小権限の原則と一致しています。

❓

よくある質問（SAA頻出）