AWS Organizations OU・アカウント設計書
用語補足: 本ドキュメントで「マネジメントアカウント」とは、AWS Organizationsを作成したアカウント（awscloud.jp43: 703480710002）を指す。一般的に「ルートアカウント」「親アカウント」とも呼ばれるが、AWS公式用語では「マネジメントアカウント（Management Account）」が正式名称。なお「ルートユーザー」（各アカウントの最高権限ユーザー）とは別の概念。
1. 設計方針
目的
本設計書は、既存のフラットなOrganization構造を、ベストプラクティスに沿ったOU・アカウント・SCP構成に移行するための設計を定義する。
| 目的 | 内容 |
|---|---|
| セキュリティ境界の確立 | アカウント分離により爆発半径（blast radius）を限定する。本番データ（医療情報）を構造的に保護する |
| 役割分離と権限委任 | マネジメントアカウントの役割を最小化し、セキュリティサービスの管理を委任管理者に委任する。管理者ごとの責任範囲を明確にする |
| 多層防御（Defense in Depth） | SCPで組織全体のガードレール（大枠の制限）を設け、IAM権限セットで多層防御を構築する |
| ガバナンスの一元化 | セキュリティサービス（CloudTrail, GuardDuty, Security Hub等）を委任管理者から一元管理し、設定漏れ・入れ忘れをなくす |
| 監査・コンプライアンス対応 | 監査ログ（CloudTrail）を改ざん不能な別アカウントに集約する。3省2ガイドラインの技術的安全管理措置をOU境界で実現する |
設計原則
- セキュリティ・運用上のニーズに基づいてOU構造を設計する（社内組織構造ではなく）
- マネジメントアカウントにはリソースを置かない
- 可能な限り Delegated Admin で委任し、マネジメントアカウントへのアクセスを最小化する
- SCPはOU単位で適用し、Sandbox OUで事前検証する
- 恒久的な設定はTerraform管理を推奨する
2. OU構造
設計
Root (r-8z8v)
│
├── Security OU
│ ├── fd-security-tooling ← 新規作成（委任管理者）
│ └── fd-log-archive ← 新規作成（監査ログ集約専用）
│
├── Infrastructure OU
│ └── p82516-220328 (770217130318) ← 踏み台・共通基盤
│
├── Workloads OU
│ ├── Production OU ← 現在は Tier-1 のみ（※1）
│ │ ├── fd-aws-production (967691968827) ← Tier-1（医療情報）
│ │ ├── p82516-220386 / fd-sys (913831226605) ← Tier-1（Amazon Connect）
│ │ └── ctop-production / RDIP (324454774785)
│ │
│ └── Non-Production OU
│ ├── fd-aws-staging (301608970378)
│ ├── ctop-staging / RDIP (323155024650)
│ ├── p82516-220391 / fd-dev (900176301532)
│ └── poc-cloud-clinic (499591337329)
│
├── Sandbox OU
│ └── fd-infra-dev (853790572692) ← SCPの事前検証用途を兼務
│
├── Suspended OU
│ └── hospital-ai-poc (378589999200) ← 閉鎖済み
│
└── Root直下（移動しない）
├── awscloud.jp43 (703480710002) ← マネジメント（移動不可）
├── aws.jp.mz+fd-support-2 (211125417886) ← MZポータル管理
└── aws.jp.mz+fd-support-3 (866741171210) ← 外部連携（external-relation）※本番データを扱うか未確認のため保留※1 Production OUのTier別分離については「2.2 Production OUのTier別分離（将来）」を参照。
各OUの役割
| OU | 目的 | SCP方針 |
|---|---|---|
| Security | セキュリティサービスの委任管理、監査ログ集約 | 厳格（ログ削除禁止等） |
| Infrastructure | 共通基盤（VPN, Route53, Bastion, SSM） | 中程度 |
| Workloads / Production | 本番ワークロード（現在はTier-1のみ） | 厳格（リージョン制限、セキュリティサービス保護） |
| Workloads / Non-Production | 開発・ステージング・PoC | 中程度（Production OUに準拠、一部緩和） |
| Sandbox | インフラ検証・SCPの事前テスト | Non-Productionと同等のSCPを適用。SCPテスト時に新SCPを追加して検証 |
| Suspended | 閉鎖済み・停止アカウント | 全Deny |
Sandbox OUの運用
fd-infra-dev を Sandbox OU に配置し、SCPの事前検証用途を兼務する。
SCPテスト手順:
1. テスト対象のSCPを Sandbox OU に適用
2. fd-infra-dev で動作確認
・制限対象のアクションが拒否されること
・通常操作（EC2, S3, ECS等）に影響がないこと
3. 検証OK → 本番OUに適用
4. Sandbox OU のテスト用SCPを削除（元のSCP構成に戻す）
通常時:
・Non-Production OUと同等のSCPを適用
・インフラ検証環境として通常利用
Policy Staging OUを別途作成しない理由:
・AWS推奨OUにPolicy Staging OUがあるが、常に空のOUを維持する意味が薄い
・Sandbox OU（fd-infra-dev）で実ワークロードに対してSCPテストできる方が実用的
・OU数を減らすことで構造をシンプルに保てる
・SCPの追加頻度が高くなった場合は専用OUの作成を再検討する2.2 アカウントのOU間移動
OU間の移動はコンソールまたはCLIでいつでも可能。
移動方法:
コンソール: Organizations → 対象アカウントにチェック → アクション → 移動 → 移動先OU選択
CLI: aws organizations move-account --account-id <ID> --source-parent-id <元OU> --destination-parent-id <先OU>注意事項:
移動した瞬間にSCPの適用が変わる:
・移動元OUのSCPが外れる
・移動先OUのSCPが適用される
→ サービスが使えなくなる可能性がある
現在の設計での安全性:
・既存SCP（ECAM_Partnerled_base_policy）はRootに適用 → 全OUに適用されるため移動しても変わらない
・新規SCP（セキュリティ保護、LeaveOrg禁止）もRootに適用 → 同上
・リージョン制限SCPはWorkloads/Infrastructure/Sandboxに適用 → これらのOU間の移動は影響なし
・Suspended OUに全Deny SCPがあるため、誤ってSuspendedに移動すると全操作が拒否される
移動を検討するケース:
・Tier-2アカウント作成時にProduction OUをTier別に分離する場合
・アカウントの用途が変わった場合（開発→本番昇格等）
・OU設計の見直し時
OU設計を完璧にしてから始める必要はない。
まず配置して、合わなければ後から移動すればよい。2.3 OUネストとSCPの複雑化に関する注意
OUをネストすると、アカウントに適用されるSCPはRoot〜そのアカウントまでの
全階層のSCPのAND条件になる。
ネストが深いほど「このアカウントに結局どのSCPが効いているか」が把握しにくくなる。
例: Root > Workloads > Production > Tier-1 > fd-aws-production の場合
効くSCP = ①Root + ②Workloads + ③Production + ④Tier-1 + ⑤アカウント直接
→ 5階層分のSCPを全部読まないと何ができるかわからない
→ どこか1つでもDenyされていたら、他でAllowしても効かない
推奨:
・OUネストは浅く保つ（2〜3階層が理想）
・AWSの上限は5階層（これを超えるネストは不可）
・今の設計は最大3階層（Root > Workloads > Production）なので問題なし
・Tier別分離しても4階層で上限に余裕あり
ネストが深くなると起きる問題:
・SCPのデバッグが困難（どの階層のDenyで止まっているか特定しにくい）
・OU間移動時に複数階層のSCPが同時に変わり影響が予測しにくい
・チームメンバーの理解コストが上がる2.4 Production OUのTier別分離（将来）
現状:
Production OUには Tier-1（医療情報）のアカウントのみが存在する。
Tier-2 アカウントは未作成のため、OU分離は不要。
Tier-2アカウント作成時に検討すべきOU構成:
Workloads OU
├── Production OU
│ ├── Tier-1 OU ← 医療情報（PHI）を扱うアカウント
│ │ ├── fd-aws-production
│ │ └── fd-sys
│ │
│ └── Tier-2 OU ← 機微な個人情報を扱うアカウント
│ └── （新規Tier-2アカウント）
│
└── Non-Production OU
└── ...
Tier別OU分離の目的:
・Tier間のアクセス制限をSCPで構造的に強制する
例: Tier-2 → Tier-1 のリソースへの直接アクセスをDeny
・監査スコープをTier単位で限定する
・3省2ガイドライン「技術的安全管理措置」をOU境界で実現する
分離時に追加するSCP:
・Tier-2 OU: Tier-1アカウントのリソースへのクロスアカウントアクセスをDeny
・Tier-1 OU: 必要に応じてTier-2からの参照を条件付き許可
判断基準:
・Tier-2アカウントを作成するタイミングで分離を実施
・それまでは現在のProduction OU（Tier-1のみ）で運用3. アカウント設計
新規作成アカウント
fd-security-tooling（委任管理者）
アカウント名: fd-security-tooling
メール: fdt-sre+security-tooling@fastdoctor.jp
配置先: Security OU
用途: セキュリティサービスの委任管理者
委任するサービス:
・CloudTrail → 組織トレイルの管理
・GuardDuty → 脅威検出の組織統合
・Security Hub → セキュリティスコアの組織統合
・Health → 組織ヘルスビュー
・Config → 構成管理
・Inspector → 脆弱性スキャン
・IAM Identity Center → SSO管理（※1）
・IAM（Root Access Management） → Centralized Root Access
・Macie / Detective / Access Analyzer
Terraform管理:
・新規ディレクトリ作成が必要
・恒久的なセキュリティ設定はTerraformで管理推奨
※1 IAM Identity Centerについて:
ID管理は情シスが関与する領域であるため、セキュリティサービスの管理と
同一アカウント（fd-security-tooling）に置くべきか要検討。
情シスの管理範囲・責任分界によっては、Identity Center専用のアカウントを
作成し、Security OUまたは専用OUに分離する可能性がある。
導入検討時に情シスと協議して決定する。fd-log-archive（ログ集約）
アカウント名: fd-log-archive
メール: fdt-sre+log-archive@fastdoctor.jp
配置先: Security OU
用途: 監査ログを集約するストレージ専用アカウント
目的:
・「ログを出した本人がログを消せない」状態を作る
・攻撃者がアカウントに侵入しても、監査ログはLog Archiveにあるため
「いつ、誰が、何をしたか」の証跡が残る
・監査ログが消されると侵入の痕跡が消えるため、
ログの保存場所とログを出す場所を分離することが重要
集約対象（監査ログ）:
・CloudTrail 組織トレイルのログ
・Config ログ
集約しないもの（運用ログ → 各アカウントで管理）:
・ALBアクセスログ / VPC Flow Logs / WAFログ / アプリケーションログ等
・理由:
- 運用・トラブルシューティング用のログは手元（各アカウント）にある方が実用的
- 改ざん防止は各アカウントのS3バージョニング/Object Lockで対応可能
- 万一運用ログが消されても、監査ログ（CloudTrail）で「誰が消したか」を追跡可能
- ログ量が膨大（特にFlow Logs）で集約するとコスト増
※ コンプライアンス要件で一元管理が必要になった場合は別途検討
アクセス制御:
・このアカウントへの書き込みはCloudTrailサービス（+ Config）のみ
・読み取りはSecurity Toolingアカウントのみ
・ログの削除・変更は原則禁止
・人間がLog Archiveにログインしてログを操作することは原則ない既存アカウントの分類
| アカウントID | 現在の名前 | 実際の用途 | 配置先OU | Terraform管理 | セキュリティサービス状態 |
|---|---|---|---|---|---|
| 703480710002 | awscloud.jp43 | マネジメント | Root（移動不可） | — | CloudTrail ✅(※1), 他は未確認 |
| 967691968827 | fd-aws-production | FDメイン本番 | Production | production/ | ほぼ全部 ✅（Security Hub以外） |
| 913831226605 | p82516-220386 | fd-sys / Amazon Connect本番 | Production | amazon-connect/ | ほぼ全部 ✅（Security Hub以外） |
| 324454774785 | ctop-production | ctop(RDIP)本番（※2） | Production | rdip-production/ | ⚠️ Macie/AA以外なし |
| 301608970378 | fd-aws-staging | FDステージング | Non-Production | staging/ | ほぼ全部 ✅（Security Hub以外） |
| 323155024650 | ctop-staging | ctop(RDIP)ステージング（※2） | Non-Production | rdip-staging/ | ⚠️ Macie/AA以外なし |
| 900176301532 | p82516-220391 | fd-dev / FD開発 | Non-Production | develop/ | ほぼ全部 ✅（Security Hub, Inspector以外） |
| 499591337329 | poc-cloud-clinic | PoC | Non-Production | cc-poc/ | ⚠️ 全サービスなし |
| 853790572692 | fd-infra-dev | インフラ検証・SCPテスト | Sandbox | infra-dev/ | ほぼ全部 ✅（Security Hub以外） |
| 770217130318 | p82516-220328 | 踏み台・共通基盤 | Infrastructure | integration/ | グループA（Security Hub, Inspector, Macie以外 ✅） |
| 378589999200 | hospital-ai-poc | PoC（閉鎖済み） | Suspended | hospital-ai/（削除候補） | — |
| 211125417886 | aws.jp.mz+fd-support-2 | MZサポート | Root直下 | — | 未調査 |
| 866741171210 | aws.jp.mz+fd-support-3 | 外部連携（external-relation） | Root直下 | external-relation/ | ほぼ全部 ✅（Security Hub以外） |
※1: 2026-05-20にPhase 1で個別トレイルを手動作成
※2 ctop系アカウントについて: ・SREで管理できておらず、別部署が外部委託先で運用している ・構成・管理状況の詳細が不明 ・CloudTrail/GuardDuty/Config等のセキュリティサービスが未導入 → 組織統合で自動的にカバーされる ・現時点ではFD系アカウントと同じOU（Production / Non-Production）に配置する → 適用すべきSCPに差がないため、OU分離の理由がない ・以下の場合にOU分離を再検討する: - ctop系に異なるSCPを適用する必要が出た場合 - セキュリティ要件がFD系と大きく異なることが判明した場合 - 委託先に対してOUレベルで権限を制限する必要がある場合 ・データの機密性レベル（Tier分類）も不明 → Tier-1（医療情報）相当のデータを扱っている可能性があるが未確認 → 将来Production OUをTier別に分離する際に、ctop系の分類も確認が必要 ・CloudTrail/GuardDuty等の組織統合はサービスに影響がないため、そのまま適用してよい ・SCP等サービスに影響がある設定を適用する際にctop担当者とコミュニケーションを取る ・問題や異なるSCPを適用したい要件が発生した場合にOU分離を検討する
4. SCP設計
本セクションは概要レベルの方針と設定例を示すものであり、JSON定義・NotActionリスト・Condition等の実装詳細は実施時に別途設計する。
SCP適用マトリクス
| SCP | 適用先 | 影響範囲 |
|---|---|---|
| FullAWSAccess（既存） | Root | 全アカウント |
| ECAM_Partnerled_base_policy（既存） | Root | 全アカウント |
| SCP① セキュリティ保護（新規） | Root | 全アカウント |
| SCP③ LeaveOrg禁止（新規） | Root | 全アカウント |
| SCP② リージョン制限（新規） | Infrastructure, Production, Non-Production, Sandbox | ワークロード系全体（Security OUは除外） |
| SCP④ 全Deny（新規） | Suspended | 閉鎖済みアカウントのみ |
| SCP⑤ 本番データ保護（新規） | Production | 本番アカウントのみ |
Rootに適用 = 全メンバーアカウントに継承（マネジメントアカウントには効かない） Security OUにリージョン制限を適用しない理由: セキュリティサービスが複数リージョンで動作するため
新規SCP
| SCP | 適用先 | 目的 | 方針例 |
|---|---|---|---|
| SCP① | Root | セキュリティ基盤の保護 | CloudTrail/GuardDuty/Security Hub の無効化・削除を拒否。メンバーアカウントのrootによるアクセスキー作成を拒否。Config/Inspector等の導入時にアクションを追加 |
| SCP② | Infrastructure, Production, Non-Production, Sandbox | リージョン制限 | 許可リージョン（ap-northeast-1, us-east-1, us-west-2, ap-northeast-3）以外でのリソース作成を拒否。グローバルサービス（IAM, CloudFront, Route53等）は除外。Security OUには適用しない（セキュリティサービスが複数リージョンで動作するため） |
| SCP③ | Root | Organization離脱禁止 | organizations:LeaveOrganization を無条件Deny。既存SCPではrootが除外されているため補完として追加 |
| SCP④ | Suspended | 閉鎖済みアカウントの封鎖 | 全アクションを拒否 |
| SCP⑤ | Production | 本番データ保護 | 下記「Production OU固有のデータ保護方針」を参照 |
JSON定義等の実装詳細は実施時に別途設計する。 SCPは「APIコール（操作）」を制限するもので、既存リソースには影響しない。ただし新規作成・スケールアウト・障害復旧時に拒否される可能性があるため、Sandbox OUで事前検証すること。 Rootに適用するSCP（①③）はMegazone管理のアカウント（MZサポート、外部連携）にも影響する。適用前にMZとコミュニケーションを取り、MZ側の運用に支障がないことを確認すること。
Production OU固有のデータ保護方針（SCP⑤）
Production OUには Tier-1（医療情報）を含む本番アカウントが配置されるため、データ保護を目的としたSCPを適用する。SCPまたはDeclarative Policyのどちらで実装するかは実施時に判断する。
| 保護対象 | 方針 |
|---|---|
| S3パブリックアクセス | パブリックアクセスブロック設定の変更を禁止。本番データの意図しない公開を防止 |
| S3外部転送 | レプリケーション先をOrganization内に限定。本番データの外部アカウントへの持ち出しを防止 |
| RDS/Auroraスナップショット | スナップショットのパブリック共有を禁止。本番DBの流出を防止 |
| EBSスナップショット | スナップショットのパブリック共有を禁止 |
| AMI | パブリック共有を禁止。本番EC2イメージの外部共有を防止 |
3省2ガイドライン「技術的安全管理措置」およびアカウント分離ガイドラインのデータ保護要件に対応する。
将来検討するSCP
以下は既存ワークロードへの影響確認が必要なため、段階的に検討・追加する。
| SCP | 目的 | 注意事項 |
|---|---|---|
| S3パブリックアクセス禁止（全OU） | Production以外のOUにも適用を拡大する場合 | 公開が必要なバケットがないか確認 |
| rootユーザーMFA強制 | MFAなしでのrootユーザー操作を拒否 | MFA設定を管理可能なSaaS（パスワードマネージャー等）の導入が前提。導入でき次第検討 |
| rootユーザー操作制限 | メンバーアカウントのrootの全操作を制限 | Centralized Root Access導入後は不要 |
| デフォルトVPC制限 | デフォルトVPCでのリソース作成を禁止 | fd-sys(913831226605)がデフォルトVPCを使用中。適用不可 |
| IMDSv2強制 | EC2メタデータをv2に限定。SSRF攻撃対策 | Declarative Policyでも対応可能。既存EC2への影響確認が必要 |
| EBS/RDS暗号化強制 | 暗号化なしのボリューム/DB作成を禁止 | 既存の暗号化なしリソースの有無を確認 |
| CloudTrail設定変更禁止（拡充） | UpdateTrail等の追加制限 | 運用上の設定変更が必要な場合の除外条件を検討 |
5. 実施手順
詳細な実施手順、依存関係、操作者の分担は別途ロードマップを参照。
Terraform管理方針
| 対象 | Terraform管理 | 理由 |
|---|---|---|
| OU作成 | しない | 1回限りの操作。変更頻度が極めて低い |
| アカウント作成 | しない | 1回限りの操作。terraform destroyで事故的に削除されるリスクがある |
| アカウントのOU間移動 | できない | Terraform未対応（API直接のみ） |
| SCP | する（推奨） | 変更・追加が継続的に発生する。コードレビューを経てから適用したい。変更履歴がGitに残る |
SCP以外のサービス（CloudTrail, GuardDuty, Security Hub等）のTerraform管理方針は、各サービスの設計時に検討する。 SCPの管理はResource-based delegation policyを使えばfd-security-toolingアカウントに委任可能（マネジメントアカウントへのログインが不要になる）。delegation policyの作成自体はマネジメントアカウントで1回行う必要がある。
6. セキュリティサービス導入方針
fd-security-tooling に委任するセキュリティサービスの導入状況と方針。
導入状況
| サービス | 状態 | 設計書 |
|---|---|---|
| CloudTrail | ✅ 組織統合済み | CloudTrail 設計書 |
| Config | ✅ 組織統合済み | Config 設計書 |
| GuardDuty | ✅ 組織統合済み | GuardDuty 設計書 |
| Security Hub | ✅ 組織統合済み | Security Hub 設計書 |
| Inspector | 🔧 設計済み | Inspector 設計書 |
| GuardDuty S3 Malware | 🔧 対象選定完了 → 実装へ | GuardDuty 設計書 §12 / 調査結果 |
| Macie | ⏸ 見送り中（Phase 4） | 本セクション参照 |
| Detective | 📋 未着手 | - |
| IAM Access Analyzer | 📋 未着手 | - |
Macie の導入方針
現時点では見送り。 ガバナンス整備後に Phase 4 として導入予定。
見送りの理由（2026-08-14 判断）
- 費用対効果が薄い: Macie はテキストベースの機密データ（PII、クレカ番号、APIキー等）を検出するサービスだが、医療情報を含む最大容量の3バケット（合計 7TB+）は全て JPEG 画像であり、Macie は画像の中身を読めない。テキスト系の機密データバケット（DBダンプ、CSV、文字起こし等）は S3 棚卸しで既に手動特定済みであり、Macie を入れて新たに見つかるものは少ない
- 漏洩リスクが低い: 全バケットでパブリックアクセスが無効化されており、アカウントレベルでも S3 Block Public Access が有効。意図しない外部公開による機密データ漏洩のリスクは構造的に低い
- ガバナンス未整備: 個人情報の分類基準・管理ポリシー・是正フローが組織的に整備されていない段階。Macie が機密データを検出しても、その結果を受けて是正・対応するプロセスがなければ効果を発揮しない。先にデータ分類ポリシーと運用フローを整備してから導入すべき
- コスト: バケット評価 $0.10/バケット/月 + オブジェクト監視 $0.012/1,000オブジェクト/月 + データ分析 $1.00/GB で推定 $130〜200+/月
導入ロードマップ
| Phase | 施策 | 状態 |
|---|---|---|
| Phase 1 | GuardDuty S3 Malware Protection 導入 | 対象確定 → 実装へ |
| Phase 2 | S3 Server Access Logs + Storage Lens 有効化 | 調査完了 → 実装へ |
| Phase 3 | データ分類ポリシー・ガバナンス整備 | 未着手 |
| Phase 4 | Macie 導入 | 見送り中 |
導入時の前提条件（Phase 4 で満たすべき条件）
- データ分類ポリシーが定義されていること（どのレベルの機密データにどう対応するか）
- Macie の検出結果を受けて是正する運用フローがあること
- AWS の設計思想は「全バケット対象 → ログ・CI/CD を除外」。今回の棚卸し結果（約250件のログ・CI/CDバケット）を除外リストに活用可能
- 30日間無料トライアルでまず評価し、想定外の機密データが見つかるか確認してから継続判断