Amazon IAMポリシーの最小権限抽出アプローチを模索する

2025.3.13

こんにちは、NRIデジタルの島です。

AWSを利用したシステムを構築していく中で、お客さまのセキュリティポリシーなどにより、各AWSサービスに対する一連のオペレーションで利用するIAMポリシーを「必要最小限の権限」で払い出すことが求められるシーンがあります。筆者はこれまで手探りで実施していたのですが、大枠での抽出（例えばサービス名：Get*など）になってしまうことが多く、結果過剰権限になってしまう傾向がありました。そこで、一連の処理やオペレーションが実行されている運用稼働中や構築中の環境にて、「実利用ベースで効率的に最小権限を抽出できないか」を確認してみました。AWS CloudTrail（以下CloudTrail）やIAMアクセスアナライザーでの検証を踏まえ、これらを活用した「自動IAMポリシー生成」機能にて、ある程度の効率化ができましたので、本記事ではこの軌跡についてご紹介します。

抽出方法のアプローチ

「必要最小限の権限を抽出する」という要件を考えると、CloudTrailにアクセスされたAPI操作のログが出力されるので、それを参照して愚直に整理する方法がまず思いつくところかと思います。ただし、1件1件これらのログをポリシーに落としていくのはかなり骨の折れる作業です。ツール化して取り込む方法も考えられますが、CloudTrailの仕様をしっかりと理解しなければならず、また今後のアップデートにも追従していく必要があり、こちらも結構大変です。

そのため、別のアプローチとして、以下「 IAMアクセスアナライザー」が使用できないかを検討してみました。
新しい IAM アクセスアドバイザー API を使用した AWS IAM アクセス権限分析の自動化

IAMアクセスアナライザー

「IAMアクセスアナライザー」について調べようとすると、似たようなサービスとして「IAMアクセスアドバイザー」というものが出てきます。
最終アクセス情報を使用して AWS のアクセス許可を調整する – AWS Identity and Access Management
IAMアクセスアドバイザーは、「IAMユーザーやロールに割り当てられたアクセス許可の使用状況」」を確認することができるサービスで、AWS管理コンソール上からは、「IAM」ページの「最終アクセス日時」にて確認可能です。

AWS CLIやSDKからも利用することが可能で、以下のAPIを使用して情報を取得することになります。

iam:GenerateServiceLastAccessedDetails

iam:GetServiceLastAccessedDetails

iam:GetServiceLastAccessedDetailsWithEntities

iam:ListPoliciesGrantingServiceAccess

ただ、IAMアクセスアドバイザーは、各サービスへの「最終アクセス日時」と「アクセスを許可させているポリシー」を抽出するものであり、あくまでサービスレベルでアクセスしてるしてないが可視化されるのみのため、今回の「ある一連のオペレーションをするために必要な最小の権限」を抽出したい場合には利用できないと思います。上記でAWS Elastic Load Balancing（以下ELB）を例に取ると、「ELBへのアクセスは「2日前」にされており、それは付与されてる「AdministratorAccess」ポリシーによってアクセスが許可されている」とわかるのみです。例えば、「DescribeRules」権限などの参照権限で十分という情報は取得することは難しいです。

一方、IAMアクセスアナライザーは、意図しないアクセス許可のリスクを検出するためのサービスです。
AWS Identity and Access Management Access Analyzer の使用 – AWS Identity and Access Management
上記公式ドキュメントによると、以下の機能が具備されているようです。

IAM Access Analyzer の外部アクセスアナライザーは、外部エンティティと共有されている組織およびアカウントのリソースを特定するのに役立ちます。
IAM Access Analyzer の未使用のアクセスアナライザーは、組織およびアカウント内の使用されていないアクセス権限を特定するのに役立ちます。
IAM Access Analyzer は、ポリシーの文法および AWS ベストプラクティスに照らして IAM ポリシーを検証します。
IAM Access Analyzer のカスタムポリシーチェックは、指定したセキュリティ基準に照らして IAM ポリシーを検証するのに役立ちます。
IAM Access Analyzer は、AWS CloudTrail ログでのアクセスアクティビティに基づいた IAM ポリシーを生成します。

筆者の現在参画しているプロジェクトでは、AWS環境構築に「AWS Cloud Development Kit（以下CDK）」を使用しています。そこで、「CDKで環境構築する際の最小権限の抽出」をユースケースとしてIAMアクセスアナライザーを試してみようと思います。IAMアクセスアナライザーには、外部からのアクセスを分析する「外部アクセス（上記機能の1点目）」と、使用されてないアクセス権限を特定する「未使用のアクセス（上記機能の2点目）」の2つのアナライザーを定義できます。今回の最小権限抽出の要件を満たせそうな「外部アクセス」を試してみようと思います。

アナライザー（外部アクセス）を作成

上記のようにアナライザーを作成後、各種CDK操作を実行してみます。

cdk bootstrap
cdk ls
cdk synth
cdk diff ・・・
cdk deploy ・・・
cdk destroy ・・・

しかしながら、一向に情報が表示されません。

どうやら、IAMアクセスアナライザーの「外部アクセス」は IAM ロールや S3 バケットなどのリソースポリシーを分析して「別のアカウントに共有されているリソースを検出」する目的で使用するようで、今回のようなIAM ユーザーに必要な権限を確認する目的では使用できなそうです。

AWS Identity and Access Management Access Analyzer の使用
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/what-is-access-analyzer.html#what-is-access-analyzer-resource-identification

(抜粋)
=========
IAM Access Analyzerの外部アクセスアナライザーは、外部エンティティと共有されている組織およびアカウントのリソースを特定するのに役立ちます。
=========

自動IAMポリシー生成

IAMアクセスアナライザー単体では上記の通り要件をかなえられませんでしたが、もう少し深堀してみようと思います。前述したIAMアクセスアナライザーの機能一覧の最後に以下の記述があります。

（再掲）

IAM Access Analyzerは、AWS CloudTrail ログでのアクセスアクティビティに基づいた IAM ポリシーを生成します。

これはIAMアクセスアナライザーとCloudTrailのタッグでIAMポリシーを自動的に生成してくれるもので、公式にも以下ページがありました。
IAM Access Analyzer ポリシーの生成 – AWS Identity and Access Management

本機能が要件にマッチしており使用できそうですので、実際に以下の手順で試してみたいと思います。

実行するIAMユーザーに一旦フル権限を付与し、CDK操作（cdk deployやdestroyなど）実行
実行後、その時間帯を指定し、自動ポリシー生成を実行
②で生成された権限のみのポリシーを付与したIAMユーザーにて再度CDK操作を実行し、問題なく完了することを確認

本記事ではIAMユーザーの場合で解説しておりますが、「AWS CodeBuild」などで実行されるIAMロールにおいても同様のアプローチになります。

では、順に実行していきます。

1.フル権限IAMユーザーにてCDK実行

「AdministratorAccess」ポリシーを付与したIAMユーザーにて、再び以下各種CDKコマンドを実行し、すべて正常終了させます。

cdk bootstrap
cdk ls
cdk synth
cdk diff ・・・
cdk deploy ・・・
cdk destroy ・・・

2.IAMユーザーページより「ポリシーを生成」を実行

実行後、実行した時間帯を指定して該当のIAMユーザーページより「ポリシーを生成」を実行する。

数分待って「成功」になれば完了です。

生成されたポリシーです。いい感じに生成されていそうです。

追加などある場合は、ここで調整できます。

生成されたJSONは以下のようになります。ワイルドカード（*）の記述はなく具体的に必要な権限がピックアップされていそうです。

Resourceは変数化（リージョンなど）されているため、そのままだとエラーとなりますので、置き換えが必要となります。

本ポリシー生成機能は、同一アカウント内で並列で複数同時実行できませんので注意してください。

※以前は「一日の実行回数」に制限があったようですが、今はその制限はなさそうです

3.生成された権限のみのポリシーを付与したIAMユーザーにて再度CDK操作を実行

さて、ポリシーが生成されたので、そのポリシーを別のIAMユーザーに付与して再度CDK操作を実行してみます。期待値はエラーなしで正常終了することです。
以下結果です。

>cdk diff ${DEPLOYED_ENV}SqsEnv
・・・
Lookup role arn:aws:iam::XXXXXXXXXX:role/cdk-hnb659fds-lookup-role-XXXXXXXXXX-ap-northeast-1 was not assumed. Proceeding with default credentials.
User: arn:aws:iam::XXXXXXXXXX:user/temp-cdk-user is not authorized to perform: cloudformation:GetTemplate on resource: arn:aws:cloudformation:ap-northeast-1:XXXXXXXXXX:stack/dev01SqsEnv/ae17ad70-e379-11ef-ac1e-0e17bc43fb77 because no identity-based policy allows the cloudformation:GetTemplate action

残念ながら、権限不足のエラーとなり失敗となりました。

本機能で全ての必要な権限かつ最小の権限が生成されることを期待したのですが、どうやらCloudTrailでのポリシー生成には以下の制限があり、100%満たすことはできなそうです。以下公式ページに記載の通り、S3データイベントや、CloudTrailによって追跡されないアクションは生成されたポリシーに含まれないとのことです。

IAM Access Analyzer ポリシーの生成
IAM Access Analyzer ポリシーの生成 – AWS Identity and Access Management

(一部抜粋)
=========
・データイベントを使用できません — IAM Access Analyzer は、生成されたポリシーで、Amazon S3 データイベントなどのデータイベントのアクションレベルのアクティビティを識別しません。
・PassRole – iam:PassRole アクションは CloudTrail によって追跡されず、生成されたポリシーには含まれません。
=========

Cloud Trailで追跡アクションを増やすには、以下ページにあるようにデータイベントを追加する方法がありますが、それでもすべてを満たすことは難しいです。
データイベントをログ記録する – AWS CloudTrail

現状のアプローチ考察

結果、現時点では本件の要件（使用したもののみ許可する）を満たすためには以下のように、作成されたポリシーをベースにトライアンドエラーで対応していくアプローチが最短と筆者は考えております。

実行するIAMユーザーに一旦フル権限を付与し、CDK操作（cdk deployやdestroyなど）実行
実行後、その時間帯を指定し、自動ポリシー生成を実行
②で抽出した権限のみ付与したIAMユーザーにて再度CDK操作を実行
発生したエラーをもとに不足の権限を追加
③-④を繰り返し、問題なく完了することを確認

力技な感じもしますが、②まで完了時点で多くの最小権限をカバーできるので、1から整理するよりは効率的に作業していけると思います。③-④手順の繰り返しは筆者のCDK実行においては数回の繰り返しのみで正常化することができました。

さいごに

本記事を執筆するにあたり、当初は機械的なアプローチでスムーズに最小権限が抽出できることを期待しておりましたが、少なくとも「CDK実行における必要最小権限整理」というユースケースにおいてはそのような方法はありませんでした。しかしながら、完璧ではないまでも実利用ベースで多くの権限を自動生成でき、不足分は差分を調整していくような本記事でのアプローチにてだいぶ効率的になるのではないでしょうか。また、不足はあれど過剰権限を防止できるという意味でもメリットがあると思います。
本記事でご紹介したアプローチや考え方は、CDK以外のユースケースにおいても有効と考えておりますので、同じようにポリシーや権限の適正化を考えている方々の一助になれば幸いです。