開發人員應該知道的零信任模型

語言: CN / TW / HK

什麼是零信任模型

零信任安全模型是一種設計和實現安全 IT 系統的方法。零信任背後的基本概念是“從不信任,總是需要驗證”。這意味著使用者、裝置和連線在預設情況下永遠不受信任,即使他們在連線到公司網路或之前已經通過身份驗證。

現代 IT 環境由許多互相連線的元件組成,包括內部伺服器、基於雲的服務、移動裝置、邊緣位置和物聯網(IoT)裝置。傳統的安全模型保護所謂的“網路邊界”,在這種複雜的環境中是無效的。

攻擊者可以破壞使用者憑證並訪問防火牆後的內部系統。

它們還可以訪問部署在組織之外的雲資源或物聯網資源。零信任模型在受保護資產周圍建立微型邊界,並使用相互認證、裝置身份和完整性驗證、基於嚴格的使用者授權訪問應用程式和服務等安全機制。

為什麼零信任模型很重要

在零信任模型出現之前,企業使用防火牆和虛擬專用網(VPN)等技術來控制對網路和應用程式的訪問。這些解決方案的問題是,一旦連線通過了安全檢查,它就是隱式可信任的,並且可以對網路進行開放的訪問。不管是合法使用者還是攻擊者都可以訪問敏感資料和關鍵任務資源。

為了降低這種威脅的可能性,企業實現了多個複雜的安全層來檢測和阻止攻擊,但攻擊者仍然可以繞過這些防禦。零信任模型根據細粒度訪問策略和當前安全上下文選擇性地允許使用者訪問允許他們訪問的特定資源,從而解決了開放網路的訪問問題。

零信任模型的核心原則是什麼

實現零信任安全模型需要將以下原則納入組織的安全策略中。

持續的驗證

持續驗證是零信任的一個關鍵方面——它意味著不存在隱式可信任裝置、憑據或區域。有幾個要素對於各種資產的持續驗證來說是必不可少的,包括基於風險的有條件訪問(維護使用者體驗)和易於應用的動態安全策略(考慮到合規性需求)。

實現持續驗證的一個關鍵策略是零信任網路訪問(ZTNA)——一種強制零信任策略的解決方案。ZTNA 可以實現最小特權原則(PLP),這樣使用者或服務帳戶只能在需要時訪問資源。這種網路策略最大限度地降低網路安全風險,保護組織免受來自內部和外部的威脅。

微分割

零信任網路需要實現微分割來建立多個保護區域,而不是單一的安全邊界。這種方法有助於分別保護網路的不同部分,一個受損區域不會威脅到網路的其他部分。

最小特權訪問

最小特權原則是零信任的關鍵,它向每個使用者或實體授予最小必要的訪問許可權,防止暴露于敏感的網路區域中。最小許可權原則要求謹慎管理使用者許可權。

裝置訪問控制

裝置訪問控制為使用者訪問控制提供了補充,確保裝置無法通過適當的授權訪問網路。零信任系統必須監控試圖訪問網路的裝置,以減少攻擊表面積。

內網漫遊預防

內網漫遊是指攻擊者在網路的不同部分之間移動。即使已知攻擊者的初始入口點,要檢測他們也極具挑戰性,因為他們可能已經移動到網路的任何部分。

零信任解決方案對網路進行分割,限制內網漫遊和滲透,確保隔離被洩露的帳戶或裝置能夠消除威脅。

執行分割的實際元件可能是 ZTNA、集成了零信任策略的下一代防火牆(NGFW)或雲安全訪問代理(CASB,一種附加在雲資源上的小型防火牆)。這些工具可以從多個維度對網路進行分割——例如應用程式分割、環境分割、過程分割和基於使用者的分割。

零信任的應用場景和好處

多年來,零信任模型一直是一個既定的標準,但它仍在經歷規範化的過程,以幫助企業應對不斷變化的威脅環境。數字化轉型的普及和網路威脅的增長促使許多企業採用或改進他們的零信任策略。

零信任安全模型對所有的組織來說都是有好處的,對於使用混合或多雲部署模型、非託管裝置、遺留系統或軟體即服務(SaaS)應用程式的組織來說尤為如此。在這些環境中,組織擁有可控範圍之外的資源,或者可能與組織的安全政策和實踐不相容——零信任可以幫助在這些系統周圍建立安全邊界。

零信任模型對於及時檢測和應對常見威脅來說也至關重要,例如:

  • 勒索軟體攻擊是一種帶有雙重目的的威脅,它既執行惡意程式碼也會破壞身份。

  • 內部威脅——這種風險隨著遠端訪問和外部使用者的增加而增加。

  • 供應鏈攻擊——由遠端特權使用者和非託管端點裝置構成的風險。

實現零信任有助於組織解決 SOC(安全運營中心)或安全分析師技能缺失等問題。零信任模型支援在混合環境中大規模設定安全策略,並使用自動化來檢測和應對威脅,減少了手動工作和安全團隊的工作量。

它有助於最大限度地減少安全機制對使用者體驗的影響,同時強制遵守法規和行業標準。零信任的另一個優勢是,在面對快速演變的威脅時加強組織的安全策略。

由於業務、安全和數字化條件的不同,每個組織都面臨著獨特的挑戰。零信任是一種可調整的策略,可以滿足不同組織的特定安全需求。

零信任參考架構

向零信任模型過渡可能是一個非常複雜的過程。谷歌和微軟是兩個實現了大規模零信任的企業,它們建立了參考架構,可供業內其他組織效仿。

谷歌 BeyondCorp

BeyondCorp 是谷歌的零信任實現,建立在谷歌的長期經驗之上,結合了社群的想法和最佳實踐。BeyondCorp 將訪問控制安全層從單體外圍轉移到網路個體使用者,允許遠端 Worker 從任意位置安全地訪問網路,而無需使用傳統的 VPN。

BeyondCorp 提供了一系列最佳實踐和概念,可以幫助其他組織實現零信任模型。它也是一種商業解決方案,可用於在組織中實現零信任。商用解決方案叫作 BeyondCorp Enterprise(取代之前的 BeyondCorp Remote Access)。

新版 BeyondCorp 為 Chrome 添加了零信任特性。除了在託管終端裝置上部署代理外,企業還可以通過瀏覽器擴充套件 BeyondCorp 架構。Chrome 的更新包括威脅保護和嵌入式資料功能,有助於防止意外或惡意資料洩露、惡意軟體感染以及其他形式的網路和裝置洩露。

BeyondCorp Enterprise 提供了連續認證特性,定期對裝置、使用者和應用程式之間的所有互動進行認證。企業可以建立並實施訪問控制策略,持續地驗證認證資料,包括使用者身份、裝置資料和 IP 地址,一旦出現違反策略,將立即取消其訪問。

第三方安全供應商可以利用 BeyondCorp 聯盟計劃為這個新平臺開發零信任產品。例如,終端安全供應商 Tanium 提供了與 BeyondCorp Enterprise 的整合平臺,允許兩種產品交換安全資訊,為組織提供更高的環境可見性。

微軟零信任模型

微軟公佈了其內部 零信任模型的實現細節 。這種零信任實現解決方案專注於企業範圍內的企業服務,例如微軟 Office 和業務線(LOB)應用程式。

它適用於執行在 Windows、Android、Mac 或 iPhone 上的裝置,雲移動裝置管理服務微軟 Intune 負責管理這些移動裝置。

微軟的零信任模型包括四個階段。

  1. 身份驗證——微軟通過對遠端訪問請求要求進行雙重身份驗證來保護網路。過去使用智慧卡進行驗證,現在使用 Azure Authenticator 來實現移動裝置驗證,未來計劃消除密碼機制,支援全面的生物特徵認證。

  2. 裝置執行狀況驗證——微軟使用 Intune 註冊新使用者裝置。裝置健康策略指示哪些裝置是健康的,或者在訪問主要的生產應用程式(如 SharePoint、Exchange 和 Teams)之前需要加以管理(測試和修補漏洞)。對於某些場景,微軟通過虛擬 Windows 應用程式和桌面為非託管裝置提供支援。

  3. 訪問驗證——任何對微軟服務的訪問嘗試都必須經過基於身份、裝置健康狀況、總體安全上下文(例如一天中的時間和使用者的位置)和來自微軟智慧安全圖的其他資料的驗證。這裡的創新之處在於,微軟可以對訪問進行驗證,無論使用者是直接訪問公司網路、通過 VPN 訪問,還是通過網路訪問資源。

  4. 服務驗證——微軟提出了一種未來的機制來驗證服務,確保在允許使用者與服務互動之前它們是健康的。這一特性目前處於規劃階段。

開發人員的注意事項

零信任模型將安全責任從網路轉移到了應用程式。應用程式本身具有驗證細粒度策略的能力,並確保每個使用者準確地訪問允許他們訪問的功能和資料。

在零信任環境中,開發人員不能僅僅依靠簡單的 API 令牌進行身份驗證和授權,他們必須全面瞭解如何在考慮到當前安全上下文的情況下保護請求者與應用程式的每一步互動。

零信任環境中的應用程式需求

在零信任安全模型中開發應用程式時,開發人員需要:

  1. 評估會話的整體上下文,以確定總體風險。

  2. 確定零信任驗證的關鍵因素——使用者的身份、發出請求的裝置的狀態、正在使用的應用程式功能以及請求試圖訪問的資料。

  3. 確保每個請求(即使它們來自網路外圍)都應用了安全策略。

  4. 應用額外的安全措施,如多因子身份驗證、功能限制和強制合規性控制。

  5. 確保在應用程式生命週期的所有階段僅基於白名單授予訪問許可權——換句話說,只有在顯式允許的情況下才授予訪問許可權。

第一步到第三步通常是通過特定 ZTNA 工具的 API 來實現的,如 Perimeter81 或 CrowdStrike Zero Trust。

第 4 步通常通過 Auth0 或 Okta 等身份驗證解決方案來實現。在大型組織中,Azure Active Directory 等企業身份識別服務起到了補充作用,或者直接取代了這些服務。

第 5 步是在應用程式層實現的——這是應用程式開發人員對零信任模型的主要貢獻。

持續測試零信任需求

僅僅實現上述的措施是不夠的,我們還需要測試和驗證應用程式是否正確地實現了身份驗證、授權和強資料加密。這就要求:

在開發的早期階段對程式碼進行靜態分析,確保每個使用者互動都適當呼叫了零信任和身份驗證/授權元件。

在測試、UAT 和生產環境中對應用程式進行動態分析,並測試使用者請求是否收到了適當的安全措施。

執行模糊測試和滲透測試,找出並消除開發生命週期中引入的漏洞——例如缺少身份驗證或不正確的安全策略應用。

管理第三方風險

零信任框架還需要對第三方開源和專有元件的安全性進行驗證。開發人員來需要了解他們的專案中使用了哪些元件、它們帶來了怎樣的風險和漏洞,以及如何應用更新和修復。

軟體組合分析(SCA)解決方案可用於獲取軟體專案中使用的開源元件的可見性,包括數千個傳遞性依賴項。對於每個開源庫,這些工具都可以識別出其安全弱點,指出其程式碼質量問題,還可以警告組織對可能造成法律問題的許可進行限制。關於軟體組合分析的更多資訊可以參考這個 指南

第三方元件並不是唯一的風險來源。開發團隊必須監視整個軟體供應鏈,包括開發環境、持續整合(CI)系統、部署系統和 Staging 環境、容器儲存庫,以及將程式碼從開發階段帶到生產環境所涉及的任何其他元素。

安全性左移

開發人員必須從一開始就將安全性納入到他們的設計和程式碼庫中。這是將隱式信任轉變為顯式身份驗證、強身份識別和訪問控制的最佳方式。這就是為什麼轉向 DevSecOps——開發人員、安全團隊和運營人員之間的密切合作——是對實現零信任模型的支援。

DevSecOps 團隊可以在軟體交付生命週期的所有階段實現零信任需求。內建在零信任框架中的應用程式可以在外圍控制失效時保護敏感資料和功能。例如,即使防火牆、入侵防禦系統(IPS)和資料丟失預防(DLP)工具出現配置錯誤、故障或被攻擊者破壞,應用程式也會盡最大努力保護其資產。

為了確保應用程式和後端系統一直處於被保護和執行的狀態,仍然需要在每次部署後進行持續的漏洞掃描。

總結

現在開發人員的職責遠遠超過了以前——他們也被期望成為安全專家。企業開始意識到最能防止再次出現安全漏洞的人是具有安全意識的開發人員,他們從軟體專案啟動的第一天就開始實現安全編碼實踐。這是一個很重大的責任,但對開發人員來說也是一個很大的機會,他們可以在向客戶交付價值的過程中扮演更核心的角色。

我希望本文能夠幫助開發人員開發他們的安全智慧模型,並幫他們帶上“零信任眼鏡”——通過零信任模型的透鏡來觀察程式碼和軟體架構。這不僅可以幫助他們開發出更安全的應用程式,而且還可以提高他們“說到做到”的能力——在現代安全環境中有效地溝通和理解目標和策略。

作者簡介:

Gilad David Maayan 是一名技術作家,他曾與 SAP、Imperva、Samsung NEXT、NetApp 和 Check Point 等 150 多家技術公司合作,為開發人員和 IT 領導層提供技術解決方案,產出技術和思想領導力內容。

原文連結:

What Developers Must Know About Zero Trust