SQL Server 2008安全性探讨
发布时间：2012-08-29 09:29 来源：未知
SQL Server身份验证模式
Microsoft SQL Server 2008提供了两种对用户进行身份验证的模式，默认模式是Windows身份验证模式，它使用操作系统的身份验证机制对需要访问服务器平局进行身份验证，从而提供了很高的安全级别。另一种方式是SQL Server和Windows身份验证模式，允许基于Windows的和基于SQL的身份验证。因此，它又是被称为混合模式。Windows身份验证模式允许使用存储在本地计算机的安全帐户管理器SAM数据库中的现有帐户，或者，假如该服务器是活动目录域的一个成员，则可以使用Micorsoft Windows活动目录数据库中的帐户。使用Windows身份验证模式的好处包括允许SQL或数据库管理员使用已经存在的帐户，从而减少管理开销，以及允许他们使用强大的身份验证协议，例如Kerberos或Windows NT LAN Manager（NTLM）。在Windows身份验证模式中，SQL并不存储或需要访问用于身份验证的密码信息。Windows身份验证提供程序将负责验证用户的真实性。混合模式允许创建SQL Server独有的登录名，这些登录名没有相应的Windows或活动目录帐户。这可以帮助那些不属于您的企业的用户通过身份验证，并获得访问数据库中安全对象的权限。当使用SQL登录名时，SQL Server将用户名和密码信息存储在master数据库中，它负责对这些平局进行身份验证。
主体
主题Principal这个术语用于描述将与SQL Server交互的个人、组和进程。主题可用的资源取决于他们的位置。Microsoft SQL Server支持集中不同类型的主题，他们定义在三个不同的级别上:Windows级别、SQL Server级别和数据库级别。
登录名
和SQL 以前的版本不同，SQL Server 2008并不自动为[BUILTIN\Administrators]组创建登录名，以免使服务器上具有本地管理权限的任何人都可以登录进该SQL Server。相反，必须在安装向导中设置帐户时添加管理员，或在安装后将管理员添加到sysadmin角色。同时还创建一个SQL登录名sa，sa帐户对于所有的SQL功能拥有完全管理访问权限。在安装时，系统会提示为sa帐户指定密码。
CREATE LOGIN [AughtEight\Bob] from Windows; GO CREATE LOGIN [AughtEight\G NorthWest Sales] from Windows; GO CREATE LOGIN Carol PASSWORD='Th1sI$|\/|yP@ssw0rd'; GO ALTER LOGIN Carol WITH PASSWORD='newpassword', CHECK_POLICY=OFF; GO DROP LOGIN [AughtEight\Bob]; GO
凭据 Microsoft SQL Server 2008提供了一个将SQL Server登录名映射到外部Windows帐户的功能。假如需要允许SQL Server登录名与SQL Server本身范围之外的资源交互，这个功能很有帮助。他们还可以与为EXTERNAL_ACCESS权限配置的程序集一起使用。凭据可以配置为一对一映射，也可以配置为多对一映射，允许多个SQL Server登录名使用一个共享Windows帐户进行外部访问。在SQL Server 2008中，登录名可以与多个凭据相关联。 --使用自己的服务器名称替代AughtEight USE master CREATE CREDENTIAL StreetCred WITH IDENTITY='AughtEight\CarolStreet', SECRET='P@ssw0rd'; GO --把Carol的SQL Server登录名和StrretCred平局相关联 ALTER LOGIN Carol WITH CREDENTIAL=StreetCred; GO;
服务器角色 Microsoft SQL Server 2008定义了8个可用于简化SQL 登录名管理和委托管理的服务器级别角色。这些角色通常被称为固定服务器角色，因为对于这些角色，唯一能更改的只是成员资格。固定服务器角色可以基于角色的用途，为一个登录名自动支配一组通用权限。要向固定服务器角色添加一个登录名，可使用sp_addsrvrolemember存储过程。 USE master CREATE LOGIN Ted WITH PASSWORD='P@ssw0rd'; GO EXEC sp_addsrvrolemember 'Ted','securityadmin'; GO USER master EXEC sp_dropsrvrolemember 'Ted','securityadmin'; GO
数据库用户 数据库用户是Microsoft SQL Server 2008采用的安全模型的另一个组成部分。用户可直接或通过一个或多个数据库角色中的成员关系访问安全的数据库对象。用户也可与表、视图和存储过程之类的对象的所有权相关联。 在创建登录名时，除非它是拥有所有数据库管理权限的固定服务器角色的一个成员，否则该登录名在附加到服务器的各数据库中没有显示权限。此时，该登录名和来宾数据库用户关联在一起，并继承该用户帐户的权限。在SQL Server Management Studio管理数据库用户时，有几个选项可供选择。在常规属性页上，可以为用户指定一个名称，并将该用户和一个现有的登录名关联起来。注意，用户名和登录名并不一定要匹配，但是为了方便管理，最好的做法是使用一致的命名约定，但这并不是强制要求。在常规页上可以配置的其他选项包括用户的默认架构、该用户所拥有的架构以及该用户所属的数据库角色。 USE tempdb; CREATE USER Carol; GO USE master; CREATE LOGIN [AughtEight\Bob] FROM WINDOWS; USE AdventureWorks2008; CREATE USER BillyBob FOR LOGIN [AughtEight\Bob] WITH DEFAULT_SCHEMA=sales; USER AdventureWorks2008; CREATE CERTIFICATE SalesCert ENCRYPTION BY PASSWORD='P@ssw0rd' WITH SUBJECT='Sales Schema Certificate', EXPIRY_DATE='12/31/2010'; GO CREATE USER SalesSecurity FOR CERTIFICATE SalesCert; USE AdventureWorks2008 ALTER USER SalesSecurity WITH NAME=SalesSchemaSecurity; GO USE AdventureWorks2008 ALTER USER BillyBob WITH DEFAULT_SCHEMA=Production; GO USE master CREATE LOGIN TempCarol WITH PASSWORD='MyPassword', CHECK_POLICY=OFF; GO USE tempdb ALTER USER Carol WITH Login=TempCarol; GO USE AdventureWorks2008 DROP USER BillyBob; GO
固定数据库角色 每个SQL Server数据库都有一系列固定数据库角色，可用于在必要时把权限委托给用户。和固定服务器角色一样，对于固定数据库角色来说，唯一可以改变的就是成员资格。用户定义的数据库角色对管理权限和对数据库中的资源的访问提供了更多的控制。在使用基于角色的安全模型时，可能京城发现内置主体（比如Windows中的组或SQL中的角色）提供了过得uod访问权限，或者没有提供足够的权限。在这种情况下，可以创建用户定义的角色，控制整个一组用户对安全对象的访问。 USE AdventureWorks2008 CREATE ROLE SalesStaff AUTHORIZATION Carol; GO USE AdventureWorks2008 ALTER ROLE SalesStaff WITH NAME=SalesStaffRole; GO USE AdventureWorks2008 DROP ROLE SalesStaffRole; GO USE AdventureWorks2008 EXEC sp_addrolemember 'db_datareader','Carol'; GO USE AdventureWorks2008 EXEC sp_droprolemember 'db_datareader','Carol'; GO
另外一种可以用来帮助保护数据库环境的角色是应用程序角色。应用程序角色和标准的角色类型截然不同，他们没有成员，可以而且应该被设置为使用密码进行身份验证。当运行一个特定的应用程序的所有用户必须采用同样的数据访问时，通常使用应用程序角色。应用程序可以不需要提示用用提供用户名和密码就实例化应用程序角色，从而避免了依赖于个人用户是否拥有适当的访问权限让应用程序正常工作。 USE AdventureWorks2008 CREATE APPLICATION ROLE SalesApp WITH PASSWORD='P@www1rd',DEFAULT_SCHEMA=Sales; GO USE AdventueWorks2008 GO DECLARE @cookie varbinary(8000); EXEC sp_setapprole 'SalesApp','P@ssw0rd',@fCreateCookie=true,@cookie=@cookie OUTPUT; GO SELECT USER_NAME();
一旦执行了上述脚本，该连接执行的所有活动都将在该应用程序角色下操作。当关闭连接时，应用程序角色会话也终止。通过ALTER APPLICATION ROLE语句，可以更改应用程序角色的名称、密码和默认架构。 USE AdventureWorks2008 ALTER APPLICATION ROLE SalesApp WITH NAME=OrderEntry,PASSWORD='newP@ss0rd'; GO USE AdventureWorks2008 DROP APPLICATION ROLE OrderEntry; GO
权限 在对象或资源上定义权限的语句会定义一个权限状态、一个操作、奖项哪个对象应用权限和操作，以及权限和动作将应用于哪个安全主体。首先，需要知道基本上有三种权限状态：GRANT,GRANT_W_GRANT和DENY。用于控制权限状态的三个命令为GRANT,REVOKE和DENY。 SQL Server 2008使用一个分层的安全模型，允许指定可在服务器、数据库、架构或者对象级别授予的权限。也可以在表和视图内为选定列指派权限。在保护数据库服务器时，应使用两个关键策略：在授权时应当采用的第一个策略为”最小特权原则“，这一策略规定只向用户提供适当的权限进行操作。通过对数据库环境做出这样严格的限制，可以提供一个能最小化服务器的受攻击面，同时又维护运行功能的解决方案。第二个策略是深度防御。好的安全实现方案应在数据库的所有层上提供安全性。这可能包括针对客户机和服务器之间的通信采用IPSec或SSL，在身份验证服务器上使用强密码加密以及在表或视图中配置列级权限。 服务器权限 可以通过制定权限以及将被指派权限的登录名来管理服务器控制权限，如： --将创建数据库的权限授予登录名Ted USE master GRANT CREATE ANY DATABASE TO Ted; GO --Ted有权更改该登录名及允许其他人更改登录名 USE master GRANT ALTER ANY LOGIN TO Ted WITH GRANT OPTION; GO --删除Ted的更改登录名的能力 USE master REVOKE ALTER ANY LOGIN TO Ted CASCADE; GO --禁止Ted创建新数据库 USE master DENY CREATE ANY DATABASE TO Ted; GO
但是，对于一个登录名或用户时否能够执行某一特定的操作而言，DENY和EVOKE并不总是终极答案，假如某登录名是sysadmin固定服务器角色的一个成员，该登录名就可以完全控制SQL Server及其资源，而且组织此登录名访问服务器上的对象没有太大意义。 端点是服务器级别的对象，在授予、撤销和拒绝时，它使用的语法和服务器权限有一些不同。下面的例子创建了一个名为ServiceBroker的端点，它将被用于一个Service Broker应用程序，然后将该端点的ALTER权限授予Ted： CREATE ENDPOINT ServiceBroker STATE=STARTED AS TCP (LISTENER_PORT=5162) FOR SERVICE_BROKER (AUTHENTICATION=WINDOWS); GO USER master GRANT ALTER ON ENDPOINT :: ServiceBroker TO Ted; GO USE master GRANT ALTER ON LOGIN::Ted TO Carol WITH GRANT OPTION; GO
数据库的作用域权限 USE AdventureWorks2008 CREATE USER Alice FOR LOGIN [AughtEight\Alice] WITH DEFAULT_SCHEMA=SALES; GO GRANT CONTROL ON SCHEMA::Sales TO Alice
架构作用域权限 Use AdventureWorks2008 GRANT SELECT, UPDATE ON Person.Person to Alice GO
SQL Server加密 关于SQL Server 2008使用的加密层级结构，顶层是Windows层，其中包括Windows Data Protection API (DPAPI)。DPAPI负责使用本地机器密钥加密服务的服务主密钥。服务主密钥是SQL环境中加密链的顶层。首次创建低级别的密钥时，系统会自动生成服务主密钥。 服务主密钥的下面是数据库主密钥Database Master Key。数据库主密钥可以保护数据库中所有证书的私钥和非对称密钥的私钥。它是采用3DES加密算法和密码加密的对称密钥。该密钥的副本使用服务主密钥加密，并存储在主数据库和应用它的数据库中。假如数据库被转移到另一个服务器上，可以使用OPEN MASTER KEY语句并提供加密密码来解密数据库主密钥。 在数据库作用域中，还有可用于加密数据库的对称密钥和非对称密钥，以及可以用于数字签名和实现不可否认性的证书。 应该首先创建数据库主密钥，记住数据库主密钥是对称密钥，用来加密数据库中的所有私有密钥数据。假如使用非对称密钥或证书，这是非常有用的，因为创建它们时不需要提供密码或其它保护与双方关联的私钥的机制。要为AdventureWorks2008数据库创建一个新的主密钥，可以执行下面的命令： USE AdventureWorks2008 CREATE MASTER KEY ENCRYPTION BY PASSWORD='P@ssw0rd'; GO
创建主密钥需要数据库的CONTROL权限，假如已经创建了一个主密钥，那么要想创建新的主密钥，必须删除现有的主密钥。假如现有的主密钥已被用来加密数据库中的一个私钥，那么就不能删除它了。一旦创建了主密钥，就可以查询sys.database目录视图，通过is_master_key_encrypted_by_server列查看该数据库主密钥是否已经使用服务主密钥加密。该列使用一个布尔值表明数据库主密钥是否使用服务主密钥加密。假如数据库主密钥是在另一个服务器上创建的，该值就为0 SELECT NAME, [is_master_key_encrypted_by_server] FROM sys.databases
在继续讨论使用其他密钥之前，让我们看一下如何备份服务主密钥和数据库主密钥。假如必须进行灾难恢复，且需要恢复使用这些密钥之一加密的数据，那么这将是相当有用的。梁宗密钥的语法是相似的，但需要额外的一部来备份加密的数据库主密钥。 首先看服务主密钥，在BACKUP SERVICE MASTER KEY语句中使用一个文件路径，可以是一个本地或UNC路径，以及一个满足密码复杂度要求的密码，备份文件时使用密码可以防止他人将您的主密钥还原到另一台服务器上，然后解密您的数据库主密钥 BACKUP SERVICE MASTER KEY TO FILE='C:\KyeBackups\ServiceMasterKey' ENCRYPTION BY PASSWORD='c@MplexP@ssw0rd'; --假如需要还原该服务主密钥，可使用 RESTORE SERVICE MASTER KEY FROM FILE='C:\KyeBackups\ServiceMasterKey' DECRYPTION BY PASSWORD='c@MplexP@ss0rd';
备份和还原数据库主密钥的方法如下： --Backup the database master key USE AdventureWorks2008; OPEN MASTER KEY DECRYPTION BY PASSWORD='P@ssw0rd' BACKUP MASTER KEY TO FILE='C:\KyeBackups\AWorksMasterKey' ENCRYPTION BY PASSWORD='dn9e8h93ndwjKJD'; GO --Restore the database master key USE AdventureWorks2008; RESTORE MASTER KEY FROM FILE='C:\KyeBackups\ServiceMasterKey' DECRYPTION BY PASSWORD='dn9e8h93ndwjKJD' ENCRYPTION BY PASSWORD='P@ss0rd' GO
可扩展的密钥管理 SQL Server 2008中一项最重要的新功能是可扩展的密钥管理EKM,Extensible Key Management，它使用Microsoft Cryptographic API,MSCAPI在SQL Server 2008环境的外部生成和存储用于数据和密钥加密的加密密钥。这通常通过使用HSM,Harware Security Model，硬件安全模块实现，HSM供应商可创建一个与MSCAPI连接的提供程序，提供一部分HSM功能给SQL Server 2008和其他利用MSCAPI的应用程序，遗憾的是，由于MSCAPI用作HSM与SQL Server之间的中间层，它无法将HSM的所有功能提供给SQL Server。 为了使用EKM，必须首先在服务器上启用它。它默认是关闭的，但可通过sp_configure命令打开。由于启用EKM是高级功能，因此必须制定shwo advanced配置，下面的实例展示了如何为服务器打开EKM： sp_configure 'show advanced',1; GO RECONFIGURE GO sp_configure 'EKM provider enabled',1; GO RECONFIGURE GO
在启用了EKM后，现在可以在HSM模块、智能卡或USB设备上存储加密密钥。不管何时使用存储在这些设备上的密钥加密数据，要解密数据，必须连接上这些设备。这颗防止未授权的用户将数据库文件复制并放至欺骗性服务器，从而访问所有秘密数据。 对称密钥 如前所述，对称密钥提供了一个用于加密大量数据的有效模型。使用同样的密钥来加密和解密可以把资源开销降低到最低，生成对称密钥的语法： CREATE SYMMETRIC KEY name [AUTHORIZATION owner] [FROM PROVIDER] providername WITH options ENCRYPTION BY mechanism
下面的例子创建了一个名为SalesKey1的新的对称密钥，该密钥使用的是192为的3DES（3KEY）算法： USE AdventureWorks2008 GO --Create Symmetric Key CREATE SYMMETRIC KEY SalesKey1 WITH ALGORITHM=TRIPLE_DES_3KEY, KEY_SOURCE='The quick brown fox jumped over the lazy dog', IDENTITY_VALUE='FoxAndHound' ENCRYPTION BY PASSWORD='9348hsxasnA@B'; GO
可以使用ALTER SYMMETRIC KEY语句添加或删除用于加密密钥的方法，也可以使用DROP SYMMETRIC KEY语句删除对称密钥。在这个例子里，使用之前在数据库用户中创建的SalesCert证书来加密对称密钥，然后删除前例中的密码加密 --Open the symmetric key OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY PASSWORD='9348hsxasnA@B' --Add encryption using the certificate created earlier ALTER SYMMETRIC KEY SalesKey1 ADD ENCRYPTION BY CERTIFICATE SalesCert --Remove the password encryption LATER SYMMETRIC KEY SalesKey1 DROP ENCRYPTION BY PASSWORD='9348hsxasnA@B' --Close the symmetric key CLOSE SYMMETRIC KEY SalesKey1
非对称密钥 CREATE ASYMMETRIC KEY name [AUTHORIZATION owner] [FROM key_source] WITH ALGORITHM=algrithm [ENCRYPTION BY PASSWORD='password']
在创建非对称密钥时，可以指定密钥对的所有者和密钥源（可以是一个强名称文件、一个程序集或一个可执行的程序集文件）另外，也可以使用一个决定私钥使用的位数的算法，选择密钥成俗是512，1024还是2048位，还可以使用ENCRYPTION BY PASSWORD选项来加密私钥。假如没有指定密码，数据库主密钥将加密私钥 USE AdventureWorks2008 CREATE ASYMMETRIC KEY HumanResources WITH ALGORITHM=RSA_2048; GO
可以使用ALTER ASYMMETRIC KEY语句更改密钥对的属性，可以使用REMOVE PRIVATE KEY选项将私钥从数据库中删除（确保已经先备份过私钥），或者可以更改保护私钥的方式。例如，可以更改用来加密私钥的密码，然后把保护方式从密码改为数据库主密钥，反之亦然。下面的代码，通过密码加密在过去不久的文章里的例子中创建的HumanResouces密钥对中的私钥： USE AdventureWorks2008 ALTER ASYMMETRIC KEY HumanResources WITH PRIVATE KEY (ENCRYPTION BY PASSWORD='P@ssw0rd')
下面的例子中，通过先解密，然后用一个新的密码重新加密的方式更改用于加密私钥的密码 USE AdventureWorks2008 ALTER ASYMMETRIC KEY HumanResources WITH PRIVATE KEY(DECRYPTION BY PASSWORD='P@ssw0rd',ENCRYPTION BY PASSWORD='48UFDSJehf@*hda'); GO
证书 在加密方面，公钥证书和非对称密钥的操作方式一样，不过，密钥对被绑定到证书。公钥包含在省属详细信息中，而私钥必须被安全地归档。与证书关联的私钥必须用密码、数据库主密钥或另外一个加密密钥保护。在加密数据时，最好的做法是使用一个对称密钥加密数据，然后使用公钥加密该对称密钥。 当创建一个自签名证书时，可以使用CREATE CERTIFICATE语句。可以选择一个强密码或者数据库主密钥加密私钥。或者也可以使用CREATE CERTIFICATE语句从一个文件导入证书或私钥。另外，可以基于已签名的程序集创建证书。 在证书创建完成之后，可以使用ALTER CERTIFICATE语句修改证书。可以执行的更改包括改变保护四方的方式或从SQL Server中删除私钥。只有证书被用于验证数字签名时才需要杉树私钥。假如公钥被用来加密数据或对称密钥，那私钥应当可以解密。在创建证书时最好使用BACKUP CERTIFICATE语句备份证书和关联的私钥。您可以只备份证书而不归档私钥，使用公钥来验证或加密只能用私钥解密的信息。 一旦证书不需要，可以使用DROP CERTIFICATE语句删除。假如证书仍然和其他对象关联，则无法删除。 --Create the Personnel Data Certificate USE AdventureWorks2008; CREATE CERTIFICATE PersonnelDataCert ENCRYPTION BY PASSWORD='HRcertific@te' WITH SUBJECT='Personnel Data Encryption Certificate' EXPIRY_DATE='12/31/2011'; GO --Backup the certificate and private key to the file system Use AdventureWorks2008 BACKUP CERTIFICATE PersonnelDataCert TO FILE='c:\certs\Personnel.cert' WITH PRIVATE KEY (DECRYPTION BY PASSWORD='HRcertific@te', FILE='c:\certs\Personnelkey.pvk', ENCRYPTION BY PASSWORD='@notherPassword'); GO --Import the certificate and private key into the TempDB database USE tempdb CREATE CERTIFICATE PersonnelDataCert FROM FILE='c"\certs\Personnel.cer' WITH PRIVATE KEY (FILE='c:\certs\Personnelkey.pvk', DECRYPTION BY PASSWORD='@notherPassword', ENCRYPTION BY PASSWORD='TempDBKey1'); GO --更改用于加密私钥的密码 USE tempdb ALTER CERTIFICATE PersonnelDataCert WITH PRIVATE KEY (ENCRYPTION BY PASSWORD='P@ssw0rd789', DECRYPTION BY PASSWORD='TempDBKey1') USE AdventureWorks2008 ALTER CERTIFICATE PersonnelDataCert REMOVE PRIVATE KEY GO USE tempdb DROP CERTIFICATE PersonnelDataCert; GO
加密数据 并不是每一种数据类型都可以使用EncryptByKey函数加密。有效的数据类型是nvarchar、char、wchar、varchar和nchar。表或视图中常备查询的列不应加密，因为解密大量会被一再查询的数据的过程通常会得不偿失。加密数据之前，必须打开将执行加密过程的密钥。数据通常手对称密钥保护，而对称密钥又受到非对称密钥对保护。假如对称密钥手密码保护，那么对对称密钥和密码有ALTER 权限的用户都可以打开和关闭对称密钥。假如对称密钥由一个非对称密钥或证书保护，用户还需要拥有对非对称密钥或证书上的CONTROL权限 ALTER TABLE Sales.CreditCard ADD EncryptedCardNumber varbinary(128); GO OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY CERTIFICATE SalesCert WITH PASSWORD='P@ssw0rd' UPDATE Sales.CreditCard SET EncryptedCardNumber=EncryptByKey(Key_GUID('SalesKey1'),CardNumber); GO CLSE SYMMETRIC KEY SalesKey1; GO ALTER TABLE Sales.CreditCard ADD DecryptedCardNumber NVARCHAR(25); GO OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY CERTIFICATE SalesCert WITH PASSWORD='P@ssw0rd'; GO UPDATE Sales.CreditCard SET DecryptedCardNumber=DecryptByKey(EncryptedCardNumber); GO CLOSE SYMMETRIC KEY SalesKey1; GO Select TOP(10) CreditCardID, CardNumber AS Original, EncryptedCardNumber AS Encrypted, DecryptedCardnumber AS Decrypted FROM Sales.CreditCard; GO
不过，可以在SELECT语句中至此那个DecryptByKey函数来查看为加密的数据 OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY CERTIFICATE SalesCert WITH PASSWORD='P@ssw0rd'; GO SELECT CreditCardID, CardNumber, EncryptedCardNumber AS 'Encrypted Card Number', CONVERT(nvarchar, DecryptByKey(EncryptedCardNumber)) AS 'Decrypted Card Number' FROM Sales.CreditCard; GO CLOSE SYMMETRIC KEY SalesKey1;
透明数据加密 SQL Server 2008的另一项新工能是透明数据加密（TDE,Transparent Data Encryption）。TDE被设计为针对启用了TDE的数据库或事务日志文件，使用数据库加密密钥（DEK,Database Encryption Key）执行实时IO加密。TDE的好处是它保护处于休眠状态的所有数据。这意味着当前未读入内存的数据都是用DEK保护。不过，当查询运行时，从查询检索的数据将在被读入内存时解密。与使用对称和非对称密钥解密单个表或列中的数据不同，在读或写受TDE保护的数据库中的表时，不必调用解密函数。 设置TDE比其他加密方法要复杂些，因为在启用它之前有一些条件必须满足：首先，master数据库中必须有一个数据库主密钥；其次，必须在master数据库中创建或安装一个可用于加密DEK的证书，或者可以使用EKM提供程序的非对称密钥；然后，需要在将加密的数据库中创建DEK，最后，在数据库中启用加密。 USE master CREATE MASTER KEY ENCRYPTION BY PASSWORD='MyStrongP@ssw0rd'; GO CREATE CERTIFICATE AughtEightTDE WITH SUBJECT='TDE Certificate for the AUGHTEIGHT Server'; GO USE AdventureWorks2008 CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM=TRIPLE_DES_3KEY ENCRYPTION BY SERVER CERTIFICATE AughtEightTDE; GO ALTER DATABASE AdventureWorks2008 SET ENCRYPTION ON; GO
数字签名 数字签名提供身份验证和不可否认性。同城，公钥私钥对用于对消息进行数字签名。下面是数字签名如何和电子邮件消息一起工作的例子。 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保护休眠中的数据：加密数据库和事务日志文件可降低他人复制数据文件并卷走敏感的商业数据的可能性 总是备份数据加密密钥：这是显而易见的，但要确保安全可靠地备份用于加密数据的密钥或其他加密密钥。同时测试备份和恢复策略 了解您在公司安全策略中的角色：大多数组织都有一个备案的安全策略，定义了可接受的网络使用，以及对服务器或服务行为的期望。作为一名数据库管理员，配置和保护服务器的职责可能会被备案为总体安全策略的一部分。对数据库管理员以及服务器的期望必须明确表述。同时，也应清楚贵的管理员的责任。 原文链接：http://www.cnblogs.com/xupengnannan20070617/archive/2012/08/28/2658718.html
