MSSQL管理员账号那些事儿，怎么管才不出问题和风险多点注意

说到MSSQL数据库的管理员账号,也就是那个sa账号，这绝对是整个数据库系统里最要害的一把钥匙，管得好，天下太平；管得不好，那就是给黑客大开方便之门，数据泄露、系统瘫痪啥的都可能发生，这事儿必须得认真对待。

最最要紧的一点,就是千万别用那个默认的sa账号干日常的活儿，这个账号的名字是公开的，就像你家大门的锁，如果用的还是最原始、人人都知道的钥匙，那安全根本谈不上，很多攻击者一上来就会尝试爆破sa账号的密码，第一条黄金法则就是：创建一个拥有必要权限的个性化管理员账号，用于日常的数据库管理和维护工作，这个账号的名字别起得太明显，admin”、“dba”这种，最好起个不起眼的名字，然后把sa账号晾在一边，把它当作一个“备用钥匙”或者“紧急钥匙”来处理。

就是密码问题,sa账号和任何一个管理员账号，都必须设置极其复杂的强密码，这个密码不能是“123456”、“password”这种开玩笑的，也不能是公司名、生日这类容易猜到的，最好是大小写字母、数字、特殊符号混合起来的长密码，要定期更换密码，比如每90天换一次，千万别觉得麻烦，这是最基本的安全防线，微软的官方安全文档里就一直强调强密码和定期更换的重要性。

光有密码还不够,还得把账户的登录策略和系统的安全策略挂钩，比如说，要启用“强制密码策略”，这样数据库账号的密码复杂度要求和过期时间就能和Windows服务器的策略保持一致，省得你手动去记，还有，要设置登录失败锁定，比如连续输错5次密码，这个账号就暂时锁住一段时间，这能有效防止别人用程序自动不停地尝试密码（也就是所谓的暴力破解）。

权限这块儿要遵循“最小权限原则”，这是什么意思呢？就是给管理员账号的权限，刚好够他完成工作就行，别动不动就给最高的“sysadmin”服务器角色，有的人可能只需要备份数据库，那就只给他备份操作的权限；有的人只需要查看性能数据，那就给相应的只读权限，分清楚每个人需要干什么，然后按需分配权限，这样即使某个管理员的账号不小心泄露了，或者被误操作了，造成的破坏也能控制在一定范围内，绝对不能图省事，把所有管理员都加到sysadmin角色里。

还有一点很容易被忽视,就是定期审计和检查，你得知道谁在什么时候用管理员账号登录了系统，干了些什么，要开启SQL Server的审计功能，或者至少开启登录的“审核”功能，记录下成功的和失败的登录尝试，定期查看这些日志，看看有没有什么可疑的活动，有没有在深更半夜从没见过的IP地址尝试登录sa账号？有没有管理员执行了不寻常的危险操作？这都是风险的苗头，根据一些企业的安全实践指南，对特权账号操作的日志记录和定期审查是内控的关键环节。

再说说那个sa账号本身,在确保你已经有了其他可靠的管理员账号之后，最彻底的安全做法就是直接禁用sa账号，在很多严格的生产环境里，这都是标准操作，因为只要这个账号存在，哪怕密码再复杂，它也是一个显眼的目标，直接禁用掉，就从根源上消除了一個风险点，在禁用之前，一定要再三确认你有其他可以完全控制数据库的账号。

管好MSSQL管理员账号,核心就是这几件事：弃用默认sa做日常、设超强密码并定期换、启用失败锁定、严格按需分配最小权限、勤查登录和操作日志、最后考虑直接禁用sa，把这些事儿做到位了，数据库的大门才算得上是上了几道靠谱的锁，安全系数才能大大提升，这些方法在很多像等保测评这样的安全规范里也都是被反复强调的要点。