小编Jam*_*mes的帖子

我需要镜像一些数据库并在它们上使用透明数据加密(TDE)，因为我们的数据必须在“静止”时加密。

我在主体和镜像上都设置了 TDE。我在设置两个数据库的镜像时遇到的问题。由于我使用的是 TDE，我不知道通过 gui 设置镜像的方法，所以我不得不使用 t-sql 来完成工作。

下面是我在镜像服务器上使用的代码

--Restore the full backup to the mirrored mdf and ldf
OPEN MASTER KEY DECRYPTION BY PASSWORD = '1Password'
RESTORE DATABASE TDE
   FROM disk = '\\SERVERNAME\SQL_Stuff\Backup\TDE_FULL.bak'
      WITH NORECOVERY,
       REPLACE,
       MOVE 'TDE' TO 'E:\TDE.mdf',
      REPLACE,
      MOVE 'TDE_log' TO 'G:\TDE.ldf'
CLOSE MASTER KEY 
GO

--Restore the log backup to the mirrored db
OPEN MASTER KEY DECRYPTION BY PASSWORD = '1Password'
RESTORE LOG TDE
    FROM DISK = '\\SERVERNAME\SQL_Stuff\Backup\TDE_LOG.trn'
    WITH NORECOVERY;
CLOSE MASTER KEY …

我知道 SQL Server 2012 和 2014 提供了提供此功能的AlwaysOn 可用性组，但我仍然停留在 SQL Server 2008 R2 上一段时间。

我最近看到了这个 AWS 白皮书：http : //media.amazonwebservices.com/AWS_RDBMS_MS_SQLServer.pdf

我对第 11 页的这张图表感到困惑： 这似乎表明镜像数据库可以用于读取（检查“可读副本”功能列），就像使用日志传送时一样，因为根据我的经验，镜像数据库根本无法使用--它的唯一目的是用于故障转移。

这个问题的答案：数据库镜像仅限于原始数据库似乎证实了我的怀疑，即镜像数据库不可读，尽管只是顺便说一句。

这份白皮书是错误的，还是 SQL Server 2008 R2 镜像数据库确实可读？

如果是，需要做什么，因为尝试在 SSMS 中连接会导致一个窗口连接到主数据库，并且运行USE [database]会出现以下错误：

Msg 954, Level 14, State 1, Line 1
The database "database" cannot be opened. It is acting as a mirror database.

更新：我知道有一些方法可以解决这个问题，并从镜像和延时中获取一些可读的东西，我想有人可以争论快照是“可读副本”，但那是与您通过日志传送或事务复制获得的可读副本类型非常不同，因为这两者都会自动更新，即使稍微过时（也许快照也可能是 - 我坚持标准Edition，所以我对Enterprise Edition功能集不太熟悉）。除此之外，一个真正可读的同步镜像（比如使用AlwaysOn Availability Groups在 2012+ 中）将提供一个完美同步的可读版本——这更有用，因为镜像可用于分配读取查询负载并避免返回过时数据的所有问题。我的主要目的（如上面的问题所述）实际上是获得关于镜像本身可读性的明确答案（不是快照或它的副本）。虽然提供的答案与我自己的经验一致，但所提供的确定来源的唯一链接是实现类似结果的可能方法——它们都没有明确说明镜像不可读。我将接受提供此类链接的第一个答案。

我一直在阅读 SQL 注入，作为对相当大的 Web 服务进行安全审计的一部分。我一直在谷歌搜索并阅读我可以在这里和 SO 上找到的所有帖子，并且对真正应该如何构建动态查询以及 MySQL 和 MSSQL 之间的一些差异有相当深入的了解。我最终看到了今年早些时候由 Microsoft 发布的名为SQL Injection 的页面。在标题为“过滤输入”的部分中，它指出：

通过删除转义字符，过滤输入也可能有助于防止 SQL 注入。但是，由于可能会出现问题的字符数量众多，因此这不是可靠的防御。以下示例搜索字符串定界符。

private string SafeSqlLiteral(string inputSQL)  
{  
  return inputSQL.Replace("'", "''");  
}  

编写安全代码第二版也在第 401-402 页讨论了这一点，但看起来作者实际上并没有尝试 C# 示例（或者他在 2003 年使用的 SQL 版本可能没有正确处理转义字符串）。它指出字符串输入将导致无效查询（实际上，转义只是查询其中带有单引号的值），然后指出它也可能会被使用未加引号的数字字段的值攻击（尽管不能，因为示例中的字段来自类型为 的局部变量int，它不可能包含注入所需的信息）。

我不怀疑这里存在可能的攻击向量，但我无法找到有关如何实现这一点的任何解释。从我的其他研究来看，一种可能的方法可能涉及非 Unicode 字符串中的奇怪字节序列。就我而言，我正在使用 .NET，所以不可能有这样的序列，我认为 ADO.NET、SQL Server 或两者都可以正确处理 Unicode 字符串与单个内部的任何其他类型的字符-引号。（虽然有趣的是示例代码似乎是在 C# 中）。

我也很清楚微软页面上列出的其他 SQL 注入方法，对于这个问题，我并不担心这些。此外，我只关心此处正确键入的字符串文字输入。此代码始终在编写 SQL 查询之前将传入类型解析为其适当的运行时类型，因此引号转义仅适用于数据是文字字符串数据时。所以就我而言，该函数实际上更像是：

private string SafeSqlStringLiteral(string inputString)  
{  
  return "'" + inputString.Replace("'", "''") + "'";  
}  

我最关心的就是文档中的下面这句话：

但是，由于可能会出现问题的字符数量众多，因此这不是可靠的防御。

这只是指奇怪的单字节编码，还是有适用于的 Unicode 字符（我无法以编程方式找到一个）？

我正在审查的代码非常广泛，并且在很多地方都使用了这种类型的转义（并且以一种不容易修复的方式）。我不是直接要求利用漏洞（这对 IIRC …