主要內容：
一、探討運維人員安全職責
二、解析數據庫業界案例事件
三、雲上數據庫安全問題解決方案
一、探討運維人員安全職責
1）數據安全現狀
企業IT關注點包括架構、性能、成本，IDC權威調研機構數據顯示，全球74.6%的企業最關心的問題是安全性，安全性永遠是第一位，數據庫是安全重中之重。
運維人員安全職責：從維護數據到支撐業務，根據業務相關性分成3層：
·第一層是數據的安全性，也就是如何防止託庫。保障好數據庫安全，這一層的能力更專注在數據庫本身防護，比如加密技術，權限控制技術。比如數據庫被暴力破解，因為沒有加密，被黑客攻破後把這個數據完全蕩走，在日常的運維過程當中接觸最多，需要對數據庫做內在或者外圍加固，防止數據庫系統被攻破，把裡面的數據拖走或者是毀壞。
·第二層是業務安全，這一層會更關注在流程機制安全上，如何杜絕刪庫跑路。比如內部人員，因為本身流程不規範，出現了業界最常說的刪庫跑路行為，是業務安全的屬性，需要運維人員去完善。
·第三層則是業務合規，這一點特別是在一些金融、保險、政府等敏感行業上，本身會有數據合規需求，比如兩地三中心、操作審計等監管必須能力。為什麼這一點會是最重要的，大家日常做運維肯定都知道，眼前的事情肯定最重要，一旦不合規，業務都上不了線，那業務數據本身也就產生不了價值。所以從業務相關角度來講，業務合規安全性最重要。
二、解析數據庫業界案例事件
1）安全無小事
數據庫安全問題，70%甚至80%以上都是由人禍造成的。不管是外在或者是內部的人，不管是因為客觀性攻擊數據庫，或者是主觀性破壞數據庫，人禍都佔了很大部分。整體上做數據庫的安全防護時，技術往往是一方面，更多的行為是在於人冶上面，怎樣通過這種流程跟手段有效的控制，在技術之外，把安全性的防護做好，是在整個數據庫安全領域裡，面臨的最為頭疼的一個問題。
人禍之外，天災屬於不可抗力因素，比如地震、海嘯或者其他極端的影響，施工團隊把機房電纜光纜給挖斷了，發生了火災等。這個行為的出現是不可抗力，且無法杜絕，我們需要通過本身的運維手段加固、防護，在發生事情時，解決事情對企業帶來的影響。
2）安全事件
人禍叢生，誰來背鍋？
人禍安全事件帶來了哪些影響？下面列舉了兩個案例：
第一個案例:在17年-18年的時候，MongoDB作為流行的非關係型數據庫,3.2還是3.4版本上面出現了本身開源軟件上的版本漏洞。這個版本漏洞導致一旦數據庫暴露在公網，有很多的手段可以通過免密登錄的方式直接登錄數據庫。
國外的黑客團隊，專門針對MongoDB的bug做了一次批量攻擊，全網掃描開放的MongoDB端口的主機，登錄上去之後，把裡面的所有的數據庫的備份數據全部拿走了，本地數據庫上面已經沒有任何數據。黑客給每一臺被攻擊的企業做了留言，一旦想拿回數據，就往這個賬戶上面匯0.2個比特幣，0.2個比特幣是針對普通企業，特別有名的企業，比特幣價碼會水漲船高。據不完全統計，全球範圍之內大概有3萬個數據庫受到攻擊，大概產生6000個比特幣，即使按照今天比特幣估值，贖金的範圍大概是在5億人民幣左右。
本身開源軟件產生的漏洞問題，很難在日常運維、維護過程當中被發現。因為大家下載一個軟件部署上去之後，做了很多的外圍加固，一旦內部出了安全問題，運維人員背這個鍋，顯得相對無辜。
第二個案例：在年初發生的事情，業內有一家比較大的企業出現了實實在在版的刪庫跑路行為，最後跑路沒有成功又被抓回來了。這個行為產生的影響是，這家業務整個服務廢掉36個小時左右，一天多的時間之內都服務不了。最後企業整體市值蒸發掉差不多7億元。所以一旦產生了安全事件，如果沒有特別好的防護機制，每一筆都會產生上億元的損失。
天災不斷，何以規避？
近年來經常會看到，比如某個地方的電纜給挖了，官網崩了，機房斷電了，不管是騰訊或者是阿里支付寶，都出現過部分業務在那段時間內無法被用戶繼續訪問。但是大家可以發現像騰訊、阿里這樣的大公司，其實做了非常完善的防護機制，從來沒有出現過因為電纜、光纖被挖斷，導致數據丟失。
對於相對沒有大公司雄厚的基金或者人力實力的時候，怎麼避免天災對企業帶來的影響，是很多運維人員會遇到的問題。
三、雲上數據庫安全問題解決方案
1）上雲能解決問題麼
雲數據庫安全能力能解決通用場景下的各類天災人禍嗎？答案是能解決，但不是全部。從下面MyBase全鏈路安全圖，可以看出：
·事前：數據安全防護，需要對開源軟件漏洞提前進行修復，從整個用戶使用的內容上來看，包括專用網絡隔離、白名單控制、賬號密碼鑑權、安全環境免密。
·事中：在攻擊的過程當中，對整個訪問鏈路加密、數據落盤加密、備份文件加密。
·事後：一旦被攻破了之後，整體攻擊電路都能做到攻擊行為上的審計，全量操作日誌審計。
阿里依託本身比較強悍的產業優勢，已經做得相對完善。所以企業有比較強的數據安全防護上的需求，對數據庫做加密需求或攔截需求，需要採購很多外圍系統，用雲數據庫MyBase方案解決，會更為得心應手。
2）雲安全與自有安全體系的結合
上面講到，從業務相關性上面對數據安全做了三個等級劃分：
第一層：數據安全性，阿里雲的MyBase雲數據庫，專屬集群上面已經做到相對比較多的防護，包括白名單控制、返回電路SSL加密、TDE加密以及開源軟件連帶的內核漏洞修復，阿里雲都有自己的團隊在做。
·第二層：業務安全，數據庫本身的加密安全防護沒有問題之後，人治上面通過防護機制杜絕內部工作人員做從刪庫到跑步行為，更多需要依賴流程約束。
MyBase提供了兩層防護，第一層防護是：對所有的數據庫都會有一個至少7天之內的備份存儲，可以做到沒有辦法容忍刪除。也就是說備份，即使把現在數據庫上面的所有數據都刪掉了，備份依然會在阿里雲上面，只要事例還在有效期之內，依然會存在事例內部，依然可以通過備份把數據恢復。
在這個基礎之上，還提供了第二層保護，通過額外的工具產品，比如通過GPS做跨賬號或地域備份。比如數據庫在賬號a，把這一部分的備份移到了賬號b上面，這樣一來，即使賬號a裡面做了極端破壞行為，數據依然會有一段存儲在賬號b裡面，可以做防護性的恢復措施。MyBase通過工具跟產品的結合，包括大家在內部的運維機制管理，完善業務安全屬性。
·第三層：業務合規性，更多體現在兩地三中心方案、數據審計方案，會有證監會或者銀監會強制要求企業滿足訴求。如果只是數據庫層面，MyBase目前的產品能力上面完全可以滿足。
但是很多企業在使用服務器的時候，要求有物理隔離性，物理隔離性跟雲計算的共享資源機制，相互之間是相背的，雲計算技術有沒有辦法解決物體隔離性問題。下面會講如何解決這個問題。
3）上雲引入了新的問題？
上雲引入了兩個新的問題：
第一個問題，雲廠商是否可信？
第二個問題，雲計算屬於共享性質的資源部署，通過隔離機制跟其他業務部署在同一臺物理機上面，這樣一來，共享機制會不會放大被別入侵的可能性？
先來回答第一個問題，如今雲廠商可信度已經不是特別大的問題了，第一點是因為：不管是雲廠商本身，或是引入了第三方機構一直在跟雲廠商合作，包括國家級的等保合規，第三方可信雲，都會對引入第三方認證機制來認可雲廠商本身的安全跟防護機制是完全可靠的。
第二點是因為：在上雲時，肯定要選擇比較大的雲廠商，能夠被國際或者國內大客戶認可的雲廠商，比如阿里雲，已經合作了很多金融、政府、各個行業的領頭羊企業。如果一家雲廠商已經大到可以容納很多行業的企業進來，安全問題已經被開始進來的頭部企業的要求完全滿足過了。
整體上看，雲廠商的可信度建議大家上雲時，從兩個方向去看，
第一，是看雲廠商本身有沒有足夠多的第三方可信度認證。
第二，是否有很多比較大的行業企業已經選擇這家雲廠商，作為上面的基石標準。如果滿足這兩條，是可以放心上雲的。
第二個問題：共享資源放大了被侵入的可能性問題，雲計算確確實實有共享資源的機制，但是通過雲計算本身的安全能力，包括大廠本身的安全防護，事實上在共享隔離方面已經做得非常完善。大家共享在某一臺物理服務器上面，對於數據庫密碼洩露、別人的數據庫切入密碼、被外面反覆入侵的問題，影響到用戶的可能性很小。除非像金融行業，就是有要求業務一定要在一臺完全獨立的物理機上面，今天的雲計算數據庫也是可以做到的。
4）MyBase專屬集群加持完全物理隔離能力
MyBase專屬集群加持完全物理隔離能力，可以從數據庫的實例來看，在一臺非常大的物理服務器上面，某個用戶買了4合8局，就隔一個4合8局給用戶使用，其他客戶的業務跟數據庫實際也是在這個服務器上面，但也是通過隔離機制，用戶買了多少就隔了多少給他用。
MyBase機制與上面的實例級別的交互產品的區別在於，在MyBase上面，給用戶提供的是一臺完全獨立的服務器，可以是一臺完全獨立的物理主機，一臺實實在在的物理主機，在購買完這臺物理主機之後，可以在這臺物理主機上面直接分配自己的數據庫，這種方式有兩個好處：
第一，不用再擔心共享加大安全性入侵的問題。
第二，因為完全獨立的機制，完全可以滿足業界對業務要有獨立物理服務器部署的需求。
所以通過MyBase安全物理隔離的機制，可以解決很多行業合規屬性問題。大家在普通的業務場景下依然可以選擇普通的雲服務，一旦需要完全獨立的物理隔離環境就可以選擇MyBase專屬機群服務，作為數據庫上雲的選擇，從而杜絕安全性合規風險。
5）雲數據庫專屬集群 部署架構圖
現在的專屬集群裡具備了所有的雲數據庫的安全能力，同時在這些能力基礎上集成了物理隔離能力，面對行業的合規性問題。
本身的雲數據庫專屬集群，因為擁有主機級別的操作權限，可以把企業已經採購的安全的插件也安裝到雲上的數據庫裡面。比如已經買好一套審計系統，也可以選擇直接把這套審計系統部署在雲數據庫專屬集群裡面，從而把專屬集群的安全能力跟本地系統的安全能力做一個全面結合，形成更好的雙方都可以認可的安全等級防護。
