欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

《高可用MySQL》节选_MySQL

程序员文章站 2022-06-06 13:47:49
...
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