Amazon Simple Queue Service
开发人员指南
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。点 击 Getting Started with Amazon AWS to see specific differences applicable to the China (Beijing) Region.

使用 Amazon SQS Access Policy Language创建自定义策略

如果您希望仅根据 AWS 账户 ID 和基本权限 (例如 SendMessageReceiveMessage) 来允许进行 Amazon SQS 访问,则无需自行编写策略。您可以只使用 Amazon SQS AddPermission 操作。

如果您希望基于更具体的条件 (例如,请求到达的时间或请求者的 IP 地址) 来显式拒绝或允许访问,则需要自行编写 Amazon SQS 策略并使用 Amazon SQS SetQueueAttributes 操作将其上传到 AWS 系统。

主要概念

要自行编写策略,您必须熟悉 JSON 和一些关键概念。

允许

效果设为 allowstatement的结果。

操作

委托人拥有权限可以执行的活动,通常是对 AWS 的请求。

默认拒绝

没有允许显式拒绝设置时statement的结果。

条件

有关许可的任何限制或详细信息。典型的条件与日期、时间和 IP 地址相关。

效果

您希望一个策略statement在评估期间返回的结果。您编写策略语句时可以指定 denyallow 值。在策略评估期间有三种可能的结果:默认拒绝允许显式拒绝

显式拒绝

效果设为 denystatement的结果。

评估

Amazon SQS 根据策略确定是否拒绝或允许传入请求的过程。

发布者

编写策略以对资源授予权限的用户。根据定义,发布者一定是资源所有者。AWS 不允许 Amazon SQS 用户为他们不拥有的资源创建策略。

密钥

设置访问限制指定的特性。

许可

使用条件密钥允许或拒绝对资源的访问的概念。

策略

充当一条或多条语句容器的文档。

Amazon SQS 使用策略确定是否授予用户访问资源的权限。

委托人

收到策略许可的用户。

资源

委托人请求访问的对象。

statement

单个权限的正式描述,以access policy language编写,作为更大的策略文档的一部分。

请求者

发送访问资源请求的用户。

架构

下列图表介绍了为您提供 Amazon SQS 资源访问控制的主要组成部分。

 架构概述
1

您,资源所有者。

2

包含在 AWS 服务中的资源 (例如,Amazon SQS 队列)。

3

您的策略。较好的做法是为每个资源提供一个策略。AWS 服务自身提供一个 API,用于上传并管理您的策略。

4

请求者和他们向 AWS 服务传入的请求。

5

access policy language 评估代码。这是 AWS 服务内的一组代码,用于根据适用的策略对传入的请求进行评估并决定是否允许该请求者访问资源。

处理工作流程

下列图表介绍了使用 Amazon SQS access policy language进行访问控制的一般工作流程。

 架构概述

1

您为您的队列编写一个 Amazon SQS 策略。

2

上传您的策略至 AWS。AWS 服务提供一个您用来上传您的策略的 API。例如,您使用 Amazon SQS SetQueueAttributes 操作来为特定的 Amazon SQS 队列上传策略。

3

某人向您发出使用 Amazon SQS 队列的请求。

4

Amazon SQS 检查所有可用的 Amazon SQS 策略并决定哪些策略适用。

5

Amazon SQS 对这些策略进行评估,确定是否允许请求者使用您的队列。

6

根据策略评估结果,Amazon SQS 或者向请求者返回 Access denied 错误消息,或者继续处理该请求。

评估逻辑

在评估期间,Amazon SQS 确定应允许还是拒绝资源所有者以外的某人发送的请求。评估逻辑遵循多个基本规则:

  • 在默认情况下,您拒绝任何人发送的所有使用资源的请求.

  • 允许覆盖任何默认拒绝

  • 显式拒绝覆盖任何允许

  • 策略评估的顺序不重要。

下列图表详细介绍了 Amazon SQS 如何评估有关访问权限的决策。

 架构概述
1

决策开始时为默认拒绝

2

执行代码评估适用于请求的所有策略 (根据资源、委托人、操作和条件)。执行代码评估策略的顺序不重要

3

执行代码寻找适用于请求的显式拒绝指令。即使执行代码只找到了一个,也会返回拒绝决策,整个过程完成。

4

如果没有找到显式拒绝指令,执行代码将寻找适用于请求的任何允许指令。即使执行代码只找到了一个,也会返回允许决策,整个过程完成 (服务将继续处理该请求)。

5

如果没有找到允许指令,最终决策将是拒绝 (因为没有显式拒绝允许,则被视为默认拒绝)。

显式拒绝和默认拒绝之间的关系

如果 Amazon SQS 策略不直接应用于请求,该请求的结果为默认拒绝。例如,如果用户请求使用 Amazon SQS 的权限,但应用于该用户的唯一策略可使用 DynamoDB,则该请求的结果为默认拒绝

如果未能满足语句中的某个条件,则该请求的结果为默认拒绝。如果满足了语句中的所有条件,那么根据策略中效果元素的值,该请求的结果可能为允许显式拒绝。策略不会指定未满足条件时的具体做法,在这种情况下的默认结果为默认拒绝。例如,您想要阻止来自南极洲的请求。您编写了策略 A1,只要请求不是来自于南极洲,就接受请求。下列示意图说明了 Amazon SQS 策略。

 架构概述

如果用户从美国发出请求,那么条件已经满足 (该请求不是来自南极洲),则该请求的结果是允许。但是,如果用户从南极洲发出请求,那么条件未满足,该请求的默认结果为默认拒绝。您可以编写策略 A2,显式拒绝来自南极洲的请求,这样结果就变为显式拒绝。下列示意图说明了该策略。

 架构概述

如果用户从南极洲发出请求,那么条件已经满足,则该请求的结果为显式拒绝

默认拒绝显式拒绝之间的区别很重要,因为允许可以覆盖前者但不能覆盖后者。例如,策略 B 允许在 2010 年 6 月 1 日到达的请求。下图比较了将此策略与策略 A1 和策略 A2 进行组合的情况。

 覆盖

在方案 1 中,策略 A1 的结果为默认拒绝,策略 B 的结果为允许,因为该策略允许 2010 年 6 月 1 日传入的请求。策略 B 的允许结果覆盖了策略 A1 的默认拒绝结果,因此该请求获得允许。

在方案 2 中,策略 A2 的结果为显式拒绝,策略 B 的结果为允许。策略 A2 的显式拒绝结果覆盖了策略 B 的允许结果,因此该请求被拒绝。

Amazon SQS 访问策略示例

下面是典型的 Amazon SQS 访问控制策略的示例。

示例 1:为一个账户授予权限

以下示例 Amazon SQS 策略向 AWS 账户 111122223333 授予权限,使其能够从 AWS 账户 444455556666 所拥有的 queue2 收发请求。

Copy
{ "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 账户在特定时间段内访问您的账户所拥有的队列。需要编写该策略并使用 SetQueueAttributes 将其上传至 Amazon SQS,因为 AddPermission 操作不允许在授予对队列的访问权限时指定时限。

Copy
{ "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:对一个或多个账户授予权限”示例编写:它将访问时间限制在 2009 年 6 月 30 日中午 12 点 (UTC) 之前,将访问 IP 的范围限制在 10.52.176.0/24。需要编写该策略并使用 SetQueueAttributes 将其上传至 Amazon SQS,因为 AddPermission 操作不允许在授予对队列的访问权限时指定 IP 地址限制。

Copy
{ "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": "10.52.176.0/24" } } }] }

示例 4:拒绝特定账户的访问

以下示例 Amazon SQS 策略拒绝特定 AWS 账户对您队列的访问。此示例根据“示例 1:为一个账户授予权限”示例编写:它拒绝指定 AWS 账户的访问。需要编写该策略并使用 SetQueueAttributes 将其上传至 Amazon SQS,因为 AddPermission 操作不允许拒绝访问某一队列 (它仅允许对队列授予访问权限)。

Copy
{ "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" }] }