こんにちは！クラウドのインフラやサーバーのセキュリティを担当していると、毎日いろいろな設定と格闘することになりますよね。
新しいシステムを作るとき、AWSなどのクラウド環境で「IAMロール（サーバーやサービスに権限をあたえるための身分証のようなもの）」を設定する機会がたくさんあると思います。「このリソースから別のリソースへアクセスできるようにしよう！」と設定を進める中で、ふとこんな疑問を持ったことはありませんか？
「あれ？この信頼ポリシー（Trust Policy）の設定、適当に書いちゃうと、外から変なアクセスをされちゃったりしないのかな……？」
そうなんです！実はここ、セキュリティの現場でもよく狙われる、とっても重要で、かつ初心者のころはハマりやすい「落とし穴」があるんです。
今回は、サイバー攻撃者も思わずニヤリとしてしまう、この「思わぬ落とし穴（Confused Deputy問題）」について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. 身の回りの防犯で考えてみよう：「信頼」を悪用される恐怖
セキュリティの小難しい話に入る前に、少しだけ私たちの日常生活に置き換えて考えてみましょう。
あなたは、とても信頼できる「Aさん」というお友達に、自分の家の合鍵を預けました。Aさんは普段から誠実で、あなたの家に出入りして荷物を受け取ったりするのを手伝ってくれています。ここまでは何も問題ありませんよね。
では、こんな状況を想像してみてください。
ある日、ちょっと悪知恵の働く「Bくん」が、Aさんにこう近づいてきました。
- 「ねえねえ、Aさん。実はあの人の家にあるお宝をちょっと見たいんだけど、君、合鍵持ってるよね？ 僕の代わりにちょっとそのお宝を取ってきてくれない？」
ここで、もしAさんが「おや、Bくんがそう言うなら、信頼しているA（自分）が頼まれているんだし、鍵を開けてお宝を取ってきてあげようかな」と、深く考えずにBくんの言うことを聞いてしまったらどうなるでしょうか？
……ぞっとしますよね。Aさんは悪気がない（むしろ親切心のつもりかもしれない）のに、結果として泥棒の片棒を担がされてしまっています。
ITの世界でも、これとまったく同じことが起きます。これが、今回お話しする「Confused Deputy（混同された代理人）問題」と呼ばれるセキュリティ上の脆弱性です。
—
2. クラウドの世界で起きる「Confused Deputy問題」とは？
AWSなどのクラウド環境では、さまざまなシステムやサービス（これが先ほどの「Aさん」にあたります）が、私たちの代わりに別のシステム（「お宝」がある場所）へアクセスして仕事をしてくれます。
ここで、私たちがIAMロールの「信頼ポリシー（Trust Policy）」の設定をサボってしまい、「どの外部の誰からの依頼であっても、とりあえずこのロールを使ってアクセスしてよし！」とガバガバな状態にしておいたとします。
すると、悪意ある攻撃者が、別の会社（テナント）のクラウド環境などから、あなたの作った仕組み（Aさん）を悪用して、「ねえ、あなたの権限を使って、あそこの機密データをこっそり覗き見してよ！」と巧みに誘導（代理実行）してしまうのです。
「Aさん」はあなたのために一生懸命働いているつもりなのに、指示する相手を間違えて（混同して）、結果的に機密情報を攻撃者に差し出してしまう……これが、クラウドにおけるConfused Deputyのメカニズムです。
—
3. 救世主は「ExternalID」と「SourceArn」！
「うわ、なんだか怖くなってきた……どうやって防げばいいの？」と思いましたよね。安心してください。ちゃんと強力な対策が用意されています！
クラウドの世界でこの不正を防ぐために使うのが、信頼ポリシーに設定するExternalID（外部ID）とSourceArnという2つのパスワード・身元確認の仕組みです。
先ほどの家の例えに戻すと、こうです。
ExternalID: Aさんが家に入る時、「本当に持ち主から頼まれた仕事なのか？」を確認するための、2人だけが知っている「合い言葉」。SourceArn: 「このリソース（特定のサービス）からの依頼以外は、絶対に受け付けない！」という「専用の窓口指定」。
これらをしっかりと設定することで、いくら外部から悪意あるリクエストが来ても、「おっと、合言葉（ExternalID）が違うからダメです！」「指定された窓口（SourceArn）以外からの依頼は受け付けません！」と、システムがピシャリと跳ね返してくれるようになります。
—
4. 実践！安全なIAM信頼ポリシーの書き方
それでは実際に、実務でそのまま使える安全なIAMロールの信頼ポリシー（JSON形式）を見てみましょう。今回は、外部の別アカウントやSaaSサービスに安全に権限を渡すケースを想定しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ConfusedDeputyPreventionByExternalIDAndSourceArn",
"Effect": "Allow",
"Principal": {
"Service": "monitoring.amazonaws.com" // 例として、外部の監視サービスを信頼する場合
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:ExternalId": "ここにあなた企業だけが知る秘密の合い言葉(ExternalID)を設定します"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:iam::123456789012:root-or-service-resource" // 許可する特定の送信元リソースを明示
}
}
}
]
}設定のポイントを優しく解説！
1. Principal
- 「どのサービスやアカウントを信頼するか」の大きな枠組みを指定します。ここでは例として監視サービスを指定しています。
2. Condition（条件）
- ここが今日の主役です！「ただ信頼するだけじゃなく、特定の条件を満たした時だけ許可する」という強力なフィルターをかけます。
3. aws:ExternalId
- 外部サービス側と事前に共有しておく「合い言葉」です。これが一致しない限り、アクセスは絶対に許可されません。推測されにくいランダムな文字列（UUIDなど）を使うのが鉄則です。
4. aws:SourceArn
- 「どのリソースからのアクセスか」を特定します。この設定を入れておくことで、関係のない別の場所からの寄り道を完全にシャットアウトできます。
—
5. まとめ：一歩ずつ、安全なインフラを作っていきましょう！
今回は、IAMロールの信頼ポリシーにおけるConfused Deputy問題と、その回避策についてお話ししました。
セキュリティの世界は、初めて見る用語ばかりで難しく感じてしまうかもしれませんが、本質的な仕組みは「誰に、どこまで、どうやって身元を確認するか」という身近な防犯と同じです。
- 「外部サービスと連携するときは、なんとなく設定しない」
- 「
ExternalIdやSourceArnが設定できる場所では、必ず設定して身元を厳しく確認する」
この2つを意識するだけで、あなたの作るシステムは劇的に安全になります。一歩ずつ、確実にセキュリティの引き出しを増やしていきましょう！
それでは、次回のインフラ・クラウドセキュリティの解説もお楽しみに！
コメント