SAP-C02-114 · セクション 13 / タスク 3.2
Least Privilegeを監査する
IAM Policy / IAM Role / Least Privilege / Excess Permission / IAM Access Analyzer / Unused Permission / Permission Reduction
最小権限の基本は、
必要な主体へ
必要なアクションを
必要なリソースに対して
必要な条件でだけ許可することです。
しかし既存環境では、導入時には必要だった権限や、トラブル対応のため一時的に追加した権限が、そのまま残っていることがあります。
例えば、
IAMロール
↓
AdministratorAccess
実際の通常処理
↓
S3読み取りだけという状態です。
このとき重要なのは、
ポリシーが広そう
↓
すぐ削除ではありません。
現在のIAMロール / ポリシーを把握
↓
業務上必要な権限を確認
↓
利用実績を確認
↓
未使用・過剰権限を候補化
↓
削減しても成立するか検証
↓
段階的に権限を縮小
↓
正常性を確認という監査を行います。
ゴール
既存環境について、
- IAMロールとIAMポリシーの現在状態を把握する
- 業務要件と実際のアクセス許可を比較する
- 「未使用」と「不要」を区別する
- 使用実績があっても過剰な権限を識別する
- IAM Access Analyzerの未使用アクセス分析を監査へ利用する
- 追跡期間を業務サイクルに合わせて設定する
- アクセスアクティビティを権限削減の根拠として利用する
- IAM Access Analyzerのポリシー生成を権限縮小の補助に使う
- 削減候補を検証してから権限を縮小する
ことを目指します。
1. 最初に「現在何を許可しているか」を把握する
最小権限監査では、最初からポリシーを書き換えません。
まず、
IAMロール
↓
どのポリシーが付いている？
IAMポリシー
↓
何を許可している？
業務
↓
本当に何が必要？を整理します。
例えば、
AppRole
├─ AmazonS3FullAccess
├─ 独自ポリシー
└─ インラインポリシーという状態なら、ポリシー名だけを見るのではなく、現在そのロールにどのアクセス許可が与えられているかを確認します。
2. 最小権限監査では「付与権限」と「必要権限」の差を見る
監査したいのは、
現在付与されている権限だけではありません。
現在付与されている権限
-
現在の業務に必要な権限
=
削減候補という差を探します。
例えば、
現在
s3:*
dynamodb:*
ec2:*
業務要件
s3:GetObject
s3:ListBucketなら、DynamoDBやEC2のアクセス許可は見直し候補になります。
ここでの目的は、権限数をできるだけ少なくすることではありません。
現在の業務を成立させる必要最小限まで縮小することです。
3. 「広い権限」と「過剰権限」は完全には同じではない
例えば、
s3:*は非常に広いアクセス許可です。
しかし監査では、
広いから削除だけで判断しません。
現在の業務要件が、
オブジェクト取得
オブジェクト登録
バケット一覧だけなら、それ以外のS3アクションは過剰権限の候補になります。
逆に、普段は利用しないものの、
四半期処理
年次処理
災害復旧
緊急運用で必要な権限が存在する場合があります。
そのため、
現在使っていない
=
必ず不要とは判断しません。
4. 未使用のアクセス許可は重要な削減候補
既存IAMロールには、
以前の機能で使っていた
一時対応で追加した
将来使う予定だった
担当者が変わって用途不明といったアクセス許可が残ることがあります。
これらのうち、一定期間使用されていないアクセス許可は、最小権限へ近づけるための重要な調査対象です。
付与されている
+
利用実績がない
↓
削減候補ただし、この時点ではまだ、
削除確定ではありません。
5. IAM Access Analyzerの未使用アクセス結果を監査へ使う
IAM Access Analyzerで未使用アクセスを検出できること自体は前提知識です。
ここで重要なのは、検出結果をどのように権限削減へつなげるかです。
未使用アクセスでは、代表的に次の検出結果タイプを扱います。
UnusedIAMRole
↓
未使用IAMロール
UnusedIAMUserAccessKey
UnusedIAMUserPassword
↓
未使用IAMユーザー認証情報
UnusedPermission
↓
未使用アクセス許可
├─ サービスレベル
└─ 対応するアクションレベルつまり、
検出結果
↓
そのまま削除ではなく、
検出結果
↓
業務要件と利用状況を確認
↓
削減候補として評価と使います。
IAM Access Analyzerが自動的にアクセス許可を削除するわけではありません。
監査対象を絞り込むための根拠として利用します。
6. 追跡期間は業務サイクルに合わせる
未使用アクセスアナライザーでは、分析する追跡期間を設定できます。
現在は、
1～365日の範囲で設定できます。
ここで、
30日使っていない
↓
不要と機械的に判断すると問題があります。
例えば、
月次処理
→ 毎月利用
四半期処理
→ 3か月ごと
年次処理
→ 年1回
災害復旧操作
→ 通常は利用しないでは、必要な観測期間が異なります。
したがって、
業務サイクル
↓
十分な追跡期間
↓
未使用アクセス分析という順序で考えます。
7. 「未使用」と「不要」を区別する
IAM Access Analyzerで、
kms:Decrypt
未使用と表示されたとします。
だからといって、すぐ削除できるとは限りません。
例えばそのアクセス許可が、
災害復旧時だけ使用
四半期のデータ復旧で使用
緊急時だけ使用されるものかもしれません。
したがって、
未使用のアクセス許可
↓
業務要件を確認
↓
本当に不要？
│
├─ はい → 権限削減候補
│
└─ いいえ → 必要権限として維持と判断します。
未使用アクセスは削除命令ではなく、レビューを開始するシグナルです。
8. 使用された権限でも過剰な場合がある
反対方向にも注意が必要です。
例えばアプリケーションには読み取りしか必要ないのに、以前のテスト処理によって、
s3:PutObjectが実際に使われていたとします。
利用実績があるからといって、
使用された
=
現在も必要とは限りません。
最小権限の基準は、
過去に使われたかではなく、
現在の正当な業務要件に
必要かです。
したがって、
利用実績
+
業務要件の両方を確認します。
9. IAMロール単位で「必要な責任」を確認する
既存IAMロールには、時間の経過とともにアクセス許可が追加され続けることがあります。
初期
S3読み取り
↓
機能追加
DynamoDB書き込み
↓
障害調査
EC2操作
↓
現在
すべて残存という状態です。
監査では、
このIAMロールは
現在何を担当しているのかを改めて確認します。
その責任に不要になったアクセス許可を削減候補にします。
ロールをどう分割するかという新規設計そのものではなく、現在のIAMロールへ残っているアクセス許可が現在の責任に一致しているかを監査します。
10. 1つのポリシーだけ削減して終わらない
例えばIAMロールに、
広いAWSマネージドポリシー
+
狭いカスタマーマネージドポリシーの両方がアタッチされているとします。
狭いポリシーを新しく追加しても、
広いポリシーが残っている
↓
広い権限も残るなら、権限縮小は完了していません。
したがって、
縮小後のポリシーを準備
↓
必要操作を検証
↓
古い広いポリシーを外す
↓
実際のアクセス許可を再確認まで行います。
11. アクセスアクティビティを権限縮小の根拠にする
IAMでは、最終アクセス情報などを利用して、
どのサービスへ
いつアクセスしたかを確認できます。
また、一部のサービスではアクション単位の最終アクセス情報も利用できます。
例えば、
許可
EC2
S3
DynamoDB
実際の利用
S3のみなら、
EC2
DynamoDBを調査対象にできます。
ただしこれも、
利用されていない
=
必ず削除可能という意味ではありません。
業務要件との突合が必要です。
12. IAM Access Analyzerのポリシー生成を削減案の作成に使う
既存IAMユーザーやIAMロールに広いアクセス許可がある場合、IAM Access AnalyzerではCloudTrailのアクセスアクティビティを基にポリシーを生成できます。
広いIAMポリシー
↓
実際のCloudTrailアクティビティ
↓
IAM Access Analyzer
↓
利用実績を基にした
ポリシーテンプレートポリシー生成では、最大90日間のCloudTrailアクティビティを分析対象にできます。
これにより、
AdministratorAccessなどを手作業でゼロから縮小するより、実際に利用されたサービスやアクションを削減案の出発点にできます。
13. 生成されたポリシーをそのまま「正解」としない
IAM Access Analyzerが生成するポリシーは、
観測されたアクティビティを基にしています。
しかし、
観測期間中に
年次処理がなかった
障害対応を実施しなかった
まれな業務フローが動かなかったという可能性があります。
また、生成後にはリソース範囲や条件などをさらに調整する必要があります。
したがって、
ポリシー生成
↓
そのまま置換ではなく、
ポリシー生成
↓
業務要件と比較
↓
必要なアクションを補正
↓
リソースを限定
↓
条件を調整
↓
検証と進めます。
14. 権限削減は段階的に行う
大量のアクセス許可を一度に削除すると、
何を消した結果
どの処理が失敗したのかが分かりにくくなります。
既存環境では、
削減候補を決定
↓
縮小ポリシーを準備
↓
通常処理をテスト
↓
定期処理 / 例外処理も確認
↓
広い権限を削除
↓
アクセス拒否や業務影響を確認と段階的に進めます。
特に本番環境では、
削減
↓
確認
↓
次の削減という単位を管理します。
15. 「一度も使われていない権限を全部削除」も危険
典型的な誤りは、
未使用アクセス検出結果
↓
一括削除です。
例えば、
通常処理では未使用
しかし
災害復旧で必須という権限まで削除すると、通常時には問題が見つからず、障害発生時に初めて失敗します。
そのため削減前に、
通常業務
定期業務
緊急業務
復旧業務まで確認します。
16. 逆に「念のため残す」だけでも最小権限にならない
一方、
いつか使うかもしれないという理由ですべてのアクセス許可を維持していては、最小権限へ改善できません。
必要性を確認できないアクセス許可は、
誰が必要と言っているか
どの処理で必要か
どの頻度で必要か
どのリソースへ必要かを確認します。
根拠がなければ削減候補とします。
17. 最小権限監査の基本フロー
既存環境では次の順序で考えます。
1. IAMロール / IAMポリシーを棚卸し
↓
2. ロールの現在の責任を確認
↓
3. 業務上必要な権限を整理
↓
4. 利用実績を確認
↓
5. IAM Access Analyzerで
未使用アクセスを確認
↓
6. 未使用
≠
不要
を確認
↓
7. 過剰権限を削減候補化
↓
8. 必要ならアクセスアクティビティから
縮小ポリシー案を作成
↓
9. 業務要件で補正
↓
10. 段階的に権限削減
↓
11. 正常性を確認18. 混同しやすいポイント
| 誤りやすい判断 | 正しい考え方 |
|---|---|
| 広いポリシーなら即削除 | 現在の業務要件と比較して過剰範囲を特定 |
| 未使用アクセス = 不要 | 定期・緊急・復旧用途も確認 |
| 使用実績がある = 必要 | 現在の正当な業務要件が基準 |
| IAM Access Analyzerが権限を自動削除する | 削減候補を発見・分析する |
| 30日未使用なら削除 | 業務サイクルに合う追跡期間を設定 |
| 生成ポリシーをそのまま適用 | 業務要件、リソース、条件を確認・調整 |
| 狭いポリシーを追加すれば完了 | 古い広いアクセス許可が残っていないか確認 |
| 一度に大量削減する | 段階的に削減・検証する |
19. SAP-C02での判断手順
問題文で、
IAMロールに広い権限
+
既存環境
+
最小権限へ改善が出たら、
何が付与されている？
↓
現在の役割は何？
↓
何が実際に使われている？
↓
十分な期間を観測した？
↓
未使用アクセスはある？
↓
まれな必要処理ではない？
↓
現在の要件より広い権限は？
↓
安全に縮小できる？と考えます。
決定打は、
未使用だから全部削除でも、
念のため全部残すでもありません。
業務要件と利用実績の両方を根拠に、不要な権限だけを安全に削減することです。
まとめ
最小権限の監査では、
現在の権限
↓
業務要件
↓
利用実績
↓
未使用アクセス
↓
過剰権限
↓
削減候補
↓
検証
↓
権限削減という流れで考えます。
重要なのは、
未使用
≠
必ず不要
使用済み
≠
必ず必要
ポリシー生成
≠
完成した最小権限ポリシーです。
IAM Access Analyzerや最終アクセス情報は、機械的にアクセス許可を削除するためではなく、既存IAMロール / IAMポリシーを現在の業務要件へ近づけるための監査根拠として利用します。