SQL Server的安全性是由多个层次构成的：网络、操作系统、服务器以及数据库。这些层次需要分别进行加强，因为它们其中任何一个出现问题都会导致整个方案的失败。

　　网络和操作系统安全已经在本系列文章的第一部分讨论过。本文将探讨数据库和服务器层面的保护。

　　服务器安全属性

　　在服务器属性选项卡中，可以通过xp_cmdshell指定一个“服务器代理帐号”。我再次强烈推荐，如果使用xp_cmdshell，我推荐给代理帐号优先较低的权限。

　　特别地，服务器属性中有2个值得注意的设置：Enable C2审计跟踪和Enable Common Criteria规范。

　　Enable C2审计跟踪允许跟踪数据驱动的对象访问——包括成功或失败的，除非有专门的控制或服务器关闭，它会随着时间一直增长。

　　Enable Common Criteria规范会导致内存在被重新分配前被重写。虽然这能够增强系统的安全性，但内存的申请会减慢。而且，这个选项也会改变登录审计和权限设置。因此，在打开这个选项之前，应该要小心设计数据库权限，以及性能需求。

　　SQL Server SSL安全性

　　SQL Server Configuration Manager控制所有SSL使用。

　　如果安装了证书，右击“Protocols for S2K8”，然后选择“Properties”，就会出现下面的屏幕。

　　在“Flags”和“Certificate”选项卡中，可以指定是否需要强制加密。

　　在一个高度安全的生产系统，最好是选择强制加密。我推荐在生产系统中设置“Hide Instance”为“Yes ”。这是因为在一个生产系统中允许SQL Server浏览服务定位一个实例会使定位和攻破一个生产SQL Server变得更容易。

　　而且，在生产环境中，最好避免使用自有签名证书，因为它可能被中间人攻击所攻破——中间人攻击是通过单独连接每一个目标并延迟它们之间的消息来进行窃听的攻击方式。在开发/QA环境中，这将取决于系统所需要的工作安生性级别。

　　SQL Server终端安全性

　　当一个终端创建后，要保证状态只有在需要时才启动，同时使用一个非标准端口(通知网络组端口号以及使用的TCP协议)和允许/要求的加密。

　　只有需要的端口才应该打开，并且只打开要求的协议。假定网络不是加密流量，我建议设置加密为“required”。在下面的情况中，其它终端将必须设置为必需的(或支持的)。

　　CREATE ENDPOINT endpoint_mirroring

　　STATE = STARTED

　　AS TCP ( LISTENER_PORT = 8035 )

　　FOR DATABASE_MIRRORING (

　　AUTHENTICATION = WINDOWS KERBEROS, ENCRYPTION = SUPPORTED,

　　ROLE=ALL);

　　下一步是给终端赋予权限。考虑到安全性问题，我建议不要使用基本的认证。同时还应该限制连接访问到最少的登录可能。更好的做法是，使用仅限于这个终端或在企业中使用范围很小的登录身份。

　　GRANT CONNECT on ENDPOINT::endpoint_mirroring TO [DomainConnectingUser];

　　GO

　　SQL Server服务帐号安全性

　　每一个SQL Server服务应该用不同的Active Directory (AD)帐号安装。绝不应该给一个SQL Server服务单独一个AD帐号域管理员。

　　这是因为人们都会有懒性而牺牲安全性来简化使用方法。每一个SQL Server服务都应该使用不同的帐号，因为每一个服务都使用要求锁定不同权限的不同的功能领域。另一方面，你的SQL Server服务AD帐号也可能不需要访问Internet或交互登录的权限。

　　在数据库系统中，整个系统的任何一个方面的缺陷都可能被利用来获取重要系统的访问。因此，重要的是要考虑各个系统层——网络、操作系统、服务器和数据库——是互联的。