MySQL安全策略(MySQL安全注意事項)
導讀
MySQL被運用于越來越多的業(yè)務中,在關鍵業(yè)務中對數據安全性的要求也更高,如何保證MySQL的數據安全?
數據安全如果只靠MySQL應用層面顯然是不夠的,是需要在多個層面來保護的,包括網絡、系統、邏輯應用層、數據庫層等。
下面是我們可借鑒的一些安全策略。
1、網絡、系統層面
在這個層面可以做很多的事情,我們可以把這些安全要求作為新系統安裝時的標準要求,放到自動化裝機方案中。
把運行MySQL的服務器放在內網中,不要啟用公網;
迫不得已啟用公網的話,修改sshd端口到10000以上;
設置防火墻策略,只允許信任的服務器連接sshd和MySQL端口;
修改idrac/imm密碼,設置GRUB密碼;
設置密碼安全策略,比如要求 PASS_MIN_LEN 不低于8位,其實最好是直接用一個復雜密碼做MD5之后再作為正式密碼,32位長度的安全程度夠高吧;
將操作日志記入syslog并且發(fā)送到遠程log server上,堅決不能只存儲在本地;
除了必須的賬號,其他的都設為無登入權限;
盡量把運行MySQL的服務器獨立出來,不要和web server、app server放一起。必須放一起的話,也要設置好權限分離,不允許web server、app server進程的屬主有直接訪問MySQL datadir的權限;
禁用web server層的autoindex配置;
可能的話,采用https代替http;
關鍵應用保持更新,避免老版本的漏洞風險;
設置nginx、php等應用服務的安全策略,禁用危險函數等;
可以考慮購買運營商提供的一些安全防護、掃描器等產品;
堅決杜絕二逼行為,把關鍵配置文件上傳到公共網絡上(如把公司項目代碼放在github上作為個人項目,內含內網賬號密碼信息)。
2、邏輯應用層
在這個層面,等多的是依賴運營及開發(fā)人員的安全意識,很多本可以避免的低級安全漏洞完全可以在這個層面處理掉,比如下面提到的XSS、CSRF、SQL注入等漏洞。
盡量不要在公網上使用開源的cms、blog、論壇等系統,除非做過代碼安全審計,或者事先做好安全策略。這類系統一般都是黑客重點研究對象,很容易被搞;
在web server層,可以用一些安全模塊,比如nginx的WAF模塊;
在app server層,可以做好代碼安全審計、安全掃描,防止XSS攻擊、CSRF攻擊、SQL注入、文件上傳攻擊、繞過cookie檢測等安全漏洞;
應用程序中涉及賬號密碼的地方例如JDBC連接串配置,盡量把明文密碼采用加密方式存儲,再利用內部私有的解密工具進行反解密后再使用?;蛘呖梢宰寫贸绦蛳扔弥虚g賬號連接proxy層,再由proxy連接MySQL,避免應用層直連MySQL;
應用層啟用關鍵日志記錄,例如交易日志,方便后續(xù)對賬什么的。
3、MySQL數據庫層
前面幾層如果都做的不夠安全的話,在這層也幾乎是岌岌可危了。但我們依然可以做些事情的。
啟用 safe-update 選項,避免沒有 WHERE 條件的全表數據被修改;
將 binlog 的保存周期加長,便于后續(xù)的審計、審查;
應用賬號只賦予SELECT、UPDATE、INSERT權限,取消DELETE權限。把需要DELETE權限的邏輯改成用UPDATE實現,避免被物理刪除;
需要真正刪除時,交由DBA先備份后再物理刪除;
可以采用Percona的SQL審計插件,據說還有macfee的插件;
還可以采用觸發(fā)器來做一些輔助功能,比如防止黑客惡意篡改數據。
4、后記
數據安全可以做的事情很多,本文也只是羅列了一些比較簡單可快速實施的方案。每個企業(yè)應有自己的安全策略規(guī)范,每一位參與者都應該心懷敬畏,努力遵守這些必要的規(guī)范,不使信息安全成為空談。
真正的數據安全,是靠所有人的意識安全作為支撐的,沒有這個意識靠機制、制度、工具都是不靠譜。于
相關文章
MySQL下使用Inplace和Online方式創(chuàng)建索引的教程
這篇文章主要介紹了MySQL下使用Inplace和Online方式創(chuàng)建索引的教程,針對InnoDB為存儲引擎的情況,需要的朋友可以參考下2015-11-11解決Navicat遠程連接MySQL出現 10060 unknow error的方法
這篇文章主要介紹了解決Navicat遠程連接MySQL出現 10060 unknow error的方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2019-12-12