跳转至

零信任网络架构:从概念到企业落地

零信任这个词被炒了五年,很多人以为买一个 ZTNA 产品就等于上了零信任。错了。零信任是一种架构理念,它的核心是"永不信任、始终验证"——身份为根,每一次访问请求都要重新验证,而不是一旦进门就一路绿灯。

这篇文章不谈概念,直接说怎么落地:身份系统集成、NAC 对接、微分段策略、以及几个容易翻车的点。

零信任三原则,先搞清楚

原则 含义 落地手段
身份为根 每个请求都要验证身份,不信任网络位置 IdP + MFA + 设备信任
持续验证 不是一次验证终身有效,每次访问都要重新评估 行为分析 + 动态策略
最小权限 只给访问所需的最小权限,不多给 基于身份的 ACL + 微分段

三个原则缺一不可。只做了身份验证没做持续验证,等于传统零信任(进门验身份证但不监控行为)。只做最小权限没有身份验证,权限分配没有依据。

落地路线图:四个阶段别跳步

Phase 1:身份治理(1-2 个月)

这是最容易被低估的阶段。没有干净的身份数据,后面所有策略都是空中楼阁。

# 盘点现有身份源
# 1. 找出所有身份系统
find /etc -name "*.conf" | xargs grep -l "ldap\|saml\|oauth" 2>/dev/null
# 2. 导出用户列表(示例:LDAP)
ldapsearch -x -H ldap://idp.internal -b "dc=company,dc=com" \
    "(objectClass=person)" uid employeeType

# 3. 检查 MFA 覆盖率
# 检查各系统的 MFA 启用率
mysql -e "SELECT provider, COUNT(*) FROM mfa_settings GROUP BY provider;"

关键指标: - 100% 关键账号(管理员、研发、财务)有 MFA - 离职账号 5 分钟内禁用 - 身份数据来自单一来源(SSO)

踩坑:某公司先上了 ZTNA,发现身份系统里有 200 个离职账号还在活跃。零信任变成"零清除"——该访问的还是能访问。身份治理必须先于零信任上线。

Phase 2:NAC 对接(2-4 周)

网络访问控制(NAC)是零信任的入口。设备没进 NAC,就进不了内网。

# 常见 NAC 设备对接(以 Aruba ClearPass 为例)
# 1. 注册终端设备
# 终端安装 agent 或走 802.1x
# 2. 策略引擎配置
# 设备类型识别 → 合规检查 → 分配 VLAN/ACL
# 3. 与 IdP 集成
# RADIUS → LDAP/Okta 验证身份
# 示例:设备合规检查脚本(Python)
def check_device_compliance(device_id):
    """检查设备是否符合安全基线"""
    checks = {
        "disk_encryption": check_bitlocker_or_fips(device_id),
        "antivirus": check_endpoint_protection(device_id),
        "os_updates": check_patch_level(device_id),
        "jailbreak": check_jailbreak_status(device_id),
    }

    # 全部通过才放行
    if all(checks.values()):
        return {"action": "allow", "vlan": "corporate"}
    elif sum(checks.values()) >= 3:
        return {"action": "quarantine", "vlan": "remediation"}
    else:
        return {"action": "deny"}

NAC 策略决策树:

设备连接网络
  │
  ├─ 是公司资产(已注册)?
  │   ├─ 是 → 检查合规性
  │   │   ├─ 合规 → 允许接入(正常 VLAN)
  │   │   └─ 不合规 → 隔离 VLAN(提醒修复)
  │   └─ 否 → 访客网络
  │
  └─ 访客?
      ├─ 有预约 → 临时账号 + 8 小时 TTL
      └─ 无预约 → 拒绝或重定向到预约页面

Phase 3:微分段(4-8 周)

微分段是零信任的核心技术手段。把大网络切成小块,每块内部有独立的安全策略。详细的 K8s NetworkPolicy YAML 示例见 micro-segmentation.md。

微分段策略设计原则: 1. 按业务域分,不按部门分("订单系统"是一个段,不是"财务部"一个段) 2. 默认拒绝,按需放行 3. 保留审计日志

Phase 4:SASE / ZTNA 集成(4-8 周)

远程办公场景需要 ZTNA。SASE 是把 SD-WAN 和 ZTNA 打包的方案。

# ZTNA 策略配置示例(通用格式)
identity_source: Okta
mfa_required: true
device_trust:
  - platform: "windows"
    requirements:
      - bitlocker: enabled
      - endpoint_protection: active
  - platform: "macos"
    requirements:
      - filevault: enabled
      - endpoint_protection: active
access_rules:
  - app: "internal-wiki"
    allow: ["all-employees"]
  - app: "financial-system"
    allow: ["finance-team"]
    conditions:
      - mfa_strong: true
      - device_location: "corporate"
  - app: "dev-environment"
    allow: ["dev-team"]
    conditions:
      - vpn_required: false  # 直接用 ZTNA 访问

身份系统集成方案

零信任的前提是有身份系统。以下是三种常见集成方案:

方案一:企业 IdP(推荐)

用户 → SSO(Okta / Azure AD / Keycloak)→ ZTNA → 应用
         ↑
    统一身份管理

关键配置:

# Okta SSO 配置示例
# 1. 创建应用集成
okta app-saml create \
    --label "Internal Wiki" \
    --audience "https://wiki.internal/saml" \
    --relying-party "https://wiki.internal/acs"

# 2. 配置属性映射
okta app-group assign \
    --app-id app_123456 \
    --group-id grp_789012

方案二:LDAP + MFA 网关

如果公司没有现代 IdP,可以用 LDAP + MFA 网关过渡:

# Nginx + MFA 网关配置(过渡方案)
server {
    listen 443 ssl;
    server_name wiki.internal;

    # 先做 MFA 验证
    location /mfa {
        auth_request /mfa-validate;
        proxy_pass http://mfa-server;
    }

    # 验证通过后转发到应用
    location / {
        proxy_pass http://wiki-backend;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-User-Id $remote_user;
    }
}

方案三:完全自建(不推荐)

自己实现身份系统、MFA、设备管理——除非你有特殊合规要求,否则不要走这条路。成熟产品比自建可靠得多。

常见翻车点

翻车 1:策略太松等于没策略

某公司上线零信任后,发现 90% 的请求都被放行了。原因在于策略是基于"默认允许"而不是"默认拒绝"。

# 错误策略(默认允许)
access_rules:
  - app: "all"
    allow: ["all"]  # 所有人都能访问所有应用

# 正确策略(默认拒绝)
access_rules:
  - app: "internal-wiki"
    allow: ["all-employees"]
  - app: "financial-system"
    allow: ["finance-team"]
  # 未列出的应用默认拒绝

翻车 2:忽略设备信任

只验证人、不验证设备。攻击者拿到 credentials 就能从任何设备访问。

# 设备信任检查逻辑
def validate_session(user, device, location):
    # 用户身份验证
    if not user.is_verified():
        return False

    # 设备信任检查
    if not device.is_trusted():
        return False

    # 位置异常检测
    if location.is_anomalous():
        return False

    return True

翻车 3:一次性验证

一次登录永久有效,违背持续验证原则。

# 正确的 session 策略
# 1. Session TTL 不超过 4 小时
session.timeout = 4h

# 2. 敏感操作要求重新验证
if action in ["delete", "transfer", "export"]:
    require_mfa()

# 3. 异常行为触发重新验证
if anomaly_score(user_behavior) > threshold:
    invalidate_session()
    require_reauth()

Cheat Sheet:部署检查清单

# 身份系统检查
✅ MFA 覆盖率 100%(关键账号)
✅ 离职账号自动禁用
✅ 单一身份源(SSO)
✅ 设备注册流程完整

# NAC 检查
✅ 所有终端接入需通过 NAC
✅ 设备合规检查自动化
✅ 访客网络隔离
✅ 审计日志完整

# 微分段检查
✅ 默认拒绝策略
✅ 按业务域分段
✅ 跨段访问有审批
✅ 策略变更有审计

# ZTNA 检查
✅ 远程访问走 ZTNA
✅ 设备信任检查
✅ 持续验证机制
✅ 异常行为告警

总结与判断

零信任不是买一个产品就能上的。它是一个逐步推进的过程:身份治理 → NAC 对接 → 微分段 → ZTNA。跳过任何一步都会导致策略失效。

我的判断:对于中小型企业,建议的启动顺序是:① 先做好身份治理(1-2 个月);② 上 ZTNA 解决远程办公(2-4 周);③ 再做微分段(可选,根据需求)。不要一开始就上全套,那样投入太大、见效太慢,容易半途而废。

延伸阅读