Google基礎設施安全設計概述翻譯&導讀
小編導讀：安全團隊多數時候是獨立於業務團隊的存在，類似於主機agent、WAF、DDOS等安全產品，都是力求「獨立」成產品的。而Google和大多數公司不同，他們的安全能力是內嵌在基礎設施里，由基礎設施透明提供的。安全工程師參與設計、開發和實現，並檢驗基礎設施所提供的安全能力。業內曾說，安全的本質上是信任問題，你總得信任點什麼。而Google用自己的做法告訴大家，它可以不信任到什麼程度。
每個公司的基因都有所差異，不見得所有的做法我們都能學習，但是，知道世界上有這麼一家公司，是這麼實現的，一定對開拓視野和思路是有所幫助的。
筆者英文並不太優秀，但是這次也是一字一句的硬啃下來了，只因為相信，這是一篇值得精讀多遍的真正好文。
CIO級摘要
- Google擁有全球規模的技術基礎設施，用於提供信息處理全生命周期的安全能力。包括：安全的發布、用戶隱私保護、數據安全存儲、服務之間（內部）的安全交互、互聯網通信安全、運維安全
- Google自身的服務使用了這些基礎架構，即包括像Google搜索引擎、Gmail和照片等2C（面向普通用戶）的業務，也包括G Suite和Google Cloud等2B（面向企業）的業務
- 這套基礎設施提供從數據中心的物理安全開始，自底向上，逐層涵蓋到硬體、軟體、操作規範等方面
- Google投入大量的資源保護這些基礎設施（包括大量的資金和幾百名工程師，分布Google所有的產品和服務中），其中不少人是行業的權威專家
小編導讀：這一段其實主要是Google說自己如何厲害，如果你是第一遍看本文的話，可以跳過去，看完了再回過頭來看看總結比較合適。
概述
本文簡要介紹了Google基礎設施是如何設計安全特性的。該基礎設施的使命就是在Google整個信息處理生命周期中提供安全性，包括安全的發布服務、安全存儲用戶隱私數據、在Google多個服務之間安全的交互數據、保障用戶和服務之間的互聯網流量安全、安全的運維管理操作。
Google使用此基礎設施構建自己的服務，包括搜索、Gmail、照片等（面向普通用戶的）服務，也包括G Suite、Google Cloud Platform等（面向企業）的服務。
我們將從數據中心的物理安全開始，逐層介紹硬體和軟體等底層設計是如何保障安全的，最後一直到技術規範和運維流程，如何保障運維操作等方面的安全。
底層基礎設施安全
這一節，我們會詳細的從基礎設施的最底層開始介紹，從機房的物理安全，到安全定製加固過的硬體，再到底層的軟體引導棧。
機房物理安全
Google自己設計數據中心，在數據中心裡包含了多級的安全保護措施，並限制了只有非常少的Google員工才有許可權訪問。包括：生物識別、金屬探測、監控攝像頭、路障、激光檢測。當Google跟第三方數據中心合作時， Google要求合作方在原有數據中心安全措施的基礎上，必須額外增加完全由Google自主控制的生物識別、攝像頭監控和金屬探測等機制。
小編導讀：
多數公司還沒有自建數據中心的能力，即便能自己建設，也往往無法避免要跟第三方合作。此時，機房的安全管理水平可能參差不齊。如果機房管理員監守自盜（也可能是被釣魚攻擊、社工，甚至是商業間諜去應聘），走到機櫃面前，插上顯示器滑鼠鍵盤，或者U盤，甚至拔走一塊硬碟，想想就不寒而慄……Google顯然不能接受這種情況的發生，所以，他們通過各種安全措施確保可以接觸自己伺服器的人是可信的。
硬體安全
每個Google的數據中心都是由數千台接入到本地網路的伺服器組成的。所有的伺服器主板、網路設備都由Google自行設計。Google謹慎的選擇每一個組件的供應商，精心挑選組件，並且和供應商一起審計、確認該組件所提供的安全屬性是符合要求的。Google還自行設計晶元，包括一個硬體的安全晶元，該晶元被部署在伺服器以及外圍設備上，用於在硬體層面識別合法的Google自有設備。
小編導讀：坊間傳言，某大型企業被國家級對手盯上的時候，他們採購的設備在物流過程中被掉包了，於是進駐機房後，變成對手的跳板，進入內網。Google從硬體開始不信任，伺服器、路由器、交換機統統自己設計，有自己的加密晶元才是合法的設備。不合法的設備可能直接被踢出網路。而多數企業還苦苦掙扎在自有資產都盤點不清楚，網路准入僅僅在辦公環境的交換機上才會開啟的時候，Google所有設備都是白名單化的了。大名鼎鼎的Hacking Team被入侵好像就是從一個嵌入式設備開始的。Google顯然對此又有所防範了。
引導棧安全加固與機器身份識別
Google伺服器使用多種技術來確保運行的軟體引導棧是合法受信的。我們使用加密簽名的方式，對底層組件，諸如BIOS、bootloader、內核、操作系統鏡像進行簽名。這些簽名在每一次啟動、更新的時候會被校驗。而每一個上述組件都是完全由Google控制的（Google自行構建、加固），每一代硬體都會提升和加強安全能力。例如，在不同年代的伺服器設計中，Google通過一個可以被鎖定的固件晶元（firmware）、微處理器或者上述提到的安全晶元，來確保引導鏈的信任根是安全的。（均由Google自行編碼或者設計實現）
數據中心裡的每一台伺服器都有它獨特定製的身份標識（與硬體信任根綁定）。這個標識在底層的服務管理API調用中，會被用作源和目標的鑒權依據。
Google還實現了全自動化的系統，確保每一個伺服器上運行的軟體棧（包括安全補丁）都能升級到最新、檢測硬體和軟體的故障、或者在必要的情況下將其從踢出網路。
小編導讀：傳說中的Bootkit、Rootkit ，不知道是不是破壞了完整性之後就不能運行呢？其實，因為Google所有的發布基本上都是通過Borg平台（一個非常厲害的集群管理服務）。在集中管理的情況下，如果自動加上簽名和認證機制，那麼理論上伺服器是可以白名單運行所有的任務的。黑客getshell之後，下載和安裝一個木馬，不知道跑不跑的起來哦……
服務發布安全
這一節，我們從硬體和軟體的基本安全，過渡到描述「服務」是怎麼樣安全發布的。本文的 「服務」指的是由開發者編寫的，運行在我們的基礎設施上的應用程序，例如：Gmail 的SMTP服務程序、BigTable存儲服務程序、YouTube視頻轉碼程序、或者一個用來運行用戶程序的App Engine沙箱。它們可能會在數千台機器運行相同的的副本。這些服務都運行在一個叫做Borg的集群調度系統上（也是Google的基礎設施之一）。
如上所述，基礎設施並沒有賦予服務和服務之間任何的信任。換句話說，我們的基礎設施設計出來就是提供給多租戶模式使用的。
小編導讀：相比多數企業，內網很多API完全沒有鑒權機制（頂多IP白名單隔離），一旦黑客拿到shell，這一台機器淪陷了不說，跟它在一個內網裡的所有服務，面臨的威脅才更大。而Google說，抱歉，所有內網API我都會在基礎設施上幫你鑒權。
服務標識，完整性和隔離
Google內部的服務之間，仍然使用加密認證和授權機制來保障安全。在管理員和服務易於理解的前提下，提供了很強的訪問控制能力。
儘管Google也的確在網路入口和出口過濾了一些內容，避免IP欺騙之類的攻擊。但Google並沒有把網路的隔離作為主要的安全手段，這樣的思路讓我們可以最大化的保障網路的性能和可靠性。
小編導讀：在公司網路規模不大的時候，隔離的確是一個比較簡單易行的思路。但網路規模大起來，內網的隔離和網路性能、可用性的矛盾就會激增。Google通過前面描述的RPC鑒權機制，不再依賴網路隔離，是一個非常值得學習的做法。
每一個運行服務都擁有一個服務標識。向其它服務發起RPC調用或者接收RPC返回信息的時候，需要提供基於這個標識的加密憑據。這些標識對於client端來說，可以確保和自己通信的遠程服務端是可信的，對於server端而言，則可用來限制僅有受信的client才能發起請求，或者只能訪問特定的方法。
Google的源代碼都存儲在一個中心倉庫中，確保當前和歷史版本的源代碼均可被審計。基礎設施可以要求代碼必須經由特定的代碼審核、簽入、測試，才能被構建成二進位版本。代碼審核必須由至少1名作者之外的其他工程師執行，並且需要系統的負責人同意，才能提交修改動作到代碼里。這些要求，限制了內部員工或者外部黑客提交惡意代碼的能力，並且也為源代碼的追溯取證提供了必要信息。
小編導讀：聽聞Google的開發工程師入職之後，需要學習很久的編碼規範。如果考取了公司內的Readability認證，那麼發布的時候，可以挑選一位工程師，等他看完代碼提交「look good to me」，就可以申請上線了。如果不幸還沒考取到Readability認證，那麼就需要別的小夥伴審核後，提交「Approve」才能繼續流程。Approve是需要為代碼開發者背書的，如果誰總寫出有漏洞的代碼，不知道是不是會比較難找到幫自己背書的小夥伴呢……
在同一台伺服器上運行多個服務的時候，我們用了很多隔離和沙箱技術，來保護它們之間互不干擾。這些技術包括普通的Linux用戶空間、語言和基於內核的沙箱以及硬體的虛擬化。一般而言，對於高風險的服務，我們會用更多層的隔離手段(比如轉化用戶提交的數據需要做複雜的格式轉換的時候，或者在GAE（Google App Engine）、GCE（Google Compute Engine）中運行用戶提交的代碼時)。對於特別敏感的服務，例如集群管理、密鑰管理服務，我們也會專機專用，作為額外的一層加固手段。
小編導讀：雖然Google對自己的虛擬化、沙箱的隔離比較有信心，但是在高危App和核心敏感服務上，也是會乖乖的專機專用哦。縱深防禦理念發揮到極致。
內部服務的訪問控制管理
服務的負責人可以使用基礎設施特別提供的訪問控制管理功能，精確的限制哪些服務可以和自己的服務進行通信。例如，讓特定的API只能被白名單範圍的服務訪問，只要配置白名單服務的標識，基礎設施就會自動實現這些功能。
Google的工程師訪問這些服務，也同樣需要獨立的身份標識，做類似的配置，基礎設施就可以自動實現對特定的人允許或者拒絕訪問的能力。所有這些身份標識（機器、服務、員工）都在一個全局的命名空間里，由基礎設施進行維護。本文的後續部分會進一步解釋，普通用戶的憑據會有單獨的處理方式。
小編導讀：機器、服務、員工，都有自己的ID。通過這些ID組成一個一個的user group，然後一個group可以對另一個group進行特定的訪問。這裡的許可權管理據說複雜到Google內部員工也會吐槽，但是它們帶來的好處是顯而易見的。
基礎設施提供了豐富的工作流管理系統來支持這些身份標識的管理工作，包括審批鏈、日誌、告警等功能。例如，通過本系統可以設置需要雙人批准（均為群組管理員）後，方能讓某些身份標識訪問特定的群組。本系統可以為基礎設施上數以千計規模的服務提供安全的訪問控制能力。
為了自動化實現API級別的訪問控制，基礎設施還允許從資料庫里讀取ACL列表、群組信息，以便系統負責人在必要的情況下，靈活運用訪問控制能力設計規則。
小編導讀：相比之下，多數企業的內網操作根本無法關聯到自然人，機器和服務頂多精確到IP，Google的這個設計簡直是太精妙了。每一個身份請求內部服務（數據）的時候，都可以被唯一的追溯。
內部服務之間的加密通信
基礎設施除了提供前面討論的認證、授權能力之外，也在網路上提供了隱私加密能力和RPC數據的完整性保護能力。為了提供這些能力給到一些類似於HTTP之類的應用，我們會把它們封裝在RPC內。從本質上來說，RPC這樣的機制給了應用層天然的隔離防禦能力，並拋棄了對網路信道的安全依賴。內部服務之間的通訊加密，可以在網路被中間人劫持，或者網路設備被攻陷的時候，仍然是安全的。
每一個RPC的加密級別是可配置的（例如，對低敏感、低價值的數據，可以選擇在機房內部通訊的時候，僅僅做完整性的檢查）。為了對抗高級別的攻擊方（比如有能力在公網上監聽Google流量和隱私的對手），基礎設施在所有跨機房的網路流量上，強制加密通訊。這個特性無需任何配置。Google也開始部署硬體加速器，打算讓數據中心內部的通信也默認加密。
小編導讀：跨機房自動加密，機房內打算全加密，還在實施中。想想我們有多少公司全站HTTPS都沒做到，更別說跨機房（內網專線）的加密了。且不說別的，MySQL、Redis、Memcache之類的內網通訊默認就是明文的啊。默默的想了一下成本，Google是不是在這方面出過什麼事才會這麼狠心呢……
用戶數據的訪問管理
典型的Google服務是為終端用戶提供某種功能的。例如，一個終端用戶可能在Gmail里保存郵件。終端用戶在使用Gmail的時候，會跟其它服務產生交互（比如聯繫人服務），以便訪問這個用戶的地址簿。
如前所述，我們已經知道Contacts（聯繫人）服務，會被配置成僅僅接受Gmail（或者其它指定服務）的RPC請求了。
但是，這仍然是一個非常寬鬆的許可權管理級別，在此狀態下，Gmail服務可以隨時請求任意用戶的全部聯繫人數據。
所以，當Gmail發起RPC請求到Contacts（聯繫人），要求查詢某個特定的終端用戶的數據時，基礎設施要求Gmail出示終端用戶許可權票據（end user permission ticket），作為RPC請求的一部分。該票據證明了Gmail正在為某個特定的終端用戶提供服務，也確保了Contacts（聯繫人）服務只會為合法票據所代表的用戶提供對應數據的安全能力。
基礎設施利用票據（end user permission tickets）提供特定用戶識別服務。一個終端用戶的登錄被專門的認證服務驗證通過後，會得到一個認證憑據（例如Cookie、OAuth token），保存在客戶端設備上。該設備發起的每一個子請求，都需要攜帶本憑據。
當一個服務收到用戶的認證憑據時，它會轉發給到專門的認證服務校驗。校驗通過會返回一個短時間內有效的「終端用戶許可權票據」，以便於RPC請求時攜帶。在上文提到的例子中，就是Gmail服務拿到了這個票據，可以發給Contacts服務。此刻起，該票據就可以被調用方攜帶在RPC請求里，並且被處理方使用了。
小編導讀：這個理念，相當於所有的數據請求都必須經過一個集中的地方，而每一次請求都要攜帶合法票據，在驗證票據的時候，可能就把大量潛在的越權漏洞給堵住了。而由於數據都只經過同一個地方，那麼發現異常的竊取數據、或者封堵打擊，也就變的容易。
數據存儲安全
通過上面的討論，我們已經描述了Google如何安全的發布服務。現在開始討論我們如何在基礎設施上實現數據存儲的安全。
靜態加密
Google的基礎設施提供了多種存儲服務，類似於BigTable和Spanner，以及特定的密鑰管理服務。多數Google的應用不直接訪問物理存儲，而是通過存儲服務替代。存儲服務在實際寫入物理硬碟之前，可以被配置為使用密鑰（從特定的密鑰管理服務中獲取）完成加密數據。密鑰管理服務支持自動輪換，提供精確的審計日誌，並且與前面提到的許可權票據關聯到特定的用戶。
實施應用層的加密可以讓基礎設施避免被潛在的底層存儲攻擊，比如說一個惡意的硬碟固件。也就是說，基礎設施也實現了額外的保護層。我們在物理硬碟、SSD的整個生命周期都啟用硬體加密。在一塊硬碟被廢棄或者更換前，它會被一個多步驟的流程進行清理（包括2條獨立驗證的方法並行）。沒有通過這個擦除程序的磁碟會直接物理銷毀（比如粉碎）。
小編導讀：不寫磁碟IO，調用遠程存儲服務介面。介面封裝成RPC，天然擁有了加密、鑒權的能力，而一旦檢測到數據寫入完成，短期內沒什麼訪問的動作，存儲服務就自動開始給加密。看描述Google擔心硬碟廠商寫入一個惡意的木馬到硬碟固件里，這下好了，都加密了，但更換硬碟的時候依然要安全擦鞋和物理損壞，Google到底都經歷過一些什麼？
數據刪除
在Google，數據的刪除通常是打上一個刪除標記，表示該數據「即將被刪除」，而不是真正的移除數據實體。這允許我們有機會從不小心的刪除誤操作中恢複數據，不管用戶發起的還是由於bug導致的。當數據被標記為「即將被刪除」後，這個數據會被按服務預先配置的策略進行處理。
當一個終端用戶刪除了他的帳號實體，基礎設施會通知服務處理該請求，找出該帳號關聯的相關數據進行移除。
小編導讀：忽然想起那個GitLab的誤操作案例……
Internet通信安全
介紹到這一節，我們已經描述了Google的服務在我們的基礎設施上是如何被加固的。這一節我們會轉過來描述，我們的服務在Internet上的通訊，是如何加固的。
正如此前所討論的，基礎設施連接了大量的物理設備，包括區域網和互聯網，並且服務之間的通訊並不依賴網路本身的安全。但是，Google仍然把基礎設施的IP地址配置內網，以便於跟互聯網隔開。這樣我們可以更容易的實現一些額外的防護，比如規避拒絕服務攻擊的威脅。因為我們可以只暴露很少的一部分機器到外部的互聯網上。
Google 前端服務
當一個服務希望把自己提供給Internet訪問時，它得去基礎設施的GFE（Google Front End）上進行註冊。GFE確保所有的終端與自己的連接都正確的使用了TLS連接，用了正確的證書，並且遵循正確的安全策略。GFE還提供了拒絕服務防禦能力（後文會討論）。GFE收到互聯網的請求後，通過前面介紹過的RPC安全協議轉發到內部。
事實上，所有的內部服務要將自己發布到外網，都會使用GFE做為智能反向代理。GFE提供了公網域名的公網IP，拒絕服務防禦能力，TLS連接。值得一提的是，GFE也是運行在基礎設施上的，像其它服務一樣，GFE可以處理海量規模的請求。
小編導讀：不去代理上註冊，都沒法對外開服務，天然又解決了高危埠對外暴露的問題。別指望掃描Google的SSH埠然後破解密碼了，有的Google工程師寫了幾年代碼壓根沒登錄過伺服器，當然，他們的SSH服務也是經過代理中轉的，而且是用證書認證的，證書時效性很短，頒發證書還需要雙因子認證。
拒絕服務防禦
從規模和體量上來說，Google比較容易化解拒絕服務攻擊。我們有多層級聯的拒絕服務防禦手段，以緩解或者阻止拒絕服務對GFE後方的服務的風險。
在骨幹網傳遞外部請求到數據中心時，它會經過多層硬體和軟體的負載均衡。這些負載均衡設備會上報入流量的信息給基礎設施上的DoS處理服務。當DoS處理服務檢測到攻擊時，它可以要求負載均衡設備丟棄或者限制與攻擊相關的請求。
在下一層，GFE實例也會上報請求的信息給到DoS處理服務，包括一些負載均衡無法識別的應用層的信息。GFE同樣可以接受DoS處理服務的指令丟棄與攻擊相關的請求。
小編導讀：一般的DDOS防禦方案，是旁路一份流量，檢測到有攻擊了就把流量牽引過來。可Google這個描述是不需要，反正交換機路由器、服務都是自己寫的，每一層都上報一些日誌，幫助判斷是否有攻擊。而每一個設備也都可以接收指令清洗、丟棄、限制特定的請求。所以Google說自己的拒絕服務防禦是多層次的，靠負載均衡就能扛很大的流量。人家代理也很多，打死1個代理節點，似乎對全局來說完全感知不到，攻擊者也會知難而退吧。
用戶認證
討論完了拒絕服務防禦，下一層防禦來自我們的中央認證服務。這個服務對於終端用戶而言，通常展現為登錄頁面。除了詢問簡單的用戶名和密碼，該服務也會智能的根據用戶的其它信息（比如是否從一個已知的安全設備、歷史相似登錄地點），判斷風險等級並對應的做出風險控制的挑戰確認。通過鑒定後，認證服務會派發一個認證憑據（比如cookies、OAuth Token）以便後續的請求攜帶。
用戶也可以在登錄時選擇類似於OTP或者防釣魚的安全證書服務做二次驗證。為了把這些安全能力提供給Google以外的公司，我們還跟FIDO（安全密碼聯盟）共同協定了U2F（通用二次認證）開放標準。現在這些設備也可以在市場上買到，並且主流的web站點也跟隨我們實現了對U2F的支持。
運維安全
說到這裡，我們已經描述了安全是如何被設計到基礎設施里的，並且也介紹了一些類似於RPC請求的訪問控制安全機制。
現在我們來介紹一下我們是如何安全的運營基礎設施的：怎麼安全的寫出基礎設施軟體，怎麼保護僱員的機器和認證憑據，以及如何從內部和外部對抗基礎設施的威脅。
安全開發
除了中央源碼控制和雙人review機制，我們還為一些典型的安全漏洞提供了庫和框架，開發者直接調用就可以自動規避這些典型漏洞。例如，我們提供了防止XSS漏洞的web庫文件和框架。我們也提供了一些自動化的安全漏洞檢測工具，包括fuzzer、靜態代碼掃描工具和Web漏洞掃描器。
針對不同的風險我們有不同的應對方式，作為終極大招，我們也使用人工審計來解決快速的風險分類，到深度的安全設計和實現上的安全問題。這些審查是由一個包含了Web安全、加密演算法、運維安全等各方面的專家團組成的。人工安全檢查出來的結果，往往被封裝成新的安全庫特性，或者設計新的fuzzer，以便在未來用於其它產品。
除此之外，我們還運營了一個漏洞獎勵計劃，為任何發現我們的基礎設施或者應用程序的漏洞報告者提供現金獎勵。我們已經在此計劃里支付了數百萬美金。
Google也投入大量的努力來尋找我們所使用的開源軟體的0day漏洞。例如，OpenSSL的心臟滴血漏洞是由Google發現並報告的，同時Google也是CVE漏洞最多的提交者，也是為Linux KVM 提交最多安全bug補丁的廠商。
小編導讀：簡單總結就是，咱用封裝好的庫，框架，寫了代碼就是健壯，還有各種自動化的fuzzer、代碼白盒審計、web黑盒審計工具，實在不行我還有人肉，人肉完了又自動化實現檢查。要這都給漏了我就現金收漏洞，已經花了好幾百萬美金了，想想Project Zero這種團隊，就感覺挖個Google的漏洞實在是不容易。而這個過程，似乎正是SDL的完美實踐啊。終於知道為什麼Google可以為一個XSS漏洞開出那麼高的價錢了。
保護僱員設備和認證憑據的安全
為了保護員工設備和憑據免受入侵、竊取和其它非法內部活動，Google在這方面投入了大量資金，這也是Google確保自身基礎設施安全運行的重要組成部分。
一直以來，針對Google員工的高端複雜釣魚攻擊總是持續不斷，為了對抗這種攻擊，Google強制員工帳號OTP口令認證方式更換成了支持 U2F 的安全密鑰（OTP畢竟還是存在被釣魚攻擊的風險的）。
Google投入大量的資金來監控用於操作基礎設施的客戶端設備。確保操作系統更新到了安全的補丁包，限制允許安裝的軟體。我們還掃描辦公設備中，員工安裝的app程序、下載的文件，瀏覽器的擴展和所瀏覽的web頁面內容。
Google並不使用信任區域網某個網段的方式來授予訪問許可權。取而代之的是，Google用應用級別的訪問管理控制手段，來把內部的應用開放給合適的用戶，並且僅允許他們從合法受控的設備，和安全可信的網路（和物理位置）。（更詳細的描述可以閱讀BeyondCorp相關的文章）
小編導讀：Google說自己的員工長期遭受到高級釣魚的威脅，肯定所言非虛，稍微上點年紀的安全從業人員應該還記得一個著名的IE漏洞。另外，聽說Google會監控開發機的鍵盤輸入，如果你不小心在facebook、linkedin上輸入了內部的工作密碼，馬上就會收到一封郵件要求改密碼。
內部風險控制
我們嚴格限制並嚴密監控那些被賦予了基礎設施管理員許可權的Google員工。持續的評估一些特殊任務所需要的最小許可權，鼓勵自動化的安全可控的方式來完成工作。這些手段包括雙人審批機制、在debug時使用受限的（脫敏的）API介面。
Google僱員訪問終端用戶的信息會被基礎設施底層的Hook記錄日誌，安全團隊據此監控異常數據，並對可疑的問題展開調查。
小編導讀：能自動化的就不給你開手工查詢的許可權。實在要debug，還得把數據脫敏。歷史上，某些廠商調試的時候把敏感信息寫在log里，被黑客下載走了，當時還覺得debug這種場景很難杜絕，然而Google說，我們可以脫敏的情況下debug啊。
入侵檢測
Google擁有成熟的數據處理管道，可以很好的集成每一台設備的主機、網路、服務的檢測日誌。內置在這些管道上的安全策略會及時的向運維安全人員發出告警。Google的應急響應團隊實施365天24小時的全天候待命。同時，Google內部也經常實施紅藍軍對抗，以不斷的衡量和提高檢測能力。
小編導讀：這個基本上等於沒說，但是由於Google有這麼豐富的底層API提供log，所以可以做的入侵策略應該非常厲害。真實的紅藍對抗看來的確是入侵檢測的標配。不知道是不是該同情一下在Google內部扮演藍軍的團隊，都這麼嚴密，怎麼玩呢？
Google雲平台安全
在這一節，我們重點介紹我們的公共雲基礎設施，GCP，是如何從底層基礎設施繼承安全能力的。以GCE（Google Compute Engine）為例，我們詳細介紹基礎設施為它賦予了哪些安全能力。
GCE允許用戶在Google的基礎設施上運行自己的虛擬機。它是由多個邏輯組件組成的，尤其是管理所用的控制面板和虛擬機本身。
其中，管理控制面板會暴露一些外部API介面並對虛擬機創建遷移等進行任務管理。由於它運行在一些基礎設施上，所以它自然繼承了基礎設施的底層安全能力：比如安全的引導棧。不同的服務會運行在不同的服務帳號下，所以每一個服務都只會被賦予它發起RPC請求時必須的最小化的許可權。正如此前介紹過的，這些服務都存儲在一個中央的Google源碼倉庫，它們是可審計的，並且二進位是被安全的發布的。
GCE控制面板是通過GFE對外提供API的，所以它又集成了GFE的DDOS防禦特性，以及天然繼承了SSL/TLS的加密特性。用戶可以選擇Google雲負載均衡服務的選項來緩解多種拒絕服務攻擊。
用戶在登錄GCE控制面板的時候，是通過Google的認證服務校驗的（提供類似於劫持檢測的安全能力），授權服務則由中央的IAM服務實施。
控制面板的流量，包括GFE轉發給其後的服務，和跨機房之間的所有流量，都由基礎設施自動實施認證和加密。除此之外，也可以配置控制面板的一些特定流量在機房內部也必須加密。
每一個虛擬主機實例，都會有一個與之關聯的虛擬主機的管理服務同時運行。基礎設施會給這2個服務獨立的ID。一個ID是給VMM服務實例自身調用，另一個用來代表VM的身份。這使得我們可以區分那些請求是從可信的VMM來的。
GCE的將數據持久化寫入的磁碟會自動調用一個基礎設施的中央密鑰管理系統，在空閑時自動加密。這些密鑰是自動輪換的，並且支持對密鑰訪問記錄進行審計。
如今，用戶可以選擇是否把流量從他們的虛擬主機發送到互聯網上其它的虛擬主機，或者通過加密的方式傳送這些流量。我們已經開始推出廣域網之間的VM流量自動加密的機制。如前所述，基礎設施在所有廣域網之間的流量傳輸都已經是加密過的了。未來，我們也計劃通過硬體加密加速器，把所有在區域網之間的流量也進行加密，這一點之前也提過了。
給VM提供隔離能力是在硬體層面的虛擬化技術實施的，主要使用了開源的KVM。我們未來會自己給KVM做一些定製化加固的實現，包括將一些控制代碼和硬體模擬代碼移動到內核之外的低許可權進程中。我們也已經使用包括fuzzing、靜態代碼掃描和人工代碼審計等方式仔細的對KVM的核心代碼進行了檢測。之前提到了，現在Google是KVM提交漏洞最多的廠商。
最後，我們的運維安全控制是確保上述數據遵從安全策略的重要組成部分。做為Google Cloud Platform的一部分，GCE使用的用戶數據同樣遵從相同的安全策略，Google不會訪問和使用用戶的數據，除非必須為用戶提供某種支持。
小編導讀：這個例子，把前面講過的內容都串起來了。Google想強調的是，只要跑在它的基礎設施上，就自動繼承了很多安全性。而KVM這種開源的東西，Google還投入大量的精力去挖掘漏洞並報告給廠商。所以，Google明顯是在暗示只有自己的雲服務才是安全的……
總結
我們已經介紹了Google基礎設施是怎麼樣被設計成安全的構建、發布和運維服務的。包括為用戶提供的服務（例如Gmail），也包括為企業提供的服務。除此之外，我們的Google雲也是在同樣的基礎設施之上完成的。
我們投入重金加固這些基礎設施。Google擁有數百名專註於安全和隱私的工程師，遍布在所有Google產品里，包括一些專業領域裡的權威都在其列。
正如我們看到的，基礎設施的安全性是從物理組件和數據中心開始，到硬體原型，到加固的安全啟動引導鏈，到內網服務交互加固，到靜態數據加密，內網服務之間的安全管理和終端用戶訪問時的安全管理，以及對於人和技術的流程管理。
小編導讀：Google反覆的強調，是想說黑客試圖攻擊的每一個角落，都有對應的安全加固和應對。並且這些應對的辦法是固化在基礎設施平台里，可以服務於全球規模級別的數據中心和每一個服務的。很多公司的管理會有長尾，那麼Google有沒有呢？可能也會有，但是據說YouTube收購後，花了幾年時間才融入，此前一直跟Google的服務完全隔離。
小編後記
Google關鍵思路總結：
- 開發安全：Code Review、雙人審批、Fuzzer/靜態代碼掃描/安全框架&庫/Web掃描器/人工代碼審計
- 人員安全：U2F取代OTP，監控辦公設備（打補丁、限制裝軟體、監控行為）
- 風控流程：Debug時脫敏、自動化代替人工、最小化許可權、底層Log的風控體系
- 入侵檢測：紅藍軍對抗、24*365響應
- 前端代理：GFE統一支持TLS，須註冊才能對Internet提供服務，可轉發內部RPC鑒權
- 拒絕服務：GFE、負載均衡等設備上報信息並接收丟棄、限制等清洗指令
- 靜態加密：存儲服務替代硬碟，底層全盤加密，更換硬碟時安全擦除（雙重保險），物理銷毀
- 安全刪除：標記後刪除（策略可配置）
- 認證：U2F（不僅自己用還推廣給行業里）
- 登錄保護：根據風控策略判斷是否需要應答挑戰
- 用戶數據：必須攜帶票據
- 內部服務交互：默認用RPC鑒權（ID的信任來自於硬體晶元），加密傳輸
- 安全引導鏈：硬體開始的不信任，信任根來自定製的硬體晶元，BIOS、Bootloader、Kernel、OS層層簽名
- 定製硬體：伺服器、交換機、路由器統統自己設計
- 物理安全：不到1%的Google員工必須通過多重檢查才能進入機房，合作機房也需要Google自行掌控
可能為了鼓勵更多人去用自家的雲服務，Google祭出了安全大旗，連續發了好幾篇paper。看完之後，第一時間感覺到它對於甲方安全團隊價值巨大，於是趕緊逐字翻譯並梳理了一些值得借鑒的地方。如果大家英文水平好的話，強烈推薦閱讀原文和參考鏈接。我們需要學習的地方還很多。理解的不對的地方也請大家指正。感謝被我騷擾的幾位Google同學。另外，我們團隊長期招人，歡迎大家推薦或者自薦。一起打造一流的安全能力。
聯繫方式: bizhengzhao@tencent.com
推薦閱讀：