主要内容：
一、探讨運維人員安全職責
二、解析資料庫業界案例事件
三、雲上資料庫安全問題解決方案
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）雲資料庫專屬叢集 部署架構圖
現在的專屬叢集裡具備了所有的雲資料庫的安全能力，同時在這些能力基礎上內建了實體隔離能力，面對行業的合規性問題。
本身的雲資料庫專屬叢集，因為擁有主機級别的操作權限，可以把企業已經采購的安全的插件也安裝到雲上的資料庫裡面。比如已經買好一套審計系統，也可以選擇直接把這套審計系統部署在雲資料庫專屬叢集裡面，進而把專屬叢集的安全能力跟本地系統的安全能力做一個全面結合，形成更好的雙方都可以認可的安全等級防護。