客户端 - 数据库方案中的行级安全性

Question

我正在寻找一个好的模式来实现适合在客户端 - >数据库环境中使用的行级安全控件(通过例如代理,中间人Web服务或存储过程).我控制客户端和数据库.一些要求:

• 禁止用户查看他们无权查看的查询结果中的行
• 允许用户将自己的行INSERT并更新到表中,这使他们有权查看它们
• (软要求)允许用户授予其他人读取或写入行的权限
• 在Linux上运行的开源或低成本解决方案.据我了解,没有免费的数据库实现行级安全性.Oracle支持这一点,但它也是如此.Postgres 可能会在9.4中实现这一点,但它最初的目标是9.3并且滑落,并且对ML的讨论可能会再次滑落.我暂时考虑使用postgres,因为它们似乎是这个功能最远的.

我曾经有过一些(非常好的)想法:

• 使用postgresql的安全屏障视图并拒绝用户访问基础表.遗憾的是,没有好的方法将行插入安全屏障视图,因此某些特权代理/ web服务必须处理插入语句.这似乎很难做到.
• 使用常规视图,并拒绝用户访问基础表.这允许insert,但我需要非常紧密地锁定权限(例如,没有创建函数),并且似乎有很多泄漏信息的陷阱(如除以零).
• 定义SQL的某个子集,并创建一个代理,它是您与数据库唯一的通信点.代理解析您的SQL查询并重写它以强制执行安全性要求.这似乎很难做到,但也许我可以使用一个非常小的SQL子集,直到postgres实现真正的行级安全性.
• 只为不同的用户(甚至不同的DB)使用不同的表.但是我不确定它对很多用户来说有多好.此外,这似乎不符合软要求.
• 找一些商业但价格合理的DB实际支持这个
• 使用Veil但似乎没有维护,它具有其他解决方案的大部分限制

我已经在这个主题上做了大量的谷歌搜索,但我还没有看到有人在现实世界的场景中如何解决这个问题.有一些关于MS SQL的文档但是在MySQL中似乎不鼓励,而且postgres基本上不存在写入.

这似乎是一个非常常见的问题,但我想很多人都在编写Web应用程序并且满足于将用户手铐放到某些经过预先审查的查询上,但我真的需要尽可能多地为用户提供查询数据的灵活性.我的客户.

Answer 1

整个行级安全话题颇具争议。我个人对此的看法是，您试图在数据库 ACL 层实现此操作时，是对着错误的树咆哮。我知道 Oracle 支持这一点，但在我看来，从一开始这就是一个非常糟糕的主意，并且造成的挫败感多于好处。我知道您很想重用现有的访问控制功能，只是为了节省代码行，但我本人不敢走这条路，因为您可能会因为 ACL 的期望与现实而陷入死胡同实施与您希望它如何工作。