My+SQL安全策略研究.docx

发布时间：2022-06-24 发布人：admin 分类：说明书资料大小：0.05M 资料格式：docx 举报版权申诉

u012603364-6688977-4744302542950473322.docx.pdf-第1页.png

第1页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第2页.png

第2页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第3页.png

第3页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第4页.png

第4页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第5页.png

第5页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第6页.png

第6页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第7页.png

第7页 / 共11页

u012603364-6688977-4744302542950473322.docx.pdf-第8页.png

第8页 / 共11页

账户权限安全

1.1 MySQL中的账号

1.2 授权表

1.3 权限

1.4 设置MySQL权限

1.5 权限与性能

1.6 常见安全隐患

数据加密安全

2.1 账号密码加密

2.2 数据加密

2.3 数据加密与性能

数据备份安全

3.1 备份的重要性

3.2 具体备份策略

3.3 主从复制

3.4 还原

操作系统安全

网络安全

My SQL 安全策略研究 --保证 MySQL 安全是保护数据完整性和私密性的关键目录账户权限安全............................................................................................................................2 1.1 MySQL 中的账号........................................................................................................2 1.2 授权表.........................................................................................................................2 1.3 权限.............................................................................................................................3 1.4 设置 MySQL 权限.......................................................................................................4 1.5 权限与性能................................................................................................................ 5 1.6 常见安全隐患............................................................................................................ 5 数据加密安全............................................................................................................................6 2.1 账号密码加密............................................................................................................ 6 2.2 数据加密.....................................................................................................................6 2.3 数据加密与性能........................................................................................................ 6 数据备份安全............................................................................................................................7 3.1 备份的重要性............................................................................................................ 7 3.2 具体备份策略............................................................................................................ 7 3.3 主从复制.....................................................................................................................7 3.4 还原.............................................................................................................................8 操作系统安全..........................................................................................................................10 网络安全..................................................................................................................................11

账户权限安全 --确保 MySQL 账号都有足够强度的密码和适当的权限 1.1 MySQL 中的账号 MySQL 账号跟大多数系统里的不太一样，由用户名以及登陆来源（常常是主机名、 IP 地址或通配符）构成，例如在授权表 USER 中，是以 User 和 Host 作为该表的联合主键，在其它低级别授权表中还需加入数据库名或表名等信息作为联合主键。由此 MySQL 账号需要注意几个方面，在用 GRANT 语句授权时应该给用户名和登陆地址分别加引号中间用@隔开，标准语句为： GRANT ALL PRIVILEGES ON *.* TO 'user'@'%' IDENTIFIED by 'password'; 同时，可以合理的使用通配符来指定组策略和 IP 策略： GRANT ... ON ' database\_%'.* TO ' user'@'192.168.1.%' IDENTIFIED by 'password'; MySQL 认为相同用户名但是不同主机名就是完全不同的用户，这有助于对同一用户从不同的地方来连接时赋予完全不同的权限，但是，这种策略其中潜在的混乱和问题会远远超过它能带来的好处，因此，不要重用用户名。密码强度也是账户一个很重要的方面，有很多检测密码强度的工具，例如微软的密码检查器：https://www.microsoft.com/zh-cn/security/pc-security/password-checker.aspx 1.2 授权表 MySQL 拥有比较健全的权限信息，从系统级一直可以细化到表级、字段级。所有的授权表信息全部以 MyISAM 存储引擎的格式储存在 MySQL 数据库中。 User：列出可以连接服务器的用户及其口令，并且它指定他们有哪种全局（超级用户）权限。在 user 表启用的任何权限均是全局权限，并适用于所有数据库。例如，如果你启用了 DELETE 权限，在这里列出的用户可以从任何表中删除记录，所以在你这样做之前要认真考虑。 Db：列出数据库，指出哪些用户有权限访问它们。在这里指定的权限适用于一个数据库中的所有表。 Host：host 表与 db 表结合使用，在一个较好层次上控制特定主机对数据库的访问权限，该表不能够通过 GRANT、REVOKE 来进行修改，只能手动增加和删除其中条目，但是为防止 MySQL 出现各种怪异行为，建议不要动这张表。

tables_priv：指定表级权限，在这里指定的一个权限适用于一个表的所有列。 columns_priv：指定列级权限。这里指定的权限适用于一个表的特定列。 Procs_priv：指点存储过程和函数的权限。 MySQL 在授权表里检查权限的次序就是以上授权表的排列顺序，若在较高层级已经能够匹配功能授权以后则停止检查。 1.3 权限 MySQL 的权限主要分为数据库、表权限以及管理权限。数据库、表权限： ALTER 允许你使用 ALTER TABLE 语句，这个权限慎重，以为可以通过这个权限修改表名来获取无法访问的表的信息，例如 user 对 table1 有访问权，对 table2 没有访问权，他可以通过更改 table2 的表名为 table1 来变相获取访问权限。 CREATE 允许你创建数据库和表，但不允许创建索引。 DELETE 允许你从表中删除现有记录。 DROP 允许你删除（抛弃）数据库和表，但不允许删除索引。 INDEX 允许你创建并删除索引。 REFERENCES 目前不用。 SELECT 允许你使用 SELECT 语句从表中检索数据。对不涉及表的 SELECT 语句就不必要，如 SELECT NOW()或 SELECT 4/2。 UPDATE 允许你修改表中的已有的记录。管理权限：用于控制服务器或用户授权能力的管理性操作权限。 FILE 允许你告诉服务器读或写服务器主机上的文件。该权限不应该随便授予，它很危险。服务器确实较谨慎地保持在一定范围内使用该权限。你只能读任何人都能读的文件。你正在写的文件必须不是现存的文件，这防止你迫使服务器重写重要文件。如果你授权 FILE 权限，确保你不以系统管理员用户身份运行服务器，因为 root 可在文件系统的任何地方创建新文件。如果你以一个非特权用户运行服务器，服务器只能在给用户能访问的目录中创建文件。 GRANT

允许你将你自己的权限授予别人，包括 GRANT。 PROCESS 允许你通过使用 SHOW PROCESS 语句或 mysqladmin process 命令查看服务器内正在运行的线程（进程）的信息。这个权限也允许你用 KILL 语句或 mysqladmin kill 命令杀死线程。你总是能看到或杀死你自己的线程。PROCESS 权限赋予你对任何线程做这些事情的能力。 RELOAD 允许你执行大量的服务器管理操作。你可以发出 FLUSH 语句，你也能指性 mysqladmin 的 reload、refresh、flush-hosts、flush-logs、flush-privileges 和 flush-tables 等命令。 SHUTDOWN 允许你用 mysqladmin shutdown 关闭服务器。 SUPER 允许用户做超级用户的操作（例如更改服务器上的只读数据），MySQL 会为有 SUPER 权限的用户保留一条连接，哪怕是服务器已经达到了 max_connections 的极限。这可以让你在服务器无法再接受普通的客户端连接时，还能接入并管理服务器。应该尽量避免把 SUPER 权限授予太多的用户，但是，当有一些其他的普通用途（例如清楚 master 日志）也需要用到它时，就很难把握了。 1.4 设置 MySQL 权限除了自带的系统管理员账号以外还应该创建单独的数据库管理员账号，因为当有超过一个 DBA 需要访问 MySQL 时，为他们分别创建一个单独的账号要好过让他们共用一个 root 账号，这样的设置提供了更强的责任性和可审查性。在设置管理员账号时一个好的小技巧是尽量改变管理员的默认用户名，例如将 root 更改为 newroot 等一般人不易想到的名称，这有时也能够起到加到攻击者实施攻击的难度。为每一个使用数据库的人员单独创建账号，但是由于 MySQL 没有提供用户组或角色这样的功能，可以将它的名称命名在一个特定的功能角色名称后面，例如 custserv 或者 analyst，这样的好处是可以通过通配符批量修改用户权限，但是该方法在管理性上面可能会存在一定问题，具体使用中需要再仔细权衡。对于日志账户仅需要其对日志表有只写权限即可。对备份账户的权限，他一般只需要用到 SELECT 和LOCK TABLES 两项权限，LOCK TABLES 权限是数据库级别的，它只会赋予对具体表有 SELECT 权限的用会 LOCK TABLES 权限。如果一个用户是使用 SELECT INTO OUTFILE 来执行的备份，那么他还需要一个 FILE 权限，不过这个权限是系统级权限，要格外慎重。操作和监控权限，可以使用 KILL 和 SHOW 命令，还可以关闭服务器。因为这些功能都非常强大，所以，需要将它限制在一台单独的主机上使用。在 MySQL 中，存储过程、函数、视图、触发器能在两种安全上下文里执行：作为定义者（SQL SECURITY DEFINER）和作为调用者（SQL SECURITY INVOKER）。当作为调用者时，用户在执行这些存储过程、函数、视图或是触发器时，它必须要求用户拥有这些功能所涉及到的所有相关授权，否则将无法执行。

1.5 权限与性能权限看上去跟性能没什么太大的关系，但是，它们在某些环境下确实会引发性能问题。如果在授权表里，权限条目过多，它们的开销会很显著。当数据库检查一个用户是否有权限执行当前语句时，它要核对每一条添加进来的权限条目。同时，权限的存储也会消耗内存。在 MySQL 中如果权限层级里的每一层都做权限核对显然成本和工作量都是非常大的，核对系统级权限相对来说比较快速，但是，即使只仅仅定义了一个列的权限，服务器就会潜在地用全局的、数据库的、表的和列的权限去检查每一个查询，直到找到跟当前所需权限相匹配的授权。从效率和易维护的角度考虑，建议用视图代替列权限，从而避免以上以及其他由列权限带来的问题。 1.6 常见安全隐患首先要注意的就是不可见的权限，SHOW GRANT 并不能真正显示出所有用户的所有权限。比如 MySQL 刚安装好时会在本地生产一个用户名为空，密码为空的匿名本地账户，而 SHOW GRANT 命令并不能够将其显示出来。另外，默认的 MySQL 安装程序会把 test 数据库和以 test_开头的其他数据库的权限授予每一个用户，这些也是 SHOW GRANT 命令不可见的，一定要注意，在默认安装完 MySQL 之后一定要记得处理 ROOT 账户的密码和删除匿名账户。不要授予用户 mysql 数据库的权限，也不要将 ALTER，GRANT 权限授予用户，这样他们就能变相的提升自己的权限、查看其他用户的权限。还有一些影响权限管理的问题，比如重命名用户名，一定要使用标准的 RENAME USER 命令，而不要使用 UPDATA 直接操作授权表，很多时候，后者可能会造成各级别授权表中出现不一致的情况。当删除对象时，MySQL 不会去清除那些旧权限，这些陈旧的权限会一直留在那里，如果未来的某个时候又以同样的名字创建了对象，那么这些权限依然有效。还有需要注意的是避免直接操作授权表，尽量使用 GRANT、INVOKE、DROP USER 来操作授权表，如果直接操作授权表后要用 FLUSH PRIVILEGES 命令来将新的授权信息写入内存中让数据库知道做了哪些更改。

数据加密安全 --哪怕在物理上访问到了你的数据，使用这些加密了的数据也将会很困难 2.1 账号密码加密在一些不敏感的应用里，需要保护的只有一些数量较少的信息，其中密码就是必须的，在 MySQL 中，用 GRANT 创建用户时的密码都是经过散列算法计算后存储的结果在 User 表中，MySQL 不会存储明文密码在数据库中，如果想修改用户密码，需要使用 SET PASSWORD FOR ‘user’ = PASSWORD(‘password’); 密码必须经过 PASSWORD()函数计算过之后才能生效。需要注意的是 MySQL 内部的 PASSWORD()函数在各个版本中结果是不相同的，经过散列计算后的密码值存储在数据库的 user 表的 password 字段中，值的最前面会有一个“*”号，表示它时经过散列计算的。 2.2 数据加密 MySQL 提供了多个用户函数可用于数据加密，ENCRYPT() ， SHA1() ， MD5() ， AES_DECRYPT()，其中 ENCRYPT()仅仅是调用了 C 语言库里的 crypt()函数。单向散列的缺点是只能加密不能解密，MySQL 有内部的加密解密函数，其中用途最好的就是 AES_DECRYPT()和 AES_DECRYPT()，一个加密一个解密，它通过一个 KEY 值把一个字符串转换成加密的二进制字符串，解密时需要用到同样的 key 值，如：但是加密信息在 SQL 查询语句里仍旧是明文形式，并被写入到系统日志里，加强安全性的步骤是把加密 key 存放在一个用户变量里，而保证用户变量的方法就有很多了。例如，可以把这个变量放在一个存储过程里，通过这个存储过程来设置它的值，同样，也能限制对这个存储过程的访问。这就能让其他用户难以确定这个 key 值。 2.3 数据加密与性能数据加密的弊端是除了无法回避索引问题，并且加密后的数据不能直接进行计算和过滤，比如：MIN()、MIX()、AVG()、WHERE，对此的解决方案是对加密的数据表读取所有的行，解密后再进行运算，这会明显减慢处理速度。因此，对加密和性能之间要好好权衡。

数据备份安全 --哪怕是世界上设计得最好、伸缩性最强的架构，如果它不能在掉电、恶意攻击、程序 BUG、程序员的过失，以及其他灾难中幸存下来，那它也算不上好的架构。 3.1 备份的重要性人们往往把重点放在“正经事”上，却忽视了备份和还原。实际上，紧迫的往往不是重要的，同样，重要的也未必显得很紧迫。好的备份设计方案可以再系统崩溃时减少停机时间、性能缩水等负面影响。备份除了应对灾难还原还有其他一些很重要的方面，比如用户经常需要把部分数据还原到它们在以前某个时间点上存在过的状态，比如用户删除了一些数据，现在又想把它们还原回来，对于一些应用而言，这种情况发生的频率比灾难要高得多。备份还有个作用就是做测试，最好不要用真实数据做测试，如果做了备份，那么使用备份数据就可以了。 3.2 具体备份策略做备份策略应该根据需求来指定，要考虑多方面的因素，是否需要即时点还原功能的备份，是否允许做离线备份，如果不允许做离线备份，那么在线备份对性能影响能承受的范围又是多少。具体的备份策略主要有逻辑备份、裸备份、二进制日志备份、LVM 快照备份。逻辑备份：数据是 MySQL 能够识别的格式，它或者是 SQL，或者是带分界符号的文本，这些文件可以很方便的用编辑器查看，可以值检查一下数据而不做恢复，在备份的时候可以通过参数选择具体要备份的内容，甚至是数据表中的具体行，缺点是服务器必须亲自来生成它们，所以需要消耗更多的 CPU 周期。常用的逻辑备份工具是 mysqldump。裸备份：仅仅需要把数据文件复制到其他地方，就算备份了，不需要做任何额外的工作。裸备份通常容易做，也更有效率，但是它也有很多不利的地方，InnoDB 的裸文件经常要比相应的逻辑备份大很多，也不易轻易的跨平台、操作系统和 MySQL 版本，文件名的大小写敏感和浮点数的格式都会成为麻烦的根源。二进制日志备份：二进制日志是备份的最重要内容之一，它们对于即使点还原时必不可少的，因为在尺寸上它比数据小，易于经常备份。MySQL 默认是关闭二进制日志文件的，需要在配置中打开，还需注意的是要制定一个日志作废策略，以免 MySQL 用二进制日志把磁盘都填满了。 LVM 快照：文件系统快照是做在线备份的极佳方式，有快照功能的文件系统能够在瞬间将它的内容做一个一致的镜像，这个镜像就可以用来作为备份。 3.3 主从复制首先要了解的是复制和 RAID 都不是备份，更不能替代备份，他们解决不了对数据库的误操作造成的数据损失。但是他们是增强安全性和性能，保持“热备份”的利器。

总体来说，复制有 3 个步骤： 1. 主服务器把数据更改记录到二进制日志中 2. 从服务器吧主服务器的二进制日志事件拷贝到自己的中继日志中 3. 从服务器重放中继日志的事件，把更改应用到自己的数据上创建一个复制时很简单的，但是由于场景不同，基本步骤还是有很多差异。不过总的来说，分为以下三步： 1. 在每一台服务器上建立复制账号 2. 配置主、从服务器 3. 指导从服务器进行连接与复制创建复制也许不是经常会做的事情，除非有大量的服务器。但是它一旦就位，不管有多少服务器，对复制进行监控和管理就成了日常工作，应该尽可能地把这个工作自动化。其中主要的工作为： 1. 监控复制，使用 show master logs 和 show binlog events 等命令 2. 测量从服务器延迟 3. 确定主、从服务器是否一致 4. 从主服务器重新同步从服务器 5. 改变主服务器 MySQL 复制中还存在许多缺点，MySQL AB 正在计划解决它们，Google 也发布了一系列定制补丁来增强复制的特性，复制功能在具体使用中应当认真斟酌和配置。 3.4 还原如果一切都运转正常，那么就永远不需要考虑还原的事情，但是，当真正需要还原的时候，那世界上最好的备份系统都帮不上忙。备份一般都不是在极大的压力之下做的，但是，还原往往发生在一个紧要的关头，因此无论怎么强调还原的重要性都不过分。在还原时，很重要的一点是除了还原进程之外不让其他一切程序来访问 MySQL，这对于逻辑备份尤其重要，因为它是分成一块块被加载的。还原裸备份：通常是把文件复制到指定位置就可以了。是否需要关闭 MySQL 取决于使用的存储引擎，如果是 MyISAM 引擎的表通常不用关闭 MySQL 就可以直接生效，如果是 InnoDB 那就比较麻烦了。鉴于复杂性容易让还原过程出错，一个很好的经验法则是：还原过程越艰难复杂，就越要保护好逻辑备份。在裸文件备份出了点问题，不能确定是否可以供 MySQL 使用的情况下，事先保存一份逻辑备份是个不错的注意。还原逻辑备份：这时需要用 MySQL 服务器本身把数据加载到表里去，不再是简单地用操作系统把文件复制到某个地方。在加载那个导出文件之前，需要花些时间考虑下它有多大、需要多久才能加载上去以及其他任何需要再加载前考虑的问题。临时关闭二进制日志也是个好主要，除非需要把还原过程也写到从服务器里去，这会增大系统开销。对于某些存储引擎来说，加载大文件也有个顺序问题。即时点还原：MySQL 最常用的即时点还原时还原最近的一个完全备份记录，然后重放这个备份记录以来的二进制日志。有了二进制日志，就可以在任何想要的点上来做还

分享到：

赞收藏

资料库

My+SQL安全策略研究.docx

相关推荐

数据库

热门标签

最新资料