在云安全的日常方案选型里我最常被问到的问题不是“零信任到底是不是一个新概念”而是另一类更具体的同样一套零信任理念放到 AWS 和 Azure 上落地路径差在哪这个问题确实值得认真拆一拆。零信任不是买一个产品就能交付的它是一组在身份、设备、网络、数据四个层面持续做验证和最小授权的机制组合而两大云平台对这四个层面的暴露方式、控制粒度、默认行为都有明显差异。这篇内容我想基于项目评估和落地实践中的对比把 AWS 与 Azure 在零信任实现上的核心差异、各自的强项和常见坑讲清楚适合正在做多云安全规划或在单云环境里准备从“边界防护”转向零信任体系的团队参考。1. 为什么云上零信任比传统 IDC 更急迫边界失效与两大平台的底层思路差异1.1 传统边界模型在云上的失效路径过去做安全习惯上把一个数据中心当成“可信域”内部网络默认可信任防火墙守住南北向办公网和生产网做隔离边界做到位安全感就有了。但云上的资源形态完全不是这样。租户之间共享底层网络公网暴露面大一个配置失误就可能把资源对全网开放更麻烦的是攻击者现在不需要突破“网络边界”只要拿到一组有效凭据就能从任意位置访问控制面 API。我在实际评估中发现云上安全事故里相当大一部分不是“打进来的”而是“走正门进来的”——某个开发环境的 Access Key 被泄露或者某个员工账号在没有 MFA 的前提下被撞库攻击者直接用合法路径操作资源防火墙再严密也没有用。这个变化让零信任变得比在传统 IDC 里更急迫网络位置不再是信任的依据每个访问请求都应当被当成潜在攻击来看待身份、设备、行为上下文都要参与验证。1.2 AWS 以资源授权为中心Azure 以身份目录为中心同样是零信任AWS 和 Azure 的架构哲学有明显区别。AWS 的核心执行点是 IAM 策略主体用户、角色要访问某个资源最终由 IAM Policy、资源策略、SCP 共同决定。换句话说AWS 的授权逻辑是围绕“资源”和“动作”展开的身份只是其中一个输入条件。而 Azure 的信任根则建立在 Microsoft Entra ID原 Azure AD 的身份目录基础之上用户登录拿 token条件访问策略在 token 发放前做一次强校验资源层面再用 RBAC 做细粒度授权。这个差异会直接影响运维习惯在 AWS 里安全团队如果要对一个角色做限制最直接的方式是改角色边界策略或者附加一条 Deny在 Azure 里优先级最高的是把条件访问策略配置好从登录入口就过滤掉高风险请求。所以说在 AWS 做零信任第一优先级是管策略和角色在 Azure 做零信任第一优先级是管身份和会话。下面这张表是我做双云对比时常用的能快速看出两个平台在零信任各层面的对应关系零信任层面AWS 主要落地组件Azure 主要落地组件关注点差异身份认证IAM、IAM Identity Center、STSMicrosoft Entra ID、条件访问、PIMAzure 更强调登录前校验授权控制IAM Policy、权限边界、SCPRBAC 角色分配、Azure Policy、管理组继承AWS 策略组合更灵活但也更复杂工作负载身份IAM Role、IRSA、OIDC Provider托管身份、Workload Identity Federation都支持免密钥但实现路径差异明显网络微分段Security Group、Network ACL、Transit GatewayNSG、ASG、Azure Firewall、Virtual NetworkAzure 默认行为更宽松需额外收紧持续监控CloudTrail、GuardDuty、Security Hub、Access AnalyzerMicrosoft Defender for Cloud、Sentinel事件模型和分析逻辑不同所以做双云零信任时我不建议把某个平台的安全方案原样搬过去而是先把这张对应表梳理清楚再决定每一层优先做哪个平台。2. 身份与设备信任面条件访问策略和 IAM 权限边界的差异2.1 Azure 条件访问登录那一刻就把风险挡在门外Azure 上做零信任第一步通常是配条件访问Conditional Access。它是在用户登录和获得 token 的过程中执行的一套策略可以理解为云端的“门卫”用户得先证明“我是谁、我的设备可信、当前登录风险不高”系统才放行。实操时我会按这样几步来在 Microsoft Entra ID 里创建条件访问策略选择目标用户组建议先找一个试点组不要全量一把梭。指定目标资源比如“所有云应用”也可以细化到某个企业应用。配置条件最常用的是设备状态要求合规设备或混合加入设备、位置命名网络或可信 IP、风险信号登录风险/用户风险、客户端应用类型区分浏览器、移动端、旧版客户端。配置访问控制比如“阻止访问”或“授予访问但要求多因素认证 / 设备合规”。策略模式先设成“仅报告”观察一段时间再强制启用。需要特别注意的是条件访问还有一个容易被忽视的能力——持续访问评估CAE。普通的 token 有有效期在有效期内即使账号异常也要等 token 过期才能强制失效CAE 开启后关键事件发生时系统能实时撤销会话。我在实际配置中会尽量开这个能力尤其是对 Exchange Online、SharePoint 这类数据敏感应用。2.2 AWS 的权限边界与身份中心控制粒度在“策略”而不是“登录”AWS 里也有类似“登录前检查”的机制但默认并不像 Azure 条件访问那样强。真实做法是把重点放在 IAM 权限边界和角色设计上。一个典型的落地套路是这样用户通过 IAM Identity Center 做 SSO 登录配置 Permission Set相当于把一群用户映射到某个角色上角色允许执行哪些操作由策略决定。给角色附加权限边界Permissions Boundary用来限制这个角色“最大能到哪”。即便策略里写了管理权限边界里不允许的操作依然执行不了。在 IAM Policy 里使用条件键比如要求aws:MultiFactorAuthPresent为 true或者限定只能从特定 VPC 终端节点访问这是 AWS 本身支持的一种“登录条件”思路。要求所有长时凭据都改造成短时角色禁止根用户做日常操作。差异点在于Azure 条件访问是“会话入口”卡一道AWS 则更多依赖“每个 API 请求都按策略实时评估”。这让 AWS 在细粒度授权上更灵活但代价是策略一多权限组合就变得很难推导。调试时往往要一遍遍用策略模拟器验证或者看 CloudTrail 里的 Deny 日志才能定位是哪条权限导致的。2.3 条件与设备合规Azure 优势明显AWS 需借助生态如果同时管过两个平台会明显感觉到 Azure 在“设备信任”上做得很重合规设备、混合加入、设备风险等状态能直接作为条件访问的判断依据。AWS 本身没有一套内置的设备管理体系因为它更像一个“基础设施平台”设备合规更多要依赖外部 MDM再通过 OIDC 联邦把设备信息映射成 IAM 会话标签。结果就是AWS 上只能做到“请求带上了某些标签”但标签本身的可信度完全取决于上游身份源。因此在做落地时我会这样建议如果业务大量使用 Windows 终端和 Office 类应用Azure 的条件访问会带来立竿见影的效果如果业务主要是后端服务和 API 调用AWS 的 IAM 角色 权限边界更贴近日常操作逻辑。3. 工作负载身份让服务的“凭据”不再像秘密一样被拷贝3.1 AWS 的工作负载身份IAM 角色、IRSA 与 OIDC零信任里有一个很关键但容易漏掉的维度云上不仅有“人”还有大量“机器角色”。很多团队在管理用户时做得很严格EC2 里却还放着永久 Access Key数据库密码写在配置中心里这种状态等于把后门直接留给攻击者。AWS 的解法是让工作负载变成一个有身份的主体而不是靠钥匙。具体落地方式有几种EC2 / Lambda 附加 IAM Role通过实例元数据服务IMDSv2获取临时令牌跑业务不在机器里存任何密钥。EKS 上用 IRSAIAM Roles for Service Accounts创建 OIDC Provider让 Kubernetes Service Account 能映射到一个 IAM 角色Pod 调用 AWS API 时自动换取临时凭证。第三方 CI/CD 流程通过 OIDC Federation 接入流水线里不写云密钥每一次构建都从身份中心换取短时凭证。我在配置 IRSA 时有一个小经验每个 Service Account 只绑一个最小权限角色不要图省事把所有 Pod 都放到同一个角色里。否则一旦某个应用被攻破横向移动范围会非常大这恰恰违背了零信任的“最小权限”原则。3.2 Azure 的托管身份系统分配与用户分配Azure 对应的能力是托管身份Managed Identity。它分为系统分配和用户分配两种本质上是在 Entra ID 里为工作负载创建一个身份对象应用通过 Azure Instance Metadata Service 自动换取 token再访问 Key Vault、存储、数据库等目标资源。在实际项目里我更喜欢用用户分配托管身份因为它的生命周期与具体应用解耦同一个身份可以被多个资源复用权限变更只改一处删除应用也不会影响身份本身。而系统分配身份跟随资源虽然创建简单但资源删除后身份也就没了审计时容易断掉“身份—访问”这层对应关系。和 AWS 相比Azure 的托管身份机制会省掉很多“换角色”的步骤应用侧几乎不用感知身份的存在SDK 会自动处理 token 获取和刷新。但这也带来一个风险——配置太顺滑反而容易让人忘记去管权限。我在 Azure 项目里经常发现开发团队给某个托管身份分配了“贡献者”角色之后就不动了完全没有按最小权限收敛。所以两边都需要在治理层做同样的检查只是触发点不同。3.3 双云共同原则避免长时凭据和“万能角色”把 AWS 和 Azure 放在一起看工作负载身份的共同原则其实是一致的不要用长时凭据不要共享“万能角色”。AWS 用角色切换和临时凭证Azure 用托管身份和工作负载联邦都是为了让“凭证”这个东西尽量短命、尽量不可拷贝。对同时跑两个云的团队我建议在 CI/CD 层统一用 OIDC 联邦接入用一个身份系统对接两边在部署目标环境里再分别映射成 AWS 的 IAM Role 或 Azure 的托管身份。这样既不会在一个平台里留下另一边的明文字段也能把权限追踪收敛到一处。4. 网络微分段安全组和 NSG 的执行粒度与默认行为差异4.1 AWS 安全组有状态但默认严格规则合并逻辑要小心网络层是零信任落地里最“痛”的部分因为它的默认行为直接影响业务能不能跑起来。AWS 安全组默认不允许任何入站流量创建实例时如果不加规则外部基本连不上这天然符合“默认拒绝”的理念。但问题出在规则合并逻辑一个实例挂多个安全组时规则是取“并集”的只要任意一个安全组允许了某个端口就算其他安全组配得再严也没用。我见到的典型事故是运维同学给实例挂了三个安全组以为每个组都做了一层控制结果其中一个组里残留了一条0.0.0.0/0的 SSH 规则整台机器就暴露了。因此在 AWS 上做微分段我对团队的硬性要求是每个实例能挂的安全组越少越好尽量用“安全组引用安全组”的方式来聚合而不是靠人肉检查多个组之间有没有漏洞。AWS 的网络层还有一层无状态的 Network ACL它活在子网级别。很多团队配了安全组就忽略它但从纵深防御角度我会把 NACL 当成第二道保险专门用来封禁来自威胁情报里的已知恶意 IP 段。注意它是有状态的入站和出站规则必须成对维护否则很容易出现“规则配了但流量不通”的诡异问题。4.2 Azure NSG 与 ASG默认放行内网流量是最容易踩的坑Azure 的网络微分段组件是 NSG 和 ASG。第一次从 AWS 迁到 Azure 的团队容易犯一个错误以为两边默认行为一样。实际区别很大——Azure 虚拟网络内有默认的“允许虚拟网络内部流量”规则也就是说两台 VM 放在同一个 VNet 里只要没有显式 NSG 阻止它们之间默认是能互通的。这跟 AWS 安全组默认拒绝入站的习惯正好相反。所以 Azure 上做微分段第一步往往不是写“允许”规则而是写“拒绝”规则把不需要的内网互通一个个掐掉。为了减少规则爆炸我会用应用安全组ASG而不是传统 IP 段把一批 VM 放到某个 ASG 里用逻辑名写规则比如“允许 Web 前端访问仅后端 ASG 的 443 端口”这样实例 IP 变化时规则不会失效还能在权限管理里保持可读性。4.3 网络层在零信任中的定位兜底而非第一道防线双云网络微分段做多了以后我的结论是网络层不应该当零信任的“第一道防线”它更像是最后一道兜底。第一道防线在企业里更精细地嵌在 Identity、条件访问和处理 IAM/策略的地方网络只是当身份或策略被做实了之后才叫“最后一道保险、拉高防御纵深的事件发生提醒”的最后一个兜底。具体实现上AWS 可以用 Transit Gateway 把流量导到集中的安全 VPC走防火墙或网络流量检查Azure 则用 Azure Firewall Manager 集中管理跨订阅的 NSG 策略。两者都可行但不要误以为“有防火墙就有零信任”那还是传统边界思维。5. 持续验证与可视能力从 GuardDuty/Security Hub 到 Defender/Sentinel5.1 AWS 的可视化与检测CloudTrail 是零信任审计的基础零信任不是“配完策略就完事”它要求持续验证——每个请求、每次权限变更都应该能看到、能追溯。AWS 上做持续监控底层的原始素材来自 CloudTrail所有 API 调用、控制台操作、策略变更都会被记录。拿到 CloudTrail 后我会把高风险事件集中送到独立的安全账号用 EventBridge 做实时告警避免日志和生产环境混在一起。在这个基础上GuardDuty 负责检测异常行为比如挖矿通信、异常外联、某台机器短时间内大量调用 APIAccess Analyzer 专门发现“外部实体能不能访问某个资源”的问题比如某个 S3 桶意外变成了公开或者某条角色信任策略允许了外部账号跨账号访问。这些能力特别适合零信任初期的梳理工作你不需要一开始就预设信任边界而是让工具把“被信任但本不应该被信任”的路径列出来。5.2 Azure 的持续检测Defender 系列和 Sentinel 的组合Azure 的检测体系更强调“安全中心 SIEM”的组合。Microsoft Defender for Cloud 负责汇总订阅里的安全建议比如虚拟机缺补丁、存储账号未启用加密、NSG 规则暴露了管理端口等如果想进一步做行为分析和跨云事件关联一般会把日志接入 Sentinel用内置的 UEBA 分析账号异常行为再配合工作簿出安全报告。如果只选一个点来对比我认为 Azure Policy 的“Deny 效果”是它的加分项它可以做到“不合规的资源根本建不出来”比如规定某个区域的存储必须启用私有端点否则创建请求直接被拒绝。AWS 也有类似治理能力但更像通过 SCP 或控制策略“限制某些动作”在资源合规的即时拦截上表现不同。对零信任而言“建出来之前就拦掉”比“建出来之后再告警”更符合最小可信原则。5.3 双云监控的落地建议先统一事件基线再谈检测模型如果想要同时治理 AWS 和 Azure我的建议是先统一事件基线再谈检测模型。具体做法是把两边的高风险事件定义成同一套严重级别比如“凭证泄露”“异常跨境登录”“权限提升尝试”各归一个等级。选一种集中日志平台把 CloudTrail 和 Azure Activity Log 都汇进去不要分开看否则跨云攻击链路根本串不起来。告警规则先在试运行模式下跑观察误报量把明显噪音源排除掉再打开强制通知。很多团队一上来就装了一堆检测工具结果每天收到几百条告警安全团队很快“告警疲劳”真正的高危信号反而被淹没。零信任的持续验证能力不是看工具数量而是看你能不能在一分钟内回答一个问题“当前所有高权限访问里有没有任何一个不满足我预设的环境条件”6. 落地路线与常见坑在两朵云上如何选择第一道防线6.1 按业务场景决定先做身份还是先做网络不少团队问我要不要“全面零信任”我的建议是别追求一步到位。先判断业务形态更接近哪一类再决定先做哪一层。业务特征建议优先落地平台与方向理由全员使用移动办公、Office 套件等现代应用Azure Entra ID 条件访问 设备合规Azure 对设备状态和登录风险的检测最顺手大量后端 API、微服务、容器负载AWS IAM Role 权限边界 IRSAAWS 的策略模型更适合服务级权限控制双云并存需要统一身份入口先建统一身份源再做 OIDC 联邦两边都通过同一套身份源换取临时凭证弱点在高频暴露的公网入口网络微分段先行两边同时收紧默认规则先把暴露面收住再逐步补身份和监控6.2 分阶段实施路径从“资产盘点”到“最小权限试点”不管选哪个平台我都会走这样一条路径第一阶段盘点资产和身份。列出所有账号、角色、资源、网络入口把长期没人在用的账号和未打标签的资源清出来。这一步最无聊但最值钱。第二阶段建立基线。给每个资源标记三个问题“谁能访问”“默认允许了什么”“上次访问是什么时候”。回答不了这三个问题的资源其实都可以先默认拒绝。第三阶段挑一个业务线做试点。把该业务线的访问策略收敛到最小权限开启日志和告警观察业务影响调整出可用又安全的最小规则集。第四阶段把试点规则推广到其他业务线同时开启持续检测。推广时一次一个业务线不要把几百条策略一次性推上线。6.3 在我实际踩坑中觉得最值得提醒的几点踩过双云零信任的坑之后有几个点是我一定会反复强调的第一点是“默认拒绝”不等于“把策略一封就完事”。很多变更在测试环境看着没问题一上生产就把业务流量切断了。做策略变更前我会先在只读模式观察一段时间配合“如果是 Deny影响范围在哪里”的风险评估再去执行。第二点是不要把长时凭据留到“以后改”。项目周期里最容易出现的情况是先接了点开发环境的钥匙想着后面替换成角色结果一忙就忘了。每多留一个星期暴露风险就多一分。我在每次安全评审里都会先查一遍哪里还有永久密钥这是成本最低但收益最高的一项。第三点双云团队的运维习惯要兼容。AWS 用户习惯把一切都摊开在 IAM 策略里看Azure 用户则更习惯用管理组和 RBAC 的继承关系去推。两套模型不是一一对应真要同时维护建议画一张“权限推导链路图”——从用户到身份、从身份到角色/角色分配、从角色到最终动作每一步都标清楚用的是哪个平台的哪个机制。这张图看着费工夫但排查权限问题时会省下好几倍的时间。零信任落到 AWS 和 Azure 上本质上不是“哪家更安全”的问题而是“哪家的机制更适合你现有业务和团队习惯”的问题。一个原则是确定的不把任何一条访问路径默认为可信不把任何一份长时凭据留在运行环境里不给任何一次操作留死角。能做到这三点平台差异就只是工具差异零信任的骨架就已经立住了。