在 文档的另一部分 AWS 提供了一些有关 Sid 用途的附加信息:
(语句 ID)是您为策略语句提供的可选标识符。您可以为语句数组中的每个语句分配一个Sid
值。在允许您指定Sid
元素的服务(例如 SQS 和 SNS)中,ID
值只是策略文档 ID 的子 ID。在 IAM 中,Sid
值在 JSON 策略中必须是唯一的。Sid
所以是的,这只是一个描述。
您可以使用
Sid
来引用长保单中的特定声明
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAll",
"Effect": "Allow",
"Action": "*",
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "DenyList",
"Effect": "Deny",
"Action": "s3:List*",
"Resource": "arn:aws:s3:::*"
}
]
}
例如,在解释策略时,您可以说
AllowAll
语句允许所有S3操作,但DenyList
拒绝所有列表操作。想象一下,如果那些 Sids 不存在,您会如何称呼他们中的任何一个?
这可能是语义上的挑剔,但我不同意它“只是一个描述”,因为描述不必是唯一的。另外 Sid 不支持空格,所以它实际上只是一个 ID。
更新:引用AWS文档
某些 AWS 服务(例如,Amazon SQS 或 Amazon SNS)可能需要此元素并对其有唯一性要求。
我认为“仅仅描述”不足以描述 Sid 的含义。
我认为更好的问题是:“我如何利用 Sid 来发挥我的优势?”
这是一个例子:
示例:您有 1k 个策略,并且想要查找执行“S3DenyPublicReadACL”的策略。也许您将该策略存储在 s3 存储桶中,以便您可以重复使用它。
解决方案:编写一个脚本/lambda,找到它并以自动方式重用它。