我假设您在这里谈论的是 Microsoft SQL Server 提供的“TDE”功能。

TDE的意思是Transparent Data Encryption，强调“透明”。这是在存储数据时应用于数据的加密层；SQL Server 管理的每个字节在写入磁盘之前都经过加密，并在读取时解密。使用 SQL Server 的应用程序不需要知道该过程；这是一个纯粹存在于 SQL Server 与其存储文件之间的对话的问题。因此透明度。它的好处是它易于应用，并且性能非常好（CPU 开销小到可以忽略不计，没有额外的 I/O，没有额外的空间......）。不利的一面是 SQL Server 本身，而不是应用程序，是守门人：任何被 SQL Server 授予访问权限的人都将能够看到清晰的数据。

对于 PCI 合规性，请参阅本文档，其中包括本段（在末尾）：

一些密码学解决方案对存储在数据库中的特定信息字段进行加密；其他人加密单个文件甚至存储数据的整个磁盘。如果使用全盘加密，则逻辑访问必须独立于本机操作系统访问控制机制进行管理。解密密钥不得与用户帐户绑定。用于加密持卡人数据的加密密钥必须受到保护，防止泄露和滥用。用于加密持卡人数据的密钥的所有密钥管理流程和程序必须完整记录和实施。有关更多详细信息，请参阅 PCI DSS 要求 3。

“全盘加密”适用于 TDE（TDE 名义上应用于文件，但所有文件）。在 TDE 中，实际的加密密钥由 SQL Server 管理，SQL Server 将根据...其配置授予或不授予用户逻辑访问权限，该配置可能会或可能不会映射到用户帐户。所以我想说，TDE 是否授予 PCI 合规性取决于它的使用方式。

我无权就如何通过 TDE 实现 PCI 合规性给出明确的答案，但我注意到Wikipedia 页面包含一个令人鼓舞的摘录：“企业通常使用 TDE 来解决合规性问题，例如 PCI DSS。” 因此可以推测，通过 TDE 满足 PCI 要求是可能的，或者至少很多人似乎坚信这是可能的，这几乎是一样的好。

Microsoft 有关于如何在合规性上下文中配置和使用 SQL Server的文档。他们还有一个网络广播，其中可能包含很多有用的信息（我还没有看过）。

PCI 合规性和加密从密钥管理的安全角度处理加密。虽然它引用了强加密，但这通常意味着行业标准，例如 3DES 112、AES 128/256 等。在引用公钥加密的地方，它正在寻找 RSA2048。

持卡人数据 (PAN) 必须使用强加密技术进行静态加密。使用 TDE，数据使用您从 SQL 中选择的静态加密，因此很可能是 AES128 或 AES256。

对于 PCI 合规性，您需要能够展示加密密钥的双重控制和拆分知识。如果您可以使用 TDE 证明这一点（您应该能够），那么您就是。如果您有 QSA，可能值得与您的 QSA 讨论此问题。

您应该考虑为什么要加密以及它可以保护您免受什么侵害（除非您只是想在 PCI 框中打勾）。使用 TDE，加密是透明的，因此，如果磁盘被盗，窃贼会查看数据库空间中的加密数据，而本地用户始终可以看到明文数据。由于物理安全控制，物理盗窃不是问题，而是数据被盗。使用 TDE 意味着内部员工可以复制和查看数据，并且根据前端的控制，也可以由 [恶意] 最终用户以明文形式提取数据。