DevSecOps 運維模式中的安全性

現(xiàn)在公有云服務商都不約而同地轉(zhuǎn)向 DevSecOps 模式。DevSecOps 是 DevOps 的另一種實踐，它將信息技術(shù)安全性作為軟件開發(fā)所有階段的一個基本點。安全性，不僅涉及各種層次的隔離和合規(guī)性檢查，而且涉及從技術(shù)層面確保業(yè)務連續(xù)性。在 ISO/IEC 27001 信息安全管理體系中，“業(yè)務連續(xù)性管理”是安全管理中非常重要的一環(huán)，目的是為減少業(yè)務活動的中斷，使關(guān)鍵業(yè)務過程免受主要故障或天災的影響，并確保及時恢復?！皹I(yè)務連續(xù)性管理”是安全治理中的術(shù)語，把它轉(zhuǎn)化到計算機產(chǎn)品中的術(shù)語，就是“可靠性，可用性和可維護性（RAS）”。

每個云計算數(shù)據(jù)中心都有一些中心化的共享服務，比如防火墻、DNS、核心路由、負載均衡器、分布式存儲等等。雖然IT基礎(chǔ)架構(gòu)在設(shè)計和代碼執(zhí)行充分考慮到了高可用和高通量，可是實際上，總是有一些例外。比如，我們在一次防火墻升級時，因為一個偶發(fā)的 Bug，Peer 并沒有接管所有的流量，結(jié)果導致了很多服務的非計劃中斷。

在這之后，將 IT 基礎(chǔ)架構(gòu)從中心化結(jié)構(gòu)分解成眾多的較小的故障域結(jié)構(gòu)，成了我們在設(shè)計和改進云計算數(shù)據(jù)中心的關(guān)鍵考慮因素之一。我們云基礎(chǔ)架構(gòu)分布于幾十個地區(qū)Regions。每個地區(qū)的數(shù)據(jù)中心又從物理上分隔為 3 個可用性域Availability Domains，這些可用性域所有的基礎(chǔ)設(shè)施都獨立的。可用域彼此隔離，容錯，并且?guī)缀醪豢赡芡瑫r失敗。由于可用性域不共享基礎(chǔ)設(shè)施（例如電源或冷卻）或內(nèi)部可用性域網(wǎng)絡，因此區(qū)域內(nèi)一個可用性域的故障不太可能影響同一區(qū)域內(nèi)其他可用性域的客戶。在每個可用性域里，我們又進一步去中心化，分組為多個故障域Fault Domains。故障域是一組硬件和基礎(chǔ)架構(gòu)。通過適當?shù)乩霉收嫌?，我們的客戶可以提高?Oracle Cloud Infrastructure 上運行的應用程序的可用性。例如，客戶如有兩個 Web 服務器和一個集群數(shù)據(jù)庫，我們會建議他們將一個 Web 服務器和一個數(shù)據(jù)庫節(jié)點組合在一個故障域中，將另一半組分配到另一個故障域中。這可以確保任何一個故障的失敗都不會導致應用程序中斷。

除了上面這個故障域，我們還針對 Oracle SaaS 服務（Oracle 的 ERP、CRM、HCM 等行業(yè)解決方案，目前有超過 2.5 萬的企業(yè)客戶）提出了具體的指標：任何組件的災難事件都應無法導致該數(shù)據(jù)中心 10% 的客戶，或 100 個客戶的服務中斷。為此，我們團隊幾年前設(shè)計并實施一個去中心化的改進方案以實現(xiàn)這一目標。這是個以零停機時間為目標的基礎(chǔ)架構(gòu)優(yōu)化方案，涉及了防火墻、DNS、負載均衡器、Web 前端、存儲、IMAP 等等。

備份與容災是保證服務安全性和可用性繞不開的話題。雖然備份與容災的成本很高，我們還是提供了針對各種場景的備份與容災方案供客戶自己選擇。

備份數(shù)據(jù)使用率很低。在生產(chǎn)環(huán)境中，我接到的數(shù)據(jù)恢復請求平均每個季度不到千分之二，主要是顧客測試環(huán)境中的數(shù)據(jù)恢復。而真實的生產(chǎn)環(huán)境的 SaaS 服務數(shù)據(jù)恢復請求平均每個季度不到萬分之二。為了這萬分之二的使用概率，運維部門每周都會抽取一定比例的備份按照特定的安全的流程進行數(shù)據(jù)恢復測試和驗證，以確保備份是有效的。

我還和我的同事們還開發(fā)了 Oracle SaaS DR 的執(zhí)行方案?？蛻羧缳徺I了這一服務，則可通過 Oracle Site Guard 的 Web GUI 界面的簡單幾步操作，即可快速將生產(chǎn)環(huán)境從一個數(shù)據(jù)中心切換到另一個數(shù)據(jù)中心。蘑菇街技術(shù)服務總監(jiān)趙成先生在他的文章《做容災，冷備是不是個好方案》中提到了冷備的難點。我們的 DR 方案在技術(shù)上重點就是解決了非計劃中斷之后，數(shù)據(jù)同步、清除異常鎖文件、負載均衡器更新、應用配置更新、使用 Data Guard 切換數(shù)據(jù)庫等方面的問題，以及主節(jié)點恢復后如何進行反向同步并自動切換到非計劃中斷之前的配置。關(guān)于我們 DR 方案的 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective），你可以 Google 查詢“Disaster Recovery for Oracle SaaS Public Cloud Services ”，從官方正式的文檔中得到。實際上，我們生產(chǎn)環(huán)境中驗證的數(shù)據(jù)比對外公布的數(shù)據(jù)要好得多。

我把訪問控制的范圍概括為：客戶授權(quán)的特定的人、在指定的時間內(nèi)、以驗證過的安全方式、訪問脫敏的內(nèi)容，并盡可能地加密客戶數(shù)據(jù)路過的所有通道和節(jié)點。

（1)、客戶授權(quán)。我們根據(jù)客戶的行業(yè)屬性不同和數(shù)據(jù)安全性需求不同，定制了多個客戶安全審計部門參的訪問控制批準工作流。這個授權(quán)的程序涉及 SRE 工程師的國籍、第三方背景調(diào)查、客戶數(shù)據(jù)保護相關(guān)的安全培訓、筆記本電腦的硬盤加密狀態(tài)等。訪問授權(quán)的時效可能是一次性、可能是幾天、也可能是 1 個月，根據(jù)行業(yè)特點和客戶需求而定。

（2)、訪問控制的細粒度。在技術(shù)的執(zhí)行上，除了 VPN 和 Bastion (又稱 Jumpbox) 外，我們還引入了 Oracle Break Glass 方案來讓外部客戶自己來批準和授權(quán)Oracle 的 SRE 工程師對系統(tǒng)和服務的管理訪問，提供應用層的額外的安全性。Break Glass 訪問是有時間限制的，它通過僅提供對 Oracle 支持人員的臨時訪問來保護客戶的數(shù)據(jù)。我們還引入 HSM 來加強云服務環(huán)境中的數(shù)字密鑰的管理。在新一代的 Oracle SaaS 服務中，任何工程師對數(shù)據(jù)庫的 SQL 操作，會自動掛起并自動產(chǎn)生一個要求批準執(zhí)行的SR，直到相關(guān)人員審查 SQL 語句安全性并批準后才會執(zhí)行。

（3)、數(shù)據(jù)加密。除了這種受控訪問之外，我們還使用 Oracle 的 Transparent Data Encryption（TDE）和 Database Vault 對靜態(tài)數(shù)據(jù)行保護和審計?？蛻艨梢钥刂?TDE 主加密密鑰并管理其生命周期。

（4)、滲透測試、安全評估、修復和強化。另外，我們還周期性從技術(shù)的角度審查各個組件的認證和授權(quán)協(xié)議的安全性、傳輸層加密和網(wǎng)絡隔離的安全性、數(shù)據(jù)訪問控制的細粒度，并引用漏洞掃描、滲透測試和評估，對發(fā)現(xiàn)的潛在性弱點及時自動化的修復和強化方案。

在談到可靠性時，大家常提到混沌工程Chaos Engineering。我個人覺得混沌工程是對于云服務商的服務消費者而言。云服務消費者往往由于缺少對低層技術(shù)的了解，所以需要引入混沌工程觸發(fā)服務器實例失效、網(wǎng)絡故障、應用故障來使自己研發(fā)工程師遞交的運行于公有云服務能夠容忍故障同時仍然確保足夠的服務質(zhì)量。

對于公有云服務商而言，我們還得走專家模式，引入破壞性測試，從運維的角度，持續(xù)驗證和改進每個組件的可靠性、可用性和可維護性，特別是可能性的故障的恢復的解決方案，從而提高系統(tǒng)在故障后可以花較少的時間將服務恢復到運行狀態(tài)的能力。

我們通常是將整個服務的 IT 基礎(chǔ)架構(gòu)，分解為若干組件，再從以下七個維度來分析和改進每個組件恢復的解決方案。

（1)、單點故障，例如，硬件的各個組件、軟件的各個進程、硬盤熱拔插、壞盤是否會導致零 I/O、Chatty Disk 是否會導致零I/O、DISK Resilvering、系統(tǒng)啟動盤、硬盤架Enclosure。

（2)、集群框架，例如，單個儲存節(jié)點的 CRASH、HANG、PANIC、手動切換集群、手動集群 Failback、集群的 Split Brain、集群的 heartbeat 故障、高負荷下的集群接管操作、分布式鎖失效測試、數(shù)據(jù)一致性驗證失效測試。

（3)、共享服務，例如，如果有多條配置，則在 DNS、NTP、AD、LDAP、NIS 中添加或刪除一個條目不應影響數(shù)據(jù)訪問和管理接口的訪問。

（4)、數(shù)據(jù)損壞，例如，包括觸發(fā) Split Brain 并觀察是否存在數(shù)據(jù)損壞問題并找出數(shù)據(jù)服務恢復的解決方案，觸發(fā) RAID 損壞并觀察是否存在數(shù)據(jù)損壞問題并找出數(shù)據(jù)服務恢復的方案。

（5)、基礎(chǔ)架構(gòu)服務故障。

（6)、管理和監(jiān)控接口的可靠性。

（7)、Overlay 技術(shù)帶來的性能和診斷的問題，以及服務恢復的解決方案。

正因為對每個組件相應的技術(shù)領(lǐng)域有了深入研究和充分的準備，對于升級的云服務性能和可用性問題（P1 Escalation），我所在的 SRE 團隊基本上實現(xiàn)了“15 分鐘內(nèi)響應并完成數(shù)據(jù)收集與分析、15 分鐘內(nèi)給出解決方案”。

總之，云計算數(shù)據(jù)中心 DevSecOps 運維模式中的安全性是一個持續(xù)改進的過程，我們要充分考慮去中心化、備份與容災、持續(xù)改進訪問控制，并引入破壞性測試，提高系統(tǒng)在故障后快速恢復到運行狀態(tài)的能力。

本文旨在簡單闡述一下作為一個 IT 系統(tǒng)架構(gòu)師，我對當下云計算數(shù)據(jù)中心 DevSecOps 運維模式中的“Sec”（安全）的理解，以及自己工作中的一些探索。其目的在于拋磚引玉，帶動大家一起討論如何提高云服務數(shù)據(jù)中心的安全性，確保業(yè)務連續(xù)性。其中有些觀點不一定正確，歡迎批評指正。

Linux命令大全： https://www.linuxcool.com/

歡迎大家發(fā)表留言，列出你的企業(yè)從安全的角度改進”業(yè)務連續(xù)性“方面的經(jīng)驗。