こんにちは！インフラやクラウドのセキュリティの世界へようこそ。
初めてサーバーOSの要塞化やクラウドのセキュリティ設定に向き合うとき、「どこから手をつければいいんだろう…」と不安になりますよね。
今回は、AWSなどのクラウド環境で組織全体を守る強力な盾、「サービスコントロールポリシー（SCP）」について、身近な防犯の仕組みに例えながら、一歩ずつ優しく紐解いていきたいと思います。難しく考えず、リラックスして読んでいてくださいね。
—
1. なぜ「組織レベルのガードレール」が必要なのか？
皆さんは、自分の家を出るときに鍵をかけますよね。では、もし「家族全員が、勝手に玄関の鍵を外しっぱなしにできる合鍵を持っていたらどうでしょう？」
ちょっと怖いですよね。いくら「鍵を閉めてね」と口うるさく言っても、うっかりミスや、もしかしたら悪意を持った人が侵入して、勝手に鍵を開けてしまうかもしれません。
クラウドの世界もこれと全く同じです。
いくら個別のサーバーやクラウドのアカウント（AWSでいう個別のAWSアカウント）で「セキュリティをがっちり固めましょう！」と言っていても、開発者や管理者がうっかりミスをしたり、最悪の場合、管理者アカウントのパスワードが外部に漏れてしまったりすると……。クラウドの「大元（おおもと）」の鍵を勝手に開けられて、勝手に高額なサーバーを海外で大量に立てられてしまったり、大事なデータを消されてしまったりするリスクがあります。
そこで登場するのが、今回解説するSCP（サービスコントロールポリシー）です。
SCPとは、いわば「クラウド全体の管理者が握っている、絶対に破られない最強のマスターロック（ガードレール）」のようなものです。個別のユーザーがどんな権限を持っていようとも、「組織全体として、この操作は絶対に禁止！」というルールを強制的に適用することができます。
—
2. 攻撃者はどこを狙う？――「ルートユーザー」と「海外リージョン」の罠
サイバー攻撃者は、企業のクラウド環境を乗っ取ろうとするとき、人間がやりがちな「うっかり」や「油断」の隙を鋭く突いてきます。
よくある手口の1つが、「普段使わない海外のデータセンター（リージョン）でコソコソと不正な作業をする」というものです。
例えば、日本国内だけでサービスを展開している企業であれば、通常は東京リージョン（ap-northeast-1）や大阪リージョン（ap-northeast-3）しか使いませんよね。攻撃者はこの盲点を突き、セキュリティ監視の目が届きにくい遠くの海外リージョン（例えば南米やアフリカなど）で、勝手に大量の仮想サーバー（マイニング用など）を立ち上げたりします。
また、すべての権限を持った最強のアカウントである「ルートユーザー」が何らかの拍子に狙われると、家で言えば「家全体のマスターキー」が奪われた状態になってしまいます。
こうした脅威を防ぐために、「特定のリージョン以外での操作を禁止する」「ルートユーザーによる危険な操作を禁止する」というルールを、SCPを使って組織全体にガチッと縛り付ける必要があるのです。
—
3. SCPで「使っていい場所」と「ダメな場所」を制限してみよう
それでは、実際にSCPを使って、組織全体のセキュリティを向上させる設定を見ていきましょう。
今回は、「日本国内のリージョン以外でのリソース作成を禁止する」という、実務でも非常によく使われる鉄板のガードレールを例にします。
AWS Organizations環境では、JSON形式という書き方でポリシーを定義します。以下のサンプルコードを見てみてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyJapanRegions",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1",
"ap-northeast-3",
"us-east-1"
]
},
"ArnNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::123456789012:role/OrganizationAccountAccessRole"
]
}
}
}
]
}コードの解説（初心者の方向けに優しく！）
"Effect": "Deny"- 「問答無用で拒否する！」という強力な意思表示です。SCPの基本は、この
Denyを使って「やってはいけないこと」を明確に定義することにあります。 "Action": "*"と"Resource": "*"- 「すべての操作（Action）」および「すべてのリソース（Resource）」に対して適用するという意味です。
"aws:RequestedRegion"- ここがポイントです！ユーザーが「どのリージョン（場所）に対して操作を行おうとしているか」をチェックしています。ここでは、東京（
ap-northeast-1）、大阪（ap-northeast-3）、そしてグローバルな一部の処理で必要なバージニア北部（us-east-1）以外の場所からのアクセスをすべて弾く（StringNotEquals）ようにしています。 - 例外処理（
ArnNotEquals） - すべてをガチガチに縛ってしまうと、いざというときに管理者が何もできなくなってしまいます（これを「締め出し」と呼びます）。そのため、緊急時に使う特定の管理者用ロール（上記の例では
OrganizationAccountAccessRoleなど）だけは例外として許可する、といった配慮をコード内に記述しています。
—
4. 現場のインフラエンジニアからのアドバイス：焦らず、一歩ずつ適用しよう
SCPは組織全体を守る強力な盾ですが、使い方を間違うと、「社内の開発者全員が作業できなくなって大パニック！」という笑えないインシデント（自爆）を引き起こす原因にもなります。
現場でSCPを導入するときは、必ず以下のステップを踏むようにしてください。
1. まずは「ドライラン（テスト）」を行う
いきなり本番環境の組織ルートに適用するのではなく、テスト用の組織ユニット（OU）を作り、少数のアカウントで挙動をテストします。
2. 影響範囲をチームで共有する
「来週から、海外リージョンでのサーバー構築が一切できなくなります」ということを、開発チームに事前にアナウンスしておきます。
3. 例外ルールを丁寧に作り込む
自動化ツールやCI/CDパイプラインが動いている場合、SCPによってそれらが突然止まることがあります。どのロールやサービスが例外として必要になるか、事前にしっかりと洗い出しましょう。
—
まとめ
今回は、組織レベルのガードレールである「SCP（サービスコントロールポリシー）」について解説しました。
- SCPは、クラウド環境全体の「破られないマスターロック」である。
- 攻撃者が好む「海外リージョンでの不正利用」などを、組織全体で強制的にブロックできる。
- ただし、設定を間違えると自爆するため、例外処理を考慮しながら慎重に段階を踏んで導入することが大切。
セキュリティ対策というと「なんだか難しそう、面倒くさそう」と感じてしまうかもしれませんが、一つひとつの設定は、私たちの生活にある「防犯の仕組み」と同じです。
焦らず、一歩ずつ理解を深めながら、安全で堅牢なクラウドインフラを作っていきましょう！それではまた次回の記事でお会いしましょう。
コメント