Organizations 中央集中型 root アクセス管理の導入（SecurityHub CSPM対応）
- Issue: fastdoctor-jp/mental-online-karte#18637
- 親 Issue: fastdoctor-jp/mental-online-karte#18146
- 作成日: 2026-09-08
- ステータス: 方針決定済み・Megazone 確認待ち
背景
Security Hub CSPM で fd-sys / production の root MFA 未設定が検知（IAM.6 / IAM.9）。 AWS ベストプラクティスに従い、メンバーアカウントは root 資格情報を削除、マネジメントアカウントは MFA を設定する方針とした。
対象
メンバーアカウント（root 資格情報削除）
| 環境 | アカウントID | コントロール |
|---|---|---|
| fd-sys | 913831226605 | IAM.6, IAM.9 |
| production | 967691968827 | IAM.6, IAM.9 |
マネジメントアカウント（root MFA 設定）
- 中央集中型 root アクセス管理の対象外のため、MFA 設定で保護する
メンバーアカウントの方針
中央集中型 root アクセス管理
Organizations の中央集中型 root アクセス管理を有効化し、メンバーアカウントの root 資格情報（パスワード・アクセスキー・署名証明書・MFA）を一括削除する。
- 削除後、メンバーアカウントの root ログイン・パスワードリカバリは不可になる
- 特権タスクが必要な場合はマネジメントアカウントから
sts:AssumeRootで短期セッションを取得して実行 - root でしか実行できないタスク（後述）が必要な場合は、マネジメントアカウントから「Allow password recovery」で一時復旧が可能
root でしか実行できないタスク（sts:AssumeRoot では代替不可）
以下のタスクは sts:AssumeRoot では実行できず、root ログインが必要。 必要な場合はマネジメントアカウントから「Allow password recovery」で一時復旧 → 作業完了後に再度資格情報を削除する。
Note: S3 バケットポリシー・SQS ポリシーの誤設定修正は
sts:AssumeRootで対応可能なため、root ログイン不要。
| カテゴリ | タスク | 備考 | FD での発生頻度 |
|---|---|---|---|
| アカウント管理 | root メールアドレス・パスワード・アクセスキーの変更 | アカウント名・連絡先等はマネジメントアカウントから変更可能 | 極めて低い |
| アカウント管理 | IAM 管理者の権限復旧 | 唯一の管理者が自身の権限を誤削除した場合 | 極めて低い |
| Billing | Billing コンソールへの IAM アクセス有効化 | 設定済み（対応不要） | — |
| Billing | 一部の税務請求書の閲覧 | AWS Inc. / AISPL の請求書 | 低い |
| EC2 | Reserved Instance Marketplace への出品登録 | RI 売却時のみ | 極めて低い |
| S3 | S3 バケットの MFA Delete 設定 | 未使用（SCP で root アクセスキー作成禁止中。中央集中型 root アクセス管理 導入後に再検討） | — |
| KMS | 管理不能になった KMS キーの復旧 | AWS Support + root 電話番号で本人確認 | 極めて低い |
| その他 | GovCloud サインアップ / Mechanical Turk 連携 | FD では該当しない | — |
いずれも低頻度のため、「Allow password recovery」による一時復旧運用で問題ない。
sts:AssumeRoot で実行できる特権タスク
| タスクポリシー | できること |
|---|---|
IAMDeleteRootUserCredentials | root 資格情報の削除 |
IAMCreateRootUserPassword | root パスワードリカバリの許可 |
IAMAuditRootUserCredentials | root 資格情報の状態確認 |
S3UnlockBucketPolicy | 誤設定された S3 バケットポリシーの削除 |
SQSUnlockQueuePolicy | 誤設定された SQS キューポリシーの削除 |
前提条件
有効化を実行するアカウント（マネジメントアカウント or 委任管理者）に以下の IAM 権限が必要：
iam:EnableOrganizationsRootCredentialsManagementiam:EnableOrganizationsRootSessionsiam:ListOrganizationsFeaturesorganizations:EnableAwsServiceAccessorganizations:ListAccountsForParentsts:AssumeRoot
資格情報削除時は追加で以下が必要：
iam:GetAccountSummaryiam:GetLoginProfileiam:ListAccessKeysiam:ListMFADevicesiam:ListSigningCertificatesiam:DeleteLoginProfileiam:DeleteAccessKeyiam:DeleteSigningCertificateiam:DeactivateMFADevice
委任管理者
| 項目 | 値 |
|---|---|
| 委任管理者アカウント | security-tooling（860801568046） |
メンバーアカウントの root メールアドレス
- SRE チームのメーリングリストが設定されており、自社で受信可能
- 「Allow password recovery」実行時のパスワードリセットメールも SRE チームで受信できる（確認済み）
手順
bash
# 1. Trusted Access 有効化
aws organizations enable-aws-service-access \
--service-principal iam.amazonaws.com
# 2. Root credentials management 有効化
aws iam enable-organizations-root-credentials-management
# 3. Privileged root sessions 有効化
aws iam enable-organizations-root-sessions
# 4. 委任管理者の登録
aws organizations register-delegated-administrator \
--service-principal iam.amazonaws.com \
--account-id 860801568046
# 5. メンバーアカウントの root 資格情報削除
# IAM コンソール → Root access management → 対象アカウント選択
# → Take privileged action → Delete root credentialsマネジメントアカウントの MFA 方針
AWS ベストプラクティス（理想形）
AWS Well-Architected Framework（SEC01-BP02）および root ユーザーベストプラクティスでは、以下を推奨している：
| 推奨事項 | 内容 |
|---|---|
| ハードウェア MFA | FIDO2 セキュリティキーまたはハードウェア TOTP トークンを使用。秘密鍵がデバイスの外に出ないため漏洩リスクが最も低い |
| 複数 MFA デバイス登録 | 最大8台まで登録可能。紛失・故障時のバックアップとして推奨 |
| Two-person rule | パスワード管理者と MFA 管理者を分離し、1人では root にログインできないようにする |
| グループメールアドレス | root メールアドレスに個人メールではなく DL を使用 |
| パスワードの安全な保管 | AWS アカウントに依存しない場所に保管（循環依存の回避） |
| root ログインの監視 | GuardDuty / CloudWatch で root 使用を検知・通知 |
当環境の課題とベストプラクティスからの逸脱
AWS ベストプラクティスをそのまま適用できない課題があるため、リスクを許容した上で代替策を採用する。
| ベストプラクティス | 当環境の課題 | 採用した代替策 | 残存リスクと緩和策 |
|---|---|---|---|
| ハードウェア MFA | 物理デバイス管理が人に依存。退職・異動・不在時に使えなくなる | 仮想 MFA（TOTP）+ GCP Secret Manager で管理 | シード漏洩リスク → GCP IAM でアクセス制御 + 監査ログで検知 |
| 複数 MFA デバイス登録 | 2台以上登録するとメール+電話による MFA リカバリが無効化される | MFA 1台のみ登録し、リカバリ経路を残す | GCP 障害時に MFA 取得不可 → メール+電話で代替認証（Megazone 協力要） |
| Two-person rule | 人に依存。少人数チームでは緊急時に2人集まれない | 不採用（単独操作可能） | 1人で root ログイン可能 → GuardDuty / CloudWatch で使用を検知・通知 |
| SaaS パスワードマネージャ | 新規契約が必要 | GCP Secret Manager（既存環境活用） | — |
| root メールアドレスを DL に変更 | Megazone（代理店）の情報が設定されており変更不可 | 変更せず、Megazone と復旧フローを合意 | 代替認証時に Megazone の協力が必要 |
採用方針: GCP Secret Manager + oathtool
上記の課題を踏まえ、GCP Secret Manager に TOTP シードを保管し、oathtool で OTP を生成する方式を採用する。
検討した全案の比較
| 案 | メンバー非依存 | AWS障害耐性 | 新規契約不要 | コスト | セキュリティ | 不採用理由 |
|---|---|---|---|---|---|---|
| GCP Secret Manager + oathtool | ✅ | ✅ | ✅ | 無料 | ◎ IAM + 監査ログ | — 採用 |
| SaaS パスワードマネージャ | ✅ | ✅ | ❌ | 有料 | ◎ | 新規契約の手続きコストと継続費用が限定用途に対して過剰 |
| FIDO2 ハードウェアキー | ❌ | ✅ | ✅ | 数千円 | ◎ 最高 | 物理デバイス管理が人に依存。リモートワーク時に使えない |
| 個人端末 Authenticator | ❌ | ✅ | ✅ | 無料 | △ | 個人端末に紐づくため、退職・紛失で使用不可 |
| 印刷して金庫保管 | ✅ | ✅ | ✅ | 無料 | ○ | 物理アクセス必須。緊急時にリモートから対応不可 |
| マネジメント EC2 | ✅ | ❌ | ✅ | EC2常時起動 | △ | 循環依存（root ログイン不可 → EC2 アクセス不可 → MFA 取得不可） |
| メンバー EC2 | ✅ | ❌ | ✅ | EC2常時起動 | △ | AWS 障害時に EC2 も影響。root が最も必要な障害時に使えない |
| 自前パスワードマネージャ | ✅ | 構築先次第 | ✅ | 開発コスト | △ | セキュリティ品質が自前実装に依存。限定用途に対して過剰 |
GCP Secret Manager + oathtool の詳細
仕組み
AWS で root の MFA 設定時に TOTP シード（秘密鍵）が発行される
→ シードを GCP Secret Manager に保存
→ root ログイン時に oathtool で OTP を生成して入力
通常の Authenticator アプリと同じ仕組み。保管場所と OTP 生成ツールが異なるだけ。コスト
| 項目 | 料金 |
|---|---|
| GCP Secret Manager シークレット保管 | 無料（6個まで） |
| アクセス（読み取り） | 10,000回まで無料 |
| oathtool | 無料（OSS: brew install oath-toolkit） |
実質コストゼロ。
運用フロー
bash
# root ログイン時に OTP を生成（コマンド1行）
oathtool --totp -b $(gcloud secrets versions access latest \
--secret=<シークレット名> \
--project=<GCPプロジェクト>)MFA リカバリ（MFA が使えなくなった場合）
| 状況 | 復旧方法 |
|---|---|
| GCP Secret Manager にアクセスできない | root メールアドレス + 登録電話番号で AWS の代替認証フロー（Megazone の協力が必要） |
| AWS の代替認証もダメ | AWS Support に連絡して MFA を無効化 |
Note: 代替認証フローを残すため MFA デバイスは 1台のみ 登録する（2台以上だとこのフローが無効化される）。復旧フローについては Megazone への確認時に合意しておくこと。
マネジメントアカウント root の MFA 初期設定手順
- マネジメントアカウントに root でコンソールログイン
- セキュリティ認証情報 → MFA デバイスの割り当て → 仮想 MFA デバイスを選択
- QR コード画面で「シークレットキーを表示」→ TOTP シード（テキスト）を取得
- シードを GCP Secret Manager に保存
oathtoolで OTP を2回生成（30秒間隔）して MFA を有効化- ローカルのシードファイルを削除
本番環境の GCP プロジェクト・アクセス制御
MFA シード管理専用の GCP プロジェクトを新規作成する。権限管理を既存プロジェクトと分離し、アクセスできる人を厳密に制限するため。
| 項目 | 内容 |
|---|---|
| GCP プロジェクト | 専用プロジェクトを新規作成（MFA シード管理用） |
| アクセス権限 | SRE チームの必要メンバーに roles/secretmanager.secretAccessor を付与 |
| 監査ログ | GCP Cloud Audit Logs でシークレットへのアクセスを記録（デフォルト有効） |
セットアップ手順の自動化
oathtool のインストールや GCP プロジェクトの認証設定など、各メンバーの初期セットアップを効率化するためのスキル（Claude Code skill）を別途作成する。
root ログインの監視
root ログインが発生した場合に検知できるよう、以下のいずれかを設定する：
- GuardDuty:
Policy:IAMUser/RootCredentialUsageで root 使用を検知（既に有効化済みなら追加設定不要） - CloudWatch Events: root ログインイベントを検知して SNS 通知
検証結果
検証環境
| 項目 | 値 |
|---|---|
| AWS アカウント | infra-dev（853790572692） |
| GCP プロジェクト | fdt-sre-dev |
検証手順と結果
| # | 手順 | 結果 |
|---|---|---|
| 1 | oathtool インストール（brew install oath-toolkit） | ✅ 成功 |
| 2 | テスト用 IAM ユーザー mfa-test-user を作成 | ✅ 成功 |
| 3 | 仮想 MFA デバイスを作成し TOTP シード（Base32）を取得 | ✅ 成功 |
| 4 | oathtool で OTP を生成し MFA を有効化 | ✅ 成功 |
| 5 | GCP Secret Manager にシードを保存 | ✅ 成功 |
| 6 | GCP Secret Manager からシードを取得して oathtool で OTP 生成 | ✅ 成功 |
| 7 | 生成した OTP で AWS コンソールにログイン | ✅ 成功（MFA 認証通過を確認） |
| 8 | テストリソースの後片付け | ✅ 完了 |
結論
GCP Secret Manager + oathtool で AWS の MFA 認証が正常に動作することを確認した。
Megazone への確認事項
マネジメントアカウントの root 連絡先情報が Megazone（代理店）の情報になっている。
確認すべきこと
「マネジメントアカウントの root ユーザーに自社で MFA を設定・管理してよいか」
- OK → 自社で MFA 設定を実施
- NG → Megazone に MFA 設定を依頼
※ root メールアドレス・電話番号は Megazone のまま変更しない方針