SASE 安全访问服务边缘实战：统一 SD-WAN 与安全策略

Q: SASE 和零信任有什么区别？

SASE 是产品形态（网络+安全的统一交付），零信任是设计理念（永不信任、始终验证）。SASE 可以实现零信任，但零信任也可以用传统方案实现。简单说：SASE 是车，零信任是驾驶规则。

Q: ZTNA 和 VPN 到底该用哪个？

远程办公人员用 ZTNA，内网设备互通用 VPN 或微分段。ZTNA 是身份驱动，VPN 是网络位置驱动。ZTNA 对 SaaS 应用体验更好，VPN 对内网资源控制更细。大多数公司需要两者并存，不能二选一。

Q: SASE 套件太贵怎么办？

三条退路：① 先用开源方案搭 SD-WAN（VyOS/OPNsense）+ 自管 SWG（Squid + Dansguardian）过渡；② 云上 SASE（AWS Network Firewall + Transit Gateway）；③ 按分支数量谈厂商价格，小批量采购可以砍价 30% 以上。

SASE（Secure Access Service Edge）这个词从 2019 年 Gartner 提出来到现在，厂商炒了快七年，很多团队还在纠结"到底该买还是该自建"。这篇文章不谈概念，直接说三件事：你的场景该走哪条路、ZTNA 和 VPN 怎么分工、分支加速和安全策略怎么不落单。

SASE 是什么，先说人话

SASE = SD-WAN（网络层）+ 安全栈（SWG / ZTNA / DLP / SASE Firewall）统一交付到一个边缘节点。本质是把"分支走总部出公网"和"用户回家直接走公网"两种方式，换成"所有流量都收敛到云安全网关"。

两种架构的对比很直接：

传统架构：
分支 → IPSec → 总部防火墙 → 互联网 / SaaS
         ↑
         安全能力分散在总部

SASE 架构：
分支 → SASE 边缘节点（安全）→ 互联网 / SaaS
用户   → SASE 边缘节点（安全）→ 互联网 / SaaS
         ↑
         网络和安全统一收敛在边缘

SASE 的核心价值不是安全更强——是安全策略和转发策略不再打架。传统架构里 IT 和安全各管各的，SD-WAN 说"这路径快"，安全说"这条路不能走"，两边对不上。SASE 把这两个决策合到一起，策略一次生效。

三条落地路径，选哪条取决于你的规模

路径一：买成熟 SASE 套件（推荐 50+ 分支 / 1000+ 用户）

代表厂商：Zscaler、CrowdStrike SASE、Palo Alto Prisma Access、Cisco Secure Connect。

这类方案的优点是策略统一、管理界面现成、全球边缘节点覆盖。缺点是贵，且厂商锁定。

选型决策树：

你有几个分支？
├─ 少于 10 个分支 → 先看路径二（自建轻量方案）
└─ 10 个以上分支
    ├─ 用户主要访问 SaaS（Office 365 / Google Workspace）→ ZTNA 优先
    ├─ 用户主要访问内网应用 → SD-WAN 优先
    └─ 两者都多 → 直接上 SASE 套件

实际案例：一家 80 分支、1200 人的电商公司，上线 Zscaler 后 SaaS 访问延迟从 300ms 降到 80ms，但年度成本从 40 万涨到 90 万。IT 负责人当时的判断是"值"，因为排障时间从每周 15 小时降到 2 小时。

路径二：自建 SWG + SD-WAN + IAD（适合 10-50 分支、预算有限）

用开源组件拼凑：

# SD-WAN：VyOS（跑在 x86 小机器或虚拟机上）
# 官网：https://www.vyos.io/
# 分支节点配置示例（简化）：
set interfaces ethernet eth0 address 10.0.1.1/24
set interfaces ethernet eth1 address 'pppoe0'
set protocol flow-accounting enable

# SWG：Squid + Dansguardian（开源透明代理）
apt install squid dansguardian
# 配置 /etc/squid/squid.conf 的访问控制
acl safe_urls dstdomain "/etc/squid/safe_urls.txt"
http_access allow safe_urls
http_access deny all

这条路径的成本极低，但运维负担不低。安全策略要自己维护，厂商支持要自己承担。适合有 2-3 个专职网络工程师的团队。

路径三：云上 SASE（AWS / 阿里云 / Azure 原生方案）

如果你已经重度依赖某家云，用云原生方案比买第三方套件便宜且集成度高。

AWS 示例：

# 1. 创建 SASE 边界（AWS Network Firewall）
aws network-firewall create-firewall \
    --firewall-name sase-fw \
    --subnets subnet-abc1 subnet-def2 subnet-ghi3 \
    --vpc-id vpc-12345678

# 2. Transit Gateway 做分支汇聚
aws ec2 create-transit-gateway \
    --region us-east-1 \
    --amazon-side-asn 64512

# 3. 分支 VPN 连接到 TGW
aws ec2 create-vpn-connection \
    --transit-gateway-id tgw-xxxxxx \
    --type ipsec.1 \
    --static-routes-only \
    --vgw-id vgw-yyyyyy

阿里云对应的是 SD-WAN 插件 + Cloud Enterprise Network（CEN）+ 云防火墙的组合，逻辑相同。

ZTNA vs VPN：怎么分工不用吵架

这是落地时最容易扯皮的地方。我的判断很简单：

ZTNA 负责远程办公人员访问 SaaS 和应用——不需要知道内网 IP，只要身份认证通过就能访问指定应用
VPN 负责内网设备互访和遗留系统——某些老系统不支持应用层网关，只能通过 L2/L3 VPN 访问

具体策略：

# ZTNA 策略示例（Zscaler 风格）
identity_provider: Okta / Azure AD
default_action: deny-all
permitted_apps:
  - app: office365
    users: all
  - app: internal-wiki
    users: ["security-team", "eng-leads"]
  - app: dev-k8s-dashboard
    users: ["dev-team"]
    conditions:
      - device_posture: enrolled
      - location: not_china

# 传统 VPN 策略（保留给不能用 ZTNA 的系统）
# OpenConnect 服务端配置（OCServ）
port = 443
protocol = ocserv
auth = "plain[try_first_pass]"
dns = 10.0.0.1
mtu = 1400
ipv4-network = 10.10.0.0/24
ipv4-netmask = 255.255.255.0
max-clients = 200

常见错误：把 VPN 当万能钥匙。某公司所有远程办公都走 VPN，结果内网带宽被占满，SaaS 体验反而比不用 VPN 还差。VPN 是为遗留系统保留的，不是默认选项。

分支加速：SD-WAN 的核心价值

SD-WAN 的价值不只是安全，还有一个经常被忽视的点：分支到互联网的加速。传统架构下，分支访问互联网要绕回总部出公网，延迟极高。SD-WAN 让分支流量就地出站，SASE 边缘节点负责安全检查。

传统：分支 A → 总部（300km）→ 互联网
SD-WAN：分支 A → SASE 边缘（最近）→ 互联网

实测数据（某零售连锁，50 个门店）：

场景	传统 WAN	SD-WAN + SASE
门店到总部 ERP	120ms	85ms（走 MPLS）
门店到 SaaS（办公套件）	350ms（绕总部）	60ms（本地出口）
门店到云存储	400ms	55ms
安全策略统一性	低（各店各自为政）	高（云端统一下发）

部署前必做的三件事

1. 盘点现有分支网络拓扑

别急着上方案，先把分支列表搞清楚：

# 收集分支网络信息
for branch in $(cat branches.txt); do
    echo "=== $branch ==="
    ssh $branch "echo 'LAN:'; ip addr show | grep 'inet '; echo 'WAN:'; 
    ip addr show pppoe0 2>/dev/null | grep 'inet '; 
    echo 'ISP:'; cat /etc/resolv.conf | head -2"
done > branch-inventory.txt

2. 确定身份源和 MFA 策略

ZTNA 的前提是有身份系统。没有身份，SASE 就是无源之水。

身份源优先级：
① 企业现有 IdP（Azure AD / Okta / Keycloak）
② 如果没有，先在 SASE 平台上建本地目录
③ 必须开 MFA，否则等于没加安全

3. 灰度上线顺序

Phase 1：先上一个分支试点（选网络条件最差的）
Phase 2：确认 SaaS 体验改善后，扩展到 10 个分支
Phase 3：全量切换，保留传统路径作为 fallback 7 天
Phase 4：关闭传统路径，完全走 SASE

失败案例：某公司 Phase 1 没做，直接全量切换，第二天 20 个分支同时断网，因为 SASE 边缘节点配置有误。恢复用了 6 小时，损失超百万。永远先试点再全量。

Cheat Sheet：常见操作速查

# 检查分支到 SASE 边缘的连通性
ping -c 5 <sase-edge-host>

# 检查安全策略是否生效（Zscaler 示例）
zia api --query "traffic:logs?date=today&policyViolation=true" | jq '.[] | {src_ip, dst_url, policy}'

# 查看 SD-WAN 链路质量
# VyOS 示例
show sdwan interface
show sdwan app-qos statistic

# 检查 ZTNA 连接状态（Zscaler）
zti status

总结与判断

SASE 不是必选项。如果你的场景是"全部用户在办公室、只有少量远程办公"，传统 VPN + 边界防火墙就够。SASE 的价值主要在两种场景：① 分支多且分散；② 用户远程办公比例高且 SaaS 依赖深。

我的判断：对于中小型企业（50 分支以下），路径二（自建）或路径三（云上原生）性价比更高。路径一（买套件）适合预算充足、不想养运维团队的公司。不管走哪条路，ZTNA 取代 VPN 是大趋势，越早布局越早受益。