# IAM Access Analyzer の使いどころ：外部共有リスクと最小権限を整理する
IAM の権限レビューで一番まずいのは、「たぶん大丈夫」で済ませることです。
S3 バケットポリシー、KMS キー、IAM ロール、Lambda 関数などは、設定の一部を間違えるだけで外部アカウントから使える状態になることがあります。しかも、人力レビューだけでは見落としやすい。画面を眺めて安心する運用は、だいたい長続きしません。
この記事では、IAM Access Analyzer を外部共有リスクと最小権限レビューの入口としてどう使うかを整理します。
結論：Access Analyzer は「権限が広すぎるかも」を機械で洗う入口
先に結論を書くと、IAM Access Analyzer は次の用途で効きます。
- 外部アカウントに共有されている AWS リソースを見つける
- パブリックアクセスやクロスアカウントアクセスの意図しない設定を検出する
- CloudTrail の利用履歴をもとに IAM ポリシーを絞る材料を作る
- 最小権限レビューの出発点を作る
つまり、Access Analyzer は「すべてを自動で安全にしてくれる魔法」ではありません。危ない可能性がある権限を、人がレビューできる形に出すサービスです。
なぜ IAM の人力レビューは漏れやすいのか
IAM のレビューが難しい理由は、権限が一か所にまとまっていないからです。
たとえばアクセス許可は、次のような場所に散らばります。
- IAM ポリシー
- IAM ロールの信頼ポリシー
- S3 バケットポリシー
- KMS キーポリシー
- SQS キューポリシー
- Lambda のリソースベースポリシー
しかも、
- \"*\" が入っている
- 外部アカウント ID が入っている
- Organization 外への共有がある
- 条件句が緩い
といった設定は、個別に見ると問題なさそうでも、全体としては危ないことがあります。
ここを人力だけで追うのはつらい。だから Access Analyzer を使って、まず機械に洗わせます。
外部共有リスクを見つける
Access Analyzer の分かりやすい使いどころは、外部共有の検出です。
たとえば次のような状態を検出対象にできます。
- S3 バケットが外部アカウントから読める
- KMS キーが想定外の principal に許可されている
- IAM ロールを外部アカウントが assume できる
- SQS や Lambda のリソースベースポリシーが広い
重要なのは、検出結果をそのまま「全部悪」と見ないことです。
外部共有には、正当な設計もあります。たとえば監査アカウント、ログ集約アカウント、CI/CD 用アカウントとの連携です。見るべきなのは、その共有が意図したものか、条件が十分に絞られているかです。
最小権限に近づける
Access Analyzer は、最小権限のレビューにも使えます。
実務では、最初から完璧な IAM ポリシーを書くのは難しいです。検証中に広めの権限を付け、そのまま残ることもあります。雑です。よくあります。だから後で削る仕組みが必要です。
Access Analyzer のポリシー生成機能では、CloudTrail に記録された実際のアクセス履歴をもとに、利用されたアクションを反映したポリシー案を作れます。
たとえば、開発用に次のような広い権限を一時的に付けていたとします。
```json
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
```
CloudTrail の履歴を見れば、実際には s3:GetObject と s3:PutObject しか使っていない、ということが分かるかもしれません。その場合、レビューして権限を絞る材料になります。
もちろん、生成されたポリシーをそのまま本番投入するのは雑です。アプリケーションの将来の操作、障害対応時の作業、運用手順まで含めて確認する必要があります。
CloudTrail と組み合わせる
Access Analyzer を最小権限に使うなら、CloudTrail との関係を押さえておくべきです。
CloudTrail は「実際に何が呼ばれたか」を記録します。Access Analyzer はその履歴を材料にして、使われた権限を見える形にできます。
役割を分けるとこうです。
| 目的 | 主に見るもの |
|---|---|
| 外部共有を検出する | Access Analyzer finding |
| 実際に使われた API を見る | CloudTrail event |
| IAM ポリシーを絞る材料を作る | Access Analyzer policy generation |
| 最終的な許可範囲を判断する | 人間のレビュー |
最後だけは自動化できません。判断まで機械に丸投げすると、必要な権限を削って障害を作るか、不要な権限を残して監査で怒られます。どちらも面倒です。
比較表で役割を整理する
| 観点 | 人力レビューだけ | Access Analyzer を使う |
|---|---|---|
| 外部共有の見落とし | 起きやすい | 検出しやすい |
| クロスアカウント確認 | ポリシーを追う必要がある | finding として見やすい |
| 最小権限化 | 勘に寄りやすい | CloudTrail 履歴を材料にできる |
| 判断 | 人が行う | 人が行う |
| 運用負荷 | 高くなりがち | レビュー対象を絞りやすい |
Access Analyzer はレビュー担当者を置き換えるものではありません。レビュー対象を絞り、危ない設定を見つけやすくする道具です。
導入時の注意点
使うときは、次の点を決めておくと運用しやすくなります。
- finding を誰が確認するか
- archive rule をどう管理するか
- 正当な外部共有をどう記録するか
- CloudTrail の保持期間をどうするか
- 生成ポリシーを誰がレビューして適用するか
特に archive rule は雑に作ると危険です。「毎回出てうるさいから消す」という運用を始めると、照妖鏡どころか曇った鏡になります。
試験での見分け方
AWS 認定試験では、次のキーワードが出たら Access Analyzer を疑う価値があります。
- 外部アカウントへの共有を検出したい
- パブリックアクセスの可能性を見つけたい
- IAM ポリシーを最小権限に近づけたい
- CloudTrail の利用履歴をもとに権限を見直したい
- クロスアカウントアクセスを確認したい
「権限を誰が使ったかを監査ログで追いたい」なら CloudTrail が中心です。一方、「ポリシー上、外部から使える可能性があるか」を見たいなら Access Analyzer が本命になります。
まとめ
IAM Access Analyzer は、IAM を安全にするための自動修復ボタンではありません。
ただし、次の用途ではかなり強いです。
- 外部共有リスクを見つける
- クロスアカウントアクセスを可視化する
- CloudTrail をもとに最小権限化の材料を作る
- 人力レビューの漏れを減らす
IAM は放っておくと広がります。だから、広がった権限を見つけて削る仕組みが必要です。
Access Analyzer は、その最初の一歩として使いやすいサービスです。権限レビューを気合いで回す前に、まず機械に洗わせましょう。