以下是引用片段: USE AdventureWorks GO CREATE SYNONYM History FOR HumanResources.EmployeeDepartmentHistory SELECT * FROM History |
你还可以为完整的四部分名称定义History 同义字,如下面的代码所示:
以下是引用片段: CREATE SYNONYM History FOR MyServer.AdventureWorks.HumanResources.EmployeeDepartmentHistory |
使用像这样的完整的四部分名称允许使用从另一个数据库上下文得到的同义字,假设当前的用户具有使用这个同义字和读取表的权限:
以下是引用片段: USE pubs SELECT * FROM AdventureWorks..History |
还要注意,如果你不提供一个schema名称作为新的同义字名称的一部分,那它将成为默认schema 的一部分。
5. 加密和密钥管理
服务器级别的安全可能是系统管理员最为关注的,但是数据库是一个生产环境中所有活动发生的地方。对于大多数情况,数据库管理员可以让数据库开发人员关注于数据库的细节,只要开发人员是在环境的约束之下。SQL Server 2008提供了大量的特性用于保护数据库。
5.1 数据加密
SQL Server 2000 和之前的版本没有对数据库中存储的数据进行加密的内置支持。为什么你需要对安全地放置在防火墙之后的很安全的服务器上存储在很安全的数据库中的数据进行加密?这是因为有一个出现了几年的重要的安全原则——defense in depth。Defense in depth意味着分层防范,以便即使攻击者突破了你最外层的防御,他们还是需要再通过层层防御才能抵达中心。在一个数据库中,这意味着如果一个攻击者通过了防火墙和服务器上的Windows安全后抵达了数据库,她还是需要作些工作来试图解析你的数据。而且,在数据和隐私受到法律保护的今天,数据需要进行强有力的保护。
SQL Server 2008使用对称和非对称密钥以及数字证书提供了对广泛的数据加密种类的大力支持。最重要的是,它为你管理密钥,因为到目前为止,密钥管理是最难加密的部分。保密秘密绝非易事。
作为一个管理员,你可能至少要管理密钥层级的上层,如图10所示。数据库管理员需要了解服务器级别的服务主密钥和数据库级别的数据库主密钥。每一个密钥保护它的子密钥,而这些子密钥反过来保护它们自己的子密钥,这样在树型结构中传递下去。一个例外就是当一个密码是保护一个同义字密钥或证书的时候,这是SQL Server 让用户管理他们自己的密钥和保证密钥的隐密性的方式。
图 10:SQL Server 2008中的加密密钥层次
注意 Microsoft建议不要直接使用证书或非对称密钥来加密数据。非对称密钥加密会将性能降低很多倍,而且你使用这个机制所能保护的数据量是受限的,它取决于密钥模块。你可以使用一个密码而不是数据库主密钥来保护证书和非对称密钥。
服务主密钥是一个管理SQL Server 中所有密钥和证书的密钥。它是SQL Server在安装过程中自动创建的一个同义字密钥。它显然是一个重要的秘密,因为它被知道了的话,那么攻击者就可以解析SQL Server管理的服务器上的每一个密钥。Windows中的数据保护API(Data Protection API ,DPAPI)会保护服务主密钥。
SQL Server为你管理服务主密钥,不过你可以在它上面执行维护任务将它输入到一个文件中,重新生成它,并从一个文件将它