資料庫被刪之反思
一、資料庫為什麼會被刪？
同事小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。
關於Linux配置安裝phpmyadmin，可以參考我寫的如下文章:
Ubuntu16.04下安裝配置phpmyadmin
nginx上配置phpmyadmin
centos7之安裝wordpress（雖然是安裝wordpress，不過這裡用到的是在phpmyadmin里建庫以及添加用戶授權等）
針對數據備份層面，我的解決辦法是兩個:
第一個，定期備份，腳本自動化備份(需結合定時任務)，感興趣的朋友可以閱讀我的這篇文章:mysql常用備份命令和shell備份腳本
，
為防止萬一加一個定期打包備份的sql腳本並遠程傳輸到另外一台伺服器上面，關於遠程壓縮傳輸文件可以參考我的這篇文章:
Linux遠程傳輸文件免密碼
Linux關於壓縮和解壓縮實例
。
第二個，實時備份，從資料庫本身入手，開啟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同事的阿里雲伺服器因資料庫密碼過於簡單被黑客綁架(需要花比特幣才能贖回)，當時針對此我採取了一些措施，但措施並不全面，這次刪庫事件或許就是來自之前的警告。
