Google Infrastructure Security 設計總覽白皮書 (三)

原文內容於 2017 年初撰寫，僅代表當時寫的現狀。隨著 Google 不斷改進對客戶的保護，Google 的安全政策和系統可能會改變。

安全的數據儲存

到目前為止，我們已經描述如何安全部署服務。現在我們轉向討論如何在基礎設施上實行安全的數據存儲。

實體存儲加密

Google 的基礎架構提供了各式各樣的儲存服務，如 Bigtable, Spanner, 和一個中央金鑰管理服務。大多數Google 的應用程式透過這些儲存服務間接訪問實體存儲。儲存服務可以使用中央金鑰管理服務中的密鑰，在數據寫入實體存儲之前對數據進行加密。該密鑰管理服務支持自動密鑰輪換，提供大量的審計日誌，並融合前面文章提到的終端用戶權限票據，將金鑰鏈接到特定的終端用戶。

在應用程式層執行加密可以使基礎架構能夠將自身與較底層的儲存（如惡意磁碟韌體）中的潛在威脅隔離。不過除此之外，基礎設施還增添了額外的保護層。我們在我們的硬碟和 SSD 中啟用硬體加密，並精心追蹤每個硬碟的生命週期。在退役的加密存儲設備可以離開 Google 的託管之前，Google 使用至少涵蓋兩個獨立驗證的多重驗證過程對其進行清理。沒通過清理流程的設備會直接在本地摧毀（例如碎化）。

刪除數據

在 Google, 刪除數據最常見的方式是先將數據標記為「計劃刪除」，而不是完全刪除數據。這使 Google 能夠恢復誤刪的數據，不論這類誤刪是客戶啟動還是由於內部的錯誤或處理錯誤。在被標記為「計劃刪除」 之後，會依據特定服務政策策略性的刪除數據。

當終端用戶刪除他全部的帳戶時，基礎設施會通知處理終端用戶數據的服該帳戶已被刪除。然後服務就可以安排刪除終端用戶要刪除的帳戶數據。這項功能使服務開發人員能夠輕鬆執行控制終端用戶。

安全網路通訊

到這裡我們描述了服務如何安全地於基礎設施上運行。本篇文章我們將敘述服務間會如何安全地通訊。

如同稍早討論的內容依樣，基礎設施是由許多透過LAN和WAN互連的實體機器構成，並且各個服務之間的安全性並不代表網路的安全性。然而我們將基礎設施從外網隔離，以內網 IP 空間的形式，讓我們可以更加簡便地執行額外的防護措施，例如我們可以藉由只將一部分的機器暴露於外網流量之下而降低 DoS 攻擊產生的風險。

Google 的前端服務

當有新的服務要接受來自外部網路的流量時, 這個服務會向我們的基礎設之中一個稱為 Google Front End (GFE) 的服務註冊。GFE 確保所有的 TLS 連線終止於使用正確的憑證上並且遵循最佳實踐，例如支持完美的前向安全性。GFE同時也會防護 DoS 攻擊 (我們會更詳細地在後面敘述)。GFE 會傳遞針對那些稍早討論過、使用 RPC 安全性協定服務的要求。

實際上任何想要選擇外部公開自己的內部服務都使用 GFE 作為一個聰明的前端反向代理。這個前端提供外部 IP 位址來代管公開 DNS name、DoS 防護以及 TLS 終止。值得注意的是，GFE 就如任何其他的服務一般可運行在基礎設施上，並且具有能夠擴充來因應進來的要求流量的能力。

DoS 防護

我們整個基礎設施的擴充可以讓 Google 簡單地吸收許多 DoS 攻擊。我們擁有多階 (multi-tier)、多層(multi-layer) DoS 防護，降低 DoS 在 GFE 後端運作的服務影響的風險。

我們的骨幹提供一個外部連線給我們其中一個資料中心後，會經過許多硬體與軟體負載平衡層上。這些負載平衡器會報告關於在基礎設施上、流至中心 DoS 服務流量的資訊。當中心 DoS 服務偵測到 DoS 攻擊產生時，在負載平衡器上可以設定要丟棄或者切斷關於攻擊的流量。

到下一層的時候，GFE 實例也會報告關於一些收到中心 DoS 服務的要求的資訊，包含一些負載平衡器沒有的應用層訊息。中心 DoS 服務同時可以設定 GFE 實例丟棄或者切斷攻擊流量。

使用者驗證

經過 DoS 防護後，下一層的防護是中心身分驗證服務。這項服務通常會向終端使用者顯示為 Google 登入頁面。除了要求常見的使用者名稱及密碼外，該項服務同時很巧妙地更新使用者額外的資訊。這些資訊是基於一些風險指標，例如在過去他們是否登入同樣的裝置，或者同樣相似的地點。經過審核使用者，身分驗證服務會提出憑證，例如 cookies 和 OAuth token 等，這些可以用來處理隨後的程式呼叫。

當登入的時候，使用者也擁有第二種要素可供選擇，例如 OTP 或者防止釣魚攻擊的安全金鑰。為了確保這些在 Google 的好處，我們和許多裝置供應商組成 FIDO 聯盟來共同運作，並共同研發通用第二因素 (Universal 2nd Factor, U2F) 開放標準。這些裝置現在於市面上販售並且其他主要大型網站服務都遵循表示支持 U2F 標準。

維運安全

到這裡我們敘述了在我們的基礎設施上如何設計了安全性的議題，並且闡述了一些安全性運作的機制，例如於 RPC 的存取控制。

現在我們開始說明我們如何實際上安全地操作這些基礎設施：我們安全地創建基礎設施軟體、我們保護員工的機器及憑證，而且我們防禦從內部及外部行為者所帶來的威脅。

安全的軟體研發

除了稍早提到的中心資源控管和雙方特性審核外，我們同時提供了函式庫，讓開發者防止導入特定的安全臭蟲類別。舉例來說，我們在網站應用程式上面擁有能夠的清除 XSS 安全漏洞函式庫。另外還有自動化工具可以自動地偵測安全臭蟲，包含模糊測試、統計分析工具及網站安全掃描器。

在最後確認階段中，我們使用手動安全性審核一定的範圍：從較少風險的特性快速分類到針對大部分具有風險的特性做審核執行。這些審核會由一群包含跨網站安全的專家、密碼學和系統安全運維所組成的團隊負責執行。這樣做的結果就是利用新的安全庫的特性以及新的模糊測試可接著應用到其他未來的產品。

此外我們也進行了一個「漏洞回報獎勵計畫」，我們會獎勵那些發現並回報關於在我們基礎設施或者應用程式上的一些臭蟲或漏洞。我們已經獎勵數百萬美元在這個計劃上。

Google 也投資了大筆的金額在我們使用的所有開放原始軟體中，找出零時差安全漏洞(0-day exploits)和其他安全性議題並且及時回朔到這些議題。舉例來說，OpenSSL 心臟出血漏洞 (Heartbleed bug)在 Google 這邊發現，並且 Google 也是在常見弱點及漏洞 (CVE) 和修復 Linux KVM Hypervisor 虛擬機安全漏洞最大的貢獻者。

維持員工裝置和憑證安全

我們強力投資於保護我們的員工裝置和憑證以避免危害，並且監視各種行為來探索潛在的危害或者非法的內部行為。這是我們投資中非常關鍵的部分，確保我們的基礎設施是安全運作的。

有經驗的釣魚攻擊會持續瞄準我們的員工。為了防護這樣的威脅，我們利用強制使用相容 U2F 的安全金鑰來代替可以成為釣魚攻擊的 OTP 給我們的員工。

我們投資了大筆金額在監控我們用來運作基礎設施的客戶端裝置。我們確保客戶端裝置上維運的系統映像檔版本都有最新的安全性更新，並且我們控制那些安裝起來的應用程式。不僅如此，我們擁有掃描使用者安裝應用程式、下載檔案程式、瀏覽器擴充程式以及那些從客戶端來受瀏覽的內容。

公司 LAN 網路並不是我們優先關注在存取服務上的機制。我們使用應用程式層級的管理來控制那些允許我們曝露內部應用程式給特定使用者，當這些使用者來自正確受控的裝置及可預期的網路和地理位址。(更多細節請見 ‘BeyondCorp’)

降低內部風險

我們會非常積極的限制和主動地監控授權為主要admin的員工的行為，並且持續地去除在一些特定的任務上具有特權的存取需求。我們會提供自動化的機制能夠安全地、受控地完成同樣的任務。這包含在進行特定操作的時候要求兩個獨立的單位都授權和導入部分 API，可以在不洩漏敏感資料的狀況下 debug。

Google 員工在存取到終端使用者資訊時這些存取記錄會透過底層基礎設施留存。Google 的安全團隊主動地監控存取樣式和調查不尋常的事件。

入侵檢測

Google 擁有富有經驗的資料處理管線，結合了各裝置上基於主機的訊號、從基於網路、在基礎設施上進行監控的訊號，還有從其他基礎服務來的訊號。一些規則和機器的靈巧機能建置在這些管線上，提供給負責安全維運的工程師可能產生意外的警示。我們負責調查和意外事件回報的團隊一天 24 小時，一年 365 天會進行分類、審查及對應這些潛在的意外事件。我們作為「紅隊試驗」來測量及更新我們的偵測及回報機制的效率。

相關文章：
Google 資訊安全白皮書：Google Infrastructure Security (一)
Google 資訊安全白皮書：Google Infrastructure Security (二)
Google 資訊安全白皮書：Google Infrastructure Security (四) 
(原文翻譯自：https://cloud.google.com/security/security-design/)