MySQL8.0新加了不少功能,其中在用戶管理中增長了角色的管理,默認的密碼加密方式也作了調整,由以前的sha1改成了sha2,同時加上5.7的禁用用戶和用戶過時的設置,這樣方面用戶的管理和權限的管理,也增長了用戶的安全性。MySQL8.0中,mysql庫中表的文件合併到數據根目錄中的mysql.ibd中(MySQL8.0 Innodb引擎重構)。同時MySQL8.0可使用SET PERSIST動態修改參數並保存在配置文件中(mysqld-auto.cnf,保存的格式爲JSON串),這個是DBA同窗的福音,沒必要擔憂設置以後忘記保存在配置文件中重啓以後又被還原的問題了。查閱了MySQL8.0的官方文檔,經過官方的示例來查看新的管理方式。
mysql
在MySQL 8.0中,caching_sha2_password是默認的身份驗證插件而不是以前版本的mysql_native_password,默認的密碼加密方式是sha2。若是須要保持以前的驗證方式並保持以前版本的密碼加密方式須要在配置文件中修改,暫不支持動態修改,須要重啓生效:default_authentication_plugin = mysql_native_password。
將8.0已有的sha2密碼修改成sha1的模式:
ALTER USER 'root'@'127.0.0.1' IDENTIFIED BY 'passowrd' PASSWORD EXPIRE NEVER; #修改加密規則爲永不過時
ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'password'; #更新一下用戶的密碼加密方式爲以前版本的方式
FLUSH PRIVILEGES; #刷新權限sql
MySQL8.0的用戶受權和以前有所區別,老版本的經常使用受權語句在8.0中會報錯:數據庫
MySQL8.0以前版本:
GRANT ALL ON . TO wangwei
@127.0.0.1
IDENTIFIED BY 'passowrd' WITH GRANT OPTION;
MySQL8.0版本:
CREATE USER wangwei
@127.0.0.1
IDENTIFIED BY 'passowrd';
GRANT ALL ON . TO wangwei
@127.0.0.1
WITH GRANT OPTION;
MySQL8.0中帶過時時間用戶的建立:
CREATE USER wangwei
@127.0.0.1
IDENTIFIED BY 'wangwei' PASSWORD EXPIRE INTERVAL 90 DAY;
GRANT ALL ON . TO wangwei
@127.0.0.1
WITH GRANT OPTION;
MySQL8.0修改用戶密碼:
ALTER USER 'wangwei'@'127.0.0.1' IDENTIFIED BY 'wangwei';安全
要全局創建自動密碼到期策略,請使用default_password_lifetime系統變量。其默認值爲0,禁用自動密碼過時。若是值default_password_lifetime正整數N,則表示容許的密碼生存期,以便密碼必須天天更改N。能夠加在配置文件中:
1:要創建全局策略,密碼的使用期限大約爲六個月,請在服務器my.cnf文件中使用如下行啓動服務器:
[mysqld]
default_password_lifetime=180
2:要創建全局策略,以便密碼永不過時,請將其設置default_password_lifetime爲0:
[mysqld]
default_password_lifetime=0
這個參數是能夠動態設置並保存的:
SET PERSIST default_password_lifetime = 180;
SET PERSIST default_password_lifetime = 0;
建立和修改帶有密碼過時的用戶,賬戶特定的到期時間設置示例:
要求每90天更換密碼:
CREATE USER 'wangwei'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
ALTER USER 'wangwei'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
禁用密碼過時:
CREATE USER ' wangwei'@'localhost' PASSWORD EXPIRE NEVER;
ALTER USER 'wangwei'@'localhost' PASSWORD EXPIRE NEVER;
遵循全局到期政策:
CREATE USER 'wangwei'@'localhost' PASSWORD EXPIRE DEFAULT;
ALTER USER 'wangwei'@'localhost' PASSWORD EXPIRE DEFAULT;服務器
MySQL容許限制重複使用之前的密碼。能夠根據密碼更改次數、已用時間或二者來創建重用限制。賬戶的密碼歷史由過去分配的密碼組成。MySQL能夠限制今後歷史記錄中選擇新密碼:
1:若是根據密碼更改次數限制賬戶,則沒法從指定數量的最新密碼中選擇新密碼。例如,若是密碼更改的最小數量設置爲3,則新密碼不能與任何最近的3個密碼相同。
2:若是賬戶因時間的限制而被限制,則沒法從歷史記錄中的新密碼中選擇新密碼,該新密碼不會超過指定的天數。例如,若是密碼重用間隔設置爲60,則新密碼不得在最近60天內選擇的密碼之間。
注意:空密碼不記錄在密碼歷史記錄中,並隨時能夠重複使用。
要全局創建密碼重用策略,請使用password_history和password_reuse_interval系統變量。要在服務器啓動時指定變量值,請在服務器my.cnf文件中定義它們。
示例:
要禁止重複使用最近6個密碼或密碼超過365天的任何密碼,請將這些行放入您的服務器 my.cnf文件中:
[mysqld]
password_history=6
password_reuse_interval=365
要動態設置和保存配置,請使用以下所示的語句:
SET PERSIST password_history = 6;
SET PERSIST password_reuse_interval = 365;app
MySQL角色是指定的權限集合。像用戶賬戶同樣,角色能夠擁有授予和撤消的權限。能夠授予用戶賬戶角色,授予該賬戶與每一個角色相關的權限。用戶被授予角色權限,則該用戶擁有該角色的權限。
如下列表總結了MySQL提供的角色管理功能:
CREATE ROLE並 DROP ROLE角色建立和刪除。
GRANT並 REVOKE爲用戶和角色分配和撤銷權限。
SHOW GRANTS 顯示用戶和角色的權限和角色分配。
SET DEFAULT ROLE 指定哪些賬戶角色默認處於活動狀態。
SET ROLE 更改當前會話中的活動角色。
CURRENT_ROLE()功能顯示當前會話中的活動角色。運維
考慮以下幾種場景:
應用程序使用名爲app_db的數據庫 。
與應用程序相關聯,能夠爲建立和維護應用程序的開發人員以及管理員帳戶。
開發人員須要徹底訪問數據庫。有的用戶只須要讀取權限,有的用戶須要讀取/寫入權限。
爲清楚區分角色的權限,將角色建立爲所需權限集的名稱。經過受權適當的角色,能夠輕鬆地爲用戶賬戶授予所需的權限。
要建立角色,請使用CREATE ROLE:
CREATE ROLE 'app_developer', 'app_read', 'app_write';
角色名稱與用戶賬戶名稱很是類似,由格式中的用戶部分和主機部分組成。主機部分,若是省略,則默認爲%。用戶和主機部分能夠不加引號,除非它們包含特殊字符。與賬戶名稱不一樣,角色名稱的用戶部分不能爲空。爲角色分配權限,使用與爲用戶分配權限相同的語法執行:
GRANT ALL ON app_db. TO 'app_developer';
GRANT SELECT ON app_db. TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';
如今假設您最初須要一個開發人員賬戶,兩個須要只讀訪問權的用戶以及一個須要讀取/寫入權限的用戶。使用CREATEUSER建立用戶:
CREATE USER 'dev1'@'localhost' IDENTIFIED BY 'dev1pass';
CREATE USER 'read_user1'@'localhost' IDENTIFIED BY 'read_user1pass';
CREATE USER 'read_user2'@'localhost' IDENTIFIED BY 'read_user2pass';
CREATE USER 'rw_user1'@'localhost' IDENTIFIED BY 'rw_user1pass';
要爲每一個用戶分配其所需的權限,可使用GRANT與剛纔顯示的形式相同的語句,但這須要列舉每一個用戶的我的權限。相反,使用GRANT容許受權角色而非權限的替代語法:
GRANT 'app_developer' TO 'dev1'@'localhost';
GRANT 'app_read' TO 'read_user1'@'localhost', 'read_user2'@'localhost';
GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost';
結合角色所需的讀取和寫入權限,在GRANT中受權 rw_user1用戶讀取和寫入的角色。
在GRANT受權角色的語法和受權用戶的語法不一樣:有一個ON來區分角色和用戶的受權,有ON的爲用戶受權,而沒有ON用來分配角色。因爲語法不一樣,所以不能在同一語句中混合分配用戶權限和角色。(容許爲用戶分配權限和角色,但必須使用單獨的GRANT語句,每種語句的語法都要與受權的內容相匹配。)ide
要驗證分配給用戶的權限,使用 SHOW GRANTS。例如:
mysql> SHOW GRANTS FOR 'dev1'@'localhost';
+-------------------------------------------------+
| Grants for dev1@localhost |
+-------------------------------------------------+
| GRANT USAGE ON . TO dev1
@localhost
|
| GRANT app_developer
@%
TO dev1
@localhost
|
+-------------------------------------------------+
ß可是,它會顯示每一個授予的角色,而不會將其顯示爲角色所表明的權限。若是要顯示角色權限,添加一個 USING來顯示:
mysql> SHOW GRANTS FOR 'dev1'@'localhost' USING 'app_developer';
+----------------------------------------------------------+
| Grants for dev1@localhost |
+----------------------------------------------------------+
| GRANT USAGE ON . TO dev1
@localhost
|
| GRANT ALL PRIVILEGES ON app_db
. TO dev1
@localhost
|
| GRANT app_developer
@%
TO dev1
@localhost
|
+----------------------------------------------------------+
一樣驗證其餘類型的用戶:
mysql> SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read';
+--------------------------------------------------------+
| Grants for read_user1@localhost |
+--------------------------------------------------------+
| GRANT USAGE ON . TO read_user1
@localhost
|
| GRANT SELECT ON app_db
. TO read_user1
@localhost
|
| GRANT app_read
@%
TO read_user1
@localhost
|
+--------------------------------------------------------+
mysql> SHOW GRANTS FOR 'rw_user1'@'localhost' USING 'app_read', 'app_write';
+------------------------------------------------------------------------------+
| Grants for rw_user1@localhost |
+------------------------------------------------------------------------------+
| GRANT USAGE ON . TO rw_user1
@localhost
|
| GRANT SELECT, INSERT, UPDATE, DELETE ON app_db
.* TO rw_user1
@localhost
|
| GRANT app_read
@%
,app_write
@%
TO rw_user1
@localhost
|
+------------------------------------------------------------------------------+學習
正如能夠受權某個用戶的角色同樣,能夠從賬戶中撤銷這些角色:
REVOKE role FROM user;
REVOKE能夠用於角色修改角色權限。這不只影響角色自己權限,還影響任何授予該角色的用戶權限。假設想臨時讓全部用戶只讀,使用REVOKE從該app_write角色中撤消修改權限 :
REVOKE INSERT, UPDATE, DELETE ON app_db. FROM 'app_write';
碰巧,某個角色徹底沒有任何權限,正如能夠看到的那樣SHOW GRANTS (這個語句能夠和角色一塊兒使用,而不只僅是查詢用戶權限可用):
mysql> SHOW GRANTS FOR 'app_write';
+---------------------------------------+
| Grants for app_write@% |
+---------------------------------------+
| GRANT USAGE ON . TO app_write
@%
|
+---------------------------------------+
從角色中撤銷權限會影響到該角色中任何用戶的權限,所以 rw_user1如今已經沒有表修改權限(INSERT, UPDATE,和 DELETE權限已經沒有了):
mysql> SHOW GRANTS FOR 'rw_user1'@'localhost'
USING 'app_read', 'app_write';
+----------------------------------------------------------------+
| Grants for rw_user1@localhost |
+----------------------------------------------------------------+
| GRANT USAGE ON . TO rw_user1
@localhost
|
| GRANT SELECT ON app_db
. TO rw_user1
@localhost
|
| GRANT app_read
@%
,app_write
@%
TO rw_user1
@localhost
|
+----------------------------------------------------------------+
實際上,rw_user1讀/寫用戶已成爲只讀用戶。對於被授予app_write角色的任何其餘用戶也會發生這種狀況,說明修改使用角色而沒必要修改我的賬戶的權限。
要恢復角色的修改權限,只需從新授予它們便可:
GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';
如今rw_user1再次具備修改權限,就像受權該app_write角色的其餘任何賬戶同樣。測試
要刪除角色,請使用DROP ROLE:DROP ROLE 'app_read', 'app_write';刪除角色會從受權它的每一個賬戶中撤消該角色。2.五、角色和用戶在實際中的應用假設遺留應用開發項目在MySQL中的角色出現以前開始,所以與該項目相關聯的全部用戶都是直接授予權限(而不是授予角色權限)。其中一個賬戶是最初被授予權限的開發者用戶,以下所示:CREATE USER 'old_app_dev'@'localhost' IDENTIFIED BY 'old_app_devpass';GRANT ALL ON old_app.* TO 'old_app_dev'@'localhost';若是此開發人員離開項目,則有必要將權限分配給其餘用戶,或者項目參與人增多,則可能須要多個用戶。如下是解決該問題的一些方法: 不使用角色:更改賬戶密碼,以便原始開發人員不能使用它,並讓新的開發人員使用該賬戶:ALTER USER 'old_app_dev'@'localhost' IDENTIFIED BY 'new_password'; 使用角色:鎖定賬戶以防止任何人使用它來鏈接服務器:ALTER USER 'old_app_dev'@'localhost' ACCOUNT LOCK;而後將該賬戶視爲角色。對於每一個新開發項目的開發者,建立一個新賬戶並授予其原始開發者賬戶:CREATE USER 'new_app_dev1'@'localhost' IDENTIFIED BY 'new_password';GRANT 'old_app_dev'@'localhost' TO 'new_app_dev1'@'localhost';其效果是將原始開發者賬戶權限分配給新賬戶。MySQL8.0的用戶和角色管理也愈來愈像Oracle了,8.0中有很多新的特性,變化仍是很大的,須要DBA不斷的學習和測試,更新對MySQL新版的認知,更好地運維MySQL數據庫。將來MySQL數據庫自治和智能數據庫是必然發展趨勢,對DBA來講是解放,也是挑戰。同時也很是感謝好友知名MySQL數據庫專家吳炳錫老師在百忙中抽空對本文進行校對。