みなさん、こんにちは。
明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。
先日GAされたSecurity Lake、みなさんもう触られていますか？
Security Lakeのサブスクライバー機能を試してみたいので、連携先にSIEM on OpenSearch Serviceを設定してみたいと思います。
概要
SIEM on Amazon OpenSearch Serviceとは？
SIEM on Amazon OpenSearch Serviceとは、AWSからOSSとして提供されているSIEM(Security Information and Event Management)ソリューションの名称です。
GitHub上で公開されているCloudFormationテンプレートを実行すると、以下のようなダッシュボードをはじめとするログ分析・可視化基盤が構築されます。
詳しくはこちらのGitHubリポジトリをご覧ください。
同じGitHubリポジトリのテンプレートを活用したWorkshopも公開されています。GitHubリポジトリにも構築手順がありますが、Workshopの方が手順がわかりやすいのでこちらもおすすめです。
今回やること
今回構築するアーキテクチャはこちらです。
検証アカウントは、事前にセットアップしたControl Towerベースのマルチアカウント環境配下のメンバーアカウントを利用します。
SIEM環境はAmazon Security Lakeと異なるアカウントにデプロイすることが推奨されます。この検証でもSIEMのデプロイはSecurity Lakeとは異なるアカウントとします。
やってみた
ここからは、先ほど紹介したGitHubリポジトリのAmazon Security Lakeとの統合の手順とWorkshopの環境構築手順を2つを参考にSIEMの環境構築やSecurity Lakeとの連携の検証を行なっていきます。
1. SIEM on Amazon OpenSearch Serviceの環境構築
この章では、SIEMデプロイ用のAWSアカウントを使って作業してください。
1-1. CloudFomationテンプレート実行
はじめにSIEMのGitHubリポジトリのCloudFormationテンプレートを実行します。
スタックの詳細では、Initial Deployment Parameters - AllowedSourceIpAddressesのパラメータのみ変更します。ここではSIEM構築後にOpenSearchダッシュボードへの接続元拠点のソースIPアドレスを、CIDRブロック形式で入力してください。
Security Lakeの設定は、(Experimental) Security Lake Integration - optionalの項目から設定できますが、この時点では入力しません。
スタックを作成し、リソース作成の完了まで30分ほど待機します。
テンプレート作成完了後、OpenSearch Serviceのドメインのステータスがアクティブになっていることを確認します。
1-2. OpenSearchコンソールへの接続確認
CloudFormationテンプレートの出力欄からOpenSearchダッシュボードのURLやログイン情報を確認してください。
OpenSearchダッシュボードのURLにアクセスし、ログインしてください。
初回ログイン時にはtenant設定を選択する必要があったので、Globalで設定しました。
ダッシュボードが表示できました。
1-3. アクセスポリシーの変更(任意)
スタック作成時に指定したOpenSearchダッシュボードへの接続元拠点のソースIPアドレスを変更したい方は、ドメインのセキュリティ設定から接続元IPアドレスの追加や変更ができます。
アクセスポリシーに、テンプレート作成に指定したアクセス許可設定が設定されています（ビジュアルエディタで見るとわかりやすい）必要に応じて許可設定の追加/変更/削除をしてください。またこの時、IAM ARNと表記されている列を削除しないようにしてください。
2. Amazon Security Lakeの設定
この章は、Security Lakeを有効化するマルチアカウント環境配下のAWSアカウントで作業してください。
2-1. Amazon Security Lakeの有効化
Security Lakeの有効化手順については今回は割愛します。有効化から実施する場合は、こちらのブログを参考に設定してください。
2-2. ロールアップリージョン(ログの集約)の設定
ロールアップリージョンを設定し、複数リージョンのログの集約設定を行います。
今回の検証環境は東京リージョンとバージニア北部リージョンでSecurity Lakeを有効化している環境なので、東京リージョンにバージニア北部リージョンのログを集約します。
ロールアップリージョンを東京、提供元リージョンをバージニア北部にしています。サービスアクセス用に利用するロールはSecurity Lake側で自動作成されるAmazonSecurityLakeS3ReplicationRoleを利用します。
設定できたようです。
aws-security-data-lake-ap-northeast-1-で始まるS3バケットを確認し、ロールアップリージョンのログ(region=ap-northeast-1/)だけではなく提供元リージョンのログ(region=us-east-1/)が保存されていればOKです。
2-3. サブスクライバー設定
サブスクライバーを設定します。
- データアクセス方法:
S3を選択 - サブスクライバーの認証情報
- アカウントID:
SIEMをデプロイしたAWSアカウントIDを入力 - 外部ID:
任意の文字列を入力
- アカウントID:
- 通知の詳細:
SQS queueを選択
サブスクライバーが設定できました。
作成されたSQSキュー(AmazonSecurityLake-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX-Main-Queue)の設定を変更し、可視性タイムアウトを5分から10分に変更します。これは必須の設定で、おそらくLambda関数(es-loader)の処理遅延による影響を抑えるためなのかなと想定しています。
SIEM側の設定更新に利用するため、作成したサブスクライバーの以下情報をまとめておきます。
- サブスクリプションエンドポイント
- AWS ロール ID
- 外部 ID
2-4. SIEM作成用CloudFormationスタックのアップデート
SIEMデプロイで利用したCloudFormationスタックを更新します。
先ほどまとめた情報を埋めて、スタックを更新します。
- SecurityLakeSubscriberSqs:
サブスクリプションエンドポイントを入力 - SecurityLakeRoleArn:
AWS ロール IDを入力 - SecurityLakeExternalId:
外部 IDを入力
3.SIEMダッシュボードの確認
OpenSearchダッシュボードのDiscoverからログを確認できます。
ログがいくつか表示されているので、ログの取り込みが正常に実行されていることがわかります。
ここでログが表示されない場合はしばらく待つか、手動でLambda関数(aes-siem-es-loader)をデプロイし新規のインスタンス上にLambdaを立ち上げてみてください。画像の検証環境では設定から5時間ほど経ったログの一覧を表示しています。
明らかにログの量が少ないと思われる場合はログ表示範囲のタイムスタンプが想定したものになっているか、フィルターがかかっていないかを確認してください。
ログの取り込みができたことまで確認できたので、検証は以上とします。
最後に
今回はSecurity Lakeのサブスクライバー機能を検証すべく、SIEM on OpenSearch ServiceにSecurity Lakeのデータを取り込んでみました。
Security LakeのサブスクライバーにAthenaを設定し他アカウントからアドホックなクエリを実行してログ検索を行う検証ブログもありますので、こちらも併せて確認してみてください。
以上、芦沢(＠ashi_ssan)でした。
7
