總結這些年數據庫運維，除了數據庫優化，審覈，高可用，故障處理等這些日常事情外，給我留下感觸最深的就是有二起數據庫入侵事件，自己親身經歷的黑客攻擊拖庫事件，一起是事件的追查者，一起是事件的發現者，兩個事件已經距離有點長時間，而且已經離開，不會對公司有什麼影響，公司名用代號替代。
今天介紹一下其中一起入侵事件，詳細追查過程和相關忽略。
A電商公司，某個週一，公司接到好幾個客戶的投訴，說接到自稱是來自公司的電話，說是搞活動，發信息鏈接給客戶搞網絡詐騙。得到這些消息後，公司CTO，拉了個羣，找運維查是否有內部人員偷取公司數據，讓我查一下數據庫是否有什麼異常。
開始分析數據庫的執行SQL，當時爲了找到慢SQL優化，特意一直開啓了訂單主庫的SQL Server的Profile事件，超過1秒的SQL都會保留，我就直接看前幾天的監控Profile的慢SQL語句，發現二個異常的SQL：
1，有一天凌晨3點查詢訂單主表的SQL，查出的數據量有幾百萬條訂單敏感數據。
2，也是在同天凌晨，發現一個根據訂單號查詢訂單表的SQL，因訂單號是字符串，他寫成了數字，導致無法使用索引，被Profile捕獲的慢SQL
隨着追查的深入，發現越來越多信息：
1，黑客攻擊拖數據前幾天，在網站系統下,一個訂單，後續取消，後根據前臺網站訂單號，進入數據庫後查詢確認是訂單數據。
2，黑客拿到賬號和密碼後，進入SQL Server數據庫，手工創建訂單關聯表視圖，通過視圖導出數據
1，視圖DDL，通過昨天完整備份+日誌，通過還原到指定時間點獲取到完整視圖語句
2，看視圖SQL，黑客只要了最近幾個月的訂單敏感數據，太早的數據沒要。
3，黑客當天拖庫前幾天，已經入侵公司線上IDC機房機器，做了一次前期的準備。
發現一臺機器的SSIS打開創建了SSIS任務包
4，黑客通過入侵BI組的一臺跳板機，登陸到線上SQL Server
通過Profile捕獲以上異常慢SQL獲取的IP，這個BI的跳板機，大概我是半年前幫他們安裝的，後續移交後就忘記有這臺機器。
5，黑客導出數據後，將壓縮包發到web網站一個目錄下，一臺2個月前剛部署的虛擬機上，通過下載軟件下載
1，下載後，黑客刪除了數據壓縮包，但是在zabbix裏有當時的網站流程出口有大流量。
2， 刪除的數據壓縮包，通過數據恢復軟件，恢復出完整的恢復出裏面的數據。
和運維同事那邊獲取的信息，大致把黑客入侵方法，拖庫的步驟弄清楚。
公司高層的二次調查：
1，第一次調查，是CTO拉羣調查，我們這幾個核心人知道，但是最終查不出黑客，報警，給了警方IP，最後警方說是來自境外詐騙IP
2，第二次調查，前一次調查結束了就沒事，沒想到幾個月後，公司又委派總裁再調查這件事
我跟2位公司高層領導他們介紹了這些情況，的確是因爲安全沒做好，讓人有可成之機。
安全改進：
1，改進線上IDC登陸，改成VPN+短信安全認證
2，數據庫密碼重設，改進程序明文密碼，改成用短名稱密碼加密服務化（連接串改成短名稱，IP，賬號和密碼通過短名稱請求服務獲取，同時connction變成私有，表中存儲加密密碼），
3，線上IDC數據庫機器，除DBA，任何人不允許下載文件。
4，跳板機改成堡壘機，記錄使用人使用行爲。
.......
個人感觸：
1，對手比你更瞭解你自己，我都忘記了半年前BI跳板機，沒有見過2個月的web網站機器，每個人都只能知道自己熟悉的機器
黑客基本摸清了我們線上服務器部署，搞清楚BI，數據庫，網站這些機器，比我們還了解我們線上IDC的服務器，
2，精心準備，細節着手
多次準備，不惜下單後，再查詢SQL確認，保證要的數據萬無一失。
3，雖然黑客有點數據庫知識，不精通，但是疏忽了查詢SQL，數字和字符區別，導致查詢慢。