漏洩したアクセスキーの調査 ── Amazon AthenaによるCloudTrailログの分析

概要

AWSのアクセスキーがコード共有サイトやパブリックリポジトリに誤って公開されるインシデントは、実際に発生しうる深刻なセキュリティ問題です。漏洩が発覚した場合、セキュリティエンジニアはアクセスキーの無効化と並行して、そのキーがどのように使用されたかを調査し、影響範囲を把握する必要があります。

本記事では、漏洩したアクセスキーの使用状況をAmazon AthenaでCloudTrailログからクエリして調査する方法を解説します。CloudTrailコンソールのイベント履歴やIAMクレデンシャルレポートなど、他の調査手段との違いも整理します。

この記事のメリット

アクセスキー漏洩時の初動対応手順を理解できる
CloudTrailログをAthenaでクエリするための環境構築手順を習得できる
漏洩したアクセスキーの使用状況を調査するためのSQLクエリの書き方を学べる
CloudTrailイベント履歴、IAMクレデンシャルレポートなど他の調査手段との使い分けを理解できる
SCS試験で「アクセスキー漏洩時の調査方法」を問われた際に正確に判断できるようになる

技術解説

アクセスキー漏洩時の初動対応

アクセスキーの漏洩が判明した場合、以下の順序で対応します。

アクセスキーの無効化: IAMコンソールまたはCLIで漏洩したアクセスキーを無効化する
一時認証情報の無効化: 漏洩したアクセスキーで取得された一時認証情報（STSトークン）がある場合、IAMユーザーにインラインポリシーで明示的にDenyを設定するか、ユーザーを削除する
影響範囲の調査: CloudTrailログを分析し、漏洩したアクセスキーによるAPI操作の履歴を確認する
不正リソースの特定と削除: 攻撃者が作成したリソース（EC2インスタンス、IAMユーザー、S3バケットなど）を特定して削除する
新しいアクセスキーの発行: 必要に応じて新しいアクセスキーを発行する

アクセスキーの無効化だけでは不十分な場合があります。漏洩したアクセスキーを使って aws sts get-session-token や aws sts assume-role が実行されていた場合、取得された一時認証情報はアクセスキーの無効化後も有効期限まで使用可能です。

調査手段の比較

漏洩したアクセスキーの使用状況を調査する手段として、以下が挙げられます。

調査手段	確認できる内容	制限事項	大量ログの分析
Amazon Athena + CloudTrailログ	API呼び出しの完全な履歴（アクセスキーID、操作内容、送信元IP、タイムスタンプなど）	S3に配信された証跡ログが必要	適している
CloudTrailイベント履歴	過去90日間の管理イベント	90日間の管理イベントのみ、大量データの分析には不向き	不向き
IAMクレデンシャルレポート	アクセスキーの最終使用日時、最終使用サービス、最終使用リージョン	具体的なAPI操作の詳細は含まれない	不可
IAM Access Advisor	サービスごとの最終アクセス日時	具体的なAPI操作の詳細は確認できない	不可

なぜAthenaが適しているのか

CloudTrailコンソールのイベント履歴でも過去90日間の管理イベントを検索できますが、アクセスキーIDでフィルタリングして大量のイベントを効率的に分析するには限界があります。Athenaを使うことで、S3に保存されたCloudTrailログに対してSQLクエリを実行し、特定のアクセスキーIDに紐づくすべてのAPI操作を効率的に抽出できます。

特に以下のケースでAthenaの利用が有効です。

大量のログデータから特定のアクセスキーIDに関連するイベントを抽出する
複数の条件（期間、リージョン、サービスなど）を組み合わせた絞り込みを行う
集計や分析（アクセス元IPアドレスの一覧、操作の種類ごとの件数など）が必要

なぜイベント履歴では不十分なのか

CloudTrailコンソールのイベント履歴は簡易的な検索機能です。過去90日間の管理イベントのみが対象であり、検索条件も限定的です。大量のログから特定のアクセスキーに関連するすべてのイベントを効率的にフィルタリングし分析するには適していません。

なぜクレデンシャルレポートでは不十分なのか

IAMクレデンシャルレポートはアカウント内のすべてのIAMユーザーの認証情報の状態を一覧化するレポートです。アクセスキーの最終使用日時や最終使用サービスを確認できますが、具体的にどのようなAPI操作が行われたかという詳細情報は含まれていません。影響範囲の把握には、操作の詳細を確認できるCloudTrailログの分析が必要です。

CloudTrailログの構造

CloudTrailログはJSON形式でS3バケットに保存されます。アクセスキーの調査で注目すべきフィールドは以下の通りです。

フィールド	説明	調査での用途
`userIdentity.accessKeyId`	API呼び出しに使用されたアクセスキーID	漏洩したアクセスキーでのフィルタリング
`eventTime`	API呼び出しの日時	不正操作のタイムラインの把握
`eventName`	実行されたAPIアクション名	攻撃者が実行した操作の特定
`eventSource`	APIを提供するAWSサービス	影響を受けたサービスの特定
`sourceIPAddress`	API呼び出し元のIPアドレス	攻撃者のアクセス元の特定
`awsRegion`	API呼び出しが行われたリージョン	攻撃が行われたリージョンの特定
`errorCode`	エラーが発生した場合のエラーコード	権限不足で失敗した操作の確認

実践

ここでは、S3に保存されたCloudTrailログをAthenaでクエリし、特定のアクセスキーIDに関連するAPI操作を調査する手順をコンソールで説明します。

前提条件

リージョン: ap-northeast-1（東京）
CloudTrailの証跡が作成済みで、ログがS3バケットに配信されている状態
CloudTrailのS3バケット名とアカウントIDが確認できていること
調査対象のアクセスキーIDが特定されていること（自分で使っているものが漏洩したと仮定して操作してください）

リソース種別	リソース名	用途
Athenaデータベース	`default`（既存）	クエリ実行用
Athenaテーブル	`cloudtrail_logs_<S3バケット名>`（自動生成）	CloudTrailログのクエリ用テーブル。本記事のクエリでは `cloudtrail_logs` と表記
S3バケット	Athenaクエリ結果保存用	Athenaのクエリ結果の保存先

手順1: CloudTrailコンソールからAthenaテーブルを作成する

CloudTrailコンソールには、Athenaテーブルを簡単に作成する機能が用意されています。

AWSマネジメントコンソールにログインし、右上のリージョンが「アジアパシフィック（東京） ap-northeast-1」であることを確認します。
上部の検索バーに CloudTrail と入力し、表示された「CloudTrail」を選択します。
左側ナビゲーションの「イベント履歴」を選択します。
画面上部の「Athena テーブルを作成」をクリックします。
「ストレージの場所」ドロップダウンでCloudTrailログが保存されているS3バケットを選択します。
「テーブルを作成」をクリックします。

CloudTrailイベント履歴画面の「Athenaテーブルを作成」ダイアログ（ストレージの場所を選択した状態）

この操作により、選択したS3バケットのCloudTrailログに対応するAthenaテーブルが default データベースに自動作成されます。テーブル名は cloudtrail_logs_<S3バケット名（ハイフンはアンダースコアに変換）> の形式で自動生成され、ダイアログ上で変更することはできません。以降のクエリでは、この自動生成されたテーブル名を cloudtrail_logs と表記します。クエリを実行する際は FROM cloudtrail_logs の部分を実際に作成されたテーブル名に置き換えてください。

手順2: Athenaのクエリ結果保存先を設定する

Athenaのクエリを実行するには、クエリ結果の保存先となるS3バケットの設定が必要です。

上部の検索バーに Athena と入力し、表示された「Athena」を選択します。
初回アクセスの場合、「クエリ結果の場所を設定する必要があります」というメッセージが表示されます。「設定を編集」をクリックします。
「クエリ結果の場所」にS3バケットのパスを入力します（例: s3://aws-athena-query-results-123456789012-ap-northeast-1/）。
「保存」をクリックします。

手順3: 漏洩したアクセスキーの使用状況を調査する

Athenaクエリエディタで以下のクエリを実行し、漏洩したアクセスキーに関連するAPI操作を調査します。

3-1. アクセスキーに関連するすべてのイベントを抽出する

漏洩したアクセスキーIDで実行されたすべてのAPI操作を時系列で取得します。

SELECT
    eventtime,
    eventname,
    eventsource,
    sourceipaddress,
    awsregion,
    errorcode
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
ORDER BY eventtime ASC;

SELECT
    eventtime,
    eventname,
    eventsource,
    sourceipaddress,
    awsregion,
    errorcode
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
ORDER BY eventtime ASC;

Athenaクエリエディタでのクエリ実行結果（アクセスキーに関連するイベント一覧が表示された状態）

このクエリにより、漏洩したアクセスキーで実行されたすべてのAPI操作が時系列で表示されます。攻撃者の行動パターンを把握するための出発点になります。

3-2. アクセス元IPアドレスを特定する

漏洩したアクセスキーがどのIPアドレスから使用されたかを確認します。

SELECT
    sourceipaddress,
    COUNT(*) AS request_count
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
GROUP BY sourceipaddress
ORDER BY request_count DESC;

SELECT
    sourceipaddress,
    COUNT(*) AS request_count
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
GROUP BY sourceipaddress
ORDER BY request_count DESC;

組織のIPアドレスでない不審なIPアドレスからのアクセスが確認された場合、そのアクセスキーが第三者に使用された可能性が高いと判断できます。

3-3. 実行された操作の種類を集計する

どのサービスのどのAPIが実行されたかを集計します。

SELECT
    eventsource,
    eventname,
    COUNT(*) AS event_count
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
GROUP BY eventsource, eventname
ORDER BY event_count DESC;

SELECT
    eventsource,
    eventname,
    COUNT(*) AS event_count
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
GROUP BY eventsource, eventname
ORDER BY event_count DESC;

RunInstances（EC2インスタンスの起動）、CreateUser（IAMユーザーの作成）、CreateAccessKey（アクセスキーの作成）などの操作が攻撃者によって実行されていないかを確認します。

3-4. エラーになった操作を確認する

攻撃者が試みたが権限不足で失敗した操作を確認します。

SELECT
    eventtime,
    eventname,
    eventsource,
    errorcode,
    errormessage,
    sourceipaddress
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
    AND errorcode IS NOT NULL
ORDER BY eventtime ASC;

SELECT
    eventtime,
    eventname,
    eventsource,
    errorcode,
    errormessage,
    sourceipaddress
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
    AND errorcode IS NOT NULL
ORDER BY eventtime ASC;

エラーになった操作を確認することで、攻撃者が意図していたがアクセス権限の不足により実行できなかった操作を把握できます。これは影響範囲の確認と、IAM権限設計の効果の検証に役立ちます。

3-5. 特定期間のイベントに絞り込む

調査対象の期間を限定してクエリを実行します。

SELECT
    eventtime,
    eventname,
    eventsource,
    sourceipaddress,
    awsregion
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
    AND eventtime >= '2026-02-19T00:00:00Z'
    AND eventtime <= '2026-03-02T23:59:59Z'
ORDER BY eventtime ASC;

SELECT
    eventtime,
    eventname,
    eventsource,
    sourceipaddress,
    awsregion
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = '<AccessKey>'
    AND eventtime >= '2026-02-19T00:00:00Z'
    AND eventtime <= '2026-03-02T23:59:59Z'
ORDER BY eventtime ASC;

漏洩が発覚した日時の前後に絞り込むことで、効率的に調査を進められます。

手順4: 調査結果に基づく対応

Athenaのクエリ結果から以下の項目を整理し、対応を進めます。

確認項目	対応内容
不審なIPアドレスからのアクセス	攻撃者のアクセス元を特定し、記録する
新規リソースの作成（EC2、IAMユーザーなど）	攻撃者が作成したリソースを特定し、削除する
IAMポリシーやロールの変更	不正な変更を元に戻す
データへのアクセス（S3のGetObject等）	データ漏洩の有無を確認する
他のアクセスキーの作成	新たに作成されたアクセスキーを無効化・削除する

まとめ

漏洩したアクセスキーの使用状況を調査する際は、S3に保存されたCloudTrailログをAmazon Athenaで分析する方法が適しています。

調査手段	適しているケース
Amazon Athena + CloudTrailログ	大量のログから特定のアクセスキーに関連するイベントを効率的に抽出・分析する
CloudTrailイベント履歴	過去90日以内の少量の管理イベントを簡易的に確認する
IAMクレデンシャルレポート	アクセスキーの最終使用日時や状態の概要を確認する

CloudTrailコンソールのイベント履歴は過去90日間の管理イベントのみを対象とし、大量データの分析には向いていません。IAMクレデンシャルレポートはアクセスキーの概要情報を提供しますが、具体的なAPI操作の詳細は含まれていません。

Athenaを使用することで、アクセスキーIDでフィルタリングしたAPI操作の完全な履歴を取得し、アクセス元IPアドレスの特定、実行された操作の集計、エラーになった操作の確認といった分析を効率的に行えます。

SCS試験では「漏洩したアクセスキーの使用状況を調査する方法」として、各調査手段が提供する情報の違いを正確に理解しておくことが重要です。