3. CASB架构模式选型

CASB（Cloud Access Security Broker，云访问安全代理）并不是单一形态的产品，而是一组部署架构模式的集合。同一款CASB产品，选择正向代理、反向代理、API模式还是日志采集模式，直接决定了它能看到什么流量、能控制到什么粒度、对用户是否透明，以及运维成本有多高。本节先逐一拆解四种模式的原理与边界，再讨论如何把它们组合成混合部署架构。

四种模式的原理与能力边界

正向代理（Forward Proxy）位于用户与云服务之间，用户终端（浏览器、移动设备或通过PAC文件、代理自动配置）把请求显式或隐式地交给CASB，由CASB代用户访问云应用。它的核心价值是实时阻断：因为流量经过CASB，CASB可以在请求发出前判断“这个用户能不能访问这个应用、能不能上传这个文件”，并直接返回拒绝页面。代价是需要在终端或网络侧做代理配置，对未托管设备（BYOD）覆盖困难，且HTTPS解密会带来证书分发和性能开销。

反向代理（Reverse Proxy）把CASB部署在云应用侧，用户访问的是CASB的域名或IP，由CASB转发到真实云应用。它常用于单点登录（SSO）集成、统一身份认证和会话控制，典型场景是给自建或私有化SaaS应用加一层访问控制。反向代理对用户基本透明，但需要把应用入口指向CASB，改造范围大，且对第三方公有SaaS（如Microsoft 365、Salesforce）通常无法直接接管入口。

API模式不经过用户流量路径，而是通过云服务商提供的管理API（如Microsoft Graph、Salesforce REST API、Google Workspace Admin SDK）以“带外”方式拉取数据。它能做到正向代理做不到的事：扫描已存储在云中的历史文件、识别敏感数据、发现影子资产、执行数据保留与合规策略。但API模式是近实时而非实时，通常有分钟级延迟，且无法阻断用户当下的上传动作，只能事后告警或删除。

日志采集模式通过接收云应用的审计日志（如AWS CloudTrail、Azure活动日志、Okta系统日志）或SIEM转发，做行为分析、异常检测和合规审计。它完全不介入流量，部署最轻，但只有“看见”能力，没有“控制”能力，属于事后取证与态势感知层。

混合部署架构的设计决策

现实中很少有企业只选一种模式。原因很简单：正向代理覆盖不了未托管设备，API模式管不住实时上传，日志采集只能看不能拦。因此，成熟的CASB落地通常是“正向代理 + API模式 + 日志采集”三层组合，反向代理则按应用类型选择性使用。

一个可参考的决策逻辑是：先按流量是否经过企业可控路径分流。托管终端（公司笔记本、已注册MDM的设备）配置PAC或代理，走正向代理做实时策略执行；未托管设备（个人手机、外包人员电脑）无法强制代理，改用API模式对云应用做带外扫描与策略下发；所有云应用的审计日志统一接入SIEM或CASB日志分析模块，用于异常行为检测和合规报表。反向代理只在需要统一身份入口的自建应用或私有化SaaS上启用。

策略编排上要注意避免能力重叠导致的误判。例如，正向代理已经阻断了一次敏感文件上传，API模式随后扫描时不应再对同一文件重复告警；反之，API模式发现的历史遗留敏感文件，应通过工单或自动删除流程处理，而不是依赖正向代理去“补拦”。建议在CASB策略层设置统一的策略优先级：实时阻断类策略（正向代理）优先级最高，API扫描类策略次之，日志告警类策略仅做记录。

一个可执行的选型检查清单

下面这份清单可直接用于CASB架构选型评审，逐项确认后再决定模式组合：

最后需要强调：四种模式不是互斥的“选择题”，而是可以叠加的“组合题”。正向代理解决“当下能不能做”，API模式解决“已经做了什么”，日志采集解决“曾经发生了什么”，反向代理解决“入口怎么统一”。把这四层能力按企业实际终端形态、应用类型和合规要求组合起来，才是CASB架构选型的完整答案。