はじめに
kyonosukeです。
今回はCloudWatchのMCPサーバが登場したので試してみました！
普段ログ運用にコストがかかってお困りの方は必見の内容になっています！
目次
今回実現したいこと
今回はCloudTrailのS3データイベントについて、Amazon Qを用いて自然言語による分析を行います。
データイベントとは、S3バケット内のオブジェクトやDynamoDBのテーブルに対するAPIコールのことであり、CloudTrailのデフォルトでは記録されません。記録回数が多くコスト負担が大きいのでこのような仕様になっているのですが、業務上重要なS3バケットはデータイベントを取得すべきです。
このとき、データイベントはCloudTrailで証跡を作成し、デフォルトでS3バケットへ、オプションでCloudWatch Logsに配信することができます。S3+AthenaやCloudWatch Logs Insightsなどを使用してログの分析を行うわけです。
ただAthenaは手間がかかりますし、CloudWatch Logs Insightsはめちゃくちゃコストがかかります。このような課題をCloudWatch MCPは解決できます。
MCP設定方法
/.aws/amazonq/mcp.jsonに以下を追加するだけです。
{
"mcpServers": {
"awslabs.cloudwatch-mcp-server": {
"autoApprove": [],
"disabled": false,
"command": "uvx",
"args": [
"awslabs.cloudwatch-mcp-server@latest"
],
"env": {
"AWS_PROFILE": "[The AWS Profile Name to use for AWS access]",
"FASTMCP_LOG_LEVEL": "ERROR"
},
"transportType": "stdio"
}
}
}
CloudWatch MCPサーバができること
CloudWatchのMCPサーバには何ができるのでしょうか。訊いてみます。
> CloudWatch MCPサーバでできることを教えて。
CloudWatch MCPサーバでは、以下のような機能を利用できます：
## ログ関連の機能
• **ロググループの検索・一覧表示** - アカウント内のCloudWatchロググループを検索し、メタデータを取得
• **ログ分析** - 異常検知、メッセージパターン分析、エラーパターンの特定
• **CloudWatch Logs Insightsクエリ** - ログデータの検索、フィルタリング、統計収集、パターン発見
• **クエリ結果の取得・キャンセル** - 実行中のクエリの管理
## アラーム関連の機能
• **アクティブアラームの取得** - 現在ALARM状態にあるすべてのアラームを表示
• **アラーム履歴の取得** - アラームの状態変化履歴と調査用の時間範囲提案
• **推奨アラーム設定** - 特定のメトリクスに対する推奨アラーム設定の取得
## メトリクス関連の機能
• **メトリクスデータの取得** - CloudWatchメトリクスの実際のデータを取得
• **メトリクスメタデータの取得** - メトリクスの説明、単位、推奨統計情報
• **Metrics Insights** - 高度なクエリ機能（GROUP BY、ORDER BY、LIMIT句など）
## 主な使用例
# ロググループの一覧表示
describe_log_groups
# 特定の時間範囲でのログ分析
analyze_log_group
# EC2インスタンスのCPU使用率データ取得
get_metric_data
# アクティブなアラームの確認
get_active_alarms
これらの機能により、CloudWatchを使った監視、ログ分析、トラブルシューティングを効率的に行うことができます。
ログの一覧を取得し、分析ができるみたいです。アラームやメトリクスにも関与できそうです。
特にanalyze_log_groupはかなり有用そうに思えます。以降で試してみましょう。
やってみる
前提
今回は以前の記事で取り上げたGuardDutyインシデントのひとつであるPolicy:S3/BucketPublicAccessGrantedが発生した後のストーリーを考えます。
このインシデントは、S3バケットのバケットポリシーがオープンな状態へと設定変更され、バケットへのアクセスがだれでも可能になっていることを示唆しています。となるとセキュリティ担当者として次にやることはオブジェクト関連のイベントが起きていないか確認することです。確認のためにはCloudTrailのデータイベントを参照する必要がありますが、この確認作業をMCPを使って実施してみましょう。
前回の記事はこちらから
調査開始
ではプロンプトを与えて調査をしてみます。
東京リージョンでプロファイルauditを用いて、
CloudWatch Logsのロググループaws-cloudtrail-logs-XXXXXXXXXXXX-dataaccesslogについて、
直近1時間でS3バケットへの侵害があったかどうかを調査してください。
awslabscloudwatch_mcp_serverを使用してdescribe_log_groupsコマンドが実行されます。
🛠️ Using tool: describe_log_groups from mcp server awslabscloudwatch_mcp_server
⋮
● Running describe_log_groups with the param:
⋮ {
⋮ "arguments": {
⋮ "log_group_name_prefix": "aws-cloudtrail-logs-XXXXXXXXXXXX-dataaccesslog",
⋮ "region": "ap-northeast-1"
⋮ },
⋮ "name": "describe_log_groups"
⋮ }
続いてexecute_log_insights_queryが実行されます。勝手にクエリ作成・実行してくれるのはいいですね。（コストはどうなっているんでしょうか、、？？）
🛠️ Using tool: execute_log_insights_query (trusted) from mcp server awslabscloudwatch_mcp_server
⋮
● Running execute_log_insights_query with the param:
⋮ {
⋮ "arguments": {
⋮ "end_time": "2025-07-17T10:00:00+00:00",
⋮ "limit": 100,
⋮ "log_group_names": [
⋮ "aws-cloudtrail-logs-XXXXXXXXXXXX-dataaccesslog"
⋮ ],
⋮ "query_string": "fields @timestamp, eventName, sourceIPAddress, userIdentity.type, userIdentity.principalId, requestParameters.bucketName, requestParameters.key, responseElements, errorCode, errorMessage\n| filter eventSource = \"s3.amazonaws.com\"\n| filter eventName in [\"GetObject\", \"PutObject\", \"DeleteObject\", \"RestoreObject\", \"CopyObject\", \"GetObjectAcl\", \"PutObjectAcl\", \"GetObjectVersion\", \"DeleteObjectVersion\", \"PutObjectRetention\", \"GetObjectRetention\", \"PutObjectLegalHold\", \"GetObjectLegalHold\"]\n| sort @timestamp desc\n| limit 100",
⋮ "region": "ap-northeast-1",
⋮ "start_time": "2025-07-17T09:00:00+00:00"
⋮ },
⋮ "name": "execute_log_insights_query"
⋮ }
⋮
● Completed in 2.435s
しばらくすると、検出結果をまとめてくれました。
## 🚨 重大なセキュリティ侵害を確認！データ削除が実行されました！
### **📊 完全な攻撃シーケンス分析**
調査期間: JST 18:00-19:00（UTC 09:00-10:00）を含む拡張調査
なんかやばそうです。詳細を見てみましょう。
### **🔥 重大な発見事項**
データ削除が確認されました！
削除されたファイル:
1. sensitive-config.txt - 09:32:57に削除 🔴
2. loveletter.txt - 09:33:15に削除 🔴
データ削除、つまりdelete-objectが実行されているようです。
### **⏰ 完全な攻撃タイムライン**
| 時刻 | アクション | ファイル | 結果 | IP | 説明 |
|---|---|---|---|---|---|
| 09:00:19-24 | GetObject (大量試行) | sensitive-config.txt, loveletter.txt | 失敗 | XXX.XXX.XXX.XXX | 初期偵察・アクセス試行 |
| 09:00:24 | PutObject | sensitive-config.txt, loveletter.txt | ✅成功 | XXX.XXX.XXX.XXX | データ投入 |
| 09:03:27-30 | GetObject | loveletter.txt | 失敗 | XXX.XXX.XXX.XXX | アクセス確認試行 |
| 09:04:44 | GetObject | sensitive-config.txt | ✅成功 | XXX.XXX.XXX.XXX | データ読み取り成功 |
| 09:07:44 | PutObject | loveletter.txt | ✅成功 | XXX.XXX.XXX.XXX | データ更新 |
| 09:08:13 | PutObject | sensitive-config.txt | ✅成功 | XXX.XXX.XXX.XXX | 機密データ更新 |
| 09:32:57 | DeleteObject | sensitive-config.txt | ✅成功 | XXX.XXX.XXX.XXX | 🚨機密データ削除 |
| 09:33:15 | GetObject | loveletter.txt | ✅成功 | XXX.XXX.XXX.XXX | 削除前データ取得 |
| 09:33:15 | DeleteObject | loveletter.txt | ✅成功 | XXX.XXX.XXX.XXX | 🚨データ削除 |
| 09:33:15 | ListObjects | バケット全体 | ✅成功 | XXX.XXX.XXX.XXX | 削除確認 |
アクセスを試みたあと、データの更新や取得、最後には削除まで行われています。これは完全にクロでしょう。
### **🎯 攻撃パターンの分析**
1. 多段階攻撃
• **偵察フェーズ**: 大量のアクセス試行（09:00:19-24）
• **侵入フェーズ**: データ投入・読み取り（09:00:24-09:08:13）
• **破壊フェーズ**: データ削除（09:32:57-09:33:15）
2. 使用されたIP
• **XXX.XXX.XXX.XXX**: 主要攻撃元（偵察・データ操作）
• **XXX.XXX.XXX.XXX**: AWS内部IP（データ投入・削除実行）
3. 攻撃の特徴
• 正規ユーザー認証情報の悪用
• 機密ファイルへの標的型攻撃
• 証拠隠滅のための削除実行
攻撃パターンの分析を行っています。認証情報を悪用され（≒内部犯）、データの破壊活動が行われてしまいました。
### **🚨 結論**
重大なセキュリティ侵害が確認されました:
✅ データアクセス: 機密ファイルへの不正読み取り
✅ データ改ざん: ファイルの不正更新
✅ データ削除: 機密ファイルの完全削除
✅ 証拠隠滅: 攻撃痕跡の消去試行
即座に以下の対応が必要です:
1. 該当ユーザーアカウントの無効化
2. アクセスキーの即座のローテーション
3. バケットアクセスの一時停止
4. フォレンジック調査の開始
5. バックアップからのデータ復旧検討
結論として、インシデントのサマリやネクストアクションを示しています。たしかにこんなインシデントが起きたら認証情報の無効化やフォレンジックをしないとですね。
いかがでしょうか。プロンプト一つ与えるだけで簡単にCloudWatchの調査ができてしまいました。MCPがクエリをしやすいようにロググループや時間を指定してあげれば本当に1プロンプトで調査～サマリまで完了します。
今まであれば各種クエリサービスでクエリを実行してそこから異常を見つけなければならなかったのが、自然言語で簡単に調査ができます。
ユースケース
ここまではCloudWatch MCPサーバをインシデント調査のために使用してみました。
ただ利用用途は他にもありそうです。ここではアイデアの一部を載せておきます。
アプリケーションエラー調査
アプリケーションのエラーをCloudWatchに集めておけば、インフラレイヤ同様MCPによる調査が可能です。
アプリログから異常パターンを検出してアラームを作成する、といったこともできそうです。
ダッシュボードの作成
複数のサービス・アプリを統合したダッシュボードを作成するのもMCPがやってくれそうです。
統合した分析により運用の効率化につながりそうです。
まとめ
今回はCloudWatch MCPサーバを使ったログの調査を行ってみました。
このMCPの登場により、今までのCloudWatch調査は過去のものになりました。膨大なログから正確な洞察を素早く得ることで、組織のセキュリティ向上に間違いなく貢献できると言えます。
今後もAmazon Qを活用したセキュリティ運用を考察します。
本記事がセキュリティ運用に困っているあなたの力になれば幸いです。