「ルートユーザーなら無敵」という幻想を捨てろ：AWS SCPで構築する「壊せない」境界線
現場の諸君、お疲れ様。今日もどこかのサーバーで、誰かが「緊急作業だから」とルート権限を振りかざし、設定ファイルを書き換えているかもしれないな。
悲しいかな、多くの現場では「権限さえあれば何でもできる」という設計がデフォルトになっている。だが、プロの現場では「全能の権限を持つ人間ですら、システムを破壊できない」という制約こそが、最強のセキュリティだ。今日は、AWSにおけるその究極のガードレール、SCP（Service Control Policy）について話をしよう。
なぜ「IAMポリシー」だけでは不十分なのか
多くのエンジニアは、IAMポリシーで「開発者にはこの権限を与えよう」と細かく設定することに注力する。だが、もしその開発者のクレデンシャルが漏洩したり、あるいは権限を持ったメンバーが魔が差して（あるいはミスで）重要なリソースを削除したらどうなる？
IAMは「許可」を与える仕組みだが、SCPは「拒否」を強制する仕組みだ。SCPは、AWS Organizations配下のアカウントに対して「ルートユーザーであっても絶対に行わせないアクション」を定義できる。いわば、クラウドのインフラレイヤーに刻み込まれた「憲法」のようなものだ。
攻撃者の視点：彼らは「足跡」を消すことから始める
攻撃者が侵害に成功した際、最初に行うのは何だと思う？ ログの停止や、自身の活動を隠蔽するためのCloudTrailの無効化だ。
もし君のアカウントでCloudTrailが停止されたら、攻撃者はやりたい放題だ。SCPを使えば、たとえ攻撃者が管理者権限を奪取したとしても、CloudTrailを止めることは物理的に不可能になる。
実践：CloudTrailの改ざんを封じるSCPの設計
以下は、組織内のすべてのアカウントにおいて、CloudTrailの停止や削除を禁止する実用的なSCPコードだ。これをOrganizationsのルートに適用すれば、どんな権限を持つユーザーもこれを突破することはできない。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCloudTrailModification",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"cloudtrail:UpdateTrail"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::123456789012:role/SecurityAdminRole"
/* 本来であれば、この除外設定すら行わず「全員拒否」が最も堅牢だ */
]
}
}
}
]
}「運用を止めるな」というプレッシャーとの戦い
「こんな厳しい制限をかけたら、緊急時に何もできなくなるのでは？」という声が聞こえてきそうだな。その通りだ。セキュリティと利便性は常にトレードオフだ。
だが、現場のエンジニアが陥る罠は、「利便性のためにセキュリティを犠牲にし、事故が起きた時に初めて後悔する」というパターンだ。
私が推奨する運用手法はこうだ：
1. 最小権限の原則をSCPで強制する: まずは、リージョンの制限（特定の国以外からの操作を拒否）や、特定の高リスクAPI（iam:DeleteAccessKey など）を制限することから始めよ。
2. 「Break-glass」用のアカウントを分離する: 何があってもSCPを回避する必要がある緊急事態のために、 Organizationsの管理アカウントに直接ログインするルート権限保持者を最小限（1〜2名）に絞り、その利用ログを別のアカウントにリアルタイムで転送する仕組みを作る。
最後に：セキュリティは「設定」ではなく「規律」だ
SCPは強力な武器だが、ただ適用すればいいというものではない。設定した後に「なぜこれが拒否されたのか」を理解できない運用チームは、結局セキュリティ設定を「面倒なもの」としてバイパスする抜け道を探し始める。
技術的に堅牢なガードレールを敷いた上で、チームに対して「なぜその権限が必要なのか」「なぜこのアクションが禁止されているのか」を言語化して教えること。それが、真のホワイトハッカーである君たちの仕事だ。
次回の現場では、ぜひ「ルートユーザーを無力化する」という視点で、自組織のポリシーを見直してみてくれ。健闘を祈る。
コメント