摘要：處在局域網之內的，由于有局域網出入口的網絡設備的基本保護，相對于暴露在廣域網中要安全不少，主要威脅對象基本控制在了可以接入局域網的內部潛在威脅者，和極少數能夠突破最外圍防線局域網出入口的安全設備的入侵者。

對于任何一個企業來說，其數據庫系統中所保存數據的安全性無疑是非常重要的，尤其是公司的有些商業數據，可能數據就是公司的根本。

失去了數據，可能就失去了一切

本章將針對mysql的安全相關內容進行較為詳細的介紹。

Mysql的大部分應用場景都是基于網絡環境的，而網絡本身是一個充滿各種入侵危險的環境

所以要保護他的安全，在條件允許的情況下，就應該從最外圍的網絡環境開始布防，因為這一層防線可以從最大范圍內阻止可能存在的威脅。

在網絡環境中，任意兩點之間都可能存在無窮無盡的道路可以抵達，是一條真正“條條道路通羅馬”的環境。

在那許許多多的道路中，只要有一條道路不安全，就可能被入侵者利用。

當然由于所處環境不同，潛在危險的來源也會不一樣。

有些mysql所處環境是暴露在廣域網中，可以說是完全裸露在任何可以接入網絡環境的潛在威脅者面前。

而有些mysql是在一個環境相對小一些的局域網之內，相對來說，潛在威脅者也會少很多。

處在局域網之內的mysql，由于有局域網出入口的網絡設備的基本保護，相對于暴露在廣域網中要安全不少，主要威脅對象基本控制在了可以接入局域網的內部潛在威脅者，和極少數能夠突破最外圍防線（局域網出入口的安全設備）的入侵者。

所以盡可能的讓我們的mysql處在一個有保護的局域網之中，是非常必要的。

有了網絡設備的保護，我們的MySQL就足夠安全了么？我想大家都會給出否定的回答。

因為即使我們局域網出入口的安全設備足夠的強大，可以攔截住外圍試圖入侵的所有威脅者，但如果威脅來自局域網內部呢？

比如局域網中可能存在被控制的設備，某些被控制的有權限接入局域網的設備、以及內部入侵者等都仍然是威脅者。

所以說，即使是在第一層防線之內，我們仍然存在安全風險，局域網內部仍然會有不少的潛在威脅存在。

這個時候就需要我們部署第二層防線“主機層防線”了。

“主機層防線“主要攔截網絡（包括局域網）或者直連的未授權用戶試圖入侵主機的行為。

因為一個惡意入侵者在登陸主機之后，可能通過某些軟件程序竊取到那些自身安全設置不夠健壯的數據庫系統的登陸口令，從而達到竊取或者破壞數據的目的。

如一個主機用戶可以通過一個未刪除且未設置密碼的無用戶名本地賬戶輕易登入數據庫，也可以通過mysql初始安裝好之后就存在的無密碼的“root@localhost”用戶登陸數據庫并獲得數據庫最高控制權限。

非法用戶除了通過登入數據庫獲取或破壞數據之外，還可能通過主機上面相關權限設置的漏洞，跳過數據庫而直接獲取mysql數據（或日志）文件達到竊取數據的目的，或者直接刪除（或者日志）文件達到破壞數據的目的。

通過第二道防線“主機層防線”的把守，我們又可以擋住很大一部分安全威脅者。

但仍然可能有極少數突破防線的入侵者。

而且即使沒有任何“漏網之魚”，那些有主機登入權限的使用者呢？是否真的就是完全可信任對象？No，我們不能輕易冒這個潛在風險。

對于一個有足夠安全意識的管理員來說，是不會輕易放任任何一個潛在風險存在的。

這個時候，我們的第三道防線“數據庫防線”就需要發揮作用了。

“數據庫防線“也就是mysql數據庫系統自身的訪問控制授權管理相關模塊。

這道防線基本上可以說是mysql的最后一道防線了，也是最核心最重要的防線。

他首先需要抵擋住在之前的兩層防線都沒有卒攔住的所有入侵威脅，同時還要能夠限制住擁有之前二層防線自由出入但不具備訪問權限的潛在威脅者，以確保數據庫 自身的安全以及所保存數據的安全。

之前的兩層防線對于所有數據庫系統來說基本上區別不大，都存在者基本相同的各種威脅，不論是Oracle還是mysql，以及其他的數據庫管理系統，都需要基本一致的“布防”策略。

但是這第三層防線，也就是各自自身的“數據庫防線”對于每個數據庫系統來說都存在較大差異，因為每種數據庫都有各自不太一樣的專門負責訪問授權相關的模塊。不論是權限劃分還是實現方式都可能不太一樣。

對mysql來說，其訪問授權相關模塊主要是由兩部分組成。

（1）一個是基本的用戶管理模塊；另一個是訪問授權控制模塊。
（2）用戶管理模塊相對簡單，主要是負責用戶登陸連接相關的基本權限控制，但其在安全控制方面的作用不必任何環節小。
（3）他就像mysql的一個“大門門衛”一樣，通過校驗每一位敲門者所給的進門“暗號”（登入口令），決定是非給敲門者開門。
（4）而訪問控制模塊則是隨時隨地檢查已經進門的訪問者，校驗他們是否有訪問所發出請求需要訪問的數據的權限。
（5）通過校驗者可以順利拿到數據，而未通過校驗的訪問者，只能收到“訪問越權”的相關反饋。

SQL語句相關安全因素：

（1）“SQL注入攻擊”指的就是攻擊者根據數據庫的SQL語句解析器的原理，利用程序中對客戶端所提交數據的校驗漏洞，從而通過程序動態提交數據接口提交非法數據，達到攻擊者的入侵目的。
（2）“SQL注入攻擊“的破壞性非常大，輕者造成數據被竊取，重者數據遭到破壞，甚至可能丟失全部的數據。

程序代碼相關安全因素：

（1）程序代碼如果權限校驗不夠仔細而存在安全漏洞，則同樣可能會被入侵者利用，達到竊取數據等目的。
（2）比如一個存在安全漏洞的信息管理系統，很容易就可能竊取到其他一些系統的登入口令。之后，就能堂而皇之的輕松登陸到其他相關系統達到竊取相關數據的目的。
（3）甚至還可能通過應用系統中保存不善的數據庫系統連接登陸口令，從而帶來更大的損失。

msql的權限系統在實現上比較簡單，相關權限信息主要存儲在幾個被稱為grant tables的系統表中，即：mysql.User，mysql.db，mysql.Host，mysql.table_priv和mysql.column_priv。

由于權限信息數據量比較小，而且訪問比較頻繁，所以mysql在啟動的時候，就會將所有的權限信息都load到內存中保存在幾個特定的結構中。

所以才有了我們每次手工修改了權限相關的表之后，都需要執行“flush privileges”命令重新加載mysql的權限信息。

當然，如果我們通過grant、revoke或者drop user命令來修改相關權限，則不需要手工執行“flush privileges”命令，因為在使用grant等來修改系統表的同時，也會修改內存結構中的權限信息。

在mysql5.0.2或更高版本的時候，mysql還增加了CREATE USER命令，以此創建無任何特別權限（僅擁有初始USAGE權限）的用戶，通過CREATE USER命令創建了新用戶后，新用戶的信息也會自動更新到內存結構中。

所以，建議讀者一般情況下盡量使用GRANT、REVOKE、CREATE USER以及DROP USER命令來進行用戶和權限的變更操作，盡量減少直接修改grant tables來實現用戶和權限變更的操作。

要為某個用戶授權，可以使用GRANT命令，要去除某個用戶已有的權限則使用REVOKE命令。

當然除了這兩個命令之外，還有一種比較暴力的辦法，那就是直接更新grant tables系統表。

當給某個用戶授權的時候，不僅需要指定用戶名，同時還要指定來訪主機。

如果授權的時候僅指定用戶名，則mysql會自動認為是對“username@%”授權。

要去除某個用戶的權限同樣也需要指定來訪主機。

可能有些時候我們還需要查看某個用戶目前擁有的權限，這可以通過兩個方式實現，首先是通過執行“show grants for "username"@"hostname"”命令來獲取之前該用戶身上的所有授權。另一種方法是查詢grant tables里邊的權限信息。

Global Level：

（1）Global Level的權限控制也叫全局權限控制，所有權限信息都保存在mysql.user表中。
（2）Global Level的所有權限都是針對整個mysqld的，對所有的數據庫下的所有表及所有字段都有效。
（3）如果一個權限是以Global Level來授予的，則會覆蓋其他所有級別的相同權限設置。
（4）比如我們首先給abc用戶授權可以update指定數據庫如test的t表，然后又在全局級別REVOKE掉了abc用戶對所有數據庫的所有表的UPDATE權限，那么這時候的abc用戶將不再擁有對test.t表的更新權限。
（5）要授予Global Level的權限，則只需要在執行GRANT命令的時候，用“*.*”來指定適用范圍是Global的即可，當有多個權限需要授予的時候，也并不需要多次重復執行GRANT命令，只需要一次將所有需要的權限名稱通過逗號（“,”）隔開即可，如：GRANT SELECT,UPDATE,DELETE,INSERT ON *.* TO "def"@"localhost"; 

Database Level：

（1）Database Level是在Global Level之下，其他三個Level之上的權限級別，其作用域即為所指定整個數據庫中的所有對象。
（2）與Global Level相比，Database Level主要少了以下幾個權限：CREATE USER、FILE、PROCESS、RELOAD、REPLICATION CLIENT、REPLICATION SLAVE、SHOW DATABASES、SHUTDOWN、SUPER和USAGE這幾個權限，沒有增加任何權限。
（3）之前我們說Global Level的權限會覆蓋底下其他四層的相同權限，Database Level也一樣，雖然他可能被Global Level的權限所覆蓋，但同時他也能覆蓋比他更下層的Table、Column和Routine這三層的權限。
（4）如果要授予Database Level的權限，則可以有兩種實現方式：
    【1】在執行GRANT命令的時候，通過“database.*”來限定權限作用域為database整個數據庫：GRANT ALTER ON test.* TO "def"@"localhost";
    【2】先通過USE命令選定需要授權的數據庫，然后通過“*”來限定作用域，這樣授權的作用域實際上就是當前選定的數據庫
（5）在授予權限的時候，如果有相同的權限需要授予多個用戶，我們也可以在授權語句中一次寫上多個用戶信息，用逗號分隔開就可以了，如：grant  create  on  perf.*  to  "abc"@"localhost","def"@"localhost";

Table Level：

（1）Database Level之下就是Table Level的權限了，Table Level的權限可以被Global Level 和Database Level的權限所覆蓋，同時也能覆蓋Column Level 和Routine Level 的權限。
（2）Table Level 的權限作用范圍是授權語句中所指定數據庫的指定表。如可以通過如下語句給test數據庫的t1表授權：GRANT  INDEX  ON  test.t1  TO "abc"@"%.jianzhaoyang.com"; 
（3）Table Level的權限由于其作用域僅限于某個特定的表，所以權限種類也比較少，僅有ALTER、CREATE、DELETE、DROP、INDEX、INSERT、SELECT、UPDATE這八種權限。

Column Level：

（1）Column Level的權限作用范圍就更小了，僅僅是某個表的指定的某個列。
（2）由于權限覆蓋的原則，Column Level的權限同樣可以被Global、Database、Table這三個級別的權限中的相同級別所覆蓋，而且由于Column Level所針對的權限和Routine Level的權限作用域沒有重合部分，所以不會有覆蓋與被覆蓋的關系。
（3）Column Level的權限只有INSERT、SELECT和UPDATE這三種。
（4）Column Level的權限授權語句語法基本和Table Level差不多，只是需要在權限名稱后面將需要授權的列名列表通過括號括起來：GRANT SELECT(id,value) ON test.t2 TO "abc"@"%.jianzhaoyang.com"; 
（5）當某個用戶在向某個表插入數據的時候，如果該用戶在該表中某列上面沒有INSERT權限，則該列的數據將以默認值填充。這一點和很多其他的數據庫有一些區別，是mysql自己在SQL上面的擴展。

Routine Level：

（1）Routine Level的權限主要只有EXECUTE和ALTER ROUTINE兩種，主要的針對的對象是procedure 和function這兩種對象。
（2）在授予Routine Level權限的時候，需要指定數據庫和相關對象，如：GRANT EXECUTE ON test.p1 to "abc"@"localhost"; 

GRANT權限：

（1）除了上述幾類權限外，還有一個非常特殊的權限GRANT，擁有GRANT權限的用戶可以將自身所擁有的任何權限全部授予其他任何用戶，所以GRANT權限是一個非常特殊也非常重要的權限。
（2）GRANT權限的授予方式也和其他任何權限都不太一樣。
（3）通常是通過在執行GRANT授權語句的時候在最后添加WITH GRANT OPTION子句達到授予GRANT權限的目的。
（4）另外，我們還可以通過GRANT ALL語句授予某個Level的所有可用權限給某個用戶，如： grant all on test.t5 to "abc"; 

以上五個Level的權限中，Table、Column和Routine三者在授權中所依賴（或引用的）對象必須是已經存在的，而不像Database Level的權限授予，可以在當前不存在該數據庫的時候完成授權。

MySQL的訪問控制實際上由兩個功能模塊共同組成，一個是負責“看守mysql大門”的用戶管理模塊，另一個就是負責監控來訪者每一個動作的訪問控制模塊。

用戶管理模塊決定造訪客人能否進門，而訪問控制模塊則決定每個客人進門能拿什么不能拿什么。

mysql中實現簡單訪問控制的流程圖如下：

用戶管理：

（1）在mysql中，用戶訪問控制部分的實現比較簡單，所有授權用戶都存放在一個系統表中：mysql.user，當然這個表不僅存放了授權用戶的基本信息，還存放有部分細化的權限信息。
（2）用戶管理模塊需要使用的信息很少，主要就是Host、User、Password這三項，都在mysql.user表中
（3）一個用戶想要訪問mysql，至少需要提供上面列出的三項數據，mysql才能判斷是否該讓它進門。
（4）這三項實際是由兩部分組成：來訪者來源的主機名（或主機IP地址信息）和訪問者的來訪“暗號”（登陸用戶名和登陸密碼），這兩部分中的任何一個沒有能夠匹配上都無法讓看守大門的用戶管理模塊乖乖開門。
（5）其中Host信息存放的是mysql允許所對應的User的信任主機，可以是某個具體的主機名或域名，也可以是用“%”來充當通配符的某個域名集合，也可以是一個具體的IP地址，同樣也可以是存在通配符的域名集合，還可以用“%”來代表任何主機，就是不對訪問者的主機做任何限制。

訪問控制：

（1）當客戶端連接通過用戶管理模塊的驗證，可連接上mysql server之后，就會發送各種Query和Command給mysql server，以實現客戶端應用的各種功能。
（2）當mysql接收到客戶端的請求之后，訪問控制模塊是需要校驗該用戶是否滿足提交的請求所需要的權限。
（3）權限校驗過程是從最大范圍往最小范圍的權限開始依次校驗所涉及到的每個對象的每個權限。
（4）在驗證所需權限的時候，mysql首先會查找存儲在內存結構中的權限數據，首先查找Global Level權限，如果所需權限在Global Level都有定義（GRANT或REVOKE），則完成權限校驗（通過或者拒絕）；
（5）如果沒有找到所有權限的定義，則會繼續查找Database Level的權限，進行Global Level未定義的所需權限的校驗，如果仍然沒有找到所有所需權限的定義，則會繼續往更小范圍的權限定義域查找，也就是Table Level、Column Level或者Routine Level。
（6）在前面我們了解到mysql的grant tables有mysql.user、mysql.db、mysql.host、mysql.table_priv和mysql.column_priv這五個。
（7）我想除了mysql.host之外的四個都非常容易理解，每一個表都針對mysql的一種邏輯對象，存放某一特定Leve的權限，唯獨mysql.host稍有區別。
（8）我們來看看mysql.host權限表在mysql訪問控制中充當了什么樣的角色？
    【1】mysql.host在mysql訪問控制模塊中所實現的功能比較特殊，和其他幾個grant tables不太一樣。
    【2】首先mysql.host中的權限數據不是通過GRANT或REVOKE來授予或者去除，而是必須手工通過INSESRT、UPDATE和DELETE命令來修改其中的數據。
    【3】其次是其中的權限數據無法多帶帶生效，必須通過和mysql.db權限表的數據一起才能生效。
    【4】而且僅當mysql.db總存在不完整的時候，才會促使訪問控制模塊再結合mysql.host中查找是否有相應的補充權限數據實現以達到權限校驗的目的。
    【5】在mysql.db中無法找到滿足權限校驗的所有條件的數據，則說明在mysql.db中無法完成權限校驗，所以也不會直接校驗db.select_priv的值是否是Y。
（9）mysql的權限授予至少需要用戶名和主機名二者才能確定一個訪問者的權限。
（10）mysql如何確定權限信息？實際上，mysql永遠優先考慮更精確范圍的權限。
（11）在mysql內部會按照username和hostname做一個排序，對于相同username的權限，其host信息越接近訪問者的來源host，則排序位置越靠前，則越早被校驗使用到。
（12）而且mysql在權限校驗過程中，只要找到匹配的權限之后，就不會再繼續往后查找是否還有匹配的權限信息，而直接完成校驗過程。

在我們了解了數據庫系統安全的相關因素和mysql權限系統的工作原理之后，就需要為我們的系統設計一個安全合理的授權策略。

我想，每個人都清楚，想要授權最簡單最簡便方便，維護工作量最少，那自然是將所有權限都授予所有的用戶來的最簡單方便了。

但是，一個用戶所擁有的權限越大，那么他給我們的系統所帶來的潛在威脅也就越大。

所以從安全方面考慮，權限自然是授予的越小越好。一個有足夠安全意識的管理員在授權的時候，都會只授權必要的權限，而不會授予任何多余的權限。

我們從安全的角度來考慮如何設計一個更為安全合理的授權策略。

首先需要了解來訪主機：

（1）由于mysql數據庫登陸驗證用戶的時候是除了用戶名和密碼之外，還要驗證來源主機，所以我們還需要了解每個用戶可能從哪些主機發起連接。
（2）當然，我們也可以通過授權的時候直接通過“%”通配符來給所有主機授予都有訪問的權限，但是這樣就違背了我們安全策略的原則，帶來了潛在風險，所以并不可取。
（3）尤其是在沒有局域網防火墻保護的情況下，更是不能輕易允許可以從任何主機登陸的用戶存在。
（4）能通過具體主機名和IP地址指定的盡量通過使用具體的主機名和IP地址來限定來訪主機，不能用具體的主機名和IP地址限定的也需要用盡可能小的通配范圍來限定。

其次，了解用戶需求：

（1）既然要做到僅授予必要的權限，那么我們必須了解每個用戶所擔當的角色，也就是說，我們充分了解每個用戶需要連接到數據庫上完成什么工作。
（2）了解用戶是一個只讀應用的用戶，還是一個讀寫都有的用戶，是一個備份作業的用戶還是一個日常管理的用戶，是只需要訪問特定的數據庫，還是需要訪問所有的數據庫。
（3）只有了解了需要做什么，才能準確的了解需要授予什么樣的權限。
（4）因為如果權限過低，會造成工作無法正常完成，而權限過高，則存在潛在的安全風險。

再次，要為工作分類：

（1）為了做到各司其職，我們需要將需要做的工作分門別類，不同類別的工作使用不同的用戶，做好用戶分離。
（2）雖然這樣可能會帶來管理成本方面的部分工作量增加，但是基于安全方面的考慮，這部分管理工作量的增加是非常值得的。
（3）而且我們所要做的分離也只是適度的分離。比如將執行備份工作、復制工作、常規應用訪問、只讀應用訪問和日常管理工作分別分理出多帶帶的特定賬戶來授予各自所需權限。
（4）這樣，既可以讓安全風險盡量降低，也可以讓同類同級別的相似權限合并在一起，不互相交織在一起。
（5）對于PROCESS、FILE和SUPER這樣的特殊權限，僅僅只有管理類賬號才需要，不應該授予其他非管理賬號。

最后，確保只有絕對必要者擁有GRANT OPTION權限：

（1）之前在權限系統介紹的時候我們已經了解到GRANT OPTION權限的特殊性，和擁有該權限之后的潛在風險，所以在這里就不贅述了。
（2）總之，為了安全考慮，擁有GRANT OTPION權限的用戶越少越好，盡可能只讓擁有超級權限的用戶才擁有GRANT OPTION權限。

使用私有局域網。我們可以通過使用私有局域網，通過網絡設備，統一私有局域網的出口，并通過網絡防火墻設備控制出口的安全。

使用SSL加密通道。如果我們對數據保密要求非常嚴格，可以啟用mysql提供的ssl訪問接口，將傳輸數據進行加密。使網絡傳輸的數據即使被截獲，也無法輕易使用。

訪問授權限定來訪主機信息。我們可以在授權的時候，通過指定主機的主機名、域名或IP地址信息來限定來訪主機的范圍。

OS安全方面。關閉mysql Server主機上面任何不需要的服務，這不僅能從安全方面減少潛在隱患，還能減少主機的部分負擔，盡可能提高性能。

使用網絡掃描工具（如nmap等）掃描主機端口，檢查除了mysql需要監聽的端口3306之外，還有哪些端口是打開正在監聽的，并去不必要的端口。

嚴格控制OS賬號的管理，以防賬號信息外泄，尤其是root和mysql賬號。

對root和mysql等對mysql的相關文件有特殊操作權限的OS賬號登陸后做出比較顯眼的提示，并在Terminal的提示信息中輸出當前用戶信息，以防止操作的時候經過多次用戶切換后出現人為誤操作。

用非root用戶運行mysql。因為如果使用root運行mysql，那么myslqd的進程就會擁有root用戶所擁有的權限，任何具有FILE權限的用戶就可以在mysql中向系統中的任何位置寫入文件。

文件和進程安全。合理設置文件的權限屬性，mysql的相關數據和日志和所在文件夾屬主和所屬組都設置為mysql，且禁用其他所有用戶的讀寫權限。以防止數據或者日志文件被竊取或破壞。

確保mysql server所在的主機上所必要運行的其他應用或服務足夠安全，避免因為其他應用或者服務存在安全漏洞而被入侵者攻破防線。

用戶設置。我們必須確保任何可以訪問數據庫的用戶都有一個比較復雜的內容作為密碼，而不是非常簡單或者比較有規律的字符，以防止被使用字典破解程序攻破。

在 MySQL初始安裝完成之后，系統中可能存在一個不需要任何密碼的root用戶，有些版本安裝完成之后還會存在一個可以通過localhost登錄的沒有用戶名和密碼的帳號。這些帳號會給系統帶來極大的安全隱患，所以我們必須在正式啟用之前盡早刪除，或者設置一個比較安全的密碼。

對于密碼數據的存放，也不要存放在簡單的文本文件之中，而應該使用專業密碼管理軟件來管理（如KeePass）。

安全參數。不需要使用的功能模塊盡量都不要啟用。例如，如果不需要使用用戶自定義函數，就不要在啟動的時候使用“--allow-suspicious-udfs”參數選項，以防止被別有居心的潛在威脅者利用此功能而對MySQL的安全造成威脅；

不需要從本地文件中Load數據到數據庫中，就使用“--local-infile=0”禁用掉可以從客戶端機器上Load文件到數據庫中

https://www.cnblogs.com/jesse...