今回は、Amazon Security Lakeの初期セットアップ手順について説明します。Amazon Security Lakeは主にセキュリティに関連するAWSサービスのログを一元的に集約するサービスです。

その特徴はログの形式にあり、Open Cybersecurity Schema Frameworkで定義されているスキーマに則ったApache Parquet形式で保管されます。それにより標準化された大量のデータを扱うことに優れています。Security Lakeとの連携をサポートしているAWSサービスであれば、Security Lakeにログを簡単に集約できます。 以下、セットアップ手順を紹介していきます。

想定する構成

Security Lakeは利用にあたり、委任管理者の指定が必須となるサービスです。したがって、管理アカウントとは別にSecurity Lakeの設定を行うための委任管理者となるAWSアカウントの指定が必要となります。管理アカウントのベストプラクティスに則り、管理アカウント内にAWSリソースは極力作らない構成とさせたいというAWSの意図がわかる仕様となっています。

Security Lake専用のAWSアカウントを用意してもよいですが、今回はSecurity Hub等のサービスの委任管理者としていたセキュリティアカウントをSecurity Lakeの委任管理者として設定した下記の構成でセットアップを行っていきます。

管理アカウントの設定

これまで紹介してきたサービスと同じく、まずは管理アカウントで委任管理者の設定を行います。

(1)委任管理者アカウントの設定は、管理アカウントでのみ実施が可能ですので、まず管理アカウントにログインを行い、Organizationsの画面へ遷移します。 (2)サイドメニューから「サービス」をクリックします。 (3)Security Lakeを見つけ、クリックします。

(4)「信頼されたアクセスを有効にする」をクリックします。

(5)表示されたポップアップで下記のように入力を行い、「信頼されたアクセスを有効にする」ボタンをクリックします。

(6)ステータスが変更されていることを確認し、「コンソールに移動する」ボタンをクリックし、Security Lakeへ移動します。

(7)「開始方法」のボタンをクリックします。

(8)セキュリティアカウントを選択し、「委任」ボタンをクリックします。 ※ すでにセキュリティ系のサービスを委任している場合、推奨の委任管理者としてデフォルトで選択されます。

(9)委任管理者が正しく設定されたことを確認します。

セキュリティアカウントの設定

委任管理者の設定に続いて、セキュリティアカウントの設定を行います。

(1)委任管理者として指定されたセキュリティアカウントへログインし、Security Lakeへ移動し、「開始方法」ボタンをクリックします。

(2)Security Lakeへ保管するログは、「特定のAWSリソースを取り込む」を選択することで変更が可能です。

今回はサポートされているすべてのAWSサービスのログを保管することとし、「AWSのデフォルトソースを取り込む」を選択します。

(3)特定のリージョンにログを集約するロールアップリージョンの指定を行います。ここでロールアップリージョンを指定した場合、もともとのログは残りつつ、ロールアップリージョンにもログがコピーされる挙動となり、二重にデータが保持されることとなります。

今回は大阪リージョンのログを東京リージョンに集約する設定を行います。加えて、Security Lakeが用意するS3バケットに保持されるログのストレージクラスの変更や削除なども指定できますので、今回は30日を超えたログは失効(削除)する設定を行います。

(4)内容を確認し、「作成」ボタンをクリックします。

(5)リージョンでの設定処理が実施されるため、完了するまで待ちます。内部的にS3バケットの作成やGlue Catalogの作成などが実施されており、少々時間を要します。筆者の環境では画像の対象のリージョンに対しての設定完了までに15分ほど時間を要しました。

Security Lakeの設定が完了すると、以下のようにログ集約対象としたリージョンごとに専用のS3バケットが作成されます。

下の階層は以下のようにAWSサービスごとに分けられます。

ロールアップリージョンを設定した場合は、以下のように集約されてきます (以下の画像は大阪リージョンのロールアップリージョンとして、東京リージョンを指定した場合) 。

Security Lakeに集められたログに対する検索は、Athenaを利用することが一般的です。こちらにサンプルクエリが紹介されているので、ぜひとも参考にしてください。サンプルクエリはそのままでは使えないため、テーブル名に含まれるリージョン名を修正したうえで、実行してください。

課題となりやすいポイント

(1)本連載ですでに紹介したように、CloudTrailの証跡をS3へ保存するといった長期保管の設定を行っていた場合は、Security Lakeを有効化することで、二重にログが保管されてしまうことになります。そのため、場合によってはログ保管コストが大きく増加する可能性もあることにご留意ください。使用状況メニューからコストを確認することをおすすめします。

(2)Security Lakeに自動的に保管できるログは同一Organizations内のAWSアカウントのみです。Control Towerの回で紹介したように、複数のOrganizationsが存在した場合、Security Lakeを利用して1カ所にログを集約できなくなります。複数のOrganizations配下のAWSアカウントのログを集約させたい場合は、各AWSサービスでの個別設定が必要となりますので、注意ください。

まとめ

今回は、Amazon Security Lakeのセットアップステップと課題となりやすいポイントについても紹介しました。本稿がSecurity Lake利用者のお役に立てば幸いです。