2025-12-27 01:55:52 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文深度对比AWS、Azure和GCP的防御机制差异，指出多云安全需针对各平台原生特性设计策略。AWS侧重请求时评估，Azure强调身份治理，GCP以边界隔离为核心。通过MFA及网络策略实例，文章强调现代工具无法替代原生架构设计，建议精通各平台逻辑以构建一致的预防性防御体系，有效控制风险。 综合评分： 90 文章分类： 云安全,安全建设,解决方案

cover_image

三大云平台防御机制深度对比

Dubito

云原生安全指北

2025年12月26日 08:35 江苏

注：本文翻译自 Blast Security – Roi Panai 的文章《Deep Technical Guide: How Cloud Defense Strategies Differ Across AWS, Azure, and GCP》[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

一、引言：多云已成常态，其安全则并非易事

如今，大多数现代组织都在多个云服务提供商上运营。这并非偶然——这是云原生业务的新常态，它需要一个多云安全策略。其动机明确且合理：

• 利用每个提供商独特的技术优势（例如，AWS 的规模、Azure 的企业身份管理、GCP 的 AI/ML 能力）
• 减少供应商锁定，增加设计灵活性
• 收购公司后整合新的云环境
• 在多个云之上构建弹性和可用性架构

工程团队拥抱多云[2]，因为它扩展了选择范围。

但对安全团队而言，它带来了一个与云时代之前截然不同的架构挑战：

如何在行为模式迥异的云提供商之间，保持一贯的强大、预防性安全？

每个云都有其独特的身份模型、网络架构、边界定义、防护机制、策略语言和运行时评估逻辑。

一个在 AWS 中微不足道的控制项，在 Azure 中可能需要完全不同的控制平面，或者在 GCP 中需要组织级别的约束。

而攻击者只需要找到一个薄弱环节——那个组织投入最少关注、专业水平最低或控制措施应用不当的云。

在多云环境中，最薄弱的云成为攻击者最容易的切入点——而跨越多个云扩展的爆炸半径[3]往往会将一次事件演变成一场危机。

二、多云安全挑战：目标一致，现实各异

安全目标通常很容易阐述：最小化暴露面、执行强身份验证、隔离环境、限制出站互联网访问、防止权限提升，以及确保工作负载在私有网络中运行。

但在多个云平台上实现这些目标却远非易事。

在 AWS 中只需一个 IAM 条件就能实现的功能，在 Azure 中可能需要一条条件访问（Conditional Access）规则，而在 GCP 中则可能需要结合服务账户作用域限制和组织约束。

架构概念并非 1:1 直接对应——你必须对同一个安全目标进行三次不同的重新思考。

这种不一致性导致了运营偏差。

安全团队可能在某个云上具备深厚专业知识，但对其他云的保护则较为薄弱。

攻击者正利用这种不对称性：先攻破一个使用较少的云账户，获取凭证，然后转向 AWS、Azure 或 GCP 中更具价值的资产。

安全工程变得更加困难，因为每个云都在快速且独立地演进。

Azure 加强了基于身份的条件，AWS 新增了 IAM 密钥和 SCP 能力，而 GCP 则在发展 VPC 服务控制。

团队必须不断地重新学习，而不仅仅是重新配置。

最终，要实现一致的多云[4]防御，需要精通每一个云，而不仅仅是一份通用策略的检查清单。

三、实际用例：目标相同，实现工作迥异

以下是三个真实用例，展示了同一个安全要求在不同提供商间的巨大差异。

它们说明了为何多云防御需要针对特定云的专业知识。

3.1 强制为控制平面操作启用MFA（AWS vs. Azure）

AWS —— MFA 按请求评估

AWS 策略允许你使用 IAM 条件来强制 MFA，例如：

"Condition":&nbsp;{&nbsp;"Bool":&nbsp;{&nbsp;"aws:MultiFactorAuthPresent":&nbsp;"true"&nbsp;}&nbsp;}

这是在运行时针对每个 API 调用进行评估。如果缺少 MFA，每次独立操作都会立即失败。

Azure —— MFA 在身份验证时强制执行

你通过 Entra ID 中的条件访问来强制 MFA。

一旦用户成功认证，Azure 并不会在每次请求时重新检查 MFA。

RBAC 根据已认证的令牌来授权操作。

➡️ 安全意图相同，但执行层面根本不同。

AWS 在请求时评估；Azure 在登录时评估[5]。

3.2 限制出站互联网访问（AWS vs. GCP）

AWS —— 互联网出站默认允许，除非你限制它。

在默认 VPC 设置中，互联网出站是允许的。用户必须显式地拒绝或限制出口。

默认态势是宽松的。

GCP —— 互联网出站默认拒绝，除非你允许它。

Compute Engine 实例默认无法访问互联网，除非你为其附加公网 IP 或创建 Cloud NAT。

默认态势是限制性的。

➡️ AWS 需要显式限制；GCP 需要显式允许。

一个对称的安全目标，以相反的方向实现。

3.3 防止数据泄露（Azure vs. GCP）

GCP —— VPC 服务控制按 API 调用评估。

Google 托管的服务（Storage、BigQuery、Pub/Sub 等）被包裹在一个服务边界（service perimeter）内。如果请求来自该边界之外，即使令牌有效且 IAM 授权，Google 也会阻止该请求。

Azure —— 网络安全边界在网络边界处评估。

网络边界与受支持的 PaaS 资源相关联；在强制执行模式下，除非规则明确允许，否则默认拒绝公共入口/出口流量。

➡️ 安全意图相同，执行层面不同。GCP 阻止边界外的 API 访问；Azure 阻止通往边界的公共网络路径。

四、各云的防御策略

以下是每个云的完整防御理念，图表已直接添加至各部分。

4.1 AWS：细粒度、运行时执行

AWS 围绕请求时安全构建。

每个 API 调用都通过 IAM → SCP → 权限边界 → 资源策略 → 服务逻辑进行评估。

这提供了极大的灵活性：

基于标签的访问控制、会话策略、VPC 条件、身份联合以及高度精细的权限。

但灵活性也带来了复杂性。

IAM 策略重叠、多账户结构以及未对齐的 SCP 可能破坏工作负载或打开攻击路径。

AWS 默认不包含租户范围内的 SSO；身份中心或外部身份提供商（IdPs）提供了这一层。

AWS 擅长运行时预防性防护措施[6]——各种预防性控制和 IAM 条件在操作发生时强制执行安全。

AWS 请求评估流程示例
调用者 → STS → RCPs → SCPs → 基于资源的策略 → IAM 策略 → 权限边界 → 会话策略 → 服务 API

4.2 Azure：身份优先，治理为重

Azure 的理念是身份和治理高于一切。

Entra ID 是整个租户中强制性的身份层。

条件访问在登录时而非每次请求时强制执行安全态势。

RBAC 是分层的：

管理组→订阅→资源组→资源。

Azure 还在实体权限之上增加了身份验证和资源的安全层：

Azure Policy 侧重于资源状态。

它在确保配置合规性和修复漂移方面功能强大，同时兼具运行时和部署前的控制措施。

Azure Entra ID 中的控制项（如条件访问和持续评估）为身份验证而非角色权限增加了额外的验证措施，例如 MFA 和网络限制。

Azure 在集中化、结构化的企业治理方面表现出色。

Azure 身份与授权流程示例
用户尝试身份验证 → 条件访问 → 身份验证令牌 → RBAC 检查 → ARM → 操作

4.3 GCP：以边界为中心，由服务账户驱动

GCP 强调强隔离边界和一致的 IAM。

关键特征：

• 具有区域子网的全局 VPC
• 除非显式配置，否则无出站互联网访问
• 服务账户是一级工作负载身份
• 组织约束强制实施全局规则
• VPC 服务控制提供强大的数据边界

IAM 绑定简单且一致 —— 但 GCP 提供的补救机制比 Azure 少，条件运行时评估也比 AWS 少。

GCP 擅长定义强隔离边界，但需要谨慎设定服务账户权限的范围。

GCP 授权流程
主体 → IAM 绑定 → 组织约束 → API 服务

4.4 综合云防御对比表

五、现代云安全解决方案的局限性

现代云安全产品——包括态势管理平台、身份分析器、权限管理工具和工作负载保护系统——提供了跨云环境的广泛可见性和分析能力。它们能发现错误配置、身份风险、过度权限和可疑行为。这些功能至关重要，它们帮助安全团队理解复杂环境中正在发生的事情。

但是，尽管这些工具提升了感知能力，却并未实现设计即安全。

它们无法保证云架构本身就能自然遏制事件、阻止横向移动或强制环境间的隔离。换句话说，它们能告诉你什么错了，但无法确保环境从一开始就是被正确构建的。

现代云安全解决方案不能：

• 设计或强制架构隔离（例如，分离生产/开发环境，或将云单元划分为信任边界）
• 确保跨提供商的私有服务访问和数据边界限制
• 以能保证在受攻击时实现隔离的方式来解析身份关系
• 防止组织在扩展到多个云时出现防护措施错位
• 将组织的预防性原则表达为云原生控制措施
• 在 AWS、Azure 和 GCP 中创建一致的分段模式
• 在执行策略时考虑云特有的架构限制

它们提供洞察——有时是非常出色的洞察——但洞察并非架构。

最大的差距是结构性的：

这些工具在环境已经存在之后才运作。

它们观察和检测，但并不定义或强制执行云的基本信任模型。

在多云安全环境中，每个提供商对身份、网络和访问的定义各不相同，有效的安全需要满足以下特性的控制措施：

• 内置于架构设计之中
• 默认阻止不安全的配置
• 限制身份的移动和权限提升
• 隔离环境，使攻击影响范围得到控制
• 体现每个云独特的防御能力
• 在环境扩展时保持一致

现代云安全工具支持这一过程，但它们无法独自实现这一目标——因为设计即安全的云架构必须在控制平面层面，使用云原生的防护措施来构建。

归根结底，多云安全不在于寻找一个“最佳”提供商——而在于认识到每个云都将安全内化到了技术栈的不同层面。

AWS 提供了无与伦比的请求时控制能力，但要求跨众多策略层面保持严谨的纪律。

Azure 集中管理身份和治理，使得企业一致性非常强大，但也提高了角色和目录权限范围错配的风险。

GCP 构建了强大的边界[7]和周界，能自然遏制爆炸半径，但依赖于严格的服务账户范围界定和自上而下的约束。

各云的目标是一致的——防止暴露、限制移动、控制影响——然而实现路径却从不相同。如果安全团队希望在多个云上实现一致的预防，他们必须为每个提供商的原生执行平面进行专门设计。

当架构、身份和防护措施都是云特定的——并且在相同意图下对齐时，多云防御方能成功。

引用链接

[1] 《Deep Technical Guide: How Cloud Defense Strategies Differ Across AWS, Azure, and GCP》: https://blast.security/blog/deep-technical-guide-how-cloud-defense-strategies-differ-across-aws-azure-and-gcp/ [2] 多云: https://aws.amazon.com/blogs/enterprise-strategy/proven-practices-for-developing-a-multicloud-strategy/ [3] 爆炸半径: https://blast.security/blog/reducing-the-blast-radius-a-practical-guide-to-containing-cloud-risk-before-it-spreads/ [4] 一致的多云: https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-multicloud-fsi/security-governance.html [5] Azure 在登录时评估: https://learn.microsoft.com/en-us/entra/identity/conditional-access/ [6] 预防性防护措施: https://blast.security/blog/guardrails-that-scale-how-to-prevent-cloud-misconfigurations-without-slowing-devops/ [7] GCP 构建了强大的边界: https://cloud.google.com/security/vpc-service-controls

交流群

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito《三大云平台防御机制深度对比》