当前位置:Gxlcms > mysql > 《高可用MySQL》节选_MySQL

《高可用MySQL》节选_MySQL

时间:2021-07-01 10:21:17 帮助过:34人阅读

bitsCN.com

《高可用MySQL》P59

安全和二进制日志

一般来说,一个有REPLICATION SLAVE权限的用户拥有读取Master上发生的所有事件的权限,因此为了确保安全应使该账户不被损害。这里介绍一些预防措施的例子:

1 尽可能使从防火墙外无法登录该账户;

2 记录所有试图登录到该账户的日志,并将日志放置在一个单独的安全服务器上;

3 加密Master和Salve间所用的连接,例如MySQL的built-in SSL(Secure Sockets Layer)支持。

即使这个账户已经安全了,还存在一些没必要放在二进制日志中的信息,因此首先不存储在那里也是有道理的。

较为常见的一个敏感信息就是密码。当执行改变服务器上的表的语句,并且它包含访问这个表所必须的密码的时候,包含密码的事件会被写入二进制日志。

一个典型的例子是:

UPDATE employee SET pass = PASSWORD('foobar') WHERE email = 'mats@example.com';

如果复制是正确的,最好重写这个没有密码的语句。可以通过以下方法实现:计算和存储哈希密码到用户定义变量,然后在表达式中使用它:

SET @password = PASSWORD('foobar');UPDATE employee SET pass = @password WHERE email = 'mats@example.com';

由于SET语句没有被复制,原来的密码将不会存储在二进制日志中,而仅在执行该语句的时候存储在服务器的内存中。

只要存储password hash到表中,而不需要纯文本密码,这种方法行之有效。如果原始密码是直接存储在表中的,就有没有办法阻止密码在二进制日志中结束。但存储哈希密码在任何情况下都是一个标准的好做法,可以防止有人通过学习密码将原始数据弄到手。

封装连接为加密Master和Salve之间的连接提供了一些保护,但如果二进制日志本身被攻破,加密连接也无能为力。

bitsCN.com

人气教程排行