保護混合工作：結合 NAC 與 ZTNA 實現無縫存取

歡迎來到 Purple 企業架構簡報。我是您的主持人，今天我們將深入探討 IT 領導者面臨的一個關鍵挑戰：保護混合工作團隊的安全。具體而言，我們將探討網路存取控制（即 NAC）與零信任網路存取（即 ZTNA）的架構融合。如果您正在管理企業場地、零售空間或公共部門環境的複雜網路，這正適合您。 讓我們設定一下背景。傳統的周邊防禦已經過時了。我們都知道這一點。一邊使用強大的 NAC 保護企業總部，另一邊卻依賴傳統 VPN 進行遠端存取，這種做法已經行不通了。這會給使用者帶來摩擦，並為 IT 帶來盲點。現代企業需要統一的安全態勢，將內部部署基礎架構與雲端原生應用程式無縫橋接。這就是結合 NAC 與 ZTNA 的用武之地。 在過去，這些是孤立的領域。使用 802.1X 等標準的 NAC 非常擅長控制建築內部的實體和無線存取。它會檢查裝置狀態並指派 VLAN。另一方面，ZTNA 是為雲端時代而設計的 - 根據身分和上下文而非網路位置來保護遠端存取。問題在於，當混合工作者在這些領域之間移動時，他們在家中透過 ZTNA 進行無縫驗證，但當他們走進辦公室時，卻遇到了不一致的原則阻礙。這令人沮喪、效率低下，坦白說，這創造了攻擊者可以利用的安全漏洞。 因此，我們來談談技術架構。解決方案是統一的身分與上下文代理層。我們需要同步 NAC 與 ZTNA 原則引擎之間的遙測數據。可以將其視為跟隨使用者的持續狀態評估，無論他們身在何處。 以下是實際運作方式。當裝置連接到企業網路時，NAC 會進行全面的狀態檢查 - 包括作業系統版本、防毒軟體狀態、憑證驗證。它會立即透過 API 整合將此上下文與 ZTNA 代理分享。如果裝置的狀態下降 - 例如偵測到惡意軟體 - NAC 會在本地網路上將其隔離，並同時指示 ZTNA 代理撤銷對關鍵雲端應用程式的存取權限。當使用者從辦公室移動到遠端位置時，ZTNA 用戶端會維持該已建立的信任上下文。無需重新驗證。體驗是無縫的，但安全是持續的。 現在，我們來深入探討支持這一點的標準。IEEE 802.1X 是內部部署驗證的黃金標準。它在連接埠層級提供裝置身分的密碼學驗證。RADIUS 作為後端協定，在 NAC 解決方案與您的身分識別提供者之間進行通訊。在 ZTNA 方面，您會看到 Microsoft Entra ID 或 Okta 等身分識別提供者，以及來自領先廠商的 ZTNA 代理。關鍵在於確保這些系統能夠進行雙向通訊。 對於場所營運商（如飯店、會議中心、體育場館）而言，這又增加了一層複雜性。您必須在同一個實體基礎設施上管理企業員工、承包商、訪客，以及數量不斷增加的 IoT 裝置。NAC 可處理網絡分段。企業員工可獲得 802.1X 驗證並存取內部資源。訪客則會被隔離在專用網路中，最理想的情況是透過 Purple 的 Guest WiFi 平台進行管理，該平台在提供強大隔離功能的同時，還能收集有價值的分析數據。至於無法支援 802.1X 的 IoT 裝置（例如數位看板、環境感測器、POS 終端機），則透過 MAC 驗證繞過（MAB）並搭配嚴格的 VLAN 分段來處理，以防堵任何潛在的安全威脅。 讓我為您介紹一個實際的部署情境。假設有一家在 global 擁有 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 指南非常值得您花時間閱讀。 今天的簡報就到這裡。感謝您的收聽，我們下次再會我們下次再見。