GCP 資訊安全系列:Google Infrastructure Security (三)

Google Infrastructure Security 設計總覽 (三)

原文內容於 2017 年初撰寫,僅代表當時寫的現狀。隨著 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 天會進行分類、審查及對應這些潛在的意外事件。我們作為「紅隊試驗」來測量及更新我們的偵測及回報機制的效率。

相關文章:
GCP 資訊安全系列:Google Infrastructure Security (一)
GCP 資訊安全系列:Google Infrastructure Security (二)
(原文翻譯自:https://cloud.google.com/security/security-design/)

 

iKala - GCP 專門家

GCP 專門家,Google Cloud 官方認證的首席合作夥伴。自家影音產品架構在 GCP 上,使用經驗超過 3 年,具備從 IDC 搬遷至 AWS 最後落腳於 GCP 的經驗,是最能協助您避掉所有技術地雷的 GCP 夥伴,更擁有業界最多支援 Google Cloud 的技術人員。

我們提供了多項的 GCP 加值服務:

了解更多: https://gcp.expert/
Facebook Fan Page: https://www.facebook.com/gcp.expert/
聯絡我們:+886 2 87681110 或請來信 gcp@ikala.tv