AWS与Azure零信任落地对比：多云环境下的安全架构实践

这两朵云我都实际交付过零信任改造先说结论零信任不是一套配置模板而是一套“信任决策逻辑”。同一个业务要同时跑在AWS和Azure上安全组规则、身份策略、审计链路全都得按各家的原生产物重写一遍。这篇文章把我同时段在AWS与Azure落零信任的差异、踩坑和验证方法整理出来给多云环境里的云架构师、安全工程师以及刚从单云往多云迁移的团队一个可参考的对照。1. 零信任在云上到底意味着什么为什么换一朵云就得换方案1.1 零信任的三条铁律在云上如何翻译零信任这个概念被讲烂了但它真正的技术内核其实很朴素不再默认内网可信不再依赖IP段和物理边界任何一次资源访问都要经过身份验证、授权判定和持续的信任校验。落到云上你会发现云环境反而是零信任最自然的载体——因为云里所有动作都是API驱动的控制面天然能感知每一次调用。NIST 800-207里强调的三条铁律翻译成云原生语言就是身份是边界云里的用户、角色、服务账号才是真正的最小权限单元不是VPC网段。每次访问都校验不能因为“来自公司办公网”就放行要看令牌、看会话、看风险。持续监控与动态收敛权限不是配完就不管要能审计、能降权、能在异常时快速隔离。这两朵云都接受这套理念但落地的姿势完全不同。AWS把零信任拆成“Organizations SCP IAM VPC安全组 CloudTrail”核心是层层叠栈式授权Azure则把零信任放在“Entra ID 条件访问 RBAC NSG Defender for Cloud”这条链路上核心是全局身份与策略联动。1.2 为什么不能说“换层皮”就行很多从单云迁移到多云的团队最容易犯的错就是认为“我在AWS上写好的安全组在Azure里找个类似的NSG复制过来就行”。事实上两边在抽象层级上就有根本差异AWS以“VPC/账户”为强隔离单元网络和IAM高度分层权限判定是多策略交集部署重心在多账户治理。Azure以“租户/订阅”为边界身份控制面集中在云目录里网络隔离更多靠NSG的规则叠加部署重心在角色分配和条件访问。这就导致同样一个“禁止研发访问生产”的需求你在AWS要设计OUSCP在Azure要设计管理组RBAC角色分配同样的“只允许订单服务访问数据库”AWS用安全组之间的引用Azure用NSG的应用安全组。方案没法平替只能重写。2. 身份与权限两套完全不同的“授权宇宙”2.1 AWS的授权宇宙IAM、角色信任、权限边界、SCP在AWS里身份和权限的根基是IAM。IAM有用户、用户组、角色三种主体但真正贯穿零信任的是角色Role因为角色可以被实例、函数、容器服务“扮演”而不是把长期密钥硬编码到机器里。权限判定不是一条策略说了算而是多层交集身份策略、资源策略、权限边界、服务控制策略SCP、会话策略。其中SCP是在AWS Organizations里挂在组织单元OU上的“上限”。你可以理解成SCP先画一个圈IAM再在这个圈里分配具体的访问权权限边界再进一步收窄。就算某个角色策略给了S3全读写只要SCP没允许S3最终结果仍然是拒绝。实际配置里我强烈建议把“跨账号访问”都收敛到角色扮演STS AssumeRole。比如生产账号里建一个produce-db-operator角色研发账号里再建一个信任生产角色的IAM用户研发账号的用户只能通过JIT方式申请临时凭证去承担生产角色而不是直接在两个账号间拉专线。这里有一个经常被人忽略的细节角色信任策略里必须写明sts:ExternalId否则恶意租户利用混淆代理人问题可以直接扮演你的角色。2.2 Azure的授权宇宙Entra ID、条件访问、RBAC、PIMAzure这边身份基准在Entra IDAzure Active Directory它既是用户目录也是所有Azure资源授权的令牌签发中心。和AWS的IAM不同Azure的授权是一个“角色分配”体系核心公式是主体 角色定义 作用域 允许访问。作用域可以从管理组、订阅、资源组一直细到单个资源。零信任里更重要的一环是条件访问Conditional Access。它可以做到只有满足“设备合规 MFA 用户风险低”这些条件的令牌才能调用某些API。这一点AWS原生没有完全对等的产品——AWS的IAM条件Condition能限定来源IP、时间、标签但做不到Azure那种基于设备的合规校验和风险联动。所以如果你有大量BYOD设备接入云控制台Azure的条件访问要省心得多。特权身份管理PIM也是Azure零信任里值得重点用的能力。它把全局管理员、订阅管理员这类高权限角色变成“按需申请、限时审批、到期自动回收”的JIT模式整体上能明显降低高权限凭证常驻带来的风险。2.3 两边的授权评估差异对照对比维度AWSAzure身份主体IAM用户/角色/用户组Entra ID用户、服务主体、托管身份权限格式JSON策略Effect/Action/Resource/Condition角色分配主体/角色/作用域全局管控上限Organization SCP挂在OU上管理组 Azure Policy挂在作用域上动态访问控制IAM Condition主要是网络/时间/标签条件访问设备/MFA/风险/位置临时特权角色扮演 STS临时凭证PIM按需激活 按时间窗口跨账户/跨目录AWS Organizations RAM Identity CenterEntra ID租户 Azure Lighthouse / B2B这里需要提醒一个非常实际的差异AWS里权限边界更像“物理上限”SCP一旦禁止底下再怎么给都是拒绝而Azure的Policy分两种效果一个是Deny一个是Append/AuditDeny只是其中一种。如果你在Azure里只用RBAC分配角色、没配Policy把某些高危操作显式Deny掉那权限边界其实是不完整的。3. 网络分段与微隔离VPC和VNet的软硬件逻辑3.1 AWS侧安全组是状态化的、NACL是无状态的、PrivateLink收敛面AWS的网络隔离分两层安全组SG和网络ACLNACL。SG是实例级别的状态化防火墙默认入站拒绝、出站允许你写了一条允许规则后回包自动被放行NACL是子网级别的无状态防火墙必须同时配好入站和出站规则。零信任里最有价值的一点是SG可以互相引用。比如订单应用的安全组叫sg-order-app数据库安全组只允许来自sg-order-app的3306连接这样就算数据库在同一个子网其他服务器也碰不到它。这种“安全组即身份”的写法比靠IP段来限流要稳得多因为安全组的成员变化会自动反映到规则上。在跨账号或跨VPC暴露服务方面AWS的核心收敛手段是PrivateLink。通过VPC端点你可以让另一个VPC通过内网地址访问你的服务不需要经过公网、不需要对等整网这实际上是把服务的“信任面”从一个大网段收敛成了几个端点。常见做法是生产VPC里只把必要的端口通过PrivateLink端点暴露给消费方VPC其余全部在安全组侧拒绝。3.2 Azure侧NSG 应用安全组 防火墙管理器Azure对应的网络件是NSG网络安全组可以绑定到子网或网卡。NSG也自带默认规则入站默认拒绝出站默认允许。它的规则有优先级数字数值越小优先级越高并且同时支持源/目的IP、服务标签比如Internet、VirtualNetwork和应用安全组ASG。应用安全组是我在Azure里做微隔离时最常用的东西。给一组VM打上ASG-App再给数据库子网的NSG写一条“只允许来自ASG-App的3306”效果和AWS的安全组引用一模一样逻辑也很好管理。如果你的网络规模变大建议把NSG统一交给Azure防火墙管理器来集中编排避免每个NSG各管各的最后形成一张谁也理不清的规则网。Azure还有一个特异优势私有端点Private Endpoint。它能把Azure SQL、存储、Key Vault这类PaaS服务“拉”进你的虚拟网络分配一个内网IP并且默认禁止公网访问。这个能力对零信任特别重要——数据库不再暴露在互联网上所有访问都从虚拟网络内部发起网络层横向移动的面被压缩了很多。3.3 横向移动防护一个典型的“两边写法”假设线上有一个订单服务和一个MySQL数据库数据库不能接受来自互联网或任意主机的连接。AWS写法数据库放在私有子网安全组只允许来自sg-order-app的3306子网NACL再兜底拒绝来自0.0.0.0/0的入站。Azure写法数据库网卡绑定的NSG加一条高优先级规则只允许来自ASG-App的3306同时用私有端点把数据库PaaS调入VNet关闭公网访问。两边最终效果接近但运维心智完全不一样。AWS的安全组更像面向实例的“应用身份”写起来很直觉但要留意安全组本身的配额和规则数Azure的NSG规则更像传统防火墙优先级和方向很容易写乱建议提前把规则命名规范定好否则半年之后根本不敢动NSG。4. 工作负载身份服务之间怎么互相验证4.1 AWS实例配置文件、任务角色、EKS的IRSAAWS里给云上工作负载分配身份的方式是“角色直接挂到资源上”。EC2可以挂实例配置文件ECS任务可以指定任务角色Lambda可以绑定执行角色EKS通过IRSAIAM Roles for Service Accounts让Pod通过OIDC联合获得IAM角色。这样服务之间互访时不需要在镜像里塞任何长期密钥。我实际用过的一个链路是这样的ECS里跑一个订单处理服务任务角色命名为ecs-order-service-role策略只允许它访问指定S3桶的指定前缀和指定的Secrets Manager密钥。它要读数据库密码时调用 Secrets Manager 获取临时凭据然后连接RDS。整个过程没有把数据库密码写进环境变量也没有任何硬编码。这里最容易被忽略的是任务角色要配合权限边界使用而且轮换密钥时要注意密钥版本的缓存。AWS的Secrets Manager有强制轮换机制但代码如果缓存旧值超过轮换周期服务就会突然失联。这个坑我们踩过建议每次调用都先取最新版本并做好重试。4.2 Azure托管身份、Key Vault与工作负载身份联合Azure给工作负载身份的产品叫托管身份Managed Identity分系统分配和用户分配两种。系统分配是资源一对一虚拟机、Function等创建时直接就带上一个Entra ID身份用户分配则像是一个“身份容器”可以分配给多个资源统一管理。配合Key VaultAzure的工作负载可以做到很优雅的“免密”访问Function通过托管身份向Key Vault请求令牌然后动态读取连接字符串再访问下游数据库。整个过程不需要存储密码文件托管身份的票据由Azure内部自动轮换。另外Azure现在还支持把OIDC联合凭证配置在应用注册或工作负载身份上让GitHub Actions、AKS的Pod都能通过短时令牌访问Azure资源。这和AWS的IRSA在原理上是同一类东西都是“外部身份平台先签出OIDC令牌云再按信任凭据换取云身份”。4.3 实操对照表场景AWS推荐Azure推荐虚拟机访问云APIEC2实例配置文件系统分配托管身份容器服务访问云APIECS任务角色 / EKS IRSAAKS工作负载身份 / 用户分配托管身份Function访问云APILambda执行角色Function系统分配托管身份密钥/凭据管理Secrets Manager KMSKey Vault 托管身份CI/CD平台访问云OIDC联合GitHub ActionsOIDC联合GitHub Actions有一点必须强调托管身份和IAM角色虽好用但权限一定要收敛。很多团队图方便直接给托管身份配了Contributor甚至Owner级别的Azure角色这就等于给每一台机器发了一把管理员钥匙和零信任完全背道而驰。5. 持续验证与审计两朵云的“眼睛”放在哪里5.1 AWS端CloudTrail、GuardDuty、Security Hub、Access Analyzer零信任要求“持续验证”验证靠什么靠日志、告警和权限分析。AWS的底座是CloudTrail它会记录所有控制台和API操作包括谁在几点扮演了哪个角色、调了哪个资源。把CloudTrail日志集中投递到中心S3桶或CloudWatch Logs是第一步。GuardDuty负责威胁检测它分析DNS请求、VPC流日志和登录行为能发现异常挖掘或暴力破解迹象。Security Hub是聚合中心接入Config规则、GuardDuty、Macie后给出综合安全评分和合规检查结果。我建议一定要开Access Analyzer它会自动分析哪些资源被外部实体访问检测出“桶策略意外公开”“角色信任策略过宽”这类问题。5.2 Azure端活动日志、Diagnostic Settings、Defender for Cloud、SentinelAzure的对应底座是“活动日志”记录Azure资源层面的控制操作但要注意活动日志默认不Capture数据平面比如读数据库里的某张表不会进活动日志。你要为每个业务资源做诊断设置把它路由到Log Analytics工作区或存储账号才能形成完整审计链。整体安全态势用Defender for Cloud看它会给出安全评分并对照CIS、SOC2等基准确认“订阅可有任何高危开放端口”“密码设置是否合规”。威胁检测与响应可以用Sentinel它是微软的云原生SIEM能接入Entra ID登录日志、Defender告警和各类资源日志做关联分析和自动编排。我实际对比后的感受是Azure的“策略 Defender”更像是套餐式体验开箱即用性强AWS则是“每个服务各管一段”组件多但可控性高。无论哪边我都建议至少把“高危账号登录成功”“特权操作创建/删除角色”“NSG或安全组规则被删除”这三类事件设置成高优先级告警。5.3 多云统一运营的小技巧如果你两边都有业务不要分别在两边看告警否则迟早漏事。低成本的做法是AWS的CloudTrail和Azure的活动日志都投递到同一个集中Log分析平台然后统一做规则。没有预算搭SIEM时就先在两个云里各建一个只读“审计角色”每周定时导出权限清单做离线比对重点看四个东西是否有长期AK/SK在云主机里躺着是否有用户权限级别被不合理升高是否存在S3或Blob存储被设为公开安全组/NSG的“允许全端口全IP”规则近期是否变更。这四类风险筛查无论云端产品怎么叫核心逻辑都是一样的。6. 实施顺序、常见陷阱与故障排查实录6.1 零信任落地的正确顺序我第一次给某团队落地时先做网络隔离安全组和NSG写得满满当当结果身份侧还是“全员管理员”等于门锁得很死但钥匙人人有最后只能推倒重来。现在我的实施顺序是先清身份统一目录、回收共享账号、收敛高权限角色。再配特权管理AWS用SCP做全局上限Azure用PIM做JIT激活。然后做工作负载身份让所有服务都通过角色或托管身份访问资源。接着才是网络SG/NSG做微隔离私有端点/PrivateLink收敛暴露面。最后接审计把日志集中、设告警、定期做权限分析。顺序反了真不是效率问题而是方向问题。身份没收拾干净之前网络规则再严只要一个高权限账号被拿到整个隔离网就形同虚设。6.2 我实际踩过的坑第一个坑是AWS的SCP把某条API误Deny结果整个OU的人突然无法创建EC2实例。排查了很久才发现不是IAM策略少了权限而是SCP在组织层面做了拒绝。这是SCP的“隐性拒绝优先于一切显式允许”特性落地时一定要先在测试OU里跑透。第二个坑是Azure NSG的“优先级数字越小越优先”很容易记反。有一次我给数据库NSG加了一条“拒绝所有来自Internet的入站”结果因为优先级写高了后面的允许规则反而先匹配导致数据库端口直接暴露。NSG规则务必遵循环境由细到粗、优先拒绝高危来源的原则。第三个坑是EKS的IRSA配置。网上很多教程只说创建IAM角色并绑定service account但要是不设置annotations里的eks.amazonaws.com/role-arnPod根本拿不到身份。Azure的AKS工作负载身份也类似OIDC签发者和客户端ID必须完全匹配差一个字符就换不到令牌。6.3 常见问题速查现象AWS侧排查Azure侧排查明明配了权限还是访问被拒检查SCP、权限边界、会话策略是否叠了Deny检查角色分配作用域、Deny策略和条件访问容器里的服务取不到云资源权限看Pod是否绑定SAIRSA注解是否匹配看是否启用了工作负载身份OIDC联合是否匹配数据库被外网扫描到检查安全组入站是否全开NACL是否正确检查NSG规则优先级和私有端点是否关闭公网高权限账号被滥用检查SCP和角色信任策略开Access Analyzer启用PIM并要求条件访问MFA审计日志不齐全检查CloudTrail多区域是否开启、数据事件是否记录给每个资源开诊断设置路由到Log Analytics6.4 一些我后来才想明白的经验零信任在云上落地本质上是“把信任从网络移交给身份和策略引擎”。AWS与Azure的实现差异再大最终都收敛到同一件事谁访问什么资源经过了几层校验有没有留下证据。所以你不用纠结于非要在一朵云里复刻另一朵云的架构只要把身份基线、权限基数、审计策略这三件事想清楚两边的差异都只是语法不同。最后分享一个我每次项目都会逼团队做的小动作在每个云环境里创建一张“关键动作清单”包括删除存储桶、修改安全组/NSG、创建高权限角色、关闭告警这几项全部设为审计重点。因为零信任不是一次配置而是一条需要持续守住的底线。真正的安全不是某个控制项配得好看而是当异常真的发生时你能在最短时间内回答出“谁、在哪、干了什么”。