知識星球
本文作者：王錄華，Oracle 雲服務研發總監
現在公有雲服務商都不約而同地轉向 DevSecOps 樣式。DevSecOps 是 DevOps 的另一種實踐，它將資訊科技安全性作為軟體開發所有階段的一個基本點。安全性，不僅涉及各種層次的隔離和合規性檢查，而且涉及從技術層面確保業務連續性。在 ISO/IEC 27001 資訊保安管理體系中，“業務連續性管理”是安全管理中非常重要的一環，目的是為減少業務活動的中斷，使關鍵業務過程免受主要故障或天災的影響，並確保及時恢復。“業務連續性管理”是安全治理中的術語，把它轉化到計算機產品中的術語，就是“可靠性，可用性和可維護性（RAS）”。
一、去中心化
每個雲端計算資料中心都有一些中心化的共享服務，比如防火牆、DNS、核心路由、負載均衡器、分散式儲存等等。雖然IT基礎架構在設計和程式碼執行充分考慮到了高可用和高通量，可是實際上，總是有一些例外。比如，我們在一次防火牆升級時，因為一個偶發的 Bug，Peer 並沒有接管所有的流量，結果導致了很多服務的非計劃中斷。
在這之後，將 IT 基礎架構從中心化結構分解成眾多的較小的故障域結構，成了我們在設計和改進雲端計算資料中心的關鍵考慮因素之一。我們雲基礎架構分佈於幾十個地區。每個地區的資料中心又從物理上分隔為 3 個可用性域，這些可用性域所有的基礎設施都獨立的。可用域彼此隔離，容錯，並且幾乎不可能同時失敗。由於可用性域不共享基礎設施（例如電源或冷卻）或內部可用性域網路，因此區域內一個可用性域的故障不太可能影響同一區域內其他可用性域的客戶。在每個可用性域裡，我們又進一步去中心化，分組為多個故障域。故障域是一組硬體和基礎架構。透過適當地利用故障域，我們的客戶可以提高在 Oracle Cloud Infrastructure 上執行的應用程式的可用性。例如，客戶如有兩個 Web 伺服器和一個叢集資料庫，我們會建議他們將一個 Web 伺服器和一個資料庫節點組合在一個故障域中，將另一半組分配到另一個故障域中。這可以確保任何一個故障的失敗都不會導致應用程式中斷。
除了上面這個故障域，我們還針對 Oracle SaaS 服務（Oracle 的 ERP、CRM、HCM 等行業解決方案，目前有超過 2.5 萬的企業客戶）提出了具體的指標：任何元件的災難事件都應無法導致該資料中心 10% 的客戶，或 100 個客戶的服務中斷。為此，我們團隊幾年前設計並實施一個去中心化的改進方案以實現這一標的。這是個以零停機時間為標的的基礎架構最佳化方案，涉及了防火牆、DNS、負載均衡器、Web 前端、儲存、IMAP 等等。
二、備份與容災
備份與容災是保證服務安全性和可用性繞不開的話題。雖然備份與容災的成本很高，我們還是提供了針對各種場景的備份與容災方案供客戶自己選擇。
備份資料使用率很低。在生產環境中，我接到的資料恢復請求平均每個季度不到千分之二，主要是顧客測試環境中的資料恢復。而真實的生產環境的 SaaS 服務資料恢復請求平均每個季度不到萬分之二。為了這萬分之二的使用機率，運維部門每週都會抽取一定比例的備份按照特定的安全的流程進行資料恢複測試和驗證，以確保備份是有效的。
我還和我的同事們還開發了 Oracle SaaS DR 的執行方案。客戶如購買了這一服務，則可透過 Oracle Site Guard 的 Web GUI 介面的簡單幾步操作，即可快速將生產環境從一個資料中心切換到另一個資料中心。蘑菇街技術服務總監趙成先生在他的文章《做容災，冷備是不是個好方案》中提到了冷備的難點。我們的 DR 方案在技術上重點就是解決了非計劃中斷之後，資料同步、清除異常鎖檔案、負載均衡器更新、應用配置更新、使用 Data Guard 切換資料庫等方面的問題，以及主節點恢復後如何進行反向同步並自動切換到非計劃中斷之前的配置。關於我們 DR 方案的 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective），你可以 Google 查詢“Disaster Recovery for Oracle SaaS Public Cloud Services ”，從官方正式的檔案中得到。實際上，我們生產環境中驗證的資料比對外公佈的資料要好得多。
三、持續改進訪問控制，在效率和安全中找到平衡點
我把訪問控制的範圍概括為：客戶授權的特定的人、在指定的時間內、以驗證過的安全方式、訪問脫敏的內容，並盡可能地加密客戶資料路過的所有通道和節點。
（1)、客戶授權。我們根據客戶的行業屬性不同和資料安全性需求不同，定製了多個客戶安全審計部門參的訪問控制批准工作流。這個授權的程式涉及 SRE 工程師的國籍、第三方背景調查、客戶資料保護相關的安全培訓、膝上型電腦的硬碟加密狀態等。訪問授權的時效可能是一次性、可能是幾天、也可能是 1 個月，根據行業特點和客戶需求而定。
（2)、訪問控制的細粒度。在技術的執行上，除了 VPN 和 Bastion (又稱 Jumpbox) 外，我們還引入了 Oracle Break Glass 方案來讓外部客戶自己來批准和授權Oracle 的 SRE 工程師對系統和服務的管理訪問，提供應用層的額外的安全性。Break Glass 訪問是有時間限制的，它透過僅提供對 Oracle 支援人員的臨時訪問來保護客戶的資料。我們還引入 HSM 來加強雲服務環境中的數字金鑰的管理。在新一代的 Oracle SaaS 服務中，任何工程師對資料庫的 SQL 操作，會自動掛起並自動產生一個要求批准執行的SR，直到相關人員審查 SQL 陳述句安全性並批准後才會執行。
（3)、資料加密。除了這種受控訪問之外，我們還使用 Oracle 的 Transparent Data Encryption（TDE）和 Database Vault 對靜態資料行保護和審計。客戶可以控制 TDE 主加密金鑰並管理其生命週期。
（4)、滲透測試、安全評估、修複和強化。另外，我們還週期性從技術的角度審查各個元件的認證和授權協議的安全性、傳輸層加密和網路隔離的安全性、資料訪問控制的細粒度，並取用漏洞掃描、滲透測試和評估，對發現的潛在性弱點及時自動化的修複和強化方案。
四、從運維的角度持續驗證和改進每個元件的可靠性、可用性和可維護性
在談到可靠性時，大家常提到混沌工程。我個人覺得混沌工程是對於雲服務商的服務消費者而言。雲服務消費者往往由於缺少對低層技術的瞭解，所以需要引入混沌工程觸發伺服器實體失效、網路故障、應用故障來使自己研發工程師遞交的執行於公有雲服務能夠容忍故障同時仍然確保足夠的服務質量。
對於公有雲服務商而言，我們還得走專家樣式，引入破壞性測試，從運維的角度，持續驗證和改進每個元件的可靠性、可用性和可維護性，特別是可能性的故障的恢復的解決方案，從而提高系統在故障後可以花較少的時間將服務恢復到執行狀態的能力。
我們通常是將整個服務的 IT 基礎架構，分解為若干元件，再從以下七個維度來分析和改進每個元件恢復的解決方案。
（1)、單點故障，例如，硬體的各個元件、軟體的各個行程、硬碟熱拔插、壞盤是否會導致零 I/O、Chatty Disk 是否會導致零I/O、DISK Resilvering、系統啟動盤、硬碟架。
（2)、叢集框架，例如，單個儲存節點的 CRASH、HANG、PANIC、手動切換叢集、手動叢集 Failback、叢集的 Split Brain、叢集的 heartbeat 故障、高負荷下的叢集接管操作、分散式鎖失效測試、資料一致性驗證失效測試。
（3)、共享服務，例如，如果有多條配置，則在 DNS、NTP、AD、LDAP、NIS 中新增或刪除一個條目不應影響資料訪問和管理介面的訪問。
（4)、資料損壞，例如，包括觸發 Split Brain 並觀察是否存在資料損壞問題並找出資料服務恢復的解決方案，觸發 RAID 損壞並觀察是否存在資料損壞問題並找出資料服務恢復的方案。
（5)、基礎架構服務故障。
（6)、管理和監控介面的可靠性。
（7)、Overlay 技術帶來的效能和診斷的問題，以及服務恢復的解決方案。
正因為對每個元件相應的技術領域有了深入研究和充分的準備，對於升級的雲服務效能和可用性問題（P1 Escalation），我所在的 SRE 團隊基本上實現了“15 分鐘內響應並完成資料收集與分析、15 分鐘內給出解決方案”。
總之，雲端計算資料中心 DevSecOps 運維樣式中的安全性是一個持續改進的過程，我們要充分考慮去中心化、備份與容災、持續改進訪問控制，並引入破壞性測試，提高系統在故障後快速恢復到執行狀態的能力。
本文旨在簡單闡述一下作為一個 IT 系統架構師，我對當下雲端計算資料中心 DevSecOps 運維樣式中的“Sec”（安全）的理解，以及自己工作中的一些探索。其目的在於拋磚引玉，帶動大家一起討論如何提高雲服務資料中心的安全性，確保業務連續性。其中有些觀點不一定正確，歡迎批評指正。
