Amazon Security Lake におけるデータ保護 - Amazon Security Lake
保管中の暗号化転送中の暗号化

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Security Lake におけるデータ保護

責任 AWS 共有モデル、Amazon Security Lake でのデータ保護に適用されます。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。お客様は、このインフラストラクチャでホストされているコンテンツに対する管理を維持する責任があります。また、使用する AWS のサービス のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、「データプライバシーのよくある質問」を参照してください。欧州でのデータ保護の詳細については、AWS セキュリティブログに投稿された「AWS 責任共有モデルおよび GDPR」のブログ記事を参照してください。

データ保護の目的で、 認証情報を保護し AWS アカウント 、 AWS IAM Identity Center または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:

  • 各アカウントで多要素認証 (MFA) を使用します。

  • SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須であり TLS 1.3 がお勧めです。

  • を使用して API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。

  • AWS 暗号化ソリューションと、 内のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。

  • Amazon Macie などの高度なマネージドセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。

  • コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-2 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「連邦情報処理規格 (FIPS) 140-2」を参照してください。

お客様の E メールアドレスなどの極秘または機密情報は、タグ、または名前フィールドなどの自由形式のテキストフィールドに配置しないことを強くお勧めします。これは、コンソール、API、または SDK を使用して Security Lake AWS CLIまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs 名前に使用する自由記述のテキストフィールドやタグに入力したデータは、課金や診断ログに使用される場合があります。外部サーバーへの URL を提供する場合は、そのサーバーへのリクエストを検証するための認証情報を URL に含めないように強くお勧めします。

保管中の暗号化

Amazon Security Lake は、 AWS 暗号化ソリューションを使用して保管中のデータを安全に保存します。生のセキュリティログとイベントデータは、Security Lake が管理するアカウントのマルチテナントの Amazon Simple Storage Service (Amazon S3) バケットに保存されます。Security Lake は、 AWS Key Management Service () の AWS 所有キーを使用してこの raw データを暗号化しますAWS KMS。 AWS 所有キーは、 AWS サービス、この場合は Security Lake が所有および管理する AWS KMS キーのコレクションであり、複数の AWS アカウントで使用できます。

Security Lake は、生のログとイベントデータに対して抽出、変換、ロード (ETL) ジョブを実行します。処理されたデータは Security Lake サービスアカウントで暗号化されたままです。

ETL ジョブが完了すると、Security Lake はアカウントにシングルテナント S3 バケットを作成します (Security Lake を有効に AWS リージョン した各 に 1 つのバケット）。Security Lake がデータをシングルテナントの S3 バケットに確実に配信できるようになるまで、データはマルチテナントの S3 バケットに一時的にのみ保存されます。シングルテナントバケットには、ログとイベントデータをバケットに書き込む権限を Security Lake に付与するリソースベースのポリシーが含まれています。S3 バケット内のデータを暗号化するには、S3-managedの暗号化キーまたはカスタマー管理のキー ( から) のいずれかを選択できます AWS KMS。どちらの方法も対称暗号化を使用します。

KMS キーを使用してデータを暗号化します。

デフォルトでは、Security Lake によって S3 バケットに配信されるデータは、Amazon S3 で管理された暗号化キー (SSE-S3) を使用した Amazon サーバー側の暗号化によって暗号化されます。直接管理するセキュリティレイヤーを提供するには、代わりに Security Lake データに AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) を使用できます。

SSE-KMS は、セキュリティレイクコンソールではサポートされていません。セキュリティレイク API または CLI で SSE-KMS を使用するには、まず KMS キーを作成するか、既存のキーを使用します。Security Lake データの暗号化と復号化にどのユーザーがキーを使用できるかを決定するポリシーをキーにアタッチします。

顧客管理キーを使用して S3 バケットに書き込まれるデータを暗号化する場合、マルチリージョンキーは選択できません。カスタマー管理キーの場合、Security Lake は CreateGrant リクエストを AWS KMSに送信することで、ユーザーに代わって許可を作成します。の許可 AWS KMS は、Security Lake に顧客アカウントの KMS キーへのアクセスを許可するために使用されます。

Security Lake では、次の内部操作に顧客管理キーを使用するための許可を必要とします。

  • カスタマーマネージドキーで暗号化されたデータキーを生成する AWS KMS には、 にGenerateDataKeyリクエストを送信します。

  • にRetireGrantリクエストを送信します AWS KMS。データレイクを更新すると、この操作により、ETL 処理用の AWS KMS キーに追加されたグラントの廃止が可能になります。

セキュリティレイクにはDecrypt権限は必要ありません。キーの許可されたユーザーが Security Lake データを読み取ると、S3 が復号化を管理し、許可されたユーザーは暗号化されていない形式でデータを読み取ることができます。ただし、サブスクライバーがソースデータを使用するにはDecrypt権限が必要です。サブスクライバー権限の詳細については、Security Lake サブスクライバーのデータアクセスの管理 を参照してください。

既存の KMS キーを使用して Security Lake データを暗号化する場合は、KMS キーのキーポリシーを変更する必要があります。キーポリシーは、Lake Formation データレイクの場所に関連付けられた IAM ロールが KMS キーを使用してデータを復号することを許可する必要があります。KMS キーのキーポリシーを変更する方法については、「 AWS Key Management Service デベロッパーガイド」の「キーポリシーの変更」を参照してください。

キーポリシーを作成したり、適切な権限を持つ既存のキーポリシーを使用したりすると、KMS キーは付与リクエストを受け付けることができ、Security Lake がキーにアクセスできるようになります。キー ポリシーの作成手順については、AWS Key Management Service 開発者ガイドのキー ポリシーの作成を参照してください。

次のキーポリシーを KMS キーにアタッチします。


{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"}
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

顧客マネージドキーを使用する場合に必要な IAM アクセス許可

Security Lake を使用するために作成する必要がある IAM ロールの概要については、「はじめに:前提条件」セクションを参照してください。

カスタムソースまたはサブスクライバーを追加すると、Security Lake はアカウントに IAM ロールを作成します。これらのロールは他の IAM ID と共有することを目的としています。これにより、カスタムソースはデータレイクにデータを書き込み、サブスクライバーはデータレイクからのデータを使用できます。という AWS マネージドポリシーは、これらのロールのアクセス許可の境界AmazonSecurityLakePermissionsBoundaryを設定します。

Amazon SQS キューの暗号化

データレイクを作成すると、Security Lake は委任されたセキュリティレイク管理者アカウントに 2 つの暗号化されていない Amazon Simple Queue Service (Amazon SQS) キューを作成します。データを保護するには、これらのキューを暗号化する必要があります。Amazon Simple Queue Service が提供するデフォルトのサーバー側の暗号化では十分ではありません。 AWS Key Management Service （AWS KMS) でカスタマーマネージドキーを作成してキューを暗号化し、暗号化されたキューを操作するためのアクセス許可を Amazon S3 サービスプリンシパルに付与する必要があります。これらのアクセス許可を付与する手順については、 AWS ナレッジセンターの「サーバー側の暗号化を使用する Amazon SQS キューに Amazon S3 イベント通知が配信されないのはなぜですか？」を参照してください。

Security Lake は AWS Lambda を使用してデータの抽出、転送、ロード (ETL) ジョブをサポートするため、Amazon SQS キュー内のメッセージを管理するためのアクセス許可も Lambda に付与する必要があります。詳細については、「AWS Lambda デベロッパーガイド」の「実行ロールのアクセス許可」を参照してください。

転送中の暗号化

Security Lake は、 AWS サービス間で転送中のすべてのデータを暗号化します。Security Lake は、トランスポート層セキュリティ (TLS) 1.2 暗号化プロトコルを使用してすべてのネットワーク間データを自動的に暗号化することにより、サービスとの間で送受信されるデータを保護します。Security Lake API に送信されるダイレクト HTTPS リクエストは、署名バージョン 4 AWS アルゴリズムを使用して署名され、安全な接続を確立します。