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

歡迎來到 Purple 企業架構簡報。我是您的主持人，今天我們將深入探討 IT 領導者面臨的一個關鍵挑戰：確保混合工作團隊的安全。具體而言，我們將探討網路存取控制（NAC）與零信任網路存取（ZTNA）的架構整合。如果您正在管理企業場域、零售空間或公共部門環境中的複雜網路，這將非常適合您。 讓我們來看看背景脈絡。傳統的邊界防護已經不復存在，我們大家都知道這點。使用強大的 NAC 來保護企業總部，同時依賴傳統 VPN 進行遠端存取，這種方式已經不再適用。這會為使用者帶來阻礙，並為 IT 團隊帶來盲點。現代企業需要一個統一的安全態勢，無縫連接地端基礎架構與雲端原生應用程式。這就是結合 NAC 與 ZTNA 的用武之處。 在過去，這些是孤立的領域。使用 802.1X 等標準的 NAC 非常擅長控制建築物內部的實體和無線存取。它會檢查裝置狀態並分配 VLAN。另一方面，ZTNA 是為雲端時代而設計的 - 根據身分和上下文（而非網路位置）來確保遠端存取安全。問題在於，當混合工作者在這些領域之間移動時，他們在家中可以透過 ZTNA 無縫進行驗證，但一走進辦公室就會遇到脫節的策略限制。這令人沮喪、缺乏效率，坦白說，這會產生攻擊者可以利用的安全漏洞。 因此，讓我們來談談技術架構。解決方案是一個統一的身分與上下文經紀商層（context brokerage layer）。我們需要同步 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 驗證繞過（MAB），並結合嚴格的裝置剖析與嚴格的 VLAN 區隔。 第四，這是一個大問題 - 未能監控 API 整合本身的健康狀況。如果 NAC 與 ZTNA 之間的同步中斷，您就會面臨安全漏洞。請針對整合健康狀況實施監控與警報，並定義在同步中斷超過定義閾值時觸發的故障安全原則。 那麼投資報酬率如何？此架構的商業案例非常吸引人。整合原則管理可減輕 IT 團隊的行政負擔。消除傳統 VPN 可顯著改善混合工作體驗，減少停機時間和挫折感。此外，能夠證明持續的狀態評估和基於身分的存取控制，可簡化符合性報告，例如 PCI-DSS 和 GDPR - 這在零售和醫療保健環境中尤其重要。 總結一下今天簡報的重點。身分是新的邊界，而上下文是關鍵。對實體線路使用 NAC，對應用程式使用 ZTNA。永不信任，始終驗證 - 並且要持續進行。分階段實施：先可見性，然後是原則，最後是執行。不要忘記訪客網路和 IoT 資產 - 它們需要成為您安全架構的一部分，而不是事後才想到的事。 如果您想更深入了解 AI 驅動的網路安全未來，請參閱 Purple 的「AI-Driven NAC and Threat Detection」指南。而對於管理分散式站點的人員，我們的「SD-WAN versus MPLS」指南非常值得您花時間閱讀。 今天的簡報就到這裡。感謝您的收聽，我們下次再見。