Amazon Secruity Lake には他のアカウントに対してクエリアクセスできる環境を構築するサブスクライバー機能があります。このブログでは、他のアカウントから Amazon Athena を用いてクエリしてみます。
サブスクライバー管理機能はユーザーガイドの次のページに説明があります。
Subscriber management in Amazon Security Lake - Amazon Security Lake
サブスクライバー機能を試す
Amazon Secruity Lake を有効化済みの環境で試します。Secruity Lake は東京リージョンとバージニア北部リージョンで有効化しており、東京リージョンをロールアップリージョンとしています。
サブスクライバー設定
サブスクライバー管理機能には、「データアクセス」と「クエリアクセス」があり、他のアカウントから Amazon Athena でアクセスさせるには「クエリアクセス」を利用します。「クエリアクセス」を設定すると Resource Access Manager (RAM) により AWS Lake Formation のテーブルが共有され、共有されたアカウントで Athena を利用できます。
サブスクライバーを作成します。
サブスクライバーメニューからサブスクライバーを作成をクリックします。
他のアカウントにアクセスを許可するイベントソースとして、今回は CloudTrail を指定してみます。データアクセス方法はLake Formationが「クエリアクセス」に該当します。サブスクライバーの認証情報では、アクセスさせたい AWS アカウント ID と外部 ID を指定します。マスキングしていますが、外部 ID は uuidgen コマンドで出力した適当な値を入力しています。
作成をクリックすればサブスクライバー設定は完了です。
共有されたアカウントの設定
アクセスしたいアカウント側の設定は次のユーザーガイドに説明があります。
Managing query access for Security Lake subscribers - Amazon Security Lake
Amazon Security Lake は裏では AWS Lake Formation が利用されており、Lake Formation のテーブルが Resource Access Manager (RAM) により他のアカウントに共有されます。
RAM の共有を確認してみます。2 つ目と 3 つ目が Security Lake 関連のリソースです（1 つ目は Security Lake に関係しないリソースなのでマスキングしています）。CloudTrail に関するテーブルが共有されていることが分かります。
なお、今回の環境では、AWS Organizations の統合されたサービス設定において、RAM を「アクセス有効」にしています。そのため、共有された側のアカウントでは承認は不要でしたが、「アクセス無効」の場合は承認作業が必要と思われます。
AWS Lake Formation の共有が確認できたため、Athena でクエリできるようにするためにテーブルのリソースリンクを作成します。
テーブル作成前に、Security Lake 用のデータベースを作成します。作成済みの default データベースを利用することもできます。
Name などを入力してCreate databaseをクリックすれば完了です。
次に、テーブルのリソースリンクを作成します。
Database は先ほど作成したベータベースを選択し、Shared table は RAM で共有されているテーブルを選択します。
Createをクリックすれば作成完了です。
共有されたアカウントで Athena のクエリ実行
Security Lake の CloudTrail ログに対して Athena でクエリ実行できました。
SELECT *
FROM "security_lake"."security_lake_cloudtrail"
ORDER BY time desc
LIMIT 5
以上で、終わりです。
さいごに
Amazon Secruity Lake には他のアカウントに対してクエリアクセスできる環境を構築するサブスクライバー機能を利用して、他の AWS アカウントから Amazon Athena を用いてクエリしてみました。
このブログがどなたかのご参考になれば幸いです。
10
