Skip to content

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

零信任这个词被炒了五年，很多人以为买一个 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 周）；③ 再做微分段（可选，根据需求）。不要一开始就上全套，那样投入太大、见效太慢，容易半途而废。

延伸阅读