権限設計は一度書いて終わりではありません。リソースポリシーで他アカウントに開けた口、プロジェクトが終わっても残ったロール、いつの間にか広がった権限。設計と実態のずれは、人の目で棚卸しするには数が多すぎます。この記事は、そのずれを継続的に見張る IAM Access Analyzer が「何を見て、何を見ないのか」を、信頼ゾーンという言葉で説明できる状態を目指します。
この記事の結論
- IAM Access Analyzer は IAM の中の見張り役で、ポリシーを推論して、設計と実態のずれを finding として出します。
- 外部アクセス分析は、組織またはアカウントを信頼ゾーンとし、その外に開いたリソースポリシーを検出します。
- 未使用アクセス分析は、使われていないロール・アクセスキー・パスワード・サービス・アクションの権限を出します。内部アクセス分析は、選んだ重要リソースに組織内のどの主体が届くかを見ます。
- ポリシーの検証・カスタムチェック・生成は、書く前後（CI を含む）で効きます。外部アクセスの analyzer はリージョンごとに作る、といった範囲の癖も知っておく必要があります。
- 検出するだけで、直すのは人です。直す手段は SCP・境界・ポリシーの設計です。
IAM Access Analyzer とは何か（見張り役という位置づけ）
IAM Access Analyzer は、ポリシーを論理的に推論して「このリソースに、誰がどこから届くか」「この権限は実際に使われているか」を調べ、結果を finding（検出結果）として出すサービスです。IAM の機能群の一部として提供されています。
たとえるなら、ビルの警備室の監視カメラです。鍵を作って配るのは管理側（SCP・許可セット・権限境界）の仕事で、監視カメラは鍵を作りません。合鍵が外の人に渡っていないか、誰も使わない鍵が残っていないかを見て知らせるのが仕事です。正確な言い方に戻すと、Access Analyzer は権限を絞る機能ではなく、絞った結果が設計どおりかを確かめる機能です。
役割は大きく 2 つに分かれます。
- すでにある権限・共有を分析する: 外部アクセス・内部アクセス・未使用アクセスの 3 種類の分析
- ポリシーを書く前後を支える: ポリシーの検証、カスタムチェック、ポリシーの生成
次の章からは、まず「外」とは何かを決める信頼ゾーンを押さえ、そのうえで 3 種類の分析、書く側の機能の順に見ていきます。
THREE QUESTIONS3 つの分析
Access Analyzer は外・内・未使用の 3 つの問いに答える
-
外部
信頼ゾーンの外に、リソースが開いていないか
S3・KMS・ロールの信頼ポリシーなど
-
内部
選んだ重要リソースに、組織内のどの主体が届くか
守りたいものだけ選んで見る
-
未使用
付けた権限は、実際に使われているか
ロール・キー・パスワード・サービス・アクション
信頼ゾーンとは何か｜組織かアカウントかで「外」の定義が変わる
外部アクセス分析では、analyzer を作るときに信頼ゾーン（zone of trust）を決めます。信頼ゾーンは「ここまでは信頼してよい範囲」で、選べるのは 組織 か アカウント です。分析は、ゾーンの外のプリンシパルがリソースにアクセスできる状態を finding にします。
| 信頼ゾーンの選び方 | 「内」とみなす範囲 | 同じ組織の別アカウントへの共有 |
|---|---|---|
| 組織 | 組織に属するアカウント全体 | 内側なので finding にならない |
| アカウント | その 1 アカウントだけ | 外側なので finding になる |
つまり、同じ共有でも信頼ゾーンの選び方で finding になるかが変わります。複数アカウントを運用していて「組織の外に出ているものだけ知りたい」なら組織を、アカウント単位の境界を厳密に見たいなら、アカウントを信頼ゾーンにします。
ここで間違えやすいのが、「信頼ゾーンの内側＝安全」と読んでしまうことです。ゾーンの内側は、この分析が問題にしないだけです。組織内でも広すぎる権限は別の問題で、それは次の章の内部アクセス分析や未使用アクセス分析の守備範囲です。
CHECK 1ここまでの確認
組織を信頼ゾーンにした外部アクセス分析で、同じ組織の別アカウントにバケットを共有した場合はどうなる?
答えと解説
答え: 2. 信頼ゾーンの内側なので、外部アクセスの finding にはならない
外部アクセス分析は「信頼ゾーンの外」に開いた共有を出します。組織が信頼ゾーンなら組織内は信頼された側です。読み直すのは「信頼ゾーンとは何か」の章です。
外部アクセス・内部アクセス・未使用アクセスは何が違うか
3 種類の分析は、見ている問いが違います。
| 分析 | 見ている問い | 主な出力 |
|---|---|---|
| 外部アクセス | 信頼ゾーンの外に、リソースが開いていないか | リソースポリシーなどで外部に共有されたリソース |
| 内部アクセス | 選んだ重要リソースに、組織内のどの主体が届くか | 組織内の主体からのアクセス経路 |
| 未使用アクセス | 付けた権限は、実際に使われているか | 使われていないロール・アクセスキー・パスワード・サービス・アクションの権限 |
外部アクセス分析
S3 バケットのポリシー、KMS キーのポリシー、IAM ロールの信頼ポリシーのように、リソース側に書かれたポリシーで他の主体へ開いている状態を調べます。パブリックに開いたものも、他アカウントに開いたものも対象です。「他アカウントへの共有が増えてきたが、意図しない外部共有がないか継続的に見たい」という場面で、最初に思い浮かべる分析です。
内部アクセス分析
外部が「ゾーンの外」を見るのに対し、内部アクセス分析は組織の内側を見ます。すべてのリソースを対象にするのではなく、守りたい重要なリソースを選び、そこに組織内のどの主体が届くかを確かめます。外部アクセス分析では「内側だから問題なし」とされる範囲を、重要なリソースに限って掘り下げる使い方です。
未使用アクセス分析
こちらは共有ではなく、権限の使われ方を見ます。付けたまま使われていないロールやアクセスキー、パスワード、サービスやアクションの権限を出します。最小権限は「最初に絞る」だけでなく「使われなかった分を減らし続ける」ことで保たれるため、この分析が運用の棚卸しを支えます。
CHECK 2ここまでの確認
長く使われていない IAM ロールを棚卸ししたい。使う分析はどれ?
答えと解説
答え: 3. 未使用アクセス分析
使われていないロール・アクセスキー・権限を出すのは未使用アクセス分析です。外部は「外に開いているか」、内部は「組織内のどの主体が届くか」を見ます。
CHECK 3ここまでの確認
S3 バケットのポリシーが、意図しない他アカウントへ開いていないかを継続的に見たい。使う分析はどれ?
答えと解説
答え: 1. 外部アクセス分析
リソースポリシーによる外への共有を見るのが外部アクセス分析です。読み直すのは「3 種類の分析は何が違うか」の章です。
ポリシーの検証・カスタムチェック・生成は何をするか
ここまでは「すでにある権限」を見る機能でした。Access Analyzer にはもう一つ、ポリシーを書く前後で効く機能があります。
| 機能 | 何をするか | 効くタイミング |
|---|---|---|
| ポリシーの検証 | 文法とベストプラクティスに沿っているかを確認し、警告や提案を返す | 書いている最中、レビュー、CI |
| カスタムチェック | 「新しいアクセスを許していないか」「特定のアクセスを許していないか」など、決めた基準に照らして確認する | 変更の適用前（CI に組み込む） |
| ポリシーの生成 | 実際のアクティビティの記録をもとに、必要な権限だけを含むポリシーのたたき台を作る | 広い権限で動かしたあと、絞り込むとき |
使い分けの考え方はこうです。ポリシーの検証は「書き方として問題がないか」を見ます。カスタムチェックは「自分たちの基準を満たすか」を見るので、組織のルールを機械的に守らせたいときに向きます。ポリシーの生成は「実際に使った権限」を出発点にするので、最小権限に絞り込む最初の一歩になります。ただし生成されるのはたたき台で、そのまま適用してよいとは限りません。記録された期間に起きなかった操作の権限は含まれないため、人が内容を見て判断します。
評価の順番そのもの（明示的な Deny が優先される、など）は iam-policy-shikumi で扱っています。Access Analyzer の検証は、その評価の仕組みを前提に動いている、と捉えておけば十分です。
WRITE TO FIX書く前後の流れ
検証で止め、finding で気づき、直すのは人
-
ポリシーを書く
たたき台は生成も使える
-
検証・カスタムチェック
CI で基準を確かめる
-
適用する
SCP・ポリシー・境界
-
finding を見る
外部・未使用
-
人が直す
意図した共有は記録
使うときの癖｜リージョンごとの作成、反映の遅れ、料金の単位
仕組みは単純でも、使い始めてから気づく癖がいくつかあります。
リージョンごとに作る。 外部アクセスの analyzer は、見たいリージョンごとに作ります。リージョンをまたいで自動で見てくれるわけではないので、使っているリージョンのどこかが抜けていると、そこは分析の対象外です。「入れたはずなのに、そのリージョンのバケットは検出されない」という事態は、これで起きます。リージョン制限を SCP で掛けている組織は、許可したリージョンに揃えて作る、という考え方ができます。
反映には時間がかかる。 ポリシーを変えた直後に finding が更新されるとは限りません。変更を検出してから反映されるまでの目安は公式ドキュメントに書かれているので、「直したのに finding が残っている」と慌てる前に、公式の記述を確認します。
料金は分析の種類ごとに課金の単位が違う。 外部アクセス、未使用アクセスなど、種類によって何に対して課金されるかが異なります。数値は改定されうるので、この記事には書きません。使う分析を決めたら、公式の料金ページで確認してください。
finding は「問題」ではなく「確認が必要なもの」。 意図して外に共有しているものも finding になります。意図した共有は理由を記録したうえで、アーカイブなどで扱いを分ける運用にします。全部を消そうとするのではなく、「意図しないものだけが残る」状態を作るのが目的です。
CHECK 4ここまでの確認
外部アクセス分析を、使っている複数のリージョンのリソースに効かせるには?
答えと解説
答え: 2. 見たいリージョンごとに analyzer を作る
外部アクセスの analyzer はリージョンごとに作る前提です。見ていないリージョンは分析の対象外になります。読み直すのは「使うときの癖」の章です。
権限設計のどこに置くか（絞る側と確かめる側）
権限設計の道具は、役割で 2 つに分けると整理できます。
- 絞る側: SCP、IAM Identity Center の許可セット、権限境界、ポリシー。「何を許すか・許さないか」を決める
- 確かめる側: Access Analyzer。決めた結果が実態として設計どおりかを確かめる
RESTRICT AND VERIFY絞る側と確かめる側
権限は絞る道具と確かめる道具で役割が違う
絞る側
何を許すかを決める
- SCP
- 許可セット
- 権限境界
- ポリシー
確かめる側
結果が設計どおりかを見る
- Access Analyzer
- 外部・内部・未使用の finding
- 検証・カスタムチェック
Access Analyzer は finding を出すだけで、権限を変えません。見つけたあとに「SCP で防ぐか」「ポリシーを直すか」「そもそも設計を見直すか」を決めるのは人です。絞る側の設計は kengen-sekkei-pro で扱っているので、この記事の内容はその「減らし続ける」工程を支える部品として読むとつながります。
まとめると、Access Analyzer は外部（信頼ゾーンの外への共有）・内部（組織内で重要リソースに届く主体）・未使用（使われていない権限）の 3 つの問いに答え、書く前後にはポリシーの検証・カスタムチェック・生成が効きます。リージョンごとに作る癖と、finding を人が判断する運用を押さえておけば、同僚や顧客にも一言で説明できます。
参照ソース
- IAM Access Analyzer とは（AWS IAM ユーザーガイド） — 分析の種類（外部・内部・未使用）、信頼ゾーン、ポリシーの検証・カスタムチェック・生成、リージョンの扱い、反映の目安、課金の単位の根拠
- IAM Access Analyzer の料金（AWS 公式） — 料金の数値は書かず、確認先として案内するために参照
