AWS Security Lake

AWS Security Lake は、AWS のサービスやオンプレミス、サードパーティ製品が生成するセキュリティ関連ログを自動的に収集し、利用者専用の Amazon S3 データレイクに集約するマネージドサービスです。取り込んだデータを業界標準スキーマに正規化して保管するため、利用者は収集基盤やデータ変換パイプラインを自前で構築せずに、横断的なセキュリティ分析や長期保管に集中できます。

解決する課題

セキュリティの調査や監査では、CloudTrail、VPC フローログ、Route 53 のクエリログ、各種検出結果など、出どころも形式もバラバラなログを突き合わせる必要があります。これらをサービスごと・アカウントごと・リージョンごとに個別に収集して保管し、さらにツールが読める形に整える作業は負荷が高く、分析の前段で多くの時間を消費します。

• ログが各サービスやアカウントに分散していて横断調査が難しい → 専用データレイクに自動集約したい
• ログの形式がバラバラで、分析ツールごとに変換が必要 → 共通スキーマに正規化したい
• 監査やインシデント調査のためにログを長期保管したい → 保管とライフサイクルを一元管理したい
• 同じデータを複数のチームやツールから使いたい → 収集は一度、利用は何度でもにしたい

主要概念と用語

• データレイク: 取り込んだログを保管する、利用者のアカウント内に作られる専用の Amazon S3 ストレージ。Security Lake が管理する
• OCSF: Open Cybersecurity Schema Framework。セキュリティイベントを表すオープンな標準スキーマ。出どころの違うログを同じ構造に揃える
• ソース（Sources）: ログの供給元。AWS のネイティブログ（CloudTrail、VPC フローログ、Route 53、Security Hub の検出結果など）と、カスタムソースに分かれる
• カスタムソース: オンプレミスやサードパーティなど、AWS ネイティブ以外のログを OCSF 形式で取り込むための定義
• サブスクライバ（Subscriber）: データレイクのデータを利用する側。データへのクエリアクセスと、新着データの通知アクセスの2形態がある
• ロールアップリージョン: 複数リージョンのデータを集約する先のリージョン。横断分析の手間を減らす
• 委任管理者: AWS Organizations 連携時に、組織全体の Security Lake を統括するアカウント
• Parquet: 列指向のファイル形式。正規化後のデータはこの形式で保管され、分析クエリを効率化する

仕様・制限・クォータ

Security Lake は リージョン単位 で有効化するサービスです。複数リージョンのデータを1つのロールアップリージョンへ集約でき、組織横断の集約には AWS Organizations との連携を用います。

取り込んだデータはサービス側で OCSF スキーマ に正規化され、Apache Parquet 形式で利用者の S3 に保管されます。データのパーティション分割やフォーマット変換は Security Lake が担うため、利用者が変換処理を書く必要はありません。

保管期間は S3 のライフサイクル設定として管理でき、ストレージクラスの移行や有効期限を指定できます。1つのデータレイクに登録できるソースやサブスクライバの数、カスタムソースの数などには サービスクォータ が設定されています。対応ソースの一覧や具体的なクォータ上限値は変動しうるため、最新の公式ドキュメントとサービスクォータの値を確認してください。

内部の仕組み

ソースを有効化すると、Security Lake は対象のログを継続的に収集し、OCSF スキーマへの正規化と Parquet 形式への変換を行ったうえで、利用者アカウント内の専用 S3 バケットに、時刻やソースで分割（パーティション）された形で書き込みます。AWS ネイティブのソースについては、Security Lake 側が内部的に収集経路を構成するため、利用者が個別にログの配信設定を組む手間が省けます。

集約したデータはバケットに置かれるだけでなく、メタデータが AWS Glue データカタログ に登録されます。これにより、Amazon Athena などのクエリエンジンからテーブルとして直接参照でき、SQL で横断分析できます。

データの利用は サブスクライバ を通じて行います。クエリアクセス型のサブスクライバには、対象データへの参照権限が付与されます。データアクセス型のサブスクライバには、新しいオブジェクトが到着するたびに通知が届き、サードパーティ製の分析・SIEM 製品がそれを受け取って取り込めます。供給元（プロデューサー）と利用側（コンシューマー）を分離することで、収集は一度行い、複数のツールから何度でも使える構成になります。

設計パターン / ベストプラクティス

• 組織管理と委任管理者: AWS Organizations と連携し、専用の委任管理者アカウントから組織全体のソースとサブスクライバを統括する
• ロールアップリージョンの設定: 各リージョンのデータを集約リージョンへまとめ、横断分析と保管管理を一箇所に寄せる
• 保管のライフサイクル設計: 直近データは高速にアクセスできるクラスに、古いデータは低コストなクラスへ移行し、保持期間を監査要件に合わせて定める
• 役割分担の明確化: 検出は GuardDuty、集約と評価は Security Hub、ログの一元保管と横断分析は Security Lake、という役割を整理して重複を避ける
• カスタムソースの活用: オンプレミスやサードパーティのログも OCSF 形式で取り込み、AWS ネイティブログと同じ土俵で分析できるようにする
• 最小権限のサブスクライバ: サブスクライバには必要なソースとデータのみを参照させ、利用範囲を絞る

運用・監視

• ソースごとの取り込み状況を点検し、想定したログが欠落なく集約されているか確認する
• ロールアップリージョンや組織内アカウントのカバレッジを定期的に見直し、調査対象に漏れがないようにする
• データ到着の通知（データアクセス型サブスクライバ）を使い、新着ログを下流のツールへ連携する
• S3 のライフサイクルとストレージ使用量を監視し、保管コストが想定内に収まっているかを追跡する
• Athena からの定型クエリを用意し、インシデント調査や監査レポートの作成を再現可能にする

コスト

Security Lake 自体の料金は、主に 取り込んで正規化したデータの量 に基づく従量課金です。これに加えて、データを保管する Amazon S3 のストレージ料金、横断分析に使う Amazon Athena のクエリ料金、メタデータ管理の AWS Glue など、関連サービスの費用が別途かかります。取り込むソースが多くログ量が大きい環境ほど、正規化と保管のコストが増えます。

セキュリティ

• データレイクは利用者アカウント内の S3 に作られ、保管データは暗号化される。鍵管理は AWS KMS と連携できる
• データへのアクセスはサブスクライバ単位で制御し、参照できるソースとアカウントを 最小権限 に絞る
• 委任管理者アカウントは特権扱いとし、MFA などで保護する
• ログには機微な情報が含まれうるため、クロスアカウントやサードパーティへの共有範囲を明確にし、監査ログで利用状況を追跡する
• Security Lake は収集・保管・配布が役割であり、脅威の検出や修復は GuardDuty や Security Hub など各サービスと組み合わせて実現する

関連サービス・比較

AWS Security Hub は、各サービスの検出結果を集約して基準で評価し、状態を可視化するダッシュボードです。一方 Security Lake は、検出結果に限らず生のセキュリティログそのものを標準スキーマで一元保管し、任意のツールで横断分析できる基盤を提供します。Security Hub が「評価と可視化」を担うのに対し、Security Lake は「ログの集約と長期保管・分析基盤」を担い、両者は補完的に使えます。

ハンズオン / CLI例

次の例は、現在のリージョンで Security Lake を有効化し、AWS ネイティブソースを登録したうえで、データを利用するサブスクライバの状況を確認するものです。

# Security Lake をリージョンで有効化（暗号化方式などは要件に合わせて指定）
aws securitylake create-data-lake \
  --configurations '[{"region":"ap-northeast-1","encryptionConfiguration":{"kmsKeyId":"S3_MANAGED_KEY"}}]' \
  --meta-store-manager-role-arn "$ROLE_ARN"

# データレイクの構成と状態を確認
aws securitylake list-data-lakes

# 取り込み対象として登録されているログソースの一覧を確認
aws securitylake list-log-sources

# データを利用するサブスクライバの一覧を確認
aws securitylake list-subscribers