數據庫被刪之反思
一、數據庫為什么會被刪？
同事小L最近負責整理數據庫初始化腳本，在導出演示環境的數據庫腳本后，在另外的服務器上執行該數據庫腳本，最后由于操作的時候打開的窗口過多，沒有注意到環境，當時他打開了很多窗口，有演示環境，也有自己試驗環境，也有開發環境，一堆窗口，最后執行的時候發現執行錯了，將演示環境給干掉了，演示環境有我們大量的數據，主要用于給客戶演示用的，數據非常重要。
二、數據庫被刪后，第一時間采取的措施是什么？
數據庫被刪后，第一時間采取的措施是想辦法恢復，但由于binlog未開啟以及定時備份數據庫腳本也沒有，最后無法恢復，只得經理采取一些措施來解決這個問題了。
三、我的反思以及從中發現存在哪些問題？
雖然說直接責任人并不是我，但我對此也有一定的責任。
這次刪庫事件我發現最大的問題就是數據庫安全策略做的不夠全面。數據庫安全策略包含物理安全、訪問控制、數據備份等。
1.物理安全
物理安全是安全防范的基本，主要是指保證數據庫服務器、數據庫所在環境、相關網絡的物理安全性。
2.訪問控制
訪問控制是基本安全性的核心。它包括了帳號管理、密碼策略、權限控制、用戶認證等方面，主要是從與帳號相關的方面來維護數據庫的安全性。
3.數據備份
定期的進行數據備份是減少數據損失的有效手段，能讓數據庫遭到破壞(惡意或者誤操作)后，恢復數據資源。這也是數據庫安全策略的一個重要部分。
這次問題主要出在訪問控制和數據備份上面。訪問控制沒有做好，導致開發人員人人都能對演示環境(演示環境等同于生產環境)、測試環境、開發環境的數據庫進行庫的CRUD以及庫中的表CRUD等。通常來說，數據庫以及數據庫中的表以及具體字段不能隨意進行添加、刪除、修改等，特別是對于等同于生產環境的演示環境。
訪問控制只是數據庫安全策略的一種手段，但這種手段還需與數據備份相結合，才能稱的上是雙重保障。
四、針對發現的問題我的解決辦法是什么？
針對訪問控制層面，我的解決辦法是:
以演示環境(等同于生產環境)為例， 限制數據庫為內網訪問且對應的用戶只能訪問所授權的數據庫 ，命令如下:
- GRANT ALL PRIVILEGES ON 數據庫名稱.* TO '數據庫特定用戶'@'192.168.52.317' IDENTIFIED BY '數據庫特定用戶密碼' WITH GRANT OPTION;
- FLUSH PRIVILEGES;
- EXIT;
如果其它微服務需要連接該數據庫但又處于不同的服務器環境下，也可通過上面ip進行控制，只不過需要新建對應的用戶。
因為一些需求可能需要公網訪問該數據庫，也可以采取上面的措施進行，目的是為了更精細化的控制權限。
也許有人覺得敲命令來控制似乎很麻煩，別擔心，有一個工具就已經替我們解決了這個問題(數據庫訪問控制)，那就是phpmyadmin。
針對數據備份層面，我的解決辦法是兩個:
第一個， 定期備份 ，腳本自動化備份(需結合定時任務)
第二個， 實時備份 ，從數據庫本身入手，開啟binlog。
在my.conf配置如下即可:
- [mysqld]
- # 開啟binlog
- log-bin=mysql-bin
- server-id=1
- binlog_format=ROW
修改完配置記得重啟mysql。
登錄mysql查看binlog是否開啟，執行如下命令即可:
- show variables like 'log_%';
效果圖如下(說明binlog已開啟):
就目前來說，我已經落地了兩個，一個是實時備份(開啟binlog)，另外一個是定時備份(結合腳本和定時任務)。
五、總結
不經意間想起了歐陽修寫的《五代史伶官傳序》其中有一句我印象很深刻，”夫禍患常積于忽微，而智勇多困于所溺”。在此之前已經就有了一個前車之鑒，一位Java同事的阿里云服務器因數據庫密碼過于簡單被黑客綁架(需要花比特幣才能贖回)，當時針對此我采取了一些措施，但措施并不全面，這次刪庫事件或許就是來自之前的警告。
