Amazon OpenSearch Service と Amazon Security Lake の Zero-ETL 統合をやってみる
2025.01.2112/1 に Amazon OpenSearch Service と Amazon Security Lake の zero-ETL に関するアップデートがありました。
概要については以下のブログをご参考ください。
Amazon Security Lake には、外部との統合に「データアクセス」と「クエリアクセス」の２種類の方法があり、外部のサードパーティから直接クエリを行う場合は、「クエリアクセス」を利用します。
本記事では Amazon Security Lake の「クエリアクセス」を使って、Amazon OpenSearch Service との zero-ETLをやってみます。
また、下記のブログでは Amazon Security Lake と Amazon Athena の「クエリアクセス」が紹介されていますので併せてご覧いただければと思います。
Security Lake と OpenSearch Service の zero-ETLを試す
事前にAWS Organizationsの有効化と、Security Lakeの委任管理者アカウントの設定を行った環境で試します。
Security Lakeの有効化
委任管理者アカウントで、Security Lakeの有効化を行います。
AWSソースの選択や、取得対象とするリージョン、アカウントを任意で指定、サービスロールを作成し、設定します。
（ロールアップリージョンや、ストレージクラスの選択も任意で設定します。）
有効化したあとに、「要約」の画面で表示される「サービスリンクロールを有効化」をクリックしておきます。
さらにSecurity Lakeが管理するバケットをLake Formationに登録するかどうかを問われる画面が表示されますので、「バケットを登録」をクリックします。
サブスクライバーの設定
Security Lakeでサブスクライバーを作成します。
サブスライバー名と、Lake Formationを選択します。
アカウントID には、OpenSearch Service を動かすアカウントIDを入れます。
外部IDは、ランダムな文字列等や任意の文字列で入力します。
RAM でリソース共有を受け入れる
サブスライバーの設定を行うと、委任管理者アカウント上のSecurity Lakeで利用されるLake Formationのテーブルが、ダイレクトクエリを行う側のアカウントで共有されます。
OpenSearch Service を動かすアカウントで、RAM (Resource Access Manager) にアクセスし、共有を受け入れます。
「自分と共有」の場所に、保留中のリソースが確認できるので、それを選択し共有を受け入れます。
「共有リソース」の部分を確認すると、カタログ（マスク部分は委任管理アカウントID）、データベース、Security Lakeで共有対象としたもの（今回はSecurity Lakeで取得しているログソース全て）のテーブルが共有されていることが分かります。
試しに、OpenSearch Serviceを動かすアカウント側のLake Formationからもリソースが共有されているか確認してみます。
テーブルは正しく共有されていそうです。
データベースを確認すると、何も表示がされず共有されていないように見えています。
OpenSearch Serviceからのダイレクトクエリでは、共有データベースへのアクセスが必要となります。上記の手順でサブスクライバーに必要なリソースの共有ができたと思い、OpenSearch Serviceの接続を行ったところ、共有データベースが参照できず、うまくいきませんでした。さらに個別で下記の手順で共有設定したところ、うまくいきましたので、続いて設定していきます。
追加でLake Formationから共有を行う
Security Lake 委任管理アカウントの方から、Lake Formationで個別にデータベースの共有を行います。
Lake Formation の 「Data Permissions」 の設定で、「Grant」を選択します。
（こちらの画面でもDatabaseの共有権限は付与されていないことが確認できました。RAMでは共有できていたように見えたのに何故だろう...）
External Accounts を選択し、共有先のアカウントを選択します。
Named Data Catalog resourcesを選択し、カタログと、共有するデータベースを選択します。
Describeの権限を付与します。
これで、データベースの共有ができたので、再び共有先のアカウント（OpenSearch Serviceを動かすアカウント）のRAMで共有を受け入れます。
その後、共有先アカウントのLake Formationでデータベースを確認すると、共有されていることが確認できました。
Lake Formationでリソースリンクの設定
共有されたLake Formationのデータベースは、共有された側のアカウントから直接リソースを参照することができません。
その代わりにリソースリンク経由で、共有元のリソースにアクセスできるようになります。
OpenSearch Serviceを動かすアカウントのLake Formationでデータベースを作成します。
リソースリンクを選択し、共有されたデータベースを選択します。（Shared Account はSecurity Lakeの委任管理アカウントになります。）
OpenSearch Service で zero-ETL 接続の設定
データ接続を設定します。
セキュリティレイクを選択します。
IAMロールの作成と、Glue databaseを選択します。このとき、データベースが選択できるようになっている必要がありますが、ここで表示がされない場合は、一度共有設定やリソースリンクの設定が正しいか見直します。
作成に少し時間がかかるので、待ちます。
OpenSearch Service Serverless からデータを直接クエリする
OpenSearch Service Serverlessのアプリケーションが作成され、コンソールに接続することができます。
ログを詳しく見るをクリックしてみます。
データを見てみます。
Security Lakeのデータに直接アクセスして、クエリをかけることができます。
クエリ言語とタイムフィールドを選択する画面が出てくるのですが、そのまま何か選択すると、現在の時刻から２時間前のデータを検索しようとします。
AWSのログはUTCタイムで記録がされているので、勝手に入るwhereの検索条件と日本時間とでずれがあるので何も表示がされません。
一度、whereの条件を消して、上部のタイムピッカーで15分前までのデータなどで検索しなおすとデータが出力されていれば、クエリが返ってきます。
最初の条件では、どんなログでも表示されませんので注意が必要です。
CloudTrailのログのクエリ結果を見てみると、OCSFのフィールドに認識されてログが検索できていることが確認できます。
いくつかのデータフィールドで、ネスト構造のJSONが文字列として認識されていそうなので、取り扱いを少し考える必要がありそうです。
また、直接クエリで接続したデータに対してダッシュボード化することもできます。
テンプレートも用意されているので、さくっと作れるようです。
VPC flow logs、WAF logs、CloudTrail logsのビルトインダッシュボードがつくれるようです。
ただし、可視化した場合には、料金がだいぶかかりそうなのでこの点は注意が必要そうです。
Amazon OpenSearch Service のコストに関しては、基本的に下記ブログの S3 と OpenSearch Service の zero-ETL 統合と同じ考え方となりますので、ご参考いただければと思います。
まとめ
Amazon OpenSearch Service と Amazon Security Lake の zero-ETL をやってみました。
データパイプラインをつくらずともすぐに分析ができ、かつOCSFで正規化されたデータとして扱うことができることを確認しました。
ただ、データの正規化によるログソースを横断した相関分析の実現という点においては、もう少しサービス側のアップデートが必要になってくるのかなと感じました。
今後のさらなるアップデートに期待です。
参考
Amazon Security Lake サブスクライバーのクエリアクセスの管理
![[アップデート] Amazon CloudWatch Logs と Amazon OpenSearch Service 間で Zero-ETL 統合が提供されて Direct Query を実行できるようになりました #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3nibOl2sZ0LKJueI0FHFi5/14de7bd294f7916a28b789105c60d450/reinvent-2024-newservice-jp.jpg)
