我有一些敏感的資產（Lambda、S3 存盤桶、IAM...），我想保護以防有人試圖擦除存盤桶策略、洗掉函式或對這些資源造成任何損害。所有這些都被標記為 <<MY_KEY>>:<<MY_VALUE>>。問題是我想在組織級別執行此操作，因為我有多個 AWS 賬戶。我在一個SCP 中使用這個策略。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyActionsOnTaggedResources",
"Effect": "Deny",
"Action": [
"s3:PutBucketPolicy",
"s3:PutBucketTagging",
"s3:DeleteBucketPolicy",
"s3:PutAccessPointPolicyForObjectLambda",
"s3:PutBucketPublicAccessBlock",
"s3:DeleteAccessPointPolicyForObjectLambda",
"s3:PutMultiRegionAccessPointPolicy",
"s3:PutBucketAcl",
"s3:PutBucketPolicy",
"s3:DeleteAccessPointPolicy",
"s3:DeleteBucketPolicy",
"s3:PutAccessPointPolicy",
"s3:BypassGovernanceRetention",
"lambda:DeleteFunction",
"lambda:DeleteCodeSigningConfig",
"lambda:DeleteFunctionCodeSigningConfig",
"lambda:AddLayerVersionPermission",
"lambda:RemoveLayerVersionPermission",
"lambda:EnableReplication",
"lambda:AddPermission",
"lambda:DisableReplication",
"lambda:DeleteLayerVersion",
"lambda:DeleteFunctionEventInvokeConfig",
"lambda:PublishVersion",
"lambda:CreateAlias",
"lambda:RemovePermission",
"iam:DeleteRole",
"iam:DeleteInstanceProfile",
"iam:DeletePolicy",
"iam:DeleteRolePolicy",
"iam:DeleteUserPolicy",
"iam:DeleteGroupPolicy",
"iam:UpdateAssumeRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:DeleteRolePermissionsBoundary",
"iam:CreatePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/<<MY_KEY>>": "<<MY_VALUE>>"
},
"StringNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/<<MY_ROLE>>"
]
}
}
}
]
}
為了測驗，每當我放置一個不是我角色的角色時，我仍然可以修改資源。我的錯誤在哪里？
uj5u.com熱心網友回復：
你可以修改這個StringNotEquals來StringNotLike和嘗試？當您*在 Condition中使用通配符 ( ) 時，StringNotEquals將不起作用。其余的政策看起來很合理。
字串條件運算子
我還建議使用訪問分析器來驗證策略。這將在構建策略時捕獲類似的錯誤。請參閱訪問分析器。
uj5u.com熱心網友回復：
事實證明@John Rotenstein 是對的。S3 API 呼叫不支持 ResourceTag 作為條件。
由于這是作業中的緊急需求，我最終在 AWS 開設了一個支持案例，他們回復如下：
I understand you trying to restrict actions on an S3 bucket using the ResourceTag condition key.
Unfortunately, you cannot currently use the AWS:ResourceTag condition key to control access to the s3 bucket, please refer the following documentation[1]. In the documentation, you can see that only the resource type that currently supports the aws:ResourceTag condition key is "storagelensconfiguration". There is an existing feature request with the s3 service team to add support for the AWS:ResourceTag condition key which I have 1'd on your behalf. I am unable to provide an ETA for when the feature might get released since I have no visibility over the processes of the service team. However, all new feature announcements will be made available on our What's new with AWS page[2].
When it comes to controlling access to s3 with the use of tags, we do have the examples in the following AWS Documentation[3] which uses the tags applied to specific objects to control access. It makes use of the condition keys, s3:ExistingObjectTag/<tag-key>, s3:RequestObjectTagKeys and s3:RequestObjectTag/<tag-key> to control access to certain S3 actions however it requires the individual objects to be tagged, it will not work with tags at the bucket level. I would suggest reading through the above linked documentation[3] and see if the solution described in it will meet your organizations needs.
I hope you find the above information helpful, please let me know if you have any additional questions.
[1] Actions, resources, and condition keys for Amazon S3 - https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html
[2] What's New with AWS? - https://aws.amazon.com/new/
[3] Tagging and access control policies - https://docs.aws.amazon.com/AmazonS3/latest/userguide/tagging-and-policies.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/354345.html
標籤：亚马逊网络服务 亚马逊-s3 aws-lambda 亚马逊