【零信任安全架构】SaaS 与云原生的零信任：CASB、CSPM 和 Kubernetes 超网络策略

2020 年代的企业工作负载已经大规模迁移出了数据中心——电子邮件在 Google Workspace 或 Office 365、代码在 GitHub 或 GitLab、CRM 在 Salesforce、身份在 Okta 或 Entra ID。这些 SaaS 应用是新的”企业内网”——而它们的安全边界不是防火墙，而是 API 和身份配置。

前置阅读：身份感知代理。

一、SaaS 安全的零信任视角

传统安全团队对 SaaS 应用的控制通常是”审批是否开通”——但开通之后，SaaS 应用内部的数据访问控制由各个应用的配置决定，安全团队对这些配置的可见性极低。

1.1 SaaS 的三个零信任盲区

盲区 1：过度的分享权限。Google Workspace 管理员可以查看整个域的文件分享设置——但一个用户把 Q4-earnings.xlsx 从”仅限同域用户”改为”任何有链接的人都可以查看”通常不会被实时检测。

盲区 2：休眠账户和过度权限。一个离职员工的 GitHub 账号在被 HR 系统注销后，可能仍然拥有对私有仓库的访问权限——因为 GitHub 的 SSO 注销和 GitHub 的内部授权是两套独立的系统。

盲区 3：OAuth 应用权限过度。用户在为”帮我整理邮件”的第三方应用授权 OAuth scope 时，通常不会仔细阅读完全部权限范围。一个恶意的 OAuth 应用可能被授予了 https://mail.google.com/（读取全部邮件）的权限。

1.2 SSPM 和 CASB 的角色

SSPM（SaaS Security Posture Management） 的作用是持续审计 SaaS 应用的安全配置：

• Google Workspace：“哪些外部用户被添加到了共享硬盘？”“哪些文件设置了公开分享？”
• Salesforce：“哪些用户有’修改全部数据’的权限但在过去 90 天未登录？”
• GitHub：“哪些仓库是 public 的但标记为 INTERNAL 的标签？”

CASB（Cloud Access Security Broker） 在 SSPM 的基础上增加了实时执行能力——CASB 部署在用户和 SaaS 应用之间的路径上（通过反向代理或 API 连接），可以： - 阻止未授权设备访问 SaaS 应用 - 在执行高风险操作（下载所有客户数据）时触发额外的 MFA 验证 - 自动加密上传到 SaaS 应用的敏感文件

CASB 的零信任化本质上是在 SaaS 应用前面加一个 IAP——这与 身份感知代理 的原理相同，但 CASB 需要理解每个 SaaS 应用的 API 和操作语义，而不仅仅是 HTTP 请求。

二、云 IAM 的零信任改造

2.1 云 IAM 的爆炸半径

AWS IAM、GCP IAM、Azure RBAC 的共同问题是：权限通常以”角色”为单位分配，而角色中的权限集合可能在创建时过于宽松。

一个典型的 AWS IAM 角色可能包含：

{
  "Effect": "Allow",
  "Action": ["s3:*"],
  "Resource": ["arn:aws:s3:::my-bucket/*"]
}

这个策略为这个角色授予了对 my-bucket 的所有 S3 操作——但当这个角色只需要 s3:GetObject 时，s3:DeleteObject 和 s3:PutObject 就是不必要的权限。在不必要权限被攻击者利用时——这就是 blast radius 的扩大。

零信任的云 IAM 原则： - 用 IAM Access Analyzer 或类似工具检测未使用的权限，定期降权 - 对生产环境的操作（如 s3:DeleteBucket、ec2:TerminateInstances）要求 JIT（Just-In-Time）权限提升 - 服务账号应该有独立的最小权限角色——不要让 10 个服务共享一个 admin 角色

2.2 多云 IAM 的统一

大型企业通常同时使用 AWS、GCP 和 Azure——每个云平台的 IAM 模型不同：

统一多云 IAM 的实践方案：使用外部身份源（如 Okta、Entra ID）作为所有云平台的身份提供者——通过 SAML/OIDC 联邦，用户和服务的身份在云平台外部被验证，云平台的 IAM 角色通过身份属性（组、角色）映射。这避免了在每个云平台单独创建和管理用户。

三、Kubernetes 超网络策略

3.1 NetworkPolicy 的运维规模

单个 Kubernetes 集群的 NetworkPolicy 管理是可控的——但当集群数量达到 50+ 时，跨集群的一致性和审计变得困难：

• 每个集群都有独立的 NetworkPolicy 规则集——没有跨集群的一致性检查
• 不同集群的相同服务（如 payment-service 在 prod-us 和 prod-eu）可能有不同的 NetworkPolicy——这种不对称是安全漏洞的来源

解决方向： - 策略即代码 + GitOps：所有 NetworkPolicy 存储在 Git 仓库中，ArgoCD/Flux 自动同步到每个集群。同一个 Git 仓库保证策略的一致性。 - Cilium ClusterMesh（已在 微分段一文 中讨论）：统一多个集群的 Identity 空间。 - 策略合规扫描：定期的 CronJob 扫描所有集群，检查是否存在未经批准的 allow-all NetworkPolicy 或缺少了 default-deny 的命名空间。

3.2 Shadow IT 的发现

Shadow IT——业务部门自己开通了 SaaS 工具但 IT 部门不知道——是多云和 SaaS 环境中的独特问题。这些未被管控的工具： - 使用公司邮箱登录但不经过公司的 SSO（因此无法使用 MFA） - 可能被授予了访问公司 Google Drive 或 GitHub 仓库的 OAuth 权限 - 在企业 IT 的资产管理表中完全不存在

发现 Shadow IT 的方法： - CASB 的云应用发现：通过分析网络流量日志和 API 调用日志发现员工在使用哪些未经批准的 SaaS 应用 - SSO 日志分析：如果企业 SSO 是强制入口，SSO 的登录日志包含了所有经过认证的应用访问——包括 Shadow IT - 信用卡记录分析：在公司的费用报销系统中搜索 SaaS 订阅费用

下一篇：零信任与软件供应链。

参考资料

1. Gartner. (2024). Magic Quadrant for Cloud Access Security Brokers.
2. AWS. IAM Access Analyzer. https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
3. Google Cloud. BeyondProd: A New Approach to Cloud-Native Security. https://cloud.google.com/docs/security/beyondprod
4. CNCF. Cloud Native Security Whitepaper. https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2024-v2.pdf