【実務・中級編】 IAMにおける最小権限の原則(PoLP)の実装と管理 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

おい、ちょっと手を止めてくれ。インシデント対応の現場にいると、攻撃者がどこから侵入し、どうやって権限昇格（Privilege Escalation）を果たすのか、その手口が生々しく見えてくる。

よくある悲劇がこれだ。「開発スピードを優先したいから」「とりあえず動くようにしたいから」という理由で、AWSのIAMポリシーやAzureのRBACで AdministratorAccess や *（ワイルドカード）をベタッと付与してしまう設計。
攻撃者は、アプリケーションのわずかな脆弱性（例えば、不完全なSSRFや依存ライブラリのRCE）を突いてインフラの足がかりを掴んだ後、その「野良権限（過剰に付与されたIAMロール）」を悪用して、一瞬でクラウド環境全体のマスターキーを奪い去る。暗号理論がどれほど堅牢でも、鍵を管理する「門番（IAM）」がザルであれば、金庫の扉は開きっぱなしなのと同じだ。

今回は、現場のエンジニアが明日から即座に実践できる、IAMにおける最小権限の原則（PoLP: Principle of Least Privilege）の徹底と、IAM Access Analyzerを活用した権限最適化の泥臭い実践ノウハウを叩き込む。綺麗ごとは抜きだ。実戦で生き残るための設定を見ていこう。

—

1. なぜ「ワイルドカード」は悪魔の囁きなのか？（攻撃者の視点）

クラウド環境における最大のセキュリティリスクは、コードのバグそのものではなく、「そのコードが実行されている文脈（コンテキスト）が持つ権限の大きさ」だ。

例えば、S3のバケットから特定の一時ファイルを読み込むだけのLambda関数に、以下のような「お祈りポリシー」がアタッチされているケースを想像してほしい。

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

もし、このLambdaが依存するWeb APIに脆弱性があり、リモートコード実行（RCE）を許したとする。攻撃者は環境変数からAWSのセッショントークンを窃盗し、手元のCLIから aws s3api delete-bucket を叩いたり、全顧客のPII（個人識別情報）が詰まったRDSスナップショットを外部に公開設定に変更したりすることが可能になる。

「最小権限の原則」とは、「業務を遂行するために必要な最小限のアクションと、最小限のリソース（ARN）へのアクセスだけを許可し、それ以外をすべてデフォルトで拒否する」という、セキュリティの鉄則だ。

—

2. 実践：セキュアなIAMポリシーの設計と実装

では、実務でどう書くべきか。
「特定のS3バケット内の、特定のプレフィックス（フォルダ）配下にあるオブジェクトの読み込み（GetObject）のみを許可する」セキュアなIAMポリシーのJSONサンプルを見てほしい。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSpecificS3FolderOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::my-company-secure-data-bucket/app-uploads/*"
    },
    {
      "Sid": "DenyOtherActions",
      "Effect": "Deny",
      "Action": [
        "s3:Delete*",
        "s3:Put*"
      ],
      "Resource": "arn:aws:s3:::my-company-secure-data-bucket/app-uploads/*"
    }
  ]
}

ポイント

1. アクションの限定: s3:* のような雑な指定を避け、必要最小限の s3:GetObject のみに絞っている。
2. リソースの特定（ARN指定）: グローバルな * ではなく、特定のバケットとパス（app-uploads/*）に限定している。
3. 明示的な拒否（Explicit Deny）: Deny を明示的に挟むことで、万が一他のポリシーで広範な権限が混ざったとしても、このルールが優先的に安全を担保する。

—

3. IAM Access Analyzerを用いた権限最適化の自動化プロセス

手動で全リソースのポリシーを監査するのは、人間の認知限界を超えている。ここで頼るべきなのが AWS IAM Access Analyzer だ。

Access Analyzerは、外部のプリンシパル（別のアカウントや匿名ユーザー）に対して、自社のリソースがどのように共有されているかを「論理推論（ZetaVerifiable Security等に類似した数学的モデル）」を用いて解析し、意図しない公開を検知してくれる。

実務では、単にコンソールを眺めるだけでなく、AWS CLIやInfrastructure as Code（Terraformなど）を組み込んで、CI/CDパイプラインの一部として組み込むのがプロのやり方だ。

権限の萎縮（Privilege Shrinking）を自動化するスクリプト（Python）

現場で私がよく使う、CloudTrailのログやIAMの「直近で使用されたサービス（Last Accessed）」のデータを元に、使われていない過剰な権限を洗い出すためのPythonスクリプトの骨子だ。Boto3を使って、監査を自動化する。

import boto3
from botocore.exceptions import ClientError

def analyze_unused_iam_permissions(role_name):
    """
    指定されたIAMロールのアクセス実績を検証し、
    長期間使用されていないアクションをログ出力する実用スクリプト
    """
    client = boto3.client('iam')
    
    try:
        # ロールに紐づくポリシーの最終アクセス情報を取得
        # ※実際のプロダクションでは generate_service_last_accessed_details を非同期で実行する
        response = client.get_role(RoleName=role_name)
        print(f"[*] 監査対象ロール: {response['Role']['RoleName']}")
        print(f"[*] 作成日時: {response['Role']['CreateDate']}")
        
        # ここにCloudTrailやAccess Analyzerの評価結果を突合するロジックを組み込む
        # 例: 90日間一度も呼ばれていないAPIアクションを検知してリスト化
        
        print("[+] 権限の最適化チェックが完了しました。不要な権限は削除を検討してください。")
        
    except ClientError as e:
        print(f"[-] エラーが発生しました: {e.response['Error']['Message']}")

if __name__ == "__main__":
    # 実際の運用では、全ロールをループさせてスキャンするバッチに組み込む
    target_role = "my-production-app-role"
    analyze_unused_iam_permissions(target_role)

このスクリプトを定期実行（AWS EventBridge + Lambdaなど）させ、使われていない権限（Dead Permissions）をあぶり出す。そして、人間がレビューした上で、ポリシーをそぎ落していく。これが「権限の最小化」を維持し続ける唯一の現実的なアプローチだ。

—

4. セキュリティチーフからの現場の教訓

「動くものを作る」のはジュニアエンジニアの仕事だ。「安全に、かつ壊れにくく動くものを作る」のが、シニアでありプロフェッショナルである我々の仕事だ。

IAMポリシーやRBACの設定を適当に済ませることは、自宅の玄関の鍵を開けっぱなしにして出かけるようなものだ。どれほど強固なAES暗号でデータを守ってい出ところで、鍵束そのものを泥棒に渡してしまっては意味がない。

明日から君のプロジェクトでやるべきことは一つだ。
1. 現在動いているアプリケーションのIAMロール／サービスアカウントを洗い出す。
2. ワイルドカード（*）が使われている箇所をすべて特定する。
3. IAM Access Analyzerを有効化し、外部公開リスクのあるポリシーを即座に修正する。

手を動かそう。セキュリティは、祈りではなく「実装」で守るものだ。