桌上摆着两种设计。一种把员工留在基于角色的 VLAN 中,人员调动时修改交换机端口。另一种对会话进行认证,并让策略决定它可以到达什么。这个选择与是否现代无关;关键在于三个条件在你的楼里是否成立。只要有一条不成立,基于端口的设计就不愚蠢,它才是你真正能运维的那一种。

这三个条件是可执行性、身份质量和故障时的行为。

条件 1:接入设备能否执行返回的策略

802.1X 是终端上的请求者、交换机或接入点中的认证者,以及通过 RADIUS 抵达的认证服务器之间的关系。服务器可以返回 VLAN 或其他策略结果,RFC 3580 描述了这种信令。交换机仍然必须实现你所依赖的那个结果。

要的应当是能力,而不是协议:动态 VLAN 分配、可下载的 ACL,或者重定向到注册门户。

条件 2:身份来源是否权威,是否易于快速变更

目录中的组成员关系只有在角色变更时业务本来就会编辑的那个字段上才有用。如果角色分配放在每月复制到组的表格里,身份驱动的访问只是把过时的输入自动化了。也要检查延迟,因为一个新员工一整天无法工作,比手工改端口的结果更糟。设备认证、用户认证以及两者并用是不同的选择,打印机需要明确的模型,而不是没有解释的例外通道。

把映射写下来:哪个组授予哪条策略,谁可以修改它。

条件 3:在试点之前确定故障时的行为

每次部署都有未认证状态和服务器不可用状态,而这两种状态下的策略都是安全决策。静默回落到受信网段会毁掉设计;硬性失败会在中断期间阻断工作。通常的折中是只允许上网的受限网段,加上一条通往服务台的清晰路径。要在真实的交换机或无线平台上测试回落,因为厂商默认值各不相同。

如果没有人能用一句话描述回落,设计就没有完成。

VPN 的位置

VPN 在不受信任的路径上认证访问,在办公室 LAN 上也要求它,可以是一个有意的信任决策。它并不消除组映射的需要,也不消除文件服务器自身的授权。它还让网关容量、客户端软件和会话管理进入运维负担。

为了避开编辑 VLAN 而买的 VPN 解决错了问题,还添了两个新问题。

表格,以及唯一值得保留的东西

ConditionHolds?Design
Devices enforce returned policyYes802.1X with dynamic policy, stable segments
Devices cannot enforce itNoKeep segments, add an application gateway
Identity source lags role changesNoFix provisioning before admission
No acceptable unauthenticated stateNoRestricted segment with a portal
Departures must lose access quicklyYesDynamic disconnect plus credential revocation

为服务器、访客、设备和运营技术保留网段。这些边界关乎流量而非职位,能经受任何重组。把员工权限放进身份策略,那里角色变更只是一次编辑;当移除必须迅速时,使用受支持的断连机制。

设计的检验是一次搬桌子:它应当移动一个人和他的设备,而不是围绕另一个插口重建他的权限。

相关文章