我有一个现有的SQL Server 2005数据库,其中包含使用对称密钥加密的数据.使用密码打开对称密钥.我正在升级到使用此数据库的前端应用程序,其中包括添加许多新表,存储过程,UDF等,以及对现有表和数据库对象的许多修改.为此,我正在制作现有开发数据库的副本,以便在进行新开发时可以独立支持,维护和更新当前系统.
复制数据库的好方法是什么？通常,我会备份现有数据库,然后将其还原到新数据库.但是,鉴于加密数据,这是否可行？我是否仍然可以使用现有的对称密钥和密码加密并更重要的是解密新数据库中的数据？
我可能想要使用DTS仅传输现有架构.在新数据库中创建新的对称密钥/密码.然后编写即席查询以传输数据,使用现有密钥/密码进行解密,并使用新数据库中的新密钥/密码进行加密.
我猜其核心是,对称密钥是否适用于加密/解密单个数据库或同一服务器上的许多数据库中的数据？
我需要使用SQL Server 2005,asp.net和ado.net编写Web应用程序.存储在此应用程序中的大部分用户数据必须加密(读取HIPAA).
过去,对于需要加密的项目,我在应用程序代码中加密/解密.但是,这通常用于加密密码或信用卡信息,因此在几个表中只有少数列.对于这个应用程序,需要对几个表中的更多列进行加密,因此我怀疑将加密职责推入数据层的性能会更好,特别是考虑到SQL Server 2005对多种加密类型的本机支持.(如果有人有真实的经验证据,我可能会相信.)
我咨询了BOL,而且我很擅长使用谷歌.所以我不希望链接到在线文章或MSDN文档(可能我已经阅读过了).
到目前为止,我已经掌握了一种方法是使用一个使用证书打开的对称密钥.
所以一次性设置步骤(理论上由DBA执行):
然后,只要存储过程(或通过Management Studio的人类用户)需要访问加密数据,您必须首先打开对称密钥,执行任何tsql语句或批处理,然后关闭对称密钥.
那么就asp.net应用程序而言,在我的情况下是应用程序代码的数据访问层,数据加密是完全透明的.
所以我的问题是:
我是否要打开,执行tsql语句/批处理,然后在sproc中关闭对称密钥？我看到的危险是,如果tsql执行出现问题,代码sproc执行永远不会到达关闭密钥的语句.我假设这意味着密钥将保持打开,直到sql杀死sproc执行的SPID.
我应该考虑为我需要执行的任何给定过程进行三次数据库调用(仅在需要加密时)？一个数据库调用打开密钥,第二个调用执行sproc,第三个调用关闭密钥.(每个调用都包含在自己的try catch循环中,以最大化开放键最终关闭的几率.)
我需要使用客户端事务的任何注意事项(意味着我的代码是客户端,启动事务,执行多个sprocs,然后假定成功提交事务)？