出海企业多云安全架构：AWS EC2 与阿里云攻击面对比与防御实战

出海企业多云安全架构：AWS EC2 与阿里云攻击面对比与防御实战

Photo by panumas nikhomkhai on Pexels

刚搭建完第二朵云，你发现真正的难题才刚刚开始。多云架构上线第一天，团队通常会面临一个比"选哪家云"更难回答的问题：安全模型不统一、身份权限各自为政、日志散落在不同控制台，运维压力翻倍增长。更要命的是，每朵云都有自己独特的攻击面——如果把"安全"等同于"买防火墙"，迟早会在某个你没留意的角落里踩中真实威胁。

这篇文章从威胁建模的底层逻辑出发，对比 AWS EC2 与阿里云两套主流 IaaS 的攻击面差异，拆解各自的核心控制项，并给出可直接落地的多云安全架构建议。

AWS EC2 的四层攻击面与关键控制

AWS EC2 的安全边界不是一台虚拟机那么简单。从攻击者视角看，EC2 实例有四个需要单独管理的层次。

实例层指的是操作系统、应用和监听端口本身。攻击者通过暴露的 Web 应用漏洞、弱口令或未修补的系统漏洞进入实例，这是最直观的一层，也最容易被忽视——补丁管理稍有不慎，整个实例就成了入口。

IAM 与凭据层是 EC2 安全里最容易被低估的部分。附加到实例的 Instance Profile（相当于 IAM Role）决定了该实例能调用哪些 AWS API，而实例元数据服务 IMDS（Instance Metadata Service）则是获取凭据的直接通道。这里有个关键细节：IMDSv1 与 IMDSv2 的区别。IMDSv1 只要一个 HTTP 请求就能拿到 IAM 凭据，SSRF 攻击可以直接利用；IMDSv2 要求先用 PUT 请求获取 session token，大幅提升了攻击门槛。AWS 对新实例默认启用 IMDSv2，但老账户里的旧实例很可能仍在用 IMDSv1，需要主动审计。

网络层包括实例级别的有状态防火墙 Security Group、子网级别的无状态防火墙 NACL，以及 VPC Flow Log 记录的流量日志。Security Group 默认允许出站、拒绝入站，配置逻辑与传统防火墙有差异，第一次接触的团队容易弄反。

AMI 与镜像层决定了实例从启动那一刻起就带有哪些已知漏洞。使用来源不明的 AMI，等于在实例启动前就已经埋下了隐患。

这四层中，IMDSv2 的推广是最具杠杆效应的单点修复——2019 年 Capital One 的数据泄露事件，正是通过 EC2 上的 SSRF 漏洞搭配 IMDSv1 提取 IAM 凭据造成的，涉案数据超过 1 亿条。对出海企业而言，这不是一个可以靠"买防火墙"来回避的问题。

Photo by Aleksander Dumała on Pexels

阿里云的攻击面：RAM、堡垒机与数据驻留

阿里云的计算服务（ECS）与 AWS EC2 定位相近，但安全模型的设计哲学有明显差异，理解这些差异是多云安全架构的前提。

**RAM（资源访问管理）**是阿里云的 IAM 等价物，但实现细节不同。RAM 用户可以绑定多个权限策略，支持临时的安全令牌（STS Token），同样遵循最小权限原则。关键区别在于：RAM 的权限传递链路比 AWS IAM 稍长，角色嵌套层数多时容易出现权限扩散（Privilege Creep）。定期运行 ram list-roles 并撤销未使用的自定义策略，是保持 RAM 健康度的有效手段。

堡垒机与运维通道是阿里云安全的另一层特色。阿里云原生提供运维安全中心（OOS 自动化）与云盾堡垒机等服务，用于管理服务器登录审批、命令录制和高危操作审计。对金融、医疗或涉及 GDPR 合规的出海业务来说，这套机制比 AWS Systems Manager 的开环设计更符合国内监管审美。

数据驻留与跨境传输是出海东南亚企业必须面对的现实约束。阿里云在新加坡（ap-southeast-1）、吉隆坡等地设有 Region，但部分服务的备份节点仍在境内。这与 AWS 跨 Region 复制逻辑不同——如果业务对数据主权有严格要求，选择阿里云时需要逐服务确认数据物理位置，并在合同层面落实数据处理协议（DPA）。

PDPA 合规下的日志保留与跨云统一监控

在新加坡 Region 部署工作负载，PDPA（个人数据保护法）对日志保留有明确要求：CloudWatch Logs 至少保留 12 个月，且日志内容如涉及个人数据处理，需证明访问控制已到位。这对多云架构提出一个常被低估的挑战：AWS 有 CloudWatch，阿里云有 ActionTrail 与 SLS（日志服务），GCP 有 Cloud Logging——三个平台的日志格式、保留策略和告警阈值各不相同，如果各自为政，合规审计将是一场噩梦。

实际可行的方案是选定一个统一的 SIEM 平台作为中央日志湖，所有云厂商的日志统一转发至此。Grafana+Loki 是开源方案里最常见的组合，也可以用阿里云日志服务的合规版做跨云聚合。关键不在工具，在于日志 schema 的标准化——在架构设计阶段就把这个坑填上，比上线后再补要便宜十倍。

同样重要的是 GuardDuty 的覆盖范围。启用了 GuardDuty 但只覆盖部分 Region，等于在未启用区域留了一个盲区。正确做法是确认所有活跃 Region 都纳入 GuardDuty 监控范围，且 VPC Flow Log 输出到独立的安全账户，防止主账户被攻破后攻击者同步删除日志。

Photo by Henri Mathieu-Saint-Laurent on Pexels

多云安全架构的四个核心实践

把上面讨论的差异整合成可落地的架构，有四个实践是出海企业必须优先落地的。

**统一身份与零信任架构。**不要依赖各云厂商的原生 IAM 做跨云统一身份。推荐方案是以 Okta 或 Azure AD 作为身份提供者（IdP），通过 SAML/OIDC 联邦登录各云平台控制台，消除跨平台多套账号的风险。Zero Trust 的核心原则是"永不信任，始终验证"——即使流量来自内网，所有访问请求都应通过身份验证与设备合规检查。

**网络分段与微分段。**VPC 设计要避免"一个子网走天下"的懒人架构。按工作负载性质（数据库、应用、缓存）分 Subnet，配合安全组白名单策略，是 AWS 与阿里云通用的基础实践。微分段进一步将控制粒度下沉到单实例级别，是应对横向渗透的关键手段。

**密钥管理与 BYOK 策略。**无论 AWS KMS 还是阿里云密钥管理服务（KMS），都强烈建议使用 BYOK（Bring Your Own Key）模式——密钥在客户侧生成和管理，云厂商仅在授权下使用密钥进行加解密操作，并提供完整的使用审计日志。这是对抗"云厂商内部人员滥用权限"这一法律层风险的技术手段，是出海合规的标配。

**定期渗透测试与威胁演练。**每年至少一次由专业团队执行白盒或黑盒渗透测试，覆盖所有云环境。测试报告不仅用于发现漏洞，更重要的是验证告警响应链路是否顺畅——很多团队在测试后才发现，告警能发出来，但 24/7 SOC 没有人真正去看。

总结：多云安全是架构决策，不是买产品的决策

多云架构的真正挑战，从来不在于"买了哪家的服务"，而在于团队能否在差异化的安全模型之间建立统一的治理视角。AWS EC2 的 IMDS 防御、阿里云 RAM 的权限健康度、GCP 的项目层级权限——每一朵云都有自己的攻防逻辑，没有银弹可以一次性解决所有问题。

建立可落地的多云安全架构，需要技术团队与专业 MSP 协同：架构设计与威胁模型由内部安全团队主导，日常监控、事件响应与合规报告可以交给持有 APN Security 认证的 Agilewing MSS 团队承接，让团队把精力放在产品本身而非基础设施的持续运营上。

如果您正在规划东南亚多云架构，或希望对现有云环境做一次完整的安全评估，欢迎与 Agilewing 顾问团队直接沟通，获取针对您业务场景的专属方案。