近日，Google發(fā)布了基礎設施安全設計概述的文章，解釋了如何在云中保護其自身的安全，以及公有云服務。

該安全設計思路包涵了六層安全，并透露了一些有趣的事情，比如曝光了“Google在設計定制芯片，包括目前部署在服務器上的硬件和周邊設備上的安全芯片，這些芯片可在硬件層面安全地識別和驗證合法的Google設備。

　　▲

同時，Google服務器使用各種技術來確保它們正在引導正確的軟件堆棧。在低級組件(如BIOS，引導加載程序，內(nèi)核和基本操作系統(tǒng)映像)上使用加密簽名。這些簽名可以在每次引導或更新期間驗證。這些組件全部由Google控制，構建和強化。隨著新一代硬件的發(fā)展，Google努力不斷地提高安全性：例如，根據(jù)服務器設計的需要，將引導鏈的信任歸功于鎖定固件芯片，運行Google編寫的安全代碼的微控制器，或者上面提到的Google設計的安全芯片。

此外還透露了，Google在第三方數(shù)據(jù)中心中托管服務器時，所采用的安全措施。確保在數(shù)據(jù)中心運營商提供的安全層之上有由Google控制的物理安全措施。例如，在這些地點，我們可以操作獨立的生物識別系統(tǒng)，照相機和金屬探測器。

文中還提及，Google的應用程序在將數(shù)據(jù)寫入磁盤之前如何加密數(shù)據(jù)，以使如惡意磁盤固件更難以訪問數(shù)據(jù)。

也就是說，基礎設施還實現(xiàn)了額外的保護層。在硬盤驅動器和SSD中啟用硬件加密支持，并仔細跟蹤每個驅動器的生命周期。在停用的加密存儲設備可以物理地離開之前，它使用包括兩個獨立驗證的多步驟過程來清潔。沒有通過該擦拭程序的設備在內(nèi)部用物理方法破壞(例如粉碎)。

此外，Google還具有用于掃描用戶安裝的應用程序、下載、瀏覽器插件和從Web瀏覽的內(nèi)容以便在公司客戶端上適用的系統(tǒng)。

如在公司LAN上不是我們授予訪問權限的主要機制。相反，我們使用應用程序級訪問管理控制，允許我們只在特定用戶來自正確管理的設備和預期的網(wǎng)絡和地理位置時公開內(nèi)部應用程序。

Google使用的自動和手動代碼審查技術來檢測開發(fā)人員編寫的軟件中的錯誤。手動審核“由包括網(wǎng)絡安全，密碼學和操作系統(tǒng)安全專家的團隊進行。同時，Google運行一個漏洞獎勵計劃，向任何能夠發(fā)現(xiàn)并通知Google基礎設施或應用程序中的錯誤的人員付給報酬，Google已經(jīng)在這個計劃中支付了幾百萬美元的獎金。

Google的源代碼存儲在中央存儲庫中，其中服務的當前版本和過去版本都是可審計的。此外，可以將基礎設施配置為要求從特定的審查，檢入和測試的源代碼構建服務的二進制文件。此類代碼審查需要至少一個除作者以外的工程師的檢查和批準，并且系統(tǒng)強制該代碼對任何系統(tǒng)的修改必須由該系統(tǒng)的所有者批準。這些要求限制內(nèi)部人或對手對源代碼進行惡意修改的能力，并且還提供從服務返回其源的取證跟蹤。

文中還指出，Google的公有云在KVM虛擬機管理程序的自定義版本中運行虛擬機，它稱“我們是最大的CVE和針對Linux KVM虛擬機管理程序的安全漏洞修復程序最大的提交者”。

上一頁12下一頁查看全文

內(nèi)容導航

第1頁：Google曝光其服務器都含自定義安全芯片

第2頁：Google基礎設施安全設計概述

《Google基礎設施安全設計概述》的譯文，已經(jīng)在由作者@網(wǎng)路冷眼在看雪論壇上全文發(fā)布，全文如下：

本文檔概述了Google的技術基礎設施安全性是如何設計的。這種全球性的基礎設施旨在通過Google的全信息處理生命周期提供安全性。此基礎架構提供服務的安全部署，使用終端用戶隱私保護的安全數(shù)據(jù)存儲，服務之間的安全通信，通過互聯(lián)網(wǎng)與客戶的安全和私人通信以及管理員的安全操作。

Google使用此基礎架構構建其互聯(lián)網(wǎng)服務，包括搜索，Gmail和照片等消費者服務以及G Suite和Google Cloud Platform等企業(yè)服務。

我們將從我們的數(shù)據(jù)中心的物理安全開始，繼續(xù)到如何保證基礎設施的硬件和軟件安全，最后描述技術限制和流程以支持運營安全。

▲Google基礎設施安全層：從底層的硬件基礎架構到頂層的操作安全性的各種安全層。每一層的內(nèi)容在本文中詳細描述。

安全低級基礎設施

在本節(jié)中，我們將介紹如何保護基礎架構的最低層，從物理場所到數(shù)據(jù)中心的特定硬件，以及在每臺機器上運行的低級軟件堆棧。

物理設施的安全

Google設計和構建自己的數(shù)據(jù)中心，其中包含多層物理安全保護。對這些數(shù)據(jù)中心的訪問僅限于Google員工中的很小一部分。我們使用多個物理安全層來保護我們的數(shù)據(jù)中心地板，并使用生物識別、金屬檢測、攝像機、車輛障礙和基于激光的入侵檢測系統(tǒng)等技術。 Google還在第三方數(shù)據(jù)中心內(nèi)部托管了一些服務器，我們確保在數(shù)據(jù)中心運營商提供的安全層之上有由Google控制的物理安全措施。例如，在這些地點，我們可以操作獨立的生物識別系統(tǒng)、照相機和金屬探測器。

硬件設計與原型

Google數(shù)據(jù)中心由連接到局域網(wǎng)的數(shù)千臺服務器計算機組成。服務器母板和網(wǎng)絡設備均由Google自行設計。我們審查與我們合作的組件供應商，謹慎選擇組件，同時與供應商合作，審計和驗證組件提供的安全屬性。我們還設計定制芯片，包括目前部署在服務器和外設上的硬件安全芯片。這些芯片可讓我們在硬件層面安全地識別和驗證合法的Google設備。

安全引導堆棧和機器身份

Google服務器機器使用各種技術來確保它們正在引導正確的軟件堆棧。我們在低級組件(如BIOS，引導加載程序，內(nèi)核和基本操作系統(tǒng)映像)上使用加密簽名。這些簽名可以在每次引導或更新期間驗證。這些組件全部由Google控制、構建和強化。隨著每一代新硬件的發(fā)展，我們努力不斷地提高安全性：例如，根據(jù)服務器設計的生成，我們將引導鏈的信任歸功于可鎖定的固件芯片，運行Google編寫的安全代碼的微控制器，或者上面提到的Google設計的安全芯片。

數(shù)據(jù)中心中的每個服務器機器都有自己的特定標識，可以綁定到硬件根信任和計算機引導的軟件。此身份用于驗證機器上的低級管理服務的API調用。

Google已經(jīng)創(chuàng)建了自動化系統(tǒng)，以確保服務器運行其軟件堆棧(包括安全補丁)的最新版本，檢測和診斷硬件和軟件問題，并在必要時從服務中刪除計算機。

安全服務部署

我們將繼續(xù)描述我們?nèi)绾螐幕镜挠布蛙浖酱_保一個服務安全地部署在我們的基礎設施上。“服務”是指開發(fā)人員寫入并希望在我們的基礎設施上運行的應用程序二進制文件，例如Gmail SMTP服務器，BigTable存儲服務器，YouTube視頻轉碼器或運行客戶應用程序的App Engine沙盒?？赡苡袛?shù)千臺機器運行相同服務的副本以處理所需的工作負載規(guī)模。在基礎設施上運行的服務由名為Borg的集群編排服務控制。

正如我們將在本節(jié)中看到的，基礎設施不承擔在基礎設施上運行的服務之間的任何信任。換句話說，基礎設施從根本上設計為多租戶模式。

服務標識，完整性和隔離

我們在應用層使用加密認證和授權進行服務間通信。這在管理員和服務可以自然地理解的抽象級別和粒度上提供了強大的訪問控制。

我們不依賴內(nèi)部網(wǎng)絡分段或防火墻作為我們的主要安全機制。雖然我們在我們的網(wǎng)絡中的各個點使用入口和出口過濾，以防止IP欺騙作為另一個安全層。這種方法還有助于我們最大限度地提高網(wǎng)絡的性能和可用性。

在基礎架設施上運行的每個服務都具有關聯(lián)的服務帳戶身份。向服務提供加密憑證，在向其他服務發(fā)出或接收遠程過程調用(RPC)時，可以使用該憑證來證明其身份。這些標識由客戶端使用，以確保它們正在與正確的預期服務器通信，并由服務器限制對特定客戶端訪問方法和數(shù)據(jù)。

Google的源代碼存儲在中央存儲庫中，其中服務的當前版本和過去版本都是可審計的。此外，可以將基礎設施配置為要求從特定的審查，檢入和測試的源代碼構建服務的二進制文件。此類代碼審查需要至少一個除作者以外的工程師的檢查和批準，并且系統(tǒng)強制該代碼對任何系統(tǒng)的修改必須由該系統(tǒng)的所有者批準。這些要求限制內(nèi)部人或對手對源代碼進行惡意修改的能力，并且還提供從服務返回其源的取證跟蹤。

我們有各種隔離和沙盒技術，用于保護服務不受在同一臺機器上運行的其他服務的影響。這些技術包括正常的Linux用戶分離，基于語言和基于內(nèi)核的沙箱以及硬件虛擬化。一般來說，我們對更危險的工作負載使用更多的隔離層;例如，當對用戶提供的數(shù)據(jù)運行復雜文件格式轉換器時，或者為Google AppEngine或Google Compute Engine等產(chǎn)品運行用戶提供的代碼時。作為一個額外的安全邊界，我們使非常敏感的服務，如集群協(xié)調服務和一些關鍵的管理服務，可以專門在專用計算機上運行。

服務間訪問管理

服務的所有者可以使用由基礎設施提供的訪問管理特征來精確地指定哪些其他服務可以與其通信。例如，服務可能希望僅將一些API提供給其他服務的特定白名單?？梢允褂迷试S的服務帳戶標識的白名單配置該服務，然后該基礎設施自動實施此訪問限制。

訪問服務的Google工程師也會被授予單獨的身份，因此可以類似地配置服務以允許或拒絕其訪問。所有這些類型的身份(機器、服務和員工)都位于基礎設施維護的全局名稱空間中。如將在本文檔稍后解釋的，最終用戶身份被單獨處理。

基礎設施為這些內(nèi)部身份(包括審批鏈，日志記錄和通知)提供了豐富的身份管理工作流系統(tǒng)。例如，可以通過允許兩方控制的系統(tǒng)將這些身份分配給訪問控制組，其中一個工程師可以向另一個工程師(也是該組的管理員)批準的組建議進行改變。該系統(tǒng)允許安全的訪問管理過程擴展到在基礎設施上運行的數(shù)千個服務當中。

除了自動API級訪問控制機制，基礎she設施還為服務提供從中央ACL和組數(shù)據(jù)庫讀取的能力，以便他們可以在必要時實現(xiàn)自己的定制的細粒度訪問控制。

服務間通信的加密

除了前面部分討論的RPC認證和授權功能之外，基礎設施還為網(wǎng)絡上的RPC數(shù)據(jù)提供加密隱私和完整性。為了向其他應用層協(xié)議(如HTTP)提供這些安全優(yōu)勢，我們將它們封裝在我們的基礎設施RPC機制中。實質上，這提供了應用層隔離并且消除了對網(wǎng)絡路徑的安全性的任何依賴。即使網(wǎng)絡被竊聽或網(wǎng)絡設備被攻破，加密的服務間通信可以保持安全。

服務可以為每個基礎設施RPC配置他們想要的加密保護級別(例如，僅為數(shù)據(jù)中心內(nèi)的低價值數(shù)據(jù)配置完整性級別保護)。為了防止可能試圖竊取我們的專用WAN鏈路的復雜對手，基礎設施自動加密在數(shù)據(jù)中心之間通過WAN的所有基礎設施RPC流量，而不需要服務的任何顯式配置。我們已經(jīng)開始部署硬件加密加速器，這將允許我們將此默認加密擴展到我們數(shù)據(jù)中心內(nèi)的所有基礎架構RPC流量當中。

最終用戶數(shù)據(jù)的訪問管理

典型的Google服務是為最終用戶完成某項任務。例如，最終用戶可以在Gmail上存儲他們的電子郵件。最終用戶與諸如Gmail之類的應用程序的交互跨越基礎設施內(nèi)的其他服務。因此，例如，Gmail服務可以調用由聯(lián)系人服務提供的API來訪問最終用戶的地址簿。

我們已經(jīng)在前面部分中看到，可以配置聯(lián)系人服務，使得只允許來自Gmail服務(或來自聯(lián)系人服務想要允許的任何其他特定服務)的RPC請求。

然而，這仍然是一個非常廣泛的權限集。在此權限的范圍內(nèi)，Gmail服務可以隨時請求任何用戶的聯(lián)系人。

由于Gmail服務代表特定最終用戶向聯(lián)系人服務發(fā)出RPC請求，因此基礎設施提供了一項功能，可讓Gmail服務將“最終用戶權限故障單”作為RPC的一部分。此單據(jù)證明Gmail服務目前正代表該特定最終用戶為請求提供服務。這使聯(lián)系人服務能夠實現(xiàn)保護措施，其中它僅返回故障單中指定的最終用戶的數(shù)據(jù)。

基礎設施提供發(fā)出這些“最終用戶權限票據(jù)”的中央用戶身份服務。最終用戶登錄由中央身份服務驗證，然后中央身份服務向用戶的客戶端設備發(fā)出用戶憑證，例如cookie或OAuth令牌。從客戶端設備到Google的每個后續(xù)請求都需要提供該用戶憑證。

當服務接收到最終用戶憑證時，它將憑證傳遞給中央身份服務以進行驗證。如果最終用戶憑證正確驗證，中央身份服務返回可用于與請求相關的RPC的短期“最終用戶權限故障單”。在我們的示例中，獲取“最終用戶權限標簽”的服務將是Gmail服務，這會將其傳遞給聯(lián)系人服務。從那時起，對于任何級聯(lián)呼叫，“最終用戶權限票據(jù)”可以由呼叫服務作為RPC呼叫的一部分傳遞給被呼叫者。

▲服務標識和訪問管理：基礎結構提供服務標識，自動相互認證，加密的服務間通信和由服務所有者定義的訪問策略的實施。

安全數(shù)據(jù)存儲

到目前為止，在討論中，我們已經(jīng)描述了如何安全地部署服務。我們現(xiàn)在來討論如何在基礎設施上實施安全數(shù)據(jù)存儲。

Encryption at Rest

Google的基礎架構提供各種存儲服務，如BigTable和Spanner，以及中央密鑰管理服務。 Google的大多數(shù)應用程序通過這些存儲服務間接訪問物理存儲。存儲服務可以配置為使用來自中央密鑰管理服務的密鑰在將數(shù)據(jù)寫入物理存儲之前對數(shù)據(jù)進行加密。此密鑰管理服務支持自動密鑰輪換，提供廣泛的審核日志，并與前面提到的最終用戶權限標簽集成，以將密鑰鏈接到特定的最終用戶。

在應用程序層執(zhí)行加密允許基礎設施將自身與較低級別的存儲(例如惡意磁盤固件)的潛在威脅隔離。也就是說，基礎設施還實現(xiàn)了額外的保護層。我們在硬盤驅動器和SSD中啟用硬件加密支持，并仔細跟蹤每個驅動器的生命周期。在停用的加密存儲設備可以物理地離開我們的保管之前，它使用包括兩個獨立驗證的多步驟過程來清潔。沒有通過該擦拭程序的設備在內(nèi)部用物理方法破壞(例如粉碎)。

刪除數(shù)據(jù)

在Google上刪除數(shù)據(jù)通常首先將特定數(shù)據(jù)標記為“計劃刪除”，而不是完全刪除數(shù)據(jù)。這允許我們從無意的刪除中恢復數(shù)據(jù)，無論是客戶還是由于內(nèi)部的錯誤或進程錯誤造成的。在被標記為“計劃刪除”之后，根據(jù)服務特定策略來刪除數(shù)據(jù)。

當最終用戶刪除其整個帳戶時，基礎設施通知處理最終用戶數(shù)據(jù)的服務已刪除該帳戶。然后，服務可以調度與已刪除的最終用戶帳戶相關聯(lián)的數(shù)據(jù)以進行刪除。此功能使服務的開發(fā)人員能夠輕松實現(xiàn)最終用戶控制。

安全的互聯(lián)網(wǎng)通信

在本文檔中的這一點之前，我們已經(jīng)描述了如何保護我們的基礎設施上的服務。在本節(jié)中，我們將討論如何確保互聯(lián)網(wǎng)和這些服務之間的通信安全。

如前所述，基礎設施包括通過LAN和WAN互連的大量物理機器，并且服務間通信的安全性不依賴于網(wǎng)絡的安全性。然而，我們確實將我們的基礎設施與互聯(lián)網(wǎng)隔離為私有IP空間，以便我們可以更容易地實現(xiàn)額外的保護，例如防御拒絕服務(DoS)攻擊，只需將機器的一部分直接暴露給外部互聯(lián)網(wǎng)流量。

Google前端服務

當服務想要在因特網(wǎng)上可用時，它可以向稱為Google前端(GFE)的基礎設施服務注冊自己。 GFE確保所有TLS連接都使用正確的證書和遵循最佳實踐(如支持完全轉發(fā)保密)。 GFE還應用于拒絕服務攻擊的保護(我們將在后面更詳細地討論)。然后，GFE使用先前討論的RPC安全協(xié)議轉發(fā)對服務的請求。

實際上，任何選擇向外部發(fā)布的內(nèi)部服務都使用GFE作為智能反向代理前端。此前端提供其公共DNS名稱，拒絕服務(DoS)保護和TLS終止的公共IP托管。請注意，GFE像任何其他服務一樣在基礎設施上運行，因此具有擴展以匹配傳入請求卷的能力。

拒絕服務(DoS)保護

我們的基礎設施規(guī)模龐大，使Google能夠簡單地消化掉許多DoS攻擊。也就是說，我們有多層、多級DoS保護，進一步降低任何DoS對運行在GFE后面的服務的影響的風險。

在我們的骨干網(wǎng)向我們的一個數(shù)據(jù)中心提供外部連接之后，它通過幾層硬件和軟件進行負載平衡。這些負載平衡器將關于入站流量的信息報告給在基礎設施上運行的中央DoS服務。當中央DoS服務檢測到發(fā)生DoS攻擊時，它可以配置負載均衡器以丟棄或限制與該攻擊相關聯(lián)的流量。

在下一層，GFE實例還將關于他們正在接收的請求的信息報告給中央DoS服務，包括負載平衡器沒有的應用層信息。然后，中央DoS服務還可以配置GFE實例以丟棄或限制攻擊流量。

用戶驗證

在DoS保護后，下一層防御來自我們的中央身份服務。此服務通常向最終用戶顯示為Google登錄頁面。除了要求簡單的用戶名和密碼，該服務還智能地挑戰(zhàn)用戶基于風險因素的其他信息，例如他們是否從同一設備或過去的類似位置登錄。在對用戶進行身份驗證后，身份服務會發(fā)出憑證，例如可用于后續(xù)呼叫的Cookie和OAuth令牌。

用戶還可以選擇在登錄時使用第二個因素，例如OTP或防網(wǎng)絡釣魚安全密鑰。為了確保這些好處超越Google，我們在FIDO聯(lián)盟與多個設備供應商合作開發(fā)通用第二因子(U2F )開放標準。這些設備現(xiàn)已在市場上出售，其他主要的網(wǎng)絡服務也跟隨我們實施U2F支持。

操作安全

到目前為止，我們已經(jīng)描述了如何在我們的基礎設施中設計安全性，并且還描述了一些用于安全操作的機制，例如RPC上的訪問控制。

我們現(xiàn)在轉向描述我們?nèi)绾伟踩夭僮骰A設施：我們安全地創(chuàng)建基礎設施軟件，我們保護我們員工的機器和憑據(jù)，我們防御內(nèi)部人員和外部角色對基礎設施的威脅。

安全軟件開發(fā)

除了前面介紹的中心源代碼控制和雙方審查功能之外，我們還提供了防止開發(fā)人員引入某些類型的安全漏洞的庫。例如，我們有消除Web應用程序中的XSS漏洞的庫和框架。我們還有自動化工具，用于自動檢測安全漏洞，包括模糊器、靜態(tài)分析工具和Web安全掃描程序。

作為最后檢查，我們使用手動安全審查，從快速分類到更低風險的功能，深入設計和實施審查最危險的功能。這些審核由包括網(wǎng)絡安全、密碼學和操作系統(tǒng)安全專家的團隊進行。審查還可以產(chǎn)生新的安全庫功能和新的模糊器，然后可以應用于其他未來的產(chǎn)品。

此外，我們運行一個漏洞獎勵計劃，我們向任何能夠發(fā)現(xiàn)并通知我們基礎設施或應用程序中的錯誤的人員付給報酬。我們已經(jīng)在這個計劃中支付了幾百萬美元的獎金。

在我們使用的所有開源軟件中查找0天漏洞利用和其他安全問題上，Google還投入大量精力，并上傳這些問題。例如，在Google上發(fā)現(xiàn)了OpenSSL Heartbleed錯誤，我們是CVE以及Linux KVM虛擬機管理程序的安全錯誤修復程序最大的提交者。

保持員工設備和證書安全

我們進行了大量投資，以保護我們員工的設備和憑證免受妥協(xié)，并監(jiān)控活動以發(fā)現(xiàn)潛在的妥協(xié)或非法內(nèi)部活動。這是我們投資的關鍵部分，以確保我們的基礎設施安全運行。

復雜的網(wǎng)絡釣魚目標一直瞄準我們員工。為了防范這種威脅，我們已經(jīng)替換了可疑的OTP第二個因素，強制使用我們員工帳戶中與U2F兼容的安全密鑰。

我們對我們的員工用于操作我們的基礎設施的監(jiān)控客戶端設備進行了大量投資。我們確保這些客戶端設備的操作系統(tǒng)映像是最新的安全補丁，我們控制可以安裝的應用程序。此外，我們還具有用于掃描用戶安裝的應用程序、下載、瀏覽器插件和從Web瀏覽的內(nèi)容以便在公司客戶端上適用的系統(tǒng)。

在公司LAN上不是我們授予訪問權限的主要機制。相反，我們使用應用程序級訪問管理控制，允許我們只在特定用戶來自正確管理的設備和預期的網(wǎng)絡和地理位置時公開內(nèi)部應用程序。(更多細節(jié)參見我們關于'BeyondCorp'的附加閱讀。)

降低內(nèi)部風險

我們積極主動地限制和監(jiān)控已授予對基礎設施管理訪問權限的員工的活動，并通過提供可以以安全和受控的方式完成相同任務的自動化，持續(xù)努力消除對特定任務的特權訪問的需要。這包括需要對某些操作進行雙方批準，并引入有限的API，允許在不暴露敏感信息的情況下進行調試。

Google員工對最終用戶信息的訪問權限可以通過低級基礎設施的掛鉤記錄。 Google的安全小組會主動監(jiān)控訪問模式并調查異常事件。

入侵檢測

Google擁有先進的數(shù)據(jù)處理管道，將基于主機的信號集成到單個設備上，基于網(wǎng)絡的信號來自基礎設施中的各個監(jiān)控點，以及來自基礎設施服務的信號?；谶@些管道建立的規(guī)則和機器智能為運維安全工程師警告可能的事件。我們的調查和事故響應小組每年365天全天24小時對這些潛在事件進行分類、調查和應對。我們進行紅隊(Red Team)練習來衡量和提高我們的檢測和反應機制的有效性。

保護Google云端平臺(GCP)

在本節(jié)中，我們強調我們的公共云基礎設施，GCP，如何從底層基礎設施的安全中受益。在本節(jié)中，我們將使用Google Compute Engine(GCE)作為示例服務，并詳細描述我們在基礎設施上構建的特定于服務的安全改進。

GCE使客戶能夠在Google的基礎設施上運行自己的虛擬機。GCE實現(xiàn)包括幾個邏輯組件，最顯著的是管理控制平面和虛擬機本身。

管理控制平面公開外部API表面并協(xié)調虛擬機創(chuàng)建和遷移等任務。它作為基礎設施上的各種服務運行，因此它自動獲得基本完整性功能，如安全引導鏈。各個服務在不同的內(nèi)部服務帳戶下運行，以便每個服務都可以被授予只有在對控制平面的其余部分進行遠程過程調用(RPC)時所需的權限。如前所述，所有這些服務的代碼存儲在中央Google源代碼存儲庫中，并且在此代碼和最終部署的二進制代碼之間存在審計跟蹤。

GCE控制平面通過GFE公開其API，因此利用了拒絕服務(DoS)保護和集中管理的SSL / TLS支持等基礎設施安全功能?？蛻艨梢酝ㄟ^選擇使用基于GFE構建的可選的Google Cloud Load Balancer服務來獲得對在其GCE VM上運行的應用程序的類似保護，并可以減輕許多類型的DoS攻擊。

對GCE控制平面API的最終用戶認證是通過Google的集中身份服務完成的，該服務提供安全功能，例如劫持檢測。授權使用中央云IAM服務完成。

從GFE到其后面的第一服務以及其他控制平面服務之間的控制平面的網(wǎng)絡流量由基礎設施自動認證并且每當它從一個數(shù)據(jù)中心傳播到另一數(shù)據(jù)中心時被加密。此外，基礎設施也被配置為加密數(shù)據(jù)中心內(nèi)的一些控制平面業(yè)務。

每個虛擬機(VM)都使用關聯(lián)的虛擬機管理器(VMM)服務實例運行?；A設施為這些服務提供兩種身份。一個身份由VMM服務實例用于其自己的調用，一個身份用于VMM代表客戶的VM進行的調用。這允許我們進一步對來自VMM的呼叫的信任進行分割。

GCE持久磁盤使用由中央基礎設施密鑰管理系統(tǒng)保護的密鑰在靜止時進行加密。這允許自動旋轉和對這些鍵的訪問的中央審計。

今天的客戶可以選擇是否將來自其VM的流量發(fā)送到其他VM或互聯(lián)網(wǎng)，或者實施他們?yōu)榇肆髁窟x擇的任何加密。我們已開始推出自動加密，用于將客戶虛擬機的廣域網(wǎng)遍歷跳轉到虛擬機流量。如前所述，基礎設施內(nèi)的所有控制平面WAN流量都已加密。將來，我們計劃利用之前討論的硬件加速網(wǎng)絡加密，以加密數(shù)據(jù)中心內(nèi)的虛擬機之間的LAN流量。

提供給VM的隔離基于使用開源KVM堆棧的硬件虛擬化。我們通過將一些控制和硬件仿真棧移動到內(nèi)核之外的非特權進程，進一步強化了我們的KVM的特定實現(xiàn)。我們還使用諸如模糊、靜態(tài)分析和手動代碼審查等技術廣泛測試了KVM的核心。如前所述，大多數(shù)最近公開披露的漏洞已被上傳到來自Google 的KVM。

最后，我們的運營安全控制是確保訪問數(shù)據(jù)遵循我們的政策的關鍵部分。作為GoogleCloud Platform的一部分，GCE對客戶數(shù)據(jù)的使用遵循GCP對客戶數(shù)據(jù)政策的使用，即除非有必要向客戶提供服務，否則Google不會訪問或使用客戶數(shù)據(jù)。

結論

我們已經(jīng)描述了Google基礎設施是如何設計的，以便在互聯(lián)網(wǎng)規(guī)模上安全地構建、部署和運營服務。這包括Gmail等消費者服務和我們的企業(yè)服務。此外，我們的Google云端產(chǎn)品是建立在這個相同的基礎設施之上。

我們在確保我們的基礎設施服務方面投入了大量資金。我們有數(shù)百名專門用于安全和隱私的工程師，分布在所有Google產(chǎn)品中，包括許多獲得認可的行業(yè)權威機構。

正如我們所看到的，基礎設施的安全性是從物理組件和數(shù)據(jù)中心到硬件來源，然后到安全引導、安全服務間通信、安全數(shù)據(jù)靜止，受保護的服務訪問互聯(lián)網(wǎng)以及我們?yōu)檫\營安全而部署的技術和人員流程。