【入門編】クラウド環境におけるクロスアカウント攻撃と信頼関係の悪用 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

クラウドの「合い鍵」を悪用する泥棒？クロスアカウント攻撃の恐怖と対策を優しく解説！

皆さん、こんにちは！

突然ですが、皆さんの「家」には鍵がかかっていますよね？そして、その鍵を誰かに渡すとしたら、信頼できる家族や親しい友人に限るのではないでしょうか。

実は、クラウドの世界でも、これと似たような「鍵」と「信頼関係」の仕組みが使われています。それが、今回お話しする「IAMロール」と「クロスアカウント攻撃」なんです。

「え、なんか難しそう…」と思ったあなた、大丈夫です！このブログでは、新人のIT担当者さんや、セキュリティに初めて触れる開発者さんにも分かりやすいように、身近な例え話を交えながら、クラウドの「合い鍵」を悪用する泥棒のからくりと、その恐ろしい攻撃から大切なクラウド環境を守る方法を、一歩ずつ丁寧に解説していきますね。

1. クラウドの「合い鍵」って何？ IAMロールの基本

まず、クラウド環境での「合い鍵」にあたる「IAMロール」について、簡単にお話ししましょう。

皆さんが普段使っているAmazon Web Services (AWS) のようなクラウドサービスでは、様々なサービス（例えば、データの保管庫であるS3、コンピューターを動かすEC2など）が連携して動いています。これらのサービスが、お互いに「あれ、ちょっとこのデータ見せてくれる？」「この処理お願いできる？」といったやり取りをする際に、お互いを「信頼」するための仕組みが必要になります。

この「信頼」を証明するのが「IAMロール」なんです。

例えるなら、これは「一時的な合鍵」のようなものです。Aさん（あるサービス）がBさん（別のサービス）に何かをお願いしたいときに、AさんはBさんに対して「この作業だけなら、この鍵（IAMロール）を使ってね」と、一時的な合鍵を渡すイメージです。

この「合い鍵」は、誰に、どの範囲で、どんな作業を許可するのかを細かく設定できるので、セキュリティ上、とても便利な仕組みなんですよね。

2. 泥棒が狙う「信頼関係」の穴：クロスアカウント攻撃とは？

さて、この便利な「合い鍵」の仕組みですが、悪意のある「泥棒」もこの「信頼関係」の隙を狙ってきます。それが「クロスアカウント攻撃」と呼ばれるものです。

皆さんの家でも、もし「玄関の鍵」と「勝手口の鍵」があったとして、家族以外の人に「玄関の鍵」を渡してしまったらどうでしょう？その人が、本来入ってほしくない部屋にまで入ってしまったり、勝手口からこっそり出入りしたりするかもしれませんよね。

クラウドのクロスアカウント攻撃も、これと似ています。

攻撃者は、まず「泥棒」になりきります。
そして、信頼されている「Aさん」（攻撃者が乗っ取った、あるいは自分で用意したアカウント）が、別の「Bさん」（皆さんの大切なクラウドアカウント）に対して、本来渡すべきではない「合い鍵」（IAMロール）を渡している穴を見つけます。
その「合い鍵」を悪用して、Aさんの権限でBさんのデータにアクセスしたり、Bさんのリソースを操作したりするのです。

特に恐ろしいのは、攻撃者が「Aさん」になりすまして、Bさんに「この合い鍵（IAMロール）を受け取ってください」と指示を出すケースです。Bさんがその指示を鵜呑みにしてしまうと、攻撃者に「合い鍵」を渡してしまったことになり、まるで自分で泥棒を招き入れてしまったような状態になってしまうんです。

なぜ「クロスアカウント」と呼ぶの？

「クロスアカウント」というのは、文字通り「アカウントをまたいで」攻撃が行われるからです。皆さんのアカウント（Bさん）の信頼関係が、別の攻撃者のアカウント（Aさん）に悪用される、というイメージですね。

3. 攻撃者はどうやって「合い鍵」を渡させる？外部ID（External ID）の重要性

では、攻撃者は具体的にどのようにして、皆さんのアカウントに「合い鍵」を渡させようとするのでしょうか？ここで登場するのが、「外部ID（External ID）」という、とっても重要な防御策なんです。

皆さんの家を想像してみてください。もし、宅配業者さんが「この荷物、〇〇さん（あなた）に渡してください」と来たときに、あなたは「はい、どうぞ」とすぐに渡しますか？多分、「ご本人様確認」をしますよね。「お名前は？」「ご住所は？」といった具合に。

クラウド環境における「外部ID」は、この「ご本人様確認」の役割を果たします。

本来、Aさん（信頼されたアカウント）がBさん（皆さんのアカウント）のIAMロールを引き受ける（AssumeRoleする）際に、Bさんは「この合い鍵（IAMロール）は、本当に〇〇さん（Aさん）に渡すべきものなのか？」を確認したいわけです。

そこで、BさんはAさんに対して、「この合い鍵（IAMロール）を受け取るには、この『秘密の合言葉』（外部ID）を教えてくださいね」と伝えます。

攻撃者は、この「秘密の合言葉」を知りません。なので、攻撃者がAさんになりすましても、Bさんは「おや？秘密の合言葉が違いますね。あなたには合い鍵を渡せません！」と、攻撃をブロックできるのです。

外部ID（External ID）の設定方法

この「外部ID」は、皆さんのアカウント（Bさん）が、他のアカウント（Aさん）にIAMロールの信頼関係を設定する際に、相手に要求する形で指定します。

例えば、皆さんのアカウント（111122223333）が、信頼したいアカウント（444455556666）に対してIAMロールを許可する場合、以下のように設定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:root" // 信頼したいアカウントのARNを指定
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "YOUR_SECRET_EXTERNAL_ID_HERE" // ここに独自の秘密の合言葉を設定！
        }
      }
    }
  ]
}

ポイント：

"Principal" の部分で、信頼したいアカウント（ここでは 444455556666）を指定します。
"Condition" の "sts:ExternalId" の部分に、皆さんが独自に決めた「秘密の合言葉」を設定します。この「秘密の合言葉」は、信頼する相手（Aさん）だけが知っている必要があります。
攻撃者はこの「秘密の合言葉」を知らないため、この設定がされていると、たとえ攻撃者がAさんになりすましても、IAMロールを引き受ける（AssumeRoleする）ことができなくなります。

信頼する相手（Aさん）側での設定

信頼する相手（Aさん）側でも、この「秘密の合言葉」を使ってIAMロールを引き受けるための設定が必要になります。これは、AWS CLI（コマンドラインインターフェース）などを使って行います。

aws sts assume-role \
    --role-arn "arn:aws:iam::111122223333:role/YourTrustedRoleName" \
    --role-session-name "MySession" \
    --external-id "YOUR_SECRET_EXTERNAL_ID_HERE" # ここに、Bさんから指定された秘密の合言葉を入力！

ポイント：

--role-arn には、皆さんのアカウント（Bさん）で作成したIAMロールのARNを指定します。
--external-id に、皆さんのアカウント（Bさん）で設定した「秘密の合言葉」を正確に入力する必要があります。

この「外部ID」を設定することで、皆さんのアカウントは、信頼できる相手からの「合い鍵」の要求かどうかを、より確実に判断できるようになるんです。まるで、宅配業者さんが「〇〇さんですね？では、この合言葉をどうぞ」と確認するようなものですよね。

4. 「外部ID」がないと、こんな怖いことが…

もし、「外部ID」を設定せずに、ただ単にIAMロールの信頼関係を設定してしまった場合、どうなるでしょうか？

それは、まるで「玄関の鍵」を、誰にでも渡せるように、ドアノブにぶら下げておくようなものです。

攻撃者は、皆さんのアカウント（Bさん）が設定しているIAMロールの信頼関係をスキャンして、「あ、このロールは外部IDなしで引き受けられるぞ！」と見つけます。そして、攻撃者は自分のアカウント（Aさん）から、そのIAMロールを簡単に引き受けてしまい、皆さんのアカウントに不正にアクセスできてしまうのです。

これは、まさに「泥棒が、誰でも開けられる玄関から忍び込んでくる」ような状況です。

5. クロスアカウント攻撃を防ぐための「防御ヘッダー」の考え方

ここまでお話ししてきた「外部ID」の設定は、クラウドセキュリティにおける「防御ヘッダー」の考え方に似ています。

「防御ヘッダー」というのは、もともとWebセキュリティで使われる言葉で、HTTPリクエストやレスポンスに付与される情報のことです。例えば、ブラウザがWebサイトにアクセスする際に、「私はこういうブラウザです」「この機能を使いたいです」といった情報をサーバーに送りますよね。

IAMロールにおける「外部ID」も、まさにこの「防御ヘッダー」のような役割を果たしています。

信頼関係を設定する側（Bさん）が、「この合い鍵（IAMロール）は、この秘密の合言葉を知っている人だけに使わせてあげるよ」という「条件」という「ヘッダー」を付ける。
合い鍵を受け取る側（Aさん）は、その「秘密の合言葉」という「ヘッダー」を正しく付けてリクエストしないと、合い鍵を受け取れない。

このように、お互いに「この条件を満たさないと、このやり取りはできませんよ」という「ヘッダー」のようなものを設定することで、不正なアクセスを防ぐことができるのです。

6. まとめ：クラウドの「合い鍵」は、しっかり管理しよう！

今日のまとめです！

IAMロールは、クラウドサービスがお互いに連携するための「一時的な合い鍵」のようなものです。
クロスアカウント攻撃は、この「合い鍵」の信頼関係を悪用して、別のアカウントから皆さんのクラウド環境に不正アクセスする攻撃です。
外部ID（External ID）は、このクロスアカウント攻撃を防ぐための、とっても強力な「秘密の合言葉」のようなものです。
信頼関係を設定する際は、必ず外部IDを設定することを強くお勧めします。
これは、クラウドセキュリティにおける「防御ヘッダー」の考え方と似ていて、お互いに「条件」を確認し合うことで安全を確保します。

クラウド環境は、皆さんの大切なデータやシステムを守るための「家」のようなものです。その「家」の「合い鍵」であるIAMロールを、誰に、どのように渡すのかをしっかりと考え、外部IDのような「秘密の合言葉」を設定することで、泥棒の侵入を防ぎ、安全なクラウド環境を維持していきましょう。

「一歩ずつ対策を学んでいきましょう！」という、皆さんのペースで、これからも一緒にクラウドセキュリティの知識を深めていけたら嬉しいです。

もし、今日の記事で「ここがちょっと分からないな…」という点があれば、遠慮なくコメントなどで質問してくださいね！