MySQL安全配置(1)
MySQL_Help_Link
1 安全策略
1.1 管理意义上的数据安全
访问 MySQL 数据库必须首先访问数据库的某个权限、即以某个权限模式用户的身份登录，大部分的安全管理主要通过模式用户的权限来实现。
MySQL 的相关权限信息主要存放在 grant tables 的系统表中，即 mysql.User(全局级别权限) 、 mysql.db (数据库级别权限)、 mysql.Host(数据库级别权限) 、mysql.table_priv(表级别权限) 和、 mysql.column_pr(列级别权限)表中， MySQL 启动时装入内存。应尽量使用 GRANT 、REVOKE 、CREATE USER 及 DROP USER 来进行用户和权限的变更操作。如 :GRANT SELECT.UPDATE,DELETE,INSERT,EXECUTE ON test_shop.* TO ‘ test_guest ‘@’localhost’;
查看某用户权限，如 SHOW GRANTS FOR ‘test_guest’@’ localhost ‘
1.2 防范故障角度的数据安全
数据文件是操作系统级的对象，因此一般来讲具有相当的脆弱性、而且依赖于操作系统的性能特点。由于磁盘介质的因素、一个大的数据文件上个别数据块的损坏可能导致整个数据文件的不可用，这对一个系统来说是灾难性的，而且大的表空间或数据文件的恢复是困难和耗时的。
巨大对象的分区在性能角度之外也有安全的因素，当磁盘错误使一个巨大表中一个单独的数据块不能读写时可能导致整个表不可用，必须恢复包含该表的整个表空间。
考虑到数据仓库问题。可以进行以下操作：
对数据量大且不进行写操作的表，使用 myisampack 工具，生成压缩、只读 MyISAM 表。可以压缩 40% - 50% 的表文件空间。具体操作如下：
A 压缩文件： >myisampack ../data/music_shop/ 表名 .MYI
B 重建索引： >myisamchk -rq --sort-index --analyze../data/test_shop/ 表名 .MYI
C 强制 mysqld 使用新表： > mysqladmin flush-tables
如果要进行写操作，可以解压缩一个压缩的表，恢复原有状态，使用 myisamchk 。 如： myisamchk --unpack ../data/music_shop/ 表名 .MYI
最后，系统上线后，随着数据量的增加，会发现数据目录下的磁盘空间越来越下，造成安全隐患。可以采取两种措施。一种针对 MyISAM 存储引擎的表，在建表时分别指定数据目录和索引目录到不同的磁盘空间，而默认会同时放在数据目录下。另外一种针对 InnoDB 存储引擎的表，因为数据文件和索引文件在一起的，所以无法将它们分离。当磁盘空间不足时，可以增加一个新的数据文件，这个文件放在有充足空间的磁盘上。具体请查阅参数innodb_data_file_path 设置。
1.3 容灾与备份机制
建立主从数据库集群，采用 MySQL 复制
MySQL 复制的优点：
1 如果主服务器出现问题，可以快速切换到从服务器;
2 可以在从服务器上执行查询操作，降低主服务器的访问压力;
3 可以在从服务器上执行备份，以避免备份期间影响主服务器的;
应注意的问题：
由于实现的是异步的复制，所以主从服务器之间存在一定的差距。在从服务器上进行的查询操作要考虑到这些数据的差异，一般只有对实时性要求不高的数据可以通过从服务器查询。
定期备份文件与数据，通过各种方式保存文件与数据。
以下是几点防范的措施：
制定一份数据库备份 / 恢复计划，并对计划进行仔细测试。
启动数据库服务器的二进制变更日志，该功能的系统开销很小 ( 约为 1%) ，二进制日志包含备份后进行的所有更新，我们没有理由不这样做。(log-bin=file，file可以不指定)
定期检查数据表，防范于未燃。
定期对备份文件进行备份，以防备份文件失效。
把 MySQL 的数据目录和备份文件分别放到两个不同的驱动器中，以平衡磁盘 I/O 和增加数据的安全。
2 安全隐患
2.1 正确设置目录权限
设置目录权限的原则是软件和数据分开，具体如下：
1. 将 mysql 安装在单独的用户下
2. 安装时，以 root 用户进行安装，mysql 的软件默认都为 root 权限
3. 安装完毕后，将数据目录权限设置为实际运行 mysql 的用户权限，比如：
Chown –R mysql:mysql /home/mysql/data
2.2 尽量避免以 root 权限运行 mysql
将 4.1 的目录权限设置完毕后，启动、停止 mysql 以及日常的维护工作都可以在
mysql 用户下进行，没有必要 su 到 root 后再用—user=mysql 来启动和关闭 mysql，
这样就没有必要授权维护人员 root 权限，而且最重要的一定是因为任何具有 FILE权限的用户能够用 root 创建文件。
2.3 删除匿名账号
有些版本的 MySQL 安装完之后会安装一个空账号( User = ‘‘ )，此账号对 test 数据库有完全权限，为避免此账号登陆后，建立大表，占用磁盘空间，影响系统安全，建议删除
drop user ''@'localhost';
drop user ''@' localhost.localdomain’;
2.4 给 root 账号设置口令
建议以一句话的拼音为口令。如 SET PASSWORD=PASSWORD(‘woshiyitiaoyu’)
并且限定只能通过 localhost 访问。
2.5 只授予账号必须的权限
如： Grant select,insert,update,delete on tablename to ‘username’@’hostname’
2.6 除 root 外，任何用户不应有 mysql 库 user 表的存取权限
如果拥有 mysql 库中 user 表的存取权限(select、update、insert、delete)， 就
可以轻易的增加、修改、删除其他的用户权限，造成系统的安全隐患。
如：use mysql;delete from db where user<>‘root’ and db=‘mysql’
2.7 不要把 file 、 process 、或 super 权限授予管理员以外的账号
会产生保密信息外泄，查看管理员执行的动作，普通用户执行 kill 命令等严重的安全隐患。
FILE 权限可以被滥用于将服务器主机上 MySQL 能读取的任何文件读入到数据库表中。包括任何人可读的文件和服务器数据目录中的文件。可以使用 SELECT 访问数据库表，然后将其内容传输到客户端上。不要向非管理用户授予 FILE 权限。
有这权限的任何用户能在拥有 mysqld 守护进程权限的文件系统那里写一个文件!为了更加安全，由 SELECT ... INTO OUTFILE 生成的所有文件对每个人是可写的，并且你不能覆盖已经存在的文件。
file 权限也可以被用来读取任何作为运行服务器的 Unix 用户可读取或访问的文件。使用该权限，你可以将任何文件读入数据库表。这可能被滥用，例如，通过使用 LOADDATA 装载“/etc/passwd”进一个数据库表，然后能用 SELECT 显示它。PROCESS 权限能被用来察看当前执行的查询的明文文本，包括设定或改变密码的查询。
SUPER 权限能用来终止其它用户或更改服务器的操作方式。比如 kill 进程不要将 PROCESS 或 SUPER 权限授给非管理用户。mysqladmin processlist 的输出显示出当前执行的查询正文，如果另外的用户发出一个 UPDATE user SETpassword=PASSWORD('not_secure')查询，被允许执行那个命令的任何用户可能看得到
2.8 LOAD DATA LOCAL 带来的安全问题
由 MySQL 服务器启动文件从客户端向服务器主机的传输。理论上，打过补丁的服务器可以告诉客户端程序传输服务器选择的文件，而不是客户用LOAD DATA 语句
指定的文件。这样服务器可以访问客户端上客户有读访问权限的任何文件。
在 Web 环境中，客户从 Web 服务器连接，用户可以使用 LOAD DATA LOCAL 来读取 Web 服务器进程有读访问权限的任何文件(假定用户可以运行 SQL 服务器的任何命令)。在这种环境中，MySQL 服务器的客户实际上是 Web 服务器，而不是连接 Web 服
务器的用户运行的程序。
解决方法：
可以用--local-infile=0 选项启动 mysqld 从服务器端禁用所有 LOAD DATA
LOCAL 命令。
对于 mysql 命令行客户端，可以通过指定--local-infile[=1]选项启用 LOAD
DATA LOCAL，或通过--local-infile=0 选项禁用。类似地，对于 mysqlimport，--local or -L 选项启用本地数据文件装载。在任何情况下，成功进行本地装载需要服务器启用相关选项。
2.9 使用 MERGE 存储引擎潜藏的安全漏洞
Merge 表在某些版本中可能存在以下安全漏洞：
用户 A 赋予表 T 的权限给用户 B
用户 B 创建一个包含 T 的 merge 表，做各种操作
用户 A 收回对 T 的权限
安全隐患：用户 B 通过 merge 表仍然可以访问表 A 中的数据
