寫技術白皮書的目的是：
①培養大家從行業角度做宏觀綜述的能力；
②保證團隊技術的可傳承性，一份份白皮書仿若一本本九陽真經，至少有個復盤的本本留下來，
好，下面就開始這份（防）刪庫跑路技術白皮書，
1 概述
刪庫跑路是一種歷史悠久、后果嚴重的公司資產損壞事故，一旦發生，輕則業務短時間不可用，重則公司倒閉關門，甚至有人為此坐牢，
圖1 從刪庫到跑路
對于這種重大經營性風險，經歷過掛牌上市的公司都有方法機制預防和應對，生產環境安全保障的流程制度是否健全，也是審計機構重點核查的物件，與其審計機構進場的時候臨時抱佛腳，不如你仔細閱讀本文，未雨綢繆，把該做的工具做好，把該建的流程規范建好，
1.1 微盟刪庫后被刑拘
最近一次也是最為人所知的是香港上市公司微盟集團刪庫，在這次運維工程師“含恨”出手連根擦除、應用服務中斷整整九天的事件里，微盟被洗掉的資料體量達到了數百TB，隨后這位賀姓員工被上海市寶山區公安局刑事拘留，
有詩為證：一鍵驚神刪主備，SaaS憑空起風雷，身負重責莫自棄，我心光明道不移，
恢復小隊通過審計日志可以看出，2020年2月23日19時許，微盟的賀姓運維工程師洗掉了微盟業務資料，甚至下了死手洗掉了備份資料檔案，微盟被刪的資料分為兩部分，一部分是存放在自建資料庫里的現網業務資料，部署在資料庫服務器上；一部分是存放在備份服務器上的備份資料，因為是檔案洗掉操作，兩種服務器里的檔案都是碎片化記憶，且不可見，二者區別在于，資料庫服務器中的殘存檔案數量多，型別繁雜；而備份服務器檔案型別單一，資料集中，
經過相對常規的操作，2月17日及以前的所有資料都找回來了，2月28日，微盟拿到2月17日的備份資料后，恢復所有業務線上生產環節，老用戶可登錄后臺，微站產品所有資料重新上線，但這還不夠，騰訊云技術團隊和資料恢復公司還需要通過打撈小檔案拼接大檔案的方式繼續恢復后續的資料，
圖2 前線工程師在做拷貝資料
每一次拼接，都要資料從頭到尾掃描一遍，匹配是否成功，為了加快掃描和驗證，需要強大的計算力，騰訊云臨時呼叫騰訊上海機房 100 臺服務器做支持，如果能順利推進，整個程序可無障礙執行，一旦出現問題，就要推翻重來，一次需要 12 小時，經歷了無數次“打撈、掃描、拼接、驗證”后，終于，最大的一個核心資料檔案在2月28日晚上找回來了，它由 7 個碎片組成，
3月1日晚，微盟發布公告說，由于此次資料量規模非常大，為了保證資料一致性和線上體驗，3月2日凌晨2點進行系統上線演練，3月3日上午9點資料恢復正式上線，同時發布了1.5 億元的商家賠付計劃，
這份公告對這次事件也進行了反思：“沒有嚴格按照公司的內控管理制度，對運維人員的權限進行分級和磁區管理，”這次事件中的最大問題在于，權限管理過于簡化，沒有嚴格劃分業務場景并且梳理最低的操作權限需求，導致了超級管理員的出現，而恰巧超級管理員出現了不軌意圖，給企業造成了重大損失，
“你讓我評價這件事，我第一感受是不要再發生這種事情了，企業的IT治理一定要把安全放在第一位，”恢復資料作戰總指揮徐勇州說，“微盟是幸運的，能100%找回資料是奇跡，但如果再發生一次，未必有這么幸運了，”
依據《刑法》第 286 條（對計算機資訊系統功能進行洗掉、修改、增加、干擾，造成計算機資訊系統不能正常運行，后果嚴重的，構成“破壞計算機資訊系統罪”）以及相關司法解釋，“刪庫跑路”如果造成 10 臺以上計算機系統不能正常運行就可以判刑，如果影響 50 臺以上則至少判 5 年，即“刪庫跑路”的量刑標準與影響到的計算機系統數量有關，毫無疑問，以微盟的體量，賀姓員工量刑至少五年起，
微盟如此慘痛的教訓，喚起了我們更多的記憶，
1.2 順豐刪庫后被辭退
2018年9月，順豐科技運維高級工程師鄧某在接到變更需求后，按照操作流程要求，登陸生產環境跳板機，在選定洗掉時，游標回跳到 RUSS 庫的實體，在未看清所選內容的情況下，便通過 delete 執行洗掉，同時鄧某忽略了彈窗提醒，直接回車，導致 RUSS 生產資料庫被刪掉，因為運維工程師一個不嚴謹的操作，導致 OMCS運營監控系統瞬間崩潰，他的結局是被辭退，
圖3 順豐內部通報郵件
1.3 刪索引也會判刑
邱某2014年入職到杭州的一家科技公司，擔任技術總監，因老板逼其離職，2018年6月23日就在自己家里面遠程登上了公司在阿里云的資料庫，當然為了不過早暴露，他選擇洗掉了資料庫上的一些關鍵索引和部分表格，但最終仍造成公司經濟損失，因邱某自愿認罪并賠償了公司8萬元，杭州市余杭區人民法院酌情予以從輕處罰，并對被告人邱某判處有期徒刑二年六個月，緩刑三年，
1.4 廣西移動用戶資料被誤格式化
2017年9月，某企業技術工程師幫助廣西移動進行擴容割接（即增加系統容量）時，不小心將 HSS 設備里面的用戶資料格式化洗掉，導致廣西移動近 80 萬用戶資料丟失，
1.5 Verelox被已離職員工刪庫
2017年6月10日，Verelox（一家提供VPS、服務器出租和托管的云主機服務商）貼出公告：不幸的是，一名前任管理員刪光了所有的客戶資料，并且擦除了大多數服務器上面的內容，正因為如此，我們已采取了必要的步驟或措施，暫時將我們的網路下線，我們一直在努力恢復資料，但是這個方法可能恢復不了已丟失的所有資料，
1.6 Digital Ocean刪庫后人還在
2017年4月5日，位于紐約的云服務商Digital Ocean 也遭遇了系統刪庫：由于配置錯誤，本應指向測驗環境的任務被指向了生產環境，測驗任務包含的環境初始化程序洗掉了主生產資料庫，由此開啟了一次長達4小時56分鐘的停機事故，
1.7 gitlab刪庫后人還好
2017 年 2 月，gitlab 的一位荷蘭籍DBA 在深夜給線上資料庫做負載均衡作業時，遭受了 DDoS 攻擊，在阻止了攻擊之后，又發現了資料庫不同步的問題，于是開始修復，在修復的程序中，他發現 db2.staging都 hang 在那里，無法同步，于是他想把db2.staging 的資料庫洗掉了，這樣從新啟動一個新的復制，結果，洗掉資料庫的命令錯誤地敲在了生產環境上（db1.cluster）：
sudo rm -rf
這是一個包含了 300 GB 實時生產資料的檔案夾，等到他徹底清醒過來急忙按下 CTRL+C，只剩下 4.5GB 資料……由于沒有有效的備份，嘗試了所有5個恢復工具都沒有完成恢復，gitlab 被迫下線，
圖4 gitlab官方推特發通告
一樁樁一件件，觸目驚心，我們不能等到事件發生之后，再來悔恨，再四處求助恢復資料，
2 風險綜述
除了刪庫跑路之外，我們其實還會遇到其他高風險以至于雞飛蛋打，
2.1 機房故障災難
常見的是云資料庫 RDS 實體故障，比如我們曾經在就餐午高峰遭遇突發的主資料庫 CPU 100%，誰也連不進去，整整 45 分鐘，我們還曾遇到過阿里云單機房網路不可用，完全連不進去，整整三個小時，這時候如果企業有多活機房，則可通過其他機房的資料進行恢復，如果只有單機房，只能根據異地備份檔案來恢復，
2.2 底層存盤災難
底層存盤并不一定總能訪問到，如果你要恢復資料，最好有一份異地備份檔案，2018年6月27日下午，阿里云工程師團隊在上線一個自動化運維新功能中，執行了一項變更驗證操作，觸發了一個未知代碼bug，從而禁用了部分內部IP，導致全國大量客戶投訴云存盤 OSS 產品無法訪問，也就是資料不可見了，
2.3 實體誤釋放災難
云資料庫實體一旦被誤釋放，資料和備份會都被洗掉，那將是塌天大禍，這時候如果有多活機房，則可通過其他機房的資料進行恢復，如果只有單機房，只能根據異地備份檔案來恢復，
2.4 程式誤刪誤覆寫災難
BUG 上線產生了大量臟資料，或刪錯了很多資料，可通過“資料備份”和“日志備份”功能恢復到指定時間點，如果只是少量資料錯誤，可通過回滾 Binlog 日志檔案進行修復，很多年前，我們就曾經在頭一天晚上發布了一個版本，到了第二天上午八九點收到了洪水一樣的投訴，這才發現大錯已經釀成，追悔莫及，當時還只有單機房，只有凌晨的常規資料庫備份，足足花了一天時間才將資料悉數糾正，
2.5 訂正資料災難
同上，我們對訂正線上資料也非常謹慎，尤其是當一個新業務剛上線不久，管理后臺功能尚未完善之際，運營人員經常會找研發刷庫，而且通常會很急，急急忙忙撰寫刷庫腳本的，與經過開發、聯調、測驗、上線完整流程的，就是不一樣，不是不可以刷庫，但請記住，經常刷庫就一定要做成系統功能，常在河邊走，難免會濕鞋，出了事兒就是大事兒， 既然會遇到如此多災難，那么我們應該如何防患于未然呢？
3 業界綜述
防范刪庫跑路，本質上還是一個資料庫安全的問題，對于這個問題，業界早有定論，蓋國強曾經撰寫過一本書：《資料安全警示錄》，提出了資料安全的五個緯度，可以基于這五個緯度來梳理企業的資料安全，并據此建立相應的安全防護措施，這五個緯度分別是：軟體安全、備份安全、訪問安全、防護安全、管理安全，它們可能會導致兩種性質的安全問題：一）內部威脅：由于內部管理不善而導致的資料安全問題；二）外部威脅：由于外部惡意攻擊入侵所帶來的安全問題，通常我們把安全問題狹義化為后者，這實際上是片面的，在資料安全問題上，前者造成的資料損失、資料損毀，其發生概率和影響度都遠遠超過后者，
圖5 內外部兩種威脅
3.1 資料安全五大方面和十六條建議
下面對資料安全的五大方面做一個簡要分析：
一）軟體安全：指的是我們選擇的資料庫產品、版本是否穩定安全，廠商所能提供的補丁集和BUG修正是否及時，基礎硬體與作業系統是否經過認證，很多用戶在部署資料庫軟體時，僅僅選擇了最容易獲得的初始發布版本，遺漏了可能已經存在的補丁修正，并且在運行維護中并不能夠及時跟蹤軟體更新，也無法獲得BUG資訊、補丁修正和安全告警，這就使得軟體本身的很多風險隱患得不到修正，如果軟體安全無法保證，資料庫安全的基礎也就喪失了，
二）備份安全：指用戶資料能否得到及時有效的備份保全，能否在故障災難之后獲得及時的恢復和挽救，在資料庫運行期，最為重要的就是備份安全，如果沒有可靠的備份，將資料集中起來就只能是等待資料災難，所以我們將備份安全提升到核心地位，備份以及隨之衍生的容災安全等，都是企業整體資料架構應該考慮的因素，很多企業在資料災難之后因為缺乏有效備份而一蹶不振，根據 Gartner 早年間一份調查報告顯示，在經歷了資料完全丟失而導致系統停運的企業中，有五分之二再也沒能恢復運營，余下的企業也有三分之一在兩年內宣告破產，由此可見，由于備份安全問題導致的企業傷害可能遠遠大于黑客攻擊，
三）訪問安全：指用戶資料庫的訪問來源和訪問方式是否安全可控，通常資料庫系統處于IT系統的核心，其安全架構涉及主機、系統、存盤、網路等諸多方面，如果沒有明確的訪問控制，缺乏足夠的訪問分析與管理，那么資料庫的安全將是混亂和無法控制的，在應用軟體使用和訪問資料庫時，要正確設定權限，控制可靠的訪問來源，保證資料庫的訪問安全，唯有保證訪問安全才能夠確保資料不被越權使用、不被誤操作所損害，通常最基本的訪問安全要實作程式控制、網路隔離、來源約束等，
四）安全防范：指通過主動的安全手段對資料庫通訊、傳輸等進行增強、監控、防護、屏蔽或阻斷，諸如資料加密、審計、資料防火墻等技術都在這一范疇之內，我們必須認識到，在IT技術高度發展的今天，風險是無處不在、層出不窮的，可能我們從未思考過的安全問題，每天都在不斷涌現，所以在資料庫環境中采取主動式防護，可以幫助我們監控分析和屏蔽很多未知風險，
五）管理安全：指在企業資料的日常管理維護范疇內，能否充分保證資料安全以及服務的高可用連續提供，諸如DBA的維護、檔案的管理、引數或資料結構的變更等等都可能引入資料風險，管理安全要求我們通過規范、制度以及技術手段去確保維護管理安全，另外，基于硬體、電力等基礎平臺的故障都可能影響資料庫服務的高可用性，在管理中要通過監控手段及時預警，通過集群、備庫等切換與服務分擔保障服務的連續性，
基于以上分析，蓋國強進一步提出了 16 條建議：
<1>備份重于一切：DBA四大守則的第一條就指出，『備份重于一切』，有了有效的備份，即使遭遇災難，也可以從容應對，唯一會讓DBA們從夢中驚醒的就是：沒有備份！所以對于資料庫運維來說，第一重要的是做好備份！有備方能無患！
<2>嚴格管控權限：過度授權為資料庫埋下安全隱患，所以在向用戶授權時一定要遵循最小權限授予原則，避免因為過度授權而帶來的安全風險，微盟這次安全風險，如果用戶只具備最低權限，那么也不會遭遇如此災難，
<3>明確用戶職責：應當明確不同的資料庫用戶的作業范圍，應當使用普通用戶身份的，就絕對不應該使用DBA的用戶身份，只有職權相稱，才能夠避免錯誤，降低風險，即便是擁有管理員職責的用戶，也應當遵循以不同身份執行不同任務的習慣，比如SYS和SYSTEM用戶的使用就應當進行區分和界定，
<4>密碼策略強化：毫無疑問，資料庫用戶應當使用強化的密碼規則，確保弱口令帶來的安全風險，很多資料泄露問題來自弱口令攻擊和提權，
<5>限制登錄工具：明確限制不同工具的使用場景，明確規定工具的準確來源，或者通過堡壘機等來限制資料庫訪問，對于工具也可以做出明確規則和限制，如限制僅能通過SQL Developer訪問生產，PL/SQL Developer工具僅能訪問測驗環境，以減少安全風險甚至誤操作風險，
<6>禁止遠程DDL：可以限制DDL操作僅能在資料庫服務器本地進行，禁止遠程連接執行DDL操作，這一手段在很多（未上公有云的）公司被嚴格執行，
<7>使用系結變數：在開發程序中，嚴格使用系結變數，系結變數可以防范SQL注入攻擊，減少資料庫安全風險，這次安全事故，很多用戶開始猜測是SQL注入，走了很多分析上的彎路，
<8>監控監聽日志：監聽日志記錄了資料庫訪問的來源、程式等資訊，包括惡意掃描，密碼嘗試等，一定要重視監聽日志的作用，并對其進行分析和監控，以清楚地繪制資料庫訪問圖譜，
<9>資料網路隔離：資料庫的網路環境應該一直隱藏在最后端，避免將資料庫置于直接的訪問連接之下，由此可以減少資料庫的訪問風險，
<10>測驗和生產環境隔離：環境互通就意味著同時可以訪問，也就可能帶來很多意想不到的安全風險，企業應當將測驗環境和生產環境部署于不可互通，或者不可同時訪問的網路環境中，避免因為錯誤連接而發生的資料庫災難，分離部署一方面可以降低誤操作的可能性，也可以屏蔽一些無關的訪問可能，從而從網路鏈路上保證資料安全，
<11>密碼差異設定：有些測驗環境或者非產品環境是利用產品環境恢復得到的，DBA在建立了測驗環境后，就沒有修改資料庫用戶的登錄密碼；經常性的，DBA也習慣在所有環境中設定通用的密碼；這些習慣為系統帶來了很多風險和不確定性，特別建議用戶在不同環境中采用不同的密碼設定，這是因為一方面產品環境和測驗環境面對的訪問用戶不同，密碼設定相同則意味著產品環境的安全性完全得不到保障；另一方面，DBA登錄到不同的資料庫需要使用不同的密碼，這進一步減低了DBA在錯誤的環境下執行命令的可能性，
<12>重要資料加密：很多重要的資料，需要加密存盤，最典型的就是用戶和密碼資訊，大量的泄密事件本質上是因為缺乏最基本的加密防范，對重要資料實施一定的安全防護加密，是應當予以適時考慮的安全方面之一，
<13>適時的軟體升級：這里的軟體指資料庫軟體，
<14>防范內部風險：不可否認，絕大部分安全問題都來自于企業內部，來自最緊密、最輕易的接觸和訪問，企業的人員變動，崗位變更，都可能導致資料安全問題的出現，單純依靠對管理員的信任不足以保障資料安全，必須通過規章、制度與規范的約束才能夠規避安全風險，很多企業為了便利而舍棄規范、規章或者安全限制是得不償失的做法，安全防范應當從內部做起，從限制約束自我做起，當最緊密相關的訪問都遵從守則，那么系統的安全性就能夠獲得大幅度的提升，
<15>樹立安全意識：安全問題最大的敵人是僥幸，很多企業認為安全問題概率極低，不會落到自己的環境中，所以對于安全不做必要的投入，造成了安全疏忽，所以安全問題最大的敵人是我們自己，安全需要一點一滴的加強，逐步完善，
<16>開始安全審計：云資料庫可能已經提供了一些安全防范的手段和方法，特別建議企業適當展開安全防范措施，開啟部分任務審計，定期分析資料庫風險，由此逐步完善資料庫安全，
3.2 防患于未然的六大法寶
而經歷了此次劫難完整程序的騰訊云團隊，則給出了六條建議，相比較于事后搶救性恢復，如何避免這樣的災難再次發生，是更為重要的，只要把握住如下六大法寶，就可以防患于未然，
一）建設資料庫災備系統：資料庫災備系統是基于資料庫層的技術和架構來實作對資料的保護，確保在諸如機房故障、地震、火災等不可抗因素下資料的安全，兩地三中心、三地四中心這類叫法其實就是指資料庫異地多中心的災備系統，建立災備系統的好處顯而易見，在業務環境發生安全故障（自然災備、機房故障、人為誤刪）的時候，我們可以第一時間切換到異地的災備資料庫恢復資料和業務訪問，一套健全的災備系統可以使最佳復原時間目標（RTO）降低到秒級，目前主流云廠商資料庫產品都有配套的災備產品解決方案，如下圖所示，
圖7 公有云提供的異地資料庫災備方案
二）有效的備份：微盟這個時候如果沒有資料庫備份，或者備份沒有驗證過導致備份檔案不可用，就失去了最后一根救命稻草，只能選擇走作業系統級別的磁盤檔案恢復，即使僥幸能恢復，耗時也會非常之久，導致相當長的業務停機時間，需要注意的是，備份不是簡單的工具應用，而是系統化的備份策略，全量備份、增量備份、日志備份的策略搭配、備份異地存盤、備份有效性驗證都必須考慮到位，把備份當做一個系統工程去建設，而不只是簡單的備份工具運營，
三）訪問控制策略：對于絕大多數中小型公司來說，一個運維或DBA就能管整個系統，并且擁有整個系統所有主機的最大權限，比如 root，這種集權式的管理就存在“刪庫跑路”的風險，在運維體系的建議中，我們需要規避這種不受到權限制約的超級用戶，建議方案是建立多權分立的權限體系，以三權分立的體系為例，將傳統資料庫系統 DBA的角色分解為三個相互獨立的角色，分別是安全管理員，審計管理員，資料管理員，基于此基礎提出的安全策略，主要細分為三個部分，分別為資料加密、資料脫敏訪問、強制訪問控制，三者組合提供多個層級的資料安全保障能力，安全管理員、審計管理員、資料管理員這三個角色之間相互制約，消除出系統中的超級權限，從系統角色設計上解決了資料安全問題，
圖8 三權分立權限分解圖
四）資料存盤加密：資料加密是將資料庫中的資料通過身份認證、密鑰+密碼、密鑰管理等進行資料保護的技術，是防止資料庫的資料資訊篡改和泄露的有效手段，通過資料資訊加密能夠確保資料用戶資訊的安全，即使資料被非法匯出、備份檔案被竊取，也無法恢復和訪問丟失的資料， 對于一些重要的機密資料，如一些金融資料、賬號密碼、商業秘密等，都必須存盤在資料庫中，需要防止對它們的未授權訪問，哪怕是整個系統都被破壞了，加密仍可以保護資料的安全，對資料庫安全性的威脅有時來自于網路內部，一些內部用戶可能非法獲取用戶名和密碼，或利用其他方法越權使用資料庫，甚至可以直接打開資料庫檔案來竊取或篡改資訊， 資料加密方式有兩種：1）業務敏感資料加密：呼叫加密函式，將加密后的結果寫入資料庫，正常讀取的也是加密后的資料，在應用里面執行解密，當然，敏感資料加解密涉及到一定的應用程式改造成本，需要決策層權衡下，2）資料庫內置加密功能：比如MySQL5.7版本推出的資料庫內置的TDE 透明資料加密，可對資料庫的表空間檔案進行加密，現在主流云廠商的資料庫產品都有自己的加密功能，可以做到更加細粒度的加密，
五）資料庫審計能力：資料庫審計能夠實時記錄資料庫活動，對資料庫操作進行細粒度審計的合規性管理，對資料庫遭受到的風險行為進行告警，如黑客對資料庫 SQL 注入攻擊、例外操作等，因此，提高資料庫的安全級別，還需要資料庫審計技術支撐，審計主要有如下幾種：1）陳述句審計2）（資料庫）物件審計3）（資料庫）用戶審計4）細粒度審計，FGA（Fine-Grained Audit） 另外，資料庫審計技識訓用于監視并記錄對資料庫服務器的各類操作行為，通過對網路資料的分析，實時、智能地決議對資料庫服務器的各種操作，并記入審計資料庫中以便日后進行查詢、分析、過濾，實作對目標資料庫系統用戶操作的監控和審計，資料庫審計技術可以監控和審計用戶對資料庫中的資料庫表、視圖、序列、包、存盤程序、函式、庫、索引、同義詞、快照、觸發器等的創建、修改和洗掉等，分析的內容可以精確到SQL操作陳述句一級，還可以根據設定的規則，智能判斷出違規操作資料庫的行為，并對違規行為進行記錄和報警，
六）強調安全規范：這一點其實并不是資料庫功能系統層面的安全，而是管控制度層面的安全建設，
1）嚴格管控權限，明確用戶職責，遵循最小權限授予原則，避免因為過度授權而帶來的安全風險，明確不同的資料庫用戶能夠用于的作業范圍，防范和隔離風險，比如：資料庫應用賬號只賦予SELECT、UPDATE、INSERT權限，取消DELETE權限，把需要DELETE權限的邏輯改成用UPDATE實作，避免被物理洗掉，
2）密碼策略強化，防范弱口令帶來的安全風險，定期更換密碼，同時生產和測驗環境嚴格使用不同的密碼策略，
3）移除匿名賬戶和廢棄的賬戶，比如經典的：mysql> use mysql;mysql> DELETE FROM userWHERE user="";mysql> flush privileges;
4）制訂規范并貫徹執行，良好的規范是減少故障的基礎，全面的規范提升開發和運維人員的標準化，
5）防范內部風險，絕大部分安全問題都來自于企業內部，通過規章、制度與技術手段規避安全風險，比如建立三權分立權限體系，
6）樹立安全意識，安全問題最大的敵人是僥幸，制定安全方案，定期分析資料庫風險，逐步完善資料庫安全，
7）及時打好安全補丁，務必保持資料庫為最新版本，因為攻擊者可以利用上一個版本的已知漏洞來訪問企業的資料庫，
騰訊云資料庫團隊語重心長地告誡我們，微盟刪庫事故的發生對其他企業的資料安全保護敲響了警鐘，僅僅依靠單點防護難以達到真正的安全防護效果，而構建基于全生命周期的安全防護成為必然選擇，
4 我們的做法
前文講述了很多風險來源和安全規范，那么接下來分享一下我們保障資料庫安全的常規操作，
4.1 訪問安全型別的預防機制
首先，我們通過自研平臺 IDCenter、SimpleWay 配搭 LDAP 服務完成了帳號管理，這樣工程師在離職的時候，相關VPN帳號、堡壘機帳號、阿里云帳號均會被洗掉，再也無法登錄生產環境，登錄線上堡壘機也都有IP 白名單的限制，只允許公司 IP 訪問，
其次，我們依托 JumpServer 來阻斷危險操作，JumpServer 是一款由 Python + Django 開發的開源跳板機系統，能夠為企業提供認證、授權、審計、自動化運維等基本功能，工程師登錄 JumpServer 后，我們在內部屏蔽了一些高危命令，只要有人執行，系統就會強制阻斷，而且系統對任何操作都會有審計和歷史記錄，
最后，開發工程師對線上的服務只有讀的權限，沒有操作權限，
4.2 安全防范型別的預防機制
首先，與支付交易相關的商業應用需要做到資料脫敏存取，即有可能被開放訪問的用戶和客戶的敏感資訊，如手機號，身份證號，銀行卡號，密鑰，在資料庫存盤和讀取的時候會采用 AES-128 對稱加解密，降低萬一被拖庫后的商業風險，
4.3 備份安全型別的預防機制
我們采用了混合云部署方式，橫跨 8 個機房，既有公有云提供的云資料庫，也有自行搭建的資料庫集群，它們都有相應的備份機制，更進一步的是，我們通常采用異地雙活機制，同時還會將資料同步到資料湖里，所以相當于資料做了三地實時備份，如下圖所示，環境中有四個機房：主機房，從機房，資料機房，應急機房，
圖9 交易系統網路拓撲圖
如上圖所示，餐飲門店的客戶通過智能設備發起點餐或收單請求，第一次請求將默認訪問基礎域名，而基礎域名指向主機房，所以請求將進入主機房，主機房會判定客戶真正的業務歸屬機房以及對應的分片，將對應的動態域名下發給智能設備，智能設備以后的請求都將訪問動態域名，請求會直接進入對應的機房以及分片，客戶的業務歸屬機房和分片，可以通過控制臺動態調整，調整后，可以快速通知到智能設備，從而做到秒級切換客戶流量，主機房與從機房的多活資料（包括資料庫資料和快取資料）保持實時雙向同步，主機房和從機房的業務資料變化都會分發到資料機房（即資料湖），所有大資料計算都在資料機房完成，就這樣，我們天然地做到了資料多地實時備份，
4.4 管理安全型別的預防機制
我們有工具和流程雙重保障，這其中的工具，指的是資料庫自動化運維平臺（內部代號iDB），這也是一些大型互聯網公司所重點關注的IT基礎設施之一，它可以做到兩點：第一，確保生產環境的變更操作，有審核記錄，有操作記錄，能回滾，第二，用戶崗位職責與系統用戶權限相符合，責權利對稱，
圖10 iDB（資料庫自動化運維平臺）在IDCenter上的入口
資料存盤安全保障，首先是工具的預防機制，
- 帳號權限控制：業務工程操作資料庫的帳號在iDB里申請和分配，寫帳號只有insert、delete、update和select權限，無alter、drop和truncate等DDL權限，讀帳號只有select權限，
- 帳號密碼控制：研發人員只是在 iDB 里為應用訪問某個環境里的資料源申請工程帳號而已，部署和上線發布對他來說是透明的，工程的組態檔里密文密碼是我們自研的另一個研發協作平臺（內部代號CloudEngine）在構建鏡像的時候自動完成填充的，他不需要接觸到資料庫密碼，研發人員不知道資料庫明文密碼，也就沒有機會犯錯，
- 資料查詢權限：研發人員只允許通過iDB查詢線上資料，并保留登錄和查詢記錄，
- 資料訂正權限：研發人員只允許通過iDB提交DML陳述句，驗證語法正確性、是否使用索引、分表操作是否包含路由欄位和單條影響行數等規則，在DBA審核后生成備份并執行，誤操作可回滾，
- 表結構修改權限：研發人員只允許通過iDB提交DDL陳述句，驗證語法后經DBA審核后執行，這種DDL操作也支持回滾，
其次，是公有云資料庫的安全預防機制，
- 云資料庫的管理權限：資料庫管理人員（即DBA）可以管理云資料庫，但是資料庫的實體釋放操作則需要運維經理角色確認，
- 資料庫訪問白名單：只允許指定IP和業務工程所在網段訪問相應的資料庫，
最后，資料庫的備份及可恢復性測驗，非常關鍵，備份永遠是資料庫管理員的第一要務，我們設定通過腳本自動備份，將備份相關資訊記錄到iDB系統中，每周會做備份的可恢復性自動檢查，
位于IDC機房的自建資料庫集群的備份機制是，通過腳本自動備份，將備份相關資訊記錄到iDB系統中，每周會做備份的可恢復性自動檢查，
阿里云的資料備份，則使用阿里云自帶的“備份恢復”功能，介紹如下：
1）資料備份
RDS提供如下兩種備份功能：資料備份：設定的是周一至周日每天凌晨在備庫實體進行全量物理備份（后臺使用Percona XtraBackup備份），備份保留7天，日志備份：已開啟日志備份（Binlog日志檔案），日志備份保留7天，
2）資料恢復
恢復到阿里云RDS實體，可以這么做：按備份集：根據“資料備份”，將備份檔案資料克隆出一個獨立的實體，驗證后，再將資料手動或通過DTS遷回原實體，按時間點：根據“資料備份”和“日志備份”，將最近的一次全備和全備后的日志備份恢復到一個新實體，經過驗證后，再將資料遷回原實體，恢復到自建機房資料庫，可以這么做：根據“資料備份”和“日志備份”，使用恢復工具PerconaXtraBackup將備份恢復到指定時間點， 雖然有這樣那樣的措施，但云資料庫仍存在一定管理風險，下面依次闡述，
4.4.1 阿里云實體釋放時的風險
手動釋放阿里云RDS實體的時候，大家務必小心謹慎，請多人交叉核對實體ID是否正確，其原因如下所示，首先，阿里云上“按量付費”的讀寫實體，子帳號都可以直接釋放實體，無需主帳號確認， 其次，阿里云上“包年包月”的寫實體，子帳號看不到“釋放實體”的按鈕，只能提工單釋放，
但是在提工單的時候，需要手動填寫阿里云的RDS“實體ID”，而無需提供額外資訊，主帳號在工單中確認后，即可釋放并退款，為了避免子帳號填寫錯誤而誤釋放實體，需要在處理阿里云工單時引入線下審核機制，主帳號負責人務必與DBA二次確認后，再由主帳號確認退款，
4.4.2.阿里云RDS管理權限的風險
有RDS管理權限的話，即可在管理界面上刪庫和帳號，無需登錄資料庫，但阿里云管理平臺上無法簡單快捷地檢查哪些子賬戶擁有RDS管理權限，所以除了DBA之外誰有權刪庫，無法一目了然，所以我們必須在賦權上小心謹慎，保證不同角色權限隔離，如擁有管理權限AliyunRDSFullAccess，就可以直接洗掉庫，小心哦，
4.4.3.阿里云RDS的備份可恢復性測驗
我們確實有在做自動化可恢復性測驗，但僅限于我們自己的IDC機房的資料庫備份可恢復性測驗，阿里云的云資料庫本身并沒有備份可恢復性測驗，
4.4.4.實體恢復時間過長
實體級故障恢復時間較長，對于高頻交易型別業務來說也是一個重大風險，比如100G資料的實體恢復需要40分鐘，
4.4.5.誤操作沒有快速恢復工具
目前阿里云沒有提供快速恢復工具，需要開發工具，能快速從Binlog日志檔案中恢復最近的誤操作，
4.5 小結
刪庫跑路再現江湖，微盟市值蒸發10億元，還要對商戶賠付1.5億元，其中公司承擔1億，管理層承擔5000萬，所以說小洞不補，大洞吃苦，一出了事兒就是大事兒，備份，備份，備份，永遠是 DBA 的第一重責，備份高于一切，除了備份之外，還要未雨綢繆建設工具、流程和制度，我司的研發哲學第五條是“永遠要給自己留一個后備方案”，異地備份，多地備份，權限隔離，操作審計，交叉確認，……善待員工，給公司留條后路，
-完-
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/76774.html
標籤：其他