Question

我想限制我的角色，使其不能写入其他帐户中未经授权的存储桶。例如，我将在帐户A中具有角色A。在帐户B中创建了S3存储桶B，并具有一个存储桶策略，允许角色A对其进行写入。我需要有关角色A /帐户A的策略，以防止角色A能够写入存储桶B。

这可能吗？

Answer 1

默认情况下，存储桶是私有的。但是，如果您已经有一个存储桶策略，允许帐户A中的角色对其进行写操作并且不想检查该策略，则可以添加 明确拒绝。

拒绝将禁止s3::PutObject进入存储桶及其对象。这because有效：

在任何这些政策中，
显式拒绝 将覆盖。

以下是可以添加到帐户A中的角色的此类策略的示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "deny-puts-to-bucket-in-acc-b",
            "Effect": "Deny",
            "Action": "s3:PutObject",
            "Resource": [
                 "arn:aws:s3:::<bucket-from-account-B>/*",
             ]
        }
    ]
}

这仅拒绝PutObject。您可能还会考虑其他操作，例如PutObjectAcl或存储桶本身的操作等等。

尽管如此，上述政策应该是一个好的开始，以使其适合您的特定要求。

Answer 2

（从IAM策略的角度来看！）最简单的（）方法是使用访问点，同时最大程度地避免忽略某些内容并引入潜在的安全问题的风险。

您可以创建访问点并将它们与存储桶关联。然后，您不尝试直接与存储桶进行交互，而是与访问点进行交互。

之所以可以为您提供帮助，是因为有一个IAM策略条件密钥可用于测试拥有访问点的帐户ID。然后，您只需要在IAM角色的策略中添加一条语句，当请求符合测试"Effect": "Deny"的条件时，该语句将在所有资源上"StringNotEquals": { "s3:DataAccessPointAccount": "YOUR_ACCT_NUMBER" }进行所有S3动作。

请注意，如果不通过访问点，将无法访问任何S3资源。因此，这将增加您的初始设置复杂性（以及创建新存储桶的复杂性，因为现在您还需要创建和关联访问点）。与S3交互也将变得更加复杂，因为您现在始终需要通过访问点。

如果要实现这样的解决方案，则需要权衡取舍。但是这将实现您的目标：该IAM角色不可能在您帐户之外访问S3存储桶。

以下是该政策的样子（针对您的特定需求）：

{ "Version": "2012-10-17", "Statement": [ { "Sid": "denyWithoutAccessPoint", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:DataAccessPointAccount": "YOUR_AWS_ACCT_ID" } } } ] }

请记住，您还需要Allow所有需要的操作。

如果这种折衷方案（与更复杂的S3交互以实现完全简单的IAM策略）对您不起作用，那么您将需要一些不同的东西。

请记住，总是需要权衡。

替代1

@Marcin描述的另一种可能性是：明确拒绝访问其他帐户中的这些存储桶。

但是，这里的权衡是 您永远不会知道 什么是S3存储桶，它们是其他AWS账户拥有的所有，该访问权限授予了您的IAM角色的访问权限。

因此，您只能拒绝访问您知道的存储桶。

在威胁模型中，攻击者希望从您的帐户中窃取数据，他们可以创建一个您不知道的新存储区，并通过存储区策略授予对IAM角色的访问权限在该新存储桶上，然后以某种方式使角色写入该新创建的存储桶。

好处：您的应用程序使用S3的方式没有变化。

缺点：可能的攻击情形，因为您无法从其他帐户中了解允许访问您角色的其他存储桶的完整列表（即，您将“主动”阻止访问，即仅之后< / em>可能已经发生了不好的事情。

替代2

另一种替代方法是您创建一个IAM策略，该策略明确拒绝访问 该策略中未枚举的所有存储桶 。 >
要实现此“否定列表”，请使用NotResource，而不是更常见的Resource策略元素。

以下是该政策的样子：

{ "Version": "2012-10-17", "Statement": [ { "Sid": "denyWithoutAccessPoint", "Effect": "Deny", "Action": "s3:*", "NotResource": [ "arn:aws:s3:::my-bucket-1", "arn:aws:s3:::my-bucket-1/*", "arn:aws:s3:::my-bucket-2", "arn:aws:s3:::my-bucket-2/*" ] } ] }

再次，与该答案中的其他示例策略一样，请记住，您仍然需要显式允许操作。

好处：您无需更改与S3交互的方式，也不必知道其他帐户中允许访问您的IAM角色的所有存储桶的名称。

缺点：您需要维护这个不断增长的存储桶列表。另外，请记住，最终可能会达到最大策略大小，从而使此解决方案的规模受到限制（尽管可能会增长很多）。

限制角色的S3写权限

2 个答案: