我想为连接到特定SQL Server数据库(只有一个数据库)的 任何 客户端强制执行行级安全性。我不想强制要求在客户端进行任何特定设置(因为这意味着客户端可以设置自己以便它可以访问任何东西 - 这当然会很糟糕; BTW,客户端是使用Windows Auth或SQL Auth连接的WinApp。我基本上希望这对任何客户都是透明的。客户甚至不应该知道这种情况正在发生。
行级安全性的执行将在数据库内部的视图中执行,这些视图分层在表上方(实质上:没有人能够直接对表执行DML;相反,所有操作都应该针对表执行位于表格顶部的视图。这些视图将在特定的“执行为”下运行替代触发器,以确保可以正确执行DML操作。
所以基本上,我想通过将其烘焙到数据库本身来消除客户端绕过这个安全模型的潜力。
我还希望从应用于当前连接的有效权限中分离授予用户的权限(以这种方式考虑:如果您连接到数据库,则具有与您的连接关联的安全上下文 - 维护在请注意,DB - 此安全上下文包含有关您有权访问的项目的信息。建立连接后,将创建此安全上下文并使用基于分配给您的权限的信息填充此信息,并在连接关闭时使用在此安全上下文中被删除;实际上,应删除整个安全上下文)。当然,安全上下文应该只在给定连接中可用,连接不应该甚至能够看到其他连接存在安全上下文。
(编辑:明确定位的方案之一,这解释了为什么安全上下文与'定义的权限'分离如下:如果您建立与数据库的连接,您将获得SecContext;现在您的连接是处于活动状态/未关闭状态,管理员会为您分配新权限,这些新权限将不会应用于此当前打开的连接。您必须关闭连接并重新建立连接才能在SecContext中反映这些更改
我知道如何强制执行视图只会返回用户有权访问的信息。这是最容易的部分......这个问题是关于创建和删除我正在讨论的安全上下文。
有人会知道如何实现这一目标。
由于
答案 0 :(得分:2)
SQL Server临时表(名称以#开头的表)仅对当前连接可用,并在最后删除。您只需要在创建新连接时建立它。
然而,听起来您正在重新实施DBMS已经为您做的很多事情。我建议阅读有关SQL Server内置安全机制的更多信息,特别是登录/用户/模式分离。
答案 1 :(得分:0)
我对摘要中的应用程序并不是很了解,所以我并不完全理解你从这里来的地方,但这里有一个问题:听起来你是在向用户提供直接连接你的数据库。你需要这样做吗?
也许我忽略了这一点,但如果你在应用程序中内置了一个API,而不是为用户提供直接的数据库连接,那么这些行级别的安全性是不是可以完全消除?如果以这种方式进行设置,那么您的API可能是网守,它会阻止用户对不应授予访问权限的行进行更改。也许这比直接在数据库级工作更简单?
我希望这有用。