Go to Qiita Advent Calendar Top
LoginSignup
1
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?

@yosimitu

【AWS re:Invent 2025】IAM Policy AutopilotとIAM Access Analyzerでつくる段階的権限最小化

Posted at

はじめに

みなさん、こんにちは。
今年の re:Invent 2025 はいろんな意味で衝撃が多かったのではないでしょうか。特にワーナーのキーノートプレゼンが最後だという発表は、本当に残念すぎます。ワーナーのラストステージを現地で見ることができたのは、本当に運が良かったです。

今回の、re:Invent 2025 全体を通して、「AIエージェント」を軸に、ビルダー体験をどう変えていくか、というメッセージが強く打ち出されていたと感じました。特にフロンティアエージェントのように"自律的にタスクを進めてくれるエージェント"を中心に開発や運用のあり方をアップデートする流れがあったように思います。

こうしたエージェントが自律的に動けば動くほど、現実には次のような壁にぶつかります。

  • その変更を実行するための IAM 権限をどう安全に用意するか
  • 権限が足りずに AccessDenied を踏んだとき、どう素早く原因特定・修正するか
  • 権限を広げすぎた場合、どう運用で削って最小権限へ寄せるか

そこで登場したのが、IAM Policy Autopilotです。

IAM Policy Autopilot は、

「アプリケーションコードから IAM ポリシーを自動生成するオープンソースの MCP サーバー兼 CLI ツール」

です。アプリケーション内の AWS SDK 呼び出しを静的解析し、AWS の公開リファレンスをもとに IAM アクションへ再現性をもってマッピングしてくれます。

(補足) IAM ポリシーの作成が難しい理由

Well-Architected Framework の考え方においては「最小権限(に近いポリシー)」を実現することが推奨されていますが、実際には、

  • 最小権限に近づけること
  • 開発サイクルに間に合うスピードでポリシーを用意すること

の両方を満たすのははっきり言って難しいです。それゆえ次のような形で IAM ポリシーの作成について対処されているのではないでしょうか。心当たりありませんか？

  • とりあえず AdministratorAccess を付けて動かす
  • 既存のプロジェクトを参考にそれっぽい権限を作成する
  • セキュリティレビュー等で指摘されて AWS 管理ポリシーに差し替えるが、権限が足りずに AccessDenied を踏む
  • CloudTrail のイベント履歴を見ながら手作業でポリシーを直す
  • LLM にポリシー生成を依頼し、出力された JSON をベースに手で調整する

この記事では、従来の IAM ポリシー作成パターンの悩みを整理しつつ、IAM Policy Autopilot がどこまで解決策になりうるのか、どのような前提や制約があるのか、さらに一歩ふみこんで IAM Access Analyzer との関係性についてもまとめていきます。

IAM Policy Autopilotについて

IAM Policy Autopilot(以降、Autopilot) の特徴は次のとおりです。

  • アプリケーションコード（AWS SDK 呼び出し）の静的解析による操作の収集
  • AWS 公開のサービスリファレンスをもとに IAM アクションをマッピング
  • AI コーディングアシスタントから MCP サーバーとして呼び出し可能(CLIも可)
  • AccessDenied の解析と、ポリシー修正案の提示
  • 生成対象はアイデンティティベースポリシーのみ（リソースベースポリシーや SCP などは対象外）

Autopilot の狙いは、直接「最小権限を完成」させる、のではなく、まずは 「動くために必要な権限セット(ベースライン）」を自動で作ることです。本当の意味での最小化はその後での検証・運用フェーズで決定する流れになります。

従来の IAM ポリシー作成パターンと課題

ケース#1 AdministratorAccess で逃げ切る

  • 最速で動く代わりに、ほぼすべての操作を許可してしまう
  • 「あとでちゃんと見直す」はほぼやらない(笑)

検証環境や PoC ならまだしも、本番ロールに残ったままだと事故時ったときの説明ができません。

ケース#2 AWS 管理ポリシーでなんとかする

AmazonS3FullAccess や AmazonDynamoDBFullAccess といった管理ポリシーは、AdministratorAccess よりマシなレベルです。

  • 名前よりも権限が広いことがある
  • 逆に、KMS 周り（kms:PutKeyPolicy など）のように別ポリシーが必要なケースがある

結局最小権限とは言い難い設定と言えるでしょう。

ケース#3 CloudTrail を見ながら手作業でなんとかする

次によくあるケースです。

  1. やや広めのポリシーでデプロイ
  2. CloudTrail のイベント履歴を確認
  3. 実際に使われたアクションを洗い出し
  4. 未使用アクションを削る

このとき、IAM Access Analyzer の「未使用アクセス分析」を使えば多少は楽になりますが、

  • 本番トラフィックが溜まるまで時間がかかる
  • 特定の分岐・例外系のアクセスがなかなか踏まれない
  • ポリシー更新と IaC の差分管理が複雑になる

といった課題は残ります。

ケース#4 生成AIにポリシー生成を依頼する

最近増えているパターンがこれです。

「このコードに必要な IAM ポリシーを JSON で書いて」

というプロンプトで生成AIに生成させるやり方です。ただし、生成AIには次のようなリスクがあります。

  • 存在しないアクション(s3:HeadBucket など)を返す可能性
  • SDK メソッド名と IAM アクション名の対応は適切か
  • 同じプロンプトでも結果が変わる(再現性)

もちろん最終的に人が IAM ポリシーを確認する必要があり、工数がゼロになるわけではありません。

IAM Policy Autopilot のアーキテクチャ

IAM Policy Autopilot は、baseline（たたき台）を作り、レビューして洗練させる形で行います。

処理の流れ

ざっくりとしたフローは次のとおりです。

  1. コード解析

    • 対応言語（執筆時点では3言語のみ）
      • Python
      • Go
      • TypeScript

  2. SDK オペレーションの抽出

    • 例：
      • s3_client.get_object(...)
      • kms_client.generate_data_key(...)
      • table.put_item(...)（DynamoDB）
    • メソッド名とクライアントの型情報から、どのサービスのどのオペレーションかを特定

  3. オペレーション → IAM アクションへのマッピング

    • AWS 公開の「Actions, Resources, and Condition Keys」のデータを内部に持ち、
    • GetObject → s3:GetObject
    • GenerateDataKey → kms:GenerateDataKey
      のようにマッピングする

  4. ポリシー JSON の生成

    • Identity-based policy として Version, Statement を含む JSON を生成
    • Effect, Action, Resource, Condition を組み立てる

ここでのポイントは、同じコードからは常に同じポリシーが生成される(決定論的というようです)という点です。生成AIが持つ「毎回微妙に違う」問題を避けやすくなります。

CLI で使ってみる

インストール

PyPI からインストールできます。

pip install iam-policy-autopilot

あるいは GitHub のインストールスクリプト経由でも導入可能です。

pip で「error: externally-managed-environment」が出る場合は以下を参照してください。
https://zenn.dev/kail/articles/ef502d950e8268

私の環境では以下で実行しました。

% pipx install iam-policy-autopilot
  installed package iam-policy-autopilot 0.1.1, installed using Python 3.14.2
  These apps are now globally available
    - iam-policy-autopilot

今回インストールしたバージョンは以下です。

% iam-policy-autopilot --version 
  iam-policy-autopilot 0.1.1

IAM Policy Autopilotのコマンドは以下があります。

  • fix-access-denied : Fix AccessDenied errors by analyzing and optionally applying IAM policy changes
  • generate-policies : Generates complete IAM policy documents from source files
  • mcp-server : Start MCP server
  • help : Print this message or the help of the given subcommand(s)

ポリシー生成（generate-policies）

では使ってみましょう。S3にあるオブジェクトをローカルにダウンロードするサンプルスクリプトです。

s3download.py
import boto3
s3 = boto3.client('s3')

# バケット名、ダウンロードオブジェクト名、ダウンロードファイル名
S3_BUCKET_NAME = 'sample-bucket'
S3_OBJECT_NAME = 'sample.jpg'
LOCAL_FILE_NAME = '/tmp/sample.jpg'

def lambda_handler(event, context):

    # S3ダウンロード
    s3.download_file(S3_BUCKET_NAME, S3_OBJECT_NAME, LOCAL_FILE_NAME)

    return

実行したコマンドは以下です。

iam-policy-autopilot generate-policies \
    ./s3download.py --region us-east-1 --account 123456789012 --pretty

主なオプション

  • --account
    ポリシー生成時に埋め込む AWS アカウント ID
  • --region
    リージョン（KMS や S3 の ARN 生成に利用）
  • --pretty
    インデント付き JSON で出力

コマンドを実行すると、次のような JSON ファイルが生成されました。

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

念の為、LLMにも作成してもらいましょう。

ChatGPT(5.2 Auto)に以下のプロンプトで作成してもらいました。

以下のスクリプトを実行するうえで、
必要な最小権限を備えたIAMポリシーのJSONファイルを作成してください。

生成された結果は以下です。

chatgpt.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGetSpecificObject",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::sample-bucket/sample.jpg"
    }
  ]
}

Autopilot で生成した内容は以下のとおりです。

  • スコープが圧倒的に広い
  • アクションも結構多め
    • s3:GetObject（必須）
    • s3:GetObjectTagging（タグ取得）
    • s3:GetObjectVersion（バージョン取得）
    • s3:GetObjectRetention / s3:GetObjectLegalHold（Object Lock系）
    • s3-object-lambda:GetObject（Lambda経由のGetObject）
  • KMSがワイルドカードですべてが対象

結論から言えば、「汎用的に何でも読む」ためのポリシーに近く、今回の用途(固定バケット・固定オブジェクトの取得)に対しては過剰権限が生成されているように思います。

AccessDenied 補正について

これ以外にも、Autopilot には AccessDenied が発生したときに、CloudTrail のイベントを入力としてポリシー差分を生成するサブコマンド(fix-access-denied)も提供されています。

  • CloudTrail から対象イベントを JSON で取得
  • Autopilot に渡して、不足アクションだけを含む差分ポリシーを生成
  • 既存ポリシーにマージして再デプロイ

といったループを CI やローカル開発に組み込むイメージです。

MCPサーバーとして AI コーディングアシスタントと連携

IAM Policy Autopilot は MCP サーバーとしても動作することが可能です。Kiro や Claude などの MCP 対応コーディングアシスタントから呼び出すことで、「AI から IAM の細かい仕様を隠蔽する」形で利用することができます。

MCP 連携のイメージ

設定例：

{
  "mcpServers": {
    "iam-policy-autopilot": {
      "command": "uvx",
      "args": ["iam-policy-autopilot", "mcp-server"],
      "env": {
        "AWS_REGION": "ap-northeast-1"
      }
    }
  }
}

この状態で、コーディングアシスタントに対して

src/ 配下のコードを ECS にデプロイする CloudFormation テンプレートを作成し、必要な IAM ロールも含めてください。

と依頼すると、以下のように動作します。

  1. AI がテンプレート生成と IAM 設計が必要だと判断
  2. IAM Policy Autopilot MCP を呼び出してポリシーを生成
  3. 生成ポリシーを CloudFormation / CDK コードに埋め込む

IaC とガバナンスへの組み込み

IAM ポリシーは「一度付けたら剥がれない」ものになりがちです。そこで、実運用を意識して IAM ポリシーをアプリケーションコードと同じ品質ゲートに通すための運用パターンについても考えてみます。

ここはまだ試行錯誤のレベルなので確実に動かせるかどうかはみなさんの環境で試してみてください。

IaC への組み込み例（CDK）

  1. CI で Autopilot を実行し、policies/auto/app.json を生成

  2. CDK で PolicyDocument.fromJson として取り込む

import * as fs from 'fs';
import * as iam from 'aws-cdk-lib/aws-iam';

const raw = JSON.parse(fs.readFileSync('policies/auto/app.json', 'utf-8'));

// Autopilot がラッパー構造で出す場合があるので吸収する
// - { Version, Statement } の形式ならそのまま
// - { Policies: [{ Policy: { Version, Statement } }] } なら剥がす
const docJson = raw.Policies?.[0]?.Policy ?? raw;

const policyDoc = iam.PolicyDocument.fromJson(docJson);

new iam.Role(this, 'AppRole', {
  assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
  inlinePolicies: {
    AppPolicy: policyDoc,
  },
});

3.Pull Request では

  • 生成ポリシーの差分
  • IAM Access Analyzer のポリシー検証結果をセットでレビューする
aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://policies/auto/app.json \
  > policies/auto/app.validate.json

こうしておくと、ポリシーの変更もアプリケーションコードと同じレビューとして実行することができます。

IAM Policy Autopilot と IAM Access Analyzer の補完関係

Autopilot と関連するサービス IAM Access Analyzer についても見ていきましょう。

Autopilot　は、「このコードが動くために必要なアクションの上限である集合ポリシー」を作るのに対して、Access Analyzer は、「実際のポリシーがどのようなリスクや無駄を持っているか」をチェックし、「実際に使われていない権限」検出することが可能です。

比較

観点 IAM Policy Autopilot IAM Access Analyzer
主な入力 アプリケーションコード、AccessDenied ログ IAM ポリシー、CloudTrail イベント、アカウント設定
主な出力 Identity-based policy（JSON） 分析結果(外部アクセス、未使用アクセス、ポリシー検証など)
タイミング 設計・実装時（プレデプロイ） デプロイ前後(検証・運用)
アプローチ 静的解析＋公式リファレンスから「必要権限」を生成 実際のポリシー評価とログに基づき「リスクや過剰な権限」を検出
対象 Identity-based policy Identity-based Policy / Resource-based policy

段階的な最小権限化の流れ

IAM Access Analyzer と組み合わせることで、Autopilot による「必要となりうる権限の上限」と Analyzerによる「過剰権限の削減」によって最小権限を段階的に実現することが可能と考えます。

  1. 設計・実装フェーズ：Autopilot でポリシーの上限を作る

    • コード変更するタイミングで generate-policies を実行
    • 生成されたポリシーを IaC（CDK / CloudFormation / Terraform）に組み込み、PR を作成
    • この時点では「コード起点で見た上限」と考えておく

  2. デプロイ前検証：Access Analyzer でポリシー検証を行う

    • 外部公開（Principal: "*", パブリックアクセス）
    • 意図しないクロスアカウントアクセス
    • サービス推奨に反する書き方(絞れるのに * になっている等)を検出し、PR レビューで修正する

  3. 運用フェーズ：Access Analyzer で未使用アクセスの削減

    • 本番で一定期間運用し、Access Analyzer の未使用アクセス分析を利用
    • 実際に使われていないアクションや条件を削減する PR を出す
    • Statement の Action と Resource を段階的に絞り込んでいく

  4. テスト・障害時：Autopilot の AccessDenied 補正

    • テストや本番で AccessDenied が出た場合、該当イベントを Autopilot に渡して差分ポリシーを生成
    • 必要なアクションだけを追加した小さな差分として取り込む

まとめ

IAM Policy Autopilot は、アプリケーションコードの静的解析と AWS 公式リファレンスを使い、Identity-based policy を生成するオープンソースの MCP サーバー兼 CLI コマンドです。「最小権限に近いポリシーを、開発サイクルに間に合うスピードで用意する」という難題に対して、現実的なスタート地点を自動生成することができる(若干範囲は広めな気がしますが)ツールとして提供されました。

IAM ポリシー作成に費やしている時間を少しでも減らして、アプリケーションの設計やビジネス価値の部分に集中したいチームにとって、IAM Policy Autopilot と IAM Access Analyzer の組み合わせは、一度検証してみる価値はあるのではないかと思います。

参考リンク

1
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
1
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?