從Google白皮書看企業安全最佳實踐

此前Google在安全領域披露的信息一直很少，適逢其大力發展云計算業務，需要展示云安全方面的實力，才有了這份白皮書。它從系統的角度描述了自己安全體系的設計與實現，對廣大互聯網、云計算公司的安全小伙伴而言可謂一大福利。本文中，筆者將從一個企業安全建設者的角度，說說自己的感想，并做一些解讀。

幾點感想

1. 國內很多公司的安全團隊都是游離在產品研發、基礎架構和SRE團隊之外的，HIDS、WAF、大數據的SOC，說到底這些東西安全團隊自己就可以搞定，基本不需要其他部門的支援和介入，這和乙方安全公司提供的一套外科手術般的解決方案的思路是一脈相承的。而Google的安全體系給人的感覺是跟基礎設施深度融合，完全內置于產品設計和研發過程之中，從頂層設計的視角看完全是兩種流派：內置的安全機制vs外掛的防護體系。

2. 沒有業界安全大會上那些花俏的概念和名詞，全都是正統的安全設計思路，以既有的簡單的安全手段解決復雜的問題，有如教科書般的紳士風格。

3. 工程化大于單點技術突破。盡管Google有Project Zero、有不少牛人，不過似乎沒有特別強調單點技術，更多體現的是在一個海量的規模下解決安全問題的工程化能力。

4. 在產品服務基礎架構層面可以看到Google有一個清晰的頂層架構設計，例如全局的IAM和Borg服務。盡管可能這個看似完整的體系也是一路迭代而來，但至少從現有的積累看，從全局的層次抽象，全局資源鑒權，收斂統一用戶和流量入口，收斂分散的認證&鑒權點，在每一個對應的抽象層次上做縱深防御，全局的訪問控制模型等等看上去更像是精心規劃和設計出來的。

5. 得益于Google自研的技術棧范圍實在太廣，因為一切皆自研，所以一切安全皆可DIY，對其他公司而言這反而是一個封閉的王國，因為不太可復制。

6. 能否追的上這個安全體系，已經不取決于單點技術亦或是攻防技術是否ready，甚至不取決于安全團隊的強弱，而是取決于公司所處的階段和整體技術實力。

整體安全體系圖解

Google原來的圖有點類似于ISO27001，框架性很好，但也終歸是一個對外的版本，信息披露上比較粗線條，對于更想在實踐層面模仿的同學來說比較抽象，所以筆者以自己的理解重新歸納了兩張圖。第一張圖展示了Google的整體IT環境，包括辦公網絡、生產網絡以及交互通道的整體安全視圖：

假如一開始不好理解也沒關系，先有個框架性認識。總體上可以抽象為辦公網絡和IDC都有縱深防御體系，研發環境屬于辦公網絡之上的一個特殊子集（這里并沒有披露內部IT的其它系統怎么建設的），辦公網絡和IDC生產環境之間有限的數據通道都做了風險控制，采用“2+2結構（2個縱深防體系+2個數據通道）”。

第二張圖再單獨分解一下IDC的縱深防御體系：

更具體的實現在后面的章節里展開，最后可以再回過頭來看這張圖。

接下來，我們按照白皮書原文的順序一一解讀。

CIO視角（宏觀）

關于CIO視角，我們要Get幾個點：

1. Google有一個全球范圍的基礎架構，除了表達IDC基礎設施的廣泛程度外，也暗含了擁有全球范圍的合規性。國內有少數比較大的互聯網公司正在國際化的進程中，海外的合規性可能會成為一大挑戰，國內公司中擁有成熟的全球合規性及全球化安全運營經驗的大約只有華為和聯想，其中華為又因為云計算和海外的手機云服務在這方面積累了其它國內公司暫時不可比擬的經驗。Google有很多細微之處都提到了隱私保護，國內的因為法制不太成熟，沒有太多的強制合規性以及公民隱私數據保護的壓力，所以接下去對很多業務開始向海外擴展的公司，這些都會成為安全部門日歷表上的待辦事項。題外話：筆者在《互聯網企業安全高級指南》一書中“隱私保護”一章寫的其實是數據保護，意義有所偏差，打算第二版重寫，有可能在美團點評技術博客先發表，敬請關注。

2. 安全設計覆蓋全生命周期，別提那些連SDL都沒有實施的公司了，G廠顯然是比SDL更高級的版本，強調“設計”二字。而國內擁有安全設計能力的從業者比較稀少，所以業界的話題和氛圍上這方面都相對欠缺。

3. 成本：500個專職工程師，其它方面也都是大手筆，但不確定在安全的投入上是不是“不計成本”的態度。

物理安全

Google自有IDC的物理安全手段：生物識別、金屬檢測、攝像頭、路障、激光入侵檢測，同時Google要求使用的第三方IDC的物理安全措施對其完全可控。

物理安全這件事哪怕在很多安全從業者心里也不過是ISO27001的一些章節和控制點，并非是很多人對于安全體系建設發自肺腑的真實需求，很多人對安全建設的認知往往是對抗線上入侵者。然而這也暗示了，不同的人、不同的廠商所建立的安全體系用來對抗的目標和范疇是完全不一樣的。類似Google、Amazon、Apple這類公司他們的安全體系用來對抗的幾大場景可以歸納為：黑客、第三方、雇員、IDC/云服務提供商、商業間諜、政府機構，對抗的強度依次上升。換言之，可以舉例翻譯為：即便我使用第三方的云服務，仍然可以保證自己的數據不被偷窺。對于成為國家基礎設施的服務而言，實際上另一種不能明說的需求就是介于民用領域和軍用領域之間的對抗需求。

大量公司的安全體系主要是用來御外而不是防內的，所以供應鏈安全、數據泄露這等事情都很頭疼。基于此推斷，即便修完了所有的漏洞，做了入侵檢測，也不足以對抗很多威脅，安全這件事做的好不好，更多的還是看你拿什么尺子來衡量。看完Google安全體系，筆者推測大多數人的反應是還是它做的已經遠超出一般意義上的防黑客。

硬件安全

對絕大多數公司而言都不會涉及這個章節，因為大多數公司也就頂多白牌服務器，而不是從主板到芯片全都自研。以前覺得華為、Apple這類公司用TC（可信計算）的概念還是用的比較多，但是感覺BAT都不玩這些，到后來分析iOS就一下明白了這個其實是由產品和服務所涉及的技術棧深度決定的，因為華為、Apple這類公司的產品線橫跨硬件、OS和上層應用，而BAT等公司造輪子（自研）的范疇大多止于軟件，所以很少涉及，甚至在這些公司早期的安全團隊里大多數是由Web安全技能的人組成的業務驅動使然。

從描述上看，Google硬件到底層軟件棧的安全設計跟iOS基本是一致的，都是基于可信的思路，上一層（軟件）驗證下一層（硬件/固件）的完整性，并區分唯一標識。用唯一標識+信任鏈來鑒別是否合法的硬件來源（而不是IDC提供商在機房里偷梁換柱換了臺服務器）。

更上層的部分，例如引導程序、內核、啟動鏡像的完整性都是啟動信任鏈的一般實現，有興趣的同學可以參考一下iOS的設計與實現。硬件唯一標識會成為后面提到的全局訪問控制體系的前提之一。

這里還有一條很重要的信息：Google在自己的生產網絡引入了NAC（網絡接入控制）機制，這個安全手段本來是為OA辦公網絡的終端管理場景設計的，目的是區分不信任的終端不能接入（相對可信）的公司網絡。這樣做可以想象幾個場景：假如機房管理員從回收垃圾那兒找到了廢棄的服務器，數據也沒被刪除，即便進入了機房重新插網線也接入不了網絡；甚至進一步推測，第三方供應商跑到IDC接上自己的MacBook想用Nmap掃描一把估計也不行。

服務部署

Google在IDC內部服務治理上最大的不同是：不信任IDC內網（注明：盡管思路上可能有相似之處，但與G廠自家在辦公網絡的安全解決方案BeyondCorp不是一件事）。很多公司的IDC生產服務網絡被設計為私有云模式（單租戶），在安全上相對的信任IDC內網通信，通過2層/3層隔離或者類似IP白名單的方式來建立IDC內網的弱訪問控制體系和信任模型。而Google則是天生設計成多租戶（公有云）模式，把原本用于對終端用戶（2C端）的認證鑒權機制完全用于IDC內網的服務間通訊，服務間通訊有完整的雙向鑒權，是一個強訪問控制體系。筆者推測這樣做可能是有幾方面的原因：

• 同一個服務的不同實例可能被部署為跨物理機、跨機架甚至跨IDC，與其它的服務實例混合部署，原來相對集中的通過IP的訪問控制模型已經不太適用于完全分布式的架構，過于分散的多點對多點的ACL規則想象一下就頭疼，于是就出現一個情況：要么訪問控制很粗很大條效果不明顯，要么很細但是規則幾乎沒法寫。

• 第二個原因可能是由于server和服務實例規模數巨大引起的海量ACL條目難以維護的問題，干脆扔了，用完全的鑒權。

• 如果用傳統的訪問控制手段，例如VXLAN隔離、交換機ACL、主機iptables規則會無法維持一個巨大的彈性內部網絡，服務擴容時都會受到阻礙，監控、調試和診斷都會更難。之前有同學提出通過主機安全agent動態生成白名單的內網隔離思路，現在Google則在這個問題上給出了自己的解，這也揭開了我在《互聯網企業安全高級指南》中沒有寫出來的部分:)。本質上這是由規模量變到質變引發的問題，如果你的IDC內網只有幾臺機器真沒必要那么做。Google也強調了自己有做網絡隔離和防止IP欺騙，但沒有把這個當成主要手段。

發布安全：Google的所有代碼存儲于一個集中的代碼倉庫，同時保留當前和過去的版本，每一個發布的二進制文件都能關聯到構建時的源代碼版本，這里暗示了Google有做白名單和完整性校驗，其實Google和Amazon都有白名單，但這要求基礎架構高度統一。發布時需要至少1人review同意（可以理解為在構建/發布系統中的workflow），任何對某個系統的更改需要系統的owner同意。統一的代碼倉庫，意味著發布的入口是唯一可控的，版本可唯一追溯，同時交叉的code review可以部分矯正一些內部的不良行為：例如開發人員安置后門，惡意彩蛋等。這實際上是Google研發文化的一部分，不一定是出于安全的原因，不過總而言之，安全是這個流程的受益者。以前有boss問過我離職程序員安置后門程序如何檢測的問題，海量Web下不具有webshell & sqli的特征，當初想到結對編程，交叉review，覺得有點理論化。Google給出了的解正好，防止釣魚，同時防止內鬼，不只是簡單的防外，而是防內外，覆蓋整個價值鏈。

同一個機器間的服務隔離，主要通過：Linux原生的用戶空間隔離（Android的appid的原理），程序語言和kernel的沙箱，以及硬件虛擬化手段。對于涉及用戶提交代碼或文件的高風險服務例如Google App Engine & Google Compute Engine會使用多層次隔離和縱深防御（如下圖所示），另外對于集群管理和KMS等服務會使用專門的物理機。實際上一般情況下密鑰管理會使用專有硬件HSM，至于集群管理服務使用專用機器推測一方面可能有一些完整性校驗的安全強相關功能，另一方便可能跟集群管理服務本身的可用性要求及failover機制有關。

業內一直有HIDS（Host-based Intrusion Detection System，主機入侵檢測）的技術路線之爭，大規模容器時代即將到來，技術路線的選擇更是迫在眉睫。業界的一種看法是私有云以Linux用戶態為主，關注運維需求，軟件兼容性和server本身的可用性需求；另一種則是內核態，以純安全視角的強掌控型實現為主。從Google的實現里似乎也可以得到啟示：G廠走的是公有云，天然多租戶模式，使用了內核態路線。當然對于效仿者而言，前提是：

• 你有很強的保證kernel代碼工程質量的能力。
• 內部基礎架構、組件高度統一，否則很可能會東施效顰。

Google的內部服務訪問控制可配置為特定的服務只允許指定的API或者指定的人才可以訪問的模式，實現上通過Machine ID、Service ID、User ID放在一個全局命名空間來做訪問控制的基礎（注：2C端的訪問控制是另外一套體系），支持Group對Group來做多對多的訪問控制，同時提供了“two-party control”，即一個變更提交后需要由同group的另外一個管理員approve才能生效，這其實跟分布式事務中二階段式提交是一個原理，為了保證最終一致性。Google在這些流程的問題上直接套用了工程理論。

Google自身的工程師訪問內部API需要通過這種認證鑒權模式，實際上暗含了另外一個課題：數據安全。這部分在業界比較受重視，但需求往往比較抽象，而在實現方式上更是沒有統一的標準，Google的這種方式貌似歪打正著，把2C的鑒權模式用在生產網絡和后臺系統，實際上是對原來運維通道獲取數據途徑的更進一步收斂，保留強審計和日志，這樣一并連數據安全也算解決了一部分，雖然不是全部。

Google的內部服務提供全加密通訊的能力，例如HTTP封裝成RPC，而RPC默認提供幾種不同的加密強度：低價值數據只做完整性校驗，高價值的用更強壯的加密等級，跨IDC傳輸流量自動加密。

最后舉了一個Gmail服務訪問聯系簿（contacts服務）例子來說明RPC調用的鑒權細粒度，如果ACL設置為允許Gmail訪問聯系簿這種細粒度是不夠的，因為用戶A可以越權訪問用戶B的聯系簿，水平權限的這類問題掃描器不容易覆蓋，干脆在架構設計上一并解決：RPC請求帶用戶的ticket走一個內部的SSO（單點認證鑒權）以驗證是否可以訪問對應的數據，這樣就相當于內部的API調用在用戶這個細粒度上做了一次全流量的鑒權，從架構上避免了水平權限類的問題。再次回到安全架構的頂層設計，Google的思路就是把所有分散的鑒權點集中起來，在一個高度抽象的層次上做好一件事，最大程度的隔離。

數據安全

Google在數據安全（狹義的，指在IDC側的部分）上實踐的幾點：

• Google是做靜態數據全盤加密的。
• 不直接寫硬盤，而是通過BigTable、Spanner這種存儲服務間接寫持久化數據。
• 數據加密與KMS關聯，可以理解為用了對稱加密，密鑰中的一部分來自KMS。
• 與用戶ticket相關，可以推測為加密密鑰鏈的頂層密鑰每個用戶唯一，且動態轉換（rotate）。
• 為了加解密性能采用硬件加速。
• 數據銷毀流程會使用兩道獨立的流程來驗證（是否刪除），不經過此流程的直接物理粉碎。
• Google說自己可以追蹤每一塊硬盤全生命周期的狀態。

上面的內容里除了文件加密那塊會有一些技術復雜度，其他都是工程化的問題，想象一下隨便去機房拔塊硬盤偷數據應該是沒戲了，但是對于絕大多數公司而言，能在IDC實現全盤加密而且很可能用的不是文件系統加密，這個是一個很大的工程，實現起來比較困難，所以Google能把這些方案都落地，說明領先了很多年。對于很多公司來說，全盤數據加密會導致IOPS大幅下降，依賴KMS服務可用性指標又會下降，數據丟失和恢復又成問題，所以能實施這些方案背后是整體技術的依賴。

Internet通訊安全

暴露在互聯網通訊的安全部分總結一下就是幾個點：

• 有一個統一的接入層GFE（Google Front End）。
• 接入層統一做TLS加密以及證書管理，避免業務各自為政。
• 接入層解決了端口暴露外網的問題，雖然選擇不信任IDC內網，但是內網仍然是比外網更安全的地方。
• 接入層擁有規模優勢，具備抗DDOS能力。
• 骨干網傳輸、4層、7層流量負載均衡都有流量監測和上報流量行為數據的能力（可以理解為Google自己在這些環節實現了Anti-DDOS）。
• 有一個中央流控服務，負責丟棄流量或限制閾值。
• 接入層有一定的人機識別能力（根據設備、登錄IP等做判斷，大概是風控服務的基礎組件）。
• 因為OTP的2FA認證方式容易被釣魚，所以現在轉而用FIDO聯盟的U2F的方式代替OTP。

運維安全

1. Google有一套完整的SDL機制來盡可能的保證交付的代碼是安全的，這些手段包括：

   • 內部：集中代碼管理，交叉review，安全的代碼框架和Lib庫、fuzzer、靜態代碼掃描、Web安全掃描器，有Web安全、密碼學、操作系統安全等各領域的專家團負責安全設計review＆威脅建模，并且會持續的將這些安全經驗沉淀為通用的安全庫和工具等。

   • 外部：高額的漏洞獎勵計劃。

   • 開源軟件：大多數公司對待開源軟件的態度可能是跟隨策略，即社區發布了補丁我跟著patching，而Google表現出的態度則是，將開源軟件和自研軟件同等對待，都實施SDL那套安全審計，在例如OpenSSL，KVM等軟件上發現了不少CVE漏洞。

2. Google投入很多來保證自己的雇員設備不被黑：

   • 其中最重要的就是BeyondCorp項目，對辦公網絡進行改造、取消內網、整個OA系統云化，把原來基于物理位置的信任模型（公司辦公網絡的內網或者V*N接入到內網）改成根據雇員設備狀態，用戶生命周期內的行為動態的生成訪問控制策略，訪問控制的細粒度從VLAN/IP收斂為應用級別，例如到一個系統中的某些URL這樣的權限。這種訪問控制模型可以抑制被APT后橫向滲透的受害范圍，同時基于云化的方案可以為監控提供更多的數據來源。

   • 為了抵抗釣魚攻擊，雇員認證從OTP改成U2F。

   • 大量的終端管理行為：包括OS最新補丁、限制客戶端軟件安裝、監控下載、瀏覽器擴展、訪問的內容等。

3. 降低內部風險：

   • 監控有基礎設施訪問權限的雇員（SRE、DBA……）的終端行為，持續評估并賦予工作所需要的最小權限。
   • 數據安全的場景再次出現：Google對生產環境debug數據脫敏，并且雇員對線上用戶數據的訪問會被底層hook的日志追蹤，是否異常行為由安全團隊監控，底層的hook在這里大約可以理解為劫持了一些終端和訪問通道以及命令執行的信息，而數據脫敏則是一個很大的課題，尤其是海量數據。

4. 入侵檢測

   • Google有成熟的基于各種設備、主機、網絡、服務的日志監控，這個大約得益于Google自研的技術棧比較深，所以日志“打點”這塊是不愁了，而對于很多其他公司而言還要自研一堆安全產品，可惜的是Google在這塊幾乎沒怎么開源過。

   • 紅藍軍對抗，基本上大公司的標配，有錢就可以玩的起來。

Google云平臺安全

GCP（Google Cloud Platform）繼承前述所有的安全能力。除此之外云平臺特有的一些安全屬性包括：

• 給VM和VMM分配兩個獨立的服務ID，這樣就可以區分哪些流量來自VM而哪些來自VMM。
• GCE（Google Compute Engine）持久化磁盤的靜態數據會使用KMS產生的密鑰自動加密。
• VM廣域網之間的流量可自動加密。
• 計劃推VM內網的流量自動加密。
• KVM定制過，把一些控制和硬件模擬從內核轉移到用戶態進程中。
• 對KVM做過模糊測試、靜態掃描和人工審計，大部分KVM的漏洞都由Google發現。
• Google承諾不碰用戶數據，但除了通篇提及的方式外好像也沒特殊說明不碰用戶數據的保證手段是什么。

如何才能趕上Google

盡管這有可能是一個偽命題，不過從積極的角度不妨來分析一下：

首先這是一個公司規模強相關的命題，如果你的IT整體投入還比較小，或者IDC規模仍然不大的情況，上述安全體系方法論應該是不適用的，因為這是一個依靠大量自研，大型安全團隊才能做起來的事情。在規模更小的情況下，很多場景會有TCO更低，更簡單的解。但對于從業者來說顯然還是大規模下的經驗更有利于自身價值提升，所以后面還是要打個小廣告。

其次，跟公司所處的階段強相關，如果公司處于相對早期，或者野蠻生長階段，目標基本都是為了滿足業務需求，風險偏好會更傾向于接受風險，同時公司所處的階段會側面反映出工程技術整體的成熟度，安全要做到Google那樣是工程技術整體領先的結果，而不是安全單個職能突出的結果。

第三方面跟文化和基因也有很大的關系，基因上看公司整體是由產品、運營還是技術驅動，由技術驅動或者有工程師文化的公司比較容易實現這一點，這點不展開想必讀者也能理解。文化方面，長期有耐心的公司文化比經常擁抱變化的公司更容易實現，Google的安全建設體現的都是大工程，也許你會發現，把其中的技術點單拉出來很多都沒有遙不可及，甚至在大一點的國內互聯網公司單點技術都是ready的，但是要全面落地卻要花上幾年的時間，所以最大的差距不在于單點技術，而在于G廠已經all done并且很可能已經在新技術和新方向的路上。如同Apple在業務相對早期的時候就把iOS的整套安全體系都落地了，這才是最大的挑戰。如果在一個需要短期見效，不行則擁抱變化的環境里，安全團隊要推行這種工程化改造需要長期忍受績效中下，對Leader和成員來說壓力都會很大。

第四點是工程技術團隊的整體能力，因為技術團隊整體很弱單安全團隊特別強的存在本身就是一個偽命題。

更多因素全都寫在《互聯網企業安全高級指南》這本書里了，不再贅述。

 

 

 

來自：http://tech.meituan.com/GoogleSecurity_ayazero.html