3つのアーキテクチャで試す、IAM Policy Autopilot

Transcript

1. 3 つのアーキテクチャで試す、 IAM Policy Autopilot JAWS-UG 横浜 #93 AWS re:Invent 2025 re:Cap AI 2025/12/27 Shota Kawasaki
2. 出身: 千葉県 所属: SIer 年次: 1 年目（今回2 回目の登壇です！） 好きなサービス: CloudFront, Kiro : @kawaaaas Shota Kawasaki
3. re:Invent では多くの新サービスが公開されましたね！ https://www.youtube.com/watch?v=gji8oATVGUI&list=LL&index=3
4. https://github.com/awslabs/iam-policy-autopilot ※ ステータスは2025/12/24 時点
5. IAM Policy Autopilot とは？ AI コーディングアシスタントがIAM アイデンティティベース のポリシーを生成するのを支援するためのツール Python 、Go 、TypeScript をサポートしておりソースコードを 解析して必要なIAM ポリシーを自動生成する Kiro やClaude Code 、Cursor などのAI エージェントと統合し MCP サーバーとして利用できる他、CLI ツールとしても利用 可能 → ソースコードを解析して必要なIAM ポリシーを自動 生成してくれるツール
6. 素早さ IAM Policy Autopilot の特徴3 点 IAM ポリシーの検討にかける時間を 短縮し、開発を加速する 信頼性 コード分析により動作可能なポリシー を生成する 最新性 生成されたポリシーに、AWS の 最新サービスの情報が反映されている
7. Kiro を使用してMCP サーバーとして 3 つの環境で実際に生成してみる！ A Lambda + S3 B SQS + Lambda + DynamoDB C Lambda + Bedrock + S3 + KMS + Secret Manager
8. 環境A では、Lambda がS3 のテキストファイルを 読み取るシンプルなアーキテクチャを採用
9. 環境A で実際に生成されたポリシー 今回のアプリケーションには 不必要な権限も一部含まれている ソースコードからの取得できない情報 に関して、ワイルドカード指定となる
10. 環境B ではSQS からのメッセージをLambda が受け取り、 DynamoDB に格納するアーキテクチャを採用
11. 環境B で実際に生成されたポリシー Lambda ソース内でSQS のSDK を呼 ばないため、SQS の権限はつかない
12. 環境C では以下のアーキテクチャを採用 1.Secret Manager から仮想のWebhook URL を取得 2. 用意したプロンプトでBedrock を実行 3. 応答結果をS3 （KMS による暗号化）に保存 4.EventBridge にイベントを送信
13. 環境C で実際に生成されたポリシー① ソースコードからの取得できない情報 に関して、ワイルドカード指定となる 今回のアプリケーションには 不必要な権限も一部含まれている
14. 環境C で実際に生成されたポリシー② 呼び出すサービスが多いが、 漏れなく動作する権限が生成できている
15. 触ってみた所感 動作するIAM ポリシーを素早く生成できるのはとても便利 今回の検証で生成させたIAM ポリシーにおいて、呼び出すサービス数 が多くても権限周りのエラーは出ずに1 発で動作した アプリケーションを素早く実装する点においては有用 生成されるポリシーは最小権限ではない点には注意 あくまでも、安全に動作する可能性が高い権限セット 今回はKiro にて、Claude Opus 4.5 を使用したが、十分賢くかつIaC で 実装する際は実行環境のコンテキストを持つため、むしろ生成された ポリシーから不要な権限を積極的に削減しようとしていた AI エージェントの実装補助としての利用や、人目でのレビューが必要
16. 皆さんもIAM ポリシー生成に困ったときは IAM Policy Autopilot を！