CloudTrailとVPCフローログで、アカウントをまたいだ操作を追う ―「誰が」と「どこから」をつなぐ調査設計

開発会社のAWSアカウントから本番アカウントのロールを借りて作業してもらう。グループ会社のネットワークと閉域でつなぐ。AWSを使う会社では、こうした「アカウントをまたぐ」構成がふつうになってきました。

困るのは、何か起きたあとです。AWSの中で起きた操作の記録は、操作した側と操作された側のアカウントに分かれて残ります。ネットワークの通信の記録は、さらに別のアカウントに残っていることがあります。調べようとして初めて、ほかの会社の管理者に「ログを出してください」とお願いすることになります。

この記事では、AWSの操作記録であるCloudTrailで「誰が、どのロールで、何をしたか」を確かめ、通信の記録であるVPCフローログで「どの経路から、どこへ接続したか」を確かめ、両方を突き合わせる調査の組み立て方を書きます。GuardDutyで検知する回（GuardDutyのCustom Detection Rulesの記事）、Security Hubで修復する回（Security HubとASRのAI Toolkitの記事）に続き、検知された出来事の背景を調べる工程を扱います。

CloudTrailとは ― AWSの「操作記録」

CloudTrailは、AWSに対して「誰が、何を頼んだか」を記録するサービスです。管理画面（マネジメントコンソール）でボタンを押すのも、CLIでコマンドを打つのも、プログラムからSDKを呼ぶのも、AWSから見ればすべてAPIの呼び出しです。CloudTrailはその呼び出しを1件ずつ「イベント」として残します。

1件のイベントはJSON形式で、項目はたくさんあります。最初は次の6つだけ見れば足ります。

※以下のイベントの値はすべて架空の記入例です。

{
  "eventTime": "2026-10-15T01:23:45Z",
  "eventName": "DeleteBucket",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::111122223333:assumed-role/OpsRole/tanaka-ops"
  },
  "sourceIPAddress": "203.0.113.10",
  "requestParameters": { "bucketName": "example-bucket" },
  "errorCode": "AccessDenied"
}

← 表は横にスクロールできます →

このイベントは「OpsRoleというロールを、tanaka-opsというセッション名で使った誰かが、example-bucketを消そうとして、権限不足で失敗した」と読めます。

何もしなくても見られる90日分と、自分で残す記録

AWSアカウントを作った時点で、CloudTrailの「イベント履歴」は有効になっています。過去90日分の管理イベントを、リージョンごとに無料で検索できます。ただし90日を過ぎると消え、検索は1つのアカウントの1つのリージョンに限られます。

90日より長く残したい、複数のリージョンやアカウントをまとめて見たい、という場合は「証跡（trail）」を作り、S3バケットなどへ保存します。コンソールで作る証跡は、既定で全リージョンが対象になります。

管理イベントとデータイベントは別物

CloudTrailのイベントには種類があります。

• 管理イベント: リソースの作成・変更・削除、ロールの引き受け、サインインなど。イベント履歴に出るのはこれだけです
• データイベント: S3のファイルの読み書き、Lambda関数の実行など、リソースの中身に対する操作。既定では記録されず、証跡で明示的に有効にする必要があり、料金もかかります
• ネットワークアクティビティイベント: VPCエンドポイントを通ったAPI呼び出し。2025年2月に一般提供になりました。エンドポイントの所有者が有効にしたときだけ記録されます

「CloudTrailは最初から有効だから、全部残っている」は誤解です。S3のファイルを誰が持ち出したか、を後から調べたいなら、データイベントを事前に有効にしておく必要があります。

CloudTrailに残らないもの

CloudTrailはAWSのAPIを呼んだ記録なので、次のものは残りません。

• サーバー（EC2）にログインして打ったコマンド
• アプリケーションが出すログ
• 通信の中身や、APIを経由しない通信そのもの

最後の「通信」を記録するのが、次に説明するVPCフローログです。

VPCフローログとは ― ネットワークの「通話記録」

VPCは、AWSの中に作る自社専用のネットワークです。VPCフローログは、そのネットワークで「どこからどこへ、いつ、どれくらい通信したか」の記録です。電話の通話記録に似ていて、相手と時間と長さはわかりますが、会話の中身はわかりません。

既定の形式では、1行に14個の項目がスペース区切りで並びます。

※以下のログの値はすべて架空の記入例です。

2 111122223333 eni-0a1b2c3d4e5f67890 10.20.1.15 10.20.2.40 49152 443 6 12 4820 1792027380 1792027440 ACCEPT OK

← 表は横にスクロールできます →

フローログは既定では作られません。VPC、サブネット、ネットワークインターフェイスのどれかの単位で作成し、送信先をCloudWatch Logs、S3、Amazon Data Firehoseから選びます。既定の形式は変更できないので、項目を足したいときは作成時にカスタム形式を指定します。

CloudTrailとVPCフローログの違い

← 表は横にスクロールできます →

片方だけでは、調査の問いに半分しか答えられません。CloudTrailは「誰が」に強く、フローログは「どこから」に強い。この2つをつなぐのが、この記事の主題です。

「アカウントをまたぐ」とはどういう状態か

AWSアカウントは、請求と権限の単位になる独立した箱です。本番、開発、ログ保存などでアカウントを分けておくと、開発環境の設定ミスが本番に波及しにくくなり、費用の内訳も分けやすくなります。複数のアカウントをまとめて管理する仕組みがAWS Organizationsです（組織の作り方は過去記事「AWS Organizations入門：ゼロから作る、統制されたマルチアカウント基盤」を参照）。

アカウントをまたぐ代表的な形は2つあります。

1つ目は、ほかのアカウントのロールを引き受けて操作する形です。ロールは「一時的に借りる別の名札」のようなもので、引き受ける操作をAssumeRoleと呼びます。開発会社の担当者が自社のアカウントでサインインし、そこから本番アカウントの作業用ロールを借りて作業する、という使い方が典型です。

2つ目は、ネットワークをつなぐ形です。1つのVPCを複数のアカウントで使う共有VPC、複数のVPCを中継するTransit Gateway、2つのVPCを直接つなぐVPCピアリングがあります。

委託先、グループ会社、社内の別部署のアカウントが、ロールとネットワークの両方でつながることも珍しくありません。そのとき、記録はそれぞれのアカウントに別々に残ります。

アカウントをまたぐと、調査に必要なログが分散する

次のような仮想の例で考えます。実際のインシデントではなく、説明のための設定です。

この1件を説明するのに必要な記録は、少なくとも3か所に分かれます。

← 表は横にスクロールできます →

自社が持つ本番アカウントの記録は、自分で取りに行けます。問題は委託先のアカウントです。誰がAssumeRoleを呼んだのかという肝心の情報は、委託先のCloudTrailにしか残りません。他社が管理するアカウントのログは、自社からは取得できないのが普通です。

ですから、ログの保存期間と、調査時に開示してもらう手順は、契約の時点で取り決めておく必要があります。事故が起きてから頼むと、保存期間が切れていた、担当者が見つからない、ということが起こりえます。

CloudTrailで「誰が」を確定する

AssumeRoleは両方のアカウントに記録される

アカウントをまたいでAssumeRoleを呼ぶと、CloudTrailは呼び出した側のアカウントと、ロールがある側のアカウントの両方にイベントを記録します。2つのイベントには同じsharedEventIDが入るので、別々の場所から集めたイベントを同じ操作として結びつけられます。

ここで注意したいのが、記録される内容の差です。IAMのドキュメントによると、IAMユーザーがAssumeRoleした場合、ロール側のアカウントのイベントでは呼び出し元が「アカウント番号と主体のID」として記録されます。さらに、借りたロールでその後に行った操作のイベントには、ロールの情報しか残らず、元のユーザー名は出てきません。

ロール側だけを見ていると、「OpsRoleが消した」まではわかっても、「委託先の誰がOpsRoleを使ったか」まではたどれない、ということです。

セッションをたどる手がかり

ロールの後の操作と、元の人をつなぐ手がかりは3つあります。

• アクセスキーID: AssumeRoleのイベントのresponseElementsに、発行された一時的な認証情報のアクセスキーID（ASIAで始まる）が記録されます。後続の操作のイベントにあるuserIdentity.accessKeyIdと同じ値を探せば、同じセッションの操作だと判断できます
• ロールセッション名: AssumeRoleのときに付ける名前で、後続のイベントのARN（assumed-role/OpsRole/tanaka-opsの末尾）に出ます。ただし名前は呼び出し側が自由に付けられるので、本人確認には使えません
• ソースアイデンティティ（SourceIdentity）: ロールの信頼ポリシーでsts:SourceIdentityを必須にすると、AssumeRoleのときに利用者の識別子を渡させることができます。この値はロールを乗り継いでも引き継がれ、後から変えられません

委託先にロールを貸すなら、信頼ポリシーでsts:SourceIdentity（またはsts:RoleSessionName）の指定を求めておくと、本番側の記録だけでも「誰の作業か」の見当がつきやすくなります。

失敗したAssumeRoleは、ロール側に残らない

もう1つ、調査で見落としやすい点があります。IAMのドキュメントには、アカウントをまたいだロールの引き受けで、拒否されたSTSのリクエストはロール側のアカウントには記録しない、と書かれています。

「誰かが本番のロールを何度も借りようとして失敗していた」という痕跡は、本番アカウントではなく、呼び出した側のアカウントにしか残りません。委託先にログの開示を頼む理由が、ここにもあります。

リージョンと保存先の確認

STSのグローバルエンドポイント（sts.amazonaws.com）に送られたリクエストは、米国東部（バージニア北部）リージョンに記録されます。リージョン別のエンドポイントに送られたものは、そのリージョンに記録されます。イベント履歴で探すときは、東京リージョンだけを見て「記録がない」と判断しないようにします。

組織全体の記録を集めるには、管理アカウントで「組織の証跡」を作り、全メンバーアカウントのイベントを1つのS3バケットへ送るのが基本です。

なお、記録を検索・分析するCloudTrail Lakeは、2026年5月31日から新規顧客の受付を終了しました。既存の利用者は使い続けられ、証跡やInsightsは影響を受けません。AWSは移行先としてCloudWatchを案内しています。これから設計するなら、証跡をS3に保存してAthenaで検索するか、CloudWatchに取り込む前提で考えることになります。

組織への参加・離脱も記録に残る

2026年5月28日から、AWS Organizationsはアカウントが組織に参加したとき（AccountJoinedOrganization）と離脱したとき（AccountDepartedOrganization）に、管理アカウントへCloudTrailイベントを送るようになりました。参加の方法（新規作成か招待か）や、離脱の方法（自主的な離脱、管理アカウントによる削除、閉鎖）も記録されます。

組織の証跡やログの一元化は組織のメンバーアカウントだけが対象なので、アカウントが組織を離れると、そこから先の記録は集まらなくなります。調査対象の期間に、そのアカウントが組織にいたかどうかを、このイベントで確かめられます。

VPCフローログで「どこから」を確認する

突き合わせのキーはIPアドレスと時刻

CloudTrailのsourceIPAddressと、フローログのsrcaddrを突き合わせるのが基本です。インターネット経由の操作なら、CloudTrailには接続元のグローバルIPアドレス（NATゲートウェイを通っていればNATゲートウェイのIPアドレス）が入ります。

VPCエンドポイントを通った操作では、CloudTrailにvpcEndpointId（どのエンドポイントを通ったか）とvpcEndpointAccountId（そのエンドポイントの所有アカウント）が記録されます。この場合、sourceIPAddressにはVPC内のプライベートIPアドレスが入ることがあります。プライベートIPアドレスは別のアカウントのVPCと重複しうるので、IPアドレスだけで判断せず、エンドポイントIDと所有アカウントを組にして見ます。

時刻の扱いにも決めごとが必要です。CloudTrailのeventTimeは秒単位の1時点ですが、フローログの1行は集計期間（既定で最大10分、設定で最大1分。Nitroベースのインスタンスでは常に1分以下）をまとめたものです。startとendの値も、実際のパケットから最大60秒ずれることがあると公式ドキュメントに書かれています。照合するときは「CloudTrailの時刻の前後○分」という幅をあらかじめ決めておきます。記録が届くまでの時間も、CloudWatch Logsで約5分、S3で約10分が目安で、ベストエフォートです。

共有VPCでは「誰が作ったフローログか」で見える範囲が変わる

共有VPCでは、VPCの所有者と、サブネットを借りて使う利用者でできることが違います。

• 所有者は、共有したサブネット全体のフローログを作成できる。利用者のネットワークインターフェイスのフローログも作成できる
• 利用者は、自分が所有するネットワークインターフェイスのフローログだけを作成・参照できる
• 所有者は、利用者が作成したフローログを参照も削除もできない

利用者が自分で作ったフローログは、所有者からは見えません。調査のときに「所有者側のフローログはあるが、利用者側の設定がわからない」とならないよう、共有VPCでは所有者がサブネット単位でフローログを作っておくほうが確実です。

経路ごとに、どこに記録が残るかを表にしておく

Transit GatewayやVPCピアリングをまたぐ通信は、通過した場所ごとに記録の残り方が違います。

← 表は横にスクロールできます →

Transit Gatewayのフローログには、送信元と宛先のVPCのアカウントIDが項目として入ります。アカウントをまたぐ通信の調査では、Transit Gatewayを持つネットワーク管理用のアカウントにフローログがあるかどうかで、調べやすさが大きく変わります。

2026年6月に追加された項目

2026年6月10日、VPCフローログにEC2のタグと、通信の次の行き先（ネクストホップ）の情報を記録できる項目が追加されました。公式ドキュメントでは、バージョン11の項目として次のものが載っています。

• instance-tag、interface-tag、asg-tag（各2つまで）: インスタンス、ネットワークインターフェイス、Auto Scalingグループのタグの値
• interface-type: 記録したインターフェイスの種類（NATゲートウェイ、Network Load Balancer、Transit Gateway、VPCエンドポイントなど）
• next-hop-interface-id、next-hop-subnet-id、next-hop-az-id、next-hop-vpc-id、next-hop-interface-type: 次の行き先のインターフェイスとその所在

これまでは、IPアドレスからどのサーバーかを調べるのに、別途インスタンスの一覧と照合する手間がありました。タグの項目があれば、たとえばOwnerやEnvのタグの値がそのままフローログに入ります。NATゲートウェイやTransit Gatewayを経由した通信も、どのインターフェイスへ渡ったかを追いやすくなります。

ただし、これらは既定の形式には含まれず、カスタム形式で指定した場合だけ記録されます。タグの項目にはサービスにリンクされたロールの作成と、タグを読む権限が必要です。送信先ごとの対応状況は、作成時に確認してください。メタデータの項目はベストエフォートの値で、欠けたり不正確だったりすることがあると、公式ドキュメントにも書かれています。

フローログでわからないこと

フローログは、パケットの中身もAPIの内容も記録しません。「10.20.1.15からS3へ443番ポートで4,820バイト送った」まではわかっても、どのファイルを取得したかはわかりません。それを答えるのはCloudTrailのデータイベントです。フローログだけで操作の内容まで特定できる、とは考えないでください。

ログの集め方を、アカウント間の取り決めとして設計する

S3に直接送るか、CloudWatch Logsで受けて一元化するか

← 表は横にスクロールできます →

S3へ送る場合、バケットポリシーではログ配信サービス（delivery.logs.amazonaws.com）に書き込みを許可し、aws:SourceAccountとaws:SourceArnの条件で送信元のアカウントを限定します。公式ドキュメントは、これを混乱した代理（confused deputy）問題への対策として勧めています。

ここに落とし穴があります。フローログを作成するユーザーがバケットの所有者で、バケットポリシーの読み書き権限を持っている場合、AWSがポリシーを自動で付けますが、そのとき既存のバケットポリシーは上書きされます。ログ保存用のバケットには、ほかのアカウント向けの許可がすでに入っていることが多いので、ポリシーは自分で管理し、フローログの作成者にはバケットポリシーを変更する権限を与えないほうが安全です。

一元化ルールは過去分を運ばない

CloudWatch Logsの一元化ルールは、AWS Organizationsの管理アカウントか委任管理者のアカウントで作成し、メンバーアカウントとリージョンのロググループを、指定したアカウントへ複製します。公式ドキュメントには、ルールを作成した後に届いたログだけが対象で、作成前の過去のログは一元化されないと明記されています。

調査対象の期間が導入前にかかる場合、過去分は各アカウントのロググループに残っているものを個別に見に行くことになります。導入した日付と、その前のログをどこまで各アカウントに残すかを、運用手順書に書いておきます。

組織の外のアカウントは、契約で取り決める

一元化ルールは、送信元と送信先が同じ組織に属している必要があります。組織の外にある委託先やグループ会社のアカウントは対象になりません。

調査の手順を例で通す

先ほどの仮想例を、調査表の形で通します。値はすべて架空の記入例です。

← 表は横にスクロールできます →

2026年9月15日からは、Amazon Q Consoleで、CloudTrailの証跡や関連するCloudWatchのロググループに自然言語で問い合わせられるようになりました。「このロールに最近アクセスしたのは誰か」「このIPアドレスからの操作は何か」と聞けば、調べ始める場所を早く見つけられます。ただし、調査報告に書くのは回答の文章ではなく、その根拠になったイベントそのものです。回答が示したイベントを必ず開いて確認します。

調査の最後に、「その時点で、必要なログの設定が本当に有効だったか」を確認します。フローログが無効だった、送信先が違っていた、という事実が後から見つかると、調査結果そのものが揺らぎます。ログの設定をアカウント横断で確認する方法は、次の回（AWS Configでフローログの設定を確認する記事）で扱います。

導入前に決めること

書き込む権限と、見る権限を分ける

ログを保存するアカウントには、ログを書き込むサービス、ログを読む調査担当者、設定を管理する担当者がかかわります。調査担当者がログを読めても、消したり書き換えたりはできない構成にしておきます。調査の途中で記録が変わる可能性があると、調査結果を第三者に説明できなくなります。

費用はフローログの量で決まる

CloudTrailの管理イベントは、証跡で1つ目のコピーをS3に送る分には追加の料金がかからず、データイベントは件数に応じて課金されます。フローログは、送信先がCloudWatch LogsでもS3でも、ログの量に応じた料金（CloudWatchの「Vended Logs」）がかかります。通信が多いVPCで全部の通信を記録すると、費用が想定を超えることがあります。

料金は送信先やリージョンで変わるので、CloudTrailの料金とCloudWatchの料金で確認してください。この記事では試算値を載せていません。

始め方としては、全VPCで全通信を記録するより、次の順に広げるほうが判断しやすいと考えます。

1. 本番環境のVPCと、外部（委託先、グループ会社、インターネット）とつながる経路から始める
2. Transit Gatewayを使っているなら、Transit Gatewayのフローログを作る
3. 1〜2か月の量と費用を見て、ほかのVPCへ広げるか、集計期間や項目を絞るかを決める

アカウントをまたぐ構成は、つなぐときは手早く作れますが、記録の所在は後から整えるのが大変です。ロールを貸す前、ネットワークをつなぐ前に、「何か起きたら、どのログを、誰に頼んで、どれくらいで集められるか」を一度書き出してみてください。

参考資料

• AWS CloudTrail イベント履歴の利用
• CloudTrailのイベントレコードの内容
• IAMとSTSのCloudTrailログ（AssumeRoleの記録）
• CloudTrail Lakeの提供状況の変更
• AWS Organizations: アカウントの参加・離脱のCloudTrailイベント（2026-05-28）
• CloudTrailとAmazon Q Consoleの統合（2026-09-15）
• CloudTrailネットワークアクティビティイベントの一般提供（2025-02）
• VPCフローログのレコード
• VPCフローログのメタデータ追加（2026-06-10）
• 共有VPCの所有者と利用者の責任と権限
• Transit Gatewayのフローログ
• フローログをS3へ送るときのバケットの権限
• CloudWatch Logsのアカウント・リージョン横断の一元化