亚马逊云安全实战——用IAM和SCP筑起数据“防窃墙”

2025年，一家知名企业的云环境发生了数据泄露事件：攻击者盗取了运维人员的长期访问密钥，试图将核心数据库中的50万条客户记录导出到外部。幸运的是，他们的安全配置在最后一刻拦下了这次操作——不是因为防火墙有多强，而是因为IMDSv2和SCP在API层面直接拒绝了未经授权的请求-2。

这个故事告诉我们一个道理：即使钥匙被偷了，只要锁够好，小偷也进不去。今天要讲的，就是AWS上一系列可以帮你筑起“防窃墙”的安全实践。

一、多账户架构：把鸡蛋分到不同的篮子里

1.1 为什么需要多账户？

在单个AWS账户中强制实施最小权限极具挑战性。同样，将开发和生产环境放在同一个账户中，会因配额、IAM、网络和性能问题变得异常困难-2。

这就是为什么行业最佳实践是：通过AWS Organizations集中管理多个AWS账户-2。

1.2 多账户的普及程度

根据Datadog 2025年的云安全研究：

至少84% 的组织使用多个AWS账户

86% 的组织有使用AWS Organizations

70% 的组织将其所有AWS账户都纳入了一个AWS组织

74% 的AWS账户是某个AWS组织的一部分-2

二、服务控制策略：为整个组织设定“安全护栏”

当通过AWS Organizations管理多账户环境时，可以使用服务控制策略（SCP）在所有AWS账户中强制实施安全不变量-2。

2.1 什么是SCP？

SCP是一种组织层面的策略，可以限制成员账户中的用户可以执行的操作。注意：SCP不授予权限，它只是定义权限的边界。

2.2 SCP的采用情况

研究发现，在使用AWS Organizations的组织中，40% 利用SCP来保护共享基础设施和成员账户中的“登陆区”，以及CloudTrail和GuardD等安全机制-2。

2.3 实用的SCP示例

禁止关闭CloudTrail：

json

复制下载

{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Deny",      "Action": [        "cloudtrail:DeleteTrail",        "cloudtrail:StopLogging",        "cloudtrail:UpdateTrail"      ],      "Resource": "*"    }  ]}

强制使用IMDSv2：

json

复制下载

{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Deny",      "Action": "ec2:RunInstances",      "Resource": "arn:aws:ec2:*:*:instance/*",      "Condition": {        "StringNotEquals": {          "ec2:MetadataHttpTokens": "required"        }      }    }  ]}

三、数据边界：让凭证泄露的后果最小化

在云环境中，大多数安全漏洞都涉及一组被泄露的云凭证-5。数据边界允许组织通过限制可信身份只能从预期的网络、VPC或子网访问资源，来缓解这一风险-5。

3.1 数据边界的实施方式

在AWS上，可以通过组合使用VPC端点策略、SCP和RCP，结合诸如aws:PrincipalOrgID等全局IAM条件键来实现数据边界-5。

3.2 实施模式示例

确保S3存储桶只能通过VPC端点访问：

json

复制下载

{  "Effect": "Deny",  "Principal": "*",  "Action": "s3:*",  "Resource": "arn:aws:s3:::my-sensitive-bucket/*",  "Condition": {    "StringNotEquals": {      "aws:SourceVpce": "vpce-12345678"    }  }}

确保特定子网中的EC2实例只能向本账户的S3存储桶写入数据，无论其权限如何，以降低数据外泄风险-5。

3.3 采用情况

研究显示，近40% 的组织通过SCP、RCP、VPC端点或S3存储桶策略来使用数据边界-2。最常见的实施方式包括：

S3存储桶策略（32%的组织）：通过aws:SourceAccount条件键确保只有特定AWS账户能访问存储桶

VPC端点策略（13%的组织）：通过aws:PrincipalAccount条件键防止数据被外泄到攻击者控制的AWS账户-2

四、IMDSv2：挡住SSRF攻击的“铁门”

4.1 什么是IMDSv2？

实例元数据服务（IMDS）是EC2实例用来获取配置信息（如IAM角色临时凭证）的端点。IMDSv1容易受到服务端请求伪造（SSRF）攻击，攻击者可诱骗应用服务器访问元数据端点，从而窃取IAM凭证-5。

IMDSv2通过引入“会话控制”机制，要求请求必须携带一个通过PUT请求获取的令牌，有效阻挡了SSRF攻击。

4.2 采用率的变化

好消息是，IMDSv2的采用率正在稳步提升：

然而，数据也显示了一个值得关注的问题：创建超过两年的实例中，只有14%强制启用了IMDSv2，而最近两周创建的实例中这一比例超过50%-2。这说明老实例往往是安全短板。

4.3 如何强制启用IMDSv2？

在启动实例时配置：

bash

复制下载

aws ec2 run-instances \  --image-id ami-0abcdef1234567890 \  --instance-type t3.micro \  --metadata-options HttpTokens=required,HttpEndpoint=enabled

通过SCP强制区域级默认：AWS在2024年推出了在区域级别默认强制IMDSv2的机制-5。

五、消灭长期凭证：告别“永不过期”的钥匙

5.1 长期凭证的风险

长期凭证（如IAM用户的访问密钥）是众多已记录在案的云数据泄露事件的罪魁祸首-5。它们最大的问题是：一旦泄露，除非主动吊销，否则攻击者可以永远使用。

5.2 触目惊心的数据

根据Datadog的研究-2：

59% 的IAM用户拥有活跃超过一年的访问密钥

其中超过一半的凭证在90天内未被使用，暗示着这些风险凭证完全可以被移除

访问密钥超过三年的比例：AWS从21%升至25%，五年以上的从8%升至10%

5.3 如何替代长期凭证？

5.4 主动阻止创建长期凭证

可以使用SCP来阻止创建IAM用户：

json

复制下载

{  "Effect": "Deny",  "Action": "iam:CreateUser",  "Resource": "*"}

5.5 我们的实践

我们每月运行一次IAM凭证报告，识别并删除超过90天未使用的访问密钥。同时，所有开发者都必须通过AWS IAM Identity Center登录，不再使用IAM用户。

六、S3存储桶：别让数据“裸奔”

6.1 一个持续15年的教训

尽管涉及公开云存储的数据泄露事件已经发生了超过15年，但此类事件在2025年仍在继续发生——泄露医疗记录、数据库备份或财务记录-5。

6.2 S3 Block Public Access：最后的防线

AWS提供了S3 Block Public Access功能，可以在存储桶或账户级别阻止过往和未来的S3存储桶被公开-5。

最佳实践：

在账户级别开启此功能

通过组织级SCP限制更改S3 Block Public Access设置-5

通过组织级RCP自动阻止对S3存储桶的未经身份验证的访问

6.3 合法公开场景的处理

当确实需要公开暴露存储桶时（如托管静态网站），更推荐使用Amazon CloudFront作为CDN，而不是直接公开暴露存储桶-5。这既安全又高效。

七、写在最后：安全是一场持久战

两年来，我们逐渐建立起一套可执行、可检查、可改进的安全体系。现在，我们每天做三件事：

看异常：用GuardDuty监控异常活动

查配置：用Security Hub扫描不合规配置

清凭证：定期轮换所有访问密钥

安全不是一劳永逸的工程，而是一场永不停歇的马拉松。但只要掌握了正确的方法，你就能跑得比别人快一点、稳一点。