【実務・中級編】 AWS IAMにおける最小権限の原則(PoLP)の実装とIAM Access Analyzerによる権限の最適化 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

権限という名の「裏口」を塞げ：IAM最小権限の原則（PoLP）を実践する現場の鉄則

「管理者権限（AdministratorAccess）をとりあえず付与しておけば、デバッグ中にエラーで止まることはない」。

もし君のチームでそんな会話が聞こえてきたら、そのプロジェクトは既に「時限爆弾」を抱えていると断言してもいい。攻撃者が侵入した際、彼らがまず探すのはシェルへのアクセス権ではなく、「何でもできるIAMユーザーの認証情報」だ。

今日は、教科書的な「最小権限の原則（PoLP）」という言葉を、明日から現場で確実に実行するための「泥臭いハック」の話をしよう。

—

なぜ「広すぎる権限」が地獄を見るのか？（PoC的視点）

攻撃者がAWS環境へ侵入した際、彼らはまず sts:GetCallerIdentity を叩き、自分が何者で、どの程度の権限を持っているかを確認する。もしここで s3:ListAllMyBuckets や iam:ListAttachedUserPolicies が通ってしまったら、彼らにとってその環境は「宝探し会場」になる。

特によくあるのが、「WebサーバーのEC2インスタンスに、S3フルアクセス権限を持つIAMロールをアタッチしている」ケースだ。

もしWebアプリケーションに Local File Inclusion (LFI) や SSRF の脆弱性が一つでもあれば、攻撃者はインスタンスメタデータサービス（IMDSv2）経由で一時的な認証情報を奪取し、S3上の顧客個人情報を全件ダウンロードするだろう。これが、君たちが書いたコードの「バグ」が「全社的なセキュリティ事故」に直結するメカニズムだ。

—

ステップ1：IAM Access Analyzerで「死んだ権限」を削ぎ落とす

「最小権限って、具体的にどう決めるの？」という問いに対する唯一の正解は、「実測値に基づく」ことだ。AWS IAM Access Analyzerの「IAMポリシー生成」機能を使えば、実際のログから必要な権限だけを抽出できる。

1. アクセスアドバイザーを確認: IAMコンソールから、過去90日間に使用されていないサービスを特定する。
2. ポリシーの自動生成: 開発環境で該当アプリケーションを一定期間動かし、Access Analyzerにその間のAPI呼び出しを監視させる。

これが終わったら、次は手動で「最後の仕上げ」を行う。

—

ステップ2：JSONポリシーを「殺す」ための厳密な記述法

よくあるダメな例は Action: s3:* と Resource: * だ。これを以下のように書き換えるのが「セキュアな設計」の第一歩だ。

悪い例（攻撃者に喜ばれるポリシー）

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

良い例（業務に必要な最小範囲に絞る）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SpecificS3Access",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-secure-bucket/uploads/*"
      ]
    }
  ]
}

※ポイント：Resource にバケット名とパス（/*）を明記すること。これにより、攻撃者が他のバケット（例：prod-backup-bucket）へアクセスしようとしても AccessDenied で弾くことができる。

—

実務上のTips：IAMポリシーの管理とコード化

手作業でJSONをいじるのは事故の元だ。必ず Terraform や CDK でコード化し、CI/CDパイプラインを通すべきだ。以下は、S3バケットへの書き込み権限だけを付与する際の Terraform サンプルだ。

# セキュアなIAMポリシーの実装サンプル
resource "aws_iam_policy" "app_s3_policy" {
  name        = "AppS3WriteOnlyPolicy"
  description = "アップロード用バケットへの書き込みのみを許可"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action   = ["s3:PutObject"]
        Effect   = "Allow"
        Resource = "arn:aws:s3:::my-app-uploads/*"
      }
    ]
  })
}

—

現場のチーフからのアドバイス

「権限を絞りすぎてアプリが動かなくなった」というトラブルは、インフラエンジニアにとっては勲章のようなものだ。逆に言えば、エラーログを見て「ああ、この権限が足りないんだな」と理解してポリシーを調整するプロセスこそが、セキュリティの「堅牢化」そのものなんだ。

今日からやるべきこと：
1. 自分の管理下にあるIAMロールのうち、AdministratorAccess がついているものを1つ探し、今週中に ReadOnly または PowerUser レベルまで引き下げる計画を立てる。
2. IAM Access Analyzer を全リージョンで有効化する。

セキュリティは「魔法のツール」を入れることではなく、こうした「泥臭い引き算の作業」の積み重ねでしかない。君の書くコードが、悪意ある者にとって「攻め入る隙のない要塞」であることを祈っている。

何か行き詰まったら、いつでも相談してくれ。現場からは以上だ。