零信任架构下的身份认证：从「信任但验证」到「永不信任」

城堡的崩塌

二十年前，企业安全模型很简单：砌一堵高墙。

办公网 = 可信区域
VPN 隧道 = 远程员工进入可信区域的通道
防火墙 = 护城河，墙外皆为威胁

这个模型基于一个核心假设：内网是安全的，外网是危险的。 进了城堡，就是自己人。

到了 2026 年，这个模型已经彻底瓦解。原因如下：

边界已经模糊。 你的员工在咖啡馆用公共 Wi-Fi 办公，核心服务跑在云上，客户从世界各地通过 API 访问你的数据，CI/CD 流水线运行在第三方平台上，微服务之间通过公网通信。内网在哪里？

凭据泄露让内网变得不可信。 一名员工的 VPN 密码被钓鱼——攻击者就进入了可信区域。一个硬编码的 API Key 泄露到 GitHub 上——攻击者就能在可信区域内自由活动。在传统的横向移动攻击中，攻击者一旦突破外围，就能在整个内网中畅通无阻。

内部威胁真实存在。 居心不良的员工、被社工利用的不知情同事、离职前导出数据的员工——他们本就在可信区域内，根本不需要突破边界。

NIST SP 800-207 指出：零信任的核心原则是消除隐式信任——不再因为用户或设备位于内网就默认信任它们。

零信任的三大支柱

支柱一：永不信任，始终验证

在零信任模型中，每一次访问请求都从头评估：

Request: User A wants to access the customer database
     |
     +-- Is User A's identity verified? - MFA confirm
     +-- Does User A's current role have database access? - RBAC check
     +-- Is User A's device compliant with security policy? - Device compliance check
     +-- Is User A's session risk score within threshold? - Risk engine
     +-- Does User A have permission for this operation? - Fine-grained authorization
     +-- Is the current time/location/behavior pattern normal? - Behavioral analysis
     |
     Allow / Deny / Require additional verification

关键区别在于：这些检查不是登录时做一次就信任 8 小时——而是可以在每次请求时重新评估。

支柱二：最小权限

用户拥有的权限，永远不应超过当前任务所需：

即时访问（JIT）：权限不是永久授予，而是在需要时临时激活，用完自动回收
角色与权限分离：一个人可以拥有多个角色，但只有当前激活角色的权限生效
数据级访问控制：不是「你能访问客户数据库」，而是「你能访问客户数据库中你负责的那部分数据」

Autional 的 RBAC 系统实现了动态角色激活：

# Developer normally has read-only permissions
roles: [developer:read]

# When emergency fix is needed, temporary privilege escalation
jit_access:
  role: developer:write
  reason: "Fix urgent issue #4521 in payment module"
  ttl: 1h
  approval_required: true
  approver: security_admin

支柱三：假设已被攻破

在零信任模型中，不假设你的防御是完美的。恰恰相反——假设攻击者已经在网络内部：

微隔离：即使在同一数据中心内，除非显式授权，服务 A 也不能直接访问服务 B 的数据库
全面加密：所有服务间通信强制 TLS，即使运行在同一台物理机上
持续监控：不只是入侵检测，而是与行为基线持续比对——该账号过去 30 天平均每天导出 12MB，今天却突然导出了 2GB

持续验证：动态的会话信任评估

传统认证模型的问题在于：认证是一次性的，信任是持续的。

用户登录后拿到一个 Session Token，在接下来的 8 小时里，系统无条件信任这个令牌。即便这 8 小时内，用户的 IP 从北京跳到纽约，设备从公司笔记本换成陌生的 Android 手机，行为从查看文档变成导出全部客户数据——系统也毫无察觉，因为令牌是有效的。

零信任要求持续验证——在会话的整个生命周期中动态评估信任级别：

Autional 的持续验证引擎

Session established: trust score 100
    |
Every 5 minutes or before each sensitive operation: recalculate trust score
    |
Trust score adjustment factors:
    - 15 minutes no activity                    -5
    - IP address change (same city, same ISP)   -10
    - IP address change (cross-country)         -50
    - Device fingerprint mismatch               -60
    - Requesting sensitive data not normally accessed -20
    - Requesting high-privilege API never called before -40
    - Known attack pattern detected             -80
    - Identity reconfirmed with hardware key    +30
    |
Trust score < 50  → Require re-authentication (Step-Up Auth)
Trust score < 20  → Immediately terminate session, generate security event
Trust score >= 50 → Continue normal access

flowchart TD
    A["会话建立——信任分 100"] --> B["每 5 分钟或敏感操作前重算信任分"]
    B --> C{"重算后的信任分"}
    C -->|"低于 50"| D["要求重新认证——Step-Up"]
    C -->|"低于 20"| E["立即终止会话并生成安全事件"]
    C -->|"不低于 50"| F["继续正常访问"]

图 1：会话信任分的动态评估——从登录时的 100 分出发，系统持续重算；跌破 50 分触发增强认证，跌破 20 分直接终止会话。

这种动态评估让被盗的令牌变得毫无价值——即使攻击者拿到了有效的 Session Token，当行为模式发生剧烈变化时，他也无法继续使用。

设备安全态势评估

零信任不只验证你是谁，还要验证你使用的设备是否可信：

设备是否已注册？ 未注册设备即使凭据有效也受到限制
操作系统是否已打补丁？ 存在已知漏洞的系统版本会降低信任分
杀毒/EDR 是否在运行？ 缺少端点防护的设备自动降级
是否被 root/越狱？ 已被破解的移动设备只给只读权限
磁盘是否加密？ 未开启全盘加密的设备禁止下载数据
企业证书是否有效？ BYOD 设备需要配置企业 MDM

Autional 对接 MDM/EDR 系统获取设备合规状态，并将这些信号纳入持续信任评估。

自适应增强认证

当信任分跌破阈值时，系统不会立即拒绝访问——那会影响正常用户的工作效率——而是触发增强认证（Step-Up）：

轻度降级（信任分 40-50）：弹出 WebAuthn 生物特征确认，通过后恢复信任分
中度降级（信任分 20-40）：要求重新完成一次完整 MFA 流程
重度降级（信任分 < 20）：终止会话 + 账号临时受限 + 通知安全团队

# Autional Step-Up authentication policy example
step_up_policies:
  - trigger: trust_score_below(50)
    action: require_webauthn
    message: "Abnormal activity detected. Please confirm your identity with a security key."
  - trigger: trust_score_below(30)
    action: require_full_mfa
    message: "Identity re-verification required. Please complete multi-factor authentication."
  - trigger: device_first_seen AND sensitive_operation
    action: require_totp_plus_approval
    message: "First sensitive operation on new device requires admin approval."

API 层的零信任：服务间调用的持续认证

在微服务架构中，零信任不只作用于用户层——服务之间的内部 API 调用同样不能信任内网。

在传统模型中，服务 A 调用服务 B 只需要一个静态的内部 API Key——配好之后永久有效。在零信任模型中：

Autional 的服务间认证架构

Service A wants to call Service B's internal API
    |
    +-- Check mTLS certificate: Is Service A's identity certificate valid?
    +-- Check service-level API Key: Does it match and is it not expired?
    +-- Check if the call originates from an allowed source service?
    +-- Check if it's calling an API scope the service is authorized for?
    +-- Record complete audit log of this call (hash chain protected)
    |
    Allow / Deny

关键设计决策：

无隐式信任：即使两个服务运行在同一个 Kubernetes 集群、同一个 namespace 中，也不能默认它们可以自由通信
证书自动轮换：服务间 mTLS 证书由 Autional 基础设施自动签发与轮换，无需人工操作
单向调用链：只允许预定义的服务调用关系。如果 compliance-service 从未被定义为 session-service 的合法调用方，即使 API Key 有效也会被拒绝
全量审计：每一次服务间调用都有记录，并受哈希链保护

从城堡到城市：安全模型的哲学转变

理解零信任最好的方式，是重新想象安全的隐喻：

城堡-护城河模型（旧模型）：

砌一堵高墙。墙内皆安全，墙外皆危险。在门口查验通行证，进门之后便可自由活动。

城市模型（零信任模型）：

城市没有围墙。每栋建筑都有自己的门禁，每条街道都有监控。进入城市不需要通行证，但进入每栋楼、每个房间都要单独验证。你走的每一步，都会产生信任评估信号。

在城市模型中：

VPN 不再是万能钥匙——它只是让你走上城市街道
数据库不再是「内网数据库」——它是需要单独门禁卡的建筑
管理员不再拥有上帝视角——他们只能在自己被授权的区域内查看与操作

零信任落地的渐进路径

从传统安全架构迁移到零信任不是一次性切换。Autional 建议采用渐进式迁移路径：

阶段一：可视化（1-3 个月）

在限制任何东西之前，先看清现状：

盘点所有服务、API 及其调用关系
绘制完整的微服务依赖拓扑
识别所有在用的 API Key 及其权限范围
记录所有用户会话的活动模式

阶段二：身份加固（2-4 个月）

为所有用户启用 MFA（至少 TOTP）
管理员账号强制 WebAuthn
引入设备指纹，建立每用户的设备清单
把 API Key 从静态共享密钥迁移为基于哈希的短期令牌

阶段三：动态信任（3-6 个月）

部署会话持续验证引擎
启用自适应增强认证
落地服务间 mTLS
建立行为基线，开启异常检测

阶段四：精细化（持续）

落地 JIT 提权
微隔离服务间通信
基于风险的 API 访问控制
安全编排与自动化响应（SOAR）

结语

零信任不是一个产品，也不是一个功能——它是一种安全理念。它不是部署了 Autional 就能「打开」的开关，而是 Autional 作为平台所支撑的一次思维转变。

从「信任但验证」到「永不信任」——这不仅是安全模型的演进，更是对现实的承认：在 2026 年的数字世界里，边界已经消失。唯一可靠的安全假设是：每一个请求都可能是恶意的，每一秒都需要验证。

而这种持续不断、永不停歇的验证，正是 Autional 存在的意义。