本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 安全湖的安全 云安全 AWS 是重中之重。作为 AWS 客户，您可以受益于专为满足大多数安全敏感型组织的要求而构建的数据中心和网络架构。 安全是双方 AWS 的共同责任。[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)将其描述为云*的*安全性和云*中*的安全性： + **云安全** — AWS 负责保护在云中运行 AWS 服务的基础架构 AWS 云。 AWS 还为您提供可以安全使用的服务。作为[AWS 合规计划合规计划合规计划合](https://aws.amazon.com/compliance/programs/)的一部分，第三方审计师定期测试和验证我们安全的有效性。要了解适用于 Amazon Security Lake 的合规计划，请参阅[按合规计划提供的范围内的AWSAWS 服务按合规计划](https://aws.amazon.com/compliance/services-in-scope/)服务。 + **云端安全**-您的责任由您使用的 AWS 服务决定。您还需要对其他因素负责，包括您的数据的敏感性、您公司的要求以及适用的法律法规。 此文档将帮助您了解如何在使用 Security Lake 时应用责任共担模型。以下主题说明如何配置 Security Lake 以实现您的安全性和合规性目标。您还将学习如何使用其他 AWS 服务来帮助您监控和保护您的 Security Lake 资源。 **Topics** + [Security Lake 的身份和访问管理](security-iam.md) + [Amazon Security Sake 中的数据保护](data-protection.md) + [Amazon Security Lake 的合规性验证](compliance-validation.md) + [Security Lake 的安全最佳实践](best-practices-overview.md) + [Amazon Security Lake 中的故障恢复能力](disaster-recovery-resiliency.md) + [Amazon Security Lake 中的基础设施安全性](infrastructure-security.md) + [Security Lake 中的配置和脆弱性分析](configuration-vulnerability-analysis.md) + [Amazon 安全湖和接口 VPC 终端节点 (AWS PrivateLink)](security-vpc-endpoints.md) + [监控 Amazon Security Lake](monitoring-overview.md) # Security Lake 的身份和访问管理 AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制哪些人可以*通过身份验证*（登录）和*授权*（具有权限）使用 Security Lake 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。 **Topics** + [受众](#security_iam_audience) + [使用身份进行身份验证](#security_iam_authentication) + [使用策略管理访问](#security_iam_access-manage) + [安全湖如何与 IAM 配合使用](security_iam_service-with-iam.md) + [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md) + [AWS 安全湖的托管策略](security-iam-awsmanpol.md) + [在 Security Lake 中使用服务相关角色](using-service-linked-roles.md) ## 受众 您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异： + **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[Amazon Security Lake 身份和访问故障排除](security_iam_troubleshoot.md)） + **服务管理员**：确定用户访问权限并提交权限请求（请参阅[安全湖如何与 IAM 配合使用](security_iam_service-with-iam.md)） + **IAM 管理员**：编写用于管理访问权限的策略（请参阅[Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)） ## 使用身份进行身份验证 身份验证是您 AWS 使用身份凭证登录的方式。您必须以 IAM 用户身份进行身份验证 AWS 账户根用户，或者通过担任 IAM 角色进行身份验证。 您可以使用来自身份源的证书 AWS IAM Identity Center （例如（IAM Identity Center）、单点登录身份验证或 Google/Facebook 证书，以联合身份登录。有关登录的更多信息，请参阅《AWS 登录 用户指南》**中的[如何登录您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。 对于编程访问， AWS 提供 SDK 和 CLI 来对请求进行加密签名。有关更多信息，请参阅*《IAM 用户指南》*中的[适用于 API 请求的AWS 签名版本 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。 ### AWS 账户 root 用户 创建时 AWS 账户，首先会有一个名为 AWS 账户 *root 用户的*登录身份，该身份可以完全访问所有资源 AWS 服务 和资源。我们强烈建议不要使用根用户进行日常任务。有关需要根用户凭证的任务，请参阅《IAM 用户指南》**中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 ### 联合身份 作为最佳实践，要求人类用户使用与身份提供商的联合身份验证才能 AWS 服务 使用临时证书进行访问。 *联合身份是指*来自您的企业目录、Web 身份提供商的用户 Directory Service ，或者 AWS 服务 使用来自身份源的凭据进行访问的用户。联合身份代入可提供临时凭证的角色。 要集中管理访问权限，建议使用。 AWS IAM Identity Center有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[什么是 IAM Identity Center？](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。 ### IAM 用户和群组 *[IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*是对某个人员或应用程序具有特定权限的一个身份。建议使用临时凭证，而非具有长期凭证的 IAM 用户。有关更多信息，请参阅 *IAM 用户指南*[中的要求人类用户使用身份提供商的联合身份验证才能 AWS 使用临时证书进行访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)指定一组 IAM 用户，便于更轻松地对大量用户进行权限管理。有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM 用户使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。 ### IAM 角色 *[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*是具有特定权限的身份，可提供临时凭证。您可以通过[从用户切换到 IAM 角色（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或调用 AWS CLI 或 AWS API 操作来代入角色。有关更多信息，请参阅《IAM 用户指南》**中的[担任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。 IAM 角色对于联合用户访问、临时 IAM 用户权限、跨账户访问、跨服务访问以及在 Amazon EC2 上运行的应用程序非常有用。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 ## 使用策略管理访问 您可以 AWS 通过创建策略并将其附加到 AWS 身份或资源来控制中的访问权限。策略定义了与身份或资源关联时的权限。 AWS 在委托人提出请求时评估这些政策。大多数策略都以 JSON 文档的 AWS 形式存储在中。有关 JSON 策略文档的更多信息，请参阅*《IAM 用户指南》*中的 [JSON 策略概述](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。 管理员使用策略，通过定义哪个**主体**可以在什么**条件**下对哪些**资源**执行哪些**操作**来指定谁有权访问什么。 默认情况下，用户和角色没有权限。IAM 管理员创建 IAM 策略并将其添加到角色中，然后用户可以担任这些角色。IAM 策略定义权限，与执行操作所用的方法无关。 ### 基于身份的策略 基于身份的策略是您附加到身份（用户、组或角色）的 JSON 权限策略文档。这些策略控制身份可以执行什么操作、对哪些资源执行以及在什么条件下执行。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 基于身份的策略可以是*内联策略*（直接嵌入到单个身份中）或*托管策略*（附加到多个身份的独立策略）。要了解如何在托管策略和内联策略之间进行选择，请参阅*《IAM 用户指南》*中的[在托管策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)。 ### 基于资源的策略 基于资源的策略是附加到资源的 JSON 策略文档。示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。 基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用 IAM 中的 AWS 托管策略。 ### 其他策略类型 AWS 支持其他策略类型，这些策略类型可以设置更常见的策略类型授予的最大权限： + **权限边界** – 设置基于身份的策略可以授予 IAM 实体的最大权限。有关更多信息，请参阅《 IAM 用户指南》**中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。 + **服务控制策略 (SCPs)**-在中指定组织或组织单位的最大权限 AWS Organizations。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 + **资源控制策略 (RCPs)**-设置账户中资源的最大可用权限。有关更多信息，请参阅《*AWS Organizations 用户指南》*中的[资源控制策略 (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。 + **会话策略** – 在为角色或联合用户创建临时会话时，作为参数传递的高级策略。有关更多信息，请参阅《IAM 用户指南》**中的[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。 ### 多个策略类型 当多个类型的策略应用于一个请求时，生成的权限更加复杂和难以理解。要了解在涉及多种策略类型时如何 AWS 确定是否允许请求，请参阅 *IAM 用户指南*中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。 # 安全湖如何与 IAM 配合使用 在使用 IAM 管理对 Security Lake 的访问之前，您应该了解哪些 IAM 功能可用于 Security Lake。 **将 IAM 功能与 Amazon Security Lake 一起使用** | IAM 功能 | Security Lake 支持 | | --- | --- | | [基于身份的策略](#security_iam_service-with-iam-id-based-policies) | 是 | | [基于资源的策略](#security_iam_service-with-iam-resource-based-policies) | 是 | | [策略操作](#security_iam_service-with-iam-id-based-policies-actions) | 是 | | [策略资源](#security_iam_service-with-iam-id-based-policies-resources) | 是 | | [策略条件键](#security_iam_service-with-iam-id-based-policies-conditionkeys) | 是 | | [ACLs](#security_iam_service-with-iam-acls) | 否 | | [ABAC（策略中的标签）](#security_iam_service-with-iam-tags) | 是 | | [临时凭证](#security_iam_service-with-iam-roles-tempcreds) | 是 | | [主体权限](#security_iam_service-with-iam-principal-permissions) | 是 | | [服务角色](#security_iam_service-with-iam-roles-service) | 否 | | [服务关联角色](#security_iam_service-with-iam-roles-service-linked) | 是 | 要全面了解 Security Lake 和其他 AWS 服务如何与大多数 IAM 功能配合使用，请参阅 [IAM *用户指南中的与 IAM* 配合使用的AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 ## Security Lake 基于身份的策略 **支持基于身份的策略：**是 基于身份的策略是可附加到身份（如 IAM 用户、用户组或角色）的 JSON 权限策略文档。这些策略控制用户和角色可在何种条件下对哪些资源执行哪些操作。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 通过使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源以及允许或拒绝操作的条件。要了解可在 JSON 策略中使用的所有元素，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素引用](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)。 Security Lake 支持基于身份的策略。有关更多信息，请参阅 [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 ## Security Lake 内基于资源的策略 **支持基于资源的策略：**是 基于资源的策略是附加到资源的 JSON 策略文档。基于资源的策略的示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。对于在其中附加策略的资源，策略定义指定主体可以对该资源执行哪些操作以及在什么条件下执行。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。委托人可以包括账户、用户、角色、联合用户或 AWS 服务。 要启用跨账户访问，您可以将整个账户或其他账户中的 IAM 实体指定为基于资源的策略中的主体。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 Security Lake 服务会为存储数据的 Amazon S3 存储桶创建基于资源的策略。您无需将这些基于资源的策略附加到 S3 存储桶。Security Lake 会代表您自动创建这些策略。 示例资源是一个 S3 存储桶，其 Amazon 资源名称 (ARN) 为 `arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}`。在此示例中，`region`是您启用 Security Lake 的具体 AWS 区域 位置，并且`bucket-identifier`是 Security Lake 分配给存储桶的区域唯一字母数字字符串。Security Lake 创建了 S3 存储桶以存储来自该区域的数据。资源策略定义了哪些主体可以对该桶执行操作。以下是 Security Lake 附加到桶的基于资源的策略（桶策略）示例： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}/*", "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}" ], "Condition": { "Bool": { "aws:SecureTransport": "false" } } }, { "Sid": "PutSecurityLakeObject", "Effect": "Allow", "Principal": { "Service": "securitylake.amazonaws.com" }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}/*", "arn:aws:s3:::aws-security-data-lake-{region}-{bucket-identifier}" ], "Condition": { "StringEquals": { "aws:SourceAccount": "{DA-AccountID}", "s3:x-amz-acl": "bucket-owner-full-control" }, "ArnLike": { "aws:SourceArn": "arn:aws:securitylake:us-east-1:111122223333:*" } } } ] } ``` ------ 要详细了解基于资源的策略，请参阅《IAM 用户指南》**中的[基于身份的策略和基于资源的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)。 ## Security Lake 的策略操作 **支持策略操作：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。 有关 Security Lake 操作的列表，请参阅“服务授权参考”**中的 [Amazon Security Lake 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)。 Security Lake 中的策略操作在操作前使用以下前缀： ``` securitylake ``` 例如，要向用户授予访问特定订阅用户的信息的权限，请在分配给该用户的策略中包含 `securitylake:GetSubscriber` 操作。策略语句必须包含 `Action` 或 `NotAction` 元素。Security Lake 定义了一组自己的操作，以描述您可以使用该服务执行的任务。 要在单个语句中指定多项操作，请使用逗号将它们隔开。 ``` "Action": [ "securitylake:action1", "securitylake:action2" ] ``` 要查看 Security Lake 基于身份的策略示例，请参阅 [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 ## Security Lake 的策略资源 **支持策略资源：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。 ``` "Resource": "*" ``` Security Lake 定义了以下资源类型：订阅者和特定资源的数据湖配置 AWS 区域。 AWS 账户 您可以使用在策略中指定这些类型的资源 ARNs。 有关 Security Lake 资源类型的列表以及每种类型的 ARN 语法，请参阅“服务授权参考”**中的 [Amazon Security Lake 定义的资源类型](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-resources-for-iam-policies)。要了解可以为每种类型的资源指定哪些操作，请参阅“服务授权参考”**中的 [Amazon Security Lake 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)。 要查看 Security Lake 基于身份的策略示例，请参阅 [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 ## Security Lake 的策略条件键 **支持特定于服务的策略条件键：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Condition` 元素根据定义的条件指定语句何时执行。您可以创建使用[条件运算符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)（例如，等于或小于）的条件表达式，以使策略中的条件与请求中的值相匹配。要查看所有 AWS 全局条件键，请参阅 *IAM 用户指南*中的[AWS 全局条件上下文密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。 有关 Security Lake 条件键的列表，请参阅“服务授权参考”**中的 [Amazon Security Lake 的条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-policy-keys)。要了解可以为哪些操作和资源使用条件键，请参阅“服务授权参考”**中的 [Amazon Security Lake 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)。有关使用条件键的策略示例，请参阅 [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 ## Security Lake 中的访问控制列表 (ACLs) **支持 ACLs：**否 访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。 Security Lake 不支持 ACLs，这意味着你无法将 ACL 附加到 Security Lake 资源。 ## 用于 Security Lake 的基于属性的访问权限控制 (ABAC) **支持 ABAC（策略中的标签）：**是 基于属性的访问权限控制（ABAC）是一种授权策略，该策略基于称为标签的属性来定义权限。您可以将标签附加到 IAM 实体和 AWS 资源，然后设计 ABAC 策略以允许在委托人的标签与资源上的标签匹配时进行操作。 要基于标签控制访问，您需要使用 `aws:ResourceTag/key-name``aws:RequestTag/key-name` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。 如果某个服务对于每种资源类型都支持所有这三个条件键，则对于该服务，该值为**是**。如果某个服务仅对于部分资源类型支持所有这三个条件键，则该值为**部分**。 有关 ABAC 的更多信息，请参阅《IAM 用户指南》**中的[使用 ABAC 授权定义权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)。要查看设置 ABAC 步骤的教程，请参阅《IAM 用户指南》**中的[使用基于属性的访问权限控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)。 您可以将标签附加到 Security Lake 资源（订阅者），以及个人的数据湖配置。 AWS 账户 AWS 区域您还可以通过在策略的 `Condition` 元素中提供标签信息来控制对这些资源的访问。有关标记 Security Lake 资源的更多信息，请参阅[为安全湖资源添加标签](tagging-resources.md)。有关基于身份的策略（用于根据资源的标签控制对该资源的访问）示例，请参阅 [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 ## 为 Security Lake 使用临时凭证 **支持临时凭证：**是 临时证书提供对 AWS 资源的短期访问权限，并且是在您使用联合身份或切换角色时自动创建的。 AWS 建议您动态生成临时证书，而不是使用长期访问密钥。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)和[使用 IAM 的。AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) Security Lake 支持使用临时凭证。 ## 安全湖的转发访问会话 **支持转发访问会话（FAS）：**是 转发访问会话 (FAS) 使用调用主体的权限 AWS 服务，再加上 AWS 服务 向下游服务发出请求的请求。有关发出 FAS 请求时的策略详情，请参阅[转发访问会话](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)。 某些 Security Lake 操作需要其他 AWS 服务中的其他相关操作的权限。有关这些操作的列表，请参阅“服务授权参考”**中的 [Amazon Security Lake 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html#amazonsecuritylake-actions-as-permissions)。 ## Security Lake 的服务角色 **支持服务角色：**否 服务角色是由一项服务担任、代表您执行操作的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。IAM 管理员可以在 IAM 中创建、修改和删除服务角色。有关更多信息，请参阅《IAM 用户指南》**中的[创建向 AWS 服务委派权限的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)。 Security Lake 不代入或使用服务角色。但是，当您使用安全湖时 EventBridge AWS Lambda，诸如Amazon和Amazon S3之类的相关服务将扮演服务角色。要代表您执行操作，Security Lake 会使用服务相关角色。 **警告** 更改服务角色的权限可能会在您使用 Security Lake 时导致操作问题。仅当 Security Lake 提供相应指导时才编辑服务角色。 ## Security Lake 的服务相关角色 **支持服务关联角色：**是 服务相关角色是一种与服务相关联的 AWS 服务服务角色。服务可以代入代表您执行操作的角色。服务相关角色出现在您的中 AWS 账户 ，并且归服务所有。IAM 管理员可以查看但不能编辑服务关联角色的权限。 Security Lake 使用名为 `AWSServiceRoleForAmazonSecurityLake` 的 IAM 服务相关角色。Security Lake 服务相关角色授予代表客户操作安全数据湖服务的权限。服务相关角色是一种与 Security Lake 直接关联的 IAM 角色。它是由 Security Lake 预定义的，它包括 Security Lake AWS 服务 代表你呼叫他人所需的所有权限。Security Lake 在所有可用 Security Lake AWS 区域 的地方都使用此服务相关角色。 有关创建或管理 Security Lake 服务相关角色的详细信息，请参阅 [在 Security Lake 中使用服务相关角色](using-service-linked-roles.md)。 # Security Lake 基于身份的策略示例 默认情况下，用户和角色没有创建或修改 Security Lake 资源的权限。要授予用户对所需资源执行操作的权限，IAM 管理员可以创建 IAM 策略。 要了解如何使用这些示例 JSON 策略文档创建基于 IAM 身份的策略，请参阅《IAM 用户指南》**中的[创建 IAM 策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 有关 Security Lake 定义的操作和资源类型（包括每种资源类型的格式）的详细信息，请参阅《*服务授权参考*》中的 [Amazon Security Lake 的操作、资源和条件密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsecuritylake.html)。 ARNs **Topics** + [策略最佳实践](#security_iam_service-with-iam-policy-best-practices) + [使用 Security Lake 控制台](#security_iam_id-based-policy-examples-console) + [示例：允许用户查看自己的权限](#security_iam_id-based-policy-examples-view-own-permissions) + [示例：允许组织管理账户指定和移除委托的管理员](#security_iam_id-based-policy-examples-orgs) + [示例：允许用户根据标签查看订阅用户](#security_iam_id-based-policy-examples-review-subscribers-tags) ## 策略最佳实践 基于身份的策略用于确定某个人是否可以创建、访问或删除您账户中的 Security Lake 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议： + **开始使用 AWS 托管策略并转向最低权限权限** — 要开始向用户和工作负载授予权限，请使用为许多常见用例授予权限的*AWS 托管策略*。它们在你的版本中可用 AWS 账户。我们建议您通过定义针对您的用例的 AWS 客户托管策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。 + **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。 + **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果服务操作是通过特定的方式使用的，则也可以使用条件来授予对服务操作的访问权限 AWS 服务，例如 CloudFormation。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。 + **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。 + **需要多重身份验证 (MFA**)-如果 AWS 账户您的场景需要 IAM 用户或根用户，请启用 MFA 以提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[使用 MFA 保护 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。 有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 ## 使用 Security Lake 控制台 要访问 Amazon Security Lake 控制台，您必须具有一组最低权限。这些权限必须允许您列出和查看有关您的 Security Lake 资源的详细信息 AWS 账户。如果创建比必需的最低权限更为严格的基于身份的策略，对于附加了该策略的实体（用户或角色），控制台将无法按预期正常运行。 对于仅调用 AWS CLI 或 AWS API 的用户，您无需为其设置最低控制台权限。相反，只允许访问与其尝试执行的 API 操作相匹配的操作。 为确保用户和角色可以使用 Security Lake 控制台，请创建 IAM 策略并为其提供控制台访问权限。有关更多信息，请参阅《*IAM 用户指南*》中的 [IAM 标识符](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)。 如果您创建了允许用户或角色使用 Security Lake 控制台的策略，请确保该策略包含这些用户或角色需要在控制台上访问的资源的相应操作。否则，他们将无法在控制台上导航到或显示这些资源的详细信息。 例如，要使用控制台添加自定义来源，用户必须能够执行以下操作： + `glue:CreateCrawler` + `glue:CreateDatabase` + `glue:CreateTable` + `glue:StartCrawlerSchedule` + `iam:GetRole` + `iam:PutRolePolicy` + `iam:DeleteRolePolicy` + `iam:PassRole` + `lakeformation:RegisterResource` + `lakeformation:GrantPermissions` + `s3:ListBucket` + `s3:PutObject` ## 示例：允许用户查看自己的权限 该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管策略。此策略包括在控制台上或使用 AWS CLI 或 AWS API 以编程方式完成此操作的权限。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## 示例：允许组织管理账户指定和移除委托的管理员 此示例展示了如何创建一项策略来允许 AWS Organizations 组织管理账户的用户为其组织指定和移除委托的 Security Lake 管理员。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "securitylake:RegisterDataLakeDelegatedAdministrator", "securitylake:DeregisterDataLakeDelegatedAdministrator" ], "Resource": "arn:aws:securitylake:*:*:*" } ] } ``` ------ ## 示例：允许用户根据标签查看订阅用户 在基于身份的策略中，您可以使用条件基于标签来控制对 Security Lake 资源的访问。本示例展示了如何创建允许用户使用 Security Lake 控制台或 Security Lake API 查看订阅用户的策略。但是，只有当订阅用户的 `Owner` 标签的值是用户的用户名时，系统才会授予权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReviewSubscriberDetailsIfOwner", "Effect": "Allow", "Action": "securitylake:GetSubscriber", "Resource": "arn:aws:securitylake:*:*:subscriber/*", "Condition": { "StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"} } }, { "Sid": "ListSubscribersIfOwner", "Effect": "Allow", "Action": "securitylake:ListSubscribers", "Resource": "*", "Condition": { "StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"} } } ] } ``` ------ 在本示例中，如果用户名为 `richard-roe` 的用户试图查看某个订阅用户的详细信息，则该订阅用户必须标记为 `Owner=richard-roe` 或 `owner=richard-roe`。否则，该用户将被拒绝访问。条件标签键 `Owner` 匹配 `Owner` 和 `owner`，因为条件键名称不区分大小写。有关条件键的更多信息，请参阅《IAM 用户指南》[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中的 *IAM JSON 策略元素：条件*。有关标记 Security Lake 资源的更多信息，请参阅[为安全湖资源添加标签](tagging-resources.md)。 # AWS 安全湖的托管策略 AWS 托管策略是由创建和管理的独立策略 AWS。 AWS 托管策略旨在为许多常见用例提供权限，以便您可以开始为用户、组和角色分配权限。 请记住， AWS 托管策略可能不会为您的特定用例授予最低权限权限，因为它们可供所有 AWS 客户使用。我们建议通过定义特定于使用案例的[客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)来进一步减少权限。 您无法更改 AWS 托管策略中定义的权限。如果 AWS 更新 AWS 托管策略中定义的权限，则更新会影响该策略所关联的所有委托人身份（用户、组和角色）。 AWS 最有可能在启动新的 API 或现有服务可以使用新 AWS 服务 的 API 操作时更新 AWS 托管策略。 有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。 ## AWS 托管策略： AmazonSecurityLakeMetastoreManager Amazon Security Lake 使用一项 AWS Lambda 功能来管理您的数据湖中的元数据。通过使用此功能，Security Lake 可以将包含您的数据和数据文件的亚马逊简单存储服务 (Amazon S3) Service 分区索引到数据目录 AWS Glue 表中。此托管策略包含 Lambda 函数将 S3 分区和数据文件索引到表中的 AWS Glue 所有权限。 **权限详细信息** 该策略包含以下权限： + `logs`— 允许委托人将 Lambda 函数的输出记录到 Amazon CloudWatch 日志。 + `glue`— 允许委托人对 AWS Glue 数据目录表执行特定的写入操作。这也允许 AWS Glue 抓取工具识别您的数据中的分区。 + `sqs`— 允许委托人对在数据湖中添加或更新对象时发送事件通知的 Amazon SQS 队列执行特定的读写操作。 + `s3`— 允许委托人对包含您的数据的 Amazon S3 存储桶执行特定的读取和写入操作。 要查看此策略的权限，请参阅《AWS 托管式策略参考》**中的 [AmazonSecurityLakeMetastoreManager](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSecurityLakeMetastoreManager.html)。 ## AWS 托管策略： AmazonSecurityLakePermissionsBoundary Amazon Security Lake 会为第三方自定义源创建 IAM 角色以将数据写入数据湖，为第三方自定义订阅用户创建 IAM 角色以使用数据湖中的数据，并在创建这些角色时使用此策略来定义其权限边界。您无需执行任何操作即可使用此策略。如果使用客户管理的 AWS KMS 密钥对数据湖进行加密`kms:Decrypt`，则添加了`kms:GenerateDataKey`权限。 要查看此策略的权限，请参阅《AWS 托管式策略参考》**中的 [AmazonSecurityLakePermissionsBoundary](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSecurityLakePermissionsBoundary.html)。 ## AWS 托管策略： AmazonSecurityLakeAdministrator 您可以在某个主体为其账户启用 Amazon Security Lake 之前为该主体附加 `AmazonSecurityLakeAdministrator` 策略。此策略授予管理权限，允许主体拥有对所有 Security Lake 操作的完全访问权限。之后，该主体便可注册到 Security Lake 中，并在 Security Lake 中配置来源和订阅用户。 该策略包括 Security Lake 管理员可通过 Security Lake 对其他 AWS 服务执行的操作。 该`AmazonSecurityLakeAdministrator`政策不支持创建 Security Lake 所需的实用程序角色来管理 Amazon S3 跨区域复制、在中注册新的数据分区 AWS Glue、对添加到自定义源的数据运行 Glue 爬虫或通知 HTTPS 终端节点订阅者新数据。您可以按照 [Amazon Security Lake 入门](getting-started.md)中的说明提前创建这些角色。 除 `AmazonSecurityLakeAdministrator` 托管式策略外，Security Lake 还需要 `lakeformation:PutDataLakeSettings` 权限来执行注册和配置功能。`PutDataLakeSettings` 允许将某个 IAM 主体设置为账户中所有区域 Lake Formation 资源的管理员。该角色必须同时附加有 `iam:CreateRole permission` 权限和 `AmazonSecurityLakeAdministrator` 策略。 Lake Formation 管理员拥有对 Lake Formation 控制台的完全访问权限，并且可以控制初始数据配置和访问权限。Security Lake 会将启用 Security Lake 的主体和 `AmazonSecurityLakeMetaStoreManager` 角色（或其他指定角色）指定为 Lake Formation 管理员，以便他们可以创建表、更新表架构、注册新分区以及配置表的权限。您必须在 Security Lake 管理员用户或角色的策略中包含以下权限： **注意** 为了提供足够的权限来授予基于 Lake Formation 的订阅者访问权限，Security Lake 建议添加以下`glue:PutResourcePolicy`权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowPutLakeFormationSettings", "Effect": "Allow", "Action": "lakeformation:PutDatalakeSettings", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": "securitylake.amazonaws.com" } } }, { "Sid": "AllowGlueActions", "Effect": "Allow", "Action": ["glue:PutResourcePolicy", "glue:DeleteResourcePolicy"], "Resource": [ "arn:aws:glue:*:*:catalog", "arn:aws:glue:*:*:database/amazon_security_lake_glue_db*", "arn:aws:glue:*:*:table/amazon_security_lake_glue_db*/*" ], "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": "securitylake.amazonaws.com" } } } ] } ``` ------ **权限详细信息** 该策略包含以下权限。 + `securitylake` – 允许主体对所有 Security Lake 操作拥有完全访问权限。 + `organizations` – 允许主体通过 AWS Organizations 检索有关组织中的账户的信息。如果账户属于某个组织，则这些权限允许 Security Lake 控制台显示账户名称和账号。 + `iam`— 允许委托人在 Security Lake、 AWS Lake Formation、和中创建服务相关角色 Amazon EventBridge，这是启用这些服务时的必需步骤。同时，还允许为订阅用户和自定义来源角色创建和编辑策略，这些角色中的权限仅限于 `AmazonSecurityLakePermissionsBoundary` 策略允许的权限。 + `ram`— 允许委托人配置订阅者对 Security Lake 源的 Lake Formation基于查询的访问权限。 + `s3`– 允许主体创建和管理 Security Lake 桶并读取这些桶的内容。 + `lambda`— 允许委托人管理 Lambda 用于在 AWS 源数据传输和跨区域复制之后更新 AWS Glue 表分区。 + `glue` – 允许主体创建和管理 Security Lake 数据库和表。 + `lakeformation`— 允许委托人管理 Security Lake 表的 Lake Formation 权限。 + `events` – 允许主体管理用于在新数据写入 Security Lake 来源时通知订阅用户的规则。 + `sqs`— 允许委托人创建和管理 Amazon SQS 队列，用于向订阅者通知 Security Lake 源中的新数据。 + `kms` – 允许主体向 Security Lake 授予使用客户托管密钥写入数据的访问权限。 + `secretsmanager` – 允许主体管理用于在新数据通过 HTTPS 端点写入 Security Lake 来源时通知订阅用户的密钥。 要查看此策略的权限，请参阅《AWS 托管式策略参考》**中的 [AmazonSecurityLakeAdministrator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSecurityLakeAdministrator.html)。 ## AWS 托管策略： SecurityLakeServiceLinkedRole Security Lake 使用名为`AWSServiceRoleForSecurityLake`的服务相关角色来创建和操作安全数据湖。 您不能将 `SecurityLakeServiceLinkedRole` 托管式策略附加到您的 IAM 实体。此策略附加到服务相关角色，允许 Security Lake 代表您执行操作。有关更多信息，请参阅 [Security Lake 的服务相关角色权限](https://docs.aws.amazon.com//security-lake/latest/userguide/slr-permissions.html)。 ## AWS 托管策略： SecurityLakeResourceManagementServiceRolePolicy Security Lake 使用名为的服务关联角色`AWSServiceRoleForSecurityLakeResourceManagement`来执行持续监控和性能改进，从而减少延迟和成本。提供管理由 Security Lake 创建的资源的权限。让 Security Lake 能够删除 SecurityLake \$1Glue\$1Partition\$1Updater\$1Lambda。对于已执行冰山迁移并转向 v2 源代码的客户，此 lambda 已被弃用。这个 lambda 使用的是 Python 3.9 运行时，该运行时将于 12 月被弃用。与其为这些客户更新此 lambda 的运行时，不如将其删除。我们有一个恢复流程，可以确定客户是否还需要 lambda，如果他们不需要，则将其删除。为了允许我们删除那个 lambda，需要进行这个 SLR 更新。 您不能将 `SecurityLakeResourceManagementServiceRolePolicy` 托管式策略附加到您的 IAM 实体。此策略附加到服务相关角色，允许 Security Lake 代表您执行操作。有关更多信息，请参阅[资源管理的服务关联角色权限](https://docs.aws.amazon.com//security-lake/latest/userguide/AWSServiceRoleForSecurityLakeResourceManagement.html)。 **权限详细信息** 该策略包含以下权限。 + `events`— 允许委托人列出和管理 Security Lake 事件处理 EventBridge 规则。 + `lambda`— 允许委托人管理 Security Lake 元数据处理的 Lambda 函数和配置，包括能够删除已弃用的分区更新程序函数。 + `glue`— 允许委托人在 Security Lake 元数据管理 AWS Glue 的数据目录中创建分区、管理表和访问数据库。 + `s3`— 允许委托人管理安全湖数据湖操作的 Amazon S3 存储桶配置、生命周期策略和元数据对象。 + `logs`— 允许委托人访问 CloudWatch 日志流并查询 Security Lake Lambda 函数的日志数据。 + `sqs`— 允许委托人管理 Security Lake 数据处理工作流程的 Amazon SQS 队列和消息。 + `lakeformation`— 允许委托人检索数据湖设置和 Security Lake 资源管理权限。 要查看有关策略（包括 JSON 策略文档的最新版本）的更多信息，请参阅《AWS 托管式策略参考指南》**中的 [SecurityLakeResourceManagementServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityLakeResourceManagementServiceRolePolicy.html)。 ## AWS 托管策略： AWS GlueServiceRole `AWS GlueServiceRole`托管策略调用 AWS Glue 爬虫并允许 AWS Glue 抓取自定义源数据和识别分区元数据。在数据目录中创建和更新表需要这些元数据。 有关更多信息，请参阅 [从 Security Lake 中的自定义来源收集数据](custom-sources.md)。 ## 安全湖对 AWS 托管策略的更新 查看自该服务开始跟踪这些更改以来 Security Lake AWS 托管策略更新的详细信息。有关此页面更改的自动提示，请订阅“Security Lake 文档”历史记录页面上的 RSS 源。 | 更改 | 描述 | 日期 | | --- | --- | --- | | [SecurityLakeResourceManagementServiceRolePolicy](#security-iam-awsmanpol-SecurityLakeServiceLinkedRole-ResourceManagement)— 更新了现有政策 | Security Lake 更新了托管策略`SecurityLakeResourceManagementServiceRolePolicy`，为已弃用的 SecurityLake \$1Glue\$1Partition\$1Updater\$1Lambda 函数添加了`lambda:DeleteFunction`权限。这允许 Security Lake 在迁移到 v2 源代码和冰山格式的过程中清理已弃用的 Lambda 函数。 | 2025 年 11 月 18 日 | | [AWSServiceRoleForSecurityLakeResourceManagement](AWSServiceRoleForSecurityLakeResourceManagement.md)— 更新了现有政策 | 此政策已更新，将`StringLike`运算符替换为`ArnLike`运算符，以评估`aws:ResourceAccount`条件块`lambda:FunctionArn`中的 ARN 类型密钥。这可确保策略执行更加安全。 | 2025 年 9 月 25 日 | | [Amazon Security Lake 的服务相关角色](AWSServiceRoleForSecurityLakeResourceManagement.md) — 新的服务相关角色 | 我们添加了一个新的服务相关角色`AWSServiceRoleForSecurityLakeResourceManagement`。此服务相关角色向 Security Lake 提供执行持续监控和性能改进的权限，从而减少延迟和成本。 | 2024 年 11 月 14 日 | | [Amazon Security Lake 的服务相关角色](using-service-linked-roles.md) — 更新现有服务相关角色权限 | 我们在该策略的 AWS 托管策略中添加了 AWS WAF `SecurityLakeServiceLinkedRole`操作。在 Security Lake 中启用为 AWS WAF 日志源时，其他操作允许 Security Lake 收集日志。 | 2024 年 5 月 22 日 | | [AmazonSecurityLakePermissionsBoundary](#security-iam-awsmanpol-AmazonSecurityLakePermissionsBoundary)：对现有策略的更新 | Security Lake 在策略中添加了 SID 操作。 | 2024 年 5 月 13 日 | | [AmazonSecurityLakeMetastoreManager](#security-iam-awsmanpol-AmazonSecurityLakeMetastoreManager)：对现有策略的更新 | Security Lake 更新了政策，添加了元数据清理操作，允许您删除数据湖中的元数据。 | 2024 年 3 月 27 日 | | [AmazonSecurityLakeAdministrator](#security-iam-awsmanpol-AmazonSecurityLakeAdministrator)：对现有策略的更新 | Security Lake 更新了政策，允许使用`iam:PassRole`新`AmazonSecurityLakeMetastoreManagerV2`角色，并允许 Security Lake 部署或更新数据湖组件。 | 2024 年 2 月 23 日 | | [AmazonSecurityLakeMetastoreManager](#security-iam-awsmanpol-AmazonSecurityLakeMetastoreManager)：新策略 | Security Lake 添加了一个新的托管策略，该策略向 Security Lake 授予管理数据湖中元数据的权限。 | 2024 年 1 月 23 日 | | [AmazonSecurityLakeAdministrator](#security-iam-awsmanpol-AmazonSecurityLakeAdministrator)：新策略 | Security Lake 添加了一项新的托管策略，允许委托人完全访问所有 Security Lake 操作。 | 2023 年 5 月 30 日 | | Security Lake 开始跟踪更改 | Security Lake 开始跟踪其 AWS 托管策略的更改。 | 2022 年 11 月 29 日 | # 在 Security Lake 中使用服务相关角色 Security Lake 使用 AWS Identity and Access Management (IAM) [服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)。服务相关角色是直接关联到 Security Lake 的 IAM 角色。这一角色由 Security Lake 预定义，包含 Security Lake 为您调用其他 AWS 服务 并运行安全数据胡服务所需的所有权限。Security Lake 在所有可用 Security Lake AWS 区域 的地方都使用此服务相关角色。 利用服务相关角色，您在设置 Security Lake 时不需要手动添加必要的权限。Security Lake 会定义这一服务相关角色的权限，而且除非另有定义，否则只有 Security Lake 可以担任该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务关联角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务关联角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。只有在删除服务相关角色的相关资源后，您才能删除该角色。这可以保护您的资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其他服务的信息，请参阅与 [IAM 配合使用的AWS 服务，](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)并在**服务相关角色**列中查找标有 “**是**” 的服务。选择带有链接的**是**可以查看该服务的服务相关角色文档。 **Topics** + [Security Lake 的服务关联角色 (SLR) 权限](slr-permissions.md) + [用于资源管理的服务关联角色 (SLR) 权限](AWSServiceRoleForSecurityLakeResourceManagement.md) # Security Lake 的服务关联角色 (SLR) 权限 Security Lake 使用名为 `AWSServiceRoleForSecurityLake` 的服务相关角色。该服务相关角色信任 `securitylake.amazonaws.com` 服务担任该角色。有关 Amazon Security Lake AWS 托管[策略的更多信息，请参阅AWS 管理亚马逊安全湖的](https://docs.aws.amazon.com//security-lake/latest/userguide/security-iam-awsmanpol.html)策略。 该角色的权限策略是一个名为的 AWS 托管策略`SecurityLakeServiceLinkedRole`，允许 Security Lake 创建和操作安全数据湖。该策略还允许 Security Lake 对指定资源执行以下操作： + 使用 AWS Organizations 操作检索关联账户的相关信息 + 使用 Amazon Elastic Compute Cloud (Amazon EC2) 检索有关 Amazon VPC 流日志的信息 + 使用 AWS CloudTrail 操作检索有关服务相关角色的信息 + 在 Security AWS WAF Lake 中启用日志作为日志源后，使用 AWS WAF 操作收集日志 + 使用`LogDelivery`操作创建或删除 AWS WAF 日志传输订阅。 要查看此策略的权限，请参阅《AWS 托管式策略参考》**中的 [SecurityLakeServiceLinkedRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityLakeServiceLinkedRole.html)。 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务关联角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务关联角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 创建 Security Lake 服务相关角色 您不需要为 Security Lake 手动创建 `AWSServiceRoleForSecurityLake` 服务相关角色。当您为自己启用 Security Lake 时 AWS 账户，Security Lake 会自动为您创建服务相关角色。 ## 创建 Security Lake 服务相关角色 Security Lake 不允许您编辑 `AWSServiceRoleForSecurityLake` 服务相关角色。在创建服务相关角色后，您无法更改角色的名称，因为可能有多个实体会引用该角色。不过，您可以使用 IAM 编辑角色的说明。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除 Security Lake 服务相关角色 您无法从 Security Lake 中删除服务相关角色。相反，您可以从 IAM 控制台、API 或 AWS CLI中删除服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 您必须先确认服务相关角色没有活动会话并删除 `AWSServiceRoleForSecurityLake` 使用的任何资源，然后才能删除服务相关角色。 **注意** 在您尝试删除资源时，如果 Security Lake 正在使用 `AWSServiceRoleForSecurityLake` 角色，删除可能会失败。如果发生这种情况，请等待几分钟，然后再次尝试操作。 如果您在删除 `AWSServiceRoleForSecurityLake` 服务相关角色后需要再次创建该角色，可以通过为账户启用 Security Lake 来再次创建角色。当您再次启用 Security Lake 时，Security Lake 会再次自动为您创建服务相关角色。 ## 支持 AWS 区域 Security Lake 服务关联角色 Security Lake 支持在所有可用 Security Lake AWS 区域 的地方使用`AWSServiceRoleForSecurityLake`服务相关角色。有关提供 Security Lake 的区域的列表，请参阅 [安全湖区域和终端节点](supported-regions.md)。 # 用于资源管理的服务关联角色 (SLR) 权限 Security Lake 使用名为的服务关联角色`AWSServiceRoleForSecurityLakeResourceManagement`来执行持续监控和性能改进，从而减少延迟和成本。该服务相关角色信任 `resource-management.securitylake.amazonaws.com` 服务担任该角色。启用`AWSServiceRoleForSecurityLakeResourceManagement`后还将授予其访问 Lake Formation 的权限，并自动在所有区域向 Lake Formation 注册您的 Security Lake 托管的 S3 存储桶，以提高安全性。 该角色的权限策略是一个名为的 AWS 托管策略`SecurityLakeResourceManagementServiceRolePolicy`，允许访问管理由 Security Lake 创建的资源，包括管理数据湖中的元数据。有关亚马逊安全湖 AWS 托管策略的更多信息，请参阅[亚马逊安全湖AWS 托管策略](https://docs.aws.amazon.com//security-lake/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-SecurityLakeServiceLinkedRole-ResourceManagement.html)。 此服务相关角色允许 Security Lake 监控安全湖部署到您的账户的资源（S3 存储桶、 AWS Glue 表、Amazon SQS 队列、Metastore Manager (MSM) Lambda 函数和规则）的运行状况。 EventBridge Security Lake 可使用此服务相关角色执行的一些操作示例如下： + Apache Iceberg 清单文件压缩，可提高查询性能并降低 Lambda MSM 处理时间和成本。 + 监控 Amazon SQS 的状态以检测摄取问题。 + 优化跨区域数据复制以排除元数据文件。 **注意** 如果您不安装`AWSServiceRoleForSecurityLakeResourceManagement`服务相关角色，Security Lake 将继续运行，但强烈建议您接受此服务相关角色，以便 Security Lake 可以监控和优化您账户中的资源。 **权限详细信息** 该角色使用以下权限策略进行配置： + `events`— 允许委托人管理日志源和日志订阅者所需的 EventBridge 规则。 + `lambda`— 允许委托人管理用于在 AWS 源数据传输和跨区域复制之后更新 AWS Glue 表分区的 lambda。 + `glue`— 允许委托人对 AWS Glue 数据目录表执行特定的写入操作。这还允许 AWS Glue 抓取工具识别数据中的分区，并允许 Security Lake 管理你的 Apache Iceberg 表的 Apache Iceberg 元数据。 + `s3`— 允许委托人对包含日志数据和 Glue 表元数据的 Security Lake 存储桶执行特定的读写操作。 + `logs`— 允许委托人读取权限将 Lambda 函数 CloudWatch 的输出记录到日志中。 + `sqs`— 允许委托人对在数据湖中添加或更新对象时接收事件通知的 Amazon SQS 队列执行特定的读写操作。 + `lakeformation`— 允许校长读取 Lake Formation 设置以监控配置错误。 要查看此策略的权限，请参阅《AWS 托管式策略参考》**中的 [SecurityLakeResourceManagementServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityLakeResourceManagementServiceRolePolicy.html)。 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务关联角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务关联角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 创建 Security Lake 服务相关角色 您可以使用 Security Lake 控制台或 Security Lake 创建`AWSServiceRoleForSecurityLakeResourceManagement`服务相关角色。 AWS CLI 要创建服务相关角色，您必须向您的 IAM 用户或 IAM 角色授予以下权限。在所有启用安全湖的区域中，IAM 角色必须是 Lake Formation 管理员。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowLakeFormationActionsViaSecurityLakeConsole", "Effect": "Allow", "Action": [ "lakeformation:GrantPermissions", "lakeformation:ListPermissions", "lakeformation:ListResources", "lakeformation:RegisterResource", "lakeformation:RevokePermissions" ], "Resource": "*" }, { "Sid": "AllowIamActionsViaSecurityLakeConsole", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:GetPolicyVersion", "iam:GetRole", "iam:PutRolePolicy" ], "Resource": [ "arn:*:iam::*:role/aws-service-role/resource-management.securitylake.amazonaws.com/AWSServiceRoleForSecurityLakeResourceManagement", "arn:*:iam::*:role/*AWSServiceRoleForLakeFormationDataAccess", "arn:*:iam::aws:policy/service-role/AWSGlueServiceRole", "arn:*:iam::aws:policy/service-role/AmazonSecurityLakeMetastoreManager", "arn:*:iam::aws:policy/aws-service-role/SecurityLakeResourceManagementServiceRolePolicy" ], "Condition": { "StringLikeIfExists": { "iam:AWSServiceName": [ "securitylake.amazonaws.com", "resource-management.securitylake.amazonaws.com", "lakeformation.amazonaws.com" ] } } }, { "Sid": "AllowGlueActionsViaConsole", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetTables" ], "Resource": [ "arn:*:glue:*:*:catalog", "arn:*:glue:*:*:database/amazon_security_lake_glue_db*", "arn:*:glue:*:*:table/amazon_security_lake_glue_db*/*" ] } ] } ``` ------ ------ #### [ Console ] 1. 在上打开 Security Lake 控制台[https://console.aws.amazon.com/securitylake/](https://console.aws.amazon.com/securitylake/)。 1. 单击 “摘要” 页面信息栏中的 “**启用服务相关角色**”，接受新的服务相关角色。 启用服务相关角色后，将来使用 Security Lake 时无需重复此过程。 ------ #### [ CLI ] 要以编程方式创建`AWSServiceRoleForSecurityLakeResourceManagement`服务相关角色，请使用以下 CLI 命令。 ``` $ aws iam create-service-linked-role --aws-service-name resource-management.securitylake.amazonaws.com ``` 使用创建`AWSServiceRoleForSecurityLakeResourceManagement`服务相关角色时 AWS CLI，您还必须向其授予 Security Lake Glue 数据库上所有表的 Lake Formation 表级权限（ALTER、DESCRIBE），以管理表元数据和访问数据。如果任何区域中的 Glue 表引用了之前启用安全湖的 S3 存储桶，则必须暂时授予服务相关角色的 DATA\$1LOCATION\$1ACCESS 权限，以允许 Security Lake 纠正这种情况。 您还必须向账户的`AWSServiceRoleForSecurityLakeResourceManagement`服务相关角色授予 Lake Formation 权限。 以下示例说明如何向指定区域中的服务相关角色授予 Lake Formation 权限。此示例是针对 Linux、macOS 或 Unix 进行格式化的，它使用反斜杠（\$1）行继续符来提高可读性。 ``` $ aws lakeformation grant-permissions --region {region} --principal DataLakePrincipalIdentifier={AWSServiceRoleForSecurityLakeResourceManagement ARN} \ --permissions ALTER DESCRIBE --resource '{ "Table": { "DatabaseName": "amazon_security_lake_glue_db_{region}", "TableWildcard": {} } }' ``` 以下示例显示了角色 ARN 的外观。您必须编辑角色 ARN 以匹配您的区域。 `"AWS": "arn:[partition]:iam::[accountid]:role/aws-service-role/resource-management.securitylake.amazonaws.com/AWSServiceRoleForSecurityLakeResourceManagement"` 您也可以使用 [CreateServiceLinkedRole](https://docs.aws.amazon.com//IAM/latest/APIReference/API_CreateServiceLinkedRole.html)API 调用。在请求中，指定 a `AWSServiceName` s `resource-management.securitylake.amazonaws.com`。 ------ 启用该`AWSServiceRoleForSecurityLakeResourceManagement`角色后，如果您使用 AWS KMS 客户托管密钥 (CMK) 进行加密，则必须允许服务相关角色将加密对象写入存在 CMK 的 AWS 区域中的 S3 存储桶。在 AWS KMS 控制台中，将以下策略添加到 CMK 存在的 AWS 区域中的 KMS 密钥。有关如何更改 KMS 密钥策略的详细信息，请参阅《 AWS Key Management Service 开发人员指南》[AWS KMS中的密钥策略](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html)。 ``` { "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:::[regional-datalake-s3-bucket-name]" }, "StringLike": { "kms:ViaService": "s3.[region].amazonaws.com" } } }, ``` ## 创建 Security Lake 服务相关角色 Security Lake 不允许您编辑 `AWSServiceRoleForSecurityLakeResourceManagement` 服务相关角色。在创建服务相关角色后，您无法更改角色的名称，因为可能有多个实体会引用该角色。不过，您可以使用 IAM 编辑角色的说明。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除 Security Lake 服务相关角色 您无法从 Security Lake 中删除服务相关角色。相反，您可以从 IAM 控制台、API 或 AWS CLI中删除服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 您必须先确认服务相关角色没有活动会话并删除 `AWSServiceRoleForSecurityLakeResourceManagement` 使用的任何资源，然后才能删除服务相关角色。 **注意** 在您尝试删除资源时，如果 Security Lake 正在使用 `AWSServiceRoleForSecurityLakeResourceManagement` 角色，删除可能会失败。如果发生这种情况，请等待几分钟，然后再次尝试操作。 如果您在删除 `AWSServiceRoleForSecurityLakeResourceManagement` 服务相关角色后需要再次创建该角色，可以通过为账户启用 Security Lake 来再次创建角色。当您再次启用 Security Lake 时，Security Lake 会再次自动为您创建服务相关角色。 ## 支持 AWS 区域 Security Lake 服务关联角色 Security Lake 支持在所有可用 Security Lake AWS 区域 的地方使用`AWSServiceRoleForSecurityLakeResourceManagement`服务相关角色。有关提供 Security Lake 的区域的列表，请参阅 [安全湖区域和终端节点](supported-regions.md)。 # Amazon Security Sake 中的数据保护 分 AWS [担责任模式](https://aws.amazon.com/compliance/shared-responsibility-model/)适用于亚马逊安全湖中的数据保护。如本模型所述 AWS ，负责保护运行所有内容的全球基础架构 AWS 云。您负责维护对托管在此基础结构上的内容的控制。您还负责您所使用的 AWS 服务 的安全配置和管理任务。有关数据隐私的更多信息，请参阅[数据隐私常见问题](https://aws.amazon.com/compliance/data-privacy-faq/)。有关欧洲数据保护的信息，请参阅 *AWS Security Blog* 上的 [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-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。有关使用 CloudTrail 跟踪捕获 AWS 活动的信息，请参阅《*AWS CloudTrail 用户指南》*中的[使用跟 CloudTrail 踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)。 + 使用 AWS 加密解决方案以及其中的所有默认安全控件 AWS 服务。 + 使用高级托管安全服务（例如 Amazon Macie），它有助于发现和保护存储在 Amazon S3 中的敏感数据。 + 如果您在 AWS 通过命令行界面或 API 进行访问时需要经过 FIPS 140-3 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅[《美国联邦信息处理标准（FIPS）第 140-3 版》](https://aws.amazon.com/compliance/fips/)。 强烈建议您切勿将机密信息或敏感信息（如您客户的电子邮件地址）放入标签或自由格式文本字段（如**名称**字段）。这包括您 AWS 服务 使用控制台、API 或与 Security Lake 或其他人合作时 AWS SDKs。 AWS CLI在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供网址，强烈建议您不要在网址中包含凭证信息来验证对该服务器的请求。 ## 静态加密 Amazon Security Lake 使用 AWS 加密解决方案安全地存储您的静态数据。原始安全日志和事件数据存储在特定于源的多[租户亚马逊简单存储服务 (Amazon S3) Simple Storage S3 存储](https://docs.aws.amazon.com/AmazonS3/latest/userguide/common-bucket-patterns.html#multi-tenant-buckets)桶中，该存储桶由安全湖管理的账户。每个日志源都有自己的多租户存储桶。Security Lake 使用来自 AWS Key Management Service (AWS KMS) 的[AWS 自有密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)对这些原始数据进行加密。 AWS 拥有的密钥是 AWS 服务（在本例中为 Securit AWS KMS y Lake）拥有和管理的密钥集合，供多个账户使用。 AWS Security Lake 对原始日志和事件数据运行提取、转换和加载（ETL）任务。 ETL 任务完成后，Security Lake 会在您的账户中创建单租户 S3 存储桶（您在其中启用 Security Lake AWS 区域 的每个存储桶对应一个存储桶）。只有在 Security Lake 能够可靠地将数据传送到单租户 S3 存储分段之前，数据才会暂时存储在多租户 S3 存储桶中。单租户桶包含一个基于资源的策略，该策略授予 Security Lake 向桶写入日志和事件数据的权限。要加密 S3 存储桶中的数据，您可以选择 [S3 托管的加密密钥或客户托管](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)[的密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)（来自 AWS KMS）。两者都使用对称加密。 ### 使用 KMS 密钥加密您的数据 默认情况下，Security Lake 传输到 S3 存储桶的数据使用 [Amazon S3 托管的加密密钥（SSE-S3）](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)进行 Amazon 服务器端加密。要提供您可以直接管理的安全层，您可以改为使用[带有 AWS KMS 密钥的服务器端加密 (SSE-KMS) 来处理您的 Sec](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) urity Lake 数据。 Security Lake 控制台不支持 SSE-KMS。要将 SSE-KMS 用于 Security Lake API 或 CLI，请先[创建 KMS 密钥](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)或使用现有密钥。您需要向密钥附加一个策略，规定哪些用户可以使用该密钥加密和解密 Security Lake 数据。 如果使用客户托管密钥来加密写入到 S3 存储桶的数据，则无法选择多区域密钥。对于客户托管密钥，Security Lake 将通过向 AWS KMS发送 `CreateGrant` 请求来代表您创建[授权](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)。中的授权 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 订阅用户的数据访问权限](subscriber-data-access.md)。 如果要使用现有的 KMS 密钥来加密 Security Lake 数据，则必须修改 KMS 密钥的密钥策略。密钥策略必须允许与 Lake Formation 数据湖位置关联的 IAM 角色使用 KMS 密钥解密数据。有关如何更改 KMS 密钥的密钥策略的说明，请参阅 AWS Key Management Service 开发人员指南中的[更改密钥策略](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying.html)。 创建密钥策略或使用具有适当权限的现有密钥策略时，您的 KMS 密钥可以接受授权请求，从而允许 Security Lake 访问该密钥。有关创建密钥策略的说明，请参阅《AWS Key Management Service 开发人员指南》**中的[创建密钥策略](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html)。 将以下密钥策略附加到您的 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 角色的概述，请参阅[入门：先决条件](get-started-programmatic.md#prerequisites)部分。 添加自定义源或订阅用户时，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 队列](https://repost.aws/knowledge-center/sqs-s3-event-notification-sse)？ 在 AWS 知识中心中。 由于 Security Lake 用于支持 AWS Lambda 对您的数据进行提取、传输和加载 (ETL) 任务，因此您还必须向 Lambda 授予管理您的 Amazon SQS 队列中消息的权限。有关信息，请参阅《AWS Lambda 开发人员指南》**中的[执行角色权限](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-permissions)。 ## 传输中加密 Security Lake 对 AWS 服务之间传输的所有数据进行加密。通过使用传输层安全（TLS）1.2 加密协议自动加密所有网络间数据，Security Lake 在传输中数据进出服务时对其进行保护。发送到安全湖 APIs 的直接 HTTPS 请求使用[AWS 签名版本 4 算法](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)进行签名，以建立安全连接。 # 选择不使用您的数据来改进服务 您可以使用选择退出政策，选择不将您的数据用于开发和改进 Security Lake 和其他 AWS 安全服务。 AWS Organizations 即使 Security Lake 目前未收集任何此类数据，您也可以选择退出。有关如何选择退出的更多信息，请参阅《AWS Organizations 用户指南》**中的 [AI 服务选择退出政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html)。 目前，Security Lake 不会收集它代表您处理的任何安全数据，也不会收集您上传到由此服务创建的安全数据湖的安全数据。为了开发和改进 Security Lake 服务和其他 AWS 安全服务的功能，Security Lake 将来可能会收集此类数据，包括您从第三方数据源上传的数据。我们将在 Security Lake 打算收集任何此类数据时更新本页面，并说明其工作方式。您仍有机会随时选择退出。 **注意** 要使用选择退出政策，您的 AWS 账户必须由集中管理。 AWS Organizations如果您尚未为自己的 AWS 账户创建组织，请参阅*《AWS Organizations 用户指南》*中的[创建和管理组织](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html)。 选择退出会带来以下影响： + Security Lake 将删除在您选择退出之前它收集和存储的数据（如果有）。 + 在您选择退出后，Security Lake 不会再收集或存储这些数据。 # Amazon Security Lake 的合规性验证 要了解是否属于特定合规计划的范围，请参阅AWS 服务 “[按合规计划划分的范围](https://aws.amazon.com/compliance/services-in-scope/)” ”，然后选择您感兴趣的合规计划。 AWS 服务 有关一般信息，请参阅[AWS 合规计划AWS](https://aws.amazon.com/compliance/programs/)。 您可以使用下载第三方审计报告 AWS Artifact。有关更多信息，请参阅中的 “[下载报告” 中的 “ AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。 您在使用 AWS 服务 时的合规责任取决于您的数据的敏感性、贵公司的合规目标以及适用的法律和法规。有关您在使用时的合规责任的更多信息 AWS 服务，请参阅[AWS 安全文档](https://docs.aws.amazon.com/security/)。 # Security Lake 的安全最佳实践 请参阅以下有关使用 Amazon Security Lake 的最佳实践。 ## 授予 Security Lake 用户可能的最低权限 遵循最低权限原则，为您的 AWS Identity and Access Management (IAM) 用户、用户组和角色授予最低访问策略权限。例如，您可以允许 IAM 用户查看 Security Lake 中的日志源列表，但不允许其创建日志源或订阅用户。有关更多信息，请参阅 [Security Lake 基于身份的策略示例](security_iam_id-based-policy-examples.md)。 您还可以使用 AWS CloudTrail 来跟踪 Security Lake 中的 API 使用情况。 CloudTrail 提供用户、群组或角色在 Security Lake 中执行的 API 操作的记录。有关更多信息，请参阅 [使用记录安全湖 API 调用 CloudTrail](securitylake-cloudtrail.md)。 ## 查看摘要页面 Security Lake 控制台的**摘要**页面概述了过去 14 天内影响 Security Lake 服务和用于存储数据的 Amazon S3 存储桶的问题。您可以进一步调查这些问题，以帮助您减轻可能与安全相关的影响。 ## 与 Security Hub CSPM 集成 集成 Security Lake 并在 AWS Security Hub CSPM 安全湖中接收 Security Hub CSPM 调查结果。Security Hub CSPM 从许多不同的 AWS 服务 第三方集成中生成调查结果。接收 Security Hub CSPM 调查结果有助于你大致了解自己的合规状况以及是否符合 AWS 安全最佳实践。 有关更多信息，请参阅 [与集成 AWS Security Hub CSPM](securityhub-integration.md)。 ## 删除 AWS Lambda 删除 AWS Lambda 函数时，我们建议不要先将其禁用。在删除之前禁用 Lambda 函数可能会干扰数据查询功能，并可能影响其他功能。最好直接删除 Lambda 函数而不将其禁用。有关删除 Lambda 函数的更多信息，请参阅[AWS Lambda 开发者](https://docs.aws.amazon.com//lambda/latest/dg/example_lambda_DeleteFunction_section.html)指南。 ## 监控 Security Lake 事件 您可以使用 Amazon CloudWatch 指标监控安全湖。 CloudWatch 每分钟从 Security Lake 收集原始数据并将其处理为指标。您可以设置警报，在指标达到指定阈值时触发通知。 有关更多信息，请参阅 [CloudWatch 亚马逊安全湖的指标](cloudwatch-metrics.md)。 # Amazon Security Lake 中的故障恢复能力 AWS 全球基础设施是围绕 AWS 区域 可用区构建的。 AWS 区域 提供多个物理隔离和隔离的可用区，这些可用区通过低延迟、高吞吐量和高度冗余的网络连接。这些可用区为您提供了高效的方法来设计和操作应用程序和数据库。与传统的单个或多个数据中心基础结构相比，可用区具有更高的可用性、容错性和可扩展性。 Security Lake 的可用性与区域可用性息息相关。分布在多个可用区有助于该服务在任意一个可用区发生故障时依旧保持可用性。 Security Lake 数据面板的可用性与区域可用性无关。但是，Security Lake 控制面板的可用性与美国东部（弗吉尼亚州北部）区域的可用性密切相关。 有关 AWS 区域 和可用区的更多信息，请参阅[AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)。 除了 AWS 全球基础设施外，Security Lake（其中的数据由亚马逊简单存储服务 (Amazon S3) Service 提供支持）还提供多项功能来帮助支持您的数据弹性和备份需求。 **生命周期配置** 生命周期配置是一组规则，用于定义 Amazon S3 对一组对象应用的操作。利用生命周期配置规则，您可以指示 Amazon S3 将对象转换为较低成本的存储类，或者归档或删除它们。有关更多信息，请参阅《Amazon S3 用户指南》**中的[对象生命周期管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)。 **版本控制** 版本控制是在相同的存储桶中保留对象的多个变量的方法。对于 Amazon S3 存储桶中存储的每个对象，您可以使用版本控制功能来保存、检索和还原它们的各个版本。版本控制功能可帮助您从用户意外操作和应用程序故障中恢复。有关更多信息，请参阅《Amazon S3 用户指南》**中的[在 S3 存储桶中使用版本控制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)。 **存储类** Amazon S3 提供一系列存储类，可供选择，具体取决于您的工作负载要求。S3 Standard-IA 和 S3 One Zone-IA 存储类用于大约每月访问一次且需要毫秒访问的数据。S3 Glacier Instant Retrieval 存储类专为长期归档数据而设计，您可以访问几毫秒的访问权限，大约每季度访问一次。对于不需要立即访问的归档数据，例如备份，您可以使用 S3 Glacier Flexible Retrieval 或 S3 Glacier Deep Archive 存储类。有关更多信息，请参阅《Amazon S3 用户指南》**中的[使用 Amazon S3 存储类](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)。 # Amazon Security Lake 中的基础设施安全性 作为一项托管服务，Amazon Security Lake 受 AWS 全球网络安全的保护。有关 AWS 安全服务以及如何 AWS 保护基础设施的信息，请参阅[AWS 云安全](https://aws.amazon.com/security/)。要使用基础设施安全的最佳实践来设计您的 AWS 环境，请参阅 S * AWS ecurity Pillar Well-Architected Fram* ework 中的[基础设施保护](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。 您可以使用 AWS 已发布的 API 调用通过网络访问安全湖。客户端必须支持以下内容： + 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。 # Security Lake 中的配置和脆弱性分析 配置和 IT 控制由您（我们的客户）共同 AWS 负责。有关更多信息，请参阅[责任 AWS 共担模型](https://aws.amazon.com/compliance/shared-responsibility-model/)。 # Amazon 安全湖和接口 VPC 终端节点 (AWS PrivateLink) 您可以通过创建接*口 VPC 终端节点在您的 VPC 和 Amazon Security Lake 之间建立私有*连接。接口端点由一项技术提供支持 [AWS PrivateLink](https://aws.amazon.com/privatelink)，该技术使您 APIs 无需互联网网关、NAT 设备、VPN 连接或 Di AWS rect Connect 连接即可私密访问 Security Lake。您的 VPC 中的实例不需要公有 IP 地址即可与安全湖通信 APIs。您的 VPC 和安全湖之间的流量不会离开亚马逊网络。 每个接口端点均由子网中的一个或多个[弹性网络接口](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)表示。 有关更多信息，请参阅 *AWS PrivateLink 指南*中的[接口 VPC 端点 (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html)。 ## 安全湖 VPC 终端节点的注意事项 在为 Security Lake 设置接口 VPC 终端节点之前，请[务必查看*AWS PrivateLink 指南*中的接口终端节点属性和限制](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations)。 Security Lake 支持从您的 VPC 调用其所有 API 操作。 Security Lake 仅在以下存在 FIPS 的区域支持 FIPS VPC 终端节点： + 美国东部（弗吉尼亚州北部） + 美国东部（俄亥俄州） + 美国西部（北加利福尼亚） + 美国西部（俄勒冈州） ## 为安全湖创建接口 VPC 终端节点 您可以使用 Amazon VPC 控制台或 AWS Command Line Interface (AWS CLI) 为安全湖服务创建 VPC 终端节点。有关更多信息，请参阅《AWS PrivateLink 指南》**中的[创建接口端点](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint)。 使用以下服务名称为安全湖创建 VPC 终端节点： + com.amazonaws。 *region*. securityL + com.amazonaws。 *region*.securitylake-fips（FIPS 端点） 例如，如果您为终端节点启用私有 DNS，则可以使用该区域的默认 DNS 名称向 Security Lake 发出 API 请求`securitylake.us-east-1.amazonaws.com`。 有关更多信息，请参阅 *AWS PrivateLink 指南*中的[通过接口端点访问服务](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint)。 ## 为安全湖创建 VPC 终端节点策略 您可以将终端节点策略附加到控制安全湖访问权限的 VPC 终端节点。该策略指定以下信息： + 可执行操作的主体。 + 可执行的操作。 + 可对其执行操作的资源。 有关更多信息，请参阅 *AWS PrivateLink 指南*中的[使用 VPC 端点控制对服务的访问](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)。 **示例：安全湖操作的 VPC 终端节点策略** 以下是 Security Lake 的终端节点策略示例。当连接到终端节点时，此策略向所有资源的所有委托人授予访问列出的 Security Lake 操作的权限。 ``` { "Statement":[ { "Principal":"*", "Effect":"Allow", "Action":[ "securitylake:ListDataLakes", "securitylake:ListLogSources", "securitylake:ListSubscribers" ], "Resource":"*" } ] } ``` ## 共享子网 您无法在与您共享的子网中创建、描述、修改或删除 VPC 端点。但是，您可以在与您共享的子网中使用 VPC 端点。有关 VPC 共享的信息，请参阅《*Amazon VPC 用户指南*》中的[与其他账户共享 VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)。 # 监控 Amazon Security Lake Security Lake 与 AWS CloudTrail集成，后者是一项服务，用于记录用户、角色或其他角色在 Security Lake 中执行的操作 AWS 服务。这包括来自 Security Lake 控制台的操作以及对 Security Lake API 操作的编程调用。通过使用收集的信息 CloudTrail，您可以确定向 Security Lake 提出了哪些请求。对每一个请求，您可以识别请求的时间、发出请求的源 IP 地址以及其他详细信息。有关更多信息，请参阅 [使用记录安全湖 API 调用 CloudTrail](securitylake-cloudtrail.md)。 Security Lake 和 Amazon CloudWatch 是集成的，因此您可以收集、查看和分析 Security Lake 收集的日志的指标。 CloudWatch 系统会自动收集 Security Lake 数据湖的指标，并每隔 CloudWatch 一分钟推送一次。您还可以设置警报，以便在达到某个 Security Lake 指标的指定阈值时向您发送通知。有关 Security Lake 发送到的所有指标的列表 CloudWatch，请参阅[Security Lake 指标和维度](cloudwatch-metrics.md#available-securitylake-metrics)。 # CloudWatch 亚马逊安全湖的指标 您可以使用 Amazon 监控 Security Lake CloudWatch，亚马逊每分钟收集一次原始数据，并将其处理成可读的近乎实时的指标。这些统计数据会保存 15 个月，使您能够访问历史信息并更好地了解数据湖中的数据。还可以设置特定阈值监视警报，在达到对应阈值时发送通知或采取行动。 **Topics** + [Security Lake 指标和维度](#available-securitylake-metrics) + [查看安全湖的 CloudWatch 指标](#view-securitylake-metrics) + [为安全湖指标设置 CloudWatch 警报](#securitylake-alarm-metrics) ## Security Lake 指标和维度 `AWS/SecurityLake` 命名空间包括以下指标。 | 指标 | 说明 | | --- | --- | | `ProcessedSize` | 当前存储在您的数据湖中的来自原生支持 AWS 服务 的数据量。 单位：字节 | 下列维度可用于 Security Lake 指标。 | 维度 | 说明 | | --- | --- | | `Account` | 特定 AWS 账户的 `ProcessedSize` 指标。此维度仅在您查看开启时可用 CloudWatch。`Per-Account Source Version Metrics` | | `Region` | 特定 AWS 区域的 `ProcessedSize` 指标。 | | `Source` | `ProcessedSize`特定 AWS 日志源的指标。 | | `SourceVersion` | `ProcessedSize` AWS 日志源特定版本的指标。 | 您可以查看组织中特定账户 AWS 账户 (`Per-Account Source Version Metrics`) 或所有账户 (`Per-Source Version Metrics`) 的指标。 ## 查看安全湖的 CloudWatch 指标 您可以使用 CloudWatch 控制台、 CloudWatch自己的命令行界面 (CLI) 或使用 CloudWatch API 以编程方式监控 Security Lake 的指标。选择您的首选方法，然后按照以下步骤访问 Security Lake 指标。 ------ #### [ CloudWatch console ] 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在导航窗格中，依次选择**指标、所有指标**。 1. 在**浏览**选项卡上，选择 **Security Lake**。 1. 选择**每个账户的源版本指标**或**每个源版本指标**。 1. 选择一个指标以查看其详细信息。您还可以选择执行以下操作： + 要对指标进行排序，请使用列标题。 + 要绘制指标图表，请选择指标名称，然后选择一个绘图选项。 + 要按指标进行筛选，请选择指标名称，然后选择**添加到搜索**。 ------ #### [ CloudWatch API ] 要使用 CloudWatch API 访问安全湖指标，请使用[https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)操作。 ------ #### [ AWS CLI ] 要使用访问安全湖指标 AWS CLI，请运行[https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html)命令。 ------ 有关使用指标进行监控的更多信息，请参阅[亚马逊* CloudWatch 用户指南中的使用亚马逊 CloudWatch*指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)。 ## 为安全湖指标设置 CloudWatch 警报 CloudWatch 还允许您在指标达到阈值时设置警报。例如，您可以为该**ProcessedSize**指标设置警报，以便在来自特定来源的数据量超过特定阈值时收到通知。 有关设置警报的说明，请参阅[亚马逊* CloudWatch 用户指南中的使用亚马逊 CloudWatch*警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。