如何在不使用"Principal":"*"时,通过S3 VPC端点安全访问AWS补丁托管桶?
问题背景
我正尝试让私有子网内的EC2实例通过S3 VPC端点(com.amazonaws.<region>.s3)安全访问AWS用于补丁的托管S3桶(如aws-ssm-*、amazonlinux-*等)。
现状
- 实例位于私有子网,计划通过S3 VPC端点访问S3以规避NAT网关;
- 受安全团队(CrowdStrike策略要求)限制,任何策略中不得使用
"Principal":"*"。
遇到的问题
- 只有在VPC端点策略中使用
"Principal":"*"时,补丁功能才能正常工作; - 尝试替换为EC2实例的IAM角色,或添加
"Service":"ec2.amazonaws.com"、"ssm.amazonaws.com"作为主体后,功能失效; - 推测访问AWS公有托管桶的请求为未签名HTTP请求,无IAM主体可匹配,仅
"Principal":"*"生效。
当前可行的简化版策略
{ "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": [ "arn:aws:s3:::aws-ssm-*", "arn:aws:s3:::patch-baseline-*", "arn:aws:s3:::aws-patchmanager-*", "arn:aws:s3:::amazonlinux*" ], "Condition": { "StringEquals": { "aws:SourceVpc": "vpc-xxxxxxxx" } } }
疑问
- 这属于AWS预期行为吗?
- 是否存在安全可行的替代方案(如可用的主体)?
- 使用带严格条件(如
aws:SourceVpc)的"Principal":"*"是通过VPC端点访问AWS托管桶的唯一可行方式吗? - 是否可以跳过S3 VPC端点,改用NAT网关路由S3流量?原因是什么?
需要AWS文档参考或实践经验,以便向合规团队提供合理说明。
解答
1. 属于AWS预期行为
是的,这是AWS的预期设计。AWS托管的S3桶(比如SSM补丁、Amazon Linux镜像桶)的部分访问请求是未签名的HTTP请求——例如Amazon Linux的yum工具拉取补丁时默认不会用IAM签名,SSM Agent获取部分补丁元数据时也可能发起未签名请求。这类请求不携带IAM主体信息,VPC端点策略指定具体IAM角色或服务主体时无法匹配,只有"Principal":"*"能放行。
AWS官方文档明确说明:对于未签名的S3请求,VPC端点策略必须使用"Principal":"*",同时通过aws:SourceVpc、aws:SourceIp等条件限制访问范围,确保安全性。
2. 目前无更优的主体替代方案
指定EC2实例角色、ec2.amazonaws.com或ssm.amazonaws.com作为主体失效的原因:
- EC2实例角色仅适用于签名请求,未签名请求不会携带角色信息;
ec2.amazonaws.com是EC2服务的主体,仅匹配EC2服务发起的请求,而补丁请求是实例上的进程(yum、SSM Agent)发起的,不属于该主体范围;ssm.amazonaws.com同理,仅匹配SSM服务本身的请求,不匹配实例上SSM Agent发起的请求。
目前没有其他可用主体能覆盖未签名请求的场景。
3. 带严格条件的"Principal":"*"是当前唯一可行方式
结合aws:SourceVpc条件的"Principal":"*"是合规且安全的方案:
- 条件限制请求只能来自指定VPC,外部流量无法通过该端点访问目标桶;
- 资源范围已限定为特定的AWS托管补丁桶,不会开放所有S3资源;
AWS文档将这种方式列为访问托管S3桶的推荐安全实践,因为条件能有效缩小访问范围,抵消"Principal":"*"的宽泛性。
4. 可以改用NAT网关路由S3流量,但有明显弊端
可以跳过S3 VPC端点,用NAT网关转发S3流量,但存在以下问题:
- 成本更高:NAT网关按小时和数据流量收费,而S3 VPC端点免费;
- 安全性降低:流量会通过公网路径传输(即使AWS内部是私有骨干,逻辑上仍属于公网暴露),而VPC端点是完全在VPC内部的私有连接,避免了公网暴露风险;
- 合规性问题:部分合规要求禁止通过公网访问内部资源,VPC端点更符合私有访问的合规标准。
如果必须规避"Principal":"*",这是一个备选,但不推荐。
内容的提问来源于stack exchange,提问作者Anton
相关产品推荐
相关产品推荐

