当员工分散办公、应用迁往 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 维度 传统 VPN ZTNA 访问模型 接入网络(一接入即见全内网) 接入应用(只开放授权应用) 授权粒度 网络级 应用/端口级 身份验证 较弱(静态密码常见) 强(持续身份 + 设备合规) 横向移动 一旦接入可扫全内网 不可见即不可攻 隐含信任 内网可信 永不信任,始终验证
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 终端设备 外设控制、剪贴板监控 云 DLP SaaS/云存储 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 选型矩阵 厂商/方案 强项 适用 Zscaler ZTNA + 云安全旗舰 大企业全球化 Cloudflare 边缘网络 + Tunnel/ZTNA 偏网络与开发团队 Netskope CASB + 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 持续优化清单 总结:SASE 落地的核心框架 支柱 关键能力 落地要点 网络 SD-WAN + 边缘 PoP 就近接入,降低延迟 访问 ZTNA 零信任 应用级授权,默认拒绝 云治理 CASB 影子 IT、权限、DLP Web SWG 恶意过滤、URL 控制 策略 统一编排 身份驱动,一次定义全局分发
SASE 的本质,是安全架构对"流量逃离传统边界"这一现实的回应——安全能力不再捆绑在数据中心,而是跟随用户分布在网络边缘 。它把零信任的"身份验证 + 最小授权"从理念落为可运营的能力,把分散的 VPN、防火墙、DLP、云治理整合进一套身份驱动的统一策略。落地时抓住三条主线:先盘点 (流量、SaaS、影子 IT)、再试点 (ZTNA + CASB 验证)、后扩展 (SWG、DLP、统一编排)——加上持续的红队验证,SASE 就能成为覆盖员工、应用与数据全场景的新一代安全边界。
继续阅读
探索更多技术文章 浏览归档,发现更多关于系统设计、工具链和工程实践的内容。