【AWS re:Invent 2024】SecurityLake・OpenSearchの連携に関する新機能発表セッションレポート

Amazon Security Lakeとは？

従来、セキュリティに関係するデータはバラバラのフォーマットでユーザーの任意の保存先に格納されることが多かったのですが、Security Lakeはマルチカウントのマルチリージョンのセキュリティ関連ログを一箇所に集約します。

AWS Organizationを使用する場合、複数のAWSアカウントで個別の設定をせずとも、Security Lakeを有効にしたアカウントで一気にログ集約をできるのでとても楽で便利です。

設定自体も簡易であり、マネージメントコンソールでぽちぽち進めるだけで、有効化し使い始めることができるようになっています。

SecurityLake・OpenSearchの連携の発表された主な新機能

1. Zero ETL統合

これまでSecurity LakeのデータをOpenSearchで分析するには、データを加工してから取り込む必要がありました。しかし、新機能「Zero ETL」により、ETL処理なしでSecurity LakeのデータをOpenSearchに直接取り込み、リアルタイムで分析できるようになりました。

2. オンデマンドインデックスでコスト最適化

従来、ログをOpenSearchで分析するにはすべてのデータを取り込む必要があり、ストレージコストが問題になっていました。新機能では「オンデマンドインデックス」が導入され、必要なデータだけを選んでインデックス化できるようになりました。これにより、CloudTrailやVPCフローログのような大容量データを常時保存せずに、必要な時にだけ分析可能。ストレージコストを抑えつつ、効率的にセキュリティ調査ができます。

3. Open Cybersecurity Schema Framework (OCSF) でデータフォーマットを統一

Security Lakeのログは、AWSが推進するOpen Cybersecurity Schema Framework (OCSF) を採用。これにより、異なるサービスのログフォーマットを統一でき、異種ログを統一されたスキーマで管理できます。

Open Cybersecurity Schema Framework (OCSF)とは

OCSFはオープンソースで、AWSとその主要パートナーにて作成されています。非常に活発に更新があり、バージョンが上がるごとに欲しいスキーマが入ってくるという印象です。触りはじめは1.0.0-rc.2でしたが、だいぶ更新されてきてますね。

Security Lakeでは、集約されるログをOCSFにしています。カテゴリごとにクラスという概念が存在しており、バラバラだったログフォーマットのスキーマを定義してくれています。

ログのフォーマットが統一されるというのは、分析をする際に非常に強力です。セキュリティイベントが発生し、調査の段階でデータフォーマットがバラバラだと効果的な分析ができない、という辛みを経験したセキュリティ運用者も多いかと思います。

ユースケース（想像）

CloudTrailやVPCフローログのような容量が大きくなりがちなデータは常にOpenSearchに取り込まず、必要な時にだけ分析したいというニーズもあるかと思います。その場合、zero-ETLを使うとアドホックにOpenSearchにデータ取り込みをし、分析をするということが可能になりますので、コストバランスよく使用できると思います。

Athenaで直接Security Lakeのデータを見るという手法もありますが、細かい分析をしていくのにAthenaですと少し遅いと感じる方もいるかと思いますので、OpenSearchを使ってより高速に調査ができるのはいいですね。

この新しい機能、皆さんもぜひ活用してみてください。

関連ページ

• https://note.com/kay7198/n/n44c503069a06
• https://note.com/gay_pipit1711/n/n600df4172910