面向带双因素认证的虚拟 VPN 网关的验收检查

供应商把这类设备说成虚拟的、支持双因素，而这两个词都没有回答决定采购的问题。支持哪种虚拟机镜像、哪些客户端可以注册、第二因素究竟证明了什么、身份提供方宕机时会发生什么，这些都还没有答案。把它们变成可以在演练中执行的验收阶段，决策就不再取决于说明书有多能说服人。下面的表是这些证据的结构，不是产品排名。

供应商必须就这次部署确认什么

先把部署压缩到一页：虚拟化平台或云、来宾架构、受支持的镜像，以及设备所期待的接口。再加上用户与其操作系统、设备是否受管，以及注册和登录应当如何工作。然后是私有访问：应用与前缀、DNS 安排、返回路径，以及公网出口是否在报价之内。

运维也属于同一页：谁维护设备、更新从哪里来、日志往哪里去、配置如何保护，以及业务真正同意的恢复目标是什么。请供应商确认的正是这一组合，而不是软件能跑在虚拟机里。把身份提供方、许可服务这类外部依赖显式列出，因为无论是否随设备交付，它们都是部署的一部分。没有点名任何依赖的部署页，通常意味着存在未知的依赖。

证明第二因素确实是第二因素

点明认证器与验证流程，并说明每一步确立了哪个身份。连续两次索要密码不是第二因素，而密码加一次性验证码与绑定到服务的密码学认证器是两种不同的主张。写下你买的流程，而不是盒子上的标签。

抗钓鱼是一项单独的属性，而 NIST 的认证器指南 正是这样看待它的：用户可能被骗转发的验证码仍然满足多因素认证，却不满足那项额外条件。若它在乎你，就明确要求这项属性。然后要求用用户实际使用的客户端类型做演示，覆盖注册、被拒绝或过期的挑战、认证器丢失后的恢复，以及在其他人保持连接的情况下吊销某一用户。把网关身份验证留在范围内，因为信任任意网关的客户端只是把问题挪走了，而没有解决。

在破坏任何东西之前写下通过条件

下面的表是这份表单在供应商面前真正站得住的部分，因为每一行要的是证据而不是承诺。在演练之前填好通过条件，并把没有证据的行当作未通过。五个阶段覆盖网关必须做到的事。

注册放在第一位，因为下游的一切都依赖它：无法注册的设备无法被测试。登录是独立于注册的阶段，而拒绝是大多数表单会忘掉的阶段，因为放所有人进来的网关并没有证明它拒绝过谁。吊销与恢复承担了大部分运维风险，而两者在副本上都便宜。

在副本上演练，而不是在正在运行的网关上

按受支持的部署流程，在平台副本上执行那些具有破坏性的阶段，并让每份证据带上日期与配置版本。重启这一行不能靠从控制台重启来交差，恢复这一行也不能靠导出配置来交差。记下哪些状态会自行恢复、哪些必须重新连接，因为运维团队继承的正是这个差别。演练也是唯一一次能在不解释故障的前提下为恢复计时的机会。

在每个测试的当下记录身份提供方的状态，因为对一个健康的提供方测试出的故障行，证明的恰好是表单所主张的反面。同一场演练的两位评审会发现不同的东西，第二位通常找到那一行——它的证据是一张控制台的截图。把那份证据附在它所属的那一行上，而不是放进以项目命名的文件夹。

测量你的团队将要跑的工作负载

先商定一个接近平常一周的负载，然后在你打算部署的地方测量它：并发量、流量构成，以及团队真正拥有的维护窗口。厂商宣传的吞吐数字描述的是实验室条件，对你的用户什么也没说。把恢复情况对着恢复目标去量，而不是对着计划。

当每个阶段都有证据、每份证据都有日期时，这份表单才算完成。有人维护、每一行都有证据的设备，与最长的一张打勾清单是两种不同的采购。