3. 零信任原则在SASE中的落地

零信任并不是一套可以单独购买的产品，而是一组访问决策原则。SASE 之所以能承载零信任，是因为它把网络接入（SD-WAN）、安全能力（SWG、CASB、FWaaS、ZTNA）和统一策略引擎收敛到同一朵云上，使“每一次访问都要先判断身份、设备、上下文，再决定是否放行”成为可执行的工程动作。本节围绕四条落地原则展开：身份成为新的边界、最小权限、持续验证、动态访问控制策略，并给出可操作的策略结构与示例。

一、身份为边界：从“IP 可达”到“身份可信”

传统边界模型中，只要终端位于内网网段或通过 VPN 拿到一个内网 IP，就被默认可信。零信任把这条隐含信任彻底删除：网络位置不再授予任何权限，访问主体必须由身份来定义。在 SASE 中，这个身份通常由三部分合成：

• 主体身份：用户账号（如 alice@corp.example）及其所属组、角色，来自 IdP（如 Entra ID、Okta、Keycloak）。
• 设备身份：终端在 MDM/EMM 中的注册记录、设备证书、序列号，用于区分“公司受管笔记本”与“个人手机”。
• 工作负载身份：服务账号、SPIFFE ID 或云上 IAM Role，用于东西向与 API 访问。

落地时，SASE 控制平面通过 SAML/OIDC 与 IdP 联合登录，通过 SCIM 同步用户与组，通过设备姿态接口（如 Intune 合规状态、CrowdStrike ZTA 评分）获取设备健康度。策略引擎不再写“允许 10.1.0.0/16 访问 10.2.3.4:443”，而是写“允许 财务组 用户 在 合规设备 上 访问 财务应用”。身份成为边界的直接后果是：同一台笔记本在家、在咖啡厅、在办公室，访问同一应用的判定逻辑完全一致，不再依赖它接入哪个网络。

二、最小权限：把“能连上”收窄为“只能做这件事”

最小权限在 SASE 中体现为三层收窄：应用级、操作级、数据级。应用级由 ZTNA 完成——用户不再获得整个网段，而是只看到被授权的具体应用（如 finance-app.corp.example），未授权应用在客户端根本不可见，从而消除横向扫描面。操作级由 SWG/CASB 的 URL 与 API 过滤完成，例如允许访问 GitHub 但禁止 push 到外部组织仓库。数据级由 CASB 的 DLP 规则完成，例如允许下载报表但禁止将含身份证号的字段外发。

一个可执行的权限矩阵示例（示例参数，非实测）：

最小权限不是一次性配置，而是随岗位变动持续收敛。建议以“默认拒绝 + 显式授权 + 定期复核”为基线，每季度对高权限角色做一次权限回收。

三、持续验证：从一次登录到每次请求

零信任的关键转变是把“认证一次、信任整段会话”改为“每个请求都重新评估”。SASE 的持续验证通常由三个信号源驱动：身份信号（令牌有效性、MFA 完成时间、异常登录）、设备信号（补丁级别、磁盘加密、EDR 是否在线、越狱/root 检测）、行为与环境信号（地理位置、IP 信誉、访问时间、请求频率、数据量突增）。

这些信号汇入策略引擎后，会输出一个信任评分（示例：0–100）。评分不是装饰，而是直接映射为动作：

• 评分 ≥ 80：直接放行，记录审计日志。
• 60 ≤ 评分 < 80：放行但降权，例如只读、禁止下载、强制水印。
• 40 ≤ 评分 < 60：要求重新 MFA 或设备合规检查，通过后恢复。
• 评分 < 40：阻断并告警，必要时吊销会话令牌。

持续验证的工程要点是“会话可撤销”。SASE 云网关需支持对已建立会话的实时降权与断开，而不是等令牌自然过期。例如检测到设备在登录后关闭了 EDR，应在秒级内把该会话从“可下载”降为“只读”，而不是等下一次登录。

四、动态访问控制策略：把原则写成可执行规则

动态访问控制策略是前三条原则的汇合点。一条完整的 SASE 访问策略至少包含：主体（用户/组/设备/工作负载）、资源（应用/域名/API/数据分类）、上下文条件（设备合规、位置、时间、MFA 强度）、动作（允许/拒绝/降权/二次认证）、以及审计与响应动作。下面给出一个策略片段示例，采用类 YAML 结构表达，便于映射到主流 SASE 控制台：

policy: finance-erp-access
  subject:
    groups: ["finance-staff", "finance-manager"]
    device: managed == true
  resource:
    app: "erp.corp.example"
    paths: ["/api/report/*", "/api/expense/*"]
  conditions:
    mfa: required
    device_compliance: "pass"
    trust_score: ">= 60"
    geo: ["CN", "SG"]
  action:
    if trust_score >= 80: allow
    if 60 <= trust_score < 80: allow_readonly + watermark
    if trust_score < 60: step_up_mfa
  audit:
    session_record: true
    log_fields: [user, device_id, app, path, trust_score, action]

策略生效后，运维需要观察的不是“有没有连上”，而是“每次请求的判定结果是否符合预期”。建议在 SASE 控制台按用户、应用、动作三个维度看放行/降权/阻断的比例，若某条策略长期 100% 放行，说明条件过松；若大量合法用户被 step-up，说明信任评分阈值或设备基线过严，需要校准。

把四条原则串起来看：身份为边界解决了“谁在访问”，最小权限解决了“能访问什么、能做什么”，持续验证解决了“访问过程中是否仍然可信”，动态访问控制策略则把前三者写成可执行、可审计、可回滚的规则。SASE 的价值在于让这套规则在云上统一执行，而不是在每个分支、每个 VPN 网关、每个 SaaS 代理上各写一套。落地时建议先选一个高价值应用（如财务 ERP）做试点，把身份源、设备合规、信任评分阈值和动作分支跑通，再逐步扩展到更多应用与角色。