为了遵守世界各地多个国家的各种政府法规和行业标准，组织需要实施程序和方法来确保信息得到充分保护。这些法规和标准的规定，个人只允许访问执行其工作所需要的信息子集。例如，根据 US Health Insurance Portability and Accountability Act (HIPAA)，医生被授权查看自己的病人的医疗记录，但没有权利查看其他病人的记录。同样，根据 Payment Card Industry Data Security Standard (PCI DSS)，信用卡号等持卡人数据的访问必须根据需要知道的业务进行限制。对于存储在关系数据库中的信息，在行和列级别控制数据访问的能力可以满足这一要求。
本文首先回顾解决行和列访问控制问题的传统方法，并介绍了行权限和列掩码这两个新的概念，它们是传统方法的一个高级且更有效的替代方法。在此之后，对新的权限和掩码依赖项进行讨论，并介绍安全函数和安全触发器。用例场景说明了如何使用行权限和列掩码来满足所需的访问控制。最后，本文提供了在使用行权限和列掩码时要遵循的一套最佳实践。
用于实现的行和列访问控制的传统方法有三种：数据库视图、基于应用程序的安全性和基于标签的访问控制 (LBAC)。
2.1 数据库视图
对于每个需要保护的数据库表，下面的步骤总结了使用数据库视图实现行和列访问控制的典型步骤。
1. 数据库开发人员创建包括影响所有表用户的所有安全规则的单个视图，或为每个用户或用户组创建单独的视图。
2. 数据库开发人员对一个或多个视图授予适当的特权。
3. 数据库开发人员撤销所有用户和组对基表的访问权限。
4. 如果为不同的用户或组创建多个视图，应用程序架构师应确保该应用程序包含根据用户身份和/或用户组成员将用户查询路由到适当视图的逻辑。
5. 数据库开发人员和应用程序架构师测试该实现。
当不同限制的数量较少，或这些限制只影响大型和易于确定的用户组的情况下，数据库视图运行良好。不过，当这些条件都不能满足时，视图在使用中会引起一系列问题：
• 当尝试在一个视图中包含所有限制时，视图的定义可能会变得复杂。这种复杂性可能会加剧系统的限制，并可能使视图的维护变得困难。如果采用替代方法，定义许多简单的视图，每个视图针对一组特定用户实施限制，这可以简化视图定义的维护，那么将用户请求路由到正确的视图又成为另一个问题。在这种情况下，数据库开发人员往往选择在应用程序中解析请求，而不是在数据库中进行解析。
• 如果用户在访问数据时可以忽略视图，例如，可以直接访问底层的表，那么这些限制就无法执行。
• 具有 DATAACCESS 授权的用户仍然可以完全访问数据。
2.2 基于应用程序的安全性
对于每个需要保护的数据库表，下面的步骤总结了在应用程序中实现行和列访问控制的典型步骤。
1. 应用程序将所有数据提取到应用程序内存中，然后应用自定义逻辑，根据用户的身份筛选出结果集。或者，应用程序构建部分或全部筛选逻辑到实际 SQL 语句中，并提交到数据库，以便部分或全部筛选逻辑会由数据库执行。
2. 数据库开发人员和应用程序架构师测试该实现。 虽然基于应用程序的安全性看起来可能很有吸引力，但这种方法也有若干个缺点：
• 安全策略被暴露给应用程序编程人员。
• 该方法易于出错，并且要求大量代码审查。
• 需要通过应用程序变更来反映安全策略的变更。
• 只有在通过应用程序访问时，数据才受到保护。这种保护局限性制约了对数据使用特设查询和报表生成等工具的能力。
• 具有 DATAACCESS 授权的用户仍然可以完全访问数据。
2.3 基于标签的访问控制 (LBAC)
对于每个需要保护的数据库表，下面的步骤总结了使用 LBAC 实现行和列访问控制的典型步骤。
1. 数据库安全管理员（具有 SECADM 授权的用户）创建安全标签组件和需要将安全要求映射到安全标签中的安全策略对象。
2. 数据库安全管理员创建用户在访问受保护的表时所需要的安全标签对象。
3. 数据库安全管理员向适当的用户授予安全标签和豁免权。
4. 数据库开发人员修改表，添加一个安全标签列，并将一个安全政策对象关联到表。
5. 数据库开发人员和应用程序架构师测试该实现。
LBAC 是一个强大的安全模式，极少适用于商业客户，因为它需要对数据进行分类，并有一套固定的安全规则，即，no read up rule 和 no write down rule。LBAC 和多层安全性 (MLS) 一般都针对情报和国防客户，这是 MLS 起源的地方。如需有关 MLS 和其相关规则的详细信息，请参阅在参考资料一节中列出的文件。