Amazon Security Sake 中的数据保护 - Amazon Security Lake
静态加密传输中加密

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Amazon Security Sake 中的数据保护

分 AWS 担责任模式适用于亚马逊安全湖中的数据保护。如本模型所述 AWS ，负责保护运行所有内容的全球基础架构 AWS Cloud。您负责维护对托管在此基础架构上的内容的控制。您还负责您所使用的 AWS 服务 的安全配置和管理任务。有关数据隐私的更多信息，请参阅数据隐私常见问题。有关欧洲数据保护的信息，请参阅 AWS Security Blog 上的 AWS Shared Responsibility Model and 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 中的敏感数据。

  • 如果您在 AWS 通过命令行界面或 API 进行访问时需要经过 FIPS 140-2 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅《美国联邦信息处理标准 (FIPS) 第 140-2 版》。

我们强烈建议您切勿将机密信息或敏感信息（如您客户的电子邮件地址）放入标签或自由格式文本字段（如名称字段）。这包括你 AWS 服务 使用控制台、API 或 AWS SDK 与 Security Lake 或其他人合作时。 AWS CLI在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供网址，强烈建议您不要在网址中包含凭证信息来验证对该服务器的请求。

静态加密

Amazon Security Lake 使用 AWS 加密解决方案安全地存储您的静态数据。原始安全日志和事件数据存储在由 Security Lake 管理的账户中的一个多租户 Amazon Simple Storage Service（Amazon S3）桶中。Security Lake 使用来自 AWS Key Management Service (AWS KMS) 的AWS 自有密钥对这些原始数据进行加密。 AWS 拥有的密钥是 AWS 服务（在本例中为 Securit AWS KMS y Lake）拥有和管理的密钥集合，供多个账户使用。 AWS

Security Lake 对原始日志和事件数据运行提取、转换和加载（ETL）任务。处理后的数据在 Security Lake 服务账户中保持加密状态。

ETL 任务完成后，Security Lake 会在您的账户中创建单租户 S3 存储桶（您在其中启用 Security Lake AWS 区域 的每个存储桶对应一个存储桶）。数据仅临时存储在多租户 S3 存储桶中，直到 Security Lake 能够可靠地将数据传输到单租户 S3 存储桶。单租户桶包含一个基于资源的策略，该策略授予 Security Lake 向桶写入日志和事件数据的权限。要加密 S3 存储桶中的数据，您可以选择 S3 托管的加密密钥或客户托管的密钥（来自 AWS KMS）。两者都使用对称加密。

使用 KMS 密钥加密您的数据

默认情况下，Security Lake 传输到 S3 存储桶的数据使用 Amazon S3 托管的加密密钥（SSE-S3）进行 Amazon 服务器端加密。要提供您可以直接管理的安全层，您可以改为使用带有 AWS KMS 密钥的服务器端加密 (SSE-KMS) 来处理您的 Sec urity Lake 数据。

Security Lake 控制台不支持 SSE-KMS。要将 SSE-KMS 用于 Security Lake API 或 CLI，请先创建 KMS 密钥或使用现有密钥。您需要向密钥附加一个策略，规定哪些用户可以使用该密钥加密和解密 Security Lake 数据。

如果使用客户托管密钥来加密写入到 S3 存储桶的数据，则无法选择多区域密钥。对于客户托管密钥，Security Lake 将通过向 AWS KMS发送 CreateGrant 请求来代表您创建授权。中的授权 AWS KMS 用于授予 Security Lake 访问客户账户中的 KMS 密钥的权限。

Security Lake 需要该授权才能将客户托管密钥用于以下内部操作：

  • 向发送GenerateDataKey请求 AWS KMS 以生成由您的客户托管密钥加密的数据密钥。

  • 向RetireGrant... 发送请求 AWS KMS。当您对数据湖进行更新时，此操作将导致添加到 AWS KMS 密钥以用于 ETL 处理的授权停用。

Security Lake 不需要 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 身份共享。它们允许自定义源向数据湖写入数据，并允许订阅用户使用数据湖中的数据。名为的 AWS 托管策略AmazonSecurityLakePermissionsBoundary设置了这些角色的权限边界。

加密 Amazon SQS 队列

创建数据湖时，Security Lake 会在委派的 Security Lake 管理员账户中创建两个未加密的 Amazon Simple Queue Service (Amazon SQS) 队列。您应该加密这些队列以保护您的数据。Amazon Simple Queue Service 提供的默认服务器端加密 (SSE) 是不够的。您必须在 AWS Key Management Service (AWS KMS) 中创建客户托管密钥来加密队列，然后授予 Amazon S3 服务主体使用加密队列的权限。有关授予这些权限的说明，请参阅为什么 Amazon S3 事件通知没有发送到使用服务器端加密的 Amazon SQS 队列？ 在 AWS 知识中心中。

由于 Security Lake 用于支持 AWS Lambda 对您的数据进行提取、传输和加载 (ETL) 任务，因此您还必须向 Lambda 授予管理您的 Amazon SQS 队列中消息的权限。有关信息，请参阅《AWS Lambda 开发人员指南》中的执行角色权限。

传输中加密

Security Lake 对 AWS 服务之间传输的所有数据进行加密。通过使用传输层安全（TLS）1.2 加密协议自动加密所有网络间数据，Security Lake 在传输中数据进出服务时对其进行保护。发送到 Security Lake API 的直接 HTTPS 请求使用 AWS 签名版本 4 算法进行签名，以建立安全连接。