本文想從技術(shù)的角度談?wù)勎覍?duì)云計(jì)算數(shù)據(jù)中心DevSecOps運(yùn)維模式中的安全性的理解，和過(guò)去幾年我在云服務(wù)業(yè)務(wù)連續(xù)性管理方面的探索。

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

一、去中心化

每個(gè)云計(jì)算數(shù)據(jù)中心都有一些中心化的共享服務(wù)，比如防火墻、DNS、核心路由、負(fù)載均衡器、分布式存儲(chǔ)等等。雖然IT基礎(chǔ)架構(gòu)在設(shè)計(jì)和代碼執(zhí)行充分考慮到了高可用和高通量，可是實(shí)際上，總是有一些例外。比如，我們?cè)谝淮畏阑饓ι?jí)時(shí)，因?yàn)橐粋€(gè)偶發(fā)的Bug, Peer 并沒(méi)有接管所有的流量，結(jié)果導(dǎo)致了很多服務(wù)的非計(jì)劃的Outage。

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

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

二、備份與容災(zāi)

備份與容災(zāi)是保證服務(wù)安全性和可用性繞不開(kāi)的話(huà)題。雖然備份與容災(zāi)的成本很高，我們還是提供了針對(duì)各種場(chǎng)景的備份與容災(zāi)方案供客戶(hù)自己選擇。

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

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

三、持續(xù)改進(jìn)訪(fǎng)問(wèn)控制，在效率和安全中找到平衡點(diǎn)

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

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

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

（3)、數(shù)據(jù)加密。除了這種受控訪(fǎng)問(wèn)之外，我們還使用Oracle的Transparent Data Encryption (TDE)和Database Vault對(duì)靜態(tài)數(shù)據(jù)行保護(hù)和審計(jì)?？蛻?hù)可以控制TDE主加密密鑰并管理其生命周期。

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

四、從運(yùn)維的角度持續(xù)驗(yàn)證和改進(jìn)每個(gè)組件的可靠性、可用性和可維護(hù)性

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

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

我們通常是將整個(gè)服務(wù)的IT基礎(chǔ)架構(gòu)，分解為若干組件，再?gòu)囊韵缕邆€(gè)維度來(lái)分析和改進(jìn)每個(gè)組件恢復(fù)的解決方案。

（1)、單點(diǎn)故障，例如，硬件的各個(gè)組件、軟件的各個(gè)進(jìn)程、硬盤(pán)熱拔插、壞盤(pán)是否會(huì)導(dǎo)致零I/O、Chatty Disk是否會(huì)導(dǎo)致零I/O、DISK Resilvering、系統(tǒng)啟動(dòng)盤(pán)、硬盤(pán)架(Enclosure)。

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

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

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

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

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

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

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

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

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