Amazon Security LakeがGA(一般利用可能)になりました
こんにちわ。
DevelopersIO BASECAMP一期の加藤です。
表題の通り、Amazon Security LakeのGAが発表されました。(※2023年5月31日 記事投稿時点ではドキュメントは一部プレビュー表記)
既にクラスメソッド様が11月時点でプレビュー版の記事をあげていらっしゃいますが、概要を確認しつつアカウントに設定をしてみたいと思います！
まずはアイコン確認
確認してみた所、drawioでも選択可能な図形一覧に追加されていましたが、こちらがAmazon Security Lake(以下 Security Lake)のアイコンです。
Lake Formationの時と同様に、「Lake」である事を波で表現されてます。
（他サービスと押し間違わないようにここで記憶します。）
概要
Amazon Security Lake は、クラウド、オンプレミス、およびカスタムソースからのセキュリティデータを、アカウントに保存されている専用のデータレイクに自動的に一元化します。Security Lake を使用すると、組織全体のセキュリティデータをより完全に理解できます。ワークロード、アプリケーション、およびデータの保護を強化することもできます。Security Lake は、オープンスタンダードである Open Cybersecurity Schema Framework (OCSF) を採用しています。OCSF のサポートにより、このサービスは、AWS からのセキュリティデータと幅広いエンタープライズセキュリティデータ ソースを正規化し、組み合わせることができます。
図から収集したログを最終的にAthenaやQuickSight,SageMakerへと渡して利用する流れを想定している事がわかります。
「Amazon Security Lake の特徴」に更に詳細がありましたので以下に抜粋してみました。
アカウントのデータ集約
Amazon Security Lake は、アカウントで専用のセキュリティデータレイクを作成します。Security Lake は、アカウントとリージョン全体で、クラウド、オンプレミス、およびカスタムデータソースからログとイベントデータを収集します。このサービスは、収集したログを Amazon Simple Storage Service (S3) バケットに保存するため、データのコントロールと所有権を保持できます。
データの正規化と OCSF のサポート
Amazon Security Lake は、AWS ログとセキュリティの検出結果を OCSF に自動的に正規化します。これには、AWS CloudTrail 管理イベント、Amazon Virtual Private Cloud (VPC) Flow Logs、Amazon Route 53 Resolver クエリログ、および AWS Security Hub を通じて統合されたソリューションからのセキュリティの検出結果が含まれます。サードパーティーのセキュリティソリューションからのデータと、OCSF 形式に変換した内部アプリケーションまたはネットワークインフラストラクチャからのログなどのカスタムデータを追加できます。Security Lake は OCSF のサポートにより、セキュリティデータを一元化および変換し、任意の分析ツールで利用できるようにするのをサポートします。
マルチアカウントとマルチリージョンのサポート
サービスが利用可能な複数の AWS リージョン、および複数の AWS アカウントで Amazon Security Lake を有効にすることができます。リージョンごとにアカウント全体のセキュリティデータを集約したり、複数のリージョンからのセキュリティデータをロールアップリージョンに統合したりできます。Security Lake のロールアップリージョンは、リージョンレベルのコンプライアンス要件を遵守するのに役立ちます。
セキュリティデータレイクアクセス管理
ご利用のセキュリティおよび分析ツールのために、データレイクへのアクセスの設定を合理化します。例えば、CloudTrail などの指定されたソースからのデータセットへのアクセス権のみを付与することを選択できます。アクセスには 2 つのモードがあります。新しいオブジェクトがデータレイクに書き込まれたときに通知が発行されるように、ツールへのストリーミングアクセス権を付与できます。もう 1 つのモードは、セキュリティデータレイクに保存されているデータをツールがクエリできるようにするクエリアクセスです。
データのライフサイクル管理と最適化
Amazon Security Lake は、カスタマイズ可能な保持設定でデータのライフサイクルを管理し、自動ストレージ階層化でストレージコストを管理します。Security Lake は、着信セキュリティデータを自動的にパーティショニングし、ストレージとクエリ効率の高い Apache Parquet 形式に変換します。
以下がユーザーガイドです。
利用料金
Security Lake がサポートする AWS リージョンの AWS アカウントで初めてログ収集を有効にすると、そのアカウントは Security Lake の 15 日間の無料トライアルに自動的に登録されます。無料試用期間中も他のサービスから料金が発生する場合があります。
データの取り込み、データ変換、関連サービス等記載がありますので、詳しくは以下ユーザーガイドを参照ください。
設定してみる
普段使いのアカウントをでSecurity Lakeを開いてみます。
↓
「開始方法」というボタンをクリックします。
↓
「管理を他のアカウントに委任」と出てきました。
(Security Lakeを有効にするには別アカウントへ管理を委任する必要があるのでしょうか。)
所有している別アカウントのIDを入力して「委任」をクリック。
↓
一瞬以下のようなエラーが発生しましたが、少し待ってみると、入力したIDのアカウントの表示が変わっています。
↓
(委任先アカウント/初期表示)
↓
(委任先アカウント/委任後)「開始方法」をクリック。
↓
設定項目が表示されました。
「ログイベントとソース」「リージョン」「アカウント」は特に絞らず、すべてを対象のままとします。
「サービスアクセス」ではロールの作成、使用について選択。「新しい〜」では「AmazonSecurityLakeMetaStoreManager」という名前のサービスロールが作成されるようになっているようです。
「許可の詳細を表示」した結果
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowWriteLambdaLogs",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:{{accountId}}:log-group:/aws/lambda/SecurityLake_Glue_Partition_Updater_Lambda*:*"
]
},
{
"Sid": "AllowCreateAwsCloudWatchLogGroup",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup"
],
"Resource": [
"arn:aws:logs:*:{{accountId}}:/aws/lambda/SecurityLake_Glue_Partition_Updater_Lambda*"
]
},
{
"Sid": "AllowGlueManage",
"Effect": "Allow",
"Action": [
"glue:CreatePartition",
"glue:BatchCreatePartition"
],
"Resource": [
"arn:aws:glue:*:*:table/amazon_security_lake_glue_db*/*",
"arn:aws:glue:*:*:database/amazon_security_lake_glue_db*",
"arn:aws:glue:*:*:catalog"
]
},
{
"Sid": "AllowToReadFromSqs",
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes"
],
"Resource": [
"arn:aws:sqs:*:{{accountId}}:*"
]
}
]
}
「次へ」をクリック。
↓
「ターゲット目標を定義」画面へ遷移しました。
「ロールアップリージョン」という耳慣れない単語が出てきましたが、
ロールアップリージョンは、提供元リージョンのデータを集約します。複数のロールアップリージョンを作成して、データを整理し、データ保存要件の遵守に役立てることができます。
と補足する説明が添えてあります。
その隣に「提供元リージョン」がありますので、ここではそれぞれ「ヴァージニア」と
「東京」を選択してみます。
「ストレージクラスを選択」では、「移行を追加」をクリックした場合はデフォルトのS3 Standardから以下のように移行を選択出来るようになっています。(ここにはありませんが日数入力欄も添えられます。)
「サービスアクセス」ブロックでは、
提供元リージョンとロールアップリージョン間でデータを複製する許可
として
「AmazonSecurityLakeS3ReplicationRole」が作成されます。
「許可の詳細を表示」した結果
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadS3ReplicationSetting",
"Action": [
"s3:ListBucket",
"s3:GetReplicationConfiguration",
"s3:GetObjectVersionForReplication",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:GetObjectVersionTagging",
"s3:GetObjectRetention",
"s3:GetObjectLegalHold"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::aws-security-data-lake-[[sourceRegions]]*",
"arn:aws:s3:::aws-security-data-lake-[[sourceRegions]]*/*"
]
},
{
"Sid": "AllowS3Replication",
"Action": [
"s3:ReplicateObject",
"s3:ReplicateDelete",
"s3:ReplicateTags",
"s3:GetObjectVersionTagging"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::aws-security-data-lake-[[destinationRegions]]*/*"
]
}
]
}
それぞれ確認した後、「次へ」をクリック。
↓
設定を確認して、「作成」をクリックします。
↓
エラーが表示されました。
The request failed because Security Lake isn't enabled for your account in the specified Region: ap-northeast-1. Enable Security Lake in the Region and then try again.
先にどこかで有効化設定をすべきだったのかもしれません。ひとまず左サイドカラムが見えるようになっており、「リージョン」項目があったので中を覗いてみます。
↓
Asia Pacific (Tokyo) Data lake creation in progress となっています。数分待ちましたが、更新されないので、「リージョンを追加」をクリックしてみます。
↓
と思ったのと同時に全リージョンが「Created Data Lake」に変わりました。(ちゃんと進んでいました。)
↓
S3を確認すると、委任先アカウントにバケットがリージョン分作成されているのも確認出来ました。
次章から各項目の中身を確認していきたいと思います。
順に項目を確認
概要
「サブスクライバー」が表示される事と、過去14日間に見つかった「問題」の表示が確認出来ます。(既に赤いアラートが並んでいます。)
ソース
以下、それぞれを有効化出来るようになっているようです。
CloudTrail - Management events
AWS リソースで実行される管理オペレーション
CloudTrail - Lambda data events
Lambda コンソールからの呼び出しや Lambda API へのコード呼び出しを含む、CloudTrail によってキャプチャされた Amazon Lambda の API 呼び出しのサブセット。
CloudTrail - S3 data events
S3 コンソールからの呼び出しや S3 API へのコード呼び出しを含む、CloudTrail によってキャプチャされた Amazon S3 の API 呼び出しのサブセット。
VPC Flow Logs
VPC のネットワークインターフェイスで送受信される IP トラフィックに関する情報
Route 53
Amazon VPC 内のリソースによって行われる DNS クエリ
Security Hub
AWS リソースに関連するセキュリティ検出結果
サブスクライバー
「概要」項目でも存在を確認していたサブスクライバーを作成出来ます。
↓
作成画面です。
データアクセス方法をS3にすると。通知の詳細の選択画面が表示されるのを確認しました。
更にsubscription endpointを選択すると、以下入力項目が表示されます。
リージョン
画像再掲ですが、リージョンの有効化が可能になっています。(ボタンをクリックしましたが、全リージョンが有効化済みの状態では、追加画面は表示されず現在画面に戻されてしまいました。)
カスタムソース
カスタムソースが作成出来るようです。
↓
「カスタムデータソースを作成」画面。
問題
先ほど「概要」項目内で赤枠で表示されていた問題が閲覧出来ました。
The operation failed for the following source: SH_FINDINGS/1.0. securitylake.amazonaws.com couldn't assume the Security Lake service-linked role for account 012345678901.
後で修正したいと思います。
アカウント
表示件数の関係か、ページを捲らないと一瞬見落としそうになりますが、最初に選択した通り、機能を利用開始する以前に停止(90日間の猶予期間中)しているアカウントも含め全アカウントが確認出来ました。
ソース「６」をクリックしてみた所、先ほどのソース6項目が全て有効化されている事が確認出来ました。
Settings-全般
「Security Lakeを無効にする」のみ出来るようです。
Settings-ロールアップリージョン
最初に設定した「ロールアップリージョン」「提供元リージョン」の変更のみ出来るようです。
先ほど問題で指摘されていた部分
私は存在を知らない単語ですが「SH_FINDINGS1.0」のSHは恐らくSecurity Hubでしょうか。
Webページやドキュメントでエラーメッセージを検索してみましたがHitせず、恐らく指摘されている問題のアカウントが普段使いしているアカウントのみである事から、何らかの権限不足でなければ、既存のサービスリンクドロールとの競合等を疑っています。(解決したら追記したいと思います。)
おわりに
実際にログを確認するには至りませんでしたが、アカウントを横断してログを集約・一元管理し、BIであるQuicksightや、Athena、MLサービスであるSageMakerなどで使いましょうという意図のサービスであるという事を改めて触ってみて理解しました。
恐らく、近日もっと詳しく検証や考察が添えられた記事が有志の方からUPされるのではと思いますので私もそれを見てまた勉強したいと思います。
お読みいただき有難うございました。
Discussion