SQL Server SA 最佳实践（也许不仅仅是翻译）

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

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

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

原文出处：点击打开链接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 nameFROM sys.sql_loginsWHERE sid = 0x01;

其中的sid，也就是security identifier，非常重要，原生的sa账号总是0x01。这个查询可以确定sa账号是原生账号还是由别的账号重命名的。稍后会介绍如何应对被修改成sa的账户。如果该账号是原生的，你会看到类似下面的结果：

 那么如何重命名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;

本人注：其实通过上图GUI操作中的“脚本”就可以导出脚本。

确保没有其他名为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，升级完成后再反操作。这是目前我发现的最好的方法。

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

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

安全性无处不在，不仅是SQL Server，其他DBMS都会有内置账号，我们其实已经早已习惯了这些账号，如Windows的Administrator，Ubuntu的sudo等，重点是在特定环境中如何保护这些超级账号，曾经见过一篇文章，大概是超过90%的安全问题来自于内部，所以如何规范化才是重点。总有人说微软的产品如何不安全，Linux/Unix有多好，但即使美国国防部也做不到绝对安全。

另外在SQL Server中，默认会把Windows的本机管理员账号加进去。如果不管好SQL Server所在的服务器，没有sa照样可以自如操作，甚至把sa启用，也可以用其他账号模拟sa，另外sa只是个内置账号，完全可以创建sysadmin级别的账号来完成几乎所有操作。所以文中提到的保护方法很多是可以用在其他账号里面的，开发过程要注意。

 对于开发过程中的思考，结合个人经历，有些工作的确要做到位：

1．你是否启用了混合身份验证？虽然微软一直建议尽可能使用Windows身份验证，但是现实中很难做到，所以混合身份验证往往是必须开启的。这一步最好在安装SQL Server的时候就完成，并且不要让sa出现空密码。（最慢也在SQL Server 2008 的安装过程中拒绝使用简单密码作为sa密码了）

2．开启混合身份验证之后，打好必要的补丁，创建开发和管理所需的SQL 身份验证账号。配置好适当的权限，这里要注意的一点，很多人虽然前面都做了，但是忽略了对账号的“默认数据库”选项做配置，如果你开了一个仅能访问某个用户库的账号，但又把默认数据库选项指到master库，一方面不安全，另外一方面可能出现登录失败的情况。默认情况下，master和tempdb是对任何账号都允许读的，但是其他库就不一样，如果你把某个账号的默认数据库指定到Msdb，但是这个账号没有对该库的任何权限，那么这个账号登录时就会出现登录失败的情况，也就是SQL Server错误日志中出现的“Login failed for user 'xx'. 原因: 无法打开在登录名属性中指定的数据库。”这种消息。这里根据个人经验，我建议对开发环境下，开发专用的账号直接指定到开发库。对于正式环境，大部分账号可以考虑直接指到tempdb，tempdb的作用估计大家都知道得七七八八了。所以就不累赘了。

3．开发账号权限和密码可以适当低一点。但是sa账号，任何环境下仅只能少数人知道，并且禁用，作为备用就好。周期性修改密码是一个不错的选择。记住，不要以为内部人员就可以随意，对于正规公司，不管如何管理其他账号，都应该对sa做好管理，另外作为经验之谈，要在确保你最少有一个已知密码且还在启用的前提下才去对sa和Windows 的内置账号进行操作，否则很容易就出现SQL Server无法使用的情景，如果真出现所有账号都全被禁用或删掉的情况，可以尝试使用下面的方法，不保证万能，但是在没有办法的情况下是可以尝试的：

SQL Server 中 Windows账号被删的解决方法：

启用本地账户：

1.先看一下本机的账户是否具有管理员的权限，如果没有添加上。

2.在开始菜单的搜索框中输入 cmd , 右键单击选择以管理员身份运行

3.在命令提示符输入 NET STOP MSSQLSERVRE 停止MSSQLSERVER运行（若已经停止则可以不用此方法）

4.若3有问题，提示报错，则可以在开始 -->SQL SERVER --> 配置工具 -->SQL SERVER 服务 --> 打开SQL SERVER属性-->高级 --> 启动参数里面加上 -m

5.若以上均无问题，则切换到安装路径，即Binn下sqlservr.exe的路径如：cd C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn 

6.执行 sqlservr.exe,即单用户模式进入了

7.再以管理员账户重新登陆开启一个窗口，输入SQLCMD -A

8.输入你要更改的操作命令即可，在此处我需要的是把本机账户添加 如：

   

USE masterGOCREATE LOGIN [需要添加的账号，一般格式是 机器名\登录账号名] FROM WINDOWS WITH DEFAULT_DATABASE=[Master]GOEXEC sp_addsrvrolemember @loginame=N'机器名\登录账号名', @rolename=N'sysadmin'GO

为了避免错误，可以再加一个SQL的账户以备不时之需， 也可以把sa命令启用

9.以上操作完成之后重新启动SQL SERVER服务登陆即可

另外几篇文章也可以参考一下：

1. http://www.cnblogs.com/lyhabc/p/3513560.html

2. http://sqlserver-help.com/2012/02/08/help-i-lost-sa-password-and-no-one-has-system-administrator-sysadmin-permission-what-should-i-do/

3. http://jimshu.blog.51cto.com/3171847/1563207

本文虽然很简单，但是其实很实用，符合我前面说过的“可能会大面积有助于别人的文章”。大半年没写文章，现在需要点时间慢慢恢复，大家别太在意文笔吧。