【入門編】クラウド環境におけるクロスアカウントアクセスログの追跡 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！日々のインフラ管理や開発、本当にお疲れ様です。
クラウド環境って、ボタン一つでサーバーが立ち上がったり、別の会社（や、別の部署）のシステムと連携できたりして、本当に便利ですよね。

でも、その「便利さ」の裏側には、セキュリティの落とし穴が潜んでいることがあります。特に、複数のAWSアカウントを行き来するような「クロスアカウントアクセス」は、攻撃者にとっても大好物なターゲットになりやすいんです。

今回は、このクロスアカウントアクセスを悪用されたとき、私たちSOC（セキュリティオペレーションセンター）アナリストがどのように裏をかき、CloudTrailという「防犯カメラの映像」から犯人を追跡するのかを、身近な例えを交えながら優しく紐解いていきたいと思います。

一歩ずつ、一緒に学んでいきましょう！

—

1. 例え話で理解する「クロスアカウントアクセス」と「合鍵」の危険性

まず、クラウドの「アカウント」って何に似ているでしょうか？
これは、それぞれ独立した「一軒家」のようなものです。Aさんのお家と、Bさんのお家は別々。基本的には、AさんがBさんのお家に勝手に入ることはできません。

しかし、ビジネスでは「Aさんのお家にある荷物を、Bさんのお家からちょっと手伝って動かしたい」という状況が発生します。そんなとき、どうしますか？
毎回わざわざ玄関の鍵を渡すのは面倒なので、「我が家のこの部屋（特定のバケットやリソース）に限り、Bさんが持っている身分証を見せれば、合鍵なしで出入りしていいよ」というルールを作りますよね。これがAWSでいう「クロスアカウントアクセス（権限委譲）」です。

攻撃者はこの「合鍵のルール」のどこを突くのか？

もし、Aさんがこのルール（信頼関係）をちょっと緩く設定してしまっていたらどうなるでしょう？
例えば、「Bさんなら誰でもウチに入れるよ」という雑な設定にしていたとします。そこに、泥棒（攻撃者）がBさんの家の警備をかいくぐって侵入し、Bさんの名札を偽造してAさんのお家に忍び込んでしまったら……？

Aさんからすれば、「あれ、Bさん（のふりをした人）が来たな」と思ってしまうため、気づいた時には大切なデータがごっそり持ち出されていた、なんてことが起きるのです。これが、クロスアカウント悪用の恐ろしいメカニズムです。

—

2. 犯行の足跡を見つける！CloudTrailの「防犯カメラ」を覗く

「じゃあ、泥棒が入ってきたらお手上げなの？」いいえ、そんなことはありません。
AWSには、誰が・いつ・どこから・どの部屋に入ったかをすべて記録する「AWS CloudTrail」という強力な防犯カメラ（ログシステム）が備わっています。

クロスアカウントの不正アクセスが起きると、CloudTrailのログには非常に特徴的な足跡が残ります。ここを見つけ出すのが、私たちアナリストの腕の見せ所です。

注目すべきポイントは AssumeRole と userIdentity

攻撃者が別のパブリックなアカウントから別のアカウントへ侵入する際、必ず「権限の切り替え（ロールの引き受けて）」を行います。これをAPIの名前で AssumeRole と呼びます。

CloudTrailのログを眺めるときは、以下のポイントに注目します。

どこのアカウント（ExternalIdやPrincipalId）からアクセスしてきたか？
普段はあり得ないIPアドレスや、深夜の時間帯ではないか？
予期せぬAPI（データのダウンロードなど）が実行されていないか？

—

3. 実践！怪しいクロスアカウントアクセスをあぶり出すクエリ

「理屈は分かったけど、実際にどうやってログを探せばいいの？」という方のために、現場で私たちがよく使う Amazon Athena（CloudTrailのログをSQLで検索できるサービス）用のクエリのサンプルをご紹介します。

そのままコピーして、皆さんの環境でも試せるように丁寧なコメントをつけておきました！

-- 過去24時間以内に発生した、別アカウントからの怪しい「AssumeRole（権限の切り替え）」を炙り出すクエリ
SELECT
    eventTime,                                   -- イベントが起きた日時
    userIdentity.principalId AS 実行者ID,         -- 誰が実行したか（アカウントIDやIAMユーザー名）
    sourceIpAddress,                             -- アクセス元のIPアドレス
    requestParameters.roleArn AS 奪われたロール,   -- どの権限（ロール）が使われたか
    userAgent                                    -- どのようなツールからアクセスされたか
FROM
    your_cloudtrail_logs_table                   -- ※あなたの環境のCloudTrailログテーブル名に変更してください
WHERE
    eventSource = 'sts.amazonaws.com'            -- 認証やトークン発行に関するサービスを指定
    AND eventName = 'AssumeRole'                 -- ロールを切り替えたイベントに絞り込み
    -- 自社で許可している信頼できるアカウントID以外からのアクセスをあぶり出す
    AND userIdentity.accountId != '123456789012' -- ※自社の正しいAWSアカウントIDに書き換えてください
    AND dt >= '2023-10-01'                       -- 調査対象の開始日（コスト削減のため日付で絞る）
ORDER BY
    eventTime DESC
LIMIT 100;

このクエリが教えてくれること

このSQLを実行すると、「おや？自社のアカウントIDとは違う場所から、うちの重要な権限（ロール）が使われているぞ」という履歴がリストアップされます。
もし sourceIpAddress に見覚えのない海外のIPや、Tor（匿名化ネットワーク）のIPが入っていたら……赤信号です。即座にそのロールの紐付けを解除する緊急対応（インシデントレスポンス）が必要になります。

—

4. 明日からできる防御の基本：合鍵の管理を厳格にしよう

インシデントを防ぐためには、普段からの「戸締まり」が何よりも大切です。以下の3つのポイントを見直すだけで、クロスアカウント攻撃のリスクを劇的に減らすことができます。

1. ExternalId（合言葉）を必ず設定する
別の企業や外部サービスと連携する際、AWSは ExternalId という合言葉の設定を強く推奨しています。これがあることで、仮にBさんが乗っ取られても、正しい合言葉を知らない攻撃者はAさんのお家に入れなくなります。家族だけの秘密の合言葉を設定するイメージですね。
2. 信頼関係（Trust Policy）の条件を厳しく絞る
「どのアカウントからでもOK」にするのではなく、特定のIAMユーザーや特定のIPアドレスからしかロールを引き受けられないよう、ポリシーに条件（Condition）を書き込みましょう。
3. CloudTrailのログを別の安全な金庫に保管する
もし攻撃者が社内アカウントを乗っ取った場合、証拠隠滅のためにCloudTrailのログを消そうとするかもしれません。ログは、書き換えや削除ができない別のアカウント（または専用のセキュリティ用アカウント）に厳重に保管しておきましょう。

—

まとめ

いかがでしたでしょうか？
「クロスアカウントアクセス」と聞くと難しそうに聞こえますが、「別の家との合鍵のやり取り」と捉えると、どこに気を付ければいいかが見えてきますよね。

クラウドのセキュリティは、一度設定して終わりではありません。泥棒が新しい手口を試してくるように、私たちも定期的に防犯カメラ（CloudTrail）の映像を確認し、鍵の掛け忘れがないかチェックしていくことが大切です。

難しく考えず、まずはCloudTrailのログを少し覗いてみることから始めてみませんか？
あなたの安全なクラウドライフを、陰ながら応援しています！