保障混合办公安全：结合 NAC 与 ZTNA 实现无缝访问

欢迎来到 Purple 企业架构简报。我是今天的主持人，今天我们将深入探讨 IT 领导者面临的一项关键挑战：保障混合员工队伍的安全。具体而言，我们将关注网络准入控制（即 NAC）与零信任网络访问（即 ZTNA）的架构融合。如果您正在管理跨企业场所、零售空间或公共部门环境的复杂网络，那么本期内容非常适合您。 让我们先来梳理一下背景。传统的网络边界已经不复存在。我们都深知这一点。一方面利用强大的 NAC 来保障企业总部的安全，另一方面却依靠传统 VPN 进行远程访问，这种方式已经无法满足当下的需求。它不仅会给用户带来不便，还会给 IT 团队留下盲区。现代企业需要一种统一的安全态势，将本地基础设施与云原生应用无缝连接起来。这正是将 NAC 与 ZTNA 相结合的用武之地。 从历史上看，这些是孤立的领域。NAC 使用 802.1X 等标准，非常擅长控制大楼内部的物理和无线接入。它负责检查设备态势并分配 VLAN。另一方面，ZTNA 是为云时代而生的——它基于身份和上下文来保障远程访问的安全，而不是基于网络位置。问题在于，当混合员工在这些领域之间移动时，情况就会变得复杂。他们在家中通过 ZTNA 实现了无缝身份验证，但一走进办公室，就会遇到一堆支离破碎的策略。这令人沮丧、效率低下，坦率地说，还创造了攻击者可以利用的安全漏洞。 因此，让我们来谈谈技术架构。解决方案是一个统一的身份和上下文代理层。我们需要在 NAC 和 ZTNA 策略引擎之间同步遥测数据。您可以将其理解为跟随用户的持续态势评估，无论用户身在何处。 以下是它在实际工作中的运行机制。当设备连接到企业网络时，NAC 会执行全面的态势检查——操作系统版本、防病毒状态、证书验证。它会立即通过 API 集成与 ZTNA 代理共享此上下文。如果设备的态势恶化（例如检测到恶意软件），NAC 会在本地网络上对其进行隔离，并同时指示 ZTNA 代理撤销对关键云应用程序的访问权限。当用户从办公室移动到远程位置时，ZTNA 客户端会保持已建立的信任上下文。无需重新进行身份验证。体验是无缝的，而安全保护是持续的。 现在，让我们来探讨支撑这一体系的标准。IEEE 802.1X 是本地身份验证的金标准。它在端口层级提供设备身份的密码学验证。RADIUS 作为后端协议，负责在 NAC 解决方案和您的身份提供商之间进行通信。在 ZTNA 方面，您可以使用诸如 Azure Active Directory 或 Okta 等身份提供商，以及来自领先供应商的 ZTNA 代理。关键在于确保这些系统能够进行双向通信。 对于场所运营商（酒店、会议中心、体育馆）来说，还存在另一层复杂性。您需要在同一个物理基础设施上管理企业员工、承包商、访客以及不断增加的 IoT 设备。NAC 负责处理这种细分。企业员工获得 802.1X 身份验证并访问内部资源。访客则被隔离在专用网络中，理想情况下通过 Purple 的 Guest WiFi 等平台进行管理，该平台在捕获宝贵分析数据的同时提供强大的隔离功能。对于不支持 802.1X 的 IoT 设备（例如数字标牌、环境传感器、POS 终端），则通过 MAC 身份验证绕过（MAB）进行处理，并配合严格的 VLAN 细分以控制任何潜在的安全威胁。 让我为您介绍一个真实的部署场景。假设一家拥有 500 家门店的全球零售连锁店。区域经理经常在门店、总部和家庭办公室之间往返。他们经常遇到 VPN 断开连接以及访问库存管理应用程序不稳定的问题。解决方案是采用融合的 NAC 和 ZTNA 架构。当经理在店内时，NAC 通过 802.1X 对设备进行身份验证，并与 ZTNA 代理共享受信任的内部上下文。然后，代理授予对云端托管库存应用程序的直接、优化的访问权限，无需 VPN 隧道。当经理在家工作时，ZTNA 客户端会建立通往应用程序的安全微隧道，从而保持相同的访问策略。结果如何？一致的访问体验、减少了求助台呼叫，并显著提升了安全态势。 现在，我们来看看实施。我建议采用分三个阶段的方法。第一阶段是可见性。首先在监控模式下部署 NAC。发现并分析网络上的所有设备 - 笔记本电脑、BYOD 设备、IoT、访客设备。先不要执行任何策略。同时，将您的身份提供商与 NAC 和 ZTNA 集成，以巩固用户身份。使用您的 ZTNA 解决方案来绘制应用程序访问模式。这将为您提供编写合理策略所需的数据。 第二阶段是策略定义。定义企业设备的基线态势要求。根据用户角色和应用程序敏感性实施 ZTNA 微细分。至关重要的是，在您的 NAC 和 ZTNA 平台之间建立 API 集成，以实现双向上下文共享。在转入强制执行之前，彻底测试此集成。 第三阶段是强制执行。逐步启用 NAC 强制执行，首先从试点小组开始。监控身份验证失败并调整策略。向所有企业终端推广 ZTNA 客户端。并使用托管平台将零信任原则扩展到您的访客网络。 让我为您快速介绍一些最常见的误区及指导建议。首先，上下文同步延迟。如果 NAC 与 ZTNA 之间的 API 集成出现延迟，受损设备访问云应用程序的时间可能会超出可接受的范围。解决方案是使用基于 webhook 的推送通知，而不是依赖轮询机制，以确保近乎实时的策略更新。 其次，过于严苛的策略导致服务台求助量激增。在没有充分与用户沟通的情况下实施严格的姿态检查是造成混乱的根源。利用 Captive Portal 告知用户不合规情况，并在完全阻止访问之前提供自助服务修复。 第三，IoT 设备身份验证失败。无界面的 IoT 设备根本无法支持 802.1X 或 ZTNA 客户端。解决方法是采用 MAC 身份验证绕过，并结合严格的设备画像和严格的 VLAN 划分。 第四，这也是一个大问题 - 未能监控 API 集成本身的运行状况。如果 NAC 和 ZTNA 之间的同步中断，就会出现安全漏洞。请针对集成运行状况实施监控和告警，并定义在同步丢失超过设定阈值时触发的安全防范策略。 那么投资回报率如何呢？这种架构的业务优势显而易见。整合策略管理减轻了 IT 团队的行政负担。淘汰传统的 VPN 显著改善了混合办公体验，减少了停机时间和挫败感。而能够证明持续姿态评估和基于身份的访问控制，简化了针对 PCI-DSS 和 GDPR 等框架的合规性报告 - 这在零售和医疗保健环境中尤为重要。 总结一下今天简报的关键要点。身份是新的边界，而上下文是关键。在有线网络中使用 NAC，在应用程序中使用 ZTNA。绝不信任，始终验证 - 并且要持续进行。分阶段实施：首先是可见性，然后是策略，最后是执行。不要忘记访客网络和 IoT 资产 - 它们需要成为您安全架构的一部分，而不是事后才想到的补充。 如果您想深入了解 AI 驱动的网络安全未来，请参阅 Purple 的《AI驱动的NAC与威胁检测》指南。对于管理分布式站点的用户，我们的《SD-WAN 对比 MPLS》指南也非常值得一读。 今天的简报就到这里。感谢收听，我们下期再见。