AWS セキュリティサービスの統合力 - GuardDuty から Detective まで SIEM 不要のネイティブ脅威検出
GuardDuty、Security Hub、Detective、Macie の連携によるネイティブ脅威検出の仕組みを解説し、Azure Sentinel との設計思想の違いを比較します。
ネイティブ統合という設計思想
AWS のセキュリティサービス群は、個別のツールの寄せ集めではなく、相互に連携することを前提に設計されています。GuardDuty が脅威を検出し、Security Hub がその検出結果を集約・優先順位付けし、Detective が根本原因を調査し、Macie が機密データの所在を特定する。この一連のフローが AWS のネイティブサービスだけで完結します。従来のオンプレミス環境では、SIEM (Security Information and Event Management) を中心に複数のセキュリティツールを統合する必要がありました。ログの収集、正規化、相関分析、アラート生成、インシデント調査のそれぞれに異なるツールを導入し、連携のためのカスタム開発が不可欠でした。AWS のネイティブ統合は、この統合コストを大幅に削減します。各サービスは AWS Security Finding Format (ASFF) という共通フォーマットでデータを交換するため、サービス間の連携に追加の設定やカスタム開発が不要です。
GuardDuty - 機械学習による継続的脅威検出
GuardDuty は VPC Flow Logs、CloudTrail 管理イベント、DNS ログを自動的に分析し、不正なアクティビティを検出するマネージド脅威検出サービスです。有効化はワンクリックで完了し、エージェントのインストールやログ転送の設定は不要です。GuardDuty の検出精度を支えているのは、AWS が保有する大規模な脅威インテリジェンスと機械学習モデルです。既知の悪意ある IP アドレスやドメインとの通信を検出するだけでなく、通常とは異なる API 呼び出しパターンや、異常なデータ転送量を機械学習で検出します。たとえば、普段は東京リージョンでしか操作しない IAM ユーザーが突然バージニアリージョンで EC2 インスタンスを大量に起動した場合、GuardDuty はこれを異常として検出します。2023 年には EKS Runtime Monitoring、2024 年には Malware Protection for S3 が追加され、コンテナワークロードやストレージ内のマルウェアも検出範囲に含まれるようになりました。
Security Hub と Detective の連携による調査効率化
Security Hub は GuardDuty、Inspector、Macie、Firewall Manager など複数のセキュリティサービスからの検出結果を一元的に集約するダッシュボードです。ASFF に準拠した検出結果を自動的に取り込み、重要度に基づく優先順位付けを行います。CIS AWS Foundations Benchmark や AWS Foundational Security Best Practices といったセキュリティ基準に対する自動評価も実行し、コンプライアンス状況を可視化します。Security Hub で優先度の高いアラートを特定した後、Detective で詳細な調査に移行するのが典型的なワークフローです。Detective は CloudTrail ログ、VPC Flow Logs、GuardDuty の検出結果をグラフデータベースに蓄積し、エンティティ間の関係性を視覚的に表示します。特定の IAM ロールがどの IP アドレスからどの API を呼び出したかを時系列で追跡でき、侵害の範囲と経路を迅速に特定できます。この調査プロセスが AWS ネイティブで完結する点が、サードパーティ SIEM に対する大きな優位性です。
Macie による機密データの自動検出
Amazon Macie は S3 バケット内の機密データを機械学習とパターンマッチングで自動検出するサービスです。クレジットカード番号、マイナンバー、パスポート番号、API キーなど、100 種類以上のデータタイプを識別します。Macie の価値は、組織が「どこに機密データがあるか把握していない」という根本的な課題を解決する点にあります。S3 バケットの数が数百から数千に達する大規模環境では、手動での機密データ棚卸しは現実的ではありません。Macie はバケットのインベントリを自動作成し、暗号化状況、パブリックアクセス設定、機密データの有無を一覧化します。検出結果は Security Hub に自動連携されるため、機密データが暗号化されていないバケットに存在する場合、Security Hub のアラートとして即座に可視化されます。GuardDuty が外部からの脅威を検出し、Macie が内部の機密データリスクを検出するという役割分担により、セキュリティの可視性が内外両面からカバーされます。
Azure Sentinel との設計思想の比較
Azure Sentinel (現 Microsoft Sentinel) はクラウドネイティブの SIEM/SOAR プラットフォームであり、AWS のセキュリティサービス群とは設計思想が根本的に異なります。Sentinel は Log Analytics ワークスペースにログを集約し、KQL (Kusto Query Language) で分析するアプローチを取ります。Azure だけでなく AWS、GCP、オンプレミスのログも取り込めるマルチクラウド対応が強みです。一方、AWS のアプローチは各サービスが専門領域に特化し、ASFF で連携する分散型です。Sentinel はログの取り込み量に応じた従量課金であり、大量のログを分析する場合はコストが急増する可能性があります。AWS の GuardDuty はログの取り込みコストが内包されており、分析対象のログ量を意識する必要がありません。Sentinel の優位性は、Microsoft 365 や Entra ID との深い統合にあります。メールの脅威検出、ID ベースの攻撃検出、エンドポイントの EDR データを統合的に分析できる点は、Microsoft エコシステムを活用する組織にとって大きな価値です。AWS のネイティブ統合を体系的に理解するなら、関連書籍 (Amazon) も役立ちます。
まとめ
AWS のセキュリティサービス群は、GuardDuty による脅威検出、Security Hub による集約と優先順位付け、Detective による根本原因調査、Macie による機密データ検出が ASFF を介してシームレスに連携する統合エコシステムです。サードパーティ SIEM を導入せずとも、検出から調査までの一連のセキュリティ運用が AWS ネイティブで完結します。Azure Sentinel はマルチクラウド対応と Microsoft エコシステムとの統合に強みがありますが、ログ取り込みコストの管理が課題です。AWS のアプローチは、各サービスの有効化だけで即座にセキュリティ可視性が向上する手軽さと、サービス間の自動連携による運用負荷の低さが最大の利点です。セキュリティ運用の成熟度を段階的に高めていく上で、AWS のネイティブ統合は堅実な出発点となります。