0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@CEC_Cloud_Communityin株式会社シーイーシー

IAM Policy Autopilotの実践的な使い方（設計・実行・AI連携）

0
Posted at

はじめに

こんにちは。株式会社シーイーシーのAWSコミュニティチームです。
今回は、IAMポリシーの設計やAccessDeniedの調査に役立つツール「IAM Policy Autopilot」の実践的な使い方をご紹介します。
IAMポリシーの設計やAccessDeniedの調査に、何時間も費やした経験はありませんか。

  • どのActionが足りないのか分からない
  • ResourceのARNを毎回調べている
  • 結局AdministratorAccessを付けてしまう

IAM Policy Autopilotは、コードやエラー、AIを起点に、IAMポリシーを考える作業から解放してくれるツールです。「提案ツール」であり、生成されたポリシーをそのまま本番環境に適用するのではなく、内容を理解した上で必要な権限のみを採用することが推奨されています。
本記事では、IAM Policy Autopilotの使い方を3つに整理します。

この記事で扱うこと

  • IAM Policy Autopilotの3つの使い方
  • それぞれ「何ができるのか」
  • どんな場面で使うべきか
  • 実務での注意点

この記事を読む前に

IAM Policy Autopilotを使う前に、以下の点を確認してください。

対象読者

  • AWSのIAMポリシーの基本（Action/Resource/Effect）を理解している方
  • boto3またはAWS SDKを使ったコードを書いたことがある方
  • Lambda・ECSなどのサービスにIAMロールを付与した経験がある方

IAM Policy Autopilotはあくまで「提案ツール」です。

本ツールが生成するポリシーは、静的解析をもとにした提案であり、そのまま本番環境へ適用することは推奨しません。
生成されたポリシーの内容を理解した上で、必要な権限のみを採用してください。

本番環境への適用には必ずIAM Access Analyzerなどでのレビューをはさんでください。

IAM Policy Autopilotの3つの使い方

① コードからIAMポリシーを生成する

目的

実装前や実装直後に「このコードに必要な最小権限のIAMポリシー」を作成するため。

使うコマンド

test_app.pyは実際のパスを指定してください。

iam-policy-autopilot generate-policies test_app.py \
  --region ap-northeast-1 \
  --account 123456789012 \
  --pretty

各オプションの意味

オプション 説明
--region ap-northeast-1 IAMポリシー内のARNに含まれるリージョンを指定
--account 123456789012 IAMポリシーに埋め込まれるAWSアカウントID。本番環境では実際のアカウントIDを指定すること（123456789012はダミー値）
--pretty JSONを人が読みやすい形に整形する。権限内容自体は変わらない（表示のみ）
--service-hints <SERVICES> 分析対象を指定サービスに限定する。不要な権限を削減できる
--upload-policies <PREFIX> 生成されたポリシーを指定プレフィックスでAWS IAMにアップロードする。自動適用前に必ず内容を確認すること

できること

  • boto3・AWS SDKの呼び出しを静的解析する
  • 使用しているAWS APIからActionを抽出する
  • 最小権限のIAMポリシーを生成する

ポイント

  • AWSへは一切アクセスしない（静的解析のみ）
  • CI/CDパイプラインでも安全に実行可能
  • 生成結果はあくまで「出発点」であり、そのまま本番環境へ適用しないこと

② AccessDeniedエラーをもとにIAMポリシーを修正する（運用フェーズ）

目的

実行時に発生したAccessDeniedの原因を解明して迅速に修正し、手作業でのエラーメッセージの解析を不要にするため。

使うコマンド

iam-policy-autopilot fix-access-denied \
"User: arn:aws:iam::123456789012:role/test-role is not authorized to perform: s3:GetObject on resource: arn:aws:s3:::example-bucket/input/data.json because no identity-based policy allows the s3:GetObject action"

出力例

IAM Policy Autopilot Plan
Principal: arn:aws:iam::123456789012:role/test-role
Action: s3:GetObject
Resource: arn:aws:s3:::example-bucket/*
Denial: ImplicitIdentity

Proposed permissions:
  - s3:GetObject

できること

  • AccessDeniedメッセージを構造化する
  • Action・Resource・Principalを抽出する
  • 追加すべきIAM権限を提案する

補足：AccessDeniedの2種類について

  • ImplicitDeny（暗黙的な拒否）：許可ポリシーが存在しないために拒否される
  • ExplicitDeny（明示的な拒否）：SCP（Service Control Policy）やリソースベースポリシーで明示的にDenyされている

IAM Policy Autopilotの出力にある"Denial: ImplicitIdentity"はImplicitDenyに相当します。
ExplicitDenyの場合は、単に権限を追加しても解決しないため、SCP・バケットポリシー・権限境界（Permissions Boundary）も合わせて確認してください。

③ MCPサーバーでAI・IDEと連携する（AI利用時）

目的

AIによる誤った権限設計を減らしつつ、人による確認負担を軽減する運用を目指すため。

IAM Policy AutopilotはMCP（Model Context Protocol）に対応しています。
MCPサーバー連携とは、AI（特に生成AI）が外部のシステムやデータと安全・共通ルールでつながるための仕組みのことです。

AIがコード生成時にMCPサーバーへアクセスし、IAM Policy AutopilotをIAM専用の知識源として利用します。

これにより、以下の流れが可能になります。

  1. AI（Claude・Copilot・Amazon Qなど）がコードを生成
  2. 必要なAWS権限を推測
  3. IAM Policy Autopilotを内部的に呼び出し
  4. 正しいIAMポリシー案を自動生成

注意点

  • AIが生成したIAMポリシーも、そのまま適用せず必ずレビューすること
  • MCP連携時もAWSへの実際のアクセスは発生しない（静的解析）

AmazonQ Developerでの使用例

設定例
~/.aws/amazonq/mcp.json に以下を追記します

{
  "mcpServers": {
    "iam-policy-autopilot": {
      "command": "uvx",
      "args": ["iam-policy-autopilot", "mcp-server"]
    }
  }
}

設定後は、IDEのチャットで以下のように依頼するだけです。

このapp.pyに必要な最小IAMポリシーを生成してください

AmazonQ Developer は、MCPサーバー経由でIAM Policy Autopilotを呼び出し、コードを静的解析した上でポリシー案を返します。

実際に使ってみる：コードからIAMポリシー生成

前提条件

以下の前提で検証します。

  • AWS Lambda上で動作する
  • S3バケットからJSONファイルを取得する処理
  • S3バケットの暗号化設定はSSE-S3（AWSマネージドキー）

テストコード例

app.py
import boto3

def handler():
    s3 = boto3.client("s3")
    response = s3.get_object(
        Bucket="example-bucket",
        Key="input/data.json"
    )
    body = response["Body"].read()
    print(body)

if __name__ == "__main__":
    handler()

通常出力（service-hintsなし）

iam-policy-autopilot generate-policies app.py \
  --region ap-northeast-1 \
  --account 123456789012 \
  --pretty

出力例

{
  "Policies": [
    {
      "Policy": {
        "Id": "IamPolicyAutopilot",
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "kms:Decrypt"
            ],
            "Resource": [
              "arn:aws:kms:ap-northeast-1:123456789012:key/*"
            ],
            "Condition": {
              "StringEquals": {
                "kms:ViaService": [
                  "s3.ap-northeast-1.amazonaws.com"
                ]
              }
            }
          },
          {
            "Effect": "Allow",
            "Action": [
              "s3:GetObject",
              "s3:GetObjectLegalHold",
              "s3:GetObjectRetention",
              "s3:GetObjectTagging",
              "s3:GetObjectVersion"
            ],
            "Resource": [
              "arn:aws:s3:::*/*",
              "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/*/object/*"
            ]
          },
          {
            "Effect": "Allow",
            "Action": [
              "s3-object-lambda:GetObject"
            ],
            "Resource": [
              "arn:aws:s3:::*/*",
              "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/*/object/*"
            ]
          }
        ]
      },
      "PolicyType": "Identity"
    }
  ]
}

実際に生成して分かったこと

実際に生成されたポリシーは上記のとおりですが、やや包括的な内容になりやすいことが分かりました。
例えば、単純なs3:GetObjectのみを使うコードに対して、kms:Decryptやs3:GetObjectLegalHoldなど実際には不要な権限まで含まれていました。
また、Resourceの指定も"arn:aws:s3:::/"と広い範囲になりやすく、そのまま本番環境へ適用するのは適切ではありません。

各権限が含まれる理由と今回の前提での要否

  • kms:Decrypt：SSE-KMS暗号化の場合に必要。今回はSSE-S3のため「不要」
  • s3:GetObjectLegalHold/Retention/Tagging/Version：Object Lock・バージョニング・タグを使わない場合は「不要」
  • s3-object-lambda:GetObject：S3 Object Lambdaを使わない場合は「不要」

Resourceが"arn:aws:s3:::/"と広い理由

静的解析では実行時のバケット名を特定できないため、ワイルドカードになっています。
実際のバケット名が確定している場合は、以下のように絞り込むことを強く推奨します。

前提条件に合わせ、手動で調整したポリシーがこちらです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/input/data.json"
        }
    ]
}

このように、生成されたポリシーはあくまで叩き台であり、前提条件に合わせた手動精査と、実際に動かした際の対応を含めたフローで運用することが重要です。

実務での正しい使い方

IAM Policy Autopilotは以下のフローで活用することで、最小権限のIAMポリシーを効率的に作成できます。

①叩き台生成

generate-policiesでコードを静的解析し、ポリシーの叩き台を生成します。この時点では過剰な権限が含まれる場合があります。

②動かす前に手動精査

生成されたポリシーを手動で確認して不要なActionを削除し、Resourceを具体的なARNに絞り込みます。kms:DecryptやGetObjectLegalHoldなど前提条件に合わないものを削除し、バケット名が確定している場合はResourceもさらに絞り込みます。

③実際に動かす

実装したコードを実行します。正常に動作した場合は⑤へ、AccessDeniedが出た場合は④へ戻ります。

④エラー対応

fix-access-deniedでAccessDeniedのエラーメッセージを解析し、不足している権限を特定して追加します。追加後は③に戻って再実行します。

⑤最終精査

IAM Access Analyzer（未使用アクセス分析）で実際に使われなかった権限を検出し、不要な権限を手動で削除します。一定期間運用後に実施します。

まとめ

IAM Policy Autopilotは、IAMを自動化するツールではなく、IAMで無駄な時間を費やさないための出発点を作るツールです。

  • 生成結果はそのまま採用しない。各権限の意味を理解した上で取捨選択する
  • Resourceは可能な限り具体的なARNに絞り込む
  • IAM Access Analyzerでポリシーを検証し、過剰な権限を削除する
  • AIと組み合わせることで、IAM設計の手間をさらに削減できる

IAMの設計に時間がかかっていると感じたら、まずAutopilotを試してみてください。

参考

※本記事は2026年5月時点の情報に基づいて執筆しています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?