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 以及日常的维护工作都可以在
my