こんにちは！クラウドインフラの世界へようこそ。セキュリティチームのホワイトハッカーとして、日々国内外の様々なシステムの守りを固めている私です。
今回は、AWS（Amazon Web Services）を使ったシステム開発やインフラ運用で、絶対に知っておくべき「AWS Organizationsにおけるサービスコントロールポリシー（SCP）」についてお話しします。
「なんだか難しそうな名前だな…」と思いましたか？大丈夫です！専門用語は置いておいて、まずは身近な「家の防犯」にたとえながら、一緒に一歩ずつ紐解いていきましょう。
—
1. なぜ「ガードレール」が必要なのか？（家の鍵にたとえてみよう）
皆さんが暮らす家を想像してみてください。玄関には頑丈な鍵がついていますよね。でも、もし家族の誰かがうっかり「窓の鍵をかけ忘れて出かけてしまったら……」あるいは「合鍵を持った人が、勝手に家全体の電気や水道の契約を変えてしまったら……」どうなるでしょうか？
クラウドの世界もこれとまったく同じです。
AWSでは、1つの会社の中で複数の「AWSアカウント（お部屋のようなもの）」を作ってシステムを管理することがよくあります。開発用の部屋、テスト用の部屋、本番用の部屋といった具合ですね。
ここで問題になるのが、「いくら気をつけていても、人間はミスをする」ということです。
どれだけ優秀なエンジニアであっても、深夜の作業でうっかりミスをして、世界中に公開してはいけないデータを外部に公開してしまう設定にしてしまったり、不要な高額サーバーを大量に起動してしまったりすることがあります。さらに、万が一アカウントが乗っ取られたら、悪意ある侵入者は「管理者権限（マスターキー）」を使って、すべての設定をめちゃくちゃにしてしまうでしょう。
ここで登場するのが、今回のテーマである SCP（サービスコントロールポリシー） です。
SCPは、いわば「家全体の壁に埋め込まれた、絶対に破れない鉄板のルール」のようなものです。たとえその部屋のマスターキーを持っている人（ルートユーザー）であっても、この壁に書かれたルールを破ることはできません。「この部屋では、窓を開けてはいけない」「この部屋の電気の契約は勝手に変えてはいけない」といった制限を、アカウントの外側からガッチリと縛り付けることができるのです。
—
2. SCP（サービスコントロールポリシー）の正体と強力さ
SCPは、AWS Organizationsという仕組みを使って、複数のAWSアカウントを束ねる親（管理）アカウントから子アカウントに向けて適用する「制限のルールブック」です。
従来の「IAM（Identity and Access Management）」という機能と何が違うの？と疑問に思うかもしれません。
違いを分かりやすく例えてみましょう。
- IAM（従来の権限管理）：
「この部屋の住人には、この引き出しを開けていいよ、あっちの引き出しはダメだよ」と、個別のユーザーに渡す「個別の鍵」のようなものです。
- SCP（今回の主役）：
「この部屋自体、そもそも特定の金庫のエリアには近づいてはいけない」という、建物自体の構造を縛る「建築基準法や頑丈な物理的バリケード」のようなものです。
つまり、IAMで「この操作を許可します」と書いてあったとしても、親であるSCPが「いや、このアカウントではその操作自体を全面禁止にする！」と言っていれば、絶対にその操作は実行できません。 これが、セキュリティ上の最強の盾となる理由です。
—
3. 実践！事故を防ぐためのSCP設定例
それでは、実際に現場でよく使われる実用的なSCPの設定を見ていきましょう。
今回は、新人エンジニアのうっかりミスや不正アクセスを防ぐための代表的なシナリオを2つご紹介します。
シナリオ①：特定の地域（リージョン）以外でのリソース作成を禁止する
「うちの会社は、データ保護の観点から、AWSのリソースは日本の『東京リージョン（ap-northeast-1）』や『大阪リージョン（ap-northeast-1）』以外で作ってはいけないルールにしたい！」というケースです。海外のリージョンで勝手にサーバーが立ち上がってしまうミスや不正を防ぎます。
以下のJSONコードをSCPとして設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllRegionsExceptJapan",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": "StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1",
"ap-northeast-3"
]
}
}
]
}この設定のポイント（優しく解説）
Effect: "Deny"：「〜を禁止する」という強力な拒否のルールです。NotAction：例外的に許可するサービスを指定しています。CloudFrontやIAM、Route53など、一部のグローバルサービスはリージョンに依存しないため、ここから除外しています。aws:RequestedRegion：「今、どこの地域のサーバーを使おうとしているか」をチェックしています。ここで東京（ap-northeast-1）と大阪（ap-northeast-3）以外の場所で操作しようとすると、ガチッとブロックされます。
—
シナリオ②：万が一の時のために「CloudTrail（監査ログ）」の停止を防ぐ
サイバー攻撃を受けた際、犯人は証拠を隠すために防犯カメラ（監査ログ）を止めようとします。AWSでは CloudTrail というログ記録サービスがこれにあたりますが、これを開発者がうっかり、あるいは故意に止められないようにする鉄壁のルールです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectCloudTrailFromTampering",
"Effect": "Deny",
"Action": [
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging",
"cloudtrail:UpdateTrail"
],
"Resource": "*"
}
]
}この設定のポイント（優しく解説）
- どんなに権限を持った開発者や、アカウントの最高責任者（ルートユーザー）であっても、
cloudtrail:StopLogging（ログの記録を止める）やcloudtrail:DeleteTrail（ログの設定を消す）という操作を絶対に実行できなくします。 - これにより、「誰がいつ、どんな操作をしたのか」という大事な足跡（証拠）を常に守り抜くことができます。
—
4. 導入時の注意点（ここを間違うと大変！）
SCPはあまりにも強力なルールであるため、設定する際にはいくつか泥臭い注意点があります。現場のエンジニアがよくハマる「落とし穴」をシェアしておきますね。
1. デフォルトでは「すべて許可」になっている
AWS Organizationsを作ったばかりの状態では、SCPは「何も制限しない（すべて許可する）」という緩い状態になっています。ここに自分で「禁止ルール」を追加していくことで、セキュリティを固めていきます。
2. ルート組織や親アカウントに適用しすぎない
いきなり一番上の階層（ルート）に厳しい「Deny（禁止）」のSCPを適用してしまうと、自分自身を含めて管理者が何もできなくなる「ロックアウト状態」に陥ることがあります。まずはテスト用の小さな組織（OU：組織単位）から適用して、動作確認をするのが鉄則です。
—
最後に：一歩ずつ、堅牢なシステムへ
いかがでしたでしょうか？
AWS OrganizationsのSCPは、クラウドインフラという広大な家を守るための「最強のガードレール」です。難しく聞こえるセキュリティ対策も、「うっかりミスや不正からシステムを守るための優しい防犯対策」だと捉えれば、少し親しみやすく感じられたのではないでしょうか。
最初から完璧を目指す必要はありません。まずは安全なリージョンを絞る設定など、小さく一歩を踏み出してみましょう。皆さんのインフラ構築が、より安全でワクワクする挑戦になることを応援しています！
コメント