Amazon Security Lakeの仕組みとKMS暗号化方法の紹介

Amazon Security Lake,AWS

こんにちは。プラットフォーム技術部の中村です。

AWSには、Amazon Security Lake（以下、Security Lake）という、セキュリティデータを集約・連携できるマネージドサービスがあります。

Security Lakeは非常に便利なサービスですが、デフォルトのAmazon S3マネージドキーを用いた暗号化では、S3マネージドキーへのアクセスに関する詳細な証跡が必要であったり、暗号化キーを高頻度でローテーションしたいといった要件を満たすことができません。

本記事では、Security Lakeの概要や構成例を紹介したのち、先述した高度な要件に対応するためにSecurity Lakeが保持している情報をKMS暗号化する方法を説明します。

なお、今回の記事は、案件の実績を基に執筆しているため、作業手順は特定の環境（マルチアカウント構成など）を前提にしています。適時、ご自身の環境に読み替えてご覧ください。

Security Lakeの概要

Security Lakeとは

Security Lakeとは、組織全体のセキュリティデータの一元管理・分析が可能なマネージドサービスです。AWS公式ドキュメントのSecurity Lakeユーザーガイドでは以下のように紹介されています。

Amazon Security Lake は、完全マネージド型のセキュリティデータレイクサービスです。Security Lake を使用すると、AWS 環境、SaaS プロバイダー、オンプレミス、クラウドソース、およびサードパーティーソースのセキュリティデータを、AWS アカウントに保存されている専用のデータレイクに自動的に一元化できます。
Security Lake はセキュリティデータの分析に役立つため、組織全体のセキュリティ体制をより完全に把握できます。Security Lake を使用すると、ワークロード、アプリケーション、データの保護を強化することもできます。

Amazon Security Lake とは何ですか? – Amazon Security Lake

Security Lakeの仕組み

Security Lakeの暗号化方式を変更するためには、構成要素の理解が重要です。以下にSecurity Lakeの内部構成例を示します。

Security Lakeの内部構成例
Security Lakeの内部構成例


Security Lakeの各構成要素の説明は以下です。

  • Security Lake委任管理アカウント
    • Security Lakeの設定をするためのアカウント
    • Security Lakeのリソースはこのアカウントに作成される
  • S3
    • Security Lakeが収集したログを保存するバケット
    • Security Lakeを有効化したリージョンごとに自動的に作成される
    • 「ロールアップリージョン」を設定することで、各リージョンのS3に保存されたログを特定のリージョンのS3に集約できる（内部的にはレプリケーションルールの自動追加が行われる）
  • サブスクライバー
    • Security Lake に保存されているデータにアクセスするためのエンティティ
    • ログを取り込むサービスごとにサブスクライバーを作成する必要があり、各サービスはサブスクライバーにアクセスしてログを取得する
  • Queue
    • S3にログが収集されたという情報を保持するためのキュー
    • サブスクライバーを作成すると自動的に作成される
    • Security Lakeからログを収集する各サービスは、SQSをポーリングすることでログが収集されたという情報を取得し、その情報をもとにS3からログを取得する
  • Rule（EventBridge）
    • ログの更新情報をQueueに保存するためのルール
    • サブスクライバーの取得対象ログを設定すると自動的に作成される
    • サブスクライバーの取得対象ログがS3に収集されると、EventBridgeルールがSQSにメッセージを送信する

AWS KMS カスタマーマネージドキーを用いた暗号化の必要性

Security Lakeを活用するにあたり、保持している情報の暗号化方式がセキュリティコンプライアンスを満たしているかどうか、注意する必要があります。

Security Lakeは先述の通り、Amazon S3（以下、S3）にログの実データを、Amazon SQS（以下、SQS）にログが更新されたというメッセージを保持しています。それらの暗号化方式は、デフォルトでは、S3はSSE-S3（Amazon S3マネージドキーによるサーバー側の暗号化）、SQSはSSE-SQS（Amazon SQSマネージドキーによるサーバー側の暗号化）が使用されています。

しかしながら、デフォルトのサーバ側暗号化方式（SSE-S3 / SSE-SQS）では、以下の要件を満たすことができないため、SSE-KMS（AWS Key Management Service (AWS KMS) カスタマーマネージドキーを用いた暗号化方式）の使用が求められます。

  • Secuirty Lakeが収集するセキュリティ状況のデータは機密情報にあたるため、コンプライアンス要件・監査要件から、暗号化キーの詳細な使用状況を追跡できる必要がある
  • 会社のガイドラインから、暗号化キーへのアクセスをIAMで制御する必要がある
  • 顧客環境の要件として、暗号化キーを半年ごとにローテーションする必要がある

以降は、同一Organization内で構成されたマルチアカウント環境を例にSecurity LakeのS3とSQSの暗号化方式をSSE-KMSに変更する方法を紹介します。なお、S3とSQSの暗号化方式は独立しているため、どちらか一方の暗号化方式だけを変更することも可能です。

S3の暗号化方式をSSE-KMSに変更する

前提：手順を実施するSecurity Lakeの設定

今回の手順を実施する環境の情報を以下に示します。

  • アカウント構成（いずれも同一Organizations内）
    • ログ取込み元アカウント
    • Security Lake委任アカウント
    • ログ連携先アカウント（サブスクライバーの連携先アカウント）
  • Security Lake
    • リージョン
      • ap-northeast-1（ロールアップリージョン）
      • ap-northeast-2
    • ソース
      • VPCフローログ
      • Security Hub検出結果
    • サブスクライバー
      • S3サブスクライバー
      • Lake Formationサブスクライバー
    • 暗号化方式
      • S3
        • SSE-S3（Amazon S3マネージドキーによるサーバー側の暗号化）
      • SQS
        • SSE-SQS（Amazon SQSマネージドキーによるサーバー側の暗号化）

S3の暗号化方法

以下の流れでSecurity LakeのS3の暗号化方式をSSE-KMSに変更します。

  1. S3暗号化用カスタマーマネージドキーの作成
  2. 暗号化コマンド実行
注意

手順実施前にS3に存在するオブジェクトの暗号化方式は更新されません。別途CLIなどでオブジェクトの暗号化方式を更新してください。
Security Lakeの構築と同時に暗号化方式の設定をする場合は、Security Lakeにログ収集対象アカウントを追加する前にこちらの作業をしてください。

1. S3暗号化用カスタマーマネージドキーの作成

以下のように設定したカスタマーマネージドキーを、Security Lakeを有効化するリージョンごとに作成します。

設定項目設定値
リージョン単一
キーポリシー以下を参照

○ S3暗号化用カスタマーマネージドキーのキーポリシー

{
    "Version": "2012-10-17",
    "Id": "Security-Lake-S3-Key-Policy",
    "Statement": [
        {
			<キーの削除権限や運用権限などを、必要に応じて定義>
		},
        {
            "Sid": "Allow SecurityLake ServiceRole To Use The Key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<アカウントID>:role/aws-service-role/securitylake.amazonaws.com/AWSServiceRoleForSecurityLake"
            },
            "Action": [
                "kms:CreateGrant",
                "kms:Encrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow LakeFormation And Subscriber Roles To Use The Key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                "arn:aws:iam::<アカウントID>:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormatinoDataAccess",
                "<S3サブスクライバーが存在する場合はここにサブスクライバーARNを定義>"
                ]
            },
            "Action": [
                "kms:CreateGrant",
                "kms:Decrypt"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow SLR",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:[partition]:iam::[accountid]:role/aws-service-role/resource-management.securitylake.amazonaws.com/AWSServiceRoleForSecurityLakeResourceManagement"
            },
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::<各リージョンのS3の名前>"
                },
                "StringLike": {
                    "kms:ViaService": "s3.<リージョンキー>.amazonaws.com"
                }
            }
        },
        <ロールアップリージョンを指定している場合は、以下を定義>
        {
            "Sid": "Allow SecurityLake ReplicationRole To Use The Key",
            "Effect": "Allow",
            "Principal": {
                "AWS:": "arn:aws:iam::<アカウントID>:role/service-role/AmazonSecurityLakeS3ReplicationRole"
            },
            "Action": [
            "kms:CreateGrant",
			<ロールアップリージョンのキーの場合は、以下を定義>
			"kms:Encrypt",
			"kms:GenerateDataKey"
			<ロールアップリージョン以外のキーの場合は、以下を定義>
			"kms:Decrypt"
            ],
            "Resource": "*"
        }
    ]
}

以下、キーポリシーの補足です。

  • Allow SecurityLake ServiceRole To Use The Key
    • Security Lakeのサービスリンクロールに、この鍵を暗号化に使用することを許可している
    • この許可によって、Security LakeがS3にオブジェクトを暗号化して保存できるようになる
  • Allow LakeFormation And Subscriber Roles To Use The Key
    • AWS Lake Formationのサービスリンクロールとサブスクライバー用IAMロールに、この鍵を復号に使用することを許可している
    • この許可によって、AWS Lake FormationとサブスクライバーがS3のオブジェクトを復号できるようになる
  • Allow SLR
    • Security Lakeのリソース管理用サービスリンクロールに、この鍵を復号に使用することを許可している
    • この許可によって、Security Lakeがリソースを管理できるようになる
  • Allow SecurityLake ReplicationRole To Use The Key
    （ロールアップリージョンを設定していない場合は、この許可は不要です）
    • オブジェクトを各リージョンからロールアップリージョンにレプリケートするときに使われるIAMロールに、この鍵を暗号化と復号に使用することを許可している
    • この許可によって、暗号化されたオブジェクトをレプリケートできるようになりる
    • レプリケーションに使うIAMロールを手動作成している場合は、IAMロールARNを修正してください

Organizations外のアカウントにデータを共有する場合は、クロスアカウントアクセスのための許可ポリシーを追加してください（本記事では割愛します）。

2. 暗号化コマンド実行

Security LakeのS3暗号化方式をSSE-KMSに変更したいリージョンに対して、以下のコマンドを実行します。コマンドを実行するリージョンは任意です。

$ aws securitylake update-data-lake 
>     --configurations '{ 
>         "encryptionConfiguration":{"kmsKeyId":"<S3暗号化キーのARN>"}, 
>         "region":"<Security Lakeを有効化するリージョンのコード>" 
>     }'

例として、アジアパシフィック（東京）リージョンのSecurity LakeのS3暗号化方式をSSE-KMSに変更する場合は以下になります。

aws securitylake update-data-lake 
　　　　--configurations '{ 
　　　　　　　　"encryptionConfiguration":{"kmsKeyId":"arn:aws:kms:ap-northeast-1:<アカウントID>:alias/SecurityLake-S3-Key"}, 
　　　　　　　　"region":"ap-northeast-1" 
　　　　}'

コマンドが成功すると、以下のような結果が得られます。

Security Lake暗号化コマンドの実行結果
Security Lake暗号化コマンドの実行結果

コマンド実行結果の"updateStatus"の"status"がINITIALIZED（初期化）になっています。しばらく時間をおいてから、コマンド"aws securitylake list-data-lakes“を実行します。

実行結果の "updateStatus"の"status"がCOMPLETEDになっている
実行結果の “updateStatus"の"status"がCOMPLETEDになっている

コマンド実行結果の"updateStatus"の"status"がCOMPLETEDになっていることが確認できました。

同様に、ap-northeast-3リージョンのS3も暗号化しました。

S3がKMS暗号化されていることの確認

Security Lakeのコンソールから、暗号化の設定が確認できます。

Security Lake ＞ リージョン
Security Lake ＞ リージョン

Security Lakeコンソール上の表示だけでなく、実際にオブジェクトがKMS暗号化されているか、かつロールアップリージョンを設定している場合は、レプリケーションが成功しているかを確認することをおすすめします。

まずは、ロールアップリージョンであるアジアパシフィック（東京）に保存されたオブジェクトの暗号化方式を確認します。

アジアパシフィック（東京）のS3に保存されたオブジェクト
アジアパシフィック（東京）のS3に保存されたオブジェクト

アジアパシフィック（東京）に保存されたオブジェクトの暗号化方式がきちんとSSE-KMSになっていますね。

続けて、アジアパシフィック（大阪）に保存されたオブジェクトと、アジアパシフィック（東京）にレプリケートされたオブジェクトをそれぞれ確認します。

アジアパシフィック（大阪）のS3に保存されたオブジェクト
アジアパシフィック（大阪）のS3に保存されたオブジェクト

アジアパシフィック（大阪）に保存されたオブジェクトの暗号化方式はきちんとSSE-KMSになっており、かつレプリケーションステータスがCOMPLETEDになっています。

レプリケーション後のオブジェクトも確認してみます。

アジアパシフィック（東京）のS3に保存されたオブジェクト
アジアパシフィック（東京）のS3に保存されたオブジェクト

アジアパシフィック（東京）に保存されたオブジェクトの暗号化方式はきちんとSSE-KMSになっており、かつレプリケーションステータスがREPLICAになっています。

無事、Security LakeのS3の暗号化方式をSSE-KMSに変更できました。

SQSの暗号化方式をSSE-KMSに変更する

前提：手順を実施するSecurity Lakeの設定

今回の手順を実施する環境の情報を以下に示します。

  • アカウント構成（いずれも同一Organizations内）
    • ログ取込み元アカウント
    • Security Lake委任アカウント
    • ログ連携先アカウント（サブスクライバーの連携先アカウント）
  • Security Lake
    • リージョン
      • ap-northeast-1（ロールアップリージョン）
      • ap-northeast-2
    • ソース
      • VPCフローログ
      • Security Hub検出結果
    • サブスクライバー
      • S3サブスクライバー
      • Lake Formationサブスクライバー
    • 暗号化方式
      • S3
        • SSE-KMS（AWS Key Management Service (AWS KMS) カスタマーマネージドキーを用いた暗号化）
      • SQS
        • SSE-SQS（Amazon SQSマネージドキーによるサーバー側の暗号化）

SQSの暗号化方法

以下の流れで、Security LakeのSQSの暗号化方式をSSE-KMSに変更します。

  1. SQS暗号化用カスタマーマネージドキーの作成
  2. サブスクライバー用IAMロールの更新
  3. SQS暗号化
注意

手順実施前にSQSに存在するメッセージの暗号化方式は更新されないため、別途CLIなどでメッセージの暗号化方式を更新してください。
Security Lakeの構築と同時に暗号化方式の設定をする場合は、Security Lakeにログ収集対象アカウントを追加する前にサブスクライバーを作成し、こちらの作業をしてください。

1. SQS暗号化用カスタマーマネージドキーの作成

以下のように設定したカスタマーマネージドキーを、Security Lakeのサブスクライバーが存在するリージョンごとに作成します。

設定項目設定値
リージョン単一
キーポリシー以下を参照

○ SQS暗号化用カスタマーマネージドキーのキーポリシー

{
    "Version": "2012-10-17",
    "Id": "Security-Lake-SQS-Key-Policy",
    "Statement": [
        {
			<キーの削除権限や運用権限などを、必要に応じて定義>
		},
        {
        "Sid": "Allow EventBridge To Use The Key",
        "Effect": "Allow",
        "Principal": {
            "Service": "events.amazonaws.com"
        },
        "Action": [
            "kms:GenerateDataKey",
            "kms:Decrypt"
        ],
        "Resource": "*"
        },
        {
        "Sid": "Allow Subscriber Role To Use The Key",
        "Effect": "Allow",
        "Principal": {
            "AWS": "<そのリージョンに存在するサブスクライバーのIAMロールARN>"
        },
        "Action": [
            "kms:CreateGrant",
            "kms:DescribeKey",
            "kms:GenerateDataKey",
            "kms:Decrypt"
        ],
        "Resource": "*"
        }
    ]
}

以下、キーポリシーの補足です。

  • Allow EventBridge To Use The Key
    • EventBridgeに、この鍵を暗号化に使用すること許可している
    • この許可によって、EventBridgeがSQSにメッセージを暗号化して保存できるようになる
  • Allow Subscriber Role To Use The Key
    • サブスクライバー用IAMロールに、この鍵を復号に使うことを許可している
    • この許可によって、サブスクライバー用IAMロールがSQSのメッセージを復号できるようになる

2. サブスクライバー用IAMロールの更新

サブスクライバー用IAMロールに、手順1で作成したカスタマーマネージドキーへのアクセスを許可します。

以下のIAMポリシーを、各サブスクライバー用IAMロールに付与します。

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "AllowDecryptForSpecificKey",
        "Effect": "Allow",
        "Action": "kms:Decrypt",
        "Resource": "<SQS暗号化キーのARN>"
    }
}

このIAMポリシーでは、サブスクライバー用IAMロールに、この鍵を復号に使うことを許可しています。この許可によって、サブスクライバー用IAMロールが、この鍵を使ってSQSのメッセージを復号できるようになります。

3. SQS暗号化

以下の画像のように、SQSのコンソールから、各サブスクライバーのSQSの暗号化方式をSSE-KMSに変更します。

コンソール＞暗号化＞編集
暗号化＞SSE-KMSに変更

SQSの暗号化方式を変更されているか、AWSコンソールから確認してください。

AWSコンソールから暗号化方式が変わっているか確認
SQS ＞ キュー

暗号化後、サブスクライバー経由でログが問題なく連携されることを確認してください。

まとめ

今回の記事ではSecurity Lakeの概要と、Security LakeのS3とSQSの暗号化方式をSSE-KMSに変更する方法を紹介しました。

私が半年前ほど前に作業したときは、S3暗号化後に手動でレプリケーションを編集する必要がありましたが、現在は自動設定されるようになっていました。いつかSecurity Lakeの暗号化方式を、コンソール上から簡単に変更できるようになるとよいですね。

ピンポイントな手順の紹介ではありましたが、読者の方の一助になれば幸いです。

  • Zabbix Enterprise Appliance
  • 低コスト・短納期で提供するまるごとおまかせZabbix

プラットフォーム技術部

Posted by h-nakamura