はじめに

こんにちは、藤本です。
権限管理において、AWS IAM Access Analyzerは非常に有効な方法です。
これまでに、IAM Access Analyzerの活用方法については、2本の記事を書いてきました。

今回はさらにIAM Access Analyzerについて理解を深めるため、re:Invent 2025のセッション「IAM Access Analyzer Deep Dive: From Configuration to Remediation（SEC-340）」（和名：IAM Access Analyzer Deep Dive：設定から修復まで）を受講してきました。本記事では、セッションで話された内容を整理しながら、IAM権限の設定から修復までのポイントをまとめていきたいと思います。

IAM Access Analyzerの概要

IAM Access Analyzerとは、AWS上のアクセス権限を見える化し、危険な共有設定や過剰な権限を早期に発見するための診断ツールです。

docs.aws.amazon.com

ただIAM Access Analyzerは単なる権限チェックツールではなく、最小権限に到達するための実践的なツールとして位置づけられています。
権限は一度設定して終わりではなく、アプリの機能追加や担当者の入れ替わり、組織構造・運用の変化に合わせて、少しずつ形を変えていきます。つまり、最小権限は固定のゴールではなく、アプリ・人・組織が変わり続ける限り常に揺れ動くターゲットとなります。この権限の変化を前提にIAM Access Analyzerによって継続的な見直しを行います。

IAM Access Analyzerでは、権限のライフサイクルを次の3つのフェーズに分けて考えます。

Set（設定する）：権限を作り、付与する
Verify（検出する）：付与した権限が意図どおりか検証する
Refine（改善する）：権限のズレや不要分を削って絞る

権限のライフサイクルを考えるうえで、このSet→Verify→Refineのサイクルを一度きりで終わらせず、運用に落とし込むことが重要です。

IAM Access Analyzerの自動推論

IAM Access Analyzerの核となるのが自動推論（Automated Reasoning）です。自動推論はAIと同様に高度な数学を扱う点では共通していますが、その考え方はむしろ正反対です。一般にAIは、確率に基づいて「次に何が起こりそうか」「もっともそれらしい答えは何か」を推測します。一方でIAM Access Analyzerの自動推論は決定論的に動きます。これは、AIのように推測ではなく、前提となる条件（ポリシーの記述、条件式、信頼境界など）から論理的に結論を導き、必ず同じ入力から同じ結論が得られる設計となっています。この決定性が、ポリシー評価という領域で非常に有効です。 IAMポリシーは条件分岐や例外の記述が多く、人間が読んでも「結局この条件だとアクセス可能であるか」が直感で判断しづらい場合があります。自動推論では、数学的証明のアプローチを使って、アクセスが成立するかどうかを明確に判定します。そのため、IAM Access Analyzerによって検出される外部公開やクロスアカウントアクセス、内部アクセス経路の洗い出しといった、判断を誤ると影響が大きい内容でも、根拠を持って修復に進められるようになっています。

https://aws.amazon.com/jp/security/provable-security/

【Verify / Refine】3つのアナライザー

IAM Access Analyzerには、3つのアナライザーがあります。
この3つのアナライザーは権限のライフサイクルのVerify（検出）とRefine（改善）に該当します。

①外部アクセスアナライザー

外部アクセスアナライザーは、信頼境界の外であるアカウント外・組織外・公開（パブリック）からアクセス可能になっているリソースを検知する機能です。無料で利用することができるため、とりあえず有効化することが権限運用の第一歩になります。

この外部アクセスアナライザーはスコープをアカウント単位（Account）と組織単位（Organization）のどちらかで設定できます。アカウント単位では「自アカウントの外からアクセスできるリソースがないか」を、組織単位では「自組織（AWS Organizations）の外からアクセスできるリソースがないか」を確認します。言い換えると、設定した信頼ゾーン（アカウントまたは組織）の内部に、境界の外からのアクセスを許可しているリソースが存在するかどうかを洗い出し、該当するものを検出します。また、アナライザー作成後に数秒で検出結果が表示されるため、設定してすぐに状況を把握できる即時性を強みとしています。

https://tech.nri-net.com/entry/authority_management_using_aws

外部アクセスアナライザーのベストプラクティス

アーカイブルールを作成する

ただ外部アクセスアナライザーを有効化するだけでは、権限運用は回りません。特に組織単位で検知する場合、検出結果が急激に増えやすく、重要な通知が埋もれてしまいます。そのため、アーカイブルールを活用することが大切です。アーカイブルールとは簡単に言うとフィルタリングのようなもので、検知が想定通りであるリソースに対して、アーカイブを行い、ノイズを落とす仕組みです。業務上の理由で意図的にクロスアカウント共有しているロールやバケットがある場合、それらをアーカイブ対象にすることで、対応が必要な検出結果に集中できるようになります。

命名規則をきちんと設定する

検出結果に対して、対応可否を確認する際に意外と重要になるのがリソースやルールなどの命名規則です。リソースやルールの命名が曖昧だと、用途やオーナーが追えず、うまくトリアージができません。そのため、命名規則は単なる整理整頓ではなく、セキュリティ運用の一部として取り扱うことが大切です。アーカイブルールも同様で、「何を」「なぜ」アーカイブするのかが名前から読み取れるようにしておくと、後任への引き継ぎや監査対応の場面でも意図を説明しやすくなります。

検知結果の対応フローを考慮する

外部アクセスアナライザーは検出して終わりではなく、見つけた後にどう動くかまで含めて設計しておくと効果的です。具体的には、検出結果を確認したら次のいずれかに必ず落とし込む、というような運用フローを決めておくのが望ましいです。

意図しない共有 → ポリシー/設定を修正して解消する
意図した共有 → アーカイブルールで想定内として管理する
そもそも不要なリソース → リソースの所有者に確認後、削除や整理の対象にする

運用フローを組み込み、検出結果へ適切に対応していくことで分析対象を減らすことができるため、後述の未使用アクセスアナライザーを有効化する際のコストも抑えられます。

②未使用アクセスアナライザー

未使用アクセスアナライザーは、文字通り使われていないリソースを洗い出すための機能です。対象は未使用の権限に限らず、未使用のロール／ユーザー（プリンシパル）、未使用のアクセスキーまで含まれます。スコープは外部アクセスアナライザーと同様に、アカウント単位または組織（Organization）単位で設定できます。未使用アクセスアナライザーでは、ただ未使用を見つけるだけでなく、自動推論を用いて、より最小権限に近い置き換えポリシーを推奨してくれます。これは、Refine（改善）のフェーズで、「削るべき権限は何か」、「どう置き換えればよいか」という具体的なアクションまで直結しやすくなります。

未使用アクセスアナライザーのベストプラクティス

いきなり短い追跡期間にしない

未使用アクセスアナライザー有効化の際には、未使用として判定するための基準期間として追跡期間を設定します。いきなり追跡期間を短期間にすると検出結果が増えすぎたり、検出によって削除対応を行ったことにより月次・四半期など低頻度で動くプロセスを壊してしまうリスクが上がります。運用上は、まず365日など長めに設定し、1年間使っていないものを優先的に片付けるのがおすすめです。その後、環境が落ち着いてきたら 270日 → 90日… のように段階的に縮めていくと、安全に最小権限へ寄せることができます。また、監査や棚卸しのタイミングに合わせて運用頻度を決め、それに合わせて追跡期間を設定することで定期レビューとして回す設計にするのもよいと思います。

アナライザー名に追跡期間を入れる

運用を進めていくと、追跡期間が異なるアナライザーを複数利用することがあります。 365d、90dのように追跡期間の情報をアナライザー名に含めることを検討するとよいです。そうすることで、アナライザー名に含まれた追跡期間でフィルタリングすることが可能になります。

ノイズが多いアカウントに関しては対象外とする

組織単位で運用する場合、検証環境や実験用アカウントなどのアカウントから大量に検出が発生する場合があります。優先度が低いアカウントに関しては、対象外とすることで、重大な検出結果に集中し、分析対象が減る分、コストも抑えることができます。

③内部アクセスアナライザー

内部アクセスアナライザーは、外部アクセスアナライザーの補完となる機能で、組織内の誰が重要リソースにアクセスできるのかを洗い出すための機能です。 S3バケットやDynamoDBテーブルなど、最も重要なAWSリソースのみに設定することが前提になります。アクセスできるIAM ロールやIAMユーザーを厳密に絞る必要がある機密データ・監査対象データ・経営／顧客情報などを格納するリソースに対して利用します。

内部アクセスアナライザーを有効にすると、対象リソースごとに組織内でアクセス可能なすべてのプリンシパル（IAM ユーザーまたはロール）を網羅した検出結果が生成されます。これは「誰がアクセスできるか」だけでなく、どんな条件でアクセスできるのか、そしてどの操作を実行できるのかといったアクセスの性質まで示されるため、アクセスの確認や監査対応の棚卸しに直結する情報として扱えます。

また、内部アクセスアナライザーは計算量が多いため、コストが発生します。料金は対象リソース数 × 月額（リージョン単位）で、1リソースあたり月額9ドルになります。計算量が多くなる理由としては、リソースポリシーだけでは判断せず、アイデンティティポリシー・リソースポリシー・SCP・RCPなど複数のポリシーを突き合わせて到達可能であるかを評価するためです。さらにその評価を自動推論で行い、条件や制約を含めてアクセス可否を導きます。

内部アクセスアナライザーのベストプラクティス

対象は重要なリソースに絞る

内部アクセスアナライザーは、組織内のアクセス経路を網羅的に洗い出す分、多くの検出結果が生成されます。重要なのは、その中から「何がノイズで、何が対応すべき検出結果であるか」を判断できる状況を作ることです。特に、大規模な組織で多数のアカウント・プリンシパルが存在する環境で、アクセス可能な S3 バケットを分析すると、結果が膨大になります。まずは最重要であるリソースのみに限定し、権限の絞り込みに注力すべきポイントを優先順位付けできる範囲に収めることが、継続運用の前提になります。

CSV（ARN リスト）で対象を管理し、分析対象をブレさせない

内部アクセスアナライザーは、分析対象をどこまで広げるか、絞るかという判断そのものが運用の肝になります。そこで役立つのが、ARNのリストをCSVで管理してインポートする方法です。重要リソースをCSVで一元管理しておけば、分析対象をブレなく指定できるうえ、監査や定期的なユーザーアクセスレビュー（棚卸し）のタイミングで対象を切り替えるのも容易になります。結果として、属人化を防ぎながらレビュー作業を効率化できます。

内部アクセスアナライザー作成時に、「CSVをアップロードしてリソースを追加」を選択することで、管理しているCSVをインポートすることができます。

【Set】IAM Access Analyzerのカスタムポリシーチェック

カスタムポリシーチェックとは、セキュリティ標準に基づいて新しいアクセスに対してチェックを行うことができるIAM Access Analyzer機能のひとつです。 3つのアナライザーがVerify/Refine（検出/改善）を支えるのに対し、カスタムポリシーチェックはそもそも危険な設定を混入させないためのSetフェーズに位置づけられます。

カスタムポリシーチェックでは、4つのAPIを利用します。
1つ目は、ValidatePolicyです。 ValidatePolicyは、ポリシー文法とベストプラクティスに基づく検証を行うことができます。イメージとしてはIAMポリシーのためのlinterのようなものであり、基本的な文法間違いや不備を早期に潰せます。

残りの3つは、Check系のAPIです。 ValidatePolicyとは違い、AWSの一般的なベストプラクティスではなく、組織としての標準（ガードレール）を反映しチェックするためのAPI群です。例えば、「ロールにs3:DeleteBucketは付けない」など、組織の運用ルールをそのままチェック項目に落とし込むことができます。

各Check系のAPIの詳細は以下です。

CheckNoNewAccess：既存ポリシーと比較して、更新後ポリシーがより広い権限を付与していないか確認
CheckAccessNotGranted：禁止したい権限が許可されていないかを確認
CheckNoPublicAccess：リソースポリシーが公開アクセスを許可しうるかを確認

CheckNoNewAccess - IAM Access Analyzer

CheckAccessNotGranted - IAM Access Analyzer

CheckNoPublicAccess - IAM Access Analyzer

また、カスタムポリシーチェックはAPIとして提供されているため、CI/CD内で組み込むことができ、意図せず権限を広げてしまう、禁止されるべき設定が混ざる、公開につながる設定が入るといった事故を、デプロイ前に落とすことができます。

実際にGitHubとCodePipelineを使い、CDK（IaC）で作成したリソースに対して検査するようなパイプラインを作成することができます。検査には先ほど紹介したCheck系のAPIを利用し、事前に定めた基準を満たさない場合、デプロイを止めます。また、Amazon Bedrockを組み込み、違反したステートメントと参照ポリシーをもとに修正手順を文章化、GitHub Issueを自動起票することで、失敗時のフィードバックを開発者に素早く共有・対応依頼を出すことができます。これをすることで、クラウドセキュリティ担当者と開発者とのやりとりを減らし、緊急度が高いIAMの修正に対して即時対応を可能とします。

終わりに

紹介した3つのアナライザーは、Verify/Refineフェーズで強力なガードレールとして機能します。一方でIAM権限は設定を誤ると影響範囲が大きく、後追いの修正だけでは追いつかない場面もあります。そのため、Setフェーズでカスタムポリシーチェックを組み込み、デプロイ前に止める仕組みを作っておくことが大切になります。また、Setフェーズの工夫として、AIコーディングアシストを活用するケースでは、開発スピードを落とさずに最小権限へ寄せるための仕組みも必要になります。 IAM Policy AutoPilotを利用することで、必要最低限の権限作成を支援するアプローチを組み合わせることで、セキュリティのために開発を止めない運用を行うことができます。

Verify/Refineフェーズの未使用アクセスアナライザーや内部アクセスアナライザーは有用な一方で、コスト面から導入をためらいやすいです。そのため無理に有効化するのではなく、アカウントやリソースの重要度に応じて対象を絞り、必要な範囲で適切に設定することが大切になります。

加えて、組織規模で有効化を行うと検出結果は増え、きちんと運用設計を行わないと通知しているだけとなり形骸化しがちです。だからこそ、アーカイブルール／命名規則／対応フローを整えて見直し（Refine）を回せる状態を作ることが重要になります。

最小権限は常に揺れ動くことを意識し、運用の中で継続的に改善を行いましょう!