Google Infrastructure Security 設計總覽白皮書 (二)
這篇我們將繼續探討 Google 的軟硬體是如何安全的部署在基礎架構上。
Secure Service Deployment 安全服務部署
Google 的「服務」(Service) 是指開發人員編寫並希望在基礎架構上運行的應用程式。例如 Gmail SMTP 伺服器、Bigtable 儲存伺服器、YouTube 影片轉碼器或是跑在客戶應用程式上的 App Engine 沙盒。其中可能會有數千台機器因為要處理所需的工作負載規模而在同一台機器上跑相同的服務。在基礎架構上跑的服務都由叫做 Borg的叢集協調服務(跨主機集群的自動部署、擴展以及運行應用程式容器的平台)所掌控。
延續 Google 要傳達的概念，從這篇文章可以看出 Google 的基礎架構不期待服務之間的任何信任。換句話說，Google 的基礎建設本身就是設計給客戶多重租用。
Service Identity, Integrity, and Isolation 服務識別 / 完整性 / 隔離
Google 服務間的通訊是在應用層使用密碼認證和授權管理。這提供了抽象化而且強制性的存取控制, 並讓管理人員以及服務都能輕易理解存取控管的粒度
Google 不依賴內外部網路分段或防火牆作為主要的安全機制，雖然 Google 在網路上多種節點使用出入口過濾加強安全性以防止 IP 詐騙。這樣的方法卻大幅的增強 Google 的網路績效和可用性。
在基礎架構上跑的每個服務都具有相關的服務帳戶識別身份。每項服務具有的密碼憑證可以讓其他服務進行遠程程式呼叫 (RPCs) 時驗證雙方身份。客戶可以使用這些身份驗證來確保自己與正確的伺服器溝通，並通過伺服器來限制特定客戶端的訪問、存取權限。
Google 的源代碼存儲在一個中央儲存庫中，現在服務的版本和過往服務版本都是可以再更動的。基礎架構還可以配置為要求服務的執行檔是從經過特定審查及測試的程式碼所建置出來的。這樣的代碼審查需要有作者以外的至少一位工程師的檢查和批准。而且系統規定，要對任何系統的代碼修改都必須由該系統的擁有者批准。這些規定限制了內部人員或對手對源代碼進行惡意修改，並且還提供了源服務的歷史紀錄追踪。
Google 有多許多種獨立區隔和沙箱技術來保護服務免受在同一台機器上運行的其他服務的影響。這些技術包括正常的 Linux 用戶分離、基於語言和核心的沙箱以及硬體虛擬化。通常 Google 會對更高風險的負載工作使用更多層級來隔離。舉例來說，在用戶提供的數據上運行複雜的文件格式轉換器時，或運行在用戶提供產品的程式碼，如Google App Engine 或 Google Compute Engine 等產品時。作為一個額外的安全邊界，Google 提供非常細緻的服務（如集群協調服務和一些加密管理服務）能夠在針對的機器上運行。
Inter-Service Access Management 服務期間造訪管理
服務的所有者可以使用由基礎設施提供的造訪管理 (Access Management) 功能來精確指定哪些其他服務可以與之通信。例如，某個服務可能僅希望將某些 API 提供給其他服務的特定白名單。該服務可以配置允許的服務帳戶身份的白名單，然後該基礎設施自動執行該訪問限制。
訪問服務的 Google 工程師也會獲得個人身份，因此可以對服務進行類似的配置，以允許或拒絕其訪問。所有這些類型的身份（機器、服務和員工）都位在基礎架構所維持的全球名稱範圍。待會本篇文章也會據此解釋：終端用戶身份是分開處理的。
基礎架構為這些內部身份提供了豐富的身份管理工作流程系統，包括審核鍊、日誌記錄和通知。例如，這些身份可以透過系統分配進入控制組，控制組裡可以有兩位管控者，當其中一位管理員提出變動申請另一位管理員（同時也是該組管理者）比須批准。透過這個系統的安全訪問管理流程可以在基礎架構上讓服務運行擴展至數千個服務。
除了自動 API 級別的訪問控制機制外，基礎架構還提供從中央 ACL 和群組數據庫中讀取數據的服務，方便使用者在必要時可以實施自己的定訂的訪問控制。
Encryption of Inter-Service Communication 服務間的通訊加密
除了前面討論的 RPC 身份驗證和授權功能外，基礎架構還為網路上的 RPC 數據提供加密保護和完整性。為了向其他應用層協議（如HTTP）提供這些安全好處，Google將它們封裝在基礎結構 RPC 機制中。本質上，這提供了應用層隔離並消除了對網路路徑安全的任何依賴。即使網絡被竊聽或網絡設備受到威脅，加密服務間的通訊也可以正常運作保持安全。
服務可以為每個基礎架構 RPC 配置他們想要的加密保護的層級。（例如，單為數據中心內的低值數據配置完整性層級的保護）。為了防止世故對手可能試圖訪問我們的私有 WAN 連結，基礎架構會自動加密所有在數據中心間通過 WAN 的基礎架構 RPC 流量，而且不需要服務進行任何明確的配置。Google 已經開始部署硬體加密加速器，讓基礎架構的 RPC 流量默認加密可以擴展到 Google 所有的數據中心內。
Access Management of End User Data 終端用戶資料的訪問管理
典型的 Google 服務通常是為終端使用者的需求而開發出來。例如，使用者透過 Gmail 儲存 email。在同個基礎架構中，使用者與產品服務（如 Gmail）的互動會橫跨到其他的服務。像是 Gmaul 可以用連絡服務的 API 進入使用者的電話簿。
在前一個章節可知，聯絡服務可以進行服務配置，讓只有來自 Gmail 服務的 RPC 請求可以通過，或是其他聯絡服務所允許的特定服務。
但是，這仍然是一個非常廣泛的權限集合。在這個權限範圍內，Gmail 可以隨時拿取任何用戶的聯絡人。
由於 Gmail 代表特定的使用者向聯絡人服務發出 RPC 請求，基礎結構為 Gmail 提供了將「終端用戶許可證」(end user permission ticket) 作為 RPC 一部分提供的功能。這個許可證證明 Gmail 目前正在代表該特定使用者處理請求。這使得聯絡人服務可以實施一種安全措施：只將數據返回給指定的使用者。
基礎架構提供了一個「用戶識別中心」(central user identity service)，專門發布這些「終端用戶許可證」。而終端使用者的登入是由用戶識別中心判定。例如 cookie 或 OAuth 認證。每一個從客戶端到 Google 的請求都必須提供用戶憑證。
當服務收到最終用戶憑證時，它會將憑證傳給用戶識別中心進行驗證。如果終端用戶憑證驗證正確，則用戶識別中心將返回一個「短期的終端用戶許可證」。在本篇的例子中，Gmail 會獲得終端用戶許可證，進而再傳給聯絡人服務。基於這個論點，對於任何衍生性呼叫 (cascading calls)，作為 RPC 調用的一部分，呼叫服務可以借終端用戶許可證傳給呼叫者。
服務認證和訪問管理：基礎架構提供服務識別、相互自動驗證、服務間的加密通訊和服務擁有者自訂的訪問規定。
相關文章：
Google 資訊安全白皮書：Google Infrastructure Security (一)
Google 資訊安全白皮書：Google Infrastructure Security (三)
Google 資訊安全白皮書：Google Infrastructure Security (四)
(原文翻譯自：https://cloud.google.com/security/security-design/)
