【実務・中級編】サービスコントロールポリシー(SCP)による組織レベルのガードレール – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

境界防御の限界と「SCP」という最後の砦

「OSを叩き、Nginxをチューニングし、WAFで攻撃を弾く」。これが我々の日常だ。しかし、君たちがどんなに堅牢なサーバーを作ろうが、たった一つのミス――例えば、研修中の新人が実験的に立ち上げた脆弱なEC2インスタンスや、不用意に作成された「フル権限を持つIAMユーザー」のアクセスキーがGitHubに漏洩するだけで、すべては水泡に帰す。

クラウド環境におけるセキュリティの要諦は、個々の「箱」を固めることではなく、「何があっても組織のガバナンスを突き破らせない」というガードレールを敷くことにある。AWSにおいて、その最強のツールが「SCP（サービスコントロールポリシー）」だ。

なぜ「OSの要塞化」だけでは不十分なのか

どれだけLinuxの sshd_config を厳格に設定し、fail2ban でログイン試行を弾こうが、攻撃者はサーバーOSの外側を狙う。彼らは「ルートユーザーのパスワードリセット」を試みたり、「許可されていないリージョンにバックドア用のインスタンスを立ち上げてマイニングを始める」といった、インフラの根幹を揺るがす攻撃を仕掛けてくる。

これらを個別のIAMポリシーで管理するのは限界がある。組織が拡大すればするほど、権限管理はカオス化するからだ。ここで登場するのが、組織全体に物理的な境界線を引く「SCP」である。

実践：攻撃者が最も嫌う「鉄壁のSCP」設定

以下に、組織のメンバーがどれほど特権を持とうとも、決して越えられない「組織レベルのガードレール」のサンプルを示す。

この設定は、主に「ルートユーザーの操作禁止」と「指定外リージョンの利用禁止」を強制する。これを組織のルート（Management Account）に適用すれば、子アカウントの管理者がいくら悪あがきしても、設定を変更することはできない。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUserAccess",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "acm:*",
        "iam:*",
        "organizations:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

コードのポイント解説

DenyRootUserAccess: ルートユーザーによる一切の操作を拒否する。日常運用でルートユーザーを使うことは、家の鍵を玄関先に置いておくのと同じだ。緊急時以外は絶対に使わせないことが鉄則。
DenyNonApprovedRegions: 日本国内（ap-northeast-1）と管理用リージョン以外でのリソース作成を禁止する。攻撃者がよく使う「海外リージョンでのリソース立ち上げ」を未然に封じる、極めて強力な防御策だ。

現場で「やらかさない」ための運用Tips

SCPを設定する際、一つだけ注意点がある。「適用する前に、必ず検証用OU（組織単位）でテストせよ」ということだ。

SCPは強力すぎる。もし設定ミスをすれば、開発者が突然EC2を起動できなくなり、デプロイが全停止する。私は過去に、SCPの定義ミスで全リージョンのデプロイを遮断し、半日かけて復旧させた冷や汗ものの経験がある。

運用を自動化するなら、Terraform を用いて、SCPの変更をGitで管理し、プルリクエストベースで承認を得るフローを構築しておくべきだ。

# TerraformによるSCP適用例
resource "aws_organizations_policy" "security_guardrails" {
  name        = "SecurityGuardrails"
  description = "全アカウントに適用する境界設定"
  content     = file("scp_policy.json") # 上記のJSONファイルを読み込む
}

resource "aws_organizations_policy_attachment" "root_attachment" {
  policy_id = aws_organizations_policy.security_guardrails.id
  target_id = "r-xxxx" # 組織のルートID
}

最後に：エンジニアとしての矜持

「OSの要塞化」はエンジニアの基礎体力を示すものだが、「SCPによる組織管理」はエンジニアとしての視座の高さを証明するものだ。

サーバーの中身を磨くのはもちろん大事だ。だが、それ以上に「システム全体がどうあるべきか」という境界線を設計すること。これこそが、数々のインシデントを乗り越えてきた我々のようなシニアエンジニアが、後輩に教えたい「真の守り」だ。

次にコードを書くとき、サーバーの sudo 権限を気にするのと同時に、「自分の書いたコードが、組織のSCPに守られているか」を少しだけ想像してみてほしい。それができれば、君はもう一段上のレベルに到達しているはずだ。