S3からSecurity Lake・データレイクへ — ログ集約とSIEMの現代形

ログをS3に集約したら、次はそれを「守りと分析に使える資産」にする番です。オンプレのSIEMやログサーバが担ってきたセキュリティログの集約・相関・保全は、AWSではS3を土台にした新しい形——Security Lakeやデータレイク——に置き換わります。単なる保管から一歩進んだ、ログ基盤の現代形を見ていきます。

01まずS3が「着地点」になる

AWSでは、あらゆるログがまずS3に集まります。CloudTrail（API操作）、VPCフローログ（通信）、各サービスのログ、アプリログ——これらをS3の1か所に集約するのが出発点です。オンプレのように「syslogサーバ」「ログ用NAS」と分散させず、S3という単一の着地点に寄せる。ここまでは前回のデータレイク設計の応用です。

ただし、ただ集めただけのログは「置いてあるだけ」。形式もバラバラで、相関分析もできません。ここから先が現代形です。

02AWS Security Lake — 標準形式に揃える

AWS Security Lakeは、セキュリティ関連のログをS3に集約し、OCSF（Open Cybersecurity Schema Framework）という標準スキーマに正規化して、Parquet形式で保存するサービスです。ポイントは「揃える」ことにあります。

• AWSの各種ログや、対応する外部ソースを、共通のスキーマに正規化する
• バラバラだったログが同じ土俵に乗るので、横断的な相関分析ができる
• Parquet＋パーティションで保存されるため、スモールファイル問題を避け、分析が速く安い
• 保管はS3なので、ライフサイクルで長期保全とコストの両立ができる

03Lake Formation — データレイクに統制をかける

ログには機微な情報が含まれます。誰がどのログを見られるかを、オブジェクト単位のアクセス制御だけで管理するのは限界があります。Lake Formationは、S3上のデータレイクに対して、テーブル・列・行レベルの権限を集中管理する統制層です。

「監査担当はこのログのこの列まで、運用担当はここまで」といった、業務に即した権限を、S3の生のアクセス制御より上の抽象度で設計できます。これはマルチアカウント統制や証跡の考え方と地続きの、データガバナンスの領域です。

04分析する — AthenaとOpenSearch

• Athena — S3（やSecurity Lake）上のデータに直接SQLを投げる。「先月の不審なAPI操作を横断検索」といったアドホックな調査に強い。インフラを立てずに始められる
• OpenSearch — リアルタイム性やダッシュボード、全文検索が要るなら。SIEM的なリアルタイム監視の受け皿
• パートナーのSIEM製品 — 既存のSIEMを使い続けたい場合も、Security LakeのS3を共通のデータソースとして各ツールから参照できる

重要なのは、データ（S3・Security Lake）と分析ツールが分離していることです。オンプレSIEMは「集約と分析が一体の製品」でベンダーロックインしがちでしたが、S3を土台にすれば、データは1か所に保ちつつ分析ツールは用途で選べます。

05移行の設計 — 保全要件とコストの両立

オンプレのログ基盤・SIEMからの移行では、次を握ります。

• 保全期間 — 規制で何年保つか。S3ライフサイクルとGlacierで長期保全を安く実現（テープ移行の考え方）
• 改ざん防止 — 監査ログはオブジェクトロック（WORM）で保持期間中は削除不可にできる
• 取り込み経路 — 各ログソースからS3への集約経路を設計。既存のログ転送（ファイル連携）の置き換えを含む
• スコープと機微 — カード情報等が含まれるならPCI-DSSのスコープと同じ配慮を

—まとめ

ログのS3集約は「置き場」の話ですが、Security Lakeやデータレイクは「使える資産」への進化です。OCSFで揃え、Lake Formationで統制し、Athena/OpenSearchで分析する。オンプレSIEMの「形式バラバラ」「集約と分析が一体でロックイン」という悩みを、S3を土台に解きほぐせます。ログ移行を単なる引っ越しで終わらせず、この現代形まで設計に含めると、セキュリティと分析の両方で効く基盤になります。S3シリーズの基礎・性能・集約設計と合わせてどうぞ。