「ログさえ取れば安心」という幻想を捨てろ：SIEM連携で防ぐクラウドインフラの死角
「CloudTrailは有効にしています。SIEMにも流し込んでいます。だから大丈夫ですよね？」
現場でこう聞かれるたび、私は苦笑いせざるを得ません。ログをS3に貯めてSIEMで眺めるのは「アリの巣を遠くから望遠鏡で覗いている」のと同じです。アリが今まさに基盤を食い破ろうとしている瞬間、君たちはそのログの山に埋もれて気づかない。
今日は、攻撃者が好む「クラウドの盲点」を突き、SIEMでの相関分析を単なる「死蔵ログ」から「最強の武器」に変えるための、現場の知見を共有します。
—
1. 攻撃者が狙う「ログの死角」とは？
インフラエンジニアが陥りがちな罠が、「マネージドサービスのAPIコール」を軽視することです。
攻撃者は、Webアプリの脆弱性（SQLiやRCE）を足がかりに、SSRF（Server-Side Request Forgery）を仕掛け、EC2インスタンスのIAMロールの認証情報を盗み出します。その後、何をするか？
1. `DescribeInstances` で環境を列挙する。
2. `CreateSnapshot` でデータベースを盗み出す。
3. 重要：`StopLogging` や `DeleteTrail` で証拠を消す。
これらを見逃さないためには、単一ログの監視ではなく、「IAMロールが突如として通常利用しない権限を行使し、かつその直後にログ設定が変更された」といった相関関係をアラートに上げる必要があります。
—
2. 実践：SIEMで拾うべき「異常の兆候」設定
CloudTrailやVPC Flow LogsをSIEMに流す際、ただ取り込むだけでは無意味です。以下のポリシーをSIEM（SplunkやSentinel）のクエリで監視対象に組み込んでください。
AWS IAM ポリシーの最小権限設定（最小限の防御）
まずは、ログ設定を改ざんさせないためのIAM設定です。最低限、セキュリティチームのロール以外には以下の拒否権限を付与してください。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “DenyCloudTrailTampering”,
“Effect”: “Deny”,
“Action”: [
“cloudtrail:DeleteTrail”,
“cloudtrail:StopLogging”,
“cloudtrail:UpdateTrail”
],
“Resource”: “”
}
]
}
—
3. アプリ層からの防御：WAFとログの「紐付け」実装
SIEMで相関分析をする際、一番困るのが「WAFでブロックしたIP」と「バックエンドのログ」が紐付かないことです。これを解決するには、リクエストヘッダーに「一意なリクエストID」を付与して全段で引き回す必要があります。
以下は、NginxとPHP（またはPython）でリクエストIDをトレースする実装例です。
Nginx 設定 (nginx.conf)
`X-Request-ID` を生成し、バックエンドへ伝播させます。
リクエストIDを生成してヘッダーに追加
map $http_x_request_id $request_id_final {
default $http_x_request_id;
“” $request_id;
}
server {
location / {
# バックエンドにIDを渡す
proxy_set_header X-Request-ID $request_id_final;
proxy_pass http://backend_app;
}
}
Python (FastAPI) でのログ出力例
ログの中に `request_id` を含めることで、SIEM側で「誰が・どの攻撃を・どのAPIで行ったか」が1秒で特定可能になります。
import logging
from fastapi import Request
構造化ログ（JSON形式）で出力するのがSIEM連携の鉄則
logger = logging.getLogger(“secure_app”)
@app.middleware(“http”)
async def add_request_id(request: Request, call_next):
req_id = request.headers.get(“X-Request-ID”, “unknown”)
# ここでログにリクエストIDを埋め込む
logger.info(f”Access received”, extra={“request_id”: req_id, “path”: request.url.path})
response = await call_next(request)
response.headers[“X-Request-ID”] = req_id
return response
—
4. 最後に：エンジニアが持つべき「疑いの精神」
SIEM連携を構築した後の運用で最も重要なのは、「誤検知（False Positive）を恐れないこと」です。
朝起きてSIEMのダッシュボードを見たときに「何もアラートがない」なら、それはログ基盤が壊れているか、異常に気づけない設定になっているかのどちらかです。「怪しい動きはとりあえずブロックし、後でログを精査してホワイトリストを修正する」。この泥臭い運用こそが、インシデント発生時に君たちを守る盾になります。
ログはただのデータではありません。攻撃者という名の「不審者」が君たちの城に残した足跡です。その足跡をどう繋ぎ合わせ、どう先回りするか。それができるエンジニアだけが、この荒波のようなクラウド環境を生き残れるのです。
さあ、今すぐCloudTrailのログ設定を見直し、`X-Request-ID` を仕込みに行きましょう。現場からは以上です。
コメント