SQL Server 2016 中的始终加密行为
Always encrypted Behavior in SQL Server 2016
我在 SQL Server 2016 中针对主题 Always encrypted 做了一些演示。几乎没有疑问。以下是遵循的步骤：
在数据库服务器（托管在 Microsoft Azure VM 中）：
- 在 table
MyTable 中，创建了列加密密钥 (CEK) 和主加密密钥 (CMK)
Select * from MyTable，显示加密数据。（来自应用程序和数据库服务器）- 已从数据库服务器导出证书
- 在 App Server（我的本地计算机）
中导入了证书
- 已将
Column Encryption Setting=Enabled 添加到我的应用程序的连接字符串中。
- 它工作正常，现在它按预期显示纯文本数据。
疑问：
在数据库服务器中（在 MS Azure VM 中），如果系统管理员登录（SQL 身份验证）使用附加参数 Column Encryption Setting=Enabled 连接到 SSMS，则显示纯文本数据（预期加密数据） . 我的理解是，应用程序用户以外的任何人都不应看到纯文本数据)。谁能澄清一下？
在第 3 步中，您提到从数据库服务器导出证书，以确保最大的安全性，从不将您的证书存储在数据库服务器上。服务器不需要访问证书。
If a SysAdmin login (SQL Authentication) connects to SSMS with
additional parameter Column Encryption Setting=Enabled, It is shows
plain text data (expecting encrypted data). My understanding is, no
one other then application users should see the plain text data). Can
anyone please clarify?
如果系统管理员从具有证书的客户端计算机连接到 SSMS，并且如果系统管理员有权访问该证书，那么他们将看到纯文本数据。
粗略地说，Always Encrypted 提供以下安全保证，明文数据仅对有权访问 ColumnMasterKey（证书）的实体可见
为了详细说明，请考虑以下情况。
考虑两台机器：
- MachineA：SQL 服务器所在的机器 运行
- MachineT：客户机。
考虑两个用户
UserA（这在技术上可以是一组用户，但为了简单起见，我将考虑单个用户的场景）：谁是管理员MachineA，管理 SQL 服务器并且是 SQL 服务器上的系统管理员。但是，userA 没有对 MachineT 的任何访问权限，并且 UserA 不应该能够解密存储在机器 A 上的 SQL 服务器中的任何加密数据（加密数据，在此答案的上下文中是使用 SQL 服务器的 Always Encrypted 功能加密的数据）。
UserT（这在技术上可以是一组用户，但为了简单起见，我将考虑单个用户的场景）：是受信任的用户，有权访问 MachineT，有权访问数据库 db 中的所有数据，该数据库托管在 MachineA 上的 SQL 服务器中。此外，由于 userT 是可信的，he/she 应该能够解密加密数据。
考虑 SQL 服务器 运行 在 MachineA 上有 数据库 db 和 tablet。
我们的目标是保护属于 table t 的列，比如 ssnCol，这样只有 userT 应该能够以明文形式看到 ssnCol。
上述目标可以通过以下步骤实现。
- UserT 登录 MachineT。
- UserT 在 MachineT.
中打开 SSMS
- UserT 连接到 MachineA
上的 SQL 服务器
- UserT 使用
Encrypt columns (configure Always Encrypted) 部分提到的步骤在 table t 中加密 ssnCol 12=]
- 完成此步骤后，ssnCol 列将被加密。
当userT按上述方式加密ssnCol时，会生成两个密钥
- CMK：CMK 又名列主密钥是用于加密 CEK/s 的密钥。此密钥存储在 MachineT 的 windows 证书库中。
- CEK：CEK aka 列加密密钥是用于加密 ssnCol 的密钥，该密钥以加密形式存储在SQL MachineA 上的服务器，并且不会以明文形式保留在任何地方。
因此，为了解密ssnCol，需要CEK，然而，为了解密CEK，需要CMK。
由于CMK在machineT的Windows证书库中，只有userT可以访问CMK，解密CEK并解密 ssnCol。
userA 是 machineA 上的管理员，也是 SQL 服务器上的系统管理员，但是，由于 he/she无权访问CMK，userA无法明文访问ssnCol。您可以通过使用来自 MachineA 的 SSMS，以 userA 登录并查询 ssnCol[= 来验证这一点13=]
如有其他问题，请在评论区提出，我会一一解答。
另一个非常重要的考虑因素：
Always Encrypted 的主要目标是保护您的数据免受托管 SQL 服务器计算机上的恶意软件 运行ning 和托管 SQL 服务器计算机上的恶意高权限用户的侵害（DBA、系统管理员）。如果这些是您想要在您的应用程序中解决的攻击媒介，您永远不应在托管 SQL 服务器实例的计算机上为 Always Encrypted 提供密钥，该服务器实例包含一个包含您要保护的列的数据库。如果您 运行 一个关键的配置工具，例如SSMS 或 PowerShell，在托管您的实例的机器上，并且机器受到威胁，攻击者可以窃取您的密钥，例如通过抓取 SSMS 内存。当然，如果您生成一个证书并将其放入服务器机器上的证书存储区，攻击者就更容易获得它。
请参阅 https://msdn.microsoft.com/en-us/library/mt708953.aspx#SecurityForKeyManagement 了解更多详细信息和有用的指南。
我在 SQL Server 2016 中针对主题 Always encrypted 做了一些演示。几乎没有疑问。以下是遵循的步骤：
在数据库服务器（托管在 Microsoft Azure VM 中）：
- 在 table
MyTable中，创建了列加密密钥 (CEK) 和主加密密钥 (CMK) Select * from MyTable，显示加密数据。（来自应用程序和数据库服务器）- 已从数据库服务器导出证书
- 在 App Server（我的本地计算机） 中导入了证书
- 已将
Column Encryption Setting=Enabled添加到我的应用程序的连接字符串中。 - 它工作正常，现在它按预期显示纯文本数据。
疑问：
在数据库服务器中（在 MS Azure VM 中），如果系统管理员登录（SQL 身份验证）使用附加参数 Column Encryption Setting=Enabled 连接到 SSMS，则显示纯文本数据（预期加密数据） . 我的理解是，应用程序用户以外的任何人都不应看到纯文本数据)。谁能澄清一下？
在第 3 步中，您提到从数据库服务器导出证书，以确保最大的安全性，从不将您的证书存储在数据库服务器上。服务器不需要访问证书。
If a SysAdmin login (SQL Authentication) connects to SSMS with additional parameter Column Encryption Setting=Enabled, It is shows plain text data (expecting encrypted data). My understanding is, no one other then application users should see the plain text data). Can anyone please clarify?
如果系统管理员从具有证书的客户端计算机连接到 SSMS，并且如果系统管理员有权访问该证书，那么他们将看到纯文本数据。
粗略地说，Always Encrypted 提供以下安全保证，明文数据仅对有权访问 ColumnMasterKey（证书）的实体可见
为了详细说明，请考虑以下情况。
考虑两台机器：
- MachineA：SQL 服务器所在的机器 运行
- MachineT：客户机。
考虑两个用户
UserA（这在技术上可以是一组用户，但为了简单起见，我将考虑单个用户的场景）：谁是管理员MachineA，管理 SQL 服务器并且是 SQL 服务器上的系统管理员。但是，userA 没有对 MachineT 的任何访问权限，并且 UserA 不应该能够解密存储在机器 A 上的 SQL 服务器中的任何加密数据（加密数据，在此答案的上下文中是使用 SQL 服务器的 Always Encrypted 功能加密的数据）。
UserT（这在技术上可以是一组用户，但为了简单起见，我将考虑单个用户的场景）：是受信任的用户，有权访问 MachineT，有权访问数据库 db 中的所有数据，该数据库托管在 MachineA 上的 SQL 服务器中。此外，由于 userT 是可信的，he/she 应该能够解密加密数据。
考虑 SQL 服务器 运行 在 MachineA 上有 数据库 db 和 tablet。
我们的目标是保护属于 table t 的列，比如 ssnCol，这样只有 userT 应该能够以明文形式看到 ssnCol。
上述目标可以通过以下步骤实现。
- UserT 登录 MachineT。
- UserT 在 MachineT. 中打开 SSMS
- UserT 连接到 MachineA 上的 SQL 服务器
- UserT 使用
Encrypt columns (configure Always Encrypted)部分提到的步骤在 table t 中加密 ssnCol 12=] - 完成此步骤后，ssnCol 列将被加密。
当userT按上述方式加密ssnCol时，会生成两个密钥
- CMK：CMK 又名列主密钥是用于加密 CEK/s 的密钥。此密钥存储在 MachineT 的 windows 证书库中。
- CEK：CEK aka 列加密密钥是用于加密 ssnCol 的密钥，该密钥以加密形式存储在SQL MachineA 上的服务器，并且不会以明文形式保留在任何地方。
因此，为了解密ssnCol，需要CEK，然而，为了解密CEK，需要CMK。
由于CMK在machineT的Windows证书库中，只有userT可以访问CMK，解密CEK并解密 ssnCol。
userA 是 machineA 上的管理员，也是 SQL 服务器上的系统管理员，但是，由于 he/she无权访问CMK，userA无法明文访问ssnCol。您可以通过使用来自 MachineA 的 SSMS，以 userA 登录并查询 ssnCol[= 来验证这一点13=]
如有其他问题，请在评论区提出，我会一一解答。
另一个非常重要的考虑因素：
Always Encrypted 的主要目标是保护您的数据免受托管 SQL 服务器计算机上的恶意软件 运行ning 和托管 SQL 服务器计算机上的恶意高权限用户的侵害（DBA、系统管理员）。如果这些是您想要在您的应用程序中解决的攻击媒介，您永远不应在托管 SQL 服务器实例的计算机上为 Always Encrypted 提供密钥，该服务器实例包含一个包含您要保护的列的数据库。如果您 运行 一个关键的配置工具，例如SSMS 或 PowerShell，在托管您的实例的机器上，并且机器受到威胁，攻击者可以窃取您的密钥，例如通过抓取 SSMS 内存。当然，如果您生成一个证书并将其放入服务器机器上的证书存储区，攻击者就更容易获得它。
请参阅 https://msdn.microsoft.com/en-us/library/mt708953.aspx#SecurityForKeyManagement 了解更多详细信息和有用的指南。