Contents
スポンサードリンク
AWS Organizations における OU 設計と Service Control Policy（SCP）の実装ガイド
本稿は、マルチアカウント環境での権限委譲・ガバナンスを実現するためのベストプラクティス を具体的な設定例とともに示します。
内部コード SEC01‑BP01 は、当社が策定した「アカウント分離 + 最小権限」ポリシー（Security Baseline 01 – Business Policy）を指し、外部ブログは参考情報としてのみ掲載しています。
1. OU 階層の設計指針
| レベル | 推奨用途 | 主なサブ OU |
|---|---|---|
| Root | 全体ガバナンス（管理アカウント・監査用アカウント） | - |
| Business | 部門別に権限を分離（Finance、Marketing、R&D 等） | 各部門の Prod / Staging / Dev OU |
| Environment | 環境ごとの制御を明確化（Production、Staging、Development） | 同一ビジネスユニット内で環境別にサブ OU を作成 |
- メリット
- ビジネス単位と環境単位の二軸管理が可能になるため、SCP の適用範囲を細かく制御できる。
- アカウント追加時は「部門 → 環境」のテンプレートに従うだけで、一貫したガバナンスが自動的に継承される。
2. SEC01‑BP01 に準拠した SCP テンプレート（Prod OU 向け）
以下は、Production OU に対して「ルートユーザーのアクセスキー操作を禁止し、必要最小限の read‑only アクションのみ許可」する実装例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyRootAccessKeyManagement", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:UpdateAccessKey" ], "Condition": { "StringEquals": { "aws:userid": [ "AIDAEXAMPLE_ROOT" // ルートユーザーの固定 userid（実環境に合わせて置換） ] } } }, { "Sid": "AllowReadOnlyForS3AndCloudWatch", "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:ListBucket", "cloudwatch:DescribeAlarms", "logs:FilterLogEvents" ], "Resource": "*" } ] } |
ポイント解説
| 項目 | 内容 |
|---|---|
Sid 名 |
AWS のポリシーでは一意である必要はないが、後から検索しやすいように機能を表す名前に統一。 |
| ルートユーザーの制限 | aws:userid に根拠となる ID（例：AIDAEXAMPLE_ROOT） を指定することで、実際に「ルート」だけが対象になる。IAM コンソールの Root user タブで確認可能。 |
| 許可ステートメント | 必要最小限の read‑only アクションのみを列挙し、Resource: "*" として全リソースに適用。ただし、機密データへの書き込みは除外している点が重要。 |
※注意：本ポリシーはあくまでサンプルです。実運用では各サービスごとの ARN を限定することで、さらなるスコープ縮小を検討してください。
SCP のデプロイ手順
- Organizations コンソール → ポリシー → Service Control Policies で「ポリシーの作成」
- 上記 JSON を貼り付け、名前
Prod-SEC01-BP01と説明を入力。 - 作成した SCP を対象 OU（例：
Business/Finance/Prod）に アタッチ。 aws organizations simulate-principal-policyコマンドでシミュレーションし、影響範囲を事前検証。
3. ルートユーザー保護のベストプラクティス
| 項目 | 推奨設定 |
|---|---|
| MFA | 仮想 MFA（Google Authenticator 等）またはハードウェアトークンを必ず有効化。Console → アカウント → セキュリティ認証情報 → MFA デバイスの管理 から設定可能。 |
| アクセスキー | ルートユーザーに対しては 作成しない、既に存在する場合は即削除。aws iam delete-access-key --user-name root --access-key-id <key-id> を実行。 |
| 定期レビュー | IAM の「アクセスキー」レポートを月次で確認し、未使用キーが 90 日以上残っている場合は自動的に削除する Lambda（例：rotate-access-key）と SNS 通知を組み合わせる。 |
4. AWS Control Tower による Landing Zone の構築
- Control Tower コンソール → 「Landing zone 設定」
- デフォルト OU と管理アカウント（Audit Account、Log Archive Account）を選択し、必要な Guardrails を有効化。
Create landing zoneを実行すると、以下が自動生成される- 管理用 OU（
AWSControlTowerAdmin）と共有サービス OU（AWSServiceCatalog） - Account Factory によるテンプレートベースの新規アカウント作成パイプライン
- Security Hub、Config、CloudTrail が全組織に対して有効化された状態
標準 Guardrail とカスタム Guardrail の使い分け
| 種別 | 例 | 実装方法 |
|---|---|---|
| 標準（Security） | S3 バケット暗号化、VPC Flow Logs、Root MFA 強制 | Control Tower コンソールの Guardrails タブでチェックオン |
| カスタム | 全アカウントで統一 KMS キーを使用させる | CloudFormation テンプレートに AWS::Config::Rule（例：kms-key-enabled） を記述し、Control Tower の「Custom Guardrails」へ登録 |
5. 脅威検知・監査基盤の全体像
| コンポーネント | 主な役割 |
|---|---|
| GuardDuty (マスターディテクタ) | 組織全体で脅威をリアルタイム検出。aws guardduty enable-organization-admin-account --admin-account-id <管理アカウントID> で有効化 |
| Security Hub | GuardDuty・Inspector・Macie の結果を統合し、単一ダッシュボードで可視化 |
| Organization Trail (CloudTrail) | 全アカウントの API ログを 1 本の S3 バケットに集約。--is-multi-region-trail と --enable-log-file-validation を必ず付与 |
| AWS Config | リソース設定ドリフトを評価し、カスタムルール（例：S3 暗号化）を自動適用 |
インシデント自動化フロー（概要）
- GuardDuty が高リスク検知 → EventBridge で
GuardDutyFindingイベント捕捉。 - Step Functions に渡し、以下を実行
- 該当 IAM ユーザーの一時的なアクセス停止（ポリシー更新）
- Amazon Detective がログ相関分析を実施しレポート生成
- Slack／Microsoft Teams へ通知し、チケット自動作成
このフローにより 検知から対応までの時間が数分に短縮 されます。
6. フェデレーテッド認証とクロスアカウント監査ロール
IAM Identity Center（旧 SSO）での最小権限ロール例
| ロール名 | 主な許可 |
|---|---|
ReadOnly-Prod |
CloudWatch の閲覧、S3 GetObject、RDS Describe* |
DevOps-Deploy |
CodePipeline 実行、ECS デプロイ、Parameter Store PutParameter（限定） |
SecurityAudit (クロスアカウント) |
CloudTrail LookupEvents、Config Get*, GuardDuty GetFindings、Logs FilterLogEvents |
設定手順
- Identity Center コンソール → 外部 IdP 接続 で Azure AD や Okta を登録。
- 「AWS Account Access」アプリケーションに対し、OU 別のプロビジョニングルールを作成し上記ロールとマッピング。
- ユーザーは IdP で認証後、自動的に対象ロールへ
AssumeRoleが実行される。
共通 SecurityAudit クロスアカウントロールの構築
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AuditReadOnly", "Effect": "Allow", "Action": [ "cloudtrail:LookupEvents", "config:Get*", "guardduty:GetFindings", "logs:FilterLogEvents" ], "Resource": "*" } ] } |
- 管理アカウントでポリシーを作成し、ロール
SecurityAuditにアタッチ。 - 各メンバーアカウントの信頼関係に管理アカウント ID を追加し、
sts:AssumeRoleを許可。 - CloudWatch Logs のサブスクリプションフィルターで全ログを 中央 S3 バケット（例：
audit-logs-central）へ転送し、一元的に保管。
7. 運用プロセスの自動化チェックリスト
| 項目 | 実施頻度 | 自動化手段 |
|---|---|---|
| MFA 設定監査（Root） | 月次 | Config Rule mfa-enabled-for-root → SNS 通知 |
| アクセスキーローテーション（非 Root） | 90 日ごと | Lambda (rotate-access-key) + Secrets Manager 更新 |
| Root アクティビティ監視 | 四半期 | IAM Access Analyzer レポートで Root API 呼び出しを検知、違反時は自動ロールバック手順へ |
まとめ
- OU 階層は「部門 × 環境」の二軸で設計し、SCP の適用範囲を細分化。
- SEC01‑BP01 に沿った Production 用 SCP は、ルートユーザーのアクセスキー操作を明示的に Deny し、最低限の read‑only アクションだけを Allow する形で実装。
- Root MFA とアクセスキー管理は必須の防御層であり、月次・四半期レビューと Lambda 自動化で継続的に保守。
- Control Tower による Landing Zone の自動構築と Guardrails の組み合わせで、全組織に統一されたベースラインを即座に提供。
- 脅威検知・監査基盤は GuardDuty + Security Hub + Organization Trail + Config で完結し、EventBridge と Step Functions によるインシデント自動化で対応速度を向上。
- IAM Identity Center と共通
SecurityAuditロールにより、フェデレーテッド認証とクロスアカウント監査がシームレスになる。
これらを順次導入すれば、マルチアカウント環境でも「最小権限 + 統一ガバナンス」の成熟したセキュリティ体制を実現できます。
スポンサードリンク