讀零信任網路：在不可信網路中構建安全系統19Google的BeyondCorp

躺柒發表於2024-08-15
Go

1. 概述

1.1. 基於使用者身份而不是網路位置的訪問控制體系，用於控制對應用、資料和服務的訪問

1.2. Google的全新網路安全模型完全拋棄了特權網路的概念，訪問授權僅僅依賴於使用者和裝置的憑證，而與使用者和裝置所在的網路位置無關，使用者無論使用公司內網、家庭網路還是酒店或咖啡店的網路，都不會影響訪問請求的授權結果

1.3. 在新的安全模型中，所有對企業資源的訪問都要基於裝置狀態和使用者憑證進行認證、授權和加密，並且可以針對不同的企業資源進行細粒度的訪問控制

1.4. BeyondCorp由許多相互協作的元件構成，透過這些元件之間的協作，確保只有經過嚴格認證的裝置和使用者才能被授權訪問所需的企業應用

1.5. 當需要在不同的策略中做出權衡和選擇時，務必把零信任的核心動機和設計原則牢記於心

2. 安全地識別裝置

2.1. 使用裝置清單庫和裝置證書安全地標識和追蹤所有受控裝置

2.2. 裝置清單庫

  • 2.2.1. 使用了“受控裝置”的概念，即由企業採購並妥善管理的裝置

  • 2.2.2. 只有“受控”裝置才能訪問企業應用

  • 2.2.3. 以裝置清單庫為基礎的裝置追蹤和採購流程是BeyoundCorp安全模型的基石之一

  • 2.2.4. BeyondCorp會追蹤所有受控裝置，在裝置的生命週期內發生的任何變更都會被記錄下來，這些資訊被持續監控和分析追蹤，同時提供給BeyondCorp的其他元件

  • 2.2.5. 只要建立起元裝置清單庫，就能夠掌握訪問企業應用資源的所有裝置資訊

2.3. 裝置身份

  • 2.3.1. 所有受控裝置都要具備唯一的標識，用於索引裝置清單庫裡相關裝置的資訊

  • 2.3.2. 為每臺裝置簽發專用的裝置證書是其中一種實現方式

  • 2.3.3. 只有在裝置清單庫中登記在冊且資訊正確的裝置才可以獲得裝置證書，這些證書需要儲存在硬體或軟體模式的可信平臺模組（TPM）中，或者儲存在可靠的系統證書資料庫中

  • 2.3.4. 裝置自身以及裝置證書的儲存方式是否安全可靠需要進行驗證，只有被認為足夠安全的裝置才能被歸類為受控裝置

  • 2.3.5. 當證書定期更新時，也需要重新驗證裝置的安全可靠性

  • 2.3.6. 驗證透過的裝置，其安裝的證書就可以用於後續的企業應用訪問過程

  • 2.3.7. 雖然證書可以唯一地標識裝置，但僅憑裝置證書並不能獲得訪問許可權，證書只是獲取該裝置相關資訊的一把鑰匙

3. 安全地識別使用者

3.1. 單點登入（SSO）系統是BeyondCorp的集中式使用者認證門戶，它負責對請求訪問企業資源的使用者進行雙因子認證，使用者認證需要使用使用者資料庫和群組資料庫

3.2. 使用者認證成功之後，SSO系統會生成短時令牌，它可以作為特定資源訪問授權過程的一部分

4. 訪問代理

4.1. Google的所有企業應用都透過面向網際網路的訪問代理開放給外部和內部客戶端，該代理對客戶端和企業應用之間的通訊資料進行強制加密處理

4.2. 訪問代理可以基於每一個應用進行配置，同時提供了很多通用特性

  • 4.2.1. 全域性訪問可達、負載均衡、訪問控制檢查、應用安全檢查以及抗拒絕服務攻擊等

  • 4.2.2. 完成訪問控制檢查後，訪問代理將訪問請求轉發給後端應用

5. 實施基於清單庫的訪問控制

5.1. 隨著時間的推移，授予某個使用者或裝置的訪問許可權級別也可能會發生變化

5.2. BeyondCorp能夠透過查詢多個不同的資料來源，動態推斷使用者或裝置的信任等級

5.3. 信任等級是後續訪問控制引擎執行授權判定的關鍵參考資訊

  • 5.3.1. 如果某個裝置沒有安裝最新的作業系統安全補丁，那麼其信任等級會被降低

  • 5.3.2. 某一類特定裝置，比如特定型號的行動電話或平板電腦，可以被分配特定的信任等級

  • 5.3.3. 從新的地理位置訪問企業應用的某個使用者，會被分配不同的信任等級

  • 5.3.4. BeyondCorp同時使用了靜態規則和啟發式動態規則來確定使用者或裝置的信任等級

5.4. 授權的判定因素

  • 5.4.1. 使用者的資訊、使用者所在的群組、裝置證書以及裝置清單庫中獲取的裝置屬性

  • 5.4.2. 使用者和裝置的信任等級

  • 5.4.3. 如果有必要，訪問控制引擎也可以執行基於地理位置的訪問控制

  • 5.4.3.1. 訪問控制引擎還可以透過不同的方式來限制應用程式的各部分

6. 使用和擴充套件GFE

6.1. GFE（Google前端）

6.2. 為了評估策略，傳統的做法是在每個後端應用上整合裝置信任評估服務，但是這種做法會顯著降低產品安裝和更換的效率

6.3. 透過前端的訪問代理提供集中化的策略強制執行機制，用來處理粗粒度的企業安全策略

6.4. BeyondCorp利用Google現有的前端（GFE）架構作為訪問策略強制執行的邏輯中心

  • 6.4.1. 因為所有的訪問請求都彙集到這個邏輯中心進行處理，所以自然就可以在此基礎上擴充套件GFE的功能，比如自助服務開通、認證、授權和集中式日誌記錄等

6.5. 訪問代理透過引入認證和授權策略處理機制對GFE進行了擴充套件

  • 6.5.1. 訪問代理需要對發起訪問請求的使用者和裝置進行認證，才能做出正確的授權判定

  • 6.5.2. 訪問代理整合Google的身份提供者服務完成使用者身份認證

  • 6.5.2.1. 訪問代理支援多種第三方認證機制（包括OpenID Connect、OAuth等）也支援一些定製化協議

  • 6.5.3. 訪問代理完成使用者認證之後，將使用者憑證的相關資訊從訪問請求中去除，然後再將訪問請求轉發至後端服務

  • 6.5.3.1. 確保後端服務無法透過訪問代理重放訪問請求（或使用者憑證）

  • 6.5.3.2. 訪問代理對後端服務透明

>  6.5.3.2.1. 後端服務可以在訪問代理的資料流之上疊加自身的認證邏輯，並且也避免了將不必要的Cookie和使用者憑證暴露給後端業務

  • 6.5.4. 集中的訪問控制列表（ACL）引擎，支援遠端過程呼叫服務（PRC）查詢

  • 6.5.5. 專用的訪問控制列表表示語言，使其同時兼顧可讀性和可擴充套件性

  • 6.5.6. BeyondCorp的做法是由訪問代理完成集中式的粗粒度應用訪問授權，由後端應用各自實現自身的細粒度授權

  • 6.5.7. 後端應用把訪問控制邏輯委託給前端執行

  • 6.5.7.1. 後端應用需要適當的機制來確保前端訪問代理轉發的訪問流量的確已經透過了認證和授權檢查

  • 6.5.7.2. 後端應用接收到的只是在加密通道中傳輸的HTTP請求

  • 6.5.8. BeyondCorp採用了Google內部開發的認證和加密框架LOAS（Low Overhead Authentication System，低開銷認證系統）​，它可以支援訪問代理和後端應用之間的雙向認證和通訊加密

  • 6.5.9. 後端能夠信任訪問代理在訪問請求中插入的任何後設資料（通常以HTTP訊息頭的形式）​

  • 6.5.9.1. 在反向代理和後端應用之間使用自定義協議額外插入後設資料並不是什麼新方法

  • 6.5.9.2. 訪問代理和後端應用的雙向認證機制可以確保後設資料的不可欺騙性

  • 6.5.10. BeyondCorp就是採用這種方式實現了裝置信任等級向後端應用的傳遞，後端應用可以根據信任等級進行相應的處理

7. 多平臺裝置認證面臨的挑戰

7.1. 準確地識別裝置至少需要以下兩個元件

  • 7.1.1. 某種形式的裝置標識

  • 7.1.2. 可以跟蹤任何指定裝置最新狀態的裝置清單庫

7.2. 以適當的裝置信任替代基於網路位置的信任，所以每個裝置都必須有一個一致的、不可克隆的標識，關於裝置安裝的軟體、所屬使用者和位置的相關資訊必須整合到裝置清單庫中

7.3. 桌上型電腦和膝上型電腦使用X.509證書，對應的私鑰儲存在作業系統的證書庫中

  • 7.3.1. 金鑰的安全儲存是現代作業系統的標準功能，它確保透過訪問代理與伺服器通訊的命令列工具（以及守護程序）能夠匹配正確的裝置標識

  • 7.3.2. 由於TLS要求客戶端提供擁有私鑰的密碼學證明，而且裝置標識儲存在諸如可信平臺模組（Trusted Platform Module, TPM）這類安全硬體中，因此就能確保裝置標識的不可欺騙性且不可克隆性

7.4. 移動裝置的認證可以不依賴證書

  • 7.4.1. 移動作業系統本身就可以提供安全性高的裝置標識

  • 7.4.2. IOS裝置可以使用Vender識別符號（identifierForVender,IDFV）

  • 7.4.3. 安卓裝置可以使用企業移動管理軟體（EMM）提供的裝置ID

8. 遷移到BeyondCorp

8.1. Google投入了大量資源分階段地進行遷移，在不影響公司生產力的情況下，成功地將大批網路使用者遷移到了BeyondCorp

8.2. 部署無特權網路

  • 8.2.1. 該網路雖然使用私有地址空間，但是其使用者體驗與外部網路非常相似

  • 8.2.2. 無特權網路只提供網際網路訪問、受限的基礎網路服務（如DNS、DHCP和NTCP等）以及Puppet這類配置管理服務

  • 8.2.3. Google辦公區域中的所有客戶端裝置都被分配到這個無特權網路，對無特權網路與Google其他網路的訪問透過嚴格的ACL進行限制

8.3. 工作流遷移賦能

  • 8.3.1. Google的所有應用都要遷移到BeyondCorp，並最終透過訪問代理進行訪問

  • 8.3.2. 在特權網路中直接訪問，在外網可以透過VPN訪問

  • 8.3.3. 在特權網路中直接訪問，在外網和無特權網路中透過訪問代理訪問

  • 8.3.4. 在外網、特權網路和無特權網路均透過訪問代理訪問

8.4. 減少VPN的使用

  • 8.4.1. 積極勸阻使用者使用VPN

  • 8.4.2. 只有經證實確有需要的使用者才能使用VPN訪問

  • 8.4.3. 監控VPN的使用，如果使用者在一段時期內未使用過VPN，就取消其VPN訪問許可權

  • 8.4.4. 監控VPN的使用，如果使用者在一段時期內未使用過VPN，就取消其VPN訪問許可權

8.5. 流量分析管道

  • 8.5.1. 只有確信（或接近確信）使用者的工作流都可以從無特權網路中獲取到，才能將使用者遷移至無特權網路

  • 8.5.2. 從公司的每個交換機中採集網路流的樣本，作為流量分析管道的輸入

  • 8.5.3. 基於ACL分析無特權網路與公司其他網路之間的網路流量，識別命中ACL的流量

  • 8.5.4. 對於沒有命中ACL的“逃逸”流量，將其關聯到特定的工作流和/或特定的使用者（特定的裝置）上

  • 8.5.5. 逐步解決這些“逃逸”流量的問題，以使它們能夠在BeyondCorp環境下工作

8.6. 模擬無特權網路

  • 8.6.1. 作為補充，除了透過交換機取樣流量並進行流量分析外，我們還利用安裝在Google使用者裝置上的流量監視器，模擬了整個公司的無特權網路行為

  • 8.6.2. 流量監視器有兩種工作模式

  • 8.6.2.1. 日誌記錄模式

>  8.6.2.1.1. 捕獲“逃逸”流量，但仍允許上述流量流出裝置
  • 8.6.2.2. 強制執行模式
>  8.6.2.2.1. 捕獲和丟棄“逃逸”流量

8.7. 遷移策略

  • 8.7.1. 根據工作職責、​（和/或）工作流程、​（和/或）地理位置識別潛在的可遷移候選人集合

  • 8.7.2. 在日誌記錄模式下執行模擬器，識別連續30天合格流量大於99.9%的使用者和裝置

  • 8.7.3. 如果在這段時間內使用者和裝置的合格流量大於99.99%，則為這些使用者和裝置啟動強制執行模式

  • 8.7.3.1. 如有必要，使用者可以將模擬器恢復到日誌記錄模式

  • 8.7.4. 強制執行模式成功執行30天后，將其記錄在裝置清單庫中

  • 8.7.5. 如果使用者和裝置在可遷移物件候選人集合中，並且在模擬器強制執行模式下成功工作了30天，就可以把使用者和裝置遷移到無特權網路了

8.8. 豁免處理

  • 8.8.1. 允許使用者在遷移過程中請求臨時豁免

  • 8.8.2. 維護一個未完成BeyondCorp賦能、尚未達到遷移標準的工作流列表

  • 8.8.3. 使用者可以搜尋該工作流列表，經過審批後，將他們自身以及裝置標註為特定工作流的活躍使用者

  • 8.8.4. 該工作流完成BeyondCorp賦能之後，相關使用者會收到通知，並再次進入可遷移候選人名單

9. 經驗教訓

9.1. 溝通

  • 9.1.1. 安全基礎設施的根本性改變可能會對整個公司的生產力產生負面影響，因此與使用者充分溝通這種改變帶來的影響、可能出現的問題以及可能的補救措施十分重要

  • 9.1.2. 溝通不足可能導致的問題

  • 9.1.2.1. 問題發生時，使用者感到驚訝和疑惑

  • 9.1.2.2. 補救措施效果差

  • 9.1.2.3. IT支援人員的工作超出負荷

  • 9.1.3. 過度溝通可能導致的問題

  • 9.1.3.1. 不願改變的使用者會傾向於高估變化帶來的影響，並企圖尋求不必要的豁免

  • 9.1.3.2. 當出現有危險的變化時，使用者會認為是正常現象

  • 9.1.3.3. Google的企業基礎設施在許多互不相關的方面同時開展工作，使用者很容易將應用訪問相關的問題與其他正在進行的專案問題混淆，這也會降低補救措施的效率，增加技術支援人員的工作負荷

9.2. 工程師需要支援

  • 9.2.1. 遷移能否成功很大程度上取決於團隊在訪問代理上配置後端服務的難易程度，因此後端服務的配置上線應當以減輕開發人員的開發負擔為目標，要把異常情況的出現維持在最低限度

  • 9.2.2. 沙箱在大部分情況下都非常有用，比如在對X.509證書或底層TLS庫進行重大變更之後，需要確保客戶端TLS連線能成功進行時，可以使用沙箱進行驗證

9.3. 資料質量和相關性

  • 9.3.1. 資產管理的資料質量問題非常關鍵，它可能會導致使用者裝置無意中失去對企業資源的訪問許可權

  • 9.3.2. 拼寫錯誤、標識錯誤和資訊丟失都是常見的資料質量問題，導致此類問題出現的原因有很多，可能是採購團隊接收資產並將其新增至系統時的人為失誤，也可能是製造商工作流程的失誤

  • 9.3.3. 改進工作流程，並增加自動輸入驗證功能，以便於在資料錄入時發現並減少人為錯誤

  • 9.3.4. 準確的信任評估需要裝置清單庫提供高精度的資料，這會迫使人們高度關注裝置清單庫中的資料質量

  • 9.3.5. 零信任架構裝置信任評估使資料的精確性達到前所未有的水平，也帶來了一定的安全價值

9.4. 稀疏資料集

  • 9.4.1. 裝置清單庫的上游資料來源不一定有重疊的裝置識別符號

  • 9.4.1.1. 新裝置也許有資產標籤，但是沒有主機名

  • 9.4.1.2. 在裝置生命週期的不同階段，硬碟序列號可能與不同的主機板序列號相關聯

  • 9.4.1.3. MAC地址可能發生衝突

相關文章