IAM ベストプラクティス - AWS IAM ベストプラクティス

ルートユーザーは AWS アカウントのすべての操作を実行できる最上位の権限を持つ。

侵害された場合の被害が大きいため、日常的な業務では絶対に使用せず、専用の保護を施す。

対策	内容	優先度
ハードウェア MFA の有効化	FIDO2 セキュリティキー（YubiKey 等）をルート専用に割り当てる。SMS や仮想 MFA より強力	必須
アクセスキー発行の禁止	ルートのアクセスキーは発行しない。既存のものは即時削除する	必須
連絡先・請求情報の管理	登録メールアドレスは共有メールボックス（配信リスト）を使い、個人退職時の消失を防ぐ	必須
AWS Organizations での凍結	管理アカウントの SCP でメンバーアカウントのルート操作を制限。Organizations 経由でルートセッションを一元管理	推奨
強固なパスワード + ローテーション	パスワードマネージャで管理し、退職時に必ず変更	必須

ルートユーザーでしか実行できない操作は限定的であり、事前に把握しておくことで「ルートログインが必要な瞬間」を最小化できる。

操作	ルート必須	備考
AWS アカウントの解約	はい	IAM ユーザー / ロールでは不可
ルートユーザーの MFA・パスワード変更	はい	自身の認証情報のみ
支払い方法・請求先住所の変更	はい	IAM ユーザーに委任も可能だが初期設定はルート
AWS Support プランの変更	はい	Enterprise → Business への変更等
S3 バケットの MFA Delete 有効化	はい	バケット所有者のルートのみ設定可能
CloudFront キーペアの管理（レガシー）	はい	署名付き URL の信頼された署名者
侵害されたアクセスキーの緊急ロック	状況次第	管理者が対応不能な場合のみ

長期的なクレデンシャル（IAM ユーザーのアクセスキー）は漏洩リスクが高く、現代的な AWS 運用では原則として使用しない。

用途別に以下の選択肢を推奨する。

用途	推奨される選択肢	長期キーの有無	備考
人間（開発者・運用担当）	IAM Identity Center + 外部 IdP（Entra ID / Okta / Google Workspace） → AssumeRole	なし（一時クレデンシャル）	SSO で一元管理。退職時は IdP 側の無効化で即時失効
EC2 上のアプリ	EC2 インスタンスプロファイル（IAM ロール）	なし	IMDSv2 強制とあわせて運用
ECS / Fargate 上のアプリ	タスクロール（taskRoleArn）	なし	コンテナ単位で最小権限を付与
Lambda	Lambda 実行ロール	なし	関数単位で分離する
EKS 上のワークロード	IRSA または EKS Pod Identity	なし	Service Account と IAM ロールを 1:1 で紐付け
外部 CI/CD（GitHub Actions 等）	OIDC フェデレーション + AssumeRoleWithWebIdentity	なし	リポジトリ / ブランチ単位で信頼ポリシーを絞る
オンプレ / 他クラウド	IAM Roles Anywhere または SAML フェデレーション	なし	X.509 証明書ベースの一時クレデンシャル
緊急時ブレークグラス	IAM ユーザー（MFA 必須、長期パスワード、アクセスキーなし）	パスワードのみ	Identity Center 障害時の最終手段。シークレット金庫で厳重管理

すべての選択肢で「STS による一時クレデンシャル」を基本とすることで、静的なシークレットを環境変数や CI の Secret に置く必要がなくなる。

最小権限は IAM の根幹となる考え方だが、実運用では「どこまで絞るか」のバランスが難しい。

以下の設計原則とツールを組み合わせて継続的に磨き込む。

項目	推奨	避けるべき
ポリシーの種類	カスタマー管理ポリシー（再利用可能・バージョン管理可能）	インラインポリシー（ID と一緒に埋もれて棚卸し困難）
起点となるポリシー	AWS 管理ポリシーを参考にカスタマー管理で絞り込む	AWS 管理ポリシーをそのまま本番アタッチ（過剰権限になりがち）
アクション記述	必要な API 単位で列挙（s3:GetObject, s3:PutObject 等）	s3:* や * の多用
リソース記述	ARN で限定（arn:aws:s3:::my-bucket/*）	Resource: "*" の放置
条件句	aws:SourceIp, aws:PrincipalTag, aws:ResourceTag 等で追加制約	条件句なしで信頼するだけ
権限境界	Permission Boundary でロール作成者の権限上限を設定	管理者が無制限にロール・ポリシーを作れる状態
組織レベルのガード	SCP で Organizations 全体の禁止事項（リージョン制限、ルート使用禁止等）を強制	アカウントごとに人手でガードレールを設定

* ワイルドカードの扱いを整理すると以下のようになる。

パターン	使いどころ	避けるべき場所
Action: "*"	開発環境のサンドボックスや Sandbox OU のみ	本番アカウントの通常ロール
Resource: "arn:aws:s3:::logs-*/*"	プレフィックスで論理グループ化したリソース	全バケットを指す "arn:aws:s3:::*" を本番で使用
iam:PassRole の Resource: "*"	ほぼ常に NG	渡せるロールを ARN で限定すべき

設計後は次の仕組みで「使われていない権限」を継続的に棚卸しする。

ツール / 機能	役割
IAM Access Analyzer（未使用アクセス分析）	ロール・ユーザー単位で最終アクセス日を分析し、使われていない権限を特定
IAM Access Analyzer（外部アクセス分析）	S3・KMS・Lambda 等が意図せず外部公開されていないか検出
IAM Access Analyzer（ポリシー生成）	CloudTrail の履歴から「実際に使われた権限」のみを含むポリシーを自動生成
Access Advisor（Last accessed）	サービスレベルで最後にアクセスした日時を表示。大まかな棚卸しに便利
ABAC（タグベースアクセス制御）	PrincipalTag と ResourceTag の一致で認可。多数の環境・チームがある組織で有効

MFA は IAM 侵害の大半を防ぐ単純かつ強力な対策である。

Identity Center と条件付きポリシーを組み合わせて確実に強制する。

強化策	内容	対象
IAM Identity Center の MFA 必須化	認証ソースを Identity Center 内蔵ストアにする場合、MFA を「毎回必須」または「新しいデバイスごとに必須」に設定	SSO 経由の全ユーザー
外部 IdP 側での MFA 強制	Entra ID / Okta の条件付きアクセスで MFA と準拠デバイス要件を付与	外部 IdP を使う全組織
FIDO2 / パスキーの採用	フィッシング耐性のある認証器（YubiKey、Touch ID、Windows Hello 等）を使う	ルート、特権ロール、全管理者
aws:MultiFactorAuthPresent 条件	特権操作（iam:*, kms:ScheduleKeyDeletion 等）を MFA セッション時のみ許可	カスタマー管理ポリシー
aws:MultiFactorAuthAge 条件	直近 N 秒以内に MFA 認証したセッションのみ許可。センシティブ操作を時間制限	特権ロール
セッションの短命化	Identity Center の「セッション期間」を 1〜4 時間に設定。CLI は aws sso login で再取得	開発者・運用ロール

次のような Condition ブロックを特権ポリシーに組み込むと、MFA 未認証のセッションから危険な操作を呼べなくなる。

条件句	効果
"Bool": { "aws:MultiFactorAuthPresent": "true" }	MFA 付きセッションからのみ許可
"NumericLessThan": { "aws:MultiFactorAuthAge": "3600" }	過去 1 時間以内に MFA 認証したセッションのみ許可
"IpAddress": { "aws:SourceIp": ["203.0.113.0/24"] }	許可された IP 範囲からの操作のみ（VPN 前提時）
"StringEquals": { "aws:PrincipalOrgID": "o-xxxxx" }	自組織の Principal のみ許可。クロスアカウント誤用を防ぐ