セキュリティガバナンス — Organizations · SCP · アカウント監視

第28章 で VPC を複数に分けるメンタルモデルを押さえる中で、本当の隔離はアカウント分離の方が強いという話をしました。この章はその次のステップです — いつアカウントを分け、分けたアカウントたちをどう1つの組織にまとめて統制するか です。

第2章 IAM が1つのアカウントの中で誰が何をできるかを扱ったのに対し、この章は アカウントそのものを複数置き、組織レベルで境界を引く ガバナンスを扱います。本書は単一アカウントから OU で分けるところまでを中心とし、大規模なマルチアカウント運用は概要で押さえます。

単一アカウントの限界 — いつ分けるか #

1 ~ 4部は単一アカウントを前提としました。小さなチーム、1つ2つのサービスならそれで十分です。次のサインが見えたらアカウントを分けるときです。

• 爆発半径 — dev のミスが prod のリソースに触れうる構造。アカウントを分ければ権限境界がアカウント境界と一致します。
• 請求の可視性 — どのチーム / 環境がいくら使っているかを、1つのアカウントの中ではタグでしか分けられません。アカウントを分ければ請求書が自然に分かれます。
• 規制 / 監査 — 特定のワークロードを隔離されたアカウントに置かなければならないコンプライアンス要件。
• 権限の限界 — IAM ポリシーだけでは「この環境ではそもそもこのリージョン / このサービスを使えなくする」といった組織レベルの禁止をすっきり表現するのが難しいです。

AWS Organizations — アカウントをまとめる #

AWS Organizations は複数のアカウントを1つの組織にまとめるツールです。

• 管理アカウント(management account) — 組織を作った最上位のアカウント。請求の統合と組織管理だけを行い、ワークロードは載せません。
• メンバーアカウント — 組織に属する残りのアカウント(prod / staging / dev / sandbox など)。
• OU(Organizational Unit) — アカウントをまとめるフォルダ。通常は環境(Prod OU / Non-Prod OU)やチーム基準で分けます。
• 統合請求(Consolidated Billing) — すべてのアカウントの請求が管理アカウントに集まり、ボリューム割引と Savings Plan を組織全体で共有します。

Root
├── 管理アカウント (請求 · 組織管理)
├── Security OU
│   ├── ログアーカイブアカウント
│   └── セキュリティ監査アカウント
├── Prod OU
│   └── prod アカウント
└── Non-Prod OU
    ├── staging アカウント
    └── dev アカウント

Terraform では組織 · OU · アカウントをコードで宣言します。管理アカウントで実行します。

resource "aws_organizations_organization" "org" {
  feature_set = "ALL"   # SCP など全機能を有効化
  # 組織単位で有効化しておくサービスの委任を許可
  aws_service_access_principals = [
    "guardduty.amazonaws.com",
    "securityhub.amazonaws.com",
    "config.amazonaws.com",
    "sso.amazonaws.com",
  ]
}

resource "aws_organizations_organizational_unit" "prod" {
  name      = "Prod"
  parent_id = aws_organizations_organization.org.roots[0].id
}

resource "aws_organizations_organizational_unit" "nonprod" {
  name      = "Non-Prod"
  parent_id = aws_organizations_organization.org.roots[0].id
}

resource "aws_organizations_account" "prod" {
  name      = "myapp-prod"
  email     = "aws+prod@example.com"   # アカウントごとに一意なメール
  parent_id = aws_organizations_organizational_unit.prod.id
}

SCP — 組織レベルのガードレール #

SCP(Service Control Policy) は OU やアカウントにかける 権限の上限 です。IAM との違いが核心です。

つまり SCP は「この OU のどのアカウントもこれはできない」というガードレールです。実際の権限 = (SCP が許可)∩(IAM が許可)の積集合です。SCP が塞いだものは、そのアカウントのルートユーザーですらできません。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApproved",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["ap-northeast-2", "us-east-1"]
      }
    }
  }]
}

この SCP がかかった OU のアカウントは、ソウルとバージニア以外のリージョンにリソースを作れません。グローバルサービス(IAM · Route 53 · CloudFront など)は NotAction で例外を置かないと、ロックされてしまいます。もう1つよくかけるガードレールは 監査ログの保護 です。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectAudit",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "config:DeleteConfigurationRecorder",
      "config:StopConfigurationRecorder"
    ],
    "Resource": "*"
  }]
}

Terraform で SCP を作って OU に付けます。

resource "aws_organizations_policy" "region_lock" {
  name    = "region-lock"
  type    = "SERVICE_CONTROL_POLICY"
  content = file("${path.module}/scp/region-lock.json")
}

resource "aws_organizations_policy_attachment" "region_lock_prod" {
  policy_id = aws_organizations_policy.region_lock.id
  target_id = aws_organizations_organizational_unit.prod.id
}

よく使うガードレールの組み合わせ: ① ルートユーザーの危険な操作の禁止、② 承認されたリージョン以外の使用禁止、③ CloudTrail / Config の無効化禁止、④ 特定の高コストサービスの無断使用禁止。

Control Tower — ランディングゾーンの自動化 #

Organizations + SCP + ログアカウント + 基本ガードレールを手ですべて立てるのは面倒です。Control Tower は、この初期構成(ランディングゾーン)を自動で敷いてくれます。

• OU 構造(通常は Security · Sandbox)、ログアーカイブ / 監査アカウント、推奨 SCP ガードレール(必須/強く推奨/任意)を一度に設定します。
• Account Factory で新しいアカウントを標準形(ネットワーク · ガードレール · SSO 込み)で量産します。
• 小さな組織が初めてマルチアカウントへ移るときの出発点として適しています。

本書では Control Tower の存在と役割までを押さえます。1つのアカウントから始めて OU を2、3個に分ける段階なら、Organizations + 自作の SCP いくつかで十分で、アカウントが急速に増える組織で Control Tower が値を持ちます。

アカウント全体を監視 — GuardDuty · Security Hub · Config · Inspector #

アカウントを分けたなら、組織全体を俯瞰 するツールが必要です。4つが対になります。

運用の核心は、これらをアカウントごとに別々に有効化せず、委任管理者アカウント(通常は Security OU の監査アカウント)から組織全体に一度に有効化することです。そうすれば 新しく作ったアカウントも自動で登録 されます。

# 管理アカウントで: 監査アカウントを GuardDuty 委任管理者に指定
resource "aws_guardduty_organization_admin_account" "this" {
  admin_account_id = aws_organizations_account.audit.id
}

# 監査アカウント(provider alias)で: 新規アカウントの自動有効化
resource "aws_guardduty_organization_configuration" "this" {
  provider    = aws.audit
  detector_id = aws_guardduty_detector.audit.id
  auto_enable_organization_members = "ALL"   # 既存 + 将来のアカウントすべて
}

GuardDuty の脅威通知(findings)は 第19章 EventBridge / SQS / SNS の EventBridge ルールで受け、SNS → Slack / メールへ送ります。Config のルール違反は自動是正(remediation)へつなげます。

resource "aws_cloudwatch_event_rule" "gd" {
  name          = "guardduty-findings"
  event_pattern = jsonencode({ source = ["aws.guardduty"], "detail-type" = ["GuardDuty Finding"] })
}

resource "aws_cloudwatch_event_target" "gd_sns" {
  rule = aws_cloudwatch_event_rule.gd.name
  arn  = aws_sns_topic.security_alerts.arn
}

IAM Identity Center — アカウントをまたぐ権限 #

アカウントが複数になると、アカウントごとに IAM ユーザーを作るのは管理が不可能です。IAM Identity Center(旧 AWS SSO) で一度ログインして、複数アカウントのロールを選んで使えるようにします(第5章)。

• Permission Set = 複数のアカウントに共通でデプロイするロールのテンプレート(例: AdminAccess、ReadOnly、Developer)。
• ユーザー/グループを(アカウント, Permission Set)の組み合わせに割り当てると、そのアカウントに該当するロールが自動生成されます。

resource "aws_ssoadmin_permission_set" "developer" {
  instance_arn     = local.sso_instance_arn
  name             = "Developer"
  session_duration = "PT8H"
}

resource "aws_ssoadmin_account_assignment" "dev_to_prod" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  principal_id       = local.dev_group_id
  principal_type     = "GROUP"
  target_id          = aws_organizations_account.prod.id
  target_type        = "AWS_ACCOUNT"
}

1アカウント → N アカウント移行パターン #

すでに単一アカウントで運用中なら、マルチアカウントへ移る現実的な順序は次のとおりです。

1. Organizations の作成 — 新しい管理アカウントを作り、現在のアカウントをメンバーとして招待します。管理アカウントにはワークロードを置かないのが原則です(権限が最も強いので攻撃対象領域を最小化)。
2. ログ / 監査アカウントの分離 — CloudTrail の組織トレイルとログアーカイブ S3 を専用アカウントに集めます。このアカウントは SCP で最も強く保護します。
3. 環境アカウントの分離 — dev / staging / prod をアカウントで分けます。リソースの移行は一度に行わず、新しいワークロードから新しいアカウントに載せます。
4. SCP ガードレールの適用 — リージョン制限、ルート保護、監査ログ保護からかけます。
5. アカウント間の接続 — VPC は 第28章 の Transit Gateway で、権限は IAM Identity Center の SSO でつなぎます。

マルチアカウントは不可逆ではありませんが、移行コストが大きいです。新しいアカウントは新しいワークロードから 埋め、既存の単一アカウントはゆっくり空けていきます。6部キャップストーンは単一アカウントを前提としますが、そのインフラが Terraform でコード化されていれば、新しいアカウントへ移すことも「別のアカウントの provider で apply」に近づきます。

練習問題 #

1. ご自身の組織(または架空の組織)を Root → OU → アカウント構造で描いてみてください。少なくとも管理アカウント · ログアカウント · prod · dev をどの OU に配置するかを決め、各境界が §「単一アカウントの限界」のどの問題を解くかを1行ずつ結びつけておいてください。
2. 「すべてのアカウントで ap-northeast-2 と us-east-1 以外のリージョン使用禁止」を IAM ポリシーでかけるのと SCP でかけるのとの違いを説明し、なぜグローバルサービスを NotAction で例外処理しなければならないかを §「SCP — 組織レベルのガードレール」の JSON を根拠に書いてみてください。
3. 新しいメンバーアカウントを追加したときに GuardDuty が自動で有効になるようにするにはどの設定が必要かを §「アカウント全体を監視」の Terraform から探して書き、その通知が 第19章 のどのサービスを経て担当者に届くかを1つの流れで描いてみてください。

一行まとめ: 爆発半径 · 請求の可視性 · 規制 · 権限の限界のサインが見えたら、単一アカウントをマルチアカウントへ分ける。AWS Organizations がアカウントを OU でまとめて請求を統合し、SCP は IAM と違って OU/アカウント全体に権限の上限(ガードレール)をかける deny 境界で、実際の権限は SCP ∩ IAM の積集合(ルートも SCP を越えられない)。グローバルサービスは NotAction で例外を置く。Control Tower はランディングゾーンを自動化し、GuardDuty · Security Hub · Config · Inspector は委任管理者アカウントから auto_enable_organization_members で組織全体(将来のアカウント含む)に有効化する。アカウント間の権限は IAM Identity Center の Permission Set で、ネットワークは Transit Gateway でつなぎ、移行は新しいワークロードを新しいアカウントに載せる方式で段階的に進める。

次の章 #

次の 第30章 災害復旧・バックアップ では、1つのリージョン / 1つの AZ が崩れたときにデータとサービスをどう復旧するかを扱います。RDS PITR · S3 バージョン管理 / レプリケーション · AWS Backup でバックアップを押さえ、Pilot Light · Warm Standby · Multi-Site のリージョン間 DR パターンを RTO / RPO 基準で選ぶ方法を整理します。