どんな場面で検討するか
AWS 上で担当者・アプリ・自動処理が必要なリソースだけを操作できるよう、権限を分離・制限したい場合。委託先の作業範囲、サービスロール、アカウントをまたぐアクセスを管理する土台。
組織で使う条件
実操作に合わせて最小権限へ狭め、使用していない権限と資格情報を定期的に除去する。権限境界や組織の制御と個別ポリシーの関係を確認する。 許可した操作が通ることと、範囲外操作が拒否されることを両方試験する。ロールの trust policy、セッション期間、失効・契約終了時の削除を記録する。
採用前に試すこと
- allowed/ の取得だけを許可したロールを作り、一時資格で読み取る。ポリシーの構文を検証する。
- 対象外 prefix の取得、書込み、別サービス操作、未許可のロール引受けを試す。
- セッション満了と権限削除後の再接続を確認し、引受け元・期間・操作記録をレビューする。
合格と判断する条件
- 許可ファイルを取得でき、資格情報がソース・ログ・提出資料へ残らない。
- 全て拒否され、拒否理由を操作記録とポリシーから説明できる。
- 期限切れ資格で利用を継続できず、新たな引受けも想定した条件に限定される。解除手順を別担当者が再現できる。
見落としたくない点
- 一般利用者向けの会員ログイン・アプリ内ロール管理を IAM ユーザーで代替しない。顧客 ID 基盤やアプリの認可機能は別に比較する。 AdministratorAccess を配ってから制限を考える方式や、共用ユーザーのまま監査可能と扱う方式は避ける。外部担当者には信頼元と対象範囲を明確にする。
- 一般利用者向けの会員ログイン・アプリ内ロール管理を IAM ユーザーで代替しない。顧客 ID 基盤やアプリの認可機能は別に比較する。
- AdministratorAccess を配ってから制限を考える方式や、共用ユーザーのまま監査可能と扱う方式は避ける。外部担当者には信頼元と対象範囲を明確にする。
根拠となる資料
Access Management – AWS Identity and Access Management (IAM)
Security best practices in IAM