Amazon Security Lake で構築するセキュリティデータレイク - OCSF 形式での統合分析
Security Lake による CloudTrail、VPC フローログ、Route 53 ログの自動集約、OCSF 正規化、サブスクライバーとの統合を解説します。
Security Lake の概要
Security Lake は AWS とサードパーティのセキュリティデータを自動的に集約・正規化するサービスです。従来、セキュリティ分析のためには CloudTrail ログ、VPC フローログ、GuardDuty の検出結果をそれぞれ個別に収集・変換する必要がありましたが、Security Lake はこれらを OCSF (Open Cybersecurity Schema Framework) 形式に自動変換して S3 ベースのデータレイクに集約します。データは Apache Iceberg テーブル形式で保存され、Athena から SQL で直接クエリできます。Organizations との統合により委任管理者アカウントからメンバーアカウント全体のログを一括管理でき、マルチアカウント環境でも単一のデータレイクに集約される点が従来の CloudWatch Logs やアカウント個別の S3 集約との大きな差異です。
データソースと OCSF 正規化
Security Lake は 8 種類の AWS ネイティブデータソース (CloudTrail 管理イベント、CloudTrail データイベント、VPC フローログ、Route 53 リゾルバーログ、Security Hub、Lambda 実行ログ、EKS 監査ログ、WAF ログ) を自動収集します。サードパーティのデータソース (CrowdStrike、Palo Alto Networks、Cisco Security など) もカスタムソースとして追加できます。OCSF は異なるソースのセキュリティイベントを統一スキーマに変換するオープンフレームワークで、ソースに関係なく同じカラム名・データ型でクエリできます。OCSF への正規化により、例えば CloudTrail の sourceIPAddress と VPC フローログの srcaddr を統一的な src_endpoint.ip として扱えるため、1 つのクエリで複数ソースを横断した相関分析が可能になります。パーティショニングはリージョン、アカウント ID、イベント日で自動的に行われ、Athena クエリのスキャン量を大幅に削減します。
サブスクライバーと分析
サブスクライバーはデータレイクのデータにアクセスする消費者です。データアクセスサブスクライバーは S3 上のデータに直接クエリでき、Athena や Redshift Spectrum で分析します。クエリアクセスサブスクライバーは新しいデータが到着した際に SQS 通知を受け取り、リアルタイムの分析パイプラインを構築できます。Splunk や Datadog などの SIEM ツールをサブスクライバーとして設定し、既存のセキュリティ運用ツールに Security Lake のデータを統合できます。サブスクライバーには RAM (Resource Access Manager) 経由でクロスアカウントアクセス権が自動付与されるため、IAM ポリシーの個別設定は不要です。 Security Lake の理解をさらに深めたい場合はAmazon の専門書も活用できます。
設計のベストプラクティスと落とし穴
Security Lake を導入する際は、委任管理者アカウントにログアーカイブ専用の AWS アカウントを割り当て、ワークロードアカウントと完全に分離する設計が推奨されます。ロールバック集約リージョンを設定すると、すべてのリージョンのデータを 1 つのリージョンに集約してクエリの一元化が可能ですが、リージョン間データ転送料金が発生する点に注意が必要です。よくある落とし穴として、CloudTrail のデータイベント (S3 オブジェクトレベル操作) を有効化すると取り込み量が管理イベントの数十倍になるケースがあり、事前にサンプルアカウントでログ量を測定することが重要です。また、カスタムソースの追加では OCSF スキーマへのマッピングを事前検証しないとパース失敗でデータが欠落する恐れがあるため、テスト用のカスタムソースで validation を行ってから本番適用します。Iceberg テーブルのコンパクション (小さなファイルの統合) は Security Lake が自動で実行しますが、高頻度のデータソースではクエリ性能が一時的に低下することがあるため、分析のピーク時間帯を避けた運用設計も考慮します。
CloudWatch Logs 集約や独自 ETL との比較
Security Lake を使わない従来のアプローチとして、CloudWatch Logs にログを集約して Logs Insights でクエリする方法や、Kinesis Data Firehose + Glue ETL で独自のデータレイクを構築する方法があります。CloudWatch Logs は設定が簡易ですが、ログソース間のスキーマが統一されず横断クエリが困難であり、保持期間の長いログではストレージコストが S3 対比で高額になります。独自 ETL はスキーマ設計の自由度が高い一方、正規化パイプラインの開発・運用コストが大きく、OCSF のようなオープン標準に準拠しないためサードパーティ SIEM との連携に個別の変換処理が必要です。Security Lake の利点は、正規化・パーティショニング・サブスクライバー管理がマネージドで提供される点と、OCSF 準拠によりベンダーロックインを避けつつ広範なセキュリティツールと連携できる点にあります。ただし、Security Lake はセキュリティログ専用であり、アプリケーションログやビジネスメトリクスの集約には CloudWatch Logs や独自 ETL が引き続き適切です。
Security Lake の料金
Security Lake の料金はデータの取り込み量と保存量で構成されます。AWS ネイティブソースからのデータ取り込みは 1 GB あたり約 0.75 ドルで、S3 ストレージ料金が別途発生します。Apache Iceberg 形式で保存されるため、Athena でのクエリは S3 のスキャン量に基づく料金 (1 TB あたり約 5 ドル) です。データの保持期間をリージョンごとに設定し、古いデータを自動的に Glacier に階層化することでストレージコストを削減できます。Organizations 全体で有効化する場合、ログ量の多いアカウントから段階的に導入し、コストを確認しながら展開する方法が推奨されます。なお、CloudTrail データイベントや VPC フローログは生成量が非常に大きいため、これらを有効化する際はまず 1 アカウントで 1 週間のコストを計測し、月額を外挿してから全アカウントへ展開すると予算超過を防げます。
まとめ
Security Lake は AWS のセキュリティデータを OCSF 形式で自動集約するデータレイクサービスです。Organizations 統合で組織全体のセキュリティデータを一元化し、Athena や SIEM ツールで横断的な分析を実現します。委任管理者アカウントの分離設計、データイベント有効化時のコスト事前検証、ロールバック集約リージョンの転送コストへの注意が導入成功の鍵です。