老实说，本文主要部分是翻译的，并且由于英语水平的问题，我没有完全翻译，有些我觉得不重要的就跳过了，目前看来应该八九不离十，或者说不会影响最终效果，对于英语水平好的读者，可以自行查看原文。但这一年里面我遇到了很多事情，也想了很多，我看的资料不少，但是记得的却少得可怜，要用的时候更加难以回忆。能知道从哪里找到就已经很幸运了。

?

有人说，知道在哪里能找到解决方案，已经很不错了，没有人能记住所有东西。也许吧，但是只要力所能及的事情，何不尽力呢？一直苦恼着自己的学习能力为何如此低下，最后发现是否缺少了那么一点思考？过去很多时候我仅仅是个“搬运工”，没有真正去理解现状背后的本质，所以在现在开始有精力写文章的时候，我尽量要求自己在翻译的同时加入自己的想法，也许我写下来的认识会很浅薄，也可能并不能完全反映我的认识，因为现在写下来的，或多或少会因为后续的学习和经历而不同。不过有去做总比没去做好，而且我更多地希望读者看我的思考。

?

由于种种原因，今年打算以翻译为主，但是有一点希望注意的是，我只翻译可能会大面积有助于别人的文章，或者我工作中需要用到的文章。不能自助，何谈助人！ 本文的废话到此结束，下面先看看译文，本人的浅见放到最后：

?

原文出处：点击打开链接https://www.mssqltips.com/sqlservertip/3695/best-practices-to-secure-the-sql-server-sa-account/

?

-------------------------------------------------------------------下面为翻译内容----------------------------------------------------------------

问题：

我们知道SQL Server sa账号的重要性，但是你知道你做得足够了吗？下面步骤可能有参考价值。

?

解决方案：

对于任何已知/内置账号，如Windows系统的Administrator或SQL Server的sa，应该使用一定的操作来保护它（们）。下面看看对于sa账号有哪些操作：

1． 设置难以猜到的密码。

2． 重命名sa。

3． 禁用sa。

4． 确保没有其他名为sa的账号存在。

?

设置难以猜到的密码：

即使仅使用Windows授权，都要确保sa账号的密码足够的强。毕竟SQL Server 仅接受Windows登录和同时接受Windows和SQL Server账号登录之间的区别仅仅是修改一个选项然后重启而已。

对此，更加好的方法是使用密码产生工具来产生密码，以便密码更难以记住。虽然这种方式也可以存储密码，但是在账号反复使用并且要求反复地输入密码时，如果你不使用密码，那么密码将不会驻留在内存中。

但是当你的确需要保留它用于灾难恢复时怎么办呢？在这种情况下，严格按照公司所制定的标准也可以达到保护账号和密码的效果。因为Windows管理员也会面临同样的问题，在域环境中，管理员账号密码及其他特定账号密码需要保留。

?

重命名SQL Server的登录sa账号：

当你打开SSMS（SQL Server Management Studio）的安全性文件夹时，可能会看到如下情景，而对此你选择的可能是重命名sa：

?

但是为了确保你的sa账号是原生账号，可以查询“sys.sql_logins”：

?

SELECT name
FROM sys.sql_logins
WHERE sid = 0x01;

?

?

?

那么如何重命名sa呢？我们会发现如果使用GUI操作并从“属性”中打开，是无法修改的。可以看到框中是灰色的，即不可选：

?

?

但是我们可以在下图的地方进行重命名：

?

?

也可以使用T-SQL进行：

?

?

ALTER LOGIN [sa]WITH NAME = [old_sa];

?

对上级文件夹刷新一下，就可以看到sa已经重命名了：

禁用SQL Server sa 账号：

除了重命名之外，还可以禁用sa账号。那些有权限决定哪个账号是0x01的人，可以轻易重命名这个账号。这是另外一种攻击手段。所以可以通过禁用0x01（原生的sa）来防御，实现这种防御可以有两种方式，第一种是通过GUI：

?

?

另外一种就是用T-SQL语句：

?

ALTER LOGIN [old_sa]DISABLE;

?

?

确保没有其他名为sa的账号存在：

应用程序不使用sa作为程序的账号已经提了十多年，尽管如此，今时今日依旧有相当一部分程序使用sa作为访问账号。结果就是即使应用程序可以使用一个其他的账号，但是部署时依旧使用sa。所以，应该周期化检查SQL Server中是否有存在名为“sa”的账号。你可以通过GUI检查或者使用下面的简单语句查询：

?

SELECT sid, name

FROM sys.sql_logins

WHERE name = 'sa';

但是这样会阻止你检测是否有人尝试连接吗？不会，如果你正在侦测失败登录（默认开启），可以从SQL Server日志中看到如下信息，并且注意它的意思是说这个登录账号不存在：

?

重命名和经用sa账号不会阻止内部进程使用sa账号。所以如果你的某个库的拥有者是sa，禁用sa并不会带来什么问题。其中一个原因是某些数据库，如master和tempdb，要求sa作为拥有者。同时，SQL Server 代理中，拥有者为sa的作业也不会受到影响。另外模拟账号也不会因此失败。所以，没有什么原因“不去”重命名或禁用sa账号。

除了这些问题之外，对于补丁（Service Packs）和累积更新（Cumulative Updates）会有什么影响？理论上，即使重命名和禁用sa账号，安装依旧正常完成。但是从实践上，会存在一些短暂性的小问题。因此，我的常规步骤是在升级SQL Server前把重命名过的sa账号恢复原来名称并启用sa，升级完成后再反操作。这是目前我发现的最好的方法。

?

-------------------------------------------------------------------译文到此结束----------------------------------------------------------------

-------------------------------------------------------------------以下是个人浅见-------------------------------------------------------------