零信任、VPN 与 TLS 检查各自负责不同的事

采购文件把零信任、VPN 和 TLS 检查当作同一次采购，而它们各自回答另外两者答不了的问题。隧道建立一条受保护的路径，检查网关读取它能够终止的流量，而策略决定某个具名身份能否对某个具名资源执行某个具名操作。只有最后一个是授权决定。一个产品可以把前两件事做得完美，却仍然把真正的问题留在原处。

三种机制，三个问题

隧道回答流量如何抵达网络。检查网关回答中间设备在获准终止 TLS 的地方能看到什么、能做什么。策略引擎回答谁可以对哪个资源做什么，然后它需要一个能够执行该答案的执行点。NIST 的零信任架构把资源放在中心，并拒绝从数据包来自哪里推断信任。

这套框架比一个标签更难满足，在评审中也更难伪造。它还把问题从部署了哪些产品，移到哪些决定被执行、由什么执行。

决定究竟在哪里被执行

拿一个请求来说：支持工程师打开服务控制台，而插在同一台交换机上的个人电脑不能仅仅因为在旁边就继承那份权限。写下被允许的操作、设备条件以及执行这些条件的组件。放置位置决定一切：应用网关、服务代理、主机控制，或组织真正支持的另一个边界。无论那个组件是什么，它都必须位于远程和本地尝试的路径上。

从不经过 VPN 入口的流量，不受在那里执行的检查所管辖，无论那项检查多么彻底。正是这一个缺口解释了零信任示意图与可用部署之间的大部分距离。先画出请求路径，再画架构。

解密不是授权

拦截服务于狭窄的检查目标，并自带证书、受信任根、隐私审查以及在其下会失效的应用等负担。这些都不是零信任的含义，也都不替代策略决定。认证一个人、授权一项服务，完全可以在不解密任何一个数据包的情况下完成。被解密的流量并不能说明用户是否有权执行其中承载的操作。

策略需要一种证据，而解密不是。设备健康状况是身份、资源敏感度和上下文之间的一项输入，通过一次并不会把剩下的网络交给那台机器。把两者混为一谈，会把授权问题变成证书项目。

当网关根本不在路径上时

清点那些不经过远程网关就能通行的东西：本地网段内机器之间的连接、从一个工作负载到另一个工作负载的调用，以及在云账户内直接到达的端点。对每条路径，说出一种今天确实可以部署的执行方式。无法承载代理的设备仍然需要另一种明确受支持的管控，而假定代理以后会到位，现在什么也没有关上。服务到服务的访问，通常比再加一层叠加网络更适合工作负载身份和针对资源编写的检查。

按行为而不是按示意图来验收设计：哪些操作被允许、哪些被拒绝、每个答案在哪里执行。对具体的允许与拒绝操作签字确认，并纳入一条永远到不了网关的本地路由。记录谁拥有策略、它如何变化以及吊销如何运作。

改了标签的隧道仍然是隧道。策略做决定，并且必须有东西去执行它。