クラウドの「不可視」を撃つ：GuardDutyとログ分析による脅威インテリジェンスの再構築
多くのエンジニアが、AWSの「GuardDutyを有効にしました。これで守りは万全です」という言葉で思考停止に陥るのを見てきた。厳しいことを言うようだが、それはセキュリティではなく「気休め」だ。
GuardDutyは機械学習モデルを用いた素晴らしいツールだが、魔法ではない。攻撃者はAPIの挙動を模倣し、正規の権限を奪取し、クラウドの制御プレーンを自身の庭のように歩き回る。本稿では、単なるログ収集を超えた、攻撃者の心理とパケットの裏側を読むための「防御アーキテクチャ」について論じる。
—
1. ログの背後にある「コンテキスト」を読み解く
CloudTrailやVPC Flow LogsをS3に放り込んで満足しているなら、それは死蔵資産だ。真の脅威は、単一のログイベントではなく、複数のログにまたがる「微細な不整合」の中に潜んでいる。
例えば、攻撃者がIAMクレデンシャルを奪取した際、彼らはまずsts:GetCallerIdentityを叩く。これは攻撃の定石だが、単発では無視されがちだ。我々が監視すべきは、この呼び出しと直後の「異常なユーザーエージェント」、あるいは「通常とは異なるIPセグメントからのAPIコール」との相関関係である。
GuardDutyの真価を引き出すための設定戦略
GuardDutyを単独で使うのではなく、Amazon EventBridgeと連携させ、特定の高重要度イベント（UnauthorizedAccess:IAMUser/MaliciousIPCaller.Customなど）をトリガーとして、AWS Lambdaで即座に防御的アクション（該当IAMユーザーのポリシー剥離など）を自動化すべきだ。
Lambda: 異常検知時のインシデントハンドリング例
import boto3
def lambda_handler(event, context):
# GuardDutyからのイベント詳細をパース
finding_type = event[‘detail’][‘type’]
resource_id = event[‘detail’][‘resource’][‘instanceDetails’][‘instanceId’]
# 検知内容に応じて即時隔離（セキュリティグループの付け替え等）
ec2 = boto3.client(‘ec2’)
if ‘UnauthorizedAccess’ in finding_type:
# ネットワークACLで通信を遮断する、あるいはSGを隔離用に差し替える
ec2.modify_instance_attribute(
InstanceId=resource_id,
Groups=[‘sg-0a1b2c3d4e5f6g7h8’] # 隔離用セキュリティグループ（全拒否）
)
return {“status”: “Isolated”}
—
2. プロトコル層から見る「クラウドの死角」
VPC Flow LogsはL3/L4のログだが、L7（アプリケーション層）の攻撃を見抜くには不十分だ。昨今のプロンプトインジェクションや、LLMをターゲットにした攻撃は、HTTPのリクエストボディの中に隠れている。
攻撃者がTLS通信の中で何を行っているかを可視化するには、AWS WAFのログを解析し、それをCloudWatch Logs Insightsでクエリするスキルが不可欠だ。例えば、以下のようなクエリで、異常なリクエストパターンを炙り出せる。
CloudWatch Logs Insights: WAFログから怪しい文字列を検出
fields @timestamp, @message
| filter httpRequest.uri contains “/api/v1/chat”
| filter httpRequest.body like /(?i)(select|union|drop|prompt|inject)/
| sort @timestamp desc
| limit 20
ここで重要なのは、「何が正常か」というベースライン（Baseline）の自動生成だ。固定的な閾値監視は現代のクラウド環境では無力である。
—
3. 耐量子暗号と次世代の境界防御へ向けて
これからのセキュリティアーキテクトは、RSAやECCが将来的に量子コンピュータによって破られるリスクを考慮しなければならない。AWSは既にKMSにおける耐量子（Post-Quantum）アルゴリズムの導入を進めているが、我々が実装するAPIゲートウェイやマイクロサービス間通信（mTLS）においても、将来的な移行パスを描いておく必要がある。
特に、ゼロトラストアーキテクチャへの移行は急務だ。VPC境界があれば安全という考えは捨てよ。サービス間認証にはAWS PrivateLinkを活用し、通信経路自体をインターネットから完全に分離した上で、各リクエストには署名（SigV4）を強制し、認可にはOPA (Open Policy Agent)を組み込む。これが、現在の我々が到達できる最高峰の防御設計だ。
—
4. 現場の教訓：なぜ防御はすり抜けるのか
最後に、現場の泥臭い教訓を一つ。インシデントレスポンスにおいて最も時間がかかるのは、技術的な解析ではなく「ログの整合性」だ。
- 時刻同期: 複数のAWSアカウントやリージョンを横断する場合、必ずログのタイムスタンプを正規化せよ。
- 権限の最小化: GuardDutyのログを保存するS3バケットへのアクセス権は、人間には与えるな。IAMロールを用いた最小権限の原則を徹底し、ログの改ざん耐性を担保せよ。
防御とは、ツールを導入することではない。「攻撃者はこのインフラをどう攻略するか？」という悪意を想像し、そのパスを一つずつ遮断していくチェスのような知的なプロセスである。
君たちが管理しているそのクラウド環境は、今日この瞬間もどこかの誰かにスキャンされている。ログの海の中に沈む「ノイズ」を「シグナル」に変えるのは、システムではなく、君たちの深い洞察だ。さあ、ターミナルを開き、ログの深淵を覗き込もう。
コメント