AWS インシデント対応ツールチェーン - CloudTrail から Security Hub まで統合された調査基盤
CloudTrail、Config、Detective、Security Hub を組み合わせた AWS のインシデント対応ツールチェーンを解説し、Azure Sentinel との調査アプローチの違いを比較します。
インシデント対応に求められるツールチェーンの要件
セキュリティインシデントが発生した際、対応チームに求められるのは「何が起きたか」「いつ起きたか」「誰が関与したか」「影響範囲はどこまでか」を迅速に特定することです。この 4 つの問いに答えるには、API 呼び出しの記録、リソース設定の変更履歴、ネットワークトラフィックの分析、エンティティ間の関係性の可視化が必要です。AWS はこれらの要件に対して、CloudTrail が API 呼び出しを記録し、Config がリソース設定の変更を追跡し、VPC Flow Logs がネットワークトラフィックを記録し、Detective がこれらのデータを統合してエンティティ間の関係性を可視化するという役割分担で対応しています。各サービスが専門領域に特化しつつ、Security Hub を通じて統合されるアーキテクチャにより、インシデント対応の各フェーズ (検出、トリアージ、調査、封じ込め、復旧) をネイティブサービスだけでカバーできます。
CloudTrail - すべての API 呼び出しの記録
CloudTrail は AWS アカウント内で実行されたすべての API 呼び出しを記録するサービスであり、インシデント対応の最も基本的なデータソースです。管理イベント (コントロールプレーン操作) はデフォルトで 90 日間保持され、追加設定なしで過去の操作を遡って調査できます。データイベント (S3 オブジェクトへのアクセス、Lambda の呼び出しなど) は明示的に有効化が必要ですが、有効化すればデータプレーンの操作も完全に記録されます。CloudTrail Lake は 2022 年に導入された機能で、CloudTrail のイベントを SQL で直接クエリできます。従来は S3 に保存されたログを Athena で分析する必要がありましたが、CloudTrail Lake により「過去 30 日間に特定の IAM ロールが実行した全 API 呼び出し」といった調査クエリを即座に実行できます。CloudTrail Insights は異常な API 呼び出しパターンを自動検出する機能で、通常とは異なる頻度や種類の API 呼び出しが発生した場合にアラートを生成します。これにより、攻撃者による偵察活動や権限昇格の試みを早期に検出できます。
Config によるリソース設定の変更追跡
AWS Config はアカウント内のリソースの設定変更を継続的に記録し、設定のタイムラインを提供するサービスです。インシデント対応において Config が果たす役割は、「インシデント発生前後でリソースの設定がどう変わったか」を正確に把握することです。たとえば、S3 バケットからのデータ漏洩が疑われる場合、Config のタイムラインを確認すれば、バケットポリシーがいつ変更されたか、パブリックアクセスブロックがいつ無効化されたかを特定できます。Config Rules を使えば、セキュリティ基準に違反する設定変更をリアルタイムで検出できます。「セキュリティグループで 0.0.0.0/0 からの SSH を許可してはならない」というルールを設定しておけば、違反が発生した瞬間に検出されます。Config の高度な機能として、アグリゲーターがあります。Organizations 内の全アカウントの Config データを 1 つのアカウントに集約し、組織全体のリソース設定を横断的に検索・分析できます。インシデントが複数アカウントにまたがる場合でも、アグリゲーターを通じて統一的な調査が可能です。
Detective と Security Hub による統合調査
Amazon Detective は CloudTrail ログ、VPC Flow Logs、GuardDuty の検出結果、EKS 監査ログを自動的に取り込み、グラフデータベースに蓄積します。エンティティ (IAM ユーザー、ロール、IP アドレス、EC2 インスタンスなど) 間の関係性をグラフとして可視化し、インシデントの全体像を直感的に把握できます。GuardDuty が「不審な API 呼び出しを検出した」というアラートを生成した場合、Detective でそのアラートを起点に調査を開始できます。関連する IAM ロールの過去の行動パターン、アクセス元 IP アドレスの地理的分布、同じロールが操作した他のリソースを時系列で追跡し、侵害の範囲を特定します。Security Hub はこれらの検出結果と調査結果を一元的に集約するダッシュボードとして機能します。ASFF (AWS Security Finding Format) により、GuardDuty、Inspector、Macie、Config、サードパーティツールからの検出結果が統一フォーマットで表示されます。自動修復アクションを EventBridge 経由で Lambda に連携すれば、特定の検出結果に対する封じ込め処理を自動化できます。
Azure Sentinel との調査アプローチの比較
Azure Sentinel (現 Microsoft Sentinel) はクラウドネイティブの SIEM/SOAR であり、インシデント対応に対するアプローチが AWS とは根本的に異なります。Sentinel はすべてのログを Log Analytics ワークスペースに集約し、KQL (Kusto Query Language) で横断的に分析する集中型のアプローチです。AWS の分散型アプローチ (各サービスが専門領域を担当し ASFF で連携) とは対照的です。Sentinel の強みは、Azure だけでなく AWS、GCP、オンプレミスのログも取り込めるマルチソース対応と、Microsoft 365 Defender との深い統合です。メールの脅威、エンドポイントの異常、ID ベースの攻撃を統合的に調査できる点は、Microsoft エコシステムを活用する組織にとって大きな価値です。一方、Sentinel はログの取り込み量に応じた従量課金であり、大規模環境ではコスト管理が課題になります。AWS の GuardDuty や Detective はログ取り込みコストが内包されており、分析対象のデータ量を意識する必要がありません。インシデント対応の実務を体系的に学ぶなら、関連書籍 (Amazon) も参考になります。
まとめ
AWS のインシデント対応ツールチェーンは、CloudTrail による API 呼び出しの完全な記録、Config によるリソース設定の変更追跡、Detective によるエンティティ間関係性の可視化、Security Hub による検出結果の一元集約で構成されています。各サービスが専門領域に特化しつつ ASFF で連携する分散型アーキテクチャにより、サードパーティ SIEM を導入せずともインシデントの検出から調査、封じ込めまでをカバーできます。Azure Sentinel はマルチソース対応と Microsoft エコシステムとの統合に強みがありますが、ログ取り込みコストの管理が必要です。AWS のアプローチは、各サービスの有効化だけで調査基盤が整う手軽さと、ログ分析コストが内包された予測可能な料金体系が最大の利点です。インシデント対応の成熟度を高めるには、まず CloudTrail と Config を全アカウントで有効化し、Security Hub で可視化する基盤を構築することが第一歩です。