はじめに

こんにちは！KINTO テクノロジーズ、クラウドセキュリティ G の大高です。
普段は、クラウド環境のガードレール整備と CSPM や脅威検知を利用した監視やカイゼン活動に取り組んでいます。

私たちのグループでは、日々の業務の一環として、 Amazon GuardDuty が検知した脅威に関して、ログの詳細分析を行い、正常な操作であるかを確認する場面があります。このログ分析の効率化を目指して、Amazon Q Developer を活用した検証をしてみました。

Amazon GuardDuty の脅威検知の対応

KINTO テクノロジーズでは、 AWS 環境の脅威検知に Amazon GuardDuty を利用しています。
Amazon GuardDuty が脅威を検知すると、Slack のチャンネルに通知が届くようになっており、この通知を受けて、セキュリティ担当者がログの詳細分析を行います。必要に応じて、対象のユーザーにヒアリングを行いながら、 JIRA チケットに経過を記録し、対応状況を管理しています。

現在の Amazon GuardDuty の脅威検知対応のフロー

今回の取り組みでは、脅威検知後の対応フローのうち、ログ分析のタスクを Amazon Q Developer を活用して、効率化することを目指しています。

AI によるログ分析を組み込んだ場合の Amazon GuardDuty の脅威検知対応のフロー

Amazon Q Developer とは

Amazon Q Developer は、 AWS が提供する開発アシスタント AI です。
AWS を活用したクラウド開発に特化しており、以下のような様々なユースケースに対応しています。

• AWS 環境のリソース、イベント、アクティビティの調査
• AWS 環境のトラブルシューティング
• 開発・デバッグ・コーディング支援
• ドキュメントの作成

Amazon Q Developer は、デフォルトの状態でも Amazon GuardDuty で検知した脅威について、関連ログを分析することができます。例えば、Amazon GuardDuty で検知された脅威の Findings ID とともにログ調査を依頼すると、以下のように Amazon Q Developer は Built-In のツールを使用して、自律的に調査と分析を行ってくれます。
(以下は、 Amazon Q Developer がログ調査を行う過程を一部抜粋したものです。)

Amazon Q Developer が自律的にログ分析を行う様子

Amazon Q Developer が生成したレポートには、操作を行なったユーザーや影響を受けたリソースなど検知した脅威の概要がまとめられており、推奨される対応の提案も含まれています。

デフォルトの状態で Amazon Q Developer が出力した分析レポート

しかし、実際の業務では、操作を行なったユーザーの認証の状態や操作時間のログも含めて、確認・分析を行い正常な動作であるかを判断しており、上記の内容に加え、さらなる追加の調査が必要です。
また、詳細なログ調査・分析を行うために、Amazon Q Developer とチャットによるやり取りを重ねる中で、様々な課題が見えてきました。

ログ分析を行う上での課題

Amazon Q Developer は、デフォルトの状態でも Amazon GuardDuty で検知した脅威の分析を行うことができますが、実務レベルのログの詳細分析を行うためには多くの課題があります。

1. AWS API のスロットリング制限

Amazon Q Developer は、 Built-In のツールや MCP サーバーにより提供されているツールを使用して実行した API リクエストにエラーレスポンスが返ってきた場合、自律的に修正を行い、再度、 API リクエストを送信します。
例えば、 API リクエストの文法が誤っていた場合は、自律的にコマンドの修正を行い、再度、リクエストを送信します。しかし、 API リクエストの再送が多くなると、スロットリングの上限に達してしまい、最終的に必要な情報を取得できないまま、不正確な回答や期待とは異なる回答を生成してしまうことがあります。

Amazon Q Developer で実行した API リクエストがスロットリングの上限に到達してしまい、情報の取得ができない。

2. 収集しているログの制限

Amazon Q Developer は AWS CloudTrail に保存されているログを検索・分析できますが、そもそもログが取得されていない場合は分析することができません。
AWS CloudTrail では、デフォルトで管理イベント（ IAM ユーザーの作成や EC2 インスタンスの起動など）のログは自動的に収集されますが、データイベント（ S3 バケットへのファイルアップロードや Lambda 関数の実行など）のログは手動で設定を有効化しなければ収集されません。そのため、Amazon GuardDuty が S3 バケットや Lambda 関数への不審なアクセスを検知した場合でも、事前にデータイベントのログ収集を有効化していなければ、Amazon Q Developer で AWS CloudTrail ログを検索しても詳細な分析に必要な情報を取得することができません。
Amazon Q Developer がログ分析に必要な情報を取得できなければ、推測による不正確な回答の生成をしてしまう可能性があります。

AWS CloudTrail でデータイベントの取得を有効化していないが、 Amazon Q Developer はデータイベントの検索を試みる。

AWS 環境のログの収集・保存にはコストがかかるため、会社や組織の予算に合わせて、意図的にログの収集・保存を実施していない場合もあります。現在の AWS 環境のログの収集状況を考慮して、 Amazon GuardDuty で検知した脅威の分析を行う際に、Amazon Q Developer がどのログを活用することができるかについて整理する必要があります。

3. コンテキストウィンドウの制限

生成 AI が一度に処理することができるテキストの長さのことをコンテキストウィンドウと言い、生成 AI の「記憶力」を指し示します。コンテキストウィンドウは、トークンという単位でカウントされており、過去のやり取りを含めて一定のトークン数の範囲内であれば過去のやりとりの内容を踏まえた受け答えを生成することができます。
非常に長い文章をプロンプトに入力したり、生成 AI と長いやり取りを続けたりして、トークン数の合計がコンテキストウィンドウの範囲を超えると、Amazon Q Developer は、過去に与えた指示を忘れてしまい、期待した回答をしてくれなかったり、不正確な情報を出力してしまったりする可能性が高まります。

コンテキストウィンドウを超過すると、 Amazon Q Developer が自動的に過去情報を要約して、詳細な内容は忘れてしまう

Amazon Q Developer もコンテキストウィンドウの制限があり、 200K トークンまでとなっています。（2025年10月16日現在）
トークン数のカウントには、 API のリクエストやレスポンスにより得られた情報も含まれます。無駄なプロンプトの入力を避けるだけでなく、不要な API コールを繰り返して、不要なトークンを消費しないように注意する必要があります。

4. 出力の一貫性の課題

生成 AI は、全く同じプロンプトを与えたとしても、生成する回答の出力フォーマットや含まれる情報が毎回異なります。Amazon Q Developer にログ分析のレポートを生成するように指示した場合でも、レポートに含まれる情報が毎回異なったり、レポートの構成が毎回異なったりする可能性があります。
このような場合、必要な情報を得ることができず、レポートに基づいて対応を検討したりすることが難しくなります。

課題を克服するための工夫

このように Amazon Q Developer で Amazon GuardDuty が検知した脅威を詳細分析するには、多くの課題があります。
これらの課題を乗り越えて、Amazon Q Developer を期待通りに動作をさせるために、以下の2つのアプローチで改善が必要です。

• Amazon Q Developer がログの詳細分析に必要となる情報を効率的に収集して、正確な情報に基づく回答を生成できるようにする。
• Amazon Q Developer にログの詳細分析を実施する手順や必要な操作に関する詳細な指示を与えて、実際の分析業務と同様にタスクを実行させる。

具体的には Amazon Q Developer に、MCP 連携とプロンプトの調整を行うことで改善を図りました。

1. MCP 連携

MCP（ Model Context Protocol ）とは、生成 AI が外部のツールやデータソースと連携を行うために定められた標準プロトコルです。Amazon Q Developer は、MCP に対応しています。連携したい MCP サーバーを設定ファイルに記入して、 Amazon Q Developer を起動することで、外部のツールの利用や、データ参照を行うことができます。

Amazon GuardDuty で検知した脅威に関するログの詳細分析を行うために、 Amazon Q Developer に以下のツールを連携しています。

弊社では、Splunk Cloud を利用して SIEM ( Security Information and Event Management ) を構築しており、AWS CloudTrail のログや Entra ID の認証ログといったさまざまなログが集約されています。 Splunk 社が提供する Splunk MCP Server と連携し、 Splunk Cloud の検索クエリを実行することができるツールを提供することで、Amazon Q Developer が AWS CloudTrail に保存されたログに限らず、横断的に詳細分析を行うことができるようにしています。

2. プロンプトエンジニアリング

プロンプトエンジニアリングとは、生成 AI に与える入力情報を工夫することで、意図した応答を引き出したり、回答精度の向上を図る手法です。生成 AI に対して、指示の背景や追加の情報を提供したり、タスクの遂行に関する詳細な指示を与えることで、期待した回答を生成するように調整を行っていきます。

Amazon GuardDuty で検知した脅威に関するログの詳細分析では、 Amazon Q Developer に以下のような情報をプロンプトで提供することで回答精度の改善を図っています。

プロンプトエンジニアリングにおいては、生成 AI に与える情報量が少ないと、出力内容の調整に効果が出ないことがあります。プロンプトに含む条件や指示内容を生成 AI を使用しながらできる限り詳細に記載することで、適切な情報量になるようにプロンプトを調整しました。

工夫による改善と成果

上記の調整を実施後、改めて Amazon Q Developer にログ分析を依頼した結果、生成されたレポートが以下になります。プロンプトに入力した指示は、デフォルト状態の Amazon Q Developer に分析を依頼したときと同じ文章を入力しています。

# GuardDuty Finding 詳細分析レポート

**Finding ID**: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
**検出リージョン**: ap-northeast-1  
**AWSアカウントID**: 000000000000 
**AWSアカウント名**: （不明）  
**分析日時**: 2025-10-16 17:44:14  

## 1. エグゼクティブサマリー

### 重要な発見
- **実際のユーザー特定**: User Name（ < User Email Address > ）
- **外部委託ユーザー**: 「xxxx-」プレフィックスにより外部委託会社のユーザーと判定
- **誤検知の可能性**: 高い（正規ユーザーによる通常業務の可能性）
- **CloudTrailログ**: 対象AWSアカウントのログがSplunkに存在せず、詳細な認証チェーン追跡は不可

### 緊急対応の要否判断
- **緊急度**: 低
- **理由**: 正規ユーザーによる通常業務時間帯での活動、Entra ID認証も正常

### 主要調査結果の要点
- Finding発生時刻: 2025年9月9日 13:20:05 JST（月曜日の通常業務時間）
- 操作内容: S3バケット「< S3-Bucket-Name >」からのGetObject API実行
- ユーザー: 外部委託会社の User Name
- 異常性: GuardDutyの機械学習による異常検知だが、業務時間帯での正規操作

### 推奨アクション（優先度付き）
1. **優先度: 低** - 当該ユーザーへの業務内容確認（念のため）
2. **優先度: 低** - S3アクセスログの詳細確認（必要に応じて）
3. **優先度: 中** - GuardDutyの機械学習ベースライン調整検討

## 2. 脅威の概要

**脅威タイプ**: Exfiltration:S3/AnomalousBehavior  
**重要度**: 8.0（高）  
**検出内容**: IAMエンティティによる異常なS3 API呼び出し

GuardDutyが検出した「異常な」S3 GetObject API呼び出しは、機械学習ベースラインからの逸脱を示しているが、実際には正規ユーザーによる通常業務時間帯での操作と判定される。

## 3. 脅威の詳細

### 攻撃手法の詳細分析
- **API**: S3 GetObject
- **対象バケット**: < S3-Bucket-Name >
- **認証方式**: AuthHeader（正規のAWS認証）
- **User Agent**: aws-sdk-rust/1.3.8（開発ツール使用）

### 攻撃者のプロファイリング
実際の攻撃者ではなく、正規ユーザー「 User Name 」による操作：
- 外部委託会社（「xxx-」プレフィックス）のユーザー
- 通常業務でAWS SSOを使用
- 開発環境（sandbox）での作業実績あり

### 攻撃の時系列分析
- **2025-09-09 13:20:05 JST**: S3 GetObject API実行
- **2025-09-09 13:29:43 JST**: GuardDutyによる検出
- **同日同時刻**: Entra IDでのAWS SSOログイン成功を確認

### 影響範囲の詳細評価
- **影響を受けたリソース**: S3バケット「< S3-Bucket-Name >」
- **データ漏洩リスク**: 低（sandboxバケット、正規ユーザー）
- **横展開リスク**: なし
- **継続的脅威**: なし

### 類似攻撃パターンとの比較
GuardDutyの機械学習による異常検知であり、実際の攻撃パターンとは異なる：
- 正規認証チェーンの使用
- 通常業務時間帯での操作
- 開発環境での作業

### セキュリティ制御の回避手法
回避手法は使用されておらず、全て正規の認証・認可プロセスを経由：
- Identity Center経由のSSOログイン
- 適切なロール権限での操作
- 正規のAWS SDK使用

## 4. プリンシパル情報

**ユーザー名**: < Role Name >  
**実際のユーザー**: User Name（ < User Email Address > ）  
**ユーザータイプ**: AssumedRole（Identity Center経由）  
**アクセスキーID**: < Access Key ID >  
**プリンシパルID**: < Principle ID>  

### ユーザー属性詳細
- **氏名**: User Name
- **所属**: 外部委託会社（「xxx-」プレフィックス）
- **メールアドレス**: < User Email address>
- **ロール**: < Role Name >

## 5. 異常性分析

### 時間帯による異常性評価
- **Finding発生日**: 月曜日（通常業務日）
- **Finding発生時刻**: 13:20:05 JST（通常業務時間）
- **異常性レベル**: **低** - 通常業務時間帯での活動
- **リスク評価**: 低リスク

### 地理的異常性
- **アクセス元**: 日本（< ISP Name >）
- **想定業務拠点**: 日本国内
- **異常性**: なし - 想定される業務拠点からのアクセス

### 操作パターンの異常性
- **使用ツール**: aws-sdk-rust（開発ツール）
- **操作内容**: S3 GetObject（データ取得）
- **対象**: sandboxバケット（開発環境）
- **異常性**: 低 - 開発業務での通常操作

### 認証チェーンの異常性
- **Entra ID認証**: 正常（エラーコード0）
- **Identity Center**: 正常なSSOセッション
- **AWS認証**: 正規のAssumedRole
- **異常性**: なし - 全て正規プロセス

### Entra ID認証ログ分析結果

#### 実行したSplunkクエリと結果

**1. 基本情報取得**:

index=< example > userPrincipalName="< User Email Address >" | table userDisplayName userPrincipalName

**結果**: ユーザー名「 User Name 」を確認

**2. 30日行動パターン**:

index=< example > userPrincipalName="< User Email Address >" earliest=-30d | stats count, values(location.city), values(deviceDetail.browser), values(appDisplayName) by userPrincipalName

**結果**: 
- 総ログイン回数: 59回
- アクセス地域: < Access Area >
- ブラウザ: Chrome 138.0.0
- 利用アプリ: AWS SSO, Microsoft 365 Support Service, Microsoft Account Controls V2, Microsoft Teams Web Client

**3. 時間パターン分析**:

index=< example > userPrincipalName="< User Email Address >" earliest=-7d | eval weekday=strftime(_time, "%A"), hour=strftime(_time, "%H") | stats count by weekday, hour | sort weekday, hour

**結果**: 
- 平日・休日問わず16時台のアクセスが多い
- 深夜0時台のアクセスも複数回確認（金曜、木曜、火曜、水曜）
- 通常業務時間外のアクセスパターンも存在

**4. 認証状況**:

index=< example > userPrincipalName="< User Email Address >" | stats count by status.errorCode, status.failureReason | sort -count

**結果**: 
- 成功ログイン: 28回（エラーコード0）
- 認証失敗: 確認されず
- 認証成功率: 100%

**5. Finding発生時刻周辺の認証ログ**:

index=< example > userPrincipalName="< User Email Address >" (Finding発生時刻周辺)

**結果**: 
- IPv6アドレス（< IPv6 Address >）からのAWS SSOログイン成功
- 日本国内からのアクセス
- 認証成功（エラーコード0）

### 本人性確認結果
**振舞い分析による本人確認**: 
- **通常パターンとの一致**: 高い一致度
- **アクセス地域**: 通常の< Access Area >からのアクセス
- **利用アプリケーション**: AWS SSOの通常利用
- **認証成功率**: 100%（異常な失敗なし）
- **本人らしさ**: **高い** - 通常の行動パターンと一致

## 6. リスク評価

### 総合リスク評価: **低**

#### 根拠
1. **正規ユーザーによる操作**: 実在する外部委託ユーザーによる操作
2. **通常業務時間**: 月曜日13:20の通常業務時間帯
3. **正規認証プロセス**: Identity Center経由の正常な認証チェーン
4. **開発環境**: sandboxバケットでの開発作業
5. **本人性確認**: Entra IDログで本人の通常パターンと一致

#### 誤検知の可能性
**高い** - GuardDutyの機械学習ベースラインが、このユーザーの通常パターンを十分に学習していない可能性

#### セキュリティ影響
- **データ漏洩リスク**: 極低
- **システム侵害リスク**: なし
- **横展開リスク**: なし

## 7. 詳細調査

### CloudTrailログ存在確認結果
**対象AWSアカウント（000000000000）のCloudTrailログがSplunkに存在しないため、詳細な認証チェーン追跡は困難**

実行したクエリ:
index=< example > sourcetype=aws:cloudtrail account=000000000000 | head 1

結果: 0件のログが見つかりました

### ソースIPアドレスからの候補ユーザー調査
**地理的近接性による候補ユーザー調査**:
- Finding詳細のIPアドレス（< IP Address >）での直接検索: 0件
- 実際の認証ログではIPv6アドレス（< IPv6 Address >）を使用
- 両方とも日本国内からのアクセスで地理的整合性あり

### 追加調査すべき点
1. **GuardDutyベースライン調整**: 外部委託ユーザーの通常パターン学習
2. **S3アクセスログ**: 必要に応じてバケットレベルでの詳細ログ確認
3. **ユーザー業務確認**: 当該時刻での業務内容確認（念のため）

### 不明な点や疑問点
1. GuardDutyが「異常」と判定した具体的な学習ベースライン
2. 同一バケットでの他ユーザーのアクセスパターン
3. aws-sdk-rustツール使用の業務上の必要性

## 8. 推奨対応策

### 即座の対応（優先度: 低）
1. **ユーザー確認**: User Name 氏への業務内容確認（念のため）
2. **継続監視**: 同様のパターンでの再発監視

### 短期対応（1週間以内）
1. **GuardDuty調整**: 外部委託ユーザーの正常パターン学習促進
2. **アクセスパターン分析**: sandboxバケットでの通常アクセスパターン確立

### 中長期対応（1ヶ月以内）
1. **ベースライン最適化**: GuardDutyの機械学習ベースライン調整
2. **監視ルール見直し**: 外部委託ユーザー向けの監視ルール策定
3. **ドキュメント整備**: 正常な開発作業パターンの文書化

### 対応不要と判断される理由
- 正規ユーザーによる通常業務時間帯での正当な操作
- 全ての認証プロセスが正常
- セキュリティリスクが極めて低い
- 誤検知の可能性が高い

**結論**: このFindingは誤検知と判定され、セキュリティインシデントとしての対応は不要。GuardDutyのベースライン調整を推奨。

デフォルト状態の Amazon Q Developer に Amazon GuardDuty で検知した脅威のログ分析を依頼した場合と比較して、次のような改善が見られました。
MCP 連携やプロンプトエンジニアリングにより Amazon Q Developer を調整したことで、ログ分析の出力に含まれる情報とその内容を期待するものに近づけることができました。

• プロンプト内で生成するレポートのフォーマットを指定したことで、複数回の検証でも出力内容に必要な情報が安定して含まれるようになりました。
• Splunk Cloud 上のログデータを利用して、検知した脅威のリスク判定を行うこともできており、より実務に近い分析を行うことができました。

一方で、以下の観点では、さらなる改善が必要になります。

• 複数回の検証を行う中で、不正確な情報を含むレポートが生成されることもありました。
• プロンプト内で明確な指示をしているにもかかわらず、指示を無視した出力がされることがありました。
• Splunk Cloud 上に AWS CloudTrail のログが取り込まれていない場合に、CloudTrail MCP Server が提供するツールを使用して、直接 AWS CloudTrail のログを検索せずに、Entra ID のログのみでリスク判断を行なうことがありました。

完全にハルシネーションを排除することはできず、引き続き、出力内容の検証と実行した操作をモニタリングしながら、 Amazon Q Developer の調整を継続的に行う必要があります。

まとめ

Amazon Q Developer を活用したログ分析は、デフォルトの状態では課題も多いですが、 MCP 連携やプロンプトの調整を行うことにより、実際にログ分析に活用できそうな応答を生成できるようになりました。しかし、その生成内容を完全に信用することはできず、回答の正確さや実際に操作した内容などについては、引き続き、調整と改善を行なっていく必要がありそうです。

また、今回は Amazon Q Developer をログ分析に活用するための方法に焦点を当てて検証を行ったため、本記事では言及していませんが、生成 AI のセキュアな活用という観点で、MCP サーバの最小権限の管理や認証情報の管理など、実際に運用を行なっていくためには、まだまだ改善すべき課題はあります。

引き続き、 Amazon Q Developer の活用方法を模索しながら、セキュリティ運用の改善・強化に取り組んでいきたいと思います。