SASE 与 CASB 实战:安全访问服务边界与云访问安全的落地

当员工分散办公、应用迁往 SaaS、流量绕过传统数据中心时,“把流量拉回总部再检查"的安全架构彻底失灵。SASE(Secure Access Service Edge,安全访问服务边缘)与 CASB(Cloud Access Security Broker,云访问安全代理)正是为这一"流 …

当员工分散办公、应用迁往 SaaS、流量绕过传统数据中心时,“把流量拉回总部再检查"的安全架构彻底失灵。SASE(Secure Access Service Edge,安全访问服务边缘)与 CASB(Cloud Access Security Broker,云访问安全代理)正是为这一"流量逃离传统边界"的现实而生的新一代安全架构——把网络安全能力从数据中心搬到网络边缘,与身份、策略、云访问控制融为一体。本指南从 SASE 的架构理念出发,系统覆盖 ZTNA 零信任访问、CASB 云应用治理、策略编排与落地方案。

一、传统边界失效:为什么需要 SASE

1.1 数字化时代的三个结构性变化

变化传统架构的问题
员工远程办公流量不再经过总部数据中心
应用迁往 SaaS安全栈管不到云上的应用
多云 + 边缘数据中心不再是唯一访问点

ℹ️ 核心洞察:SASE 的理念是**“安全能力跟着用户走”**——把 WAF、SWG、CASB、ZTNA 等能力融合到全球分布的 PoP(Point of Presence)边缘,用户就近接入,身份即边界。

1.2 传统"流量回程"的致命缺陷

传统架构(回程模式):
  远程用户 ──VPN──▶ 总部防火墙 ──▶ 数据中心应用
                       └──▶ 分支访问 SaaS 也要绕行
  问题:延迟高、带宽浪费、VPN 漏洞(CVE-2021-34506 等)、策略不随身份

SASE 架构(边缘就近):
  远程用户 ──▶ 就近 PoP(融合安全能力)──▶ SaaS / 私有应用
                    │
              身份验证 + 策略 + 检查全部在边缘完成
  优势:低延迟、安全内嵌、身份驱动

二、SASE 的能力全景

2.1 SASE = 网络 + 安全 的融合

SASE 两大支柱:
┌─────────────────────────────────────┐
│ 网络能力(Network)                  │
│  · SD-WAN(广域网优化)              │
│  · 全球边缘 PoP 就近接入             │
│  · 云骨干网传输                     │
├─────────────────────────────────────┤
│ 安全能力(Security)                 │
│  · ZTNA 零信任网络访问               │
│  · SWG 安全 Web 网关                 │
│  · CASB 云访问安全代理               │
│  · FWaaS 防火墙即服务                │
│  · DLP 数据防泄漏                    │
└─────────────────────────────────────┘
统一由云端控制台编排策略,身份 + 设备 + 应用驱动

2.2 安全能力的职责分工

能力职责面向
ZTNA只允许授权用户访问指定私有应用私有应用
SWG过滤恶意 Web、控制 URL 访问公网 Web
CASB治理 SaaS 应用(权限/数据/DLP)SaaS 应用
FWaaS边界防火墙(东西南北向)网络流量
DLP敏感数据检测与防泄漏数据

三、ZTNA:零信任网络访问的核心

3.1 ZTNA vs 传统 VPN

维度传统 VPNZTNA
访问模型接入网络(一接入即见全内网)接入应用(只开放授权应用)
授权粒度网络级应用/端口级
身份验证较弱(静态密码常见)强(持续身份 + 设备合规)
横向移动一旦接入可扫全内网不可见即不可攻
隐含信任内网可信永不信任,始终验证

3.2 ZTNA 的三要素

ZTNA 每次访问都验证:
  1. 身份(Who):用户是谁(MFA、SSO)
  2. 设备(What):设备是否合规(补丁、磁盘加密)
  3. 上下文(Where/When):位置、时间、风险评分
  验证通过才建立到目标应用的加密隧道(最小授权)

3.3 开源 ZTNA:Cloudflare Tunnel / Tailscale

# Cloudflare Tunnel:把内网服务暴露为私密应用(无公网端口)
cloudflared tunnel login
cloudflared tunnel create my-app-tunnel
# 配置 config.yml:映射到内网服务
cloudflared tunnel route dns my-app-tunnel app.example.com
cloudflared tunnel run my-app-tunnel
# Tailscale(基于 WireGuard 的网格 VPN)
# 特点:全网状加密、身份驱动访问、ACL 控制
tailscale up --ssh
# ACL:只允许某用户组访问特定机器端口
# 原则:默认拒绝,显式允许

3.4 自建 ZTNA 的最小实现

# minimal_ztna.py — 身份感知代理的最小实现
import functools
import jwt

def identity_gate(required_role: str):
    """装饰器:验证 JWT 身份 + 角色后才代理到内网应用。"""
    def decorator(fn):
        @functools.wraps(fn)
        def wrapper(request, *args, **kwargs):
            token = request.headers.get("Authorization", "").replace("Bearer ", "")
            try:
                payload = jwt.decode(token, SECRET, algorithms=["HS256"])
            except Exception:
                return {"error": "unauthorized"}, 401

            # 身份 + 设备 + 上下文三重校验
            if payload.get("role") != required_role:
                return {"error": "forbidden"}, 403
            if not device_compliant(payload.get("device_id")):
                return {"error": "device_not_compliant"}, 403
            if high_risk_context(payload):
                return {"error": "risky_context"}, 401

            return fn(request, payload)   # 放行,带上身份信息
        return wrapper
    return decorator


@identity_gate("finance.auditor")
def proxy_to_internal_api(request, identity):
    """只允许财务审计角色访问内部报表 API。"""
    return forward_to_internal("http://10.0.0.5:8080", request.path)

四、CASB:云访问安全代理

4.1 CASB 解决什么问题

SaaS 应用(Salesforce/Google/微信工作台等)三大风险:
  1. 影子 IT:员工自行注册云应用,IT 不知道
  2. 权限失控:离职账号未清理、过度授权
  3. 数据外泄:敏感数据上传、DLP 缺失

CASB 作为"中间层"控制云应用访问与数据:
  用户 → CASB → SaaS
          │
    权限治理 / DLP / 行为分析 / 影子应用发现

4.2 CASB 的四种部署模式

模式部署适用特点
正向代理(Inline)流量必经 CASB需实时检查能阻断,但要求流量导向
反向代理位于云应用与用户之间网关式控制对应用透明
API 模式通过云应用 API 治理数据治理不能阻断实时流量
日志分析聚合日志检测影子 IT 发现事后、非阻断

4.3 API 模式的 CASB 治理(DLP 示例)

# casb_dlp.py — 基于 SaaS API 的数据治理
def scan_uploaded_file_for_pii(file_meta, content) -> dict:
    """CASB 扫描上传至网盘的敏感数据。"""
    from detection import classify_pii
    pii = classify_pii(content)
    policy = {
        "PII_PASSport": "block",
        "PII_CreditCard": "block+alert",
        "PII_Phone": "alert_only",
    }
    actions = []
    for kind, found in pii.items():
        if found and policy.get(kind) == "block":
            actions.append(f"block:{kind}")
        if found and "alert" in policy.get(kind, ""):
            actions.append(f"alert:{kind}")
    return {"actions": actions, "detected": pii}

def enforce_saas_policy(file_meta, content, saas_api):
    """依据 DLP 策略执行:阻断或告警。"""
    result = scan_uploaded_file_for_pii(file_meta, content)
    if any(a.startswith("block") for a in result["actions"]):
        saas_api.abort_upload(file_meta["id"])
        alert_security(file_meta["user"], result["detected"])
        return "blocked"
    return "allowed"

4.4 影子 IT 发现

def discover_shadow_it(access_logs, known_apps: set) -> list[dict]:
    """从代理/日志中发现未批准的云应用访问。"""
    shadow = []
    for app in extract_cloud_apps(access_logs):
        if app not in known_apps:
            shadow.append({
                "app": app,
                "users": distinct_users_for(app),
                "bandwidth": bandwidth_for(app),
                "risk": assess_app_risk(app),
            })
    return sorted(shadow, key=lambda s: s["risk"], reverse=True)

五、SASE 的策略编排

5.1 统一策略:身份驱动 + 集中编排

策略编排目标:
  · 一个控制台管理所有边缘能力
  · 策略以"身份/设备/应用"为对象,而非 IP
  · 一次定义,全局分发到所有 PoP

策略示例:
  if 用户.role in {finance} and 设备.合规 and 应用 == "财务系统":
      允许访问 + DLP 检查
  else if 应用 == "高风险SaaS" and 未批准:
      阻断 + 告警

5.2 策略即代码

# sase_policy.yml — 声明式 SASE 策略(示意)
version: "1.0"
policies:
  - name: finance-app-access
    action: allow
    when:
      identity: {roles: ["finance.*"]}
      device: {status: compliant, mdm: enrolled}
      app: {type: internal, group: "finance-apps"}
    checks: [dlp, data_encryption]

  - name: block-high-risk-saas
    action: block
    when:
      app: {risk: high, category: ["file_sharing", "shadow_it"]}
      user: {except: ["approvers@corp.com"]}
    notify: security-team

  - name: web-access-default
    action: inspect
    when:
      destination: {category: "general-internet"}
    checks: [malware_scan, url_reputation]
# policy_engine.py — 策略引擎
def evaluate_sase_policy(subject: dict, resource: dict, policies: list) -> dict:
    """按序匹配策略:命中即执行动作。"""
    for policy in policies:
        if matches(subject, resource, policy["when"]):
            return {
                "policy": policy["name"],
                "action": policy["action"],
                "checks": policy.get("checks", []),
            }
    return {"action": "block", "reason": "no-match-default-deny"}   # 默认拒绝

5.3 默认拒绝的兜底

def build_default_deny(known_roles, known_apps):
    """任何未匹配策略的访问一律拒绝(零信任兜底)。"""
    def evaluate(subject, resource):
        if subject["role"] not in known_roles:
            return "block:unknown-role"
        if resource["id"] not in known_apps:
            return "block:unknown-app"
        return "allow"
    return evaluate

六、DLP 与数据安全在 SASE 中的位置

6.1 DLP 的分层

层覆盖手段
网络 DLP进出流量内容检测、特征匹配
端点 DLP终端设备外设控制、剪贴板监控
云 DLPSaaS/云存储API 扫描、权限治理
邮件 DLP邮件外发附件与正文检测

6.2 数据分类驱动的 DLP

# dlp_classification.py
DATA_CLASSES = {
    "credit_card": r"\b(?:\d[ -]*?){13,16}\b",
    "cn_id":       r"\b\d{17}[\dXx]\b",
    "passport":    r"[A-Z]\d{7}",
    "source_code": r"(?s)(def |class |function )",
    "secret_key":  r"(?i)(api[_-]?key|secret|token)\s*[=:]\s*['\"][^'\"]+",
}

def classify_and_respond(content, destination, dlp_policy):
    detections = {k: bool(pattern.search(content))
                  for k, pattern in DATA_CLASSES.items()}
    actions = []
    for kind, detected in detections.items():
        if detected:
            action = dlp_policy.get(kind, "alert")
            actions.append(f"{action}:{kind} to {destination}")
    if any("block" in a for a in actions):
        return {"verdict": "block", "actions": actions}
    if actions:
        return {"verdict": "alert", "actions": actions}
    return {"verdict": "allow", "actions": []}

七、落地实施路径

7.1 分阶段迁移

阶段 1(评估):盘点 SaaS 应用、影子 IT、流量分布
阶段 2(试点):选一条业务线开通 ZTNA + CASB,验证体验
阶段 3(扩展):SWG 接管 Web 访问,FWaaS 替代部分硬件
阶段 4(整合):SD-WAN 升级,策略统一编排
阶段 5(常态化):持续 DLP、行为分析、策略优化

7.2 选型矩阵

厂商/方案强项适用
ZscalerZTNA + 云安全旗舰大企业全球化
Cloudflare边缘网络 + Tunnel/ZTNA偏网络与开发团队
NetskopeCASB + DLP 强重 SaaS 治理
Palo Alto Prisma统一 SASE 平台已有 PA 生态
开源组合Tailscale + OPA + 自研小团队、可定制

7.3 迁移的权衡

维度传统SASE迁移注意
延迟回程高边缘低选好 PoP 就近
成本硬件 CapEx订阅 OpEx算 TCO
运维多台设备单控制台简化但依赖厂商
合规数据出境自控边缘 PoP 位置确认数据流经哪里

八、SASE 与现有安全栈的协同

8.1 与零信任 IAM 的协同

SASE 依赖强身份:
  企业 SSO → SASE 验证身份 → ZTNA 授权应用
  IAM(Entra ID / Okta)提供身份权威
  设备证书 + MDM 提供设备状态
  风险评分(Behavioral)动态调整访问

8.2 与 SIEM/SOC 的集成

# 将 SASE 事件接入 SIEM
def forward_sase_events(sase_api, siem_client, poll_interval=60):
    """拉取 SASE 安全事件,标准化后送入 SIEM。"""
    while True:
        events = sase_api.get_events(cursor=last_cursor)
        for ev in events:
            siem_client.send(normalize_sase_event(ev))   # 统一格式
        sleep(poll_interval)

# 关键事件类型:
#  - blocked_access(拒绝访问)
#  - risky_behavior(风险行为)
#  - shadow_it_detected(影子应用)
#  - dlp_violation(数据泄漏)

8.3 与 DLP/数据防泄漏的联动

def sase_dlp_reaction(sase_event, response_playbook):
    """根据 SASE 事件触发响应剧本。"""
    if sase_event["type"] == "dlp_violation":
        response_playbook.execute([
            revoke_user_access(sase_event["user"]),
            require_mfa_re_auth(sase_event["user"]),
            quarantine_file(sase_event["file_id"]),
            notify_dpo(),
        ])

九、SASE 的评测与持续优化

9.1 有效性评估指标

def assess_sase_deployment(sase_metrics) -> dict:
    """评估 SASE 部署的安全与体验效果。"""
    return {
        # 安全效果
        "blocked_threats": sase_metrics["blocked_malware"],
        "shadow_it_reduced": pct_change(shadow_it_before, shadow_it_now),
        "dlp_violations": sase_metrics["dlp_count"],
        "lateral_exposure": sase_metrics["ztna_exposed_surface"],
        # 用户体验
        "avg_latency": sase_metrics["edge_latency_ms"],
        "vpn_incidents": sase_metrics["vpn_outages"],
    }

9.2 红队演练:SASE 是否真的有效

演练场景:
  1. 绕过 ZTNA:用非授权账号/设备访问私有应用 → 应被拒
  2. 数据外泄:向网盘上传含信用卡数据 → DLP 应拦截
  3. 恶意站点:访问已知钓鱼域名 → SWG 应阻断
  4. 影子应用:未批准 SaaS 的流量 → 应被发现/阻断

9.3 持续优化清单

  • 策略以身份驱动,非 IP 驱动
  • 未匹配策略默认拒绝
  • 高风险 SaaS 全部在 CASB 治理内
  • DLP 覆盖主要数据类别
  • 安全事件接入 SIEM,告警闭环
  • 定期红队验证 + 策略评审

总结:SASE 落地的核心框架

支柱关键能力落地要点
网络SD-WAN + 边缘 PoP就近接入,降低延迟
访问ZTNA 零信任应用级授权,默认拒绝
云治理CASB影子 IT、权限、DLP
WebSWG恶意过滤、URL 控制
策略统一编排身份驱动,一次定义全局分发

SASE 的本质,是安全架构对"流量逃离传统边界"这一现实的回应——安全能力不再捆绑在数据中心,而是跟随用户分布在网络边缘。它把零信任的"身份验证 + 最小授权"从理念落为可运营的能力,把分散的 VPN、防火墙、DLP、云治理整合进一套身份驱动的统一策略。落地时抓住三条主线:先盘点(流量、SaaS、影子 IT)、再试点(ZTNA + CASB 验证)、后扩展(SWG、DLP、统一编排)——加上持续的红队验证,SASE 就能成为覆盖员工、应用与数据全场景的新一代安全边界。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「Security」更多文章

  1. 配置漂移与安全基线:IaC漂移检测、CIS合规、供应链安全与密钥轮换
  2. 网络微分段与零信任落地:从平面网络到按需互通的隔离架构
  3. 文件上传安全实战:从恶意文件检测到存储隔离的纵深防御