企业官网建设流程全解析

1. 先搞清楚NAC到底在解决什么问题：我们网络里最容易被忽视的漏洞

做网络运维这些年，我越来越发现一个尴尬的事实：不少企业的边界防火墙、入侵检测、终端杀毒都做得相当到位，但内网准入这块却还停留在“插上就能上网”的状态。任何一台设备，只要拿着网线往工位上一插，或者连上一个开放Wi-Fi，就和内部服务器处在同一个二层网络里。这样的网络，外表看起来风平浪静，但本质上跟把办公室大门敞开、任由陌生人进出没什么区别。

网络接入控制（NAC，Network Access Control）这东西，核心就一句话：**不让未经授权的设备随便接入网络，也不让已授权但“带病上岗”的设备在网络上自由活动。**它不是某个单一的硬件设备，也不只是一套软件协议，而是一组策略和技术的集合。它管的不只是“你是谁”，还会继续问“你的设备健不健康”“你被允许访问哪些区域”“你现在的位置是否可信”。说白了，它把网络从“接通即信任”变成了“先验证，后放行，持续监视”。

这篇文章想聊的，不只是把NAC的定义背一遍，而是从为什么需要它、怎么落地、有哪些坑、怎么选型这几个角度，把这事讲透。适合谁看？一类是刚接触企业网络、被“准入控制”这个词绕晕的新人；另一类是在甲方待过、正被“要不要上NAC、上哪种NAC”折磨的网络工程师或安全负责人。

1.1 网络“能找到”和“能控制”是两回事

很多人第一次接触NAC时，会问一个很直接的问题：“我们公司已经有DHCP、有域控、有交换机端口安全了，为什么还需要NAC？”

这个问题的答案，要分清楚“能找到设备”和“能控制设备”的区别。

• DHCP能看到谁拿了IP地址，但它无法证明“拿地址的这个人是不是该拿的”。
• 域控能验证域用户的身份，但它管不了非域设备，比如销售带来的一台MacBook、供应商临时接入的Windows笔记本。
• 交换机端口安全能限制MAC地址，但一个MAC地址可以被修改，而且它识别的是“网卡”，不是“人”。
• 防火墙能过滤流量，但它无法阻止设备已经接入二层网络后的横向探测和攻击。

NAC的定位，就是把这几个环节串起来：先通过某种方式确认接入者身份，再根据身份决定它能不能上网、能上到什么程度、要不要做安全检查，最后在发现异常时动态处置。它不是替代上面那些设备，而是让它们协同工作，形成一条完整的策略执行链。

1.2 我见过的一个典型事故，让我决心重做准入

刚工作那会儿，我所在的单位网络就处于“裸奔”状态。某天早上，办公网突然变得极慢，核心交换机的CPU利用率接近100%。排查到最后才发现，问题根源是一台被员工私自接入的笔记本。那台机器中了挖矿木马，一进内网就开始疯狂横向扫描，导致大量交换机ARP表项过载。最讽刺的是，这台笔记本连的不是公司配发的设备，而是员工自己带的家庭电脑，就因为在工位旁边插了一根网线，轻松进入了办公网。

事后复盘时，我们发现所有现成的安全设备都没能拦住这次事故：杀毒软件只装在受管终端上，防火墙看到的流量是从内部发起的，IDS虽然报了告警但处置滞后。如果当时有一个基本的NAC机制，哪怕是做一次简单的身份认证和终端健康检查，这台设备在接入的第一时间就会被隔离，后续的事情根本不会发生。

这件事之后，我花了很多时间去研究NAC的产品和方案，也陆陆续续在几家企业里主导过准入项目的落地。以下是这段时间攒下来的认知和教训，全部基于实操经验，不一定是最新营销话术，但对实际做项目的人应该有点参考价值。

2. NAC不是一套设备，而是一套“策略执行链”

很多人以为NAC是买一台设备往网络里一串联就完事，这是个很大的误解。NAC更像是给网络装了一套“门禁系统”，但门禁系统本身又由门锁、读卡器、监控摄像头、保安人员共同组成。理解这条策略执行链，是做技术选型和项目落地的前提。

2.1 从“发现”到“处置”：NAC的核心工作流

无论你用的是哪家产品，NAC的工作过程基本都逃不脱这五个环节：发现、认证、授权、检查、处置。

• 发现（Discover）：网络设备（交换机、AP或NAC网关）先感知到有新设备接入。技术上可以通过SNMP轮询、NetFlow、DHCP Snooping、LLDP、RADIUS Accounting等方式拿到设备的MAC、IP、接入端口、VLAN等基本信息。
• 认证（Authenticate）：对接入设备进行身份验证。身份可以是员工账号、访客手机号、设备MAC地址、数字证书等，具体用哪种取决于场景。
• 授权（Authorize）：根据认证结果，决定设备可以进入哪个VLAN、哪些网段，能不能访问某些关键服务器。这一步通常通过下发ACL、VLAN成员关系或防火墙策略实现。
• 检查（Posture Check）：在允许全量接入之前，确认终端是否合规。比如是否安装杀毒软件、补丁是否更新、是否越狱、是否有违规软件。这一步通常需要终端上装一个轻量Agent，或者借助已有的终端管理工具。
• 处置（Remediate）：如果检查不通过，直接拒绝、隔离到修复VLAN，或者只允许访问补丁服务器，并提示用户完成修复后重新认证。

这五个环节可以全部自动执行，也可以部分人工介入。自动化的程度，往往决定了项目上线后是“隐形”的还是“三天两头被投诉”的。

2.2 位置决定实现：In-band和Out-of-band部署

NAC的部署形态通常分两类：In-band（串接）和Out-of-band（旁挂）。这两种方式的区别不只是在拓扑图上画法不同，而是直接影响网络可用性、性能瓶颈和故障恢复复杂度。

In-band部署：NAC设备（或启用NAC功能的交换机/防火墙）串联在用户接入路径上，所有流量都经过它。

优势是策略执行非常直接，可以做到精确的流量阻断和深度检查。但缺点是容易成为单点故障和性能瓶颈——设备一旦故障，全网断网；流量一大，转发性能不够就会丢包。我在一个分支节点做试点时就遇到过这种尴尬，所有办公流量都过一台设备，高峰期CPU一直报警，连带着语音通话都开始卡顿。

Out-of-band部署：NAC以旁挂的方式接入网络，平时不拦截数据流量，只在接入认证阶段和交换机、控制器交互。

这种模式下，交换机是真正的转发主体，NAC主要做策略决策。优点是网路拓扑改动小，设备故障时一般只影响新接入认证，不掉老连接；缺点是执行粒度取决于交换机对策略的支持能力，比如能不能基于RADIUS下发VLAN、能不能下发ACL、能不能控制VoIP流量等。

从我个人的经验看，除非规模很小或者预算实在有限，否则尽量选Out-of-band的架构。真正需要串接做深度检测的新建网络项目，应该认真评估一下性能余量，而不是只看厂商的峰值指标。

2.3 没有银弹：NAC的判别方式和各自的坑

NAC判断“这个设备能不能入网”的方式，决定了它的适用场景和管理复杂度。以下是几种主流方式：

• 802.1X端口认证：由交换机/AP在接入链路层发起认证，终端用802.1X客户端（通常是操作系统自带的，比如Windows的Wired AutoConfig）响应。这是最标准、最严格的方式，但部署和排障难度最高。
• MAC认证旁路（MAB）：交换机把设备的MAC地址作为凭据送给认证服务器，服务器查库后决定是否放行。适合打印机、IP电话等无交互界面的哑终端。缺点是MAC可以伪造，安全性弱，管理MAC地址表也很麻烦。
• Web认证/Portal认证：终端接入后打开浏览器，强制跳到认证页面，输入账密或通过短信验证码登录。这是访客网络最常用的方式，灵活但体验依赖网络层面的强制跳转是否顺畅。
• DHCP指纹识别：通过分析终端DHCP请求的特征字段识别设备类型（操作系统、厂商），适合做设备分类，不适合做高强度认证。

这些方式从来不是互斥的，实践中往往是“802.1X为主、MAB兜底、Portal给访客”。真正做项目时，最让人头疼的不是单一方式怎么配，而是多种方式在同一台交换机上如何平滑共存，比如同一个端口的第一个数据包该走哪种认证流程，这涉及到认证顺序的配置细节，很考验现场工程师的经验。

3. 落地NAC最绕不过去的一环：身份认证怎么选

身份认证是整个NAC的第一道关卡，也是使用体验最敏感的地方。厂商演示环境里一次点击就能搞定的事，到了真实办公网络里可能有一万种意外。这一节把几种常见认证方式的适用场景、部署要点和真实使用感受讲清楚。

3.1 802.1X：最安全也最折腾的一套标准

802.1X是一套链路层认证标准，最初为有线网络设计，后来扩展到无线。它的工作方式可以粗略理解为：客户端先向交换机发送“我要上网”的请求，交换机不允许任何流量通过，只把它转给认证服务器（通常是RADIUS）。认证服务器和客户端之间进行EAP协议交互，验证通过后，交换机才打开端口并下发相应的VLAN和ACL。

为什么说它最安全？因为认证发生在网络接入的第一时刻、在最底层链路层，不依赖IP层以上的任何服务；它还能支持数字证书认证，做到设备级别的可信。

为什么说它最折腾？因为要正常工作，必须有配套的PKI证书体系，终端上要正确配置EAP方法（比如PEAP或EAP-TLS），交换机上要正确配置认证模板。任何一个环节出错，用户就会报“明明输对账密却上不了网”。我记得一个分支网络项目里，因为CA证书的信任链没下发到终端，导致一半电脑反复弹出证书错误提示，最后花了整整两天才排查出是证书吊销列表更新频率的问题。

所以，如果你所在的团队有专门的安全或网络运维人员，能接受复杂排障，802.1X值得上。如果团队只有一两个人，还兼着桌面运维，我建议优先考虑其他方式，或者分期建设——先上Web认证和基本的MAC认证，再逐步过渡到802.1X。

3.2 MAC旁路认证：适合打印机们，但也藏着安全隐患

MAB（MAC Authentication Bypass）是给“没有交互界面的设备”准备的，比如打印机、门禁控制器、IP电话、摄像头。交换机拿到终端的MAC地址后会发给RADIUS服务器，服务器在设备白名单里查一下，命中就通过。

这个方案实现比较简单，很多网络设备都原生支持。但它的风险点也很明显：MAC地址是可以在系统层面改的。攻击者只要在接入前把自己的网卡MAC改成一个已登记打印机的MAC，就能绕过认证。所以，MAB只能算“弱认证”，适合存在于可信物理环境里的哑终端场景，不适合作为唯一的接入控制手段。

实操中还有个容易被忽略的细节：同一台交换机上如果既配了802.1X又配了MAB，且MAB优先级较高，那么用户电脑在802.1X客户端没有正确启动时，可能会被当成哑终端走MAB流程，结果自然是“MAC不对、认证失败”。这种配置顺序问题在思科、H3C、华为的设备上处理方式略有不同，但核心原则都是先尝试802.1X，等超时后再走MAB，这需要在调试时反复验证。

3.3 Web认证：访客网络的首选，也是人性的考验

Web认证（也叫Portal认证）是最有人情味儿的一种方式：用户接入网络后不用修改任何系统设置，打开浏览器就会被强制跳到登录页，输入访客申请的账号或者手机验证码即可上网。

它的优点很明显：兼容所有平台、无需安装客户端、适合临时访客。缺点也相当直白：只验证“人”，不验证“设备”。一个人拿到访客账号后，用任何设备都能登录；而且如果认证系统只做一次然后释放流量，同一个端口接一个HUB再插五六台设备，它们也都能一起上网。

我见过不少企业用Web认证来“冒充”完整的NAC，结果就是形同虚设——访客账号满天飞，离职人员申请的临时账号还能长期使用。建议把Web认证当作NAC体系中的“访客面”，而不是全部。如果只有Web认证，至少要做到：账号有有效期限、设备MAC与账号绑定、并发会话数限制。这三个措施能让这套轻量方案撑到真正的NAC上线。

3.4 认证之外，别忘了授权策略才是“门禁的闸机”

认证通过并不等于可以访问所有资源。一个“已认证的供应商外部人员”和“已认证的内部财务员工”，权限显然不能一样。授权策略通常体现在这几个方面：

• VLAN划分：员工VLAN、访客VLAN、哑终端VLAN、隔离VLAN，不同VLAN对应不同网段的访问范围。
• ACL下发：认证通过后，交换机/控制器给端口下发一张ACL，限制只能访问特定的服务器段或应用。
• 动态防火墙策略：SDN或防火墙联动场景下，认证通过后会下发更精细的微隔离策略。
• 带宽和QoS控制：访客的带宽优先级最低，IP电话的语音流量优先级最高。

我之前参与的一个项目里，最精髓的部分不是“怎么让员工通过认证”，而是“让不同角色落在不同VLAN、拿到不同访问列表”。网络运维团队花了两周时间梳理角色和权限矩阵，比如研发、销售、人事、财务、外聘顾问各能访问哪些网段，连打印机共享和文件服务器的访问都明确下来。没有这个矩阵，NAC做得再精致也只是个昂贵的“门锁”，门后面的房间照样随便进。

4. 认证之后照样出事：授权、合规检查与动态响应

很多人有这种想法：“既然认证都通过了，那后面就应该畅通无阻吧？”事实恰恰相反，真正能体现出NAC价值的，恰恰是认证之后那段环节——授权、健康检查和发现风险后的响应。这也是为什么我主张把NAC看作一套“策略执行链”，而不是“一次认证动作”。

4.1 认证只是“第一道门”，授权策略才是灵魂

可以把NAC想象成机场安检的完整流程：持票进入航站楼（认证），不等于可以直接上飞机；你还要经过安检（健康检查），到登机口时还要出示登机牌（再校验身份），不同舱位有不同候机区（授权），如果有人被列入某些名单（策略），还会有额外检查。NAC里的“授权”就是分配登机牌和候机区域的环节，决定你能去哪些网段、访问哪些主机。

一个很常见的场景是：某家公司的供应商人员需要定期来现场做设备维护，他们需要访问内网的管理接口，但绝不能被允许访问财务系统或者研发代码库。如果只做认证不放授权，供应商人员一旦进入办公网，就可能在横向区域里任意穿梭。这几乎是内网失陷事故里最常见的扩散路径。

授权策略的制定，需要业务方和网络团队共同参与。我见过有人买完NAC设备后直接问厂商“怎么把员工认证搞定”，却从未和同事们讨论“员工到底能访问哪些资源”。结果一年后，这套系统除了能拦一些陌生设备，对核心业务资产的保护基本停留在纸面上。

4.2 终端合规检查是很多NAC项目里最实际的验收项

NAC的另一个重要能力是对终端做“健康检查”（Posture Assessment），也可以叫“合规检查”。检查项通常包括：杀毒软件是否安装且运行、病毒库是不是最新的、操作系统补丁是否达到基线、是否开启了防火墙、设备是否越狱或Root、是否在域内、是否安装了企业禁止的软件等。

它的实现方式有两种主流路线：

• Agentless（无代理）：利用现有终端管理工具（如微软的Intune/SCCM、第三方MDM）的查询结果，或者通过NAC设备主动扫描终端开放端口、探测系统信息。优点是部署工作量小，但能拿到的信息往往有限，很依赖现有工具的可靠数据。
• Agent（代理）：在终端上安装NAC厂商的安全客户端，由它负责收集系统状态并上报给策略服务器。优点是信息非常丰富，还能配合802.1X的EAP流程在认证阶段就完成检查；缺点是终端太多时需要安装、升级、官方排障，会极大地增加运维负担。

合规检查在实际项目中经常遇到一个很真实的问题：**检查标准定得太严，全网大量设备不达标，导致业务无法开展；定得太松，检查形同虚设。**一个还算合理的做法是分阶段执行：先做“通报模式”——只记录不合规情况，不阻断；等各方都清楚现状以后，再开启“隔离模式”——把不合规的设备隔离到修复VLAN，限定只能访问补丁服务器或DNS，等修复完成后自动放行。

提示：合规检查务必和现有终端管理工具配合使用，不要另造一套“轮子”。如果公司已经有成熟的Intune或MDM，优先考虑NAC产品是否支持与其对接，能省掉大量终端Agent的重复安装工作。

4.3 发现“有问题设备”之后的处置，一定要自动化

NAC的“处置”环节，最能体现项目是否真正落地。一旦在网络上发现设备被感染、出现异常扫描行为、或试图访问未授权区域，系统应该能自动执行下面几类动作之一：

• 踢下线：强制设备断开网络连接。
• 隔离VLAN：把设备移动到隔离网段，仅允许访问专门的处置服务器。
• 限制ACL：只允许访问特定IP，其他地址一律拒绝。
• 联动防火墙：在边界防火墙上生成临时阻断策略，限制该设备的对外通信，避免横向扩散和C2（命令控制）通信。

真实场景里，自动化响应能力直接决定了一次内网病毒爆发的影响面。我曾经处理过一个“终端中招后不断扫描”的告警，就是因为NAC没有启用自动隔离，而是依赖管理员手动封禁，结果从发现异常到实际处置花了将近20分钟。在蠕虫式攻击面前，20分钟足够扩散到一个广播域的所有主机了。

当然，自动化响应也不能一上来就全面放开。建议先做一段时间的“灰度”：开启监控告警、不直接处置，把误报率摸清楚后再逐步开启自动隔离。误伤一次合法终端，就可能让业务部门未来一年都对NAC抱有抗拒心理。

5. 我在企业里落地NAC的过程：从试点到全网，踩过的坑都在这

理论讲完之后，说说实际操作。这一节我以自己的实施经历为主线，把从立项、设备采购、到试点和全网推广的真实过程压缩成几段经验，希望能让你少走一些弯路。

5.1 网络设备要支持什么功能，采购前就要确认

NAC不是一台设备包打天下，它通常由NAC服务器/控制器、交换机/AP和终端客户端三大部分组成。交换机和AP是否支持对应的认证特性，直接影响项目能不能落地。

在采购或者选型之前，至少要确认网络设备支持以下能力：

• 是否支持802.1X认证；
• 是否支持基于RADIUS动态下发VLAN；
• 是否支持认证失败和访客VLAN的端口策略；
• 是否支持RADIUS CoA（Change of Authorization），也就是认证后动态修改VLAN/ACL；
• 是否支持MAC地址认证（MAB）；
• 是否支持在VLAN间做流量过滤或端口ACL。

我遇到过最尴尬的情况是：某型号交换机支持802.1X，但CoA功能是阉割版或者依赖特定版本，导致认证通过后无法动态切换VLAN，最终只能把所有用户放进一个VLAN里，失去了隔离的意义。所以，先拉一份现网设备清单，对照厂商支持矩阵逐一勾选，再决定NAC的选型，顺序不能反。

5.2 试点往往比预期慢三倍

NAC项目最忌“毕其功于一役”。我个人的经验是，先选一个小范围的试点部门，最好是IT部门自己所在的区域，让技术团队先亲身体验整个认证流程。自己都被折腾一遍之后，再推广到其他部门时，话术和预案都会扎实得多。

试点阶段的核心任务不是把功能全打开，而是做这几件事：

• 验证认证成功率是否达到99%以上（低于这个数，推广阶段会有大量抱怨）；
• 验证哑终端（打印机、门禁、IP电话）的MAB是否稳定，因为这类设备一旦因认证问题离线，业务影响最直接；
• 验证访客网络的Portal跳转是否在所有主流浏览器和手机上正常工作；
• 检查认证失败时的“逃生通道”——是彻底断网还是落到访客VLAN？策略需要和业务部门提前沟通好。

试点周期我一般建议至少两个星期，包括两个完整的业务周。因为有些设备只在特定时间开机，比如周报提交日的临时笔记本、月底的财务打印机，多等一周能暴露更多边界情况。

5.3 认证失败排障的经典链路

如果在试点期间收到“XX位置上不了网”的反馈，先别急着怀疑NAC服务器，按下面这个顺序排查基本能覆盖90%的问题：

1. 先看端口状态：在交换机上查看端口是否被802.1X置于Unauthorized状态，这能确定是认证流程压根没开始，还是开始后失败。
2. 抓包看EAP交互：在终端侧抓包，确认EAP-Request/Response走到哪一步断开。如果是证书链错误，一般在EAP-TLS的证书交换阶段就能看到ClientHello后没有后续。
3. 查RADIUS日志：确认NAC/RADIUS服务器是否收到Access-Request，以及返回的Access-Reject原因。常见原因包括用户已锁定、密码过期、设备不在白名单、证书吊销。
4. 验证交换机下发策略：认证通过后，用show命令确认动态VLAN和ACL是否生效。如果VLAN没变，多半是Radius属性（如Tunnel-Private-Group-ID）和交换机配置不匹配。
5. 排除终端的特殊配置：Windows的Wired AutoConfig是否被组策略禁用、网卡驱动是否关闭了802.1X支持、第三方安全软件是否拦截EAP报文。

这套流程里，最容易被忽略的是“认证成功但VLAN没变”这个场景，它往往不在“认证失败”的范畴内，却会让用户陷入“能上网但打不开某些资源”的玄学困境。遇到这种情况，直接抓Radius的Access-Accept报文，看它下发的属性值是否匹配交换机的VLAN映射，通常能快速定位。

5.4 不要忘了“断网逃生舱”

最后一个落地要点，可能听起来有点“反NAC”，但我认为非常重要——必须为异常情况准备逃生通道。NAC服务器故障、证书服务不可用、RADIUS链路中断的时候，如果策略是把所有未认证设备全部拒绝，结果往往是办公网络直接瘫痪，电话被打爆。

合理的做法是配置“故障逃生策略”（Fail-Open）：核心业务区可以Fail-Closed（宁可错过认证也不放行），一般办公区建议Fail-Open（NAC故障时暂时放开认证限制，保证业务连续性），同时持续告警提醒运维处理。这和安全理念并不冲突，属于“默认拒绝”与“业务可用性”之间的权衡，必须在立项阶段就和业务方达成一致。

6. 选型和演进：NAC与零信任、SaaS化之间的关系

6.1 选型时最常见的对错思路

选NAC产品时，厂商的PoC演示通常都做得很漂亮：三分钟上线、一键识别、动态隔离。但真实的选型评估，我更建议从这几个维度来打分：

身份源对接是否顺滑：是否支持对接企业已有的AD/LDAP、HR系统、访客管理系统。如果身份源对接只能靠手工导入用户，那再好的策略引擎也是空中楼阁。

终端兼容性：Windows、macOS、Linux、Android、iOS、IoT设备分别支持哪些认证方式。这一点对办公环境尤其重要，很多公司表面上看是Windows统一，实际总有研发的Linux笔记本和老板的iPad在到处接入。

策略引擎是否灵活：能不能基于“用户+设备+时间+位置+合规状态”组合出策略，而不是只能做简单的VLAN分配。零信任理念里常说的“动态策略”，在NAC中体现就是这里。

运维复杂度：升级是否方便、日志是否清晰、告警是否可解释。很多安全产品只顾着“抓贼”，却忽视了运维人员的日常负担，最终被弃用往往不是因为抓不到贼，而是因为误报太多、日志根本看不懂。

与现有安全体系联动：能否和EDR、SIEM、防火墙联动，实现发现威胁后的跨设备自动化处置。现在NAC如果只是“孤岛式”的认证工具，在安全运营中心的眼里价值会大打折扣。

6.2 NAC和零信任其实“看起来”像，但不完全是同一回事

近两年零信任很火，很多厂商把NAC产品也包装成了“零信任接入”解决方案。严格来说，零信任的范围比NAC大得多，它强调“永不信任、持续验证”，覆盖身份、终端、应用、数据、网络多个层面。NAC更像是零信任理念在“网络接入层”的一个具体实现，管的是设备能不能进网、能进哪个网段。

但两者确实有相通之处：都强调身份与设备的绑定、都要求持续检查和动态响应、都要求策略随情境变化。在实际项目中，NAC往往可以作为企业迈向零信任的第一步。先把“谁能接入网络”管住，再逐步延伸到“谁能访问某个应用”，这是比较务实的路径。

6.3 云化NAC是中小企业更现实的起点

传统的NAC部署需要本地控制器、RADIUS服务器、证书服务，对中小团队来说运维成本相当高。近几年出现的云化NAC（NAC-as-a-Service）把控制器放到了云端，企业只需在本地网络设备上做少量配置，通过云端的控制台统一管理各分支的接入策略。对于没有专职安全团队的中小企业，这种模式确实更友好。

同时，云化NAC在分支互联场景下也有天然优势：员工在总部、分支、移动办公场景下，可以共用同一套身份策略，认证体验保持一致。但对数据安全要求极高的机构（如金融、医疗、涉密单位），本地化部署可能还是更稳妥的选择，因为云化方案会把认证日志和策略配置放到云端，这时候安全合规团队的意见很重要。

提醒：不管选哪条路线，NAC都不是“买来即用”的盒子。它涉及身份源梳理、VLAN规划、ACL设计、证书体系、终端合规基线等多个前置条件，这些工作在项目启动前就应该启动，否则上线之日就是扯皮之始。

我在一个项目里最大的体会是：NAC的价值不在“认证”本身，而在于它逼着企业把“谁可以接入、接入后能干什么”这个问题彻底想清楚。这个梳理过程，往往比设备上线带来的收益还大。经历过一次内网横向扩散的事故之后，我更加确信，接入控制这块短板补不上，外部的防火墙和杀毒软件做得再强，内网也始终有一扇敞开的侧门。