はじめに
MEGAZONE株式会社の阿河です。
近年組織内で発生するセキュリティイベントの増加に伴い、社内のセキュリティログを適切に収集・分析し、迅速な対応につなげることの重要性が高まっています。しかし蓄積されたデータをどのように活用し、有効なインサイトを得るかは多くの組織にとって課題となります。
AWSでは、セキュリティ関連データを一元的に管理・分析するためのサービスとしてAmazon Security Lakeを提供しています。本記事ではAthenaを用いてクロスアカウントのSecurity Lakeデータを分析し、セキュリティインシデントに関する情報を効率的に取得・活用する手法について解説します。
目次
- 概要
- 前提条件: クロスアカウント環境のセットアップ
- クロスアカウントアクセスの設定: RAMとLakeFormaiton
- Athenaを用いたSecurity Lakeデータの分析
1. 概要
組織のセキュリティ対策において、セキュリティログの統合的な管理と分析は不可欠です。
しかし各種ログが複数のAWSアカウントに分散している場合、それらを統合・横断的に分析する仕組みが求められます。
本記事では、Amazon Security Lakeを活用し、CloudTrail の管理ログと Security Hubのデータを統合し、Athenaによる横断分析を可能にする手法について解説します。
アーキテクチャの概要
セキュリティデータを統合し、Athena による分析を可能にするため、以下の仕組みを構築しました。
Amazon Security Lake の有効化
- Amazon Security Lakeを活用し、CloudTrailやSecurity Hubなどのセキュリティ関連データを蓄積。
- これにより、組織全体のログを一元管理し、統一されたフォーマットで分析可能にする。
クロスアカウントアクセスの設定（Resource Access Manager (RAM)）
- Security Lake に格納されたデータを、異なる AWS アカウント（分析用アカウント）からアクセスできるようにするために、Resource Access Manager (RAM) を使用。
- RAM を用いることで、データをコピーせずに共有し、セキュリティを維持しながら分析を可能にする。
- データ管理と分析環境をアカウントレベルで分離する。Security Lake はデータの「蓄積・統合」に特化し、Athenaなどの分析基盤は別のアカウント（アクセス用アカウント）に配置。
Lake Formation によるデータ管理とアクセス制御
- Athenaでの分析を可能にするために、Lake Formation を用いて データへのアクセス権限を細かく制御。
- データのガバナンスを強化しつつ、必要なユーザーが適切にアクセスできる仕組みを構築。
Athena によるクエリ実行と分析
- 統合された Security Lakeのデータに対して、Athenaを用いた分析基盤を構築。
- データベースを別途用意せず、サーバーレスで 柔軟かつコスト効率よくログを分析できるようにする。
なぜ Security Lake を活用するのか？
-
Amazon Security Lakeを使用することで、複数のAWSサービスから発生するセキュリティログを統一フォーマット（Open Cybersecurity Schema Framework：OCSF)で管理できるため、データ分析の標準化と効率化 を実現できます。
-
今回のケースでは、CloudTrailの管理ログとSecurity Hubのセキュリティ検出情報を対象とし、社内のセキュリティイベントを集約・分析する基盤を構築しました。
-
従来は個別のAWSサービスからログを収集し、それらを統合することは大きな負担でしたが、Security Lakeを活用することで、ログの統一管理と横断的なクエリ実行を簡素化できるというメリットがあります。
社内セキュリティデータを効率的に活用するために
本検証では、Security Lakeにより 社内のセキュリティデータを一元管理し、Athenaによって横断的な分析を可能にするアプローチを実践しました。これにより、クロスアカウント環境でもセキュリティデータの可視性を向上させ、効率的なインシデント対応やリスク評価が可能になります。
次の章では、クロスアカウント環境のセットアップ手順について詳しく解説します。
2. 前提条件: クロスアカウント環境のセットアップ
Security Lake をクロスアカウントで利用するにあたり、AWS Organizationsを活用し、組織管理者アカウントからSecurity Lakeの管理を委任し、対象アカウントのデータを統合的に収集・分析できるようにしています。
本章では、Security Lakeの管理アカウント設定や、組織内の複数アカウントに対する前提条件の整備について解説します。
AWS Organizations の有効化
- Security Lake を利用する際、AWS Organizationsの使用は必須ではありません。 スタンドアロンのAWSアカウントでも Security Lakeを有効化し、利用することが可能です。
- ただし、複数のAWSアカウント間でセキュリティデータを統合的に管理・分析する場合、AWS Organizationsを活用することで、より効率的な運用が可能となります。
Sucurity Lakeの委任設定
- 組織の管理アカウントは、Security Lakeの管理を委任するアカウントを指定し、その委任された管理者アカウントで Security Lake の設定や運用を行います。
- 組織の管理アカウントで、マネジメントコンソールからSecurity Lakeを有効化しようとすると、委任管理者の設定を求められます。委任先のアカウント(本記事では、Security Lake管理アカウントと呼称)を指定します。
組織証跡有効化
- Security LakeでCloudTrail管理イベントを収集するには、CloudTrail管理イベントの読み取りと書き込みを収集するCloudTrail複数リージョン組織証跡が少なくとも1つ必要。
- AWS Organizationsで組織を作成した場合、その組織内のすべてのAWSアカウントのすべてのイベントを記録する証跡を作成することができます。
対象AWSアカウントでSecurity Hub有効化
Security Lakeは、AWS Security Hub のデータも統合して管理できます。
対象アカウントで Security Hubを有効化します。
※今回はCloudTrailとSecurity Hubを対象としていますが、上記リンクで対応ログを確認の上で、環境に合わせてセッティングしてください。
Security Lake の設定手順
AWS Organizations のセットアップや管理アカウントの委任が完了したら、Security Lake の有効化を実施します。
以下の設定は、Security Lake管理アカウント側で実施します。
マネジメントコンソールで、Security Lakeのページに移動。
以下で初期設定を行います。
-
ソースの設定
- ソースは「デフォルトのAWSソースの取り込み」と「特定のAWSソースを取り込む」のどちらかを選択します。今回はソースを絞るため、「特定のAWSソースを取り込む」を選択。
- CloudTrailのManagement Eventを選択
- Security Hubを選択。
-
リージョンの選択
- 今回は東京リージョンとバージニア北部リージョンを選択
-
アカウントの登録
- 対象アカウントをコンマ区切りで入力（複数アカウント対応可能）
-
サービスアクセスの設定
- 新しい IAM サービスロールを作成し、Security Lake に付与
以上の設定で有効化します。
有効化が完了しました。
3. クロスアカウントアクセスの設定: RAMとLakeFormaiton
本章では、Resource Access Manager (RAM) と Lake Formationを活用して、異なるAWSアカウントからSecurity Lakeのデータにアクセスするための設定手順を解説します。
Security Lake管理アカウント: Secuirty Lakeの設定をした管理アカウント
アクセス用アカウント: Athenaが存在するアカウント
クエリアクセスの概要
Security Lakeのサブスクライバー(クエリアクセス)は、Security Lake が収集するデータをクエリできます。これらのサブスクライバーは、Amazon Athenaなどのサービスを使用してS3バケット内のAWS Lake Formationテーブルを直接クエリします。
この仕組みを実現するためには、以下の設定が必要になります。
- Security Lake管理アカウントでサブスクライバーを作成
- アクセス用アカウントのRAMでデータ共有を承認
- Security Lake管理アカウントのLake Formation でアクセス権限を付与（Grant Permissions）
- アクセス用アカウントでリソースリンクを作成
Security Lake管理アカウントでサブスクライバーを作成
-
Amazon Security Lake コンソールに移動し、サブスクライバーを作成
- サブスクライバー名: 任意の名前を指定
- データアクセス: Lake Formation を選択
- アカウントID: アクセス用AWSアカウントのAWSアカウントIDを入力
- 外部ID: 任意の外部IDを入力。外部 ID は、サブスクライバーが提供する固有の識別子です。
-
Security Lake は、Lake Formation のクロスアカウントテーブル共有を使用して、サブスクライバーのクエリアクセスをサポートします。Security Lakeコンソール、API、または AWS CLIでクエリアクセスを持つサブスクライバを作成すると、Security LakeはAWS RAMにリソース共有を作成することで、関連する Lake Formation テーブルの情報をサブスクライバーと共有します。
-
サブスクライバーは、AWS Lake Formation（コンソールを使用する場合）または AWS Glue（API/AWS CLI を使用する場合）のいずれかで、共有Lake Formationデータベースへのリソースリンクを作成する必要があります。
RAM
サブスクライバーを作成すると、Resource Access Manager (RAM) を通じてデータ共有の招待が送信されます。
アクセスを許可する AWS アカウントで、招待を承認する必要があります。
- アクセス用AWSアカウントにログイン
- AWS RAM コンソール に移動し、[Resource shares] を開く
- 招待が届いていることを確認し、[Accept]（承認）をクリック
- 承認が完了すると、Security Lake のデータがアクセス用 AWS アカウントに共有される
Grant Permissions
Security Lake のデータにクエリを実行するためには、Lake Formation で適切な権限を付与する必要があります。
ここで Grant Permissions を設定することで、アクセス用アカウントが Security Lake のデータベースとテーブルにクエリを実行できるようになります。
- Security Lake管理アカウントで AWS Lake Formation コンソールに移動
- [データベース] タブを開き、Security Lakeのデータベースを選択
- [権限の付与 (Grant)] をクリックし、アクセス用AWSアカウントに権限を付与
- 付与するアクセス権限を設定
設定を保存し、Lake Formation のアクセス権限を適用します。
リソースリンクを作成
Lake Formationで共有されたデータを、アクセス用AWSアカウント側で利用するために、リソースリンクを作成します。
これにより、サブスクライバーアカウント側でデータベースが認識され、Athena などでクエリ可能になります。
- アクセス用 AWS アカウントで AWS Lake Formationコンソールに移動
- [データベース] タブを開き、[リソースリンクの作成] をクリック
- リソースリンクの情報を入力
- リソースリンク名: 任意の名前を指定
- 元のデータベース: 管理アカウントから共有された Security Lakeのデータベースを選択
- リソースリンクを作成
リソースリンクを作成することで、アクセス用AWSアカウント側でSecurity Lakeのデータが正式に利用可能になります。
4. Athenaを用いたSecurity Lakeデータの分析
ここまでの設定により、Security Lakeのデータがアクセス用アカウントのAthenaでクエリ可能になりました。
このセクションでは、CloudTrailの管理ログおよびSecurity Hubのログを対象にしたクエリの例をご紹介します。
CloudTrailログ
SELECT *
FROM "xxx"."xxxxxxxxxxxx"
WHERE time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP
AND api.service.name = 'iam.amazonaws.com'
ORDER BY time desc
LIMIT 25
- IAMユーザーやアクセスキーが意図せず作成されていないかを監視
- 異常なアクティビティがあれば、EventBridge + Lambdaで通知や自動オペレーションに繋げるなどのアクションが考えられる。
Secuirty Hubログ
SELECT
time_dt,
finding_info.title,
finding_info,
severity
FROM "xxx"."xxxxxxxxxxxx"
WHERE severity = 'Critical' and time_dt BETWEEN CURRENT_TIMESTAMP - INTERVAL '7' DAY AND CURRENT_TIMESTAMP
LIMIT 25
- 緊急対応が必要なFindingsを可視化
おわりに
本記事では、AWS Security Lakeを活用し、Athenaを用いたセキュリティログのクロスアカウント分析を実践しました。
今後の展開として、以下のようなアプローチも考えられます。
- Amazon QuickSight を用いたセキュリティログの可視化
- Amazon EventBridge + AWS Lambda による異常検知の自動化
- Amazon Bedrock を活用した AI ベースの異常パターン検出
社内セキュリティデータを管理し、効率的に運用していくことで、組織のセキュリティ基盤をより強固なものにしていきましょう。
ここまで読んでいただき、ありがとうございました。
MEGAZONEはAWS プレミアティア サービスパートナーとして多数のCompetencyを取得しており、大企業、ゲーム会社、スタートアップ、公共機関などさまざまな分野の5,000以上のお客様にAWSソリューションとサービスを提供しています。
Discussion