简体   繁体   English

AWS 默认访问策略 SNS 主题和 SQS q

[英]AWS default Access Policy SNS topics and SQS q's

In an attempt to further tighten the security of our solution we are now looking at the used SNS topics and SQS queues.为了进一步加强我们解决方案的安全性,我们现在正在查看使用的 SNS 主题和 SQS 队列。 All our components live in the same AWS account.我们所有的组件都位于同一个 AWS 账户中。

For starters we want to restrict the access to the SQS queues based on IP.对于初学者,我们希望限制对基于 IP 的 SQS 队列的访问。 So only requests coming from our NAT Gateway IP will be allowed.所以只允许来自我们的 NAT 网关 IP 的请求。 We don't allow anonymous access to our SQS queues.我们不允许匿名访问我们的 SQS 队列。

But there seems no way to achieve this as the creator of the SQS queues - the AWS account id - has access per default.但似乎没有办法实现这一点,因为 SQS 队列的创建者 - AWS 账户 ID - 默认具有访问权限。 So you can't create an effective permission for another user in the same AWS account id.因此,您无法为同一 AWS 账户 ID 中的其他用户创建有效权限。 As this newly created user, user2, will fall under the same AWS account id, with the same set of permissions.由于这个新创建的用户 user2 将属于相同的 AWS 账户 ID,并具有相同的权限集。

Am I correct in my understanding that all users in the same AWS account id have access per default to all created SQS queues as long as their IAM policy permits it?我是否正确理解,只要 IAM 策略允许,同一 AWS 账户 ID 中的所有用户默认都可以访问所有创建的 SQS 队列? And is my assumption right that the same behavior goes for the SNS topics?我的假设是否正确,SNS 主题也有同样的行为?

Below is the policy I would like the implement.以下是我想要实施的政策。 Beside this policy I have no other policies active for this SQS q.除了这个政策,我没有其他适用于此 SQS q 的政策。 But it is not honoring the source IP condition.但它不尊重源 IP 条件。 I still can connect from everywhere when I use a correct AWS access key/secret combination.当我使用正确的 AWS 访问密钥/秘密组合时,我仍然可以从任何地方连接。 Only when I set the AWS principal to * - everyone - the policy seems effective.仅当我将 AWS 委托人设置为 * - 每个人时,该策略似乎才有效。

{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:eu-west-1:4564645646464564:madcowtestqueue/SQSDefaultPolicy",
  "Statement": [
    {
      "Sid": "Sid1589365989662",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::4564645646464564:user/user2"
      },
      "Action": [
        "SQS:DeleteMessage",
        "SQS:SendMessage",
        "SQS:ReceiveMessage"
      ],
      "Resource": "arn:aws:sqs:eu-west-1:143631359317:madcowtestqueue",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "1.1.1.1"
        }
      }
    }
  ]
}

Reference:参考:

Amazon SQS亚马逊 SQS

Amazon SQS has the ability to define Amazon SQS policies . Amazon SQS 能够定义Amazon SQS 策略 These policies can be used in addition to IAM policies to grant access to a queue.除了IAM 策略之外,还可以使用这些策略来授予对队列的访问权限。

For example, a policy can be added that permits anonymous access to a queue, which is useful for external applications to send messages to the queue.例如,可以添加允许匿名访问队列的策略,这对于外部应用程序向队列发送消息很有用。

Interestingly, these policies can also be used to control access to the queue by IP address .有趣的是,这些策略还可以通过 IP 地址来控制对队列的访问

To test this, I did the following:为了测试这一点,我做了以下事情:

  • Created an Amazon SQS queue创建了一个 Amazon SQS 队列
  • Used an Amazon EC2 instance to send a message to the queue -- Successful使用 Amazon EC2 实例向队列发送消息 --成功
  • Added the following policy to the SQS queue:向 SQS 队列添加了以下策略:
{
  "Version": "2012-10-17",
  "Id": "Queue1_Policy_UUID",
  "Statement": [
    {
      "Sid": "Queue1_AnonymousAccess_AllActions_IPLimit_Deny",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:ap-southeast-2:xxx:queue",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "54.1.2.3/32"
        }
      }
    }
  ]
}

The IP address is that of my Amazon EC2 instance. IP 地址是我的 Amazon EC2 实例的地址。

  • I then tried send a message to the queue again from the EC2 instance -- Successful然后我尝试再次从 EC2 实例向队列发送消息——成功
  • I then ran the identical command from my own computer -- Not successful然后我从自己的计算机上运行了相同的命令——不成功

Therefore, it would appear that the SQS policy can override the permissions granted via IAM.因此,SQS 策略似乎可以覆盖通过 IAM 授予的权限。

(Be careful... I added a policy that Denied sqs:* on the queue, and I wasn't able to edit the policy or delete the queue. I had to use the root account to delete it.) (小心……我在队列上添加了拒绝sqs:*的策略,但我无法编辑策略或删除队列。我不得不使用 root 帐户将其删除。)

Amazon SNS亚马逊社交网络

I managed to achieve the same result with Amazon SNS using this access policy :使用此访问策略,我设法通过 Amazon SNS 实现了相同的结果:

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__default_statement_ID",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:ap-southeast-2:xxx:topic",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "54.1.2.3/32"
        }
      }
    }
  ]
}

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM