【问题标题】:Can a deterministically encrypted column be involved in a foreign-key constraint in SQL Server 2016SQL Server 2016 中的外键约束是否可以涉及确定性加密列
【发布时间】:2019-05-23 14:48:13
【问题描述】:

this documentation寻求澄清。

不支持加密:

具有 IDENTITY 属性的列

我想确保其中一列可以是 IDENTITY 列,如果它未加密但涉及 FOREIGN-KEY 约束,其中指向它的外部对应项确实已加密。

假设在 SQL Server 2016 或更高版本中,我们有一个 CLIENT 表:

id int IDENTITY (1,1) NOT NULL  [column is primary key]
clientname varchar(100)

[注意:CLIENT id 具有高基数。此表中有近 200,000 个客户。]

还有一个 MEDICALPROCEDURES 表:

id int PK
procedurecode varchar(10)
clientid  int

现在是外键约束:

ALTER TABLE MEDICALPROCEDURES
ADD CONSTRAINT FK_MEDICALPROCEDURES_CLIENT
FOREIGN KEY(clientid) REFERENCES CLIENT(id)

现在,如果列MEDICALPROCEDURES.clientid 被确定性加密,而列CLIENT.id 未加密,那么外键约束会成功吗?

像下面这样的查询会透明地成功吗?

select 
C.clientname, MP.procedurecode
from CLIENT c inner join MEDICALPROCEDURES MP
on C.id=MP.clientid
where C.clientid=12345

【问题讨论】:

    标签: sql-server encryption foreign-keys deterministic


    【解决方案1】:

    它不会起作用。
    不支持以下文档:“在使用随机加密或使用确定性加密时,如果引用和引用列使用不同的密钥或算法,则在外键约束中引用列”。所以你需要对 id 和 clientid 使用相同的确定性加密。

    【讨论】:

    • 文档中的那句话我不清楚。未加密的列 CLENT.id 根本没有使用任何加密算法,所以我想知道,这是否符合“不同算法”的条件?这与说外键约束中的所有列必须使用确定性加密和相同的键不太一样。
    • 在始终加密的 SQL Server 引擎中永远不应该知道未加密的值。只有客户端驱动程序拥有密钥。所以不能在服务器上执行join C.id=MP.clientid。 (SQL Server 2019 中的安全飞地改变了这一点)
    • 这是有道理的。感谢您提供有关“安全飞地”的信息。
    • 在 SQL Server 2019 中,如果两列都不是整数而是 uniqueidentifier 并且加密不是确定性而是随机的,Client.id 和 MedicalProcedures.clientid 上是否可以存在外键关系?我还没有找到有关限制的文档。
    猜你喜欢
    • 2014-11-21
    • 1970-01-01
    • 2017-06-17
    • 2011-12-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多