mysql安全评估怎么看 mysql数据安全问题

怎么查看mysql数据库中的表是否损坏可以使用语句检查表 。如果结果的msg_text部分是好的 , 那么你的表是健康的 。反之,则表明mysql数据库中的表有损坏 。另外有些厉害的高手一额可以通过运行脚本来检测 。
MyISAM 表可以采用以下方法进行修复 mysql安全评估怎么看:使用 reapair table 或myisamchk 来修复 。如果修复无效,采用备份恢复表 。
阶段1 :检查你的表
如果你有很多时间,运行myisamchk *.MYI 或myisamchk -e *.MYI。使用-s (沉默)选项禁止不必要的信息 。如果mysqld 服务器处于宕机状态,应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的'。
你必须只修复那些myisamchk 报告有错误的表 。对这样的表,继续到阶段2。如果在检查时,你得到奇怪的错误( 例如out of memory 错误) ,或如果myisamchk 崩溃,到阶段3。
阶段2 :简单安全的修复
注释:如果想更快地进行修复,当运行myisamchk 时,你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25%。
首先 , 试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”)。这将试图不接触数据文件来修复索引文件 。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接,这应该管用并且表可被修复 。开始修复下一张表 。否则 , 执行下列过程:
在继续前对数据文件进行备份 。使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”)。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件 。
如果前面的步骤失败,使用myisamchk --safe-recover tbl_name。安全恢复模式使用一个老的恢复方法,处理常规恢复模式不行的少数情况( 但是更慢)。如果在修复时,你得到奇怪的错误( 例如out of memory 错误) ,或如果myisamchk 崩溃,到阶段3。
阶段3 :困难的修复
只有在索引文件的第一个16K 块被破坏,或包含不正确的信息,或如果索引文件丢失,你才应该到这个阶段 。在这种情况下 , 需要创建一个新的索引文件 。按如下步骤操做:
把数据文件移到安全的地方 。使用表描述文件创建新的( 空) 数据文件和索引文件:
shell mysql db_name
mysql SET AUTOCOMMIT=1;
mysql TRUNCATE TABLE tbl_name;
mysql quit
如果你的MySQL 版本没有TRUNCATE TABLE,则使用DELETE FROM tbl_name。将老的数据文件拷贝到新创建的数据文件之中 。回到阶段2。现在myisamchk -r -q 应该工作了 。你还可以使用REPAIR TABLE tbl_name USE_FRM ,将自动执行整个程序 。
阶段4 :非常困难的修复
只有.frm 描述文件也破坏了,你才应该到达这个阶段 。这应该从未发生过,因为在表被创建以后,描述文件就不再改变了 。
从一个备份恢复描述文件然后回到阶段3。你也可以恢复索引文件然后回到阶段2。对后者,你应该用myisamchk -r 启动 。
如果你没有进行备份但是确切地知道表是怎样创建的 , 在另一个数据库中创建表的一个拷贝 。删除新的数据文件,然后从其mysql安全评估怎么看他数据库将描述文件和索引文件移到破坏的数据库中 。这样提供了新的描述和索引文件 , 但是让.MYD 数据文件独自留下来了 。回到阶段2并且尝试重建索引文件 。
如何查看mysql数据库隔离级别术式之后皆为逻辑mysql安全评估怎么看,一切皆为需求和实现 。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别 。
隔离级别的产生
在串型执行的条件下 , 数据修改的顺序是固定的、可预期的结果,但是并发执行的情况下,数据的修改是不可预期的,也不固定,为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果,由此产生了隔离级别 。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法 。
事务的4种隔离级别
READ UNCOMMITTED未提交读,可以读取未提交的数据 。READ COMMITTED已提交读 , 对于锁定读(select with for update 或者 for share)、update 和 delete 语句 , InnoDB 仅锁定索引记录 , 而不锁定它们之间的间隙,因此允许在锁定的记录旁边自由插入新记录 。Gap locking 仅用于外键约束检查和重复键检查 。REPEATABLE READ可重复读,事务中的一致性读取读取的是事务第一次读取所建立的快照 。SERIALIZABLE序列化
在了解了 4 种隔离级别的需求后,在采用锁控制隔离级别的基础上 , mysql安全评估怎么看我们需要了解加锁的对象(数据本身间隙),以及了解整个数据范围的全集组成 。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围(不加锁)mysql安全评估怎么看;
SQL 语句根据条件扫描到的可能需要加锁的数据范围;
以单个数据范围为例,数据范围全集包含:(数据范围不一定是连续的值,也可能是间隔的值组成)
1. 数据已经填充了整个数据范围:(被完全填充的数据范围,不存在数据间隙)
整形,对值具有唯一约束条件的数据范围 1~5 ,
已有数据1、2、3、4、5,此时数据范围已被完全填充;
整形,对值具有唯一约束条件的数据范围 1 和 5 ,
已有数据1、5,此时数据范围已被完全填充;
2. 数据填充了部分数据范围:(未被完全填充的数据范围 , 是存在数据间隙)
整形的数据范围 1~5,
已有数据 1、2、3、4、5,但是因为没有唯一约束 ,
所以数据范围可以继续被 1~5 的数据重复填充;
整形,具有唯一约束条件的数据范围 1~5,
已有数据 2,5 , 此时数据范围未被完全填充,还可以填充 1、3、4 ;
3. 数据范围内没有任何数据(存在间隙)
如下:
整形的数据范围 1~5 , 数据范围内当前没有任何数据 。
在了解了数据全集的组成后,我们再来看看事务并发时,会带来的问题 。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题,主要包括以下几种情况 。
1. 范围内已有数据更改导致的:
更新丢失:当多个事务选择了同一行 , 然后基于最初选定的值更新该行时,
由于每个事物不知道其他事务的存在,最后的更新就会覆盖其他事务所做的更新;
脏读: 一个事务正在对一条记录做修改,这个事务完成并提交前,这条记录就处于不一致状态 。
这时 , 另外一个事务也来读取同一条记录,如果不加控制,
第二个事务读取了这些“脏”数据,并据此做了进一步的处理,就会产生提交的数据依赖关系 。
这种现象就叫“脏读” 。
2. 范围内数据量发生了变化导致:
不可重复读:一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,
却发现其读出的数据已经发生了改变,或者某些记录已经被删除了 。
这种现象就叫“不可重复读” 。
幻读:一个事务按相同的查询条件重新读取以前检索过的数据,
却发现其他事务插入了满足其查询条件的新数据,这种现象称为“幻读” 。
可以简单的认为满足条件的数据量变化了 。
因为无控制的并发会带来一系列的问题,这些问题会导致无法满足我们所需要的结果 。因此我们需要控制并发,以实现我们所期望的结果(隔离级别) 。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别 。
行锁包含:
Record Locks
索引记录锁,索引记录锁始终锁定索引记录,即使表中未定义索引,
这种情况下,InnoDB 创建一个隐藏的聚簇索引,并使用该索引进行记录锁定 。
Gap Locks
间隙锁是索引记录之间的间隙上的锁 , 或者对第一条记录之前或者最后一条记录之后的锁 。
间隙锁是性能和并发之间权衡的一部分 。
对于无间隙的数据范围不需要间隙锁,因为没有间隙 。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合 。
假设索引包含 10、11、13 和 20 。
可能的next-key locks包括以下间隔,其中圆括号表示不包含间隔端点,方括号表示包含端点:
(负无穷大, 10](10, 11](11, 13](13, 20](20, 正无穷大)对于最后一个间隔 , next-key将会锁定索引中最大值的上方,
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值 。
上确界不是一个真正的索引记录,因此,实际上,这个 next-key 只锁定最大索引值之后的间隙 。
基于此,当获取的数据范围中,数据已填充了所有的数据范围,那么此时是不存在间隙的,也就不需要 gap lock 。
对于数据范围内存在间隙的,需要根据隔离级别确认是否对间隙加锁 。
默认的 REPEATABLE READ 隔离级别,为了保证可重复读,除了对数据本身加锁以外,还需要对数据间隙加锁 。
READ COMMITTED 已提交读,不匹配行的记录锁在 MySQL 评估了 where 条件后释放 。
对于 update 语句,InnoDB 执行 "semi-consistent" 读取,这样它会将最新提交的版本返回到 MySQL,
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配 。
总结延展:
唯一索引存在唯一约束 , 所以变更后的数据若违反了唯一约束的原则,则会失败 。
当 where 条件使用二级索引筛选数据时,会对二级索引命中的条目和对应的聚簇索引都加锁;所以其他事务变更命中加锁的聚簇索引时,都会等待锁 。
行锁的增加是一行一行增加的,所以可能导致并发情况下死锁的发生 。
例如 ,
在 session A 对符合条件的某聚簇索引加锁时 , 可能 session B 已持有该聚簇索引的 Record Locks,而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks 。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引 。
session A 通过索引 idA,session B通过索引 idB。
当 where 条件获取的数据无间隙时,无论隔离级别为 rc 或 rr,都不会存在间隙锁 。
比如通过唯一索引获取到了已完全填充的数据范围,此时不需要间隙锁 。
间隙锁的目的在于阻止数据插入间隙,所以无论是通过 insert 或 update 变更导致的间隙内数据的存在,都会被阻止 。
rc 隔离级别模式下,查询和索引扫描将禁用 gap locking,此时 gap locking 仅用于外键约束检查和重复键检查(主要是唯一性检查) 。
rr 模式下,为了防止幻读,会加上 Gap Locks 。
事务中,SQL 开始则加锁,事务结束才释放锁 。
就锁类型而言,应该有优化锁,锁升级等,例如rr模式未使用索引查询的情况下 , 是否可以直接升级为表锁 。
就锁的应用场景而言,在回放场景中,如果确定事务可并发 , 则可以考虑不加锁 , 加快回放速度 。
锁只是并发控制的一种粒度 , 只是一个很小的部分:
从不同场景下是否需要控制并发,(已知无交集且有序的数据的变更,MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度,(锁是一种逻辑粒度,可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化,(锁本身存在优化,如IX、IS类型的优化锁)
粒度加载的安全性能(如获取行锁前,先获取页锁 , 页锁在执行获取行锁操作后即释放,无论是否获取成功)等多个层次去思考并发这玩意 。
mysql数据库可靠性分析mysql数据库有undo空间
5种mysql做可靠性分析的方案:
1.MySQL Clustering(ndb-cluster stogare)
简介:
MySQL公司以存储引擎方式提供的高可靠性方案,是事务安全的,实时复制数据,可用于需要高可靠性及负载均衡的场合 。该方案至少需要三个节点服务器才能达到较好的效果 。
成本:
节点服务器对RAM的需求很大,与数据库大小呈线性比例;
最好使用千兆以太网络;
还需要使用Dolphin公司提供的昂贵的SCI卡 。
优点:
可用于负载均衡场合;
可用于高可靠性场合;
高伸缩性;
真正的数据库冗余;
容易维护 。
缺点:
随着数据库的变大 , 对RAM的需求变得更大,因此成本很高;
速度:
几乎 比典型的单独服务器(无千兆以太网,无SCI卡,存储引擎相关的限制少)慢10倍 。
应用场合:
冗余,高可靠性 , 负载均衡
2. MySQL / GFS-GNBD/ HA (Active/Passive)
简介:
如果多个MySQL服务器使用共享硬盘作为数据存储 , 此方案如何?
GFS/GNBD可以提供所需的共享硬盘 。
GFS是事务安全的文件系统 。同一时刻你可以让一个MySQL使用共享数据 。
成本:
最多n台高性能服务器的成本,其中一个激活的,其他作为备份服务器 。
优点:
高可靠性
某种程度的冗余
按照高可靠性进行伸缩
缺点:
没有负载均衡
没有保证的冗余
无法对写操作进行伸缩
速度:
单独服务器的2倍 。对读操作支持得较好 。
应用场合:
需要高可靠性的、读操作密集型的应用
3. MySQL / DRBD / HA (Active/Passive)
简介:
如果多个MySQL服务器使用共享硬盘作为数据存储,此方案如何?
DRBD可以提供这样的共享硬盘 。DRBD可以被设置成事务安全的 。
同一时刻你可以让一个MySQL使用共享数据 。
成本:
最多n台高性能服务器的成本,其中一个激活的,而其他则作为备份服务器 。
优点:
高可靠性;
一定程度的冗余;
以高可靠性名义来看是可伸缩的 。
缺点:
没有负载均衡
没有保证的冗余
在写负载方面没有伸缩性
速度:
在读写方面相当于单独服务器
应用场合
需要高可靠性、读操作密集型的应用
4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)
简介:
考虑不同的读、写DB数据库连接的情况 。可以使用一台主服务器用于写操作 , 而采用n台从服务器用于读操作 。
成本:
最多1台高性能写服务器,n台读服务器的成本
优点:
读操作的高可靠性;
读操作的负载均衡;
在读操作负载均衡方面是可伸缩的 。
缺点:
无写操作的高可靠性;
无写操作的负载均衡;
在写操作方面无伸缩性;
速度:
同单独服务器;在读操作方面支持得较好
应用场合
读操作密集型的、需要高可靠性和负载均衡的应用 。
5. Standalone MySQL Servers(Functionally separated) (Active)
多台功能分离的单独服务器,没有高可靠性、负载均衡能力,明显缺点太多,不予考虑 。
如何做好MySQL安全策略摘至网页链接
常见Mysql配置文件:linux系统下是my.conf,windows环境下是my.ini;
数据库整体安全需求:机密性、完整性、可用性;
下面以mysql 5.7版本为例,介绍mysql常见的安全策略、配置、加固方式等等,有些策略可能只针对Linux操作系统,更多策略可以参考CIS Mysql Benchmark相关文档:
1、操作系统级别安全配置
1.1不要将数据库放在系统分区
Windows系统:直接检查是否将数据库放置在C盘 。
Linux系统:
在终端连接上mysql数据库 , 执行如下命令:
show variables where variable_name = 'datadir';
然后返回shell命令行:
df -h datadir
其中datadir是上一条命令的返回值 。
上述命令的返回值不应是/、/var、/usr
1.2使用专用的最小权限账号运行mysql数据库进程
Windows系统:直接打开任务管理器,查看运行mysql进程的操作系统账号,不能为administrator账号 。
Linux系统:
Shell命令行运行如下命令:
ps -ef | grep mysql
查看mysql服务的运行账号是否为root或其他高权限账号,如果是的,则需要创建一个非管理员专用账号来运行mysql服务 。
1.3禁止使用mysql命令行历史记录
Linux系统:
执行如下命令:
find / -name ".mysql_history"
查看是否存在mysql的历史命令记录文件,如果存在,则需要进行如下加固:
(1)删除.mysql_history文件;
(2)设置环境变量MYSQL_HISTFILE为/dev/null,并添加到shell的初始化脚本中,创建mysql_history到/dev/null的链接:
ln -s /dev/null $HOME/.mysql_history
1.4 确保MYSQL_PWD环境变量未设置敏感信息
Windows系统下进入cmd命令行 , 使用如下命令:
Set
查看是否设置了环境变量MYSQL_PWD 。
Linux系统下使用如下命令:
grep MYSQL_PWD /proc/*/environ
查看MYSQL_PWD环境变量是否设置了敏感信息 。
确认那个配置文件或脚本设置了MYSQL_PWD环境变量 。
2、安装
2.1使用数据库专用服务器
使用专用的服务器安装mysql服务可以减少mysql服务的攻击面,尽量卸载或删除操作系统上的不必要的应用或服务,减少其他应用的安装可能给mysql的运行带来的安全风险 。
2.2 不要复用数据库账号
运行mysql服务的操作系统账号不要用来运行其他应用或服务 , 这样可以避免其他应用或服务器被攻击给mysql服务带来影响 。
2.3 历史命令行密码设置为不可见
使用如下命令:
mysql -u admin -p password
连接mysql数据库服务,退出后查看历史命令,确认password是否为明文 。
建议使用如下命令方式登录:
(1)先输入mysql -u admin -p
(2)根据命令行提示输入密码;
而不要在一整条命令中输入密码 。
另外要控制mysql配置文件访问权限 。
3、文件权限控制
3.1 控制数据目录的访问权限
数据目录是mysql数据库存放的位置,在mysql命令行界面下执行如下命令:
show variables where variable_name = 'datadir';
在终端命令行下执行如下命令:
ls -l datadir/.. | egrep "^d[r|w|x]{3}------\s*.\s*mysql\s*mysql\s*\d*.*mysql"
其中datadir是第一条命令的执行结果
如果存在问题,linux环境下在终端执行如下命令进行加固:
chmod 700 datadir
chown mysql:mysql datadir
3.2 控制二进制日志文件的权限
mysql的运行会产生很多日志 , 例如二进制日志、错误日志、慢查询日志等等 , Mysql命令行下执行如下命令:
show variables like 'log_bin_basename';
在终端命令行执行如下命令:
ls log_bin_basename.*
对于发现的每一个文件,执行如下命令:
ls -l log_bin_basename.nnnnn | egrep "^-[r|w]{2}-[r|w]{2}----\s*.*$"
根据输出确认日志文件的权限设置是否存在问题 。
对于每个日志文件,修改其权限和属组如下:
chmod 660 log file
chown mysql:mysql log file
3.3 控制错误日志文件的权限
Mysql命令行下执行如下命令:
show variables like 'log_error';
在终端命令行执行如下命令:
ls log_error.*
对于发现的每一个文件,执行如下命令:
ls -l log_error | egrep "^-[r|w]{2}-[r|w]{2}----\s*.*$"
根据输出确认日志文件的权限设置是否存在问题 。
对于每个日志文件 , 修改其权限和属组如下:
chmod 660 log file
chown mysql:mysql log file
3.4控制慢查询日志文件的权限
Mysql命令行下执行如下命令:
show variables like 'slow_query_log_file';
在终端命令行执行如下命令:
ls slow_query_log_file.*
对于发现的每一个文件,执行如下命令:
ls -l slow_query_log_file | egrep "^-[r|w]{2}-[r|w]{2}----\s*.*$"
根据输出确认日志文件的权限设置是否存在问题 。
对于每个日志文件,修改其权限和属组如下:
chmod 660 log file
chown mysql:mysql log file
3.5控制通用日志文件的权限
Mysql命令行下执行如下命令:
show variables like 'general_log_file';
在终端命令行执行如下命令:
ls general_log_file.*
对于发现的每一个文件 , 执行如下命令:
ls -l general_log_file | egrep "^-[r|w]{2}-[r|w]{2}----\s*.*$"
根据输出确认日志文件的权限设置是否存在问题 。
对于每个日志文件,修改其权限和属组如下:
chmod 660 log file
chown mysql:mysql log file
3.6控制审计日志文件的权限
Mysql命令行下执行如下命令:
show global variables where variable_name ='audit_log_file';
在终端执行如下命令:
ls -l audit_log_file | egrep "^-rw[-x]rw[-x][-r][-w][-x][ \t]*[0-9][ \t]*mysql[
\t]*mysql.*$"
根据输出确认日志文件的权限设置是否存在问题 。
对于每个日志文件,修改其权限和属组如下:
chmod 660 audit_log_file
chown mysql:mysql audit_log_file
4、通用安全
4.1安装最新的补丁
在mysql命令行下查询MySQL的版本:
SHOW VARIABLES WHERE Variable_name LIKE "version";
确认是否由需要安装的补丁包,如果有请安装 。
4.2 删除test数据库
Mysql数据库默认安装好后,存在一个名为test的数据库,如果存在 , 请执行如下命令删除:
Drop database “test”
4.3 确保读取本地文件的参数设置为失效
Mysql命令行下,使用如下命令:
SHOW VARIABLES WHERE Variable_name = 'local_infile';
查看结果是否为OFF 。
如果该命令为ON , 则数据库用户可以通过LOAD DATA INFILE 或者 SELECT local_file 读取到数据库所在操作系统本地的文件 , 在这种情况下,需要在mysql配置文件中新增一行:
Local-infile=0;
然后重启数据库服务 。
5、权限配置
5.1控制可以访问所有数据库的账号
Mysql数据库下的user表和db表中存放着可以授予数据库用户的权限,确保只有管理员账号才能访问所有数据库 。可以访问mysql数据库的用户或许可以查看密码哈希值、修改用户权限等等 。
使用如下sql语句:
SELECT user, host FROM mysql.user
WHERE (Select_priv = 'Y') OR (Insert_priv = 'Y') OR (Update_priv = 'Y')
OR (Delete_priv = 'Y')OR (Create_priv = 'Y')OR (Drop_priv = 'Y');
SELECT user, host FROM mysql.db WHERE db = 'mysql'
AND ((Select_priv = 'Y') OR (Insert_priv = 'Y') OR (Update_priv = 'Y')
OR (Delete_priv = 'Y') OR (Create_priv = 'Y') OR (Drop_priv = 'Y'));
确保返回结果只能是数据库管理员账号 。
5.2限制非管理员用户的权限
Mysql.user表中的权限列有:
file_priv:表示是否允许用户读取数据库所在主机的本地文件;
Process:表示是否允许用户查询所有用户的命令执行信息;
Super_priv:表示用户是否有设置全局变量、管理员调试等高级别权限;
Shutdown_priv:表示用户是否可以关闭数据库;
【mysql安全评估怎么看 mysql数据安全问题】Create_user_priv:表示用户是否可以创建或删除其他用户;
Grant_priv:表示用户是否可以修改其他用户的权限;
应确保只有数据库管理员才有上述权限,使用如下sql语句查看拥有各个权限的数据库账号:
select user, host from mysql.user where File_priv = 'Y';
select user, host from mysql.user where Process_priv = 'Y';
select user, host from mysql.user where Process_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Create_user_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Grant_priv = 'Y';
SELECT user, host FROM mysql.db WHERE Grant_priv = 'Y';
确保查询结果中不存在非管理员用户 。
如果存在非管理员用户,使用如下命令进行权限回收:
REVOKE FILE ON *.* FROM 'user';
REVOKE PROCESS ON *.* FROM 'user';
REVOKE SUPER ON *.* FROM 'user';
REVOKE SHUTDOWN ON *.* FROM 'user';
REVOKE CREATE USER ON *.* FROM 'user';
REVOKE GRANT OPTION ON *.* FROM user;
其中user为上述查询到的非管理员用户 。
5.3合理控制DML/DDL操作授权
DML/DDL语句包括创建或修改数据库结构的权限 , 例如insert、update、delete、create、drop和alter语句,在任何数据库中都要控制用户的此类权限,确保只授权给有业务需求的非管理员用户 。Mysql命令行下执行如下命令:
SELECT User,Host,Db FROM mysql.db WHERE Select_priv='Y'
OR Insert_priv='Y' OR Update_priv='Y' OR Delete_priv='Y' OR Create_priv='Y'
OR Drop_priv='Y' OR Alter_priv='Y';
上述查询到的用户只能对特地的数据库才有相关的权限,使用如下命令进行相关权限的回收:
REVOKE SELECT ON host.database FROM user;
REVOKE INSERT ON host.database FROM user;
REVOKE UPDATE ON host.database FROM user;
REVOKE DELETE ON host.database FROM user;
REVOKE CREATE ON host.database FROM user;
REVOKE DROP ON host.database FROM user;
REVOKE ALTER ON host.database FROM user;
其中user为查询到的未授权的用户 , host为相关主机,database为相关数据库 。
6、审计和日志
6.1开启错误日志审计功能
错误日志包括数据库运行和停止过程中的一系列活动信息,有助于分析数据库运行过程中的一些异常活动,一般情况下需要开启错误日志记录功能,使用如下命令查询:
SHOW variables LIKE 'log_error';
确保返回结果为非空,如果为空 , 需要在mysql数据库配置文件中增加相关配置 。
6.2确保日志存放在非系统区域
日志文件随着数据库的运行会不断增加,如果存放在系统区域,则会影响系统的正常运行,使用如下命令进行查询:
SELECT @@global.log_bin_basename;
确保返回结果不是如下路径:/、/var、/usr
6.3关闭原始日志功能
原始日志选项会决定一些敏感信息是否会被明文写进日志中,例如查询日志、慢查询日志、二进制日志,确保数据库配置文件中存在如下配置项:
Log-raw = OFF
7、认证
7.1 Old_passwords环境变量设置
Old_passwords决定了使用PASSWORD()函数和IDENTIFIED BY 、CREATE USER 、GRANT 等语句是时的hash算法:
0 - authenticate with the mysql_native_password plugin
1 - authenticate with the mysql_old_password plugin
2 - authenticate with the sha256_password plugin
设置为mysql_old_password代表弱hash算法,可以快速通过密码字典进行暴力破解 。使用如下命令查询相关值:
SHOW VARIABLES WHERE Variable_name = 'old_passwords';
确保返回值不为1 。
7.2 secure_auth 选项设置
如果客户端采用Old_passwords发起连接请求,如果服务器端设置了secure_auth , 则客户端会拒绝连接请求,可以根据安全需求在配置文件中做相应配置 。
7.3 密码保存
确保密码没有明文保存在全局配置文件中 。
7.4 确保所有用户都要求使用非空密码登录
执行如下语句查询是否有用户不需要密码即可登录:
SELECT User,host
FROM mysql.user
WHERE (plugin IN('mysql_native_password', 'mysql_old_password')
AND (LENGTH(Password) = 0
OR Password IS NULL))
OR (plugin='sha256_password' AND LENGTH(authentication_string) = 0);
7.5不存在空账号
使用如下命令查询是否存在空账号:
SELECT user,host FROM mysql.user WHERE user = '';
8、网络设置
如果mysql数据库服务器与应用是跨信任域部署的,则需要考虑在数据库服务器与应用服务器之间建立ssl通道进行数据传输 , 不过这种场景一般很少见,在此不详细描述 。
9、数据库备份
关于mysql安全评估怎么看和mysql数据安全问题的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站 。

    推荐阅读