最小権限設計 — IAMポリシー設計パターン
権限境界(Permission Boundary)、条件キーの活用、IAM Access Analyzerによる過剰権限検出を解説します。
セキュアなソリューション設計の出発点は、最小権限の原則 (Principle of Least Privilege) を IAMポリシーでどう実現するかです。本記事ではその実践的な設計パターンを解説します。
SAA レベル:基礎概念
IAMポリシーの基本構造
- Effect: Allow または Deny
- Action: 許可・拒否する操作(例:
s3:GetObject) - Resource: 対象リソースのARN
- Condition: 追加の条件(IPアドレス、時間帯等)
SAA 試験のポイント
IAMポリシーの評価では、明示的なDenyが常に最優先されます。Allowがどれだけ多く設定されていても、1つでもDenyがあればそのアクションは拒否される、という評価ロジックの基本がSAAで問われます。
ポリシーの種類
| 種類 | 説明 |
|---|---|
| アイデンティティベースポリシー | IAMユーザー/グループ/ロールにアタッチ |
| リソースベースポリシー | S3バケットポリシー等、リソース側に設定 |
| AWS管理ポリシー | AWSが提供する既製のポリシー |
| カスタマー管理ポリシー | 利用者が独自に作成するポリシー |
SAP レベル:高度な設計シナリオ
権限境界(Permission Boundary)
SAP 試験のポイント
権限境界は、IAMユーザーやロールに設定できる**「実効権限の上限」**を定義する仕組みです。開発者に「IAMロールを自由に作成してよいが、そのロール自身が持てる権限は権限境界の範囲内に制限する」という設計をすることで、開発者が誤って(あるいは意図的に)強すぎる権限を持つロールを作成することを防げます。SCPが組織全体に対するガードレールであるのに対し、権限境界は個々のIAMエンティティに対するガードレールという違いがSAPで問われます。
実効権限 = アイデンティティベースポリシー ∩ 権限境界
(両方でAllowされている操作のみ実行可能)
条件キーを活用した高度な制限
| 条件キー | 用途 |
|---|---|
aws:SourceIp | 特定のIPレンジからのアクセスのみ許可 |
aws:MultiFactorAuthPresent | MFA認証済みセッションのみ許可 |
aws:PrincipalOrgID | 特定のOrganizations配下のプリンシパルのみ許可 |
aws:RequestTag / aws:ResourceTag | タグに基づいた許可(ABAC: 属性ベースアクセス制御) |
SAP 試験のポイント
**ABAC(属性ベースアクセス制御)**は、タグを使って動的にアクセス制御を行う設計手法です。「Projectタグがalphaのリソースには、同じくProject=alphaのタグを持つロールのみアクセスできる」というポリシーを一度定義すれば、新しいプロジェクトが追加されるたびにポリシーを書き換える必要がなく、スケーラブルな権限管理が実現できます。IAMロールを個別に量産するRBAC(ロールベース)よりも、大規模組織ではABACが推奨されるケースが増えている点が問われます。
IAM Access Analyzerによる過剰権限検出
SAP 試験のポイント
IAM Access Analyzerは、実際のCloudTrailログ上のアクセス履歴を分析し、実際には使われていない過剰な権限を検出する機能(Access Analyzerのポリシー生成機能)を持ちます。「このロールは過去90日間、実際にはS3の読み取りしか行っていないが、ポリシー上はフルアクセスを許可している」といった乖離を検出し、最小権限のポリシーを自動生成できます。
設計上の落とし穴
「とりあえずAdministratorAccessを割り当てて、後で絞り込む」という運用は、絞り込みが実施されないまま放置されるリスクが高く、SAP試験でも回避すべきアンチパターンとして扱われます。開発初期段階から、IAM Access Analyzerを使った継続的な権限の棚卸しサイクルを組み込む設計が推奨されます。
まとめ
- SAA: IAMポリシーの基本構造、明示的Denyの優先順位を理解する。
- SAP: 権限境界によるガードレール設計、ABACによるスケーラブルな権限管理、Access Analyzerによる継続的な過剰権限の検出ができる。
次は **データ暗号化(保管時・転送時)**を見ていきましょう。