Borg 適用的二進位授權:Google 如何驗證程式碼來源及實作程式碼身分識別機制

Google 撰寫了多篇白皮書,專門介紹我們的安全團隊在內部開發的安全強化專案,其中包括 BeyondCorpBeyondProd。如需 Google 的安全性總覽資訊,請參閱我們的安全性基礎架構設計白皮書。

在這篇白皮書中,我們會說明 Google 的程式碼審查程序、來源追溯1及強制執行機制的必要性。我們會著重說明「Borg 適用的二進位授權 (BAB)」這項強制檢查機制的開發作業。BAB 的目標是確保部署在 Google 的實際工作環境軟體經過確實的審查與授權 (特別是其中的程式碼能存取使用者資料的軟體),藉此降低內部風險。不論是哪一種 Google 產品,我們都十分重視使用者資料的安全,並盡可能完整公開我們採取的安全防護措施。

本白皮書的內容撰寫於 2019 年 12 月,內容中的所有資訊皆以當時情況為依據。我們會持續改善客戶資料的保護機制,因此 Google Cloud 的安全性政策和系統未來可能會有所變動。

資訊長層級摘要

  • 內部風險是指使用者資料所面臨的安全性威脅。在 Google,我們希望盡可能降低 Google 人員以未經授權的方式,使用機構相關知識或存取使用者資料的可能性,執行未經授權的工作也包含在內。
  • Borg 適用的二進位授權 (簡稱 BAB) 是內部的部署期間強制檢查機制,可確保部署在 Google 的實際工作環境軟體和設定都已經過確實的審查與授權 (特別是可存取使用者資料的程式碼),藉此將內部風險降至最低。
  • BAB 可確保程式碼和設定部署作業符合最基本的安全標準。
  • 除了強制檢查外,BAB 還可用於非強制稽核模式,此模式會在安全未達某些標準時發出警告。
  • 採用 BAB 有助我們降低內部風險、防範潛在攻擊,以及統一 Google 的實際工作環境系統。

將 Google 內部風險降至最低

Google 將公司安全性視為第一要務,因此採取了相關措施來降低內部風險,避免 Google 人員 (或機構中的其他任何人) 利用機構知識或存取權,來從事惡意行為。此外,內部風險還包括攻擊者盜用 Google 內部人員的憑證以進行攻擊。我們投入了大量資源,推動內部風險防範領域的創新工作。在 Google,我們將保護使用者資料視為優先要務,並且致力提供全方位的防護措施。我們的目標是防止 Google 員工在未經授權的情況下存取使用者資料。

存取使用者資料的授權

在 Google,我們的服務和人員有時必須存取使用者資料。我們會在有以下需求時,透過下列方式與使用者資料互動:

  1. 透過使用者身分存取:員工直接向特定服務進行身分驗證,使服務傳回員工自己的資料。例如,登入 Gmail 帳戶的員工可看到自己的電子郵件。
  2. 某些人員在執行工作時需要:Google 人員的大部分工作都可以使用去識別化的使用者資料順利完成。但在極少數情況下,我們的人員需要在工作 (例如支援或偵錯) 中存取使用者資料。我們的目標是盡可能提高使用者資料存取的透明度。為了達到這個目標,我們採用資料存取透明化控管機制,讓 Google Cloud 客戶透過即時記錄檔查看相關人員對其資料的合格存取情況。
  3. 服務的某些部分需要 (透過程式取得):為了完成工作,某些服務可能需要透過程式大規模存取使用者資料。例如,資料管道會同時查詢數千名使用者的資料,以產生匯總的使用統計資料。出現此類需求時,系統會授予整個資料集 (而不是個別使用者資料) 的存取權。此外,系統不會記錄每位個別使用者的資料存取情況。

本白皮書著重說明第三種情形中介紹的威脅模式。我們希望針對可存取使用者資料的系統,確保系統管理員無法濫用權限。

威脅模式

本文討論的控管措施旨在透過防止單方存取來保護使用者資料。我們希望阻止 Google 人員在沒有適當授權和正當理由的情況下,逕行直接或間接存取使用者資料,或以其他方式影響使用者資料。無論行為人是懷有惡意,還是帳戶遭到盜用,或是意外獲得授權,我們的控管措施都能防止前述情況發生。

Google 的容器化基礎架構

我們的基礎架構使用名為 Borg 的叢集管理系統實現了容器化管理。我們在多個叢集中執行數十萬個來自多種應用程式的工作,每個叢集包含多達數萬台機器。儘管規模如此龐大,我們的實際工作環境仍具有相當高的同質性。因此,我們可以更輕鬆地控管及稽核用來存取使用者資料的接觸點。

此外,透過容器的使用,我們也獲得了顯著的安全優勢。 在使用上,容器具有不可變的性質,因此須透過完整重構的映像檔頻繁地重新部署。這個特性使我們能夠在背景資訊中審查程式碼變更情況,並為部署到我們基礎架構中的所有變更提供單一的堵塞點。

如要瞭解我們如何開發解決方案,藉此限制服務透過程式存取使用者資料的權限,首先必須瞭解服務在 Google 內部進入實際工作環境的流程。

第 1 步:程式碼審查

我們的原始碼儲存在單體式中央存放區中,可讓數千名員工將程式碼簽入單一位置。使用單一程式碼集可以簡化原始碼管理,特別是依賴於第三方程式碼的依附元件。單體式程式碼集還可讓您強制執行程式碼審查的單一堵塞點。在 Google,程式碼審查程序包含由作者以外的工程師 (至少一位) 進行的檢查及核准作業。我們的程式碼審查程序的基本規則如下:對任何系統執行的程式碼修改作業都必須得到該系統負責人的核准。程式碼一旦簽入,就會進行建構。

從第三方或開放原始碼匯入變更時,我們會驗證變更是否合適 (例如,是否為最新版本)。但是,針對外部開發人員對我們使用的第三方或開放原始碼所做的每項變更,我們通常沒有相同的審查控管措施。

第 2 步:可驗證的建構

我們使用的建構系統與 Bazel 十分類似,該系統會建構及編譯原始碼,為部署作業建立二進位檔。我們的建構系統在獨立且處於鎖定狀態的環境中運作,該環境與員工執行建構作業的環境分開。系統會針對每次建構作業產生一份可驗證的建構資訊清單。該清單是一份已簽署的憑證,當中完整描述用於建構作業的原始碼、任何二進位檔或其他建構作業構件的密碼編譯雜湊,以及完整的建構參數。透過此資訊清單,我們可以從二進位檔追溯檔案建立過程中所用的原始碼,進一步追溯至此清單描述的原始碼所歷經的建立和提交過程。此外,該資訊清單還能夠讓我們驗證二進位檔是否經過修改,因為對該檔案的任何變更都會自動使其簽署失效。

由於建構作業在理論上可以是任意程式碼,因此我們的建構系統已針對多用戶群進行了安全強化。換句話說,我們建構系統的設計宗旨,就是要防止單一建構作業影響其他建構作業。系統可防止建構作業進行任何可能危害可驗證建構資訊清單或系統本身完整性的變更。建構完成後,系統會使用 Borg 部署變更。

第 3 步:部署工作

建構完成後,二進位檔即能夠以 Borg 工作的形式部署到我們的容器化基礎架構中。這些工作使用可能包含二進位檔或資料的套件,其安裝作業由 Borg 管理。Borg 設定可為待部署的工作指定要求:套件、執行階段參數、引數和旗標。Borg 會根據限制條件、優先順序、配額以及設定中列出的任何要求來安排工作時程。部署完成後,Borg 工作就可以與實際工作環境中的其他工作進行互動。

第 4 步:工作身分

Borg 工作是透過身分來執行,且會藉由此身分來存取其他服務的資料儲存庫或遠端程序呼叫 (RPC) 方法。這個身分可以是角色帳戶 (例如服務) 或使用者帳戶 (例如員工的個人帳戶)。多項工作可以使用同一身分執行。只有負責執行服務的人員,才能部署或修改具有特定身分的工作,這類人員通常是我們的網站可靠性工程師 (SRE)

Borg 啟動工作時,會為工作佈建密碼編譯憑證。 工作透過應用程式層傳輸安全性機制對其他服務發出要求時,會使用這些憑證來證明身分。如要讓某項服務存取特定資料或其他服務,其身分須具備必要的權限。以 Google Cloud 的 Cloud Data Loss Prevention (Cloud DLP) API 服務為例。Cloud DLP API 如要存取掃描用資料,須符合以下兩項條件。首先,Cloud DLP API 必須設定為使用明確身分 (在本例中為角色帳戶) 執行作業。其次,該角色帳戶必須具備權限,能夠存取 Cloud DLP API 要掃描的資料。如果沒有有效的身分和正確的權限,服務將無法執行掃描作業。

根據我們的政策規定,只要是具有使用者資料 (或其他任何機密資訊) 存取權的角色帳戶,都必須由 BAB 和其他安全系統嚴格控管。至於無法存取機密資料或資源的品質確保和開發工作,則可在管控較鬆的情況下執行。

總結:工作的生命週期

簡單來說,在我們的基礎架構上執行工作的步驟如下:

  1. Google 開發人員對程式碼進行變更。開發人員隨後將程式碼傳送給一或多位其他 Google 工程師進行審查。審查工作包括檢查是否有適當的授權和記錄。獲得核准後,程式碼會簽入。
  2. 由開發人員觸發後,建構系統會在沙箱環境中以可驗證的方式建構及封裝二進位檔。此建構作業會產生一個套件,建構系統隨後會對該套件執行驗證用途的簽署作業。
  3. 前述工作會由一名工程師部署至 Borg 中。這名工程師須獲得特別授權,才能管理以適當安全身分執行的工作。
  4. 當 Borg 工作嘗試存取如使用者資料等特殊權限資源時,系統會驗證該工作的身分以進行授權。

現在,您已瞭解工作在 Google 實際工作環境中的執行方式,接下來讓我們看看 BAB 所要處理的威脅模式:防止潛在的惡意內部人員執行未經授權的工作。為此,BAB 會在部署二進位檔之前,確認一切必要的安全性檢查是否都已完成。

本節簡要介紹了我們的容器化基礎架構。如要瞭解我們為了控管使用者透過程式存取資料的權限,而採取了那些措施,您對我們的實際工作環境必須有基本認識。下節將詳細介紹這些控管措施。

Borg 適用的二進位授權 (BAB)

幾年來,我們一直在努力防止使用者資料遭到手動存取。其中的一項措施,就是只把資料和工作管理權限,授予在工作上需要此權限的 Google 人員。

BAB 的任務是確保部署在 Google 的實際工作環境軟體和設定,都已經過確實的審查與授權 (特別是可存取使用者資料的程式碼)。為此,BAB 提供了部署期間強制執行服務,可防範未經授權的工作啟動。此外,BAB 也提供稽核追蹤功能,用於追蹤啟用 BAB 的工作中所使用的程式碼和設定。

驗證

BAB 會驗證二進位檔在部署時是否符合特定要求。例如,服務負責人可能會要求服務的二進位檔必須使用經過審查、簽入、測試和授權的程式碼來建構。我們將這些類型的檢查稱為部署期間檢查。BAB 還可以在二進位檔完成部署後執行檢查,我們將這些類型的檢查稱為部署後檢查。如要進一步瞭解部署後驗證,請參閱強制執行模式一節。

程式碼變更會產生新的二進位檔。這個新二進位檔必須經過部署,當中的變更才會生效。BAB 可進行多種部署期間檢查。這些檢查包括:

  • 二進位檔是否使用已簽入的程式碼建構

    程式碼是否已提交到並簽入 Google 的原始碼存放區?要提交的程式碼通常必須先由另一位 Google 工程師進行審查。

  • 二進位檔是否以可驗證的方式建構

    此二進位檔是否可以追溯到可稽核的來源,並且是否由核准的建構系統建構?

  • 二進位檔是否使用經過測試的程式碼建構

    二進位檔是否符合測試要求?

  • 二進位檔是否使用預定在部署作業中使用的程式碼建構

    程式碼是否已提交到原始碼存放區的適當區域 (該區域與該特定 Borg 工作的專案或團隊相對應)?

雖然這些是專門針對我們實際工作環境的檢查,但您也可以在 CI/CD (持續整合/持續部署) 環境中根據自己的安全性、可靠性或法規遵循需求強制執行類似的檢查。

服務專用政策

存取機密資料的工作通常須提交程式碼,但有一些出於正當商業原因的例外情況。機密資料包括使用者資料、僱傭和財務資料,以及其他任何具「有知情必要」性質的專屬或商業資料。Google 內部的所有工作都必須具備政策,即使是不需要存取使用者資料的 Borg 工作,也得配有已定義的政策,只是當中不會列出具體要求。

服務負責人加入 BAB 時,會定義一項政策,其中包含服務的安全性要求。用於實作其服務的所有角色帳戶都必須指定 BAB 政策。BAB 政策會定義每個角色帳戶預定要啟動的工作,以及工作的程式碼和設定要求。定義或修改政策本身就是一種變更程式碼的作業,必須進行審查。

可以在 BAB 政策中強制執行的要求包括:

  • 程式碼是以可驗證的方式建構:以可驗證方式建構的程式碼可以稽核,但這並不表示程式碼已經過審查,有時候程式碼甚至尚未提交。在可驗證的建構作業中使用的程式碼至少有 18 個月可進行稽核,即使沒有提交也是如此。

  • 程式碼已提交:程式碼是透過原始碼存放區中特定的預期位置所建構。通常這種程式碼皆已經過審查。

  • 設定已提交:在部署作業期間提供的任何設定,都會經歷與一般程式碼相同的審查和提交流程。因此,只要未經過審查,任何指令列旗標值、引數和參數都無法進行修改。

強制執行 BAB 的系統和元件必須受到嚴格控管,也就是透過實作最嚴格的要求及手動控管措施來達成。

強制執行模式

BAB 會根據 Borg 工作指定的政策執行不同的動作。我們將這些動作稱為強制執行模式,可分為三種:部署期間強制執行、部署期間稽核和持續驗證。定義政策時,服務負責人必須選擇部署期間強制執行,或者是部署期間稽核。持續驗證模式則預設為啟用。下列各節將詳細介紹每種模式。

部署期間強制執行模式

提交新工作後,Borgmaster2 會諮詢 BAB,以確認工作符合 BAB 政策中規定的要求。這項檢查就如同許可控制器,如果符合要求,Borgmaster 就會啟動該工作。如果不符合要求,即使發出要求的使用者透過其他方式取得授權,Borgmaster 也會拒絕該工作。

在強制執行模式下,如果 Borg 工作不符合其 BAB 政策規定的要求,BAB 將阻止該工作的部署作業。新進入 BAB 的服務通常會從稽核模式 (下節將會介紹) 開始,然後升級到強制執行模式。

緊急應變程序

如果出現突發事件或故障,我們的首要任務是盡快恢復受影響的服務。在緊急情況下,可能需要執行尚未審查或簽入的程式碼。此時,您可以使用緊急應變旗標來覆寫強制執行模式。萬一本來應該阻止部署作業的 BAB 出現故障,緊急應變程序也可以充當備用措施。使用緊急應變程序部署工作的開發人員必須在其要求中提交正當理由。

在使用緊急應變程序的幾秒鐘內,BAB 會記錄相關 Borg 工作的詳細資訊。記錄內容會包含使用的程式碼及使用者提供的正當理由。幾秒鐘後,系統就會將稽核追蹤資訊傳送給我們的中央安全團隊,並在數小時內傳送給擁有角色帳戶的團隊。只有在不得已的情況下,才須啟動緊急應變程序。

部署期間稽核模式

在稽核模式下,如果 Borg 工作不符合政策要求,BAB 會進行記錄,但不會阻止其部署。不符合政策要求的工作會觸發快訊,提醒擁有角色帳戶的團隊。

在 Google,我們會要求特定服務 (例如存取使用者資料的服務) 使用強制執行模式。我們強烈建議所有服務負責人都使用強制執行模式,只有在將新服務加入 BAB 時才使用稽核模式。如要使用稽核模式,服務負責人必須提供正當理由,才能取得例外權限。例如,如果服務的可靠性服務等級目標 (SLO) 明顯高於 BAB 提供的目標,就可以使用稽核模式。

儘管稽核模式在微調初始政策時非常有用,但對於大多數服務而言並非實際穩定狀態。在稽核模式下,如有服務違反政策,服務負責人要到數小時後才會收到相關通知。這可能會造成通知記錄龐雜,致使真正的安全問題誤遭忽視,或導致服務負責人對政策進行錯誤設定。使用強制執行模式時,服務負責人會在嘗試啟動不符合政策的工作時,立即收到通知。因此負責人的通知記錄會清楚、明瞭得多。此外,BAB 中的強制執行模式還會抓出意外錯誤,例如不小心使用非預期角色啟動工作的錯誤。

持續驗證

部署工作後,無論工作在部署期間的強制執行情況如何,系統都會在其生命週期內對工作持續進行驗證。BAB 驗證程序會每天至少執行一次,以檢查已啟動 (並且可能仍在執行) 的任何工作是否符合其政策的最新要求。舉例來說,持續驗證模式會不斷進行檢查作業,以辨識出使用過期政策,或是使用透過緊急應變程序部署的身分來執行的工作。如果發現工作不符合最新的政策要求,BAB 會通知服務負責人,以利他們採取措施來降低風險。

全域皆允許使用的套件

Google 提供的許多服務廣泛使用某些套件。我們是透過中央機制允許這些套件的使用,而不強制每項服務維護各自的套件版本,所以此類套件稱為全域控管套件。在編寫 BAB 政策時,服務負責人可以為工作指定全域皆允許使用的套件。這些廣泛使用的套件也具有全域預設機制,因此使用者無須在每項服務的政策中,個別列出這些套件。如此一來,Google 就可以明確控管整個機構使用的常見系統元件,並且在不麻煩各個團隊的情況下對這些元件進行確實審查及更新。雖然各服務負責人都可以在服務的 BAB 政策中明確允許這些套件的使用,但系統支援的這個機制能為他們提供更加便利的途徑,Google 也推薦使用。

極端案例

對於部署在實際工作環境中的程式碼,Google 實施完善可靠的安全控管措施,包括程式碼審查可驗證的建構作業。BAB 可做為額外的控管機制和強制執行點,確保前述的安全控管措施確實能妥善運作。

但是,BAB 並非在所有情況下都能發揮效用。BAB 不支援以下極端案例:使用非標準建構系統建構的程式碼;部署在非 Borg 環境中的程式碼;以及資料分析和機器學習程式碼:在選擇最終實際工作環境參數之前,這類程式碼不適合進行人工程式碼審查。對於前述案例,我們採取了許多不同的措施來緩解安全性風險,包括其他程式碼來源系統。不過,這些程式碼仍受 Google 的一般安全控管措施約束。

實行 Borg 適用的二進位授權

為了實行 BAB,BAB 團隊開發了多項新功能,包括緊急應變程序和稽核模式。這些工具可讓服務負責人輕鬆地自行試用 BAB。如果您正考慮在自己的機構中部署類似 BAB 的機制,您可能需要進行一些額外的步驟來完成轉換作業。本節介紹了我們實行計畫中的機構和變更管理工作。

優點

BAB 提供三項優點,讓 Google 在著眼業務時,有充分的理由開發並採行這項方案。這三項優點如下:降低內部風險、強化程式碼身分及簡化法規遵循程序。

降低內部風險

BAB 的功用主要是防止任何個人在未經授權的情況下,以程式輔助方式存取使用者資料。有了 BAB,任一位工程師或取得工程師憑證的攻擊者就較難在不被發現的情況下,以不當方式存取機密資料。

強化程式碼身分

正如容器化基礎架構一節所述,Borg 工作是透過身分 (通常是角色帳戶) 來執行。在授予對任何資料的存取權之前,其他服務會使用此身分來驗證授權。但是,其他服務無法強制使用該資料,因此必須信任工作身分不會濫用其收到的資料。BAB 會將工作的身分與特定的程式碼繫結在一起,進而確保只有指定的程式碼可用於行使工作身分的權限。如此一來,工作身分 (信任特定身分,並轉為信任具備此身分與其所含權限的使用者) 就可以轉換為程式碼身分 (信任特定的一段程式碼,此程式碼已經過審查,確定具有特定語意,且在未經核准的情況下不能修改)。

簡化法規遵循程序

BAB 簡化了原先必須手動執行的法規遵循工作。Google 的某些流程要求對資料處理方式採取更嚴格的控管措施。例如,我們的財務報告系統必須遵守《沙賓法案》(SOX)。在實行 BAB 之前,我們已有一套協助手動執行法規遵循驗證的系統。在實施 BAB 後,其中有許多項檢查都可根據服務的 BAB 政策自動執行。這些檢查的執行作業自動化以後,法規遵循團隊便得以擴大服務範圍,並對這些服務採取適當的控管措施。

將服務加入 BAB

BAB 團隊必須確保加入流程既簡單又直接。一開始,Google 的服務負責人對於採用 BAB 有兩大顧慮:

  • 如果 BAB 不夠可靠,實行這套機制也許會在關鍵情況下妨礙變更。
  • 由於頻繁的程式碼簽入和疊代程序,BAB 可能會導致服務的開發速度變慢。

為了化解起初的這些顧慮,BAB 團隊開發出了稽核模式。透過這個模式,BAB 團隊能夠向一些重要的早期採用者證明 BAB 的效用。為了進一步提高可靠性,BAB 團隊訂定了可用性服務等級目標,並在強制執行模式中加入緊急應變程序。

現有服務加入 BAB 時,服務負責人通常會先啟用「僅限稽核」模式。這有助於他們在啟用強制執行模式之前,先識別並解決任何問題。只要是在實際工作環境中使用 BAB 的工作,預設政策皆為強制執行模式。如要部署工作,服務負責人必須提交政策,且該政策至少應規定程式碼必須以可驗證的方式提交及建構。服務負責人可以在不符合此最低要求的情況下部署工作,但必須先取得例外權限。如果服務需要存取機密性更高的資料和/或服務,服務負責人可能必須實施更嚴格的要求。定義初始政策並不容易,因此 BAB 團隊建立了自動化工具,用來協助服務負責人編寫政策。這些工具會查看現有工作使用了原始碼存放區的哪些部分,據此提供適當的政策建議。

新服務加入 BAB 時,服務負責人應從頭開始啟用強制執行模式。服務負責人會擬定初始政策,然後迅速地重複此步驟,以新增其他要求。系統是將政策視為程式碼變更來管理,因此政策若有任何更新,都必須經由另一位 Google 工程師審查。

影響

採用 BAB 和容器化部署模型,可在安全性和可支援性方面為 Google 提供許多優勢:

  • BAB 有助於降低總體內部風險:BAB 可要求程式碼必須符合某些標準和變更管理做法,才能存取使用者資料,藉此防範 Google 員工或盜用 Google 員工帳戶的人士逕自透過程式存取使用者資料。
  • BAB 有助統一實際工作環境系統:透過容器化系統的使用,以及在部署之前驗證 BAB 要求,我們的系統變得更易於偵錯、更可靠,且變更管理流程也更加明確。BAB 要求為實際工作環境系統要求提供了一種共通語言。
  • BAB 規定了資料保護的共通語言:BAB 會追蹤我們各個系統間的一致性。我們會在內部公布此種一致性的相關資料,供其他團隊查詢。以這種方式發布 BAB 資料,能夠讓團隊在交流資料保護意見時,擁有共通的語言。有了這種共通語言,進行跨團隊的資料處理作業時,往返次數就能減少。
  • BAB 能夠以程式輔助方式追蹤法規遵循要求:為了遵循相關法規,某些流程 (例如財務報告流程) 必須符合特定的變更管理要求。有了 BAB 後,這些檢查就能自動執行,從而節省時間並擴大涵蓋範圍。

BAB 是 Google 為降低內部風險而使用的眾多技術之一。

在您的機構中採用類似的控管措施

我們在 Google 內部實行 BAB 的過程中得到了許多寶貴的經驗和教訓。進行如此大規模的變革是一項艱鉅的任務。我們將在本節中分享在此過程中得到的經驗和教訓,希望藉此幫助貴機構順利實施 BAB 的基本原則。

建立更同質化的容器化 CI/CD 管道。

由於我們在程式碼開發工作中使用的工具擁有很高的一致性和整合性,因此我們才能夠在 Google 內部採用 BAB。相關作業要素包括程式碼審查、可驗證的建構作業、容器化部署,以及用於存取權控管的服務身分。可驗證的建構作業可讓您檢查二進位檔的建構方式;容器可讓您將二進位檔與資料分開,並為您提供強制執行堵塞點,以確保這些二進位檔符合使用要求。這不但能簡化 BAB 的採用程序,還能強化 BAB 這類解決方案的可靠性。

我們為了能夠採用以服務為主的身分 (例如服務帳戶),而不是以主機為主的身分 (例如 IP 位址),而引進了微服務。改用以服務為主的身分,就能改以不同方式管理服務之間的身分驗證與授權作業。舉例來說,如果您使用嵌入容器映像檔的識別憑證來認證身分,程式碼溯源提供的保證就會減弱。如果您無法直接採用服務身分,則可嘗試使用防護力更強的識別憑證來做為臨時措施。

確定您的目標,並根據您的要求定義政策。

建構政策導向發布流程 (每次建構一部分)。在 CI/CD 管道中,您可能需要較早實行某些變更。例如,您可能需要開始進行正式的程式碼審查,然後才能在部署期間強制執行審查。

法規遵循是建構政策導向發布流程的主要動機。如果您可以將政策中的某些法規遵循要求編寫成程式碼,就能促進測試作業的自動化,並且確保這些測試持續發揮功效。您可以從基本要求著手編寫,然後再逐步編寫更進階的要求。

在開發初期強制執行政策。

如果事先不知道某一款軟體的預定執行位置,以及該軟體將會存取哪些資料,您將很難為該軟體定義完善的政策。這就是為什麼 BAB 政策會在部署程式碼及程式碼存取資料時 (而不是建構程式碼時) 強制執行的原因。BAB 政策是根據執行階段身分定義的,因此相同的程式碼可能會在不同的環境中執行,並受不同政策的約束。

除了其他存取機制以外,我們還使用 BAB 來限制對使用者資料的存取。 透過這種方式,服務負責人可以進一步確保只有符合特定 BAB 要求的工作才能存取資料,有效地將程式碼視為身分來處理。

確定引導現有服務負責人的方式。

選出在強制執行後可立即獲得成效、且願意提供意見回饋的服務負責人。您可以先邀請服務負責人自願參與,再進行任何強制性變更。

如果可以的話,以強制執行模式優先,其次才是稽核模式,或透過限制稽核模式的寬限期來實施強制執行模式。稽核模式可讓服務負責人快速加入,並且更清楚地瞭解內部風險。稽核模式的缺點是需要一段時間才能看到降低內部風險的實際成效。這種延遲會導致其價值難以彰顯,且讓您很難說服其他人採用強制執行措施。我們的 BAB 團隊在強制執行模式中加入緊急應變程序後,服務負責人變得比較願意採用強制執行模式,因為緊急應變程序能在他們需要時,提供備用的處理途徑。

成立跨團隊變更專案團隊。

我們宣布在 Google 內部全面實施 BAB 部署作業後,在各產品團隊中選出了推動變更的負責人,而他們正是影響實施成功率的最大因素。在取得他們的幫助後,我們成立了一個正式的變更管理團隊,專責追蹤進行中的變更。然後,我們再從各產品團隊選出負責人來實施變更。

瞭解如何管理第三方程式碼。

當您的程式碼是由同一個機構進行開發、審查及維護時,您可能會採取本文中介紹的許多 CI/CD 控管措施。如有這種情況,請考慮在政策要求中加入第三方程式碼。例如,您可以先不審查程式碼,同時在存放區中妥善保管所有使用過的第三方程式碼,然後再定期根據您的安全要求進行檢查。

結論

將部署期間強制執行檢查納入 Google 容器化基礎架構和 CI/CD 流程,讓我們能夠驗證部署的程式碼和設定是否符合特定的最低安全標準。這是非常重要的控管措施,可防範潛在的惡意內部人員執行可能存取使用者資料的未授權工作。採用 BAB 後,Google 成功降低了內部風險、順利阻擋各種可能的攻擊,並統一了實際工作環境系統。

相關參考資料

如要進一步瞭解 Google 的整體安全性和容器化基礎架構,請參閱以下資源:

附註

1 來源追蹤機制可清楚呈現各項元件、元件變更,以及變更來源。請參閱 https://csrc.nist.gov/glossary/term/Provenance

5 Borgmaster 是 Borg 的集中式控制器,用於管理工作的排程,並與正在執行的工作通訊以瞭解其狀態。