【MySQL 8.0 OCP 1Z0-908认证考试】题库精讲--第四讲mysql8.0权限安全审计(下)

此专题题目较多，因此分为上下两部分来讲，此为下篇。

 完整版题库请到我的资源中下载，此为传送门。https://download.csdn.net/download/kanon_lgt/85010419?spm=1001.2014.3001.5503

---

第一题

讲解：

• 此题考查的是mysql账户创建相关的知识点

• 在mysql8中，创建user默认是unlock状态，即使在创建的时候使用with_no_login限制，此新账户也是unlock的，只是不能登录而已。
• 在mysql8中，新创建role默认是lock状态，需要unlock解锁才能使用。
• 在mysql8中，系统内部用户是lock状态的，比如mysql.sys/mysql.session/mysql.infoschema。

解锁语句为：

ALTER USER username@hostname ACCOUNT UNLOCK; -- ROLE解锁也是这个语句

看选项：

选项AC符合以上内容，

因此，选项AC正确。

---

第二题：

讲解：

• 此题考查的是MySQL Enterprise Firewall知识点

与上篇第十一题属于同一考查范围，结合上篇第十一题。

MySQL Enterprise Firewall只有Enterprise企业版才有的功能，它是一个插件式功能模块(Plugin)，严格来说，它是一个应用程序(application-level)，运行于mysql之上。

安装它后，提供如下功能：

• 当在RECORDING模式时它可以对用户发出的SQL Statement进行学习，并生成一个允许执行的SQL Statement List(allowlist)，
• 当在PROTECTING模式时它可以根据allowlist来审核SQL Statement，以决定拒绝执行还是允许执行。
• 当在DETECTING模式时它可以根据allowlist来记录可疑SQL Statement，但会允许执行。

allowlist、users对应的表是mysql.firewall_whitelist和mysql.firewall_users，它们是持久化存储的表，但是为了firewall的运行性能，这些表的数据被加载到内存(in-memory)中，并有information_schema和performance_schema中的视图来提供查询接口。

看选项：

选项A，Firewall只在企业版提供。正确。

选项B，windows平台的Firewall是通过windows的Firewall控制台来管理的。错误。

选项C，它提供information_schema中的视图供用户查看firewall 数据。正确。

选项D，firewall_users和firewall_whitelist持久化存储在mysql库中。正确。

选项E，它只显示被它阻止的connection提醒信息。错误，它不针对connection，只针对SQL Statement。

选项F，Firewall功能依赖于sha256和ANSI-specific。错误，它与此无关，是基于规则，不是基于加密。说白了，它是一个应用程序而已。

因此，选项ACD正确。

---

第三题

讲解：

• 此题考查的是mysql安全中的账户安全

创建一个mysql账户，要最大限度的增加其安全性，降低其风险性，需要从以下方面着手：

• 不要在hostname段使用通配符，比如'laoge'@'%'，或者'laoge'@'192.168.11.%'，这种账户可以从任何客户端登录到服务器。
• 强制要求账户使用加密登录，--ssl-mode=required
• 精准控制账户权限
• 密码复杂度设置
• 使用mysql_config_editor加密存储账户密码

看选项：

选项A，避免使用通配符主机名。正确。

选项B，避免使用通配符账户名。错误。mysql账户名要么是与名字精准匹配的字符串，要么是与任何账户都能匹配的空账户名('')，不存在包含通配符的账户名。比如l‘aog%’这种是不存在的。

选项C，要求使用混合大小写的账户名。这没有意义，用户名的复杂度不会影响账户的安全性。

选项D，不要使用空密码。正确。

选项E，要求用户配置到Firewall Users中。错误，这只对它执行的SQL起到审核作用，不是对账户安全的管理。

因此，选项AD正确。

---

第四题

讲解：

• 此题考查的是安全中的网络安全

看题目中描述：

• 你有一个私网，并且有一套自有的级别很高的CA证书系统，
• 所有的mysql server都被这套CA证书签名，
• 所有的客户端都被严格控制在这个私网内，
• 这个私网有自己的DNS，
• 这个私网还使用了一点其它的企业级服务，
• mysql客户端到服务器的端到端的加密连接也已经建立好了。

问你，mysql server使用的这套自签名(self-signed)的CA系统与第三方的公有企业级CA系统相比怎么样？

理论上来讲，这么一个小局域网内的与外界隔离的完整生态系统，在安全性和可信性上是不比第三方的CA系统认证的差的，反倒会更安全一些。

说实话，这个题目我也不是绝对确定正确选项，我倾向于选E。

如果有朋友还有其它意见，欢迎留言讨论。

---

第五题

讲解：

• 此题考查的是MySQL Enterprise Firewall的知识点

如本篇第二题所讲的MySQL Enterprise Firewall的基础理论，Firewall有4种状态，Firewall在4种状态间切换。

那么它的状态是如何实现切换的呢？

MySQL是通过在安装Firewall的时候创建的一系列存储过程来实现Firewall的状态切换的：

CALL mysql.sp_set_firewall_group_mode('fwgrp', 'RECORDING'); --创建1个fwgrp组的profile，并将firewall切换为记录模式(训练);
CALL mysql.sp_firewall_group_enlist('fwgrp', 'member1@localhost'); --给fwgrp组添加1个mysql账户member1@localhost,那么firewall将开始记录这个账户下的sql语句，并抽象出sql模型，得到一个可执行的sql的集合，成为allowlist或者whitelist；
CALL mysql.sp_set_firewall_group_mode('fwgrp', 'PROTECTING'); --切换到保护模式，此时firewall将根据whitelist来审核sql语句，符合whitelist种sql模型的sql可以执行，否则将被拒绝执行；
CALL mysql.sp_firewall_group_enlist('fwgrp', 'member2@localhost');--还可以给fwgrp再添加一些mysql账户，对这些账户发出的sql也执行审核；
CALL mysql.sp_firewall_group_delist('fwgrp', 'member2@localhost');--这是将member2@localhost从fwgrp组中删除，以后不再对它发出的sql进行审核；
CALL mysql.sp_set_firewall_group_mode('fwgrp', 'DETECTING'); --将firewall切换为DETECTING模式，对所有不符合whitelist中sql模型的sql语句都允许执行，但是会被记录下来；
CALL mysql.sp_set_firewall_group_mode('fwgrp', 'OFF'); --关闭fwgrp组的firewall，恢复到任意执行sql模式，但是fwgrp这个group和训练得到的whitelist不会丢失；
CALL mysql.sp_set_firewall_group_mode('fwgrp', 'ON'); --再次启用fwgrp的firewall；
CALL mysql.sp_set_firewall_group_mode('fwgrp', 'RESET'); --删除fwgrp这个group里的whitelist，并关闭这个group的；fwgrp还在，但它的whitelist规则已经为空，且它的模式是OFF；

看题目：

首先，题目中给出fwuser@localhost这个账户目前被注册到Firewall中，并且Firewall状态是PROTECTING保护模式。

其次，题目中给出fwuser@localhost这个账户目前所在的group已经有1个whitelist，它里面有一些训练得到的sql。

最后，题目执行了1个存储过程，CALL mysql.sp_set_firewall_group_mode('fwgrp', 'RESET');

问你，会发生什么？

结合上面讲到的firewall状态切换的命令，RESET会清空对应group的whitelist，并将这个group的模式设置为OFF；

看选项：

选项A， fwuser@localhost这个账户将被从mysql.user中移除。错误。它不会删除账户。

选项B，information_schema.mysql_firewall_whitelist会被truncate。错误。这个表不会被truncate，因为这个表里还保存有其它账户的whitelist。

选项C，fwuser@locahost的whitelist被truncate。正确。

选项D，mysql.firewall_users表被truncate。错误。这里面有各个被纳入firewall的users，不会truncate。

选项E，firewall将所有设置和选项都重置为默认值。错误。除了此账户的，其它账户或者组都不会被改变。

选项F，fwuser@localhost账户的模式被设置为DETECTING。错误。

选项G，fwuser@localhost账户的模式被设置为OFF。正确。

因此，选项CG正确。

---

第六题

讲解：

• 此题考查的是安全中的数据安全

没什么可解释的，直接看选项：

选项A，配置mysqld以系统管理员账户运行，比如root。错误。mysqld应该避免使用root账户启动。

选项B，使用一个隐藏在firewall后的私有网络。正确。mysql不应该对公网暴露。

选项C，配置mysqld只使用网络硬盘。错误。

选项D，配置mysql只有一个管理员账户。正确。对账户进行严格控制。

选项E，配置mysqld只使用本地磁盘或者附加磁盘并且让它自己的账户在系统中存在。错误。

因此，选项BD正确。

---

第七题

讲解：

• 此题考查的是MySQL Enterprise Firewall知识点

参考本讲的第二题

直接看选项：

选项A，对进来的SQL Statement进行记录并助力生成一个允许执行的SQL 命令白名单。正确。

选项B， 根据预先配置的白名单阻止一些潜在的威胁。正确。

选项C，动态修改SQL Statement。错误。Firewall不做修改，只做审查。

选项D，自动锁定破坏防火墙的账户。错误。Firewall不做修改，只做审查。

选项E，提供访问TCP/3306的无状态防火墙。错误。跟TCP306毫无关系。

因此，选项AB正确。

---

第八题

讲解：

• 此题考查的是安全中的mysql连接加密

mysql 的client和server之间连接是可以进行加密的，比如x509，甚至可以进行数字证书认证。

你看到的$DATADIR目录下的server-cert.pem、server-key.pem、client-cert.pem、client-key.pem、private-key.pem、public-key.pem等，都是用来进行加密与认证的。

mysql server默认是以--ssl模式启动，也就是说它支持并允许连接加密，但是不强制。

当你创建一个账户时，没有指定这个账户是否需要加密(create user没有加REQUIRED子句)，那么它就可以不加密连接到服务器。

客户端向服务器发起连接请求时，可以指定4种加密设置等级，分别为：

• DISABLED--客户端不发起加密连接
• PREFERRED--客户端发起加密连接，如果服务器端不能建立加密则自动降级为不加密连接
• REQUIRED--客户端发起加密连接，如果服务器端不能建立加密则连接失败
• VERIFY_CA--客户端发起加密连接，且要求CA证书认证，如果服务器端不能建立加密则连接失败。(在REQUIRED上更进一级)
• VERIFY_IDENTITY--客户端发起加密连接，且要求CA证书认证和客户端服务器主机名一致性认证，如果服务器端不能建立加密则连接失败。(在VERIFY_CA上更进一级)

为了让客户端与服务器端连接安全等级最高，应该如下设置：

1、服务器端：

• 服务器创建用户要求加密(CREATE USER增加REQUIRED子句)：

CREATE USER 'laoge'@'localhost' identified by 'LaoGeDB123!'  REQUIRE X509;

• 服务器端开启强制加密(require_secure_transport=ON)：

[mysqld]
ssl_ca=ca.pem
ssl_cert=server-cert.pem
ssl_key=server-key.pem
require_secure_transport=ON

2、客户端：

客户端发起连接请求增加--ssl-mode参数，这个参数有5个值可以选，分别举例如下：

• DISABLED不加密连接会报错：

[root@light log]# mysql -ulaoge -p -h192.168.11.211 --ssl-mode=disabled
WARNING: no verification of server certificate will be done. Use --ssl-mode=VERIFY_CA or VERIFY_IDENTITY.
Enter password:
ERROR 1045 (28000): Access denied for user 'laoge'@'localhost' (using password: YES)

•  PREFERRED按需加密连接同样会报错,因为服务器端强制要求加密，而客户端没有提供加密key，则会降级为不加密连接，降级为disabled。这也是默认设置：

[root@light log]# mysql -ulaoge -p -h192.168.11.211 --ssl-mode=preferred
WARNING: no verification of server certificate will be done. Use --ssl-mode=VERIFY_CA or VERIFY_IDENTITY.
Enter password:
ERROR 1045 (28000): Access denied for user 'laoge'@'localhost' (using password: YES)

• REQUIRED需要加密连接但是依然会报错，因为客户端没有提供加密key：

[root@light log]# mysql -ulaoge -p -h192.168.11.211 --ssl-mode=required
WARNING: no verification of server certificate will be done. Use --ssl-mode=VERIFY_CA or VERIFY_IDENTITY.
Enter password:
ERROR 1045 (28000): Access denied for user 'laoge'@'localhost' (using password: YES)

• VERIFY_CA需要加密并提供加密key，且提供CA证书连接，连接成功。

连接时需要提供如下参数：

• --ssl-ca
• --ssl-cert
• --ssl-key

[root@light log]# mysql -ulaoge -p -h192.168.11.211 --ssl-ca=/data/mysql/data/ca.pem --ssl-cert=/data/mysql/data/client-cert.pem --ssl-key=/data/mysql/data/client-key.pem --ssl-mode=VERIFY_CA
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 30
Server version: 8.0.28 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

• VERIFY_IDENTITY需要加密并提供加密key，且提供CA证书连接，并要求对客户端与服务器端主机名进行验证。连接失败。

需要提供如下参数：

• --ssl-ca
• --ssl-cert
• --ssl-key

[root@light log]# mysql -ulaoge -p -h192.168.11.211 --ssl-ca=/data/mysql/data/ca.pem --ssl-cert=/data/mysql/data/client-cert.pem --ssl-key=/data/mysql/data/client-key.pem --ssl-mode=VERIFY_IDENTITY
Enter password:
ERROR 2026 (HY000): SSL connection error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

是不是很奇怪，为什么会失败呢？按理说这个应该更安全，更能成功才对啊。

你可能会说，因为客户端与服务器端主机名不一致。

但是根本原因不是这样的，之所以会失败，的确是因为主机名验证失败，但失败的原因不是主机名不一致，而是因为我们mysql server的ca不是public机构颁发的，而是自签发的，也就是self-signed，这种模式是无法进行主机名验证的。这就是问题所在。

看选项：

只有选项D是最高安全与信任级别的VERIFY_IDENTITY

因此，选项D正确。

---

第九题

讲解：

• 此题考查的是安全中的mysql audit log知识点

mysql audit log是企业版独有的审计插件

其作用可以概括为基于规则(policy-base)对用户发起的connection以及执行的sql进行监控、记录、阻止。

它的安装跟普通的企业版plugin不同：

• 其它plugin一般是执行一个INSTALL PLUGIN即可完成安装，
• audit_log plugin的安装命令被集中写在了$BASEDIR/share/audit_log_filter_linux_install.sql文件中，因此其安装方式是执行这个SQL文件：

$> mysql -u root -p < audit_log_filter_linux_install.sql
Enter password: (enter root password here)

看下此sql文件中具体内容：

# Copyright (c) 2016, 2021, Oracle and/or its affiliates.

USE mysql;

CREATE TABLE IF NOT EXISTS audit_log_filter(NAME VARCHAR(64) BINARY NOT NULL PRIMARY KEY, FILTER JSON NOT NULL) engine= InnoDB CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_ci;
CREATE TABLE IF NOT EXISTS audit_log_user(USER VARCHAR(32) BINARY NOT NULL, HOST VARCHAR(255) BINARY NOT NULL, FILTERNAME VARCHAR(64) BINARY NOT NULL, PRIMARY KEY (USER, HOST), FOREIGN KEY (FILTERNAME) REFERENCES mysql.audit_log_filter(NAME)) engine= InnoDB CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_ci;

INSTALL PLUGIN audit_log SONAME 'audit_log.so';

CREATE FUNCTION audit_log_filter_set_filter RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_filter_remove_filter RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_filter_set_user RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_filter_remove_user RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_filter_flush RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_read_bookmark RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_read RETURNS STRING SONAME 'audit_log.so';
CREATE FUNCTION audit_log_encryption_password_set RETURNS INTEGER SONAME 'audit_log.so';
CREATE FUNCTION audit_log_encryption_password_get RETURNS STRING SONAME 'audit_log.so';

SELECT audit_log_filter_flush() AS 'Result';

可以发现：audit_log plugin安装除了INSTALL PLUGIN外，还要在mysql系统库中创建一些记录表，用来记录规则、用户等。

重要提醒：它的audit log是存放在文件中的，而不是在mysql创建的记录表中。audit log文件有三种格式：new XML、old XML、JSON。

因此，选项A正确。

---

第十题

讲解：

• 此题考查的是安全中的mysql账户安全

此题出的非常巧妙，我们直接通过题目来讲述知识点。

巧妙在以下几点：

1、题目中的一条GRANT语句，考查的是你是否能够准确识别出这是针对ROLE的操作，而不是针对USER。

GRANT 后面跟的不是具体的privileges(select\delete等)，而是一个用户名或者角色名(r_read@localhost)，那么你应该能看明白这是将角色r_read@localhost直接GRANT给一个用户Mark。

2、题目中的WITH ADMIN OPTION，此短语只会出现在GRANT ROLE中。

WITH ADMIN OPTION的含义是被GRANT ROLE的用户可以将这个ROLE再次GRANT给其它用户或者角色。但不能直接修改或删除这个ROLE，也不能把这个ROLE的权限集合(privileges)拆开，只将其中的部分privilege授权给其它用户。也就是说，他只能对整理ROLE进行GRANT 和REVOKE。

看选项：

选项A，Mark可以将这个role的privileges授权给其它用户。错误。他只能将这个role整体授权给其它用户。

选项B，ADMIN OPTION会自动激活这个ROLE。错误。ROLE必须通过ACCOUNT UNLOCK激活。

选项CD，Mark可以将r_read这个ROLE 授权给其他用户；或将这个ROLE从其它role处收回。正确。

选项E，ADMIN OPTION允许Mark删除这个role。错误。除了Grant 和Revoke，没有其它权限。

选项F，Mark必须登录到localhost来激活这个r_read角色。错误。Mark没有role修改权限。

因此，选项CD正确。

---

第十一题

讲解：

• 此题考查的是安全中的InnoDB Data-at-Rest加密与TDE加密知识点。

此知识点非常重要。

1、什么是InnoDB Data-at-Rest加密

首先，顾名思义，InnoDB Data-at-Rest加密是只针对InnoDB对象的静态数据加密。静态数据加密的目的是为了防止保存在磁盘上的文件被非法使用，使用该功能可以确保数据库的mysql系统表空间、InnoDB表空间、redo日志、undo日志等文件即使是被盗用也无法读取里面的敏感数据。

2、InnoDB Data-at-Rest加密实现原理

InnoDB Data-at-Rest加密是通过两层密钥架构实现静态数据加密功能。

当mysql对一个表空间文件进行加密时，会先产生一个针对该表空间的密钥，使用该密钥对此表空间加密后，该密钥又会被一个主密钥(master key)加密并被保存在被加密的表空间文件的文件头。

当应用程序或者合法用户对表进行访问时，InnoDB会先使用这个主密钥将被加密的表空间文件头的表空间密钥解密，使用解密后的表空间密钥去解密表空间。

3、InnoDB Data-at-Rest加密的密钥丢失怎么办

主密钥可以进行轮换，丢失后可以重新生成；

表空间密钥无法更改，除非对表空间重新进行加密。

因此保护好表空间加密安全，就是要保护好主密钥安全。

4、InnoDB Data-at-Rest加密如何实现

静态数据加密功能依靠MySQL的keyring plugin（钥匙环插件)来实现，密钥全部保存在钥匙环。

目前，MySQL提供如下插件：

keyring_file:社区版提供，将钥匙环数据保存在本地的文件。
keyring_encrypted_file：企业版提供，将钥匙环数据保存在本地的加密文件。
keyring_okv：企业版提供，包含一个KMIP客户端，提供一个兼容KMIP协议的集中管理解决方案，例如，Oracle Key Vault, Gemalto KeySecure等。
keyring_aws：企业版提供，与Amazon Web Services Key Management Service 通信，用于后端存储。
keyring_hashicorp：企业版提供，与HashiCorp Vault通信，用于后端存储。

5、什么是TDE
使用keyring_file 和 keyring_encrypted file 插件加密Data-at-Rest时，无法满足某些安全规范要求的密钥集中管理(centralized key management)。因此，当静态加密功能使用集中式密钥管理解决方案时，该特性被称为“MySQL企业透明数据加密(TDE)”。

说白了就是对Data-at-Rest 加密的密钥进行集中管理。而不是分散在文件系统、tablespace header等各个地方。

看选项：

选项A，MySQL TDE要求使用密钥管理插件实现密钥的集中管理。正确。

选项BD，MyISAM对象可以被加密。错误。只能对InnoDB的表空间。

选项C。只要主密钥还在，就能对丢失的InnoDB tablespace加密密钥进行重建。错误。InnoDB tablespace加密密钥不能重建，只要主密钥可以重建。

因此，选项A正确。

---

第十二题

讲解：

此题考查的是安全领域的mysql client端如何安全存储账户密码

前面提到过，要想安全存储mysql账户密码给client端使用，应该使用mysql_config_editor。

因此，选项D正确。

---

第十三题

讲解：

• 此题考查的是安全中的mysql数据库datadir目录安全性。

这个知识点是很难掌握的，也比较难辨别。

首先，讨论下rsa key文件，mysql使用rsa加密与客户端的数据，那么公钥(public)和私钥(private)就要满足以下安全要求：

private_key.pem--私钥，只能被server端读取。

public_key.pem--公钥，可以被自由分发到所有客户端，其权限允许被所有用户读取。

因此这2个文件要满足：

chmod 400 private_key.pem

chmod 444 public_key.pem

其次，讨论下cert加密文件，包括server-cert.pem和client-cert.pem，以及server-key.pem和client-key.pem。其特点与rsa key类似，server-cert.pem和server-key.pem只能在服务器本地使用，client-cert.pem和client-key.pem是分发到各个客户端，在mysql客户端连接mysql服务器时使用。而cert文件需要被全部用户可读取，key文件只需被当前用户读取。

因此这4个文件要满足：

chmod 400 server-key.pem(client-key.pem)

chmod 444 server-cert.pem(client-cert.pem)

最后，讨论下数据库schema的目录安全。

系统库mysql以及用户库accounting，其目录都不应该给world读写执行权限(否则会带来执行恶意程序的风险),而mysql应该具有rw权限。

因此要满足：

chmod 750 mysql(accounting).

因此，选项AF正确。

有朋友提出不同的见解，表示此题应该选AC。因此，此题作为疑问题标记，如果有更充分理由的朋友可以留言区表达。

---

第四讲下篇完成。

---

作者：老哥讲数据库

简介：数据库高级架构师 | Oracle 11g&12c OCM | MySQL 5.7&8.0 OCP

原创文章，转载请注明来源。