AWS Organizations 最低限のガードレール｜まず入れるSCP・RCPとコピペ雛形

「AWS Organizationsに、まずどのSCPを入れればいい？」——最低限のガードレールを、コピペできるSCP/RCPのJSON雛形付きで整理します。監査/検知の保護・root禁止・リージョン制限から、TLS必須・組織境界のRCP、そして既存ワークロードを壊さない適用順序まで。

01まず、どのSCPを入れる？

AWS Organizationsの仕組みと設計で「Root・OUにガードレール（SCP/RCP）を敷く」と書きました。では具体的にどれを、どのJSONで入れればいいのか——コピペできる雛形付きで、最低限のセットを示します。

この記事のポリシーは、AWS公式ドキュメントと公式サンプル（aws-samples／Control Tower）由来です。${Account} / [PrivilegedRole] / o-xxxxxxxxxx などはプレースホルダなので自環境の値へ置換してください。

02前提 — 評価モデルとDenyリスト戦略

雛形を貼る前に、これだけは押さえます。ここを誤ると事故ります。

• 評価順：明示的Deny ＞ 暗黙的Deny ＞ 明示的Allow。SCPは Root→OU→アカウントの全階層でAllowが揃って初めて通り、Denyは1か所でもマッチすれば即拒否。
• Denyリスト戦略：各エンティティに FullAWSAccess（SCP）/ RCPFullAWSAccess（RCP）が付いている前提で、Deny文だけを足す。この2つを外すと全拒否になるので絶対に外さない。
• 管理アカウント除外：SCP/RCPは管理アカウントに効かない。だから管理アカウントにワークロードを置かない（→ アカウント戦略）。
• サイズ上限：SCP/RCPは1つ最大5,120文字。巨大ポリシーは分割やOU設計で対応。

03① 監査・検知を止めさせない（最初に入れる）

最初に入れるべきはこれ。誰の業務も止めず、いざという時の証跡と検知を守ります。CloudTrail・Config・GuardDuty・Security Hub の停止/削除/改変を禁止（運用ロールだけ例外）。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectSecurityServices",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail",
      "config:StopConfigurationRecorder", "config:DeleteConfigurationRecorder",
      "config:DeleteDeliveryChannel",
      "guardduty:DeleteDetector", "guardduty:DisassociateFromMasterAccount",
      "securityhub:DisableSecurityHub", "securityhub:DisassociateFromMasterAccount"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/[SecurityAdminRole]" }
    }
  }]
}

04② rootユーザーの利用を禁止

メンバーアカウントの root による操作を全面禁止（監査ログ改ざん等の最終手段を封じる）。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyRootUser",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }
    }
  }]
}

05③ 組織離脱・アカウント閉鎖を禁止

メンバーアカウントが勝手に組織を抜ける／閉鎖されるのを防ぎます（短く、影響も読みやすい）。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyLeaveAndClose",
    "Effect": "Deny",
    "Action": [
      "organizations:LeaveOrganization",
      "account:CloseAccount"
    ],
    "Resource": "*"
  }]
}

06④ リージョンを制限する

許可リージョン外の操作をDeny。攻撃対象・コンプラ面で効きますが、グローバルサービスを壊さない除外が肝。下は要点版で、aws:RequestedRegion の配列に許可リージョンを入れます。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideAllowedRegions",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "organizations:*", "sts:*", "cloudfront:*", "route53:*",
      "support:*", "globalaccelerator:*", "waf:*", "wafv2:*",
      "budgets:*", "ce:*", "health:*", "account:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": [ "ap-northeast-1", "us-east-1" ]
      },
      "ArnNotLike": {
        "aws:PrincipalArn": "arn:aws:iam::*:role/AWSControlTowerExecution"
      }
    }
  }]
}

07⑤ 危険な設定変更を禁止

暗号化の無効化・パブリック化・ログ削除といった"取り返しのつかない緩和"を禁止します（運用ロールだけ例外）。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDangerousChanges",
    "Effect": "Deny",
    "Action": [
      "ec2:DisableEbsEncryptionByDefault",
      "ec2:DeleteFlowLogs",
      "s3:PutAccountPublicAccessBlock",
      "s3:PutBucketPublicAccessBlock"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/[PrivilegedRole]" }
    }
  }]
}

08RCP — TLS必須と「組織の外から触らせない」

SCPが"組織内プリンシパル"を縛るのに対し、RCP（2024/11新設）はリソース側の上限で、組織外からのアクセスも止められます（データ境界）。社外ベンダーの越境アクセスはSCPでは止まりません。

TLS必須（暗号化されていない通信を拒否）：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceTLS",
    "Effect": "Deny",
    "Principal": "*",
    "Action": [ "s3:*", "sts:*", "kms:*", "sqs:*", "secretsmanager:*" ],
    "Resource": "*",
    "Condition": {
      "BoolIfExists": { "aws:SecureTransport": "false" }
    }
  }]
}

組織境界（自組織のプリンシパル以外を拒否・AWSサービスは除外）：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceOrgPerimeter",
    "Effect": "Deny",
    "Principal": "*",
    "Action": [ "s3:*", "sts:*", "kms:*", "sqs:*", "secretsmanager:*" ],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" },
      "Bool": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}

09宣言的ポリシー — 設定を"恒久的に"固定する

宣言的ポリシー（2024新）は、SCP/RCPと違いサービスのコントロールプレーンで強制され、コンソール/CLI/SDK/新API追加後も維持されます。構文は @@assign を使う独自形式（現状は主にEC2系）。

IMDSv2 を強制（v1を塞ぐ）：

{
  "ec2_attributes": {
    "instance_metadata_defaults": {
      "http_tokens": { "@@assign": "required" },
      "http_put_response_hop_limit": { "@@assign": "2" }
    }
  }
}

VPCのパブリックアクセスをブロック：

{
  "ec2_attributes": {
    "vpc_block_public_access": {
      "internet_gateway_block": { "mode": { "@@assign": "block_ingress" } }
    }
  }
}

10Control Towerを使うなら、多くは標準装備

自前で全部書く前に。AWS Control Tower を使うと、これらの多くが必須/推奨コントロールとして自動適用されます（管理アカウント除く）。

11壊さない適用順序

最後に、既存ワークロードを壊さないための順序です。ここが実務のいちばんの肝。

• ①監査・検知の保護から（誰の業務も止めない）→ ②root・離脱防止（影響が読みやすい）→ ③リージョン・危険設定は要検証で後回し。
• Policy Staging OU か別組織で先にテストし、影響を確認してから狭いOU→広いOUへ。
• CloudTrailで対象アクションの実利用を棚卸し（特にIMDSv1・config/cloudtrail変更・使用リージョン）。RCPで組織境界を締める前は IAM Access Analyzer で外部共有を洗い出す。
• 除外は特権ロール（運用/IaC/CI-CDロール）に限定。ArnNotLike aws:PrincipalArn で。例外を広げすぎない。
• FullAWSAccess / RCPFullAWSAccess は絶対に外さない（Denyリスト戦略の大前提）。

12まとめ — 監査保護から、段階的に

最低限は①監査・検知の保護／②root禁止／③離脱防止の3点セット。ここまでは影響が小さく、すぐ入れられます。そのうえで④リージョン制限／⑤危険設定禁止／RCP／宣言的ポリシーを、検証しながら段階的に。Control Towerを使えば多くが標準で入ります。

EMWは、マルチアカウントのガードレール設計・SCP/RCPの棚卸し・段階適用を、既存構成を壊さない形でお手伝いします。仕組みの全体像はAWS Organizationsの仕組みと設計もどうぞ。

13よくある質問（FAQ）