实现列级安全性

8 分钟

列级安全性 (CLS) 可用于限制列访问权限，从而保护敏感数据。它可以精细控制谁能访问特定的数据片段，从而提高数据仓库的整体安全性。

保护敏感数据

我们来看看医疗保健行业列级安全性 (CLS) 的一个实际例子。假设我们有一个名为 Patients 的表，表中有以下列：PatientID、Name、Address、DateOfBirth 和 MedicalHistory。

MedicalHistory 列包含有关患者的健康敏感信息。根据医疗保健法规和隐私法，此信息仅可供授权的医务人员（如医生或护士）访问。

下面是在此方案中实现列级安全性的可能方式：

确定敏感列：在本例中，将 MedicalHistory 列确定为包含敏感数据。
定义访问角色：定义允许访问 Doctor 列的 Nurse 和 MedicalHistory 等角色。 Receptionist 或 Patient 等其他角色可能会受到限制，无法访问此列。
向用户分配角色：为仓库中的每个用户分配适当的角色。例如，可能会为用户 DrSmith 分配 Doctor 角色，同时可能会为用户 JohnDoe 分配 Patient 角色。
实现访问控制：根据用户角色限制对 MedicalHistory 列的访问权限。

列级安全性有助于确保只有经过授权可以查看健康敏感信息的用户才能访问该信息，同时保护患者隐私并遵守医疗保健法规。

配置列级别安全性

在我们最近探索的方案中，用于实现列级安全性的语法可能如下所示：

-- Create roles
CREATE ROLE Doctor AUTHORIZATION dbo;
CREATE ROLE Nurse AUTHORIZATION dbo;
CREATE ROLE Receptionist AUTHORIZATION dbo;
CREATE ROLE Patient AUTHORIZATION dbo;
GO

-- Grant SELECT on all columns to all roles
GRANT SELECT ON dbo.Patients TO Doctor;
GRANT SELECT ON dbo.Patients TO Nurse;
GRANT SELECT ON dbo.Patients TO Receptionist;
GRANT SELECT ON dbo.Patients TO Patient;
GO

-- Deny SELECT on the MedicalHistory column to the Receptionist and Patient roles
DENY SELECT ON dbo.Patients (MedicalHistory) TO Receptionist;
DENY SELECT ON dbo.Patients (MedicalHistory) TO Patient;
GO

在此示例中，我们首先创建角色 Doctor、Nurse、Receptionist和 Patient。然后，我们向所有角色授予对 SELECT 中所有列的 Patients 权限。最后，我们拒绝 SELECT 和 MedicalHistory 角色对 Receptionist 列的 Patient 权限。这可确保仅具有 Doctor 或 Nurse 角色的用户才能访问 MedicalHistory 列。

了解优势

在仓库安全性领域，两种常用的技术是列级安全性和视图。两种方法都可用于限制对敏感数据的访问，但其具体执行方式不同，优势也不同。下表基于访问控制粒度、维护、性能、透明度和灵活性等各个方面对这两种技术进行了比较分析。

此比较可帮助你了解每个方法的优点和缺点，并指导你选择最适合特定应用程序要求的方法。

方面	列级安全性	视图
访问控制粒度	可实现更精细的控制。可以为同一表中不同列上的不同用户或角色指定不同的访问权限。	需要为不同的权限集创建不同的视图。
维护	权限绑定到列本身，以便自动适应表结构的更改。	如果基础表结构发生更改，可能需要更新视图来反映这些更改。
“性能”	通常效率更高，因为它直接对表数据进行操作。	可能会产生性能开销，尤其是它们很复杂或者基础表较大时。
透明度	这些限制对用户是透明的。用户照常查询表，数据库引擎负责应用安全规则。	用户需要查询其他对象（视图而不是表）。
灵活性	不如视图灵活。	非常灵活，除了列级安全性之外，还可以提供行级安全性（通过在视图定义中包含 `WHERE` 子句）。它们还可以转换数据（例如，通过计算派生列），这是列级安全性无法实现的。

选择使用列级安全性还是视图取决于应用程序的具体要求。请务必在安全环境中测试进行的任何安全性更改，然后再将其应用于生产仓库。

反馈

此页面是否有帮助？