Tho*_*ell 4 sql-server row-level-security
行级安全的优缺点是什么？
我们正在将数据库从桌面应用程序移植到网络应用程序，并想知道确保敏感数据受到保护的最佳方法。
对于我们的应用程序，登录系统的用户数量是有限的，例如受信任的承包商而不是公众成员。
我们当然可以编写查询以逐个检查权限，或者设置行以便只有该组织的承包商才能看到该行。
使用什么标准来决定什么是最佳实践？
小智 9
优点
行级安全性 (RLS) 降低了应用程序开发的复杂性。如果没有 RLS，您通常会使用您的查询或通过 ORM 创建过滤器，或者将过滤条件传递给您的过程。设置好 RLS 后，user1 可以看到您希望 user1 看到的内容，而无需对您的应用程序进行太多更改。
使用 RLS，安全性位于数据库级别。如果另一个应用程序正在从不同平台读取不同语言的数据，RLS 仍然允许 user1 看到您希望 user1 看到的内容。如果有人尝试对 SSMS 运行/测试 SQL 查询，RLS 会根据您的设置显示数据。
您的数据库备份和还原将保持 RLS 完好无损。
缺点
缺点是更多以 DB 为中心的工作和少量的性能损失。如果您的 Web 开发人员在数据库方面不强，则对 RLS 进行故障排除可能会花费他们一些时间。相反，如果应用层通过 ORM 过滤信息，您可以在应用或中间件端调试和编写审计。
就行级安全性的开销而言，这里有一篇详细介绍一些挑战的文章：https : //www.mssqltips.com/sqlservertip/4005/sql-server-2016-row-level-security-limitations-performance-and -troubleshooting/和https://www.mssqltips.com/sqlservertip/4778/performance-impact-of-sql-server-2016-rowlevel-security/。
是否使用RLS？
如果您对 RLS 感到满意，我建议您尝试一下。Microsoft 在此处列出了一些与 RLS 相关的最佳实践：https : //docs.microsoft.com/en-us/sql/relational-databases/security/row-level-security? view=sql-server- 2017。
如果您的数据库受到良好保护并且仅通过应用层访问数据，您可以选择在应用层内构建过滤。在应用层进行安全检查并使用 RLS 并不是很多工作。没有一刀切的答案。对于大多数更简单的应用程序，我倾向于使用应用程序层进行过滤，因为它在审计/日志记录/调试方面非常有用。