【问题标题】:Encrypt/decrypt columns, without changing existing functionality加密/解密列,而不更改现有功能
【发布时间】:2018-01-24 13:27:25
【问题描述】:

GDPR 让这个办公室有些头疼。我们已经有一个生产中的数据库表,我们称之为personal_data,现在需要对一些列进行加密。我们使用的是 SQL Server 2012。我读过可以使用存储在数据库中的对称密钥对列进行加密和解密。

我们有几十个现有的查询、存储过程和连接到该表的视图,因此我们希望尽可能避免更改它们。

是否可以加密必要的现有列并在不修改这些现有查询的情况下查询它们?

我的想法是,如果我们将personal_data 表重命名为其他内容,然后创建一个名为personal_data 的视图,该视图会查询personal_data 表的列并在那里处理解密,因此引用“personal_data”的所有内容仍将像以前一样工作。但如果这是可能的,那么这个解决方案有什么缺陷?

【问题讨论】:

  • 我认为你有一个合理的方法。我还会考虑 SQL2016 SP1 加密选项,尤其是始终加密,即使在标准版本中也可用。在我看来,这将使您在安全方面处于最新和最合规的水平。

标签: sql sql-server encryption


【解决方案1】:

我建议创建 另一个 表,例如 _personal_data。加密该表中的数据并将当前表替换为该表上返回可接受列的视图。

您可以授予每个人对视图的访问权限,同时限制对基础表的访问。

这是一种合理的临时方法。对于 GDPR 和其他隐私计划,我更喜欢更严格的限制,个人数据位于完全独立的数据库中——因为这样更容易控制访问和记录访问。

【讨论】:

  • 太好了,所以我当时走在正确的轨道上,我想我们无论如何都需要重新创建表以使列加密
  • 如果我们使用任何加密列作为对另一个表的外键引用,它是如何工作的?
  • 我不知道您的数据库设计,但外键不应该需要加密以满足 GDPR 要求。
  • 例如,我正在加密一列 EmailId,它是对另一个表的外键引用。它将如何运作?在这种情况下,我无法加密列
  • @Melody 。 . .那么其他表需要使用加密后的emailidl作为key。
【解决方案2】:

SQL Server 2005 使开发人员能够使用 EncryptByKey 和 DecryptByKey 函数加密和解密敏感数据 您可以在SQL Server Database Encryption找到一个示例案例

但这需要更新 INSERT、UPDATE 和 READ 语句的代码 例如,

SELECT
CONVERT(nvarchar, DecryptByKey(EncryptedData)) AS 'DecryptedData'
FROM myTable;

而不是直接读取为

SELECT EncryptedData AS 'DecryptedData' FROM myTable;

另一种加密方法是SQL Server Transparent Data Encryption aka TDE。启用后,您无需更改任何代码即可写入和读取数据。但这是一种保护磁盘文件的保护措施,而不是针对特定数据字段。一旦您使用有效的连接连接数据库,所有数据对您都是透明的。

【讨论】:

  • 我的印象是 TDE 仅在 SQL Server 2016 中可用,但现在我发现这不是真的,所以这有帮助
猜你喜欢
  • 2018-05-06
  • 1970-01-01
  • 2019-04-07
  • 2012-01-22
  • 1970-01-01
  • 1970-01-01
  • 2015-12-11
  • 2015-05-01
  • 2013-10-28
相关资源
最近更新 更多