AWS認定資格 WEB問題集＆徹底解説セキュリティ専門知識（SCS）

会員登録/ログイン

1. サービス概要

Amazon Security Lakeは、AWS環境・オンプレミス・SaaS・サードパーティー製品から集めたセキュリティログとイベントを、自分のAWSアカウント内のS3バケットに専用のセキュリティデータレイクとして自動的に集約するフルマネージドサービスです。 取り込んだデータはオープンソースの標準スキーマOCSF（Open Cybersecurity Schema Framework）に正規化され、クエリ効率の高いApache Parquet形式で保存されます。

ログの種類ごとにフィールド名や構造が違う問題をサービス側で吸収するため、ETL処理を自前で作らずに複数ソースを横断して調査できます。 データの所有権は利用者にあり、保持期間やストレージ階層も利用者が決めます。集めたデータはサブスクライバーとして登録したAWSサービスやSIEMなどのサードパーティーツールが利用します。

2. 主な特徴と機能

2.1 ネイティブにサポートされるAWSのログソース

• AWS CloudTrailの管理イベント、およびデータイベント（S3、Lambda）
• Amazon VPCフローログ
• Amazon Route 53 Resolverのクエリログ
• AWS Security Hub CSPMの検出結果（GuardDuty、Inspector、Macieなどの検出結果を含む）
• Amazon EKSの監査ログ
• AWS WAF（v2）のログ

これらはソースとして有効にするだけで収集され、ログを出力する側（CloudTrailの証跡作成やVPCフローログの配信先設定）を個別に作り込む必要はありません。

2.2 カスタムソース

オンプレミスのファイアウォールや他社製セキュリティ製品のログも、カスタムソースとして追加できます。カスタムソース側は、データをOCSF準拠のParquet形式に変換し、Security Lakeが指定するS3の場所とパーティション構成で書き込むことが前提です。 Security Lakeは書き込み用のIAMロールとAWS Glueのクローラー・テーブルを用意し、以降は他のソースと同じように扱います。

2.3 サブスクライバー

• データアクセスのサブスクライバー: 新しいオブジェクトが書き込まれるたびに通知を受け、S3のオブジェクトを直接読み取る。通知はHTTPSエンドポイントへの送信（既定）か、Amazon SQSキューのポーリングを選べる。SIEMへの継続的な取り込み向け。
• クエリアクセスのサブスクライバー: AWS Lake Formationで共有されたテーブルを、Amazon Athenaなどから直接SQLでクエリする。アドホックな調査や脅威ハンティング向け。

どちらもログソース単位・リージョン単位でアクセス範囲を限定でき（1サブスクライバーあたり最大10ソース）、必要な認証情報や権限の受け渡しはSecurity Lakeが自動で行います。

2.4 マルチアカウント・マルチリージョン

AWS Organizationsと統合し、委任管理者アカウントから組織全体のアカウントとリージョンで一括有効化できます。新しく組織に参加したアカウントを自動的に収集対象へ加える設定も可能です。 また、複数リージョンのデータを1つのロールアップリージョンへ集約（他のリージョンはコントリビューティングリージョン）でき、データ所在地の要件に合わせて保存先を決められます。

2.5 ライフサイクル管理

リージョンごとに保持期間と、S3のより安価なストレージクラスへ移行するタイミングを設定でき、長期保管のコストを抑えられます。

3. アーキテクチャおよび技術要素

1. 組織の管理アカウントが、ログアーカイブ用やセキュリティ用のアカウントをSecurity Lakeの委任管理者に指定する。
2. 委任管理者が対象アカウント・リージョン・ログソースを選んでSecurity Lakeを有効化し、必要ならロールアップリージョンを設定する。
3. Security Lakeは委任管理者アカウントにS3バケットを作成し、AWSソースのデータをOCSF＋Parquetに変換して、ソース・リージョン・アカウント・日時でパーティション分割して保存する。
4. AWS GlueのData Catalogにソースごとのテーブルが作られ、Lake Formationで権限が管理される。
5. 新しいデータの到着はEventBridgeやSQSを使ってデータアクセスのサブスクライバーへ通知される。
6. クエリアクセスのサブスクライバーは、AWS RAMで共有されたLake FormationのテーブルをAthenaやAmazon Redshiftなどからクエリする。

変換・パーティション登録の処理にはLambdaが、データの整理にはGlueが使われますが、これらはサービスが管理するため利用者が実装する必要はありません。

4. セキュリティと認証・認可

• データの所有権: データレイクは利用者アカウントのS3バケットに保存され、AWSが別の場所へ持ち出すことはない。
• 暗号化: データはS3のサーバー側暗号化で保護され、AWS KMSのカスタマー管理キーで暗号化することもできる。
• 最小権限での共有: サブスクライバーごとに参照できるログソースとリージョンを限定する。バケットポリシーを手作業で編集したり、データを別バケットへ複製したりせずに共有できる。
• Lake Formationによるアクセス制御: クエリアクセスはLake Formationの権限で管理され、テーブル単位で付与される。
• 外部アカウントの識別: サブスクライバー作成時には相手のAWSアカウントIDと外部IDを指定し、なりすましによるアクセスを防ぐ。
• 監査: Security Lakeの設定変更やサブスクライバーの作成などはCloudTrailに記録される。

5. 料金形態

Security Lake自体の料金は、取り込んだデータ量と正規化処理の量に応じた従量課金です。新規利用者には一定期間の無料トライアルがあります。

• データ取り込み: AWSのログソースから取り込んだデータ量（GB）に応じて課金される。CloudTrail管理イベントとそれ以外のソースで単価が異なる。
• データ正規化: AWSソースのデータをOCSF・Parquetへ変換する処理量（GB）に応じて課金される。
• カスタムソース・サードパーティーデータ: 持ち込むこと自体にSecurity Lakeの料金はかからない（S3の保存料金は発生）。
• 関連サービスの料金: S3の保存、Glue、Lambda、EventBridge、SQS、Athenaなどのクエリ、リージョン間転送は各サービスの料金が別途かかる。
• コスト最適化: 必要なソースとリージョンだけを有効化し、保持期間とストレージクラスの移行を設定する。

6. よくあるアーキテクチャ・設計パターン

• 組織全体のログ一元化: ログアーカイブアカウントを委任管理者にし、全アカウント・全リージョンのCloudTrail、VPCフローログ、Route 53 Resolverログ、EKS監査ログを1つのデータレイクへ集約する。新規アカウントは自動有効化で取りこぼさない。
• オンプレミス・他社ログの統合: ファイアウォールやEDRのログをOCSF形式のParquetに変換し、カスタムソースとして同じデータレイクに入れる。
• 外部SOC・SIEM連携: SIEMを運用するベンダーのアカウントを、必要なソースだけに限定したデータアクセスのサブスクライバーとして登録し、SQSのポーリングで新しいオブジェクトを継続的に取り込ませる。
• 社内での脅威ハンティング: 分析用アカウントをクエリアクセスのサブスクライバーにし、共有されたLake FormationテーブルをAthenaでクエリする。
• データ所在地への対応: 地域ごとにロールアップリージョンを決め、規制で求められる地域の外にデータを出さない。

7. 設定・デプロイ手順（ハンズオン例）

1. 組織の管理アカウントで、セキュリティ用（またはログアーカイブ用）のアカウントをSecurity Lakeの委任管理者に指定する。
2. 委任管理者アカウントのSecurity Lakeコンソールで「開始方法」を選び、収集するログソース（CloudTrail、VPCフローログなど）と対象リージョン・アカウントを選ぶ。
3. 必要に応じてロールアップリージョンと、保持期間・ストレージクラス移行の設定を行う。
4. 新規アカウントを自動で有効化する設定をオンにする。
5. オンプレミスのログを入れる場合は、カスタムソースを作成し、OCSF準拠のParquetを指定の場所へ書き込む処理を用意する。
6. SIEMなどにはデータアクセスのサブスクライバー、Athenaで分析する部門にはクエリアクセスのサブスクライバーを作成し、それぞれ参照できるソースを限定する。
7. AthenaでOCSFのテーブルに対してクエリを実行し、横断調査ができることを確認する。

8. 試験で問われやすいポイント