本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Amazon SQS 中的身份和访问管理 AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制谁可以*通过身份验证*（登录）和*获得授权*（具有权限）来使用 Amazon SQS 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。 ## 受众 您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异： + **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[Amazon Simple Queue Service 身份和访问权限故障排查](security_iam_troubleshoot.md)） + **服务管理员**：确定用户访问权限并提交权限请求（请参阅[Amazon Simple Queue Service 如何与 IAM 结合使用](security_iam_service-with-iam.md)） + **IAM 管理员**：编写用于管理访问权限的策略（请参阅[策略最佳实践](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)） ## 使用身份进行身份验证 身份验证是您 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)。 # 管理 Amazon SQS 中的访问权限概述 每个 AWS 资源都归人所有 AWS 账户，创建或访问资源的权限受权限策略的约束。账户管理员可以向 IAM 身份（用户、组和角色）附加权限策略，某些服务（如 Amazon SQS）也支持向资源附加权限策略。 **注意** *账户管理员*（或管理员用户）是具有管理权限的用户。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 最佳实操](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 在授予权限时，由您指定哪些用户获得权限，获得对哪些资源的权限，以及您允许对这些资源执行哪些具体操作。 ## Amazon Simple Queue Service 资源和操作 在 Amazon SQS 中，唯一的资源是*队列*。在策略中，可使用 Amazon 资源名称 (ARN) 标识策略应用到的资源。以下资源具有与之关联的唯一 ARN： | 资源类型 | ARN 格式 | | --- | --- | | 队列 | arn:aws:sqs:region:account\$1id:queue\$1name | 以下是队列的 ARN 格式的示例： + 在美国东部（俄亥俄州）`my_queue`地区命名的队列的 ARN，属于 AWS 账户 123456789012： ``` arn:aws:sqs:us-east-2:123456789012:my_queue ``` + Amazon SQS 支持的每个不同区域中名为 `my_queue` 的队列的 ARN： ``` arn:aws:sqs:*:123456789012:my_queue ``` + 使用 `?` 或 `*` 作为队列名称通配符的 ARN。在以下示例中，ARN 匹配前缀为 `my_prefix_` 的所有队列： ``` arn:aws:sqs:*:123456789012:my_prefix_* ``` 调用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html) 操作可以获取现有队列的 ARN 值。`QueueArn` 属性的值即为队列的 ARN。有关更多信息 ARNs，请参阅 [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) *用户指南ARNs中的 IAM*。 Amazon SQS 提供用于处理队列资源的一组操作。有关更多信息，请参阅 [Amazon SQS API 权限：操作和资源参考](sqs-api-permissions-reference.md)。 ## 了解资源所有权 AWS 账户 拥有在账户中创建的资源，无论谁创建了这些资源。具体而言，资源所有者是对资源创建请求进行身份验证的*主体实体*（即根账户、用户或 IAM 角色）的 AWS 账户 。以下示例说明了它的工作原理： + 如果您使用您的 AWS 账户 根账户证书创建亚马逊 SQS 队列，则您 AWS 账户 就是该资源的所有者（在 Amazon SQS 中，资源是亚马逊 SQS 队列）。 + 如果您在中创建用户 AWS 账户 并向该用户授予创建队列的权限，则该用户可以创建队列。但是，该用户所属的 AWS 账户 是此队列资源的所有者。 + 如果您在中创建 AWS 账户 具有创建 Amazon SQS 队列权限的 IAM 角色，则任何能够担任该角色的人都可以创建队列。您的 AWS 账户 （角色所属的）拥有队列资源。 ## 管理对 资源的访问 *权限策略*描述了授予给账户的权限。下一节介绍创建权限策略时的可用选项。 **注意** 本节讨论如何在 Amazon SQS 范围内使用 IAM。这里不提供有关 IAM 服务的详细信息。有关完整的 IAM 文档，请参阅 *IAM 用户指南*中的[什么是 IAM？](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)。有关 IAM 策略语法和说明的信息，请参阅《IAM 用户指南》中的 [AWS IAM 策略参考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)。 附加到 IAM 身份的策略称作*基于身份* 的策略（IAM 策略），附加到资源的策略称作*基于资源* 的策略。 ### 基于身份的策略 可通过两种方式向用户授予访问 Amazon SQS 队列的权限：使用 Amazon SQS 策略系统和使用 IAM 策略系统。您可以使用任一系统或这两种系统来将策略附加到用户或角色。在大多数情况下，使用任一系统都能获得相同的结果。例如，您可以执行以下操作： + **将权限策略附加到账户中的用户或组** - 要向用户授予创建 Amazon SQS 队列的权限，请将权限策略附加到用户或用户所属的组。 + 将@@ **权限策略附加到其他用户中的用户 AWS 账户**-您可以将权限策略附加到其他用户中的用户， AWS 账户 以允许他们与 Amazon SQS 队列进行交互。但跨账户权限不能应用于以下操作： 跨账户权限不能应用于以下操作： + `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)` + `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)` + `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)` + `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)` + `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)` + `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)` + `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)` + `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)` + `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` + `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)` + `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)` + `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)` 要授予对这些操作的访问权限，用户必须属于拥有该 Amazon SQS 队列的同一 AWS 账户 。 + **将权限策略附加到角色（授予跨账户权限）** – 要向 SQS 队列授予跨账户权限，您必须同时结合使用 IAM 策略和基于资源的策略： 1. 在**账户 A**（队列所有者）中: + 将**基于资源的策略**附加到 SQS 队列。该策略必须向**账户 B** 中的主体（例如 IAM 角色）显式授予所需权限（例如 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)）。 1. 在**账户 A** 中，创建一个 IAM 角色： + 一个**信任策略**，允许**账户 B** 或 AWS 服务 代入该角色。 **注意** 如果您想让 AWS 服务 （例如 Lambda 或EventBridge）担任该角色，请在信任策略中指定服务委托人（例如lambda.amazonaws.com）。 + 一个**基于身份的策略**，向该代入角色授予与队列交互的权限。 1. 在**账户 B** 中，授予在**账户 A** 中代入角色的权限。 您必须将队列的访问策略配置为允许跨账户主体。仅使用基于 IAM 身份的策略不足以实现跨账户访问 SQS 队列。 有关使用 IAM 委托权限的更多信息，请参阅《IAM 用户指南》**中的[访问权限管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)。 尽管 Amazon SQS 使用 IAM 策略，但它拥有自己的策略基础架构。您可以使用带有队列的 Amazon SQS 策略来指定哪些 AWS 账户有权访问队列。您可以指定访问类型和条件（例如，条件是如果请求早于 2010 年 12 月 31 日，即授予使用 `SendMessage` 和 `ReceiveMessage` 的权限）。您可以为其授予权限的特定操作是整个 Amazon SQS 操作列表的子集。如果编写 Amazon SQS 策略并指定 `*` 以“允许所有 Amazon SQS 操作”，则意味着用户可以在此子集中执行所有操作。 下图说明了这些基本 Amazon SQS 策略中涵盖操作子集的一个策略的概念。该策略适用于`queue_xyz`，并授予 AWS 账户 1 和 AWS 账户 2 在指定队列中使用任何允许的操作的权限。 **注意** 策略中的资源指定为`123456789012/queue_xyz`，其中`123456789012`是拥有队列的账户的账户 ID。 AWS ![\[一项涵盖操作子集的 Amazon SQS 策略\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/SQS_BasicPolicy.png) 随着 IAM 的引入以及*用户*和 A *mazon 资源名称 (ARNs)* 的概念，SQS 策略发生了一些变化。以下示意图和表格描述了这些变化。 ![\[IAM 和 Amazon 资源名称已添加到 Amazon SQS 策略中。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/SQS_PolicyWithNewFeatures.png) ![\[Number one in the diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png)有关向不同账户中的用户授予权限的信息，请参阅 IAM *用户指南*中的[教程：使用 IAM 角色委派跨 AWS 账户访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)权限。 ![\[Number two in the diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) `*` 中包含的操作子集已扩展。有关允许的操作的列表，请参阅[Amazon SQS API 权限：操作和资源参考](sqs-api-permissions-reference.md)。 ![\[Number three in the diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 您可以使用 Amazon 资源名称 (ARN) 指定资源，这是在 IAM 策略中指定资源的标准方法。有关 Amazon SQS 队列的 ARN 格式的信息，请参阅 [Amazon Simple Queue Service 资源和操作](#sqs-resource-and-operations)。 例如，根据上图中的 Amazon SQS 政策，任何拥有 AWS 账户 1 或 AWS 账户 2 安全证书的人都可以访问。`queue_xyz`此外，您自己的 AWS 账户（ID 为 `123456789012`）中的用户 Bob 和 Susan 也可以访问该队列。 在推出 IAM 之前，Amazon SQS 会自动向某个队列的创建者授予对该队列的完全控制权限（即访问该队列中所有可能的 Amazon SQS 操作）。现在，除非创建者使用 AWS 安全凭证，否则上述情况将不再出现。如果任何有权创建队列的用户希望对所创建的队列执行任何操作，还必须拥有使用其他 Amazon SQS 操作的权限。 下面是一个示例策略，该策略允许用户使用所有 Amazon SQS 操作，但只能对其名称的前缀为文字字符串 `bob_queue_` 的队列使用。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:123456789012:bob_queue_*" }] } ``` ------ 有关更多信息，请参阅《IAM 用户指南》**中的[将策略用于 Amazon SQS](sqs-using-identity-based-policies.md)以及[身份（用户、组和角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)。 ## 指定策略元素：操作、效果、资源和主体 对于每种 [Amazon Simple Queue Service 资源](#sqs-resource-and-operations)，该服务都定义一组[操作](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_Operations.html)。为授予这些操作的权限，Amazon SQS 定义一组可以在策略中指定的操作。 **注意** 执行一个 操作可能需要多个操作的权限。在授予特定操作的权限时，您也可以标识允许或拒绝对其执行操作的资源。 以下是最基本的策略元素： + **Resource**（资源）- 在策略中，您可以使用 Amazon 资源名称 (ARN) 标识策略应用到的资源。 + **操作** - 您可以使用操作关键字标识要允许或拒绝的资源操作。例如，`sqs:CreateQueue` 权限允许用户执行 Amazon Simple Queue Service `CreateQueue` 操作。 + **效果**：您可以指定当用户请求特定操作（可以是允许或拒绝）时的效果。如果您没有显式授予对资源的访问权限，则隐式拒绝访问。您也可明确拒绝对资源的访问，这样可确保用户无法访问该资源，即使有其他策略授予了访问权限的情况下也是如此。 + **主体** – 在基于身份的策略（IAM 策略）中，附加了策略的用户是隐式主体。对于基于资源的策略，您可以指定要接收权限的用户、账户、服务或其他实体（仅适用于基于资源的策略）。 要详细了解 Amazon SQS 策略语法和描述，请参阅《IAM 用户指南》**中的 [AWS IAM 策略参考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)。 有关所有 Amazon Simple Queue Service 操作及其适用资源的表格，请参阅 [Amazon SQS API 权限：操作和资源参考](sqs-api-permissions-reference.md)。 # Amazon Simple Queue Service 如何与 IAM 结合使用 在使用 IAM 管理对 Amazon SQS 的访问权限之前，您应该了解哪些 IAM 特征可用于 Amazon SQS。 **可与 Amazon Simple Queue Service 结合使用的 IAM 特征** | IAM 功能 | Amazon SQS 支持 | | --- | --- | | [基于身份的策略](#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) | 是 | | [转发访问会话（FAS）](#security_iam_service-with-iam-principal-permissions) | 是 | | [服务角色](#security_iam_service-with-iam-roles-service) | 是 | | [服务关联角色](#security_iam_service-with-iam-roles-service-linked) | 否 | 要全面了解 Amazon SQS 和其他 AWS 服务如何与大多数 IAM 功能配合使用，请参阅 IAM *用户指南中与 IAM 配合使用的AWS *[服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 ## 访问控制 访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。 Amazon S3 和 Amazon VPC 就是支持的服务示例 ACLs。 AWS WAF要了解更多信息 ACLs，请参阅《*亚马逊简单存储服务开发者指南*》中的[访问控制列表 (ACL) 概述](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。 **注意** 重要的是要明白，所有人 AWS 账户 都可以将其权限委托给其账户下的用户。跨账户访问允许您共享对 AWS 资源的访问权限，而无需管理其他用户。有关使用跨账户访问的信息，请参阅 *IAM 用户指南*中的[启用跨账户访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/Delegation.html)。 有关 Amazon SQS 自定义策略中跨内容权限和条件键的更多详细信息，请参阅[Amazon SQS 自定义策略的限制](sqs-limitations-of-custom-policies.md)。 ## Amazon SQS 基于身份的策略 **支持基于身份的策略：**是 基于身份的策略是可附加到身份（如 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)。 ### Amazon EMR 基于身份的策略示例 要查看 Amazon SQS 基于身份的策略示例，请参阅[策略最佳实践](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)。 ## Amazon SQS 内基于资源的策略 **支持基于资源的策略：**是 基于资源的策略是附加到资源的 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)。 ## Amazon SQS 的策略操作 **支持策略操作：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。 要查看 Amazon SQS 操作的列表，请参阅*服务授权参考*中的 [Amazon Simple Queue Service 定义的资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)。 Amazon SQS 中的策略操作在操作前面使用以下前缀： ``` sqs ``` 要在单个语句中指定多项操作，请使用逗号将它们隔开。 ``` "Action": [ "sqs:action1", "sqs:action2" ] ``` 要查看 Amazon SQS 基于身份的策略示例，请参阅[策略最佳实践](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)。 ## Amazon SQS 的策略资源 **支持策略资源：**是 管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。 ``` "Resource": "*" ``` 要查看 Amazon SQS 资源类型及其列表 ARNs，请参阅《服务*授权*参考》中的 “[亚马逊简单队列服务定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-actions-as-permissions)”。要了解您可以在哪些操作中指定每个资源的 ARN，请参阅 [Amazon Simple Queue Service 定义的资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)。 要查看 Amazon SQS 基于身份的策略示例，请参阅[策略最佳实践](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)。 ## Amazon SQS 的策略条件键 **支持特定于服务的策略条件键：**是 管理员可以使用 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)。 要查看 Amazon SQS 条件键的列表，请参阅*服务授权参考*中的 [Amazon Simple Queue Service 的条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-policy-keys)。要了解您可以对哪些操作和资源使用条件键，请参阅 [Amazon Simple Queue Service 定义的资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)。 要查看 Amazon SQS 基于身份的策略示例，请参阅[策略最佳实践](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)。 ## ACLs 在 Amazon SQS 中 **支持 ACLs：**否 访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。 ## ABAC 与 Amazon SQS **支持 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)。 ## 将临时凭证用于 Amazon SQS **支持临时凭证：**是 临时证书提供对 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)。 ## Amazon SQS 的转发访问会话 **支持转发访问会话（FAS）：**是 转发访问会话 (FAS) 使用调用主体的权限 AWS 服务，再加上 AWS 服务 向下游服务发出请求的请求。有关发出 FAS 请求时的策略详情，请参阅[转发访问会话](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)。 ## Amazon SQS 的服务角色 **支持服务角色：**是 服务角色是由一项服务担任、代表您执行操作的 [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)。 **警告** 更改服务角色的权限可能会破坏 Amazon SQS 的功能。仅当 Amazon SQS 提供相关指导时才编辑服务角色。 ## Amazon SQS 的服务相关角色 **支持服务相关角色：**否 服务相关角色是一种与服务相关联的 AWS 服务服务角色。服务可以代入代表您执行操作的角色。服务相关角色出现在您的中 AWS 账户 ，并且归服务所有。IAM 管理员可以查看但不能编辑服务关联角色的权限。 有关创建或管理服务相关角色的详细信息，请参阅[能够与 IAM 搭配使用的AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。在表中查找**服务相关角色**列中包含 `Yes` 的表。选择**是**链接以查看该服务的服务相关角色文档。 # 亚马逊 SQS 更新了托管政策 AWS 要向用户、组和角色添加权限，与自己编写策略相比，使用 AWS 托管式策略更简单。创建仅为团队提供所需权限的 [IAM 客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)需要时间和专业知识。要快速入门，您可以使用我们的 AWS 托管式策略。这些策略涵盖常见使用案例，可在您的 AWS 账户中使用。有关 AWS 托管策略的更多信息，请参阅 *IAM 用户指南*中的[AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。 AWS 服务维护和更新 AWS 托管策略。您无法更改 AWS 托管策略中的权限。服务偶尔会向 AWS 托管策略添加其他权限以支持新功能。此类更新会影响附加策略的所有身份（用户、组和角色）。当推出新功能或有新操作可用时，服务最有可能更新 AWS 托管策略。服务不会从 AWS 托管策略中移除权限，因此策略更新不会破坏您的现有权限。 此外，还 AWS 支持跨多个服务的工作职能的托管策略。例如，**ReadOnlyAccess** AWS 托管策略提供对所有 AWS 服务和资源的只读访问权限。当服务启动一项新功能时， AWS 会为新操作和资源添加只读权限。有关工作职能策略的列表和说明，请参阅 *IAM 用户指南*中的[适用于工作职能的AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。 ## AWS 托管策略：Amazon A SQSFull ccess 您可以将 `AmazonSQSFullAccess` 策略附加到 Amazon SQS 身份。此策略授予允许完全访问 Amazon SQS 的权限。 要查看此策略的权限，请参阅《*AWS 托管策略参考》中的 [Amazon A SQSFull cces](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSQSFullAccess.html) s*。 ## AWS 托管策略：Amazon SQSRead OnlyAccess 您可以将 `AmazonSQSReadOnlyAccess` 策略附加到 Amazon SQS 身份。此策略授予允许对 Amazon SQS 进行只读访问的权限。 要查看此策略的权限，请参阅《*AWS 托管策略参考*》SQSReadOnlyAccess中的 [Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSQSReadOnlyAccess.html)。 ## AWS 托管策略： SQSUnlockQueuePolicy 如果您错误地将成员账户的队列策略配置为拒绝所有用户访问您的 Amazon SQS 队列，则可以使用`SQSUnlockQueuePolicy` AWS 托管策略来解锁队列。 *有关如何删除拒绝所有委托人访问 Amazon SQS 队列的错误配置队列策略的更多信息，[请参阅 IAM 用户指南中的对 AWS Organizations 成员账户执行特权任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html)。* ## 亚马逊 SQS 更新了托管政策 AWS 查看自该服务开始跟踪这些更改以来对 Amazon SQS AWS 托管政策的更新的详细信息。有关此页面更改的自动提示，请订阅 Amazon SQS [文档历史记录](sqs-release-notes.md)页面上的 RSS 源。 | 更改 | 描述 | 日期 | | --- | --- | --- | | [SQSUnlockQueuePolicy](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-SQSUnlockQueuePolicy) | Amazon SQS 添加了一个名为的新 AWS托管策略，该策略`SQSUnlockQueuePolicy`用于解锁队列并删除一个配置错误的队列策略，该策略拒绝所有委托人访问 Amazon SQS 队列。 | 2024 年 11 月 15 日 | | [AmazonSQSReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess) | Amazon SQS 添加了 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html) 操作，该操作用于检索与指定 Amazon SQS 队列关联的所有标签。它让您能够查看出于组织或元数据目的分配给队列的键值对。此操作与 `ListQueueTags` API 操作关联。 | 2024 年 6 月 20 日 | | [AmazonSQSReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess) | Amazon SQS 添加了一个新操作，允许您列出特定源队列下最新的消息移动任务（最多 10 个）。此操作与 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html) API 操作关联。 | 2023 年 6 月 9 日 | # Amazon Simple Queue Service 身份和访问权限故障排查 您可以使用以下信息，帮助诊断和修复在使用 Amazon SQS 和 IAM 时可能遇到的常见问题。 ## 我无权在 Amazon SQS 中执行操作 如果您收到一个错误，指明您无权执行某个操作，则必须更新策略以允许您执行该操作。 当 `mateojackson` 用户尝试使用控制台查看有关虚构 `my-example-widget` 资源的详细信息，但不拥有虚构 `sqs:GetWidget` 权限时，会发生以下示例错误。 ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: sqs:GetWidget on resource: my-example-widget ``` 在此情况下，Mateo 的策略必须更新以允许其使用 `sqs:GetWidget` 操作访问 `my-example-widget` 资源。 如果您需要帮助，请联系您的 AWS 管理员。您的管理员是提供登录凭证的人。 ## 我无权执行 iam：PassRole 如果您收到一个错误，指明您无权执行 `iam:PassRole` 操作，则必须更新策略以允许您将角色传递给 Amazon SQS。 有些 AWS 服务 允许您将现有角色传递给该服务，而不是创建新的服务角色或服务相关角色。为此，您必须具有将角色传递到服务的权限。 当名为 `marymajor` 的 IAM 用户尝试使用控制台在 Amazon SQS 中执行操作时，会发生以下示例错误。但是，服务必须具有服务角色所授予的权限才可执行此操作。Mary 不具有将角色传递到服务的权限。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` 在这种情况下，必须更新 Mary 的策略以允许她执行 `iam:PassRole` 操作。 如果您需要帮助，请联系您的 AWS 管理员。您的管理员是提供登录凭证的人。 ## 我想允许我以外的人访问我 AWS 账户 的 Amazon SQS 资源 您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表 (ACLs) 的服务，您可以使用这些策略向人们授予访问您的资源的权限。 要了解更多信息，请参阅以下内容： + 要了解 Amazon SQS 是否支持这些特征，请参阅[Amazon Simple Queue Service 如何与 IAM 结合使用](security_iam_service-with-iam.md)。 + 要了解如何提供对您拥有的资源的访问权限 AWS 账户 ，请参阅 [IAM 用户*指南中的向您拥有 AWS 账户 的另一个 IAM 用户*提供访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)权限。 + 要了解如何向第三方提供对您的资源的访问[权限 AWS 账户，请参阅 *IAM 用户指南*中的向第三方提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)访问权限。 AWS 账户 + 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（身份联合验证）提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。 + 要了解使用角色和基于资源的策略进行跨账户访问之间的差别，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 ## 我想解锁我的队列 如果您 AWS 账户 属于某个组织，则 AWS Organizations 策略可能会阻止您访问 Amazon SQS 资源。默认情况下， AWS Organizations 策略不会阻止任何向 Amazon SQS 发出的请求。但是，请确保您的 AWS Organizations 策略尚未配置为阻止访问 Amazon SQS 队列。有关如何查看您的 AWS Organizations 政策的说明，请参阅《*AWS Organizations 用户指南》*中的[列出所有政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_info-operations.html#list-all-pols-in-org.html)。 此外，如果您错误地将成员账户的队列策略配置为拒绝所有用户访问您的 Amazon SQS 队列，则可以通过在 IAM 中为该成员账户启动特权会话来解锁队列。启动特权会话后，您可以删除配置错误的队列策略以重新获得对队列的访问权限。有关更多信息，请参阅 *IAM 用户指南*中的[对 AWS Organizations 成员账户执行特权任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html)。 # 将策略用于 Amazon SQS 本主题提供基于身份的策略示例，在这些示例中，账户管理员可以向 IAM 身份（用户、组和角色）附加权限策略。 **重要** 我们建议您首先阅读以下介绍性主题，这些主题讲解了管理 Amazon Simple Queue Service 资源访问权限的基本概念和选项。有关更多信息，请参阅 [管理 Amazon SQS 中的访问权限概述](sqs-overview-of-managing-access.md)。 除 `ListQueues` 外，所有 Amazon SQS 操作均支持资源级权限。有关更多信息，请参阅 [Amazon SQS API 权限：操作和资源参考](sqs-api-permissions-reference.md)。 ## 使用 Amazon SQS 和 IAM 策略 您可以通过两种方式向用户授予访问 Amazon SQS 资源的权限：使用 Amazon SQS 策略系统（基于资源的策略）和使用 IAM 策略系统（基于身份的策略）。您可以使用一种或两种方法，但 `ListQueues` 操作除外，这是一种区域性权限，只能在 IAM 策略中设置。 例如，下图显示了等效的 IAM 策略和 Amazon SQS 策略。IAM 策略授予对 Amazon SQS 的权限`ReceiveMessage`和对您 AWS 账户`queue_xyz`中调用的队列的`SendMessage`操作，该策略将附加到名为 Bob 和 Susan 的用户（Bob 和 Susan 拥有策略中规定的权限）。此 Amazon SQS 策略还向 Bob 和 Susan 授予对同一队列进行 `ReceiveMessage` 和 `SendMessage` 操作的权限。 **注意** 以下示例显示了不带条件的简单策略。您可以在上述任一策略中指定特定条件，并获得同样的结果。 ![\[IAM 策略与等效的 Amazon SQS 策略的对比图。IAM 策略授予对 Amazon SQS 的权限ReceiveMessage和对您 AWS 账户queue_xyz中调用的队列的SendMessage操作，该策略将附加到名为 Bob 和 Susan 的用户（Bob 和 Susan 拥有策略中规定的权限）。此 Amazon SQS 策略还向 Bob 和 Susan 授予对同一队列进行 ReceiveMessage 和 SendMessage 操作的权限。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-equivalent.png) IAM 和 Amazon SQS 政策之间有一个主要区别：Amazon SQS 策略系统允许您向 AWS 其他账户授予权限，而 IAM 不允许。 您可以自行决定如何综合使用上述两种系统来管理您的权限。以下示例展示这两种策略系统是如何共同运行的。 + 在第一个示例中，Bob 同时拥有 IAM 策略和适用于其账户的 Amazon SQS 策略。IAM 策略向其账户授予对 `queue_xyz` 执行 `ReceiveMessage` 操作的权限，而 Amazon SQS 策略向其账户授予对同一队列执行 `SendMessage` 操作的权限。下图阐明了这一概念。 ![\[Amazon SQS 策略与 IAM 策略的各个组成部分的对比图。在第一个示例中，Bob 同时拥有 IAM 策略和适用于其账户的 Amazon SQS 策略。IAM 策略向其账户授予对 queue_xyz 执行 ReceiveMessage 操作的权限，而 Amazon SQS 策略向其账户授予对同一队列执行 SendMessage 操作的权限。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-union.png) 如果 Bob 向 `queue_xyz` 发送 `ReceiveMessage` 请求，则 IAM 策略将允许执行该操作。如果 Bob 向 `queue_xyz` 发送 `SendMessage` 请求，则 Amazon SQS 策略将允许执行该操作。 + 在第二个示例中，Bob 滥用他对 `queue_xyz` 的访问权限，因此有必要删除他对该队列的所有访问权限。最简单的方法是添加一个策略，拒绝他访问该队列的所有操作。此策略会覆盖另外两个策略，因为显式 `deny` 始终覆盖 `allow`。有关策略评估逻辑的更多信息，请参阅[将自定义策略与 Amazon SQS 访问策略语言配合使用](sqs-creating-custom-policies.md)。下图阐明了这一概念。 ![\[展示使用 Amazon SQS 策略替换 IAM 策略的图。Bob 滥用他对 queue_xyz 的访问权限，因此有必要删除他对该队列的所有访问权限。最简单的方法是添加一个策略，拒绝他访问该队列的所有操作。此策略会覆盖另外两个策略，因为显式 deny 始终覆盖 allow。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-deny-override.png) 您还可以向 Amazon SQS 策略中添加一条额外语句，拒绝 Bob 以任何方式访问该队列。添加一条 IAM 策略拒绝 Bob 访问该队列也具有同样的效果。有关涉及 Amazon SQS 操作和资源的策略示例，请参阅 [Amazon SQS 策略的基本示例](sqs-basic-examples-of-sqs-policies.md)。有关编写 Amazon SQS 策略的更多信息，请参阅[将自定义策略与 Amazon SQS 访问策略语言配合使用](sqs-creating-custom-policies.md)。 ## 使用 Amazon SQS 控制台所需的权限 希望使用 Amazon SQS 控制台的用户必须具有在用户的 AWS 账户中使用 Amazon SQS 队列的最小权限集。例如，用户必须具有调用 `ListQueues` 操作的权限才能列出队列，或者必须具有调用 `CreateQueue` 操作的权限才能创建队列。要将 Amazon SQS 队列订阅到 Amazon SNS 主题，则除了 Amazon SQS 权限之外，控制台还需要针对 Amazon SNS 操作的权限。 如果创建比必需的最低权限更为严格的 IAM 策略，对于附加了该 IAM 策略的用户，控制台可能无法按预期方式运行。 对于仅调用 AWS CLI 或 Amazon SQS 操作的用户，您无需为其设置最低控制台权限。 # Amazon EMR 基于身份的策略示例 默认情况下，用户和角色没有创建或修改 Amazon SQS 资源的权限。要授予用户对所需资源执行操作的权限，IAM 管理员可以创建 IAM 策略。 要了解如何使用这些示例 JSON 策略文档创建基于 IAM 身份的策略，请参阅《IAM 用户指南》**中的[创建 IAM 策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 有关 Amazon SQS 定义的操作和资源类型（包括每种资源类型的格式）的详细信息，请参阅《服务*授权*参考》中的 [Amazon Simple Queue 服务的操作、资源和条件密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html)。 ARNs **注意** 在为 Amazon EC2 Auto Scaling 配置生命周期挂钩时，您无需编写策略将消息发送至 Amazon SQS 队列。有关更多信息，请参阅《Amazon EC2 用户指南》**中的 [Amazon EC2 Auto Scaling Lifecycle Hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)。 ## 策略最佳实践 基于身份的策略确定某个人是否可以创建、访问或删除您账户中的 Amazon SQS 资源。这些操作可能会使 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)。 ## 使用 Amazon SQS 控制台 要访问 Amazon Simple Queue Service 控制台，您必须具有一组最低的权限。这些权限必须允许您列出和查看有关您的 Amazon SQS 资源的详细信息。 AWS 账户如果创建比必需的最低权限更为严格的基于身份的策略，对于附加了该策略的实体（用户或角色），控制台将无法按预期正常运行。 对于仅调用 AWS CLI 或 AWS API 的用户，您无需为其设置最低控制台权限。相反，只允许访问与其尝试执行的 API 操作相匹配的操作。 为确保用户和角色仍然可以使用 Amazon SQS 控制台，还要将 Amazon `AmazonSQSReadOnlyAccess` AWS SQS 托管策略附加到实体。有关更多信息，请参阅《IAM 用户指南》**中的[为用户添加权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)。 ## 允许用户查看他们自己的权限 该示例说明了您如何创建策略，以允许 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": "*" } ] } ``` ## 允许用户创建队列 在以下示例中，我们为 Bob 创建了一条策略，允许他访问所有 Amazon SQS 操作，但是仅限于名称前缀为文本字符串 `alice_queue_` 的队列。 Amazon SQS 不会自动向队列创建者授予使用该队列的权限。因此，除了 IAM 策略中的 `CreateQueue` 操作，我们还必须向 Bob 显式授予使用所有 Amazon SQS 操作的权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:123456789012:alice_queue_*" }] } ``` ------ ## 允许开发人员向共享队列写入消息 在以下示例中，我们为开发者创建了一个群组，并附加了一个策略，允许该群组使用 Amazon SQS `SendMessage` 操作，但只能使用属于指定 AWS 账户 且已命名的队列。`MyCompanyQueue` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:123456789012:MyCompanyQueue" }] } ``` ------ 您可以使用 `*`（而不是 `SendMessage`）向主体授予对共享队列执行以下操作的权限：`ChangeMessageVisibility`、`DeleteMessage`、`GetQueueAttributes`、`GetQueueUrl`、`ReceiveMessage` 和 `SendMessage`。 **注意** 虽然 `*` 包含其他权限类型提供的访问权限，但 Amazon SQS 会单独考虑这些权限。例如，可以向用户同时授予 `*` 和 `SendMessage` 权限，即使 `*` 包含 `SendMessage` 提供的访问权限，也是如此。 此概念在您删除权限时也适用。如果主体只有 `*` 权限，则请求删除 `SendMessage` 权限*不会* 为主体留下*除此以外的一切* 权限。相反，该请求不起作用，因为主体不具有显式 `SendMessage` 权限。要只为主体留下 `ReceiveMessage` 权限，请先添加 `ReceiveMessage` 权限，然后删除 `*` 权限。 ## 允许管理人员获取队列的一般大小 在以下示例中，我们为经理创建了一个群组，并附加了一个策略，允许该群组对属于指定 AWS 账户的所有队列使用 Amazon SQS `GetQueueAttributes` 操作。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "*" }] } ``` ------ ## 允许合作伙伴向指定队列发送消息 您可以使用 Amazon SQS 策略或 IAM 策略完成此任务。如果您的合作伙伴有 AWS 账户，则使用 Amazon SQS 政策可能会更容易。但是，合作伙伴公司中任何拥有 AWS 安全凭证的用户都可以向队列发送消息。如果需要仅向特定用户或应用程序授予访问权限，则必须像对待公司内部的用户那样对待合作伙伴，使用 IAM 策略而不是 Amazon SQS 策略。 本示例将执行以下操作： 1. 创建一个名 WidgetCo 为代表合作伙伴公司的小组。 1. 为合作伙伴公司中需要访问权限的特定用户或应用程序创建用户。 1. 将 用户添加到 组。 1. 挂载一条策略，仅允许该组对名为 `SendMessage` 的队列执行 `WidgetPartnerQueue` 操作。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:123456789012:WidgetPartnerQueue" }] } ``` ------ # Amazon SQS 策略的基本示例 本部分显示了常见 Amazon SQS 使用案例的示例策略。 在将每个策略附加到用户时，可使用控制台验证该策略的效果。最初，用户没有权限并且无法在控制台中执行任何操作。在将策略附加到用户时，可以验证用户是否能在控制台中执行各种操作。 **注意** 我们建议您使用两个浏览器窗口：一个用于授予权限，另一个用于在向用户授予权限时 AWS 管理控制台 使用用户的证书登录以验证权限。 ## 示例 1：向一个人授予一个权限 AWS 账户 以下示例策略向 AWS 账户 编号`111122223333`授予在美国东部（俄亥俄州）`444455556666/queue1`地区命名的队列的`SendMessage`权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_SendMessage", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:us-east-2:444455556666:queue1" }] } ``` ------ ## 示例 2：向其中一个授予两个权限 AWS 账户 以下示例策略为名为的队列授予 AWS 账户 编号`111122223333``SendMessage`和`ReceiveMessage`权限`444455556666/queue1`。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_Send_Receive", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:*:444455556666:queue1" }] } ``` ------ ## 示例 3：将所有权限授予两个 AWS 账户 以下示例策略授予两个不同的 AWS 账户 数字（`111122223333`和`444455556666`）权限，允许他们使用 Amazon SQS 允许共享访问美国东部（俄亥俄州）区域`123456789012/queue1`中命名的队列的所有操作。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AllActions", "Effect": "Allow", "Principal": { "AWS": [ "111122223333", "444455556666" ] }, "Action": "sqs:*", "Resource": "arn:aws:sqs:us-east-2:123456789012:queue1" }] } ``` ------ ## 示例 4：向角色和用户名授予跨账户权限 以下示例策略授予 `role1` Amazon SQS 允许共享访问位于美国东部（俄亥俄州）地区的队`123456789012/queue1`列的所有操作的`111122223333`跨账户权限。`username1` AWS 账户 跨账户权限不能应用于以下操作： + `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)` + `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)` + `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)` + `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)` + `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)` + `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)` + `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)` + `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)` + `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` + `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)` + `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)` + `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AllActions", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/role1", "arn:aws:iam::111122223333:user/username1" ] }, "Action": "sqs:*", "Resource": "arn:aws:sqs:us-east-2:123456789012:queue1" }] } ``` ------ ## 示例 5：向所有用户授予一项权限 以下示例策略向所有用户（匿名用户）授予对名为 `111122223333/queue1` 的队列的 `ReceiveMessage` 权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_ReceiveMessage", "Effect": "Allow", "Principal": "*", "Action": "sqs:ReceiveMessage", "Resource": "arn:aws:sqs:*:111122223333:queue1" }] } ``` ------ ## 示例 6：向所有用户授予有时间限制的权限 以下示例策略向所有用户（匿名用户）授予对名为 `111122223333/queue1` 的队列的 `ReceiveMessage` 权限，但有效时间仅限于 2009 年 1 月 31 日中午 12:00 至下午 3:00 期间。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_ReceiveMessage_TimeLimit", "Effect": "Allow", "Principal": "*", "Action": "sqs:ReceiveMessage", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "DateGreaterThan" : { "aws:CurrentTime":"2009-01-31T12:00Z" }, "DateLessThan" : { "aws:CurrentTime":"2009-01-31T15:00Z" } } }] } ``` ------ ## 示例 7：向 CIDR 范围内的所有用户授予所有权限 以下示例策略向所有用户（匿名用户）授予对名为 `111122223333/queue1` 的队列使用可以共享的所有可能的 Amazon SQS 操作的权限，但条件是请求必须来自于 `192.0.2.0/24` CIDR 范围。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_AllActions_AllowlistIP", "Effect": "Allow", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "IpAddress" : { "aws:SourceIp":"192.0.2.0/24" } } }] } ``` ------ ## 示例 8：不同 CIDR 范围内用户的允许列表和阻止列表权限 以下策略示例具有两项陈述： + 第一个语句向 `192.0.2.0/24` CIDR 范围（`192.0.2.188` 除外）内的所有用户（匿名用户）授予对名为 `111122223333`/queue1 的队列使用 `SendMessage` 操作的权限。 + 第二个语句阻止 `12.148.72.0/23` CIDR 范围内的所有用户（匿名用户）使用该队列。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "Queue1_Policy_UUID", "Statement": [{ "Sid":"Queue1_AnonymousAccess_SendMessage_IPLimit", "Effect": "Allow", "Principal": "*", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "IpAddress" : { "aws:SourceIp":"192.0.2.0/24" }, "NotIpAddress" : { "aws:SourceIp":"192.0.2.188/32" } } }, { "Sid":"Queue1_AnonymousAccess_AllActions_IPLimit_Deny", "Effect": "Deny", "Principal": "*", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:111122223333:queue1", "Condition" : { "IpAddress" : { "aws:SourceIp":"12.148.72.0/23" } } }] } ``` ------ # 将自定义策略与 Amazon SQS 访问策略语言配合使用 要仅根据 AWS 账户 ID 授予基本权限（例如[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)或 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)），您无需编写自定义策略。只需使用 Amazon SQS [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 操作即可。 要根据请求时间或请求者的 IP 地址等特定条件允许或拒绝访问，您必须创建自定义 Amazon SQS 策略并使用[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)操作将其上传。 **Topics** + [访问控制架构](sqs-creating-custom-policies-architecture.md) + [访问控制处理工作流程](sqs-creating-custom-policies-process-workflow.md) + [访问策略语言关键概念](sqs-creating-custom-policies-key-concepts.md) + [访问策略语言评估逻辑](sqs-creating-custom-policies-evaluation-logic.md) + [显式拒绝和默认拒绝之间的关系](sqs-creating-custom-policies-relationships-between-explicit-default-denials.md) + [自定义策略的限制](sqs-limitations-of-custom-policies.md) + [自定义访问策略语言示例](sqs-creating-custom-policies-access-policy-examples.md) # Amazon SQS 访问控制架构 下图介绍了 Amazon SQS 资源的访问控制。 ![\[介绍 Amazon SQS 资源的访问控制。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Arch_Overview.png) ![\[In the previous diagram, section number one.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 您，资源所有者。 ![\[In the previous diagram, section number two.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png)您的资源包含在 AWS 服务中（例如，Amazon SQS 队列）。 ![\[In the previous diagram, section number three.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 您的策略。比较好的做法是为每个资源提供一个策略。该 AWS 服务提供了一个 API，您可以用来上传和管理您的政策。 ![\[In the previous diagram, section number four.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) 请求者和他们向 AWS 服务传入的请求。 ![\[In the previous diagram, section number five.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) 访问策略语言评估代码。这是 AWS 服务中的一组代码，用于根据适用的策略评估传入的请求，并确定是否允许请求者访问资源。 # Amazon SQS 访问控制处理工作流程 下图介绍了使用 Amazon SQS 访问策略语言进行访问控制的一般工作流程。 ![\[使用 Amazon SQS 访问策略语言进行访问控制的一般工作流程。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Basic_Flow.png) ![\[Figure one in the previous diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 您为您的队列编写一个 Amazon SQS 策略。 ![\[Figure two in the previous diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png)您将您的保单上传到 AWS。该 AWS 服务提供了一个 API，供您上传您的政策。例如，您使用 Amazon SQS `SetQueueAttributes` 操作来为特定 Amazon SQS 队列上传策略。 ![\[Figure three in the previous diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 某人向您发出使用 Amazon SQS 队列的请求。 ![\[Figure four in the previous diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) Amazon SQS 检查所有可用的 Amazon SQS 策略并决定哪些策略适用。 ![\[Figure five in the previous diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) Amazon SQS 对这些策略进行评估，确定是否允许请求者使用您的队列。 ![\[Figure six in the previous diagram.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-6-red.png) 根据策略评估结果，Amazon SQS 向请求者返回 `Access denied` 错误消息，或者继续处理该请求。 # Amazon SQS 访问策略语言关键概念 要自行编写策略，您必须熟悉 [JSON](http://json.org/) 和一些关键概念。 **允许** 将[Statement](#statement)设为 [效果](#effect) 时`allow`的结果。 **Action** [主体](#principal) 拥有权限可以执行的活动，通常是对 AWS的请求。 **默认拒绝** 没有 [允许](#allow) 或 [显式拒绝](#explicit-deny) 设置的 [Statement](#statement) 的结果。 **Condition** 有关[许可](#permission)的任何限制或详细信息。典型的条件与日期、时间和 IP 地址相关。 **效果** 您希望一个[Policy](#policy)的[Statement](#statement)在评估期间返回的结果。您编写策略语句时可以指定 `deny` 或 `allow` 值。在策略评估期间有三种可能的结果：[默认拒绝](#default-deny)、[允许](#allow)和[显式拒绝](#explicit-deny)。 **显式拒绝** 将[Statement](#statement)设为 [效果](#effect) 时`deny`的结果。 **评估** Amazon SQS 用来根据 [Policy](#policy) 确定是否拒绝或允许传入请求的过程。 **发布者** 编写[Policy](#policy)以对资源授予权限的用户。顾名思义，发行者始终是资源所有者。 AWS 不允许 Amazon SQS 用户为他们不拥有的资源创建策略。 **键** 设置访问限制指定的特性。 **许可** 使用[Condition](#condition)和[键](#key)允许或拒绝对资源的访问的概念。 **Policy** 充当一条或多条**[语句](#statement)**容器的文档。 ![\[包含语句 1 和语句 2 的策略 A 的效果等同于包含语句 1 的策略 A 和包含语句 2 的策略 B 的共同效果。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Statement_and_Policy.png) Amazon SQS 使用策略确定是否授予用户访问资源的权限。 **主体** 收到[许可](#permission)中[Policy](#policy)的用户。 **资源** [主体](#principal)请求访问的对象。 **Statement** 单个权限的正式描述，以访问策略语言编写，作为更大的 [Policy](#policy) 文档的一部分。 **请求者** 发送访问[资源](#resource)请求的用户。 # Amazon SQS 访问策略语言评估逻辑 在评估期间，Amazon SQS 确定应允许还是拒绝资源所有者以外的某人发送的请求。评估逻辑遵循多个基本规则： + 在默认情况下，您拒绝任何人发送的所有使用资源的请求。 + *[允许](sqs-creating-custom-policies-key-concepts.md#allow)* 将覆盖任意*[默认拒绝](sqs-creating-custom-policies-key-concepts.md#default-deny)*。 + *[显式拒绝](sqs-creating-custom-policies-key-concepts.md#explicit-deny)* 将覆盖任意**允许**。 + 策略评估的顺序并不重要。 下图详述了 Amazon SQS 如何评估有关访问权限的决策。 ![\[描述 Amazon SQS 如何评估有关访问权限的决策的流程图。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Evaluation_Flow.png) ![\[In the previous diagram, number one.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 该决策开始是一个**默认拒绝**。 ![\[In the previous diagram, number two.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) 执行代码评估适用于请求的所有策略（根据资源、主体、操作和条件）。执行代码评估策略的顺序并不重要。 ![\[In the previous diagram, number three.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) 执行代码寻找应用于请求的**显式拒绝**指令。即使执行代码只找到了一个，也会返回**拒绝**决策，整个过程完成。 ![\[In the previous diagram, number four.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) 如果没有找到**显式拒绝**指令，那么执行代码将寻找应用于请求的任何**允许**指令。即使执行代码只找到了一个，也会返回**允许**决策，整个过程完成（服务将继续处理该请求）。 ![\[In the previous diagram, number five.\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png) 如果未找到任何**允许**指令，那么最终决策将是**拒绝**（因为没有**显式拒绝**或**允许**，所以这将被视为一个**默认拒绝**）。 # Amazon SQS 访问策略语言中显式拒绝和默认拒绝之间的关系 如果 Amazon SQS 策略不直接应用于请求，则该请求会导致 *[默认拒绝](sqs-creating-custom-policies-key-concepts.md#default-deny)*。例如，如果用户请求使用 Amazon SQS 的权限，但应用于该用户的唯一策略可使用 DynamoDB，则该请求会导致 **default-deny**。 如果未能满足语句中的某个条件，则该请求的结果为**默认拒绝**。如果满足了语句中的所有条件，那么根据策略中 *[效果](sqs-creating-custom-policies-key-concepts.md#effect)* 元素的值，该请求的结果可能为 *[允许](sqs-creating-custom-policies-key-concepts.md#allow)* 或 *[显式拒绝](sqs-creating-custom-policies-key-concepts.md#explicit-deny)*。如果策略没有指定如何处理未满足某个条件的情况，那么在这种情况下默认结果为**默认拒绝**。例如，您想要阻止来自南极洲的请求。您编写了策略 A1，只要请求不是来自于南极洲，就接受请求。下图说明了 Amazon SQS 策略。 ![\[在策略 A1 中，“Effect”为“Allow”，“Condition”为“if request is not from Antarctica”。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-allow-request-if-not-from-antarctica.png) 如果用户从美国发出请求，那么条件已经满足（该请求不是来自南极洲），则该请求的结果是**允许**。但是，如果用户从南极洲发出请求，那么条件未满足，该请求的默认结果为**默认拒绝**。您可以编写策略 A2，显式拒绝来自南极洲的请求，这样结果就变为**显式拒绝**。下列示意图说明了该策略。 ![\[在策略 A2 中，“Effect”为“Deny”，“Condition”为“if request is from Antarctica”。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-explicitly-deny-request-if-from-antarctica.png) 如果用户从南极洲发出请求，那么条件已经满足，则该请求的结果为**显式拒绝**。 **默认拒绝**和**显式拒绝**之间的区别很重要，因为**允许**可以覆盖前者但不能覆盖后者。例如，策略 B 允许在 2010 年 6 月 1 日到达的请求。下图比较了将此策略与策略 A1 和策略 A2 进行组合的情况。 ![\[情景 1 和方案 2 的 side-by-side比较。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-compare-allow-request-deny-request-policies-override.png) 在场景 1 中，策略 A1 的结果为**默认拒绝**，策略 B 的结果为**允许**，因为该策略允许 2010 年 6 月 1 日传入的请求。策略 B 返回的**允许**结果将覆盖策略 A1 的**默认拒绝**结果，因此，请求获得允许。 在场景 2 中，策略 B2 的结果为**显式拒绝**，策略 B 的结果为**允许**。从策略 A2 发出的**显式拒绝**将覆盖从策略 B 发出的**允许**，因此该请求会被拒绝。 # Amazon SQS 自定义策略的限制 ## 跨账户访问 跨账户权限不能应用于以下操作： + `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)` + `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)` + `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)` + `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)` + `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)` + `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)` + `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)` + `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)` + `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` + `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)` + `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)` + `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)` ## 条件键 Amazon SQS 目前只支持 [IAM 中可用条件键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)的有限子集。有关更多信息，请参阅 [Amazon SQS API 权限：操作和资源参考](sqs-api-permissions-reference.md)。 # 自定义 Amazon SQS 访问策略语言示例 以下示例是典型的 Amazon SQS 访问策略。 ## 示例 1：为一个账户授予权限 以下示例 Amazon SQS 策略为 AWS 账户 111122223333 授予权限，允许从 AWS 账户 444455556666 拥有的 `queue2` 中发送和接收请求。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase1", "Statement" : [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2" }] } ``` ------ ## 示例 2：对一个或多个账户授予权限 以下示例 Amazon SQS 策略允许在特定时间段内对您的账户拥有的队列进行一个或多个 AWS 账户 访问权限。有必要编写此策略并使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 操作将其上传到 Amazon SQS，因为 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 操作不允许在授予队列访问权限时指定时间限制。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase2", "Statement" : [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333", "444455556666" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2", "Condition": { "DateLessThan": { "AWS:CurrentTime": "2009-06-30T12:00Z" } } }] } ``` ------ ## 示例 3：对来自 Amazon EC2 实例的请求授予权限 以下示例 Amazon SQS 策略对来自 Amazon EC2 实例的请求授予访问权限。此示例根据“[示例 2：对一个或多个账户授予权限](#two-accounts)”示例编写：它将访问时间限制在 2009 年 6 月 30 日中午 12 点 (UTC) 之前，将访问 IP 的范围限制在 `203.0.113.0/24`。有必要编写此策略并使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 操作将其上传到 Amazon SQS，因为 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 操作不允许在授予队列访问权限时指定 IP 地址限制。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase3", "Statement" : [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2", "Condition": { "DateLessThan": { "AWS:CurrentTime": "2009-06-30T12:00Z" }, "IpAddress": { "AWS:SourceIp": "203.0.113.0/24" } } }] } ``` ------ ## 示例 4：拒绝特定账户的访问 以下示例 Amazon SQS 策略拒绝对您的队列的特定 AWS 账户 访问权限。此示例以 “[示例 1：为一个账户授予权限](#one-account)” 示例为基础：它拒绝访问指定的 AWS 账户。有必要编写此策略并使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) 操作将其上传到 Amazon SQS，因为 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) 操作不允许拒绝对队列的访问权限（它只允许授予对队列的访问权限）。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase4", "Statement" : [{ "Sid": "1", "Effect": "Deny", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:444455556666:queue2" }] } ``` ------ ## 示例 5：如果不是来自 VPC 端点，则拒绝访问 以下示例 Amazon SQS 策略限制对 `queue1` 的访问权限：111122223333 只能通过 VPC 端点 ID `vpce-1a2b3c4d`（使用 `aws:sourceVpce` 条件指定）执行 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) 和 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) 操作。有关更多信息，请参阅 [Amazon SQS 的 Amazon Virtual Private Cloud 端点](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoints)。 **注意** `aws:sourceVpce` 条件不需要 VPC 端点资源的 ARN，而只需要 VPC 端点 ID。 您可以通过在第二个语句中拒绝所有 Amazon SQS 操作 (`sqs:*`)，修改以下示例，以将所有操作限制到特定 VPC 端点。但是，此类策略声明将规定所有操作（包括修改队列权限所需的管理操作）必须通过在策略中定义的特定 VPC 端点进行，这可能会阻止用户以后修改队列权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "UseCase5", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:111122223333:queue1" }, { "Sid": "2", "Effect": "Deny", "Principal": "*", "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:111122223333:queue1", "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1a2b3c4d" } } } ] } ``` ------ # 将临时安全凭证用于 Amazon SQS 除了使用自己的安全证书创建用户外，IAM 还允许您向任何用户授予临时安全证书，从而允许该用户访问您的 AWS 服务和资源。您可以管理拥有 AWS 账户的用户。您还可以管理系统中没有的用户 AWS 账户 （联合用户）。此外，您为访问 AWS 资源而创建的应用程序也可以被视为 “用户”。 您可以使用上述临时安全凭证对 Amazon SQS 发出请求。API 库会使用这些凭证计算必要的签名值，以便对您的请求进行身份验证。如果您使用过期的凭证发送请求，则 Amazon S3 会拒绝请求。 **注意** 您不能基于临时凭证设置策略。 ## 先决条件 1. 使用 IAM 创建临时安全凭证： + 安全令牌 + 访问密钥 ID + 秘密访问密钥 1. 使用临时访问密钥 ID 和安全令牌准备待签字符串。 1. 使用临时秘密访问密钥（而不是您自己的秘密访问密钥）对您的查询 API 请求签名。 **注意** 在提交已签名的查询 API 请求时，请使用临时访问密钥 ID（而不是您自己的访问密钥 ID），并且包含安全令牌。有关 IAM 对临时安全证书的支持的更多信息，请参阅 I *AM 用户指南*中的[授予对 AWS 资源的临时访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/TokenBasedAuth.html)。 ## 使用临时安全凭证调用 Amazon SQS 查询 API 操作 1. 使用申请临时安全令牌 AWS Identity and Access Management。有关更多信息，请参阅《IAM 用户指南》**中的[创建临时安全凭证以便为 IAM 用户启用访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/CreatingSessionTokens.html)。 IAM 会返回一个安全令牌、一个访问密钥 ID 和一个秘密访问密钥。 1. 使用临时访问密钥 ID（而不是您自己的访问密钥 ID）准备查询，并且包含安全令牌。使用临时秘密访问密钥（而不是您自己的秘密访问密钥）对请求签名。 1. 提交已使用临时访问密钥 ID 和安全令牌签名的查询字符串。 以下示例说明如何使用临时安全凭证对 Amazon SQS 请求进行身份验证。*`AUTHPARAMS`* 的结构取决于 API 请求的签名。有关更多信息，请参阅[《*亚马逊 Web Services 一般参考*》中的 “签署 AWS API 请求](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)”。 ``` https://sqs.us-east-2.amazonaws.com/ ?Action=CreateQueue &DefaultVisibilityTimeout=40 &QueueName=MyQueue &Attribute.1.Name=VisibilityTimeout &Attribute.1.Value=40 &Expires=2020-12-18T22%3A52%3A43PST &SecurityToken=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY &AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &Version=2012-11-05 &AUTHPARAMS ``` 以下示例使用了临时安全凭证来通过 `SendMessageBatch` 操作发送两条消息。 ``` https://sqs.us-east-2.amazonaws.com/ ?Action=SendMessageBatch &SendMessageBatchRequestEntry.1.Id=test_msg_001 &SendMessageBatchRequestEntry.1.MessageBody=test%20message%20body%201 &SendMessageBatchRequestEntry.2.Id=test_msg_002 &SendMessageBatchRequestEntry.2.MessageBody=test%20message%20body%202 &SendMessageBatchRequestEntry.2.DelaySeconds=60 &Expires=2020-12-18T22%3A52%3A43PST &SecurityToken=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY &AWSAccessKeyId=AKIAI44QH8DHBEXAMPLE &Version=2012-11-05 &AUTHPARAMS ``` # 使用最低权限策略管理加密 Amazon SQS 队列的访问权限 您可以使用 Amazon SQS 通过与 [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) 集成的服务器端加密 (SSE) 在应用程序之间交换敏感数据。通过集成 Amazon SQS 和 AWS KMS，您可以集中管理保护 Amazon SQS 的密钥以及保护您的其他资源的密钥。 AWS 多个 AWS 服务可以充当向 Amazon SQS 发送事件的事件源。要使事件源能够访问加密的 Amazon SQS 队列，您需要使用[客户](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) AWS KMS 管理的密钥配置队列。然后，使用密钥策略允许服务使用所需的 AWS KMS API 方法。该服务还需要对访问进行身份验证的权限才能使队列发送事件。您可以使用 Amazon SQS 策略来实现这一目标，该策略是一种基于资源的策略，可用于控制对 Amazon SQS 队列及其数据的访问。 以下各节提供有关如何通过亚马逊 SQS 策略和 AWS KMS 密钥策略控制对加密的 Amazon SQS 队列的访问权限的信息。本指南中的策略将帮助您实现[最低权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。 本指南还介绍了基于资源的策略如何使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 和 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) 全局 IAM 条件上下文键来解决[混淆代理问题](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)。 **Topics** + [ ## 概述 ](#sqs-least-privilege-overview) + [ ## 最低权限 Amazon SQS 密钥政策 ](#sqs-least-privilege-use-case) + [ ## 死信队列的 Amazon SQS 策略语句 ](#sqs-policy-dlq) + [ ## 防范跨服务混淆代理问题 ](#sqs-confused-deputy-prevention) + [ ## 使用 IAM Access Analyzer 查看跨账户访问权限 ](#sqs-cross-account-findings) ## 概述 在本主题中，我们将为您介绍一个常见使用案例，以说明如何构建密钥政策和 Amazon SQS 队列策略。此使用案例如下图所示。 ![\[将 Amazon SNS 消息发布到 Amazon SQS。\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-least-privilege.png) 在此示例中，消息创建者是 [Amazon Simple Notification Service (SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 主题，该主题配置为将消息扇出到您的加密 Amazon SQS 队列。消息使用者是一项计算服务，例如 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 函数、[Amazon Elastic Compute Cloud（EC2）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)实例或 [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) 容器。然后，将您的 Amazon SQS 队列配置为将失败的消息发送到[死信队列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)。这对于调试应用程序或消息传递系统非常有用 DLQs ，因为您可以隔离未使用的消息，以确定其处理失败的原因。在本主题中定义的解决方案中，使用 Lambda 函数等计算服务来处理存储在 Amazon SQS 队列中的消息。如果消息使用者位于虚拟私有云（VPC）中，则本指南中包含的 [`DenyReceivingIfNotThroughVPCE`](#sqs-restrict-message-to-endpoint) 策略语句允许您将消息接收限制在该特定 VPC 上。 **注意** 本指南仅以策略语句的形式包含所需的 IAM 权限。要制定政策，您需要将声明添加到您的 Amazon SQS 政策或 AWS KMS 密钥策略中。本指南不提供有关如何创建 Amazon SQS 队列或密钥的 AWS KMS 说明。有关如何创建这些资源的说明，请参阅[创建 Amazon SQS 队列](creating-sqs-standard-queues.md#step-create-standard-queue)和[创建密钥](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)。 本指南中定义的 Amazon SQS 策略不支持将消息直接重新发送到相同或不同的 Amazon SQS 队列。 ## 最低权限 Amazon SQS 密钥政策 在本节中，我们将介绍 AWS KMS 用于加密 Amazon SQS 队列的客户管理密钥所需的最低权限权限。使用这些权限，您可以将访问权限限制为仅限目标实体，同时实施最低权限。密钥政策必须包含以下策略语句，我们将通过以下资源详细描述这些语句： + [向 AWS KMS 密钥授予管理员权限](#sqs-use-case-kms-admin-permissions) + [授予对密钥元数据的只读访问权限](#sqs-use-case-read-only-permissions) + [授予 Amazon SNS KMS 对 Amazon SNS 向队列发布消息的权限](#sqs-use-case-publish-messages-permissions) + [允许使用者解密来自队列的消息](#sqs-use-case-decrypt-messages-permissions) ### 向 AWS KMS 密钥授予管理员权限 要创建 AWS KMS 密钥，您需要为用于部署密 AWS KMS 钥的 IAM 角色提供 AWS KMS 管理员权限。这些管理员权限在以下 `AllowKeyAdminPermissions` 策略语句中进行了定义。在 AWS KMS 密钥策略中添加此声明时，请务必使用用于部署密钥、管理密 AWS KMS 钥或两者兼而有之的 IAM 角色的 Amazon 资源名称 (ARN) 替换**。 AWS KMS 这可以是您部署管道的 IAM 角色，也可以是 [AWS Organizations](https://aws.amazon.com/organizations/) 中[您组织的管理员角色](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html)。 ``` { "Sid": "AllowKeyAdminPermissions", "Effect": "Allow", "Principal": { "AWS": [ "" ] }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" } ``` **注意** 在 AWS KMS 密钥策略中，`Resource`元素的值必须是`*`，这意味着 “这个 AWS KMS 密钥”。星号 (`*`) 标识 AWS KMS 密钥策略所关联的密钥。 ### 授予对密钥元数据的只读访问权限 要向其他 IAM 角色授予对您密钥元数据的只读访问权限，请将 `AllowReadAccessToKeyMetaData` 语句添加到您的密钥政策中。例如，以下语句允许您列出账户中的所有 AWS KMS 密钥以供审计。此语句授予 AWS 根用户对密钥元数据的只读访问权限。因此，账户中的任何 IAM 主体只要其基于身份的策略具有以下语句中列出的权限，就可以访问密钥元数据：`kms:Describe*`、`kms:Get*` 和 `kms:List*`。请务必**用您自己的信息替换。 ``` { "Sid": "AllowReadAcesssToKeyMetaData", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::root" ] }, "Action": [ "kms:Describe*", "kms:Get*", "kms:List*" ], "Resource": "*" } ``` ### 授予 Amazon SNS KMS 对 Amazon SNS 向队列发布消息的权限 要允许您的 Amazon SNS 主题向加密的 Amazon SQS 队列发布消息，请将 `AllowSNSToSendToSQS` 策略语句添加到您的密钥政策中。此声明授予亚马逊 SNS 使用该 AWS KMS 密钥发布到您的亚马逊 SQS 队列的权限。请务必**用您自己的信息替换。 **注意** 声明`Condition`中的限制只能在同一 AWS 账户中使用 Amazon SNS 服务。 ``` { "Sid": "AllowSNSToSendToSQS", "Effect": "Allow", "Principal": { "Service": [ "sns.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "" } } } ``` ### 允许使用者解密来自队列的消息 以下 `AllowConsumersToReceiveFromTheQueue` 语句向 Amazon SQS 消息使用者授予解密从加密 Amazon SQS 队列收到的消息所需的权限。附加策略声明时，请替换为消息**使用者的 IAM 运行时角色 ARN。 ``` { "Sid": "AllowConsumersToReceiveFromTheQueue", "Effect": "Allow", "Principal": { "AWS": [ "" ] }, "Action": [ "kms:Decrypt" ], "Resource": "*" } ``` ### 最低权限 Amazon SQS 策略 本节将引导您了解本指南所涵盖的使用案例的最低权限 Amazon SQS 队列策略（例如，从 Amazon SNS 到 Amazon SQS）。定义的策略旨在通过混合使用 `Deny` 和 `Allow` 语句来防止意外访问。`Allow` 语句会向目标实体或实体授予访问权限。`Deny` 语句可防止其他意外实体访问 Amazon SQS 队列，同时将目标实体排除在策略条件之外。 Amazon SQS 策略包括以下语句，我们在下面对其进行了详细描述： + [限制 Amazon SQS 管理权限](#sqs-use-case-restrict-permissions) + [限制指定组织的 Amazon SQS 队列操作](#sqs-use-case-restrict-permissions-from-org) + [向使用者授予 Amazon SQS 权限](#sqs-use-grant-consumer-permissions) + [实施传输中加密](#sqs-encryption-in-transit) + [将消息传输限制为特定的 Amazon SNS 主题](#sqs-restrict-transmission-to-topic) + [（可选）将消息接收限制为特定 VPC 端点](#sqs-restrict-message-to-endpoint) ### 限制 Amazon SQS 管理权限 以下 `RestrictAdminQueueActions` 策略语句将 Amazon SQS 管理权限限制为仅限于您用于部署队列、管理队列或两者兼而有之的 IAM 角色。确保将 ** 替换为您自己的信息。指定用于部署 Amazon SQS 队列的 IAM 角色的 ARN，以及ARNs 应具有 Amazon SQS 管理权限的任何管理员角色的 ARN。 ``` { "Sid": "RestrictAdminQueueActions", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:AddPermission", "sqs:DeleteQueue", "sqs:RemovePermission", "sqs:SetQueueAttributes" ], "Resource": "", "Condition": { "StringNotLike": { "aws:PrincipalARN": [ "arn:aws:iam:::role/", "" ] } } } ``` ### 限制指定组织的 Amazon SQS 队列操作 要帮助保护您的 Amazon SQS 资源不被外部访问（由 [AWS 组织](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)外部实体访问），请使用以下语句。此语句会限制您在 `Condition` 中指定的组织访问 Amazon SQS 队列。请务必**替换为用于部署 Amazon SQS 队列的 IAM 角色的 ARN；并使用您的组织 ** ID 替换。 ``` { "Sid": "DenyQueueActionsOutsideOrg", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:AddPermission", "sqs:ChangeMessageVisibility", "sqs:DeleteQueue", "sqs:RemovePermission", "sqs:SetQueueAttributes", "sqs:ReceiveMessage" ], "Resource": "", "Condition": { "StringNotEquals": { "aws:PrincipalOrgID": [ "" ] } } } ``` ### 向使用者授予 Amazon SQS 权限 要接收来自 Amazon SQS 队列的消息，您需要向消息使用者提供必要的权限。以下策略语句会向您指定的使用者授予使用来自 Amazon SQS 队列的消息所需的权限。将该声明添加到您的 Amazon SQS 策略时，请务必**替换为使用者使用的 IAM 运行时角色的 ARN；以及**替换为用于部署 Amazon SQS 队列的 IAM 角色的 ARN。 ``` { "Sid": "AllowConsumersToReceiveFromTheQueue", "Effect": "Allow", "Principal": { "AWS": "" }, "Action": [ "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:ReceiveMessage" ], "Resource": "" } ``` 要防止其他实体接收来自 Amazon SQS 队列的消息，请将 `DenyOtherConsumersFromReceiving` 语句添加到 Amazon SQS 队列策略中。此语句会限制消息仅供您指定的使用者使用，不允许其他使用者访问，即使他们的身份权限会授予他们访问权限，也是如此。请务必**用您自己的信息替换**和。 ``` { "Sid": "DenyOtherConsumersFromReceiving", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:ReceiveMessage" ], "Resource": "", "Condition": { "StringNotLike": { "aws:PrincipalARN": "" } } } ``` ### 实施传输中加密 以下 `DenyUnsecureTransport` 策略语句强制使用者和创建者使用安全通道（TLS 连接）发送和接收来自 Amazon SQS 队列的消息。请务必**替换为用于部署 Amazon SQS 队列的 IAM 角色的 ARN。 ``` { "Sid": "DenyUnsecureTransport", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": [ "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "", "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ``` ### 将消息传输限制为特定的 Amazon SNS 主题 以下 `AllowSNSToSendToTheQueue` 策略语句允许指定的 Amazon SNS 主题向 Amazon SQS 队列发送消息。请务必**替换为用于部署亚马逊 SQS 队列的 IAM 角色的 ARN；**并替换为亚马逊 SNS 主题 ARN。 ``` { "Sid": "AllowSNSToSendToTheQueue", "Effect": "Allow", "Principal": { "Service": "sns.amazonaws.com" }, "Action": "sqs:SendMessage", "Resource": "", "Condition": { "ArnLike": { "aws:SourceArn": "" } } } ``` 以下 `DenyAllProducersExceptSNSFromSending` 策略语句禁止其他创建者向队列发送消息。将 ** 和 ** 替换为您自己的信息。 ``` { "Sid": "DenyAllProducersExceptSNSFromSending", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sqs:SendMessage", "Resource": "", "Condition": { "ArnNotLike": { "aws:SourceArn": "" } } } ``` ### （可选）将消息接收限制为特定 VPC 端点 要限制仅向特定的 [VPC 端点](https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-sqs-vpc-endpoints-aws-privatelink/)发送消息，请在您的 Amazon SQS 队列策略中添加以下策略语句。除非消息来自所需的 VPC 端点，否则此语句可防止消息使用者接收来自队列的消息。**替换为用于部署 Amazon SQS 队列的 IAM 角色的 ARN ** 和 VPC 终端节点的 ID。 ``` { "Sid": "DenyReceivingIfNotThroughVPCE", "Effect": "Deny", "Principal": "*", "Action": [ "sqs:ReceiveMessage" ], "Resource": "", "Condition": { "StringNotEquals": { "aws:sourceVpce": "" } } } ``` ## 死信队列的 Amazon SQS 策略语句 将以下策略语句（由其语句 ID 标识）添加到您的 DLQ 访问策略中： + `RestrictAdminQueueActions` + `DenyQueueActionsOutsideOrg` + `AllowConsumersToReceiveFromTheQueue` + `DenyOtherConsumersFromReceiving` + `DenyUnsecureTransport` 除了将上述策略语句添加到 DLQ 访问策略外，您还应添加一条语句，以限制向 Amazon SQS 队列传输消息，如下一节所述。 ### 限制向 Amazon SQS 队列传输消息 要限制同一账户只能访问 Amazon SQS 队列，请在 DLQ 队列策略中添加以下 `DenyAnyProducersExceptSQS` 策略语句。此语句不会将消息传输限制到特定队列，因为您需要在创建主队列之前部署 DLQ，因此在创建 DLQ 时不会知道 Amazon SQS ARN。如果您需要将访问权限限制为仅一个 Amazon SQS 队列，请在知道时使用您的 Amazon SQS 源队列的 ARN 修改 `Condition` 中的 `aws:SourceArn`。 ``` { "Sid": "DenyAnyProducersExceptSQS", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sqs:SendMessage", "Resource": "", "Condition": { "ArnNotLike": { "aws:SourceArn": "arn:aws:sqs:::*" } } } ``` **重要** 本指南中定义的 Amazon SQS 队列策略不会将 `sqs:PurgeQueue` 操作限制在某个 IAM 角色或多个角色。`sqs:PurgeQueue` 操作允许您删除 Amazon SQS 队列中的所有消息。您也可以使用此操作更改消息格式，而无需替换 Amazon SQS 队列。调试应用程序时，您可以清除 Amazon SQS 队列以删除可能错误的消息。测试应用程序时，您可以通过 Amazon SQS 队列发送大量消息，然后在进入生产环境之前清除队列以重新开始。之所以不将此操作限制为某个角色，是因为在部署 Amazon SQS 队列时可能不知道此角色。您需要将此权限添加到角色基于身份的策略中，才能清除队列。 ## 防范跨服务混淆代理问题 [混淆代理问题](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)是一个安全问题，即没有执行操作权限的实体可能会迫使更具权限的实体执行该操作。为了防止这种情况， AWS 如果您向第三方（称为跨账户）或其他 AWS 服务（称为跨服务）提供对您账户中资源的访问权限，则提供可帮助您保护账户的工具。本节中的策略语句可以帮助您防范跨服务混淆代理问题。 一个服务（呼叫服务）调用另一项服务（所谓的服务)时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为了帮助防范此问题，本文中定义的基于资源的策略使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 和 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) 全局 IAM 条件上下文键。这限制了服务对Organizations中特定资源、特定账户或特定 AWS 组织的权限。 ## 使用 IAM Access Analyzer 查看跨账户访问权限 您可以使用 [AWS IAM Access Analy](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) zer 查看您的 Amazon SQS 队列策略和 AWS KMS 密钥策略，并在亚马逊 SQS 队列或密钥授予外部 AWS KMS 实体访问权限时提醒您。IAM Access Analyzer 帮助标识您组织中的[资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html)和与信任区域之外的实体共享的账户。此信任区域可以是您在启用 IAM Access Analyzer 时指定的 AWS 账户或组织。 AWS IAM Access Analyzer 使用基于逻辑的推理来分析环境中基于资源的策略，从而识别与外部委托人共享的资源。 AWS 对于在您的信任区域外共享的资源的每个实例，Access Analyzer 都会生成一个调查结果。[调查结果](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)包括有关访问权限以及该访问权限授予到的外部主体的信息。您可以查看调查结果，以确定该访问权限是按计划授予且安全，还是计划外的访问权限并存在安全风险。对于任何意外访问，请查看受影响的策略并进行修复。有关 AWS IAM Access Analyzer 如何识别对您的 AWS 资源的意外访问的更多信息，请参阅此[博客文章](https://aws.amazon.com/blogs/aws/identify-unintended-resource-access-with-aws-identity-and-access-management-iam-access-analyzer/)。 有关 AWS IAM 访问分析器的更多信息，请参阅 [AWS IAM 访问分析器文档](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。 # Amazon SQS API 权限：操作和资源参考 在设置 [访问控制](security_iam_service-with-iam.md#access-control) 和编写您可附加到 IAM 身份的权限策略时，可以使用下表作为参考。表格列表每个 Amazon Simple Queue Service 操作、您可以为其授予执行该操作的权限的相应操作，以及您可以为其授予权限的 AWS 资源。 在策略的 `Action` 字段中指定操作，并在策略的 `Resource` 字段中指定资源值。要指定操作，请在 操作名称之前使用 `sqs:` 前缀（例如，`sqs:CreateQueue`）。 目前，Amazon SQS 支持 [IAM 中提供的全局条件上下文键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。 使用滚动条查看表的其余部分。 **Amazon Simple Queue Service API 和操作所需的权限** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-api-permissions-reference.html)