| 本文想從技術的角度談談我對雲計算數據中心 DevSecOps 運維模式中的安全性的理解，和過去幾年我在雲服務業務連續性管理方面的探索。 |
現在公有云服務商都不約而同地轉向 DevSecOps 模式。DevSecOps 是 DevOps 的另一種實踐，它將信息技術安全性作爲軟件開發所有階段的一個基本點。安全性，不僅涉及各種層次的隔離和合規性檢查，而且涉及從技術層面確保業務連續性。在 ISO/IEC 27001 信息安全管理體系中，“業務連續性管理”是安全管理中非常重要的一環，目的是爲減少業務活動的中斷，使關鍵業務過程免受主要故障或天災的影響，並確保及時恢復。“業務連續性管理”是安全治理中的術語，把它轉化到計算機產品中的術語，就是“可靠性，可用性和可維護性（RAS）”。
一、去中心化
每個雲計算數據中心都有一些中心化的共享服務，比如防火牆、DNS、核心路由、負載均衡器、分佈式存儲等等。雖然IT基礎架構在設計和代碼執行充分考慮到了高可用和高通量，可是實際上，總是有一些例外。比如，我們在一次防火牆升級時，因爲一個偶發的 Bug，Peer 並沒有接管所有的流量，結果導致了很多服務的非計劃中斷。
在這之後，將 IT 基礎架構從中心化結構分解成衆多的較小的故障域結構，成了我們在設計和改進雲計算數據中心的關鍵考慮因素之一。我們雲基礎架構分佈於幾十個地區Regions。每個地區的數據中心又從物理上分隔爲 3 個可用性域Availability Domains，這些可用性域所有的基礎設施都獨立的。可用域彼此隔離，容錯，並且幾乎不可能同時失敗。由於可用性域不共享基礎設施（例如電源或冷卻）或內部可用性域網絡，因此區域內一個可用性域的故障不太可能影響同一區域內其他可用性域的客戶。在每個可用性域裏，我們又進一步去中心化，分組爲多個故障域Fault Domains。故障域是一組硬件和基礎架構。通過適當地利用故障域，我們的客戶可以提高在 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)、滲透測試、安全評估、修復和強化。另外，我們還週期性從技術的角度審查各個組件的認證和授權協議的安全性、傳輸層加密和網絡隔離的安全性、數據訪問控制的細粒度，並引用漏洞掃描、滲透測試和評估，對發現的潛在性弱點及時自動化的修復和強化方案。
四、從運維的角度持續驗證和改進每個組件的可靠性、可用性和可維護性
在談到可靠性時，大家常提到混沌工程Chaos Engineering。我個人覺得混沌工程是對於雲服務商的服務消費者而言。雲服務消費者往往由於缺少對低層技術的瞭解，所以需要引入混沌工程觸發服務器實例失效、網絡故障、應用故障來使自己研發工程師遞交的運行於公有云服務能夠容忍故障同時仍然確保足夠的服務質量。
對於公有云服務商而言，我們還得走專家模式，引入破壞性測試，從運維的角度，持續驗證和改進每個組件的可靠性、可用性和可維護性，特別是可能性的故障的恢復的解決方案，從而提高系統在故障後可以花較少的時間將服務恢復到運行狀態的能力。
我們通常是將整個服務的 IT 基礎架構，分解爲若干組件，再從以下七個維度來分析和改進每個組件恢復的解決方案。
（1)、單點故障，例如，硬件的各個組件、軟件的各個進程、硬盤熱拔插、壞盤是否會導致零 I/O、Chatty Disk 是否會導致零I/O、DISK Resilvering、系統啓動盤、硬盤架Enclosure。
（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”（安全）的理解，以及自己工作中的一些探索。其目的在於拋磚引玉，帶動大家一起討論如何提高雲服務數據中心的安全性，確保業務連續性。其中有些觀點不一定正確，歡迎批評指正。
歡迎大家發表留言，列出你的企業從安全的角度改進”業務連續性“方面的經驗。