2026年版 AWS マルチアカウントのセキュリティ設計とガバナンス完全ガイド

1. 設計フレームワーク全体像

ポイント
- 本柱は相互に排他的ではなく、横断的に適用することで一貫したセキュリティ基盤 が構築できます。
- 各サービスの公式ガイドラインは以下のリンクから参照してください。

2. OU と SCP の設計指針

2‑1. 階層構造のベストプラクティス

実装例（テキストツリー）

2‑2. SCP（Service Control Policy）の運用モデル

ポリシー作成手順（概要）

1. JSON 定義を作成 – AWS Organizations コンソールの「ポリシー」→「Create policy」。
2. タグ付与でカテゴリ分け – Purpose=Mandatory / Purpose=Recommended。
3. OU へアタッチ – 必須は Root、推奨は対象 OU に段階的に適用。
4. 例外管理 – 特定アカウントが例外を必要とする場合は SCP の例外（Allow） を別途作成し、最小限のリストで許可。

公式ドキュメント: SCP の概要とベストプラクティス

3. Control Tower と Guardrails（ガードレール）

3‑1. Landing Zone の構築フロー

3‑2. 必須 Guardrails（2024 年版）

Guardrails の詳細は公式ページで随時更新されるため、最新情報は Control Tower Guardrails リファレンス を参照してください。

3‑3. 推奨 Guardrails とカスタム Guardrail の作り方

カスタム Guardrail の実装手順（概要）

1. AWS Config ルール作成 – aws configservice put-config-rule コマンドで評価ロジックを定義。
2. Control Tower に登録 – コンソールの「Guardrails」→「Custom Guardrails」で ARN を入力し、対象 OU にアタッチ。
3. 違反時の通知設定 – SNS トピックと Lambda 関数で自動リマインダーを実装。

参考: Control Tower カスタムガードレールの作成手順

4. IAM Identity Center と MFA の統合

4‑1. SCIM による自動プロビジョニング（2024 年リリース）

公式ガイド: IAM Identity Center の SCIM 自動プロビジョニング

4‑2. MFA を全ユーザーに必須化する条件付きアクセスポリシー

1. ポリシー作成 – IAM Identity Center → 「アクセス権限」→「新規ポリシー」
   json
{
"Version": "2023-10-01",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}
]
}
2. 全アプリケーションに適用 – 作成したポリシーを「デフォルトアクセス権限」に割り当て。
3. 未設定ユーザーへの自動通知 – CloudWatch Events で MFAEnabled = false を検知し、SNS + Lambda（リマインダー）へ転送。

詳細は IAM Identity Center の MFA 設定 を参照してください。

5. ログ・監視・コスト管理

5‑1. 必須有効化サービス一覧

各サービスのセットアップ手順は公式ドキュメントを参照。
- CloudTrail: https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html
- Config: https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/how-do-i-set-up-config.html
- GuardDuty: https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_enable.html

5‑2. ログ集約パイプライン（S3 → CloudWatch Logs Insights → OpenSearch）

1. S3 バケット aws-security-logs-<account-id> に CloudTrail と Config のログを保存。
2. Lambda (Python 3.11) が S3 イベントでトリガーされ、JSON を整形して CloudWatch Logs へ送信。
3. OpenSearch Service（t3.medium.search）にデータストリームを作成し、Kibana ダッシュボードで可視化。
4. 自動レポート – CloudWatch Logs Insights のクエリ結果を週次で PDF 化し、SNS 経由でステークホルダーへ配信。

詳細は Amazon OpenSearch Service のログ分析ガイド を参照してください。

5‑3. タグ付けと Budgets によるコスト監視

Budgets 設定手順（概要）

1. AWS Budgets コンソールで「コスト予算」作成。
2. 「フィルタ」に上記タグを組み合わせ、閾値（例: Production 10 % 超過）を設定。
3. SNS 通知と Lambda を紐付け、超過時に未承認リソースの自動停止またはタグ修正を実行。

公式ガイド: https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/budgets-create.html

6. 実装ロードマップと最終チェックリスト

6‑1. ロードマップ（5 フェーズ）

6‑2. 完了チェックリスト（簡易版）

• [ ] OU と SCP：全 OU に必須 SCP がアタッチ済みか
• [ ] Control Tower Guardrails：必須 Guardrail が 100 % 有効化されているか
• [ ] IAM Identity Center：SCIM 自動プロビジョニングが稼働し、外部 IdP と同期できているか
• [ ] MFA：全ユーザーに対して MFA が必須化され、条件付きポリシーでブロックが機能しているか
• [ ] CloudTrail：マルチリージョン設定・暗号化・S3 アーカイブが完了しているか
• [ ] ログ集約：CloudWatch Logs Insights → OpenSearch のパイプラインが正常にデータを受信し、ダッシュボードが作成済みか
• [ ] Budgets & タグ：タグ付けポリシーと予算アラートが設定され、テスト通知が届くことを確認したか

7. まとめ

本稿で提示した 4 本柱モデル＋具体的な実装手順 は、AWS が公式に推奨するベストプラクティスに基づいています。
各サービスの公式ドキュメントへのリンクを添付しているため、導入時に「設定が正しいか？」と疑問になった場合は必ず参照してください。

次のアクション
1. 本ロードマップをプロジェクト計画書に落とし込み、ステークホルダーへ共有。
2. Pilot アカウントで OU・SCP・Guardrails の最小構成を検証し、問題点を洗い出す。
3. 本番環境への段階的ロールアウトを開始し、定期的に ガードレールレビュー と コスト監視 を実施。

これらのプロセスを踏むことで、「セキュアかつガバナンスが効いた」マルチアカウント環境 が安定して運用できるようになります。ぜひ実務に活用してください。