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

現場のエンジニアへ：最小権限の原則（PoLP）は「気合」ではなく「構造」で縛れ

インフラ担当や開発者が陥りやすい最大の罠は、「とりあえず動く」権限をIAMに与えてしまうことだ。君たちが深夜にデバッグで疲れている時、AdministratorAccessを付与した開発環境のIAMキーがGitHubに流出したらどうなるか？攻撃者はそのキーを使い、数分で全リージョンのEC2をマイニングサーバーに変え、全S3バケットを暗号化するだろう。

今日は、教科書的な「最小権限の原則（PoLP）」を、泥臭い実務レベルでどう実装し、SCP（Service Control Policies）でガードレールを敷くか、その極意を伝授する。

—

1. 攻撃者の視点：なぜ「インラインポリシー」は悪なのか

インラインポリシーは、特定のIAMユーザーやロールに直接紐付く「その場限りの権限」だ。これの何が危険か？それは「棚卸しが不可能」という点に尽きる。

攻撃者がWebアプリケーションの脆弱性（LFIやSSRF）を突き、メタデータサービス（IMDSv2）から一時的な認証情報を奪取したとしよう。もしそのロールにインラインポリシーで過剰な権限が付与されていたら、調査担当者はIAMコンソールのUIを一つずつ開いて、数千行のJSONを読み解く羽目になる。インシデント発生時の「有事」において、インラインポリシーは防御側を麻痺させる毒薬だ。

対策の鉄則

インラインポリシーは禁止せよ: 全てマネージドポリシー、または顧客管理ポリシーとして切り出せ。
名前で管理せよ: App-ReadOnly-Access のように、用途と権限レベルが一目でわかる命名規則を強制する。

—

2. 実装：Terraformによる「管理された」IAMポリシー定義

開発者がインラインポリシーを書く隙を与えないために、TerraformなどのIaCで型を強制する。以下は、S3バケットへの読み取り専用アクセスのみを許可する、堅牢なポリシーのテンプレートだ。

# 顧客管理ポリシーの定義（再利用可能かつ可視化されている）
resource "aws_iam_policy" "read_only_s3_policy" {
  name        = "AppS3ReadOnlyPolicy"
  description = "特定のバケットのみ読み取りを許可する最小権限"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "s3:Get*",
          "s3:List*"
        ]
        Effect   = "Allow"
        Resource = [
          "arn:aws:s3:::my-secure-data-bucket",
          "arn:aws:s3:::my-secure-data-bucket/*"
        ]
      }
    ]
  })
}

—

3. SCPによるガードレール：開発者の「ミス」を物理的に封じる

いくらIAMポリシーを厳格にしても、誰かが権限昇格を試みれば終わりだ。ここで登場するのがSCPだ。SCPは、AWS Organizations配下の全アカウントに対し、「たとえルートユーザーであっても拒否する」という最強の境界線を作る。

例えば、「リージョンを固定する」「IAMポリシーの変更を特定ロール以外禁止する」といったルールを、SCPで組織全体に適用する。

SCPサンプル：IAM設定の改ざん禁止

以下のポリシーをルートOU（組織単位）に適用すれば、悪意ある開発者や乗っ取られたアカウントが、自ら権限を広げようとする試みを即座に AccessDenied で弾ける。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIAMPolicyModification",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:SetDefaultPolicyVersion",
        "iam:DeletePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdminRole" 
        }
      }
    }
  ]
}

*※この設定により、SecurityAdminRole 以外のユーザーによる権限変更が完全にブロックされる。*

—

4. エンジニアへのアドバイス：権限付与のフローを変えろ

「この機能を作るのにS3への書き込み権限が必要だから、とりあえず全部許可してくれ」という開発者からの依頼に対し、君たちはどう答えるべきか？

1. 「なぜ」を問う: その機能が本当に s3:PutObject を必要としているか？
2. スコープを絞る: Resource を * にせず、特定のプレフィックス（例: uploads/*）に限定できないか？
3. IAM Access Analyzerを活用する: 過去90日間のアクセスログを分析し、実際に使われていない権限を機械的に削ぎ落とせ。

最後に

セキュリティは「性善説」で回るものではない。IAMポリシーやSCPという「コードによる制約」をシステムに組み込むことで初めて、エンジニアは心理的な負荷から解放され、よりクリエイティブな開発に集中できるのだ。

明日の朝、君たちのAWS環境で、インラインポリシーが一つでも残っていないか確認してほしい。それが、プロのセキュリティエンジニアとしての第一歩だ。