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
