【テクニカル・上級編】 AWS IAMにおける最小権限の原則(PoLP)の実装とSCPによるガードレール – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

クラウドの「信頼」をハックする者たち：IAMとSCPで強制する最小権限の現実解

数多のインシデントハンドリングを手がけてきた経験上、クラウド環境におけるセキュリティ侵害の9割以上は、アプリケーションのゼロデイ脆弱性ではなく、「アイデンティティとアクセス管理（IAM）の設計ミス」に起因している。

攻撃者は洗練されたエクスプロイトコードを書くまでもなく、単に野良IAMロールに付与された過剰な権限（*の乱用）を悪用し、sts:AssumeRoleを踏み台にしてマネージメントコンソールを我が物顔で歩き回る。脆弱なパスワードや漏洩したアクセスキーは、最小権限の原則（PoLP: Principle of Least Privilege）が鉄壁に守られた環境であれば、単なる「一過性のノイズ」で終わるはずなのだ。

今回は、AWS環境においてこのPoLPを理想論で終わらせず、組織全体で強制するための実践的なアーキテクチャ、すなわち「インラインポリシーの完全排除」と「Service Control Policies（SCP）によるガードレール」の構築手法を、現場の泥臭い知見を交えて徹底的に解説する。

—

1. なぜ「インラインポリシー」は悪なのか？

AWS IAMポリシーの付与方法には、マネージドポリシーとインラインポリシーがある。セキュリティ監査の現場で最も頭痛の種となるのが、この「インラインポリシー」の存在だ。

インラインポリシーは特定のユーザー、グループ、ロールに直接埋め込まれるため、以下の致命的なセキュリティリスクを孕む。

  • ライフサイクル管理の欠如: アイデンティティの削除とともにポリシーが消滅するため、再利用や監査のトレーサビリティが著しく低下する。
  • 変更管理のブラックボックス化: TerraformやCloudFormationなどのIaC（Infrastructure as Code）管理外で、コンソールからアドホックに権限が追加されやすい。
  • バージョン管理の不在: マネージドポリシーと異なり、過去のバージョンへのロールバック（aws iam rollback-policy-version）が効かない。

対策：IAMリソースの完全なIaC化とSCPによる制限

インラインポリシーを根絶するためには、開発者やクラウドエンジニアがコンソールからポチポチとポリシーを追加できない状態を強制する必要がある。これには、AWS OrganizationsのSCPが唯一にして最強の武器となる。

—

2. SCP（Service Control Policies）によるガードレールの設計

SCPは、AWSアカウントの最大権限境界（Permission Boundary）を定義するためのメカニズムである。IAMポリシーが「何を許可するか」を決定するのに対し、SCPは「組織内のアカウントが絶対に実行できないこと（拒否の境界）」を定義する。

ここで重要なのは、SCP単体では権限を「付与」せず、あくまで境界（Guardrail）として機能する点だ。

実践的SCP：インラインポリシーの作成・変更を物理的にブロックする

以下のSCPは、組織内の特定のアカウント（あるいは全メンバーアカウント）において、インラインポリシーの作成やアタッチをAPIレベルで拒否する設定である。これをルートOU（Organization Unit）またはワークロードOUに適用する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInlinePolicyCreation",
      "Effect": "Deny",
      "Action": [
        "iam:PutUserPolicy",
        "iam:PutGroupPolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyFullAdministratorAccessGrant",
      "Effect": "Deny",
      "Action": [
        "iam:AttachUserPolicy",
        "iam:AttachGroupPolicy",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "ArnEquals": {
          "iam:PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
        }
      }
    }
  ]
}

このSCPのキモは、iam:Put*Policy アクションを完全に封じつつ、マネージドポリシーであっても危険な AdministratorAccess のアタッチを条件分岐（ArnEquals）で弾いている点だ。これにより、現場のエンジニアがどれだけ権限昇格を試みようとも、AWSのAPIレイヤーで弾かれることになる。

—

3. IAMポリシーにおける「ワイルドカード（*）」の呪縛と正しい権限分離

PoLPを実装する上で、もう一つ避けて通れないのがワイルドカードの乱用だ。例えば、S3バケットへのアクセスを許可する際に、以下のようなポリシーを書いていないだろうか。

❌ 悪しきアンチパターン

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

これでは、S3のデータプレーン（オブジェクトの読み書き）だけでなく、コントロールプレーン（バケットの削除や暗号化設定の変更）まで全権限を与えていることになる。万が一、この権限を持つコンテナが踏み台にされた場合、環境全体のデータが暗号化ランサムウェアの餌食になるか、完全消去される。

⭕ 正しい最小権限の設計（リソースベースとアクションの限定）

特定のアプリケーションが特定のS3バケットに対してのみ、オブジェクトのputとgetを行う場合の正しいポリシー設計は以下の通りだ。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificBucketObjectOperations",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:AbortMultipartUpload"
      ],
      "Resource": [
        "arn:aws:s3:::my-company-secure-workload-bucket-prod/*"
      ]
    },
    {
      "Sid": "AllowListBucketOnly",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-company-secure-workload-bucket-prod"
      ]
    }
  ]
}

ここでは、バケット自体のメタデータを操作する権限（ListBucketなど）と、バケット内のオブジェクトを操作する権限（GetObjectなど）の Resource のパス（末尾の /* の有無）を厳密に分離している。このレベルの粒度をすべてのリソース（DynamoDB、Lambda、KMS等）で徹底するのが真のPoLPである。

—

4. 監査と継続的モニタリング：アクセスアナライザーの活用

どれだけ厳密に設計しても、組織が拡大するにつれてシャドーITや権限の肥大化（Permission Creep）は必ず発生する。これを人間が目視で監査するなど不可能なため、IAM Access Analyzerを活用した自動化を組み込む。

インフラストラクチャをIaC（Terraformなど）でデプロイする際、CI/CDパイプライン上でIAMポリシーの静的解析を行うツール（例: Conftest や Checkov）を必ず組み込むべきだ。

以下は、Checkovを使用してTerraformコード内の過剰な権限（Action: * や Resource: *）を検出し、ビルドを失敗させるための設定例（カスタムポリシーの概念）だ。

# checkov カスタムチェックの例 (IAMポリシーで * を禁止する)
metadata:
  id: CKV_AWS_CUSTOM_001
  name: "Ensure IAM policies do not allow full administrative privileges"
  category: "IAM"
definition:
  cond_type: "attribute"
  resource_types:
    - "aws_iam_policy"
    - "aws_iam_role_policy"
  attribute: "policy"
  operator: "json_contains"
  value: "Action: *"
  eval_switch: false

—

5. まとめ：セキュリティは「性善説」を捨てた構造から始まる

クラウドセキュリティの本質は、エンジニアのモラルやセキュリティ意識に依存することではなく、「ミスや不正が構造的にできない環境」をコードとポリシーで強制することにある。

インラインポリシーの排除と、SCPによる組織的なガードレールの敷設は、そのための最も確実な第一歩だ。「便利さ」と引き換えにセキュリティをトレードオフにする時代は終わった。今すぐ組織のAWS Organizationsを見直し、野放しになっている権限の境界線を再定義してほしい。あなたの背後で狙っているアタッカーは、その「甘い設定」を今日も静かにスキャンしているのだから。

スポンサーリンク

コメント

タイトルとURLをコピーしました