Organizations 中央集中型 root アクセス管理 設計書
1. 概要
1.1 本ドキュメントの位置付け
本ドキュメントは、AWS Organizations の中央集中型 root アクセス管理の導入に伴う設計書である。 方針決定に至る比較検討は 比較検討資料 を参照。 運用手順は 運用手順書 を参照。
1.2 背景
Security Hub CSPM で fd-sys / production の root MFA 未設定が検知された（IAM.6 / IAM.9）。 AWS ベストプラクティスに従い、メンバーアカウントは root 資格情報を削除、マネジメントアカウントは MFA を設定する方針とした。
1.3 参照ドキュメント
2. 構成
2.1 アカウント構成
| 役割 | アカウント | ID |
|---|---|---|
| マネジメントアカウント | awscloud.jp43 | 703480710002 |
| 委任管理者（IAM） | fd-security-tooling | 860801568046 |
| メンバーアカウント | 全 ACTIVE アカウント（15アカウント） | — |
Note: 中央集中型 root アクセス管理を有効化した後に新規作成されるメンバーアカウントは、デフォルトで root 資格情報が存在しない状態で作成される。追加の対応は不要。
2.2 メンバーアカウントの root アクセス
通常時:
security-tooling → sts:AssumeRoot → 短期セッション（最大15分）
→ S3/SQS ポリシー修正等の特権タスクを実行
root ログインが必要な場合:
security-tooling → Allow password recovery
→ root メールアドレス宛にパスワードリセット
→ root ログイン → 作業 → root 資格情報を再削除2.3 マネジメントアカウントのアクセス
マネジメントアカウントの root ユーザーは Megazone（代理店）が管理しており、自社では直接利用しない。 自社では Megazone が払い出した特権 IAM ユーザー mz-fastdoctor-admin を使用してマネジメントアカウントを操作する。
mz-fastdoctor-admin ログイン時:
パスワード + MFA（GCP Secret Manager からシード取得 → oathtool で OTP 生成）3. マネジメントアカウント MFA 設計
3.1 前提
マネジメントアカウントの root ユーザーは Megazone（代理店）が管理している。 自社では Megazone が払い出した特権 IAM ユーザー mz-fastdoctor-admin を使用しており、このユーザーに MFA を設定する。
3.2 方式
GCP Secret Manager に TOTP シードを保管し、oathtool で OTP を生成する方式を採用。
採用理由と代替案の比較は 比較検討資料 を参照。
3.3 AWS ベストプラクティスからの逸脱と緩和策
| ベストプラクティス | 逸脱内容 | 緩和策 |
|---|---|---|
| ハードウェア MFA | 仮想 MFA（TOTP）を使用 | GCP IAM でアクセス制御 + Cloud Audit Logs で監査 |
| 複数 MFA デバイス登録 | 1台のみ登録 | メール+電話による代替認証フローを維持 |
| Two-person rule | 不採用（単独操作可能） | ログイン検知・通知で補完（今後実装検討） |
3.4 ログイン検知・通知（今後実装検討）
マネジメントアカウントへのログインが発生した場合に即時通知し、事後監査を行う仕組みを今後実装予定。
| 検知方法 | 内容 | 状態 |
|---|---|---|
| GuardDuty | Policy:IAMUser/RootCredentialUsage で root 使用を検知 | 検討中 |
| CloudWatch Events | root ログインイベントを検知して SNS / Slack 通知 | 検討中 |
事後報告フロー（実装後）:
- ログイン発生時、Slack 通知を受けた担当者は 24 時間以内にログイン理由を Slack に報告する
- 四半期ごとに監査ログをレビューする
3.5 MFA リカバリフロー
| 状況 | 復旧方法 | 担当 |
|---|---|---|
| GCP 認証切れ | gcloud auth login を再実行 | SRE |
| GCP Secret Manager にアクセスできない（GCP 障害等） | Megazone に連絡し、mz-fastdoctor-admin の MFA リセットを依頼 | SRE + Megazone |
Note: MFA デバイスは 1台のみ 登録する。
4. GCP Secret Manager 設計
4.1 プロジェクト
MFA シード管理専用の GCP プロジェクトを使用する。
| 項目 | 値 |
|---|---|
| プロジェクト ID | fd-secrets-management |
| 用途 | MFA シード管理（将来的に他のシークレットも格納可能） |
4.2 アクセス制御
| ロール | 対象 | 用途 |
|---|---|---|
roles/owner | fdt-sre@fastdoctor.jp | プロジェクト管理 |
roles/secretmanager.secretAccessor | SRE チームの必要メンバー | シークレット読み取り |
権限管理基準:
- 付与対象: SRE チームメンバー
- 付与・削除:
fdt-sre@fastdoctor.jp（SRE メーリングリスト）に追加されれば自動的に権限が付与される。退職・異動時はメーリングリストから削除されるため即時権限削除となる
4.3 監査ログ
| 設定 | 値 |
|---|---|
| 管理読み取り | 有効 |
| データ書き込み | 有効 |
Cloud Audit Logs でシークレットへのアクセスを記録。デフォルトで有効。
4.4 VPC Service Controls
不採用。理由: SRE メンバーがリモートで緊急時に root ログインする際に IP 制限でアクセスできなくなるリスクがある。GCP IAM + Cloud Audit Logs で十分なセキュリティを確保する。
5. ロールバック計画
5.1 中央集中型 root アクセス管理の無効化
必要に応じて機能を無効化し、メンバーアカウントの root 資格情報を復旧できる。
# 1. メンバーアカウントの root パスワードリカバリを許可
# IAM コンソール → Root access management → 対象アカウント → Allow password recovery
# 2. 中央集中型管理を無効化（必要な場合）
aws iam disable-organizations-root-credentials-management
aws iam disable-organizations-root-sessions5.2 mz-fastdoctor-admin MFA のリセット
GCP Secret Manager のシードが使用不可になった場合:
- Megazone に連絡し、
mz-fastdoctor-adminの MFA リセットを依頼 - MFA なしでログインし、新しい MFA デバイスを設定
- 新しいシードを GCP Secret Manager に保存
6. 関連 SCP
| SCP | 内容 | 変更要否 |
|---|---|---|
| root アクセスキー作成禁止 | iam:CreateAccessKey を root に対して Deny | 変更不要（中央集中型管理と共存可能） |
Note: 中央集中型管理の有効化により、メンバーアカウントの root 資格情報は削除済みのため、SCP による root 操作制限は引き続き有効だが、実質的に root ログイン自体が不可。