AWS IAM（Identity and Access Management）を安全に運用するための指針をまとめたもの。基本の考え方は「誰が・何に・どの条件でアクセスできるかを最小限にし、常に検証できる状態に保つ」こと。
目次
- 1. ルートユーザーを守る
- 2. 人間のユーザーは一時的な認証情報で
- 3. ワークロードは IAM ロールで
- 4. 最小権限の原則
- 5. ガードレールを多層で設ける
- 6. アカウントを分割する
- 7. 外部アクセスと未使用アクセスを継続的に検出する
- 8. 監視とログ
- 9. ポリシーをコードで管理する
- 10. 定期的な棚卸し
- チェックリスト
1. ルートユーザーを守る
- ルートユーザーは日常業務で使わない。請求設定やアカウント閉鎖など、ルートでしかできない操作に限る
- MFA を必ず有効化する（可能ならハードウェアキー / パスキー）
- ルートユーザーのアクセスキーは作成しない。存在する場合は削除する
- AWS Organizations 配下のメンバーアカウントでは、ルートアクセスの一元管理機能でルート認証情報自体を削除し、必要な特権操作は管理アカウントから短時間だけ実行する
- ルートユーザーのメールアドレスは個人ではなく、チームで管理する配布リストにする
2. 人間のユーザーは一時的な認証情報で
- 人間のアクセスは IAM Identity Center（旧 AWS SSO） や外部 IdP（Okta、Entra ID など）とのフェデレーションを使う
- IAM ユーザー + 長期アクセスキーの発行は原則避ける
- 権限はグループ / 権限セット単位で割り当て、個人に直接ポリシーを付けない
- 全ユーザーに MFA を必須化する
3. ワークロードは IAM ロールで
- EC2 → インスタンスプロファイル、Lambda → 実行ロール、ECS → タスクロール、EKS → IRSA / Pod Identity を使う
- AWS 外のワークロード（GitHub Actions、オンプレミスなど）は OIDC フェデレーション や IAM Roles Anywhere で一時認証情報を取得する
- アクセスキーをコード・環境変数・リポジトリに埋め込まない
- どうしても長期キーが必要な場合は、定期的にローテーションし、Secrets Manager 等で管理する
4. 最小権限の原則
- 必要なアクション・リソース・条件だけを許可する
"Action": "*"や"Resource": "*"は極力避ける- まず AWS 管理ポリシーで始め、運用が安定したらカスタマー管理ポリシーで絞り込む
- IAM Access Analyzer のポリシー生成機能で、CloudTrail の実利用履歴から最小権限ポリシーを作る
- 「最終アクセス情報（last accessed）」を見て、使われていない権限を削る
条件キーでさらに絞る
| 目的 | 条件キーの例 |
|---|---|
| 送信元 IP の制限 | aws:SourceIp |
| VPC エンドポイント経由のみ許可 | aws:SourceVpce |
| MFA 済みのみ許可 | aws:MultiFactorAuthPresent |
| 組織内からのみ許可 | aws:PrincipalOrgID / aws:ResourceOrgID |
| リージョン制限 | aws:RequestedRegion |
| タグベース制御（ABAC） | aws:ResourceTag/*, aws:PrincipalTag/* |
| 混乱した代理問題の防止 | aws:SourceArn, aws:SourceAccount |
5. ガードレールを多層で設ける
| 仕組み | 役割 |
|---|---|
| SCP（サービスコントロールポリシー） | 組織 / OU / アカウント単位で「プリンシパルができる最大範囲」を制限 |
| RCP（リソースコントロールポリシー） | 組織内リソースに対して「誰がアクセスできるか」の上限を制限 |
| アクセス許可の境界（Permissions Boundary） | 開発者などに IAM ロール作成を委任するとき、作れる権限の上限を固定 |
| セッションポリシー | AssumeRole 時にその場限りで権限をさらに絞る |
SCP の典型例:
- 利用しないリージョンを拒否
- CloudTrail / GuardDuty / Config の無効化を拒否
- ルートユーザーの操作を拒否
- 組織からの離脱（
organizations:LeaveOrganization）を拒否
6. アカウントを分割する
- AWS Organizations でマルチアカウント構成にし、本番・開発・ログ・セキュリティなどを分離する
- アカウント境界は最も強力な分離単位。権限設計の複雑さを減らせる
- AWS Control Tower でランディングゾーンを整備すると、ガードレールの初期設定が楽になる
7. 外部アクセスと未使用アクセスを継続的に検出する
- IAM Access Analyzer を組織単位で有効化
- 外部アクセス分析: S3 バケット、KMS キー、IAM ロールなどが組織外に公開されていないか検出
- 未使用アクセス分析: 使われていないロール、アクセスキー、パスワード、権限を検出
- ポリシー検証: ポリシー作成時に文法エラーやセキュリティ警告をチェック
- カスタムポリシーチェック: CI/CD でポリシー変更が過剰な権限を与えないか自動検査
- クロスアカウントのロール信頼ポリシーでは、第三者に対して
sts:ExternalIdを必須にする
8. 監視とログ
- CloudTrail を全リージョン・全アカウントで有効化し、ログ専用アカウントの S3 に集約
- GuardDuty で不審な API 呼び出しや認証情報の悪用を検知
- Security Hub で IAM 関連の設定ミス（CIS ベンチマーク等）を一元可視化
- AWS Config ルールで「ルートの MFA 有効」「アクセスキーのローテーション」などを継続評価
- ルートユーザーのログイン、IAM ポリシー変更、AssumeRole の失敗多発などにアラートを設定
9. ポリシーをコードで管理する
- IAM ポリシー・ロールは IaC（Terraform、CloudFormation、CDK） で管理し、手作業の変更を避ける
- プルリクエストでレビューし、Access Analyzer のポリシー検証を CI に組み込む
Denyを明示的に使うべき場面（重要リソースの削除防止など）を整理しておく
10. 定期的な棚卸し
- 四半期など定期的に以下を確認する
- 90 日以上使われていないユーザー・ロール・アクセスキー
- 過剰な権限（
AdministratorAccessの付与先など） - 退職者・異動者のアクセス
- クロスアカウント信頼関係の妥当性
- 不要なものは無効化 → 一定期間後に削除の 2 段階で進めると安全
チェックリスト
- ルートユーザーに MFA を設定し、アクセスキーを削除した
- メンバーアカウントのルート認証情報を一元管理で削除した
- 人間のアクセスを IAM Identity Center / フェデレーションに移行した
- 全ユーザーに MFA を必須化した
- ワークロードは IAM ロールで一時認証情報を使っている
- コードやリポジトリに長期アクセスキーが含まれていない
- ワイルドカード権限を見直し、最小権限に絞った
- SCP で組織全体のガードレールを設定した
- IAM Access Analyzer（外部アクセス・未使用アクセス）を有効化した
- CloudTrail を全リージョン・全アカウントで有効化し集約した
- GuardDuty / Security Hub / Config を有効化した
- IAM を IaC で管理し、CI でポリシー検証している
- 定期的な棚卸しの仕組みがある