本文上次更新於 2024 年 5 月，內容反映截至撰文時的情況。我們一向持續提升客戶保護措施，因此安全性政策和系統日後可能會有所變動。
本文說明我們如何運用程式碼審查、安全基礎架構，以及稱為 Borg 適用的二進位授權 (BAB) 的強制執行檢查，協助保護 Google 的軟體供應鏈，防範內部風險。BAB 可確保實際工作環境軟體在部署前經過審查和核准，特別是當程式碼可存取機密資料時，因此有助於降低內部風險。BAB 適用於在 Borg 上執行的所有服務。自本文件首次發布以來，我們已將 BAB 的重要概念納入名為「軟體構件供應鏈級別 (SLSA)」的開放規格。
本文是系列技術文件的一部分，說明 Google 安全團隊開發的部分專案，包括 BeyondCorp 和 BeyondProd，有助於提升安全性。如要概略瞭解基礎架構的安全性，請參閱 Google 基礎架構安全性設計總覽。
簡介
內部風險 是指使用者資料所面臨的安全性威脅，可能包括僱傭資料、財務資料，或其他專有或商業資料。 內部風險是指員工可能利用機構知識或存取權執行惡意行為，或是外部攻擊者可能利用遭盜用的員工憑證執行惡意行為。
為盡量降低軟體供應鏈的內部風險，我們使用 BAB。BAB 是一項在軟體部署完畢後進行的內部強制執行檢查。BAB 可確保程式碼和設定部署作業符合最基本的安全標準，並統一實際工作環境系統。
我們會限制員工的單向存取權 ，協助保護正規作業系統中的使用者資料。有了 BAB，員工就無法在沒有適當授權和正當理由的情況下，逕行直接或間接存取使用者資料，或以其他方式影響使用者資料。BAB 和相關控制項可協助我們強制執行最小權限原則，進而提升安全防護能力，不受特定威脅行為人影響。換句話說，無論行為人是懷有惡意，還是帳戶遭到盜用，或是意外獲得存取權，BAB 都能限制單方面存取。
BAB 福利
採用 BAB 和容器化部署模型，可為 Google 基礎架構提供許多安全防護優勢。包括：
- BAB 有助於降低總體內部風險：BAB 可要求程式碼必須符合某些標準和變更管理做法，才能存取使用者資料。這項規定可防範員工逕自作業 (或盜用員工帳戶的人士) 透過程式存取使用者資料。
- BAB 有助統一實際工作環境系統：透過容器化系統的使用，以及在部署之前驗證 BAB 要求，我們的系統變得更易於偵錯、更可靠，且變更管理流程也更加明確。BAB 要求為實際工作環境系統要求提供了一種共通語言。
- BAB 規定了資料保護的共通語言：BAB 會追蹤 Google 各個系統間的一致性。我們會在內部公布此種一致性的相關資料，供其他團隊查詢。發布 BAB 資料後，團隊在交流資料存取保護意見時，就能使用共通的語言。有了這種共通語言，進行跨團隊的資料處理作業時，往返次數就能減少。
- BAB 能夠以程式輔助方式追蹤法規遵循要求：BAB 簡化了原先必須手動執行的法規遵循工作。Google 的某些流程要求對資料處理方式採取更嚴格的控管措施。例如，我們的財務報告系統必須遵守《沙賓法案》(SOX)。在實行 BAB 之前，我們已有一套協助手動執行法規遵循驗證的系統。隨著 BAB 的推出，許多檢查作業都可根據服務的 BAB 政策自動執行。這些檢查的執行作業自動化以後，法規遵循團隊便得以擴大服務範圍，並對這些服務採取適當的控管措施。
BAB 是我們用來降低內部風險的BeyondProd 架構之一。
我們的開發和生產流程
根據預設，Google 的開發和生產程序包含四個必要步驟：程式碼審查、可驗證的建構作業、容器化部署，以及服務身分。以下各節將詳細說明這些步驟。
第 1 步：程式碼審查
我們的大部分原始碼都儲存在中央單體式存放區( ) 中，且需要由作者以外的工程師(至少一位) 審查及核准 。單體式程式碼集可讓您強制執行程式碼審查的單一堵塞點。
我們的程式碼審查程序的基本規則如下：對任何系統執行的程式碼修改作業都必須得到該系統負責人的核准。
從第三方 或開放原始碼匯入變更時，我們會驗證變更是否合適 (例如，是否為最新版本)。 不過，對於外部開發人員對我們使用的第三方或開放原始碼所做的每一項變更，我們通常沒有相同的審查控管措施。
第 2 步：可驗證的建構
我們的建構系統 與 Bazel 類似，可建構及編譯原始碼，為部署作業建立二進位檔。我們的建構系統在獨立且處於鎖定狀態的環境中運作 ，該環境與員工執行建構作業的環境是分開的。系統會為每個建構作業產生可驗證建構作業 產生的來源。這份出處資訊是已簽署的憑證，當中描述用於建構作業的來源和依附元件、任何二進位檔或其他建構作業構件的密碼編譯雜湊，以及完整的建構參數。這項出處資訊可實現下列功能：
- 從二進位檔追溯檔案建立過程中所用的原始碼。進一步來說，出處資訊也能追溯此資訊清單描述的原始碼所歷經的建立和提交過程。
- 驗證二進位檔是否經過修改，因為對該檔案的任何變更都會自動使其簽署失效。
由於建構作業可以是任意程式碼，因此我們的建構系統已針對多用戶群進行安全強化。換句話說，我們建構系統的設計宗旨，就是要防止單一建構作業影響其他建構作業。系統可防止建構作業進行任何可能危害建構出處或系統本身完整性的變更。建構完成後，系統會使用 Borg 部署變更。
步驟 3：容器化部署
建構系統建立二進位檔後，會將其封裝到容器映像檔 ，並以 Borg 工作 的形式部署到叢集自動化調度管理系統 Borg。 我們在多個叢集中執行數十萬個來自多種應用程式的工作，每個叢集包含多達數萬台機器。儘管規模如此龐大，我們的實際工作環境仍具有相當高的同質性。因此，我們可以更輕鬆地控管及稽核存取使用者資料的接觸點。
容器 可提供顯著的安全性優勢。容器具有不可變的性質，因此須透過完整重構的映像檔頻繁地重新部署。容器化可讓我們在背景資訊中審查程式碼變更，並為部署到基礎架構中的變更提供單一的堵塞點。
Borg 工作的設定 可為待部署的工作指定要求：容器映像檔、執行階段參數、引數和旗標。Borg 會根據工作限制、優先順序、配額，以及設定中列出的任何其他要求，安排工作時程。部署完成後，Borg 工作就可以與實際工作環境中的其他工作進行互動。
步驟 4：以服務為基礎的身分
Borg 工作會以服務身分執行。 此身分用於存取其他服務的資料儲存庫或遠端程序呼叫 (RPC) 方法 。多項工作可以使用同一身分執行。只有負責執行服務的員工 (通常是網站可靠性工程師 (SRE))，才能部署或修改具有特定身分的工作。
Borg 啟動工作時，會為工作佈建密碼編譯憑證。工作透過應用程式層傳輸安全性 (ALTS) 對其他服務發出要求時，會使用這些憑證來證明身分。 如要讓某項服務存取特定資料或其他服務，其身分須具備必要的權限。
根據我們的政策規定，凡是具有使用者資料和其他任何機密資訊存取權的服務身分，都必須受到 BAB 保護。 至於無法存取機密資料的品質確保和開發工作，則可在管控較鬆的情況下執行。
BAB 的運作方式
BAB 會與 Borg 整合，確保只有獲得授權的工作能以各項服務的身分執行。此外，BAB 也會建立稽核追蹤記錄 ，追蹤啟用 BAB 的工作中所使用的程式碼和設定，方便監控及處理事件。
BAB 的設計宗旨是確保所有實際工作環境軟體和設定都經過確實的審查、簽入、以可驗證的方式建構及授權，特別是相關程式碼可存取使用者資料時。
服務專用政策
服務負責人將服務加入 Borg 時， 會建立 BAB 政策，定義服務的安全性要求。這項政策稱為「服務專用政策」。定義或修改政策本身就是一種變更程式碼的作業，必須進行審查。
服務專屬政策會定義哪些程式碼和設定可做為服務的身分執行，以及這些程式碼和設定的必要屬性。以服務身分執行的所有工作都必須符合服務專屬政策。
Google 的所有 Borg 服務都必須設定服務專屬政策。
這項做法預設會強制執行下列規定：
- 程式碼必須可供稽核： 透過可驗證的建構作業產生的出處，我們可以將容器映像檔追溯至可供人解讀的來源。保留政策會將程式碼的人類可讀來源保留至少 18 個月，即使未提交程式碼也是如此。
- 程式碼必須提交： 程式碼是透過原始碼存放區中特定的定義位置所建構。通常，提交的程式碼皆已經過審查。
- 設定必須提交： 在部署作業期間提供的任何設定，都會經歷與一般程式碼相同的審查和提交流程。因此，只要未經過審查，任何指令列旗標值、引數和參數都無法進行修改。
如果服務無法存取機密資料，或在極少數情況下，服務獲得有效且核准的例外狀況，則可能適用較寬鬆的政策，例如僅要求程式碼可稽核，甚至完全停用 BAB。
強制執行 BAB 的系統和元件受到嚴格控管，除了嚴格的自動化要求外，還有人工控管措施。
強制執行模式
BAB 會使用兩種強制執行模式，確保工作符合服務專屬政策：
- 部署時強制執行，禁止部署不符合規定的工作。
- 持續驗證：監控並提醒您已部署的不符規定工作。
此外，在緊急情況下，緊急應變程序可以略過部署時的強制執行。
部署期間強制執行模式
Borg Prime 是 Borg 的集中式控制器，也是 ALTS 的憑證授權單位。提交新工作後，Borg Prime 會諮詢 BAB，確認工作符合服務專屬政策規定，然後 Borg Prime 才會將 ALTS 憑證授予該工作。這項檢查就如同許可控制器：只有在符合服務專屬政策時，Borg 才會啟動工作。即使員工或服務有權提出部署要求，系統仍會進行這項檢查。
在極少數情況下，服務可以提供充分理由，選擇在部署時不強制執行。
持續驗證模式
部署工作後，無論工作在部署期間的強制執行模式為何，系統都會在其生命週期內對工作持續進行驗證。BAB 程序每天至少會執行一次，檢查已啟動 (且可能仍在執行) 的工作是否符合政策的最新要求。 舉例來說，持續驗證模式會不斷檢查工作，確認是否使用過時政策，或是透過緊急應變程序部署。如果發現工作不符合最新的政策要求，BAB 會通知服務負責人，以利他們採取措施來降低風險。
緊急應變程序
如果發生突發事件或故障，我們的首要任務是盡快恢復受影響的服務。在緊急情況下，可能需要執行尚未審查或以可驗證方式建構的程式碼。因此，您可以使用緊急應變旗標覆寫強制執行模式。 萬一本來應該阻止部署作業的 BAB 出現故障，緊急應變程序也可以充當備用措施。開發人員使用緊急應變程序部署工作時，必須在要求中提交正當理由。
在緊急應變期間，BAB 會記錄相關 Borg 工作的詳細資料，並透過「低延遲緊急應變管道」 和服務身分擁有團隊，向 Google 的中央安全團隊發送通知。 記錄項目會包含已部署程式碼的快照參照，以及使用者提供的理由。只有在不得已的情況下，才須啟動緊急應變程序。
將 BAB 擴展至其他環境
BAB 最初僅支援保護 Borg 工作，且需要使用 Google 的傳統來源控制、建構和封裝管道開發軟體。現在，BAB 已新增支援功能，可保護其他軟體交付和部署環境，並支援替代來源控制、建構和封裝系統。這些不同環境的實作細節有所差異，但 BAB 的優點依然存在。
在部署前，有幾種情況不太適合進行人工程式碼審查，特別是機器學習程式碼的疊代開發，以及高頻率的資料分析。在這些情況下，我們有替代控制措施，可彌補人工審查的不足。
在您的機構中採用類似的控管措施
本節將說明我們在導入 BAB 時學到的最佳做法，方便您在機構中採用類似的控管措施。
建立同質化的容器化 CI/CD 管道
由於大多數團隊都使用單一來源控管系統、程式碼審查程序、建構系統和部署系統，因此採用 BAB 變得更加容易。程式碼審查早已是我們文化的一部分，因此我們能夠進行變更，而不會對使用者造成太多重大影響。為採用 BAB，我們著重於程式碼審查、可驗證的建構作業、容器化部署，以及用於存取權控管的服務身分。這不但能簡化 BAB 的採用程序，還能強化 BAB 這類解決方案的可靠性。
我們廣泛使用微服務和以服務為主的身分 (例如服務帳戶)，而不是以主機為主的身分 (例如 IP 位址)，因此能夠精細控管允許執行各項服務的軟體。
如果貴機構無法直接採用服務身分，則可嘗試使用其他措施保護身分符記，做為臨時措施。
確定目標，並根據需求定義政策
建構政策導向發布流程 (每次建構一部分)。在 CI/CD 管道中，您可能需要較早實行某些變更。例如，您可能需要開始進行正式的程式碼審查，然後才能在部署期間強制執行審查。
法規遵循是建構政策導向發布流程的主要動機。如果您可以將政策中的某些法規遵循要求編寫成程式碼，就能促進測試作業的自動化，並且確保這些測試持續發揮功效。您可以從基本要求著手編寫，然後再逐步編寫更進階的要求。
在開發初期強制執行政策
如果事先不知道某一款軟體的預定執行位置，以及該軟體將會存取哪些資料，您將很難為該軟體定義完善的政策。因此，服務專屬政策會在部署程式碼及程式碼存取資料時 (而不是建構程式碼時) 強制執行。政策是根據執行階段身分定義的，因此相同的程式碼可能會在不同的環境中執行，並受不同政策的約束。
除了其他存取機制以外，我們還使用 BAB 來限制對使用者資料的存取。 服務負責人可以進一步確保只有符合特定 BAB 要求的工作才能存取資料。
成立跨團隊變更專案團隊
我們宣布在 Google 內部全面實施 BAB 部署作業後，在各產品團隊中選出了推動變更的負責人，而他們正是影響實施成功率的最大因素。 我們選出能夠看到強制執行的立即功效，且願意提供意見回饋的服務負責人。我們已邀請這些擁有者自願參與，再進行任何強制性變更。在取得他們的幫助後，我們成立了一個正式的變更管理團隊，專責追蹤進行中的變更。然後，我們再從各產品團隊選出負責人來實施變更。
決定如何管理第三方程式碼
如果必須管理第三方程式碼，請考慮如何在第三方程式碼庫中導入政策規定。舉例來說，您可以先從保管所有使用過的第三方程式碼開始。建議您定期根據安全要求檢查該程式碼。
如要進一步瞭解如何管理第三方程式碼，請參閱「共同打造更安全的開放原始碼社群」。
後續步驟
- 瞭解我們用來為微服務建立安全邊界的 BeyondProd。
- 如要採用安全無虞的 CI/CD 管道，請參閱「軟體構件供應鏈級別 (SLSA)」。