aws s3仅允许cloudfront访问_【AWS 服务】通过 STS Session Tags 来对 AWS 资源进行更灵活的权限控制...

 

       S3是非常受欢迎的云对象存储，很多客户使用S3来存储他们的用户文件。终端用户可以直接通过HTTP的方式上传和管理在S3中的文件，而不需要经过服务器中转。那么如何限制S3对象的访问权限，让终端用户只有管理自己拥有的文件的权限，是很多客户关心的问题。熟悉AWS会知道，IAM的Policy是用来管理AWS访问权限的，那么如何让Policy更灵活、更动态，可以让获取到的权限凭证可以匹配到单个终端用户的S3文件目录下。

STS 介绍

       用户可以用编程方式调用 AWS Security Token Service (AWS STS) 的API，获取访问AWS资源的临时安全凭证，并将这些凭证下发给终端用户，用于后续终端用户发起访问AWS资源请求时进行身份验证。

       在调用STS API的过程中，STS支持在请求会话(session)中传入的一个或多个tag参数，tag为Key Value的键值对，在IAM Policy中使用变量名${aws:PrincipalTag/Key}，便可在IAM Policy中获取到Value值。通过在STS session中动态地传入变量值，便可以灵活地为不同的S3对象分配权限。

临时安全凭证与长期有效的安全凭证的区别

       熟悉AWS会知道，在AWS IAM中创建User后，会分配一对access key ID和secret access key(以下简称AK/SK)，在AWS CLI和SDK中都需要配置AK/SK，当以编程方式调用API时，会使用AK/SK对请求执行身份验证，这对AK/SK长期有效。

而临时安全凭证，包含AK/SK和Session Token，AK/SK用于标识用户身份，Session Token用于验证凭证的有效性，AK/SK不随User一起存储，而是动态生成，且使用期限有限，可将这些凭证的有效时间配置几分钟到几小时。

这些差异使得可利用临时凭证获得以下优势：

• 不必随应用程序分配或嵌入长期 AWS 安全凭证，降低安全凭证泄露的风险。

• 可允许用户访问您的 AWS 资源，而不必为这些用户定义 AWS 身份。临时凭证是角色和联合身份验证的基础。

• 临时安全凭证的使用期限有限，因此，在不需要这些凭证时不必轮换或显式撤销这些凭证。临时安全凭证到期后无法重复使用。

请求流程

通过STS获取临时安全凭证流程如下图。

1. 终端用户的客户端发出访问请求到服务器端。

2. 服务器端调用STS API，以获取临时安全凭证。

3. STS服务返回临时安全凭证。

4. Server将获取到的临时安全凭证下发给客户端。

5. 客户端使用临时安全凭证来访问AWS资源，本文中是S3桶。

       下面来看下具体如何实现。本文为了方便展示，使用AWS CLI方式来演示整个权限配置和获取的过程，在真实场景中建议在应用中使用AWS SDK代码来实现以上流程。

在AWS云上的配置

在AWS云上创建一个IAM User，名为ServerUser，将其AK/SK配置在服务器端，其至少拥有调用STS AssumeRole操作的权限，如下策略所示。

{    "Version":"2012-10-17",    "Statement":[        {        "Sid":"VisualEditor0",        "Effect":"Allow",        "Action":"sts:AssumeRole",        "Resource":"*"        }    ]

}

       创建一个AssumedRole，其所具有的Policy如下。该Policy中BUCKET和PREFIX根据实际情况填写，用${aws:PrincipalTag/userid}来引用STS Session传入的Tag的key，作为变量，来获取到value值，以匹配上实际的目录。文中使用的key是userid，此Policy限定了每个user只能获取其userid目录下的文件列表，和读写和删除的权限。

{    "Version":"2012-10-17",    "Statement":[        {            "Sid":"ListYourObjects",            "Effect":"Allow",            "Action":"s3:ListBucket",            "Resource":[                "arn:aws:s3:::BUCKET"            ],            "Condition":{                "StringLike":{                    "s3:prefix":[                        "PREFIX/${aws:PrincipalTag/userid}/"                    ]                }            }        },        {            "Sid":"ReadWriteDeleteYourObjects",            "Effect":"Allow",            "Action":[                "s3:GetObject",                "s3:PutObject",                "s3:DeleteObject"            ],            "Resource":[                "arn:aws:s3:::BUCKET/PREFIX/${aws:PrincipalTag/userid}/",                "arn:aws:s3:::BUCKET/PREFIX/${aws:PrincipalTag/userid}/*",            ]        }    ]

}

      修改此AssumedRole的信任关系，如下所示。通过控制台创建的Role的信任关系里的Principal是AWS的服务，在这里需要修改为上一步创建的IAM User，为ServerUser，以信任SeverUser来使用此Role来获取临时凭证。

{    "Version":"2012-10-17",    "Statement":[        {            "Effect":"Allow",            "Principal":{                "AWS":"arn:aws:iam::account-id:user/ServerUser"            },            "Action":[                "sts:AssumeRole",                "sts:TagSession"            ]        }    ]

}

演示

       在服务器端，配置AWS CLI，使用ServerUser的AK/SK对。使用CLI，调用assume-role命令，传入tag，key为userid，value为123456，表明为userid为123456的用户生成临时安全凭证。

aws sts assume-role --role-arn arn:aws:iam::account-id:role/AssumedRole --role-session-name my-session --tags Key=userid,Value=123456 —duration-seconds 1800

{"AssumedRoleUser":{

"AssumedRoleId":"AROA23ZIK3DO7XQDDB4I4:my-session",

"Arn":"arn:aws:sts::account-id:assumed-role/AssumedRole/my-session"

},

"Credentials":{

"SecretAccessKey":"xxxxxxxxxxxxxx",

"SessionToken":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",

"Expiration":"2020-04-10T07:34:12Z",

"AccessKeyId":"xxxxxxxxxxx"

},

"PackedPolicySize":3

}

      在客户端，使用上一步在服务器端获得的userid为123456的临时安全凭证，这里使用CLI export到环境中。

export AWS_ACCESS_KEY_ID=xxxxxxxxxxx export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxx export AWS_SESSION_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

       使用CLI上传一个文件到userid为123456的S3目录下，能够成功。

aws s3 cp ./myfile s3://BUCKET/PREFIX/123456/

       查看此文件家里的目录，可以看到能够返回文件列表。

aws s3 ls s3://BUCKET/PREFIX/123456/

2020-03-2508:02:370 myfile

       尝试查看userid为234567的目录，会返回如下错误。

aws s3 ls s3://xucy-static/app/234567/ An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

       通过STS服务传递session tags实现了终端用户只能管理自己的文件的场景。不难发现，sesstion tags在AWS的权限管理更具灵活性，可基于这些tags来允许或拒绝资源的访问，可将使用场景拓展到别的AWS服务中。

          敏捷云是AWS的全球核心合作伙伴，是一家致力于为企业提供云平台迁移、成本优化、安全合规、托管运维等云端服务的创新型公司。我们将与AWS一起驵中国企业构建理想的云端应该架构，让用户拥有放心安全的云端应用。

文章资料来源AWS官方，由敏捷云编写

图片来自网络，版权归原作者所有

侵删致歉

---

延伸阅读：

【AWS ·创新科技】AWS CloudFront 根据客户端IP做302重定向 【AWS ·创新科技】AWS CloudFront + Lambda@Edge 的切图方案 【AWS ·创新科技】使用AWS Lambda和Amazon Cloudwatch定时重启Instance指南 F5的分布式多云活架构 F5 的公有云WEB安全与合规性 Fortinet SD-WAN的优势与应用场景 Prisma Cloud落地中国，为本土云安全保驾护航 Prisma Cloud商业合规版的功能 【Veeam Backup for AWS】经济高效且安全无忧的 AWS 原生备份 【Veeam Backup & Replication】强大的现代数据保护解决方案         深圳敏捷云计算科技有限公司是一家专注于公有云增值服务的技术创新型公司，为企业客户提供云迁移，培训，开发，安全合规以及运维服务。