数据库的流程，制度，安全优化
MySQL數據庫安全權限控制管理思想
1.1 項目開發制度流程
開發環境à功能測試à壓力測試à阿里云主機上線，通過較為完善的項目開發流程控制，防止很多潛在的問題隱患發生(目前公司只有開發測試直接到生產環境)。
1.2 數據庫更新流程
開發人員提交需求à開發主管審核 àDBA審核à執行開發流程的數據庫更新測試步驟。
最后在阿里云上線執行。需要說明的是在一開始提交需求，就會同時抄給以上人等。
通過較為完善的數據庫更新流程控制，可以防止很多潛在的數據丟失破壞問題發生。
1.3 DBA參與項目數據庫設計
??? 在開發環節上，DBA最好可以參與數據庫的設計與審核，從源頭上減少降低不良設計及語句的發生，如果有可能可以做所有語句的審核工作，包括select，這個需要評估工作量是否允許。
1.4 各種操作申請流程
1)? 開發測試等人員權限申請流程
需要權限直接發郵件并create task到DBA，協商后予以申請權限。
2)? 數據庫更新執行流程
A． 涉及到生產數據庫重大更新，比如訂單取消等，發郵件到技術總監以及DBA，判斷業務是否允許，完成上述數據庫更改。
B． 涉及到生產數據庫小規模變更，比如產品要求做刷單操作，直接發郵件給DBA，抄送技術總監和開發負責人等。
3)? DBA定期巡檢數據庫SQL語句，該優化的SQL提出建議，發郵件給相關開發責任人， 并抄送技術總監。一般提出優化SQL事宜需要1-3個工作日完善，需和開發等協商。
1.5 定期對內部人員培訓
定期給開發及相關人員培訓，還是從源頭上減少降低不良設計及SQL語句的發生，并通過培訓告訴大家數據庫性能的重要性，讓大家提升性能意識。
1)? 數據庫設計規范及制度。
2)? SQL語句執行優化，性能優化技巧等。
3)? 數據庫架構設計等內容。
2.1 內部開發等人員權限分配
1)? 權限申請流程要設置嚴格點，讓需求不明確者知難而退。
2)? 開發和功能測試環境可以開放一些權限，阿里云正式環境嚴格控制數據庫寫權限，并且讀權限和對外業務服務器分離。
3)? 開發人員線上數據庫權限分配，給單獨的不對外服務的正式從庫只讀權限，不能分配線上正式主從庫寫權限。程序賬號授權該庫的SELECT，DML操作。
4)? 如公司領導，開通權限時問清楚做什么，發郵件回復，注明主機IP、用戶名、密碼、權限范圍，多提醒操作注意事項。
5)? 特殊賬號，由DBA專人控制，禁止在任何客戶端上執行特殊賬號操作(如只能localhost或其他策略)。
6)? 臨時在生產庫申請賬號，需要發郵件注明事項，發郵件給DBA。
2.2 Web賬戶權限分配制度
1)? 寫庫賬號默認權限為select，insert，update，delete，不要給建表改表(create，alter)的權限，更不能給all權限。
2)? 讀庫賬號默認權限為select(配合read-only參數用)。一定要確保從庫是只讀的(對所有人員)。
3)? 根據需要，最好專庫專賬號，不要一賬號管理多個庫。碎庫特別多的，根據情況處理。
4)? web和數據庫分離的服務器的授權可以根據web服務器數量多少按IP或網段來授權。
5)? 安全性和方便管理，是矛盾的，要盡量達到一個平衡的狀態，如何使平衡就要根據具體公司和業務來衡量了。
2.3 web賬戶授權實戰案例
GRANT SELECT,INSERT,UPDATE,DELETE ON blog.*TO 'blog'@10.0.0.%' identified by 'TonyS1$521';
說明：這里表示給10.0.0/24的用戶blog管理blog數據庫的所有表(*表示所有庫)只讀權限和DML權限。密碼為TonyS1$521。
GRANT SELECT ON blog.*TO 'blog'@'10.0.0.%'identified by ' TonyS1$521';
當然從庫除了做SELECT 的授權外，還可以加read-only等只讀參數。
2.4 生產環境讀寫分離賬戶設置
給開發人員的讀寫分離用戶設置，除了IP必須要不同外，我們盡量為開發人員使用提供方便。因此，讀寫分離的地址，除了IP不同外，賬號，密碼，端口等看起來都是一樣的，這才是人性化的設計，體現了DBA人員的專業。
??? 主庫（盡量提供寫服務）：blog TonyS1$521 ip:10.0.0.179 port 3306
??? 從庫（今提供讀服務）：? blog TonyS1$521 ip:10.0.0.180 port 3306
??? 提示： 兩個賬號的權限是不一樣的
??? 提示：從數據庫的設計上，對于讀庫，開發人員應該設計優先連接讀庫，如果讀庫沒有，超時后，可以考慮主庫，從程序設計上來保證提升用也要根據主庫的繁忙程度來綜合體驗，具體情況都是根據業務項目需求來抉擇。
3.1 只允許特定IP和賬號使用，要登記清楚。
3.2 限制使用web連接的賬號管理數據庫，根據用戶角色設置指定賬號訪問。
3.3 按開發及相關人員根據職位角色分配管理賬號。
3.4 統一所有數據庫賬號登錄入口地址。禁止所有開發私自上傳等數據庫管理等。
3.5 遠程維護主機和數據庫：開通vpn，跳板機，內部IP等管理數據庫。
4.1 開發環境、生產環境限制或禁止開發人員ssh root 管理，通過sudo細化權限，使用日志審計。
4.2 禁止非管理人員管理有數據庫web client端的服務器的權限。
細則補充：對數據庫的select 等大量測試，統計，備份等操作，要在不對外提供select的單獨從庫執行。因為在主庫上執行有表鎖(如果訪問數據表很大時)。
主從使用規則
5.1 在master上主要操作為DML、DDL和部分SELECT操作‘
5.2 在slave上主要是SELECT查詢操作。
6.1 慢查詢日志分析；白名單機制à上線前審核所有SQL；
6.2 定期檢查數據庫內存使用命中率；
6.3 定期檢查主從復制是否一致；
6.4 定期做好備份恢復測試à檢查數據庫備份文件的有效性；
6.5 定期檢查主從數據庫中數據表設計是否有多余索引；
6.6 定期檢查數據庫鎖情況；
6.7 分析數據庫TPS和QPS情況；
6.8 分析數據庫主機資源使用比率à內存、CPU、磁盤I/O阻塞、網絡等。
轉載于:https://www.cnblogs.com/musings/p/6044102.html
總結
以上是生活随笔為你收集整理的数据库的流程，制度，安全优化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vim总结
- 下一篇： const 内联 枚举 宏