数字签名

数字签名提供身份验证和不可否认性。同城，公钥私钥对用于对消息进行数字签名。下面是数字签名如何和电子邮件消息一起工作的例子。

Bob给Alice发送了一条信息，而他的邮件客户端被配置为自动为所有发出的消息添加他的数字签名。在这种情况下，当消息准备好发送时，系统会生成一个密钥，然后传递给一个哈希算法，将数据单向转换为一个哈希值。哈希值附加在消息上，而用于生成哈希值的密钥由Bob的私钥加密。该消息发送给了 Alice，她接受明文形式的消息，以及该消息的哈希值版本。Alice具有访问Bob的公钥的权限，使用该公钥解密用来生成哈希值的密钥。于是该密钥被传递给哈希算法，生成一个新的哈希。如果新的哈希与原来的随消息一起发送的哈希匹配，Alice可以确信该消息在发送过程中没有被更改。如果哈希值不匹配，那么说明该消息在发送之后已经被更改，不应被信任。

下面的代码创建了一个名为Sales.DisplaySomeVendors的简单存储过程。然后可以使用前面的SalesCert证书给该存储过程添加一个签名。需要解密该西药来对该存储过程进行数字签名：

CREATE PROCEDURE Sales.DisplaySomeVendors AS SELECT TOP (20) * FROM Purchasing.Vendor; GO 
USE AdventureWorks2008; ADD SIGNATURE TO Sales.DisplaySomeVendors BY CERTIFICATE SalesCert WITH PASSWORD='P@ssw0rd'; GO 

最佳实践

与其他应用程序和服务器产品一样，应遵循一些指导原则来帮助提升安全级别。记住，你永远都不可能为每个可能的威胁做好准备，但是可以让恶意用户更难访问数据

使用强密码：应当利用密码策略，要求用户创建定期更改的复杂密码

不要以sa帐户登录：尽量少使用sa帐户。必须要求用户使用他们自己的登录名，从而可以跟踪那个用户在执行什么操作。

对SQL服务使用最小特权帐户：应用最小特权原则，并使用用有正好满足服务需要的权限的帐户

定期审核主体：勤勉的管理员会知道自己创建哪些帐户和谁要为这些帐户负责，并且知道需要采取哪些步骤禁用或删除多余的帐户

禁用或删除所有不使用的网络协议：在SQL Server配置管理器中，可以启用或禁用SQL Server使用的协议。

使用在线加密保护传输中的数据：仅仅保密服务器上的数据是不够的，应使用诸如SSL和IPSec等技术在数据从客户端向服务器、从服务器向客户端或从服务器向服务器移动时保护他们

不要把SQL Server放在物理安全性低的地方：如果恶意用户能够实地访问您的计算机，那么这台计算机就相当于别人的了

最小化服务器的可见度：Slammer蠕虫病毒可以大量快速传播是因为很少组织意识到在自己的防火墙中开放SQL连接的害处。设计良好的数据库应用程序会使用一个健壮而安全的前端，把数据库引擎的可见度降到最低。

删除或禁用不必要的服务和应用程序：应该关掉不使用的服务和功能，从而最小化SQL Server的受攻击面

尽可能使用Windows身份验证：Windows和Kerberos身份验证本身都比SQL身份验证更加安全，但这是您和您的应用程序开发人员和安全小组都必须遵守的设计决策

不要对经常被搜索的列进行加密：加密经常被访问或搜索的列导致的问题可能比它解决的问题还要多

使用TDE保护休眠中的数据：加密数据库和事务日志文件可降低他人复制数据文件并卷走敏感的商业数据的可能性

总是备份数据加密密钥：这是显而易见的，但要确保安全可靠地备份用于加密数据的密钥或其他加密密钥。同时测试备份和恢复策略

了解您在公司安全策略中的角色：大多数组织都有一个备案的安全策略，定义了可接受的网络使用，以及对服务器或服务行为的期望。作为一名数据库管理员，配置和保护服务器的职责可能会被备案为总体安全策略的一部分。对数据库管理员以及服务器的期望必须明确表述。同时，也应清楚贵的管理员的责任。