前言:
提到数据库用户的安全， 确实是一个很有意思的话题。
用户名：什么样的用户名比较好？
密码策略：肯定是比较复杂一点比较好。
锁定策略：需不需要锁定？解锁策略是什么样的?
预防：在设定一系列策略，并实施之后，能有效预防攻击吗？
本文不针对某一具体的DBMS，其实它应该是关于用户安全方面的一个共性话题。
分析：
如果只是针对用户创建本身， 构建比较安全的用户创建：
用户名搞得长长的，让它不是那么容易被人记住。比如HANA基本上对于新建的用户，就推荐使用GUID形式的用户名，32位去掉'-'的GUID串。你就不用指望去记它了。
密码策略：如不低于16位。里边至少有大小写、特定字符还有数字，每样都沾点儿，增加破解难度。
密码有效期：比如180天过期，必须进行更改。也有要求2个月或1个月改一次的。并且不能使用以前的6次或3次临近的密码，更严格的是任何历史密码都不能用。
锁定策略：用户连续6次密码验证失败，立即锁定，然后，嗯，多长时间解锁？ 有一个小时的，有6个小时的，也有24个小时的。
这样弄下来，似乎创建出来的用户是非常安全的。想破解确实是真的比较难的了。
可是，对于一套系统而言，它有没有缺陷呢？
首先，说说用户名，新建的用户名，你可以强制使用复杂难记的名字，但是还有一些是内置的用户名，如HANA中的system, dbadmin，这些你基本上绕不开啊，知道了这些用户名，用户就有机会去尝试。同理，PostgreSQL中的postgres默认用户，Oracle中的system, sys, scott用户，Sybase或者SQL Server中的sa用户等等, SAP Sybase SQLAnywhere中的用户dba等等。这些半公开的用户名，就给了攻击者去尝试的机会。而一旦有了尝试的机会，就很容易触发了第4条锁定策略，试着试着，我的天啊，该用户被锁了。于是乎，DB的管理员自己也上不去了，他只能相办法去解锁或重置用户密码。重置之后，还是有人在攻击，于是再度被锁定。
依然是这个用户名，有些开发人员或系统架构人员，把初始数据库的连接用户名，都弄成非常简单的用户名。事实证明，它也留下了安全隐患。只要数据库用户名被公开，最后仍然会被陷入上边的怪圈。
这时，肯定有人会着急的问：难道就没有补救措施吗？
单靠创建用户这几板斧，肯定是不够的，只能结合“防火墙”策略本身来进一步限制。如：
限制访问数据库服务器的IP地址：
DB管理员用户，只限于本机访问
应用业务系统的数据库普通用户，严格限制IP地址，最终可能就一两台机器能访问
形如这样，可以把攻击范围缩小到那一两台机器上。如果把用户名弄得复杂些，让攻击用户无法猜测，碰撞不上，那么，难度就会大很多。那些内置的用户的访问，尤其是管理员用户，最好就限制在本机上，一旦离开了视线，很容易成了靶子。正所谓防君子，防不了小人。
上边说的所有的东西，都还是基于明文的，如果加上对连接的双向SSL通信加密，安全性就会得到进一步保障。
说了这么多，上边的处理策略4，实质上确实是一把双刃剑，处理不好，可能会让你的数据库用户成为攻击的活靶子，人家不一定要将你的库拖走，他只想让你的库不可用（不能被正常访问）。
所以，建议在设计和架构之初，相关的用户名以及相应的防火墙策略甚至单双向SSL，根据实际的安全级别需求，一定要考虑清楚。
