【问题标题】:Grant all tables (except 1) Read permission on a Role while not knowing which tables there are every day授予所有表(除了 1)对某个角色的读取权限,但不知道每天都有哪些表
【发布时间】:2015-08-04 22:36:25
【问题描述】:

在我们的数据仓库(将动态变化)中,每天都会删除和重建表。我们组织中的某些开发人员也有可能在该数据库中创建更多表。 因此,我无法授予持久数据库的权限。

问题: 我想做某种每天运行的工作,列出数据库中的所有表名(当时存在的),如“Select * FROM sys.tables” 然后我希望表名作为脚本的输入值,该脚本通过所有表名运行并将它们放置在如下脚本中:

GRANT SELECT TO [Tablename1] TO [ROLE_READALLTABLES Except 1 table],
GRANT SELECT TO [Tablenaam2] TO [ROLE_READALLTABLES Except 1 table] 

如此循环,直到所有现有表都可读。 所以整个数据库中的所有表(除了1个表)都应该得到GRANT SELECT的权限。

我已经查看了所有相关的答案,但我似乎不知道如何让它发挥作用。 我希望有人可以帮助我。

更新 我使用 Microsoft SQL Server 2014,并通过 SQL Management Studio 2014 工作 更新 2: 有一个例外。该表具有架构 [dbo]。像所有其他表格一样

【问题讨论】:

  • 我使用 MS SQL Server 2014,我使用 SQL management studio 2014

标签: sql-server sql-server-2014 database-permissions


【解决方案1】:

您通常可以使用 db_datareader 角色授予对所有表的访问权限,然后使用具有 DENY 规则的特定角色来排除对作为例外的一个表的访问权限。

步骤大概是这样的:

1) 创建您的“阅读所有内容,除了 1 个角色”:

CREATE ROLE [ROLE_READALLEXCEPT1]

2) 像这样创建您的“拒绝”角色:

CREATE ROLE [ROLE_DENY]
GO
DENY SELECT, INSERT, UPDATE, DELETE ON myTable TO [ROLE_DENY]
GO

3) 然后将您的“除外 1”角色添加到其中:

EXEC sp_addrolemember @rolename = 'ROLE_DENY', @membername = 'ROLE_READALLEXCEPT1'

4) 将您的角色添加到 db_datareader:

EXEC sp_addrolemember @rolename = 'db_datareader', @membername = 'ROLE_READALLEXCEPT1'

deny 角色应该覆盖 db_datareader,最终结果是您的角色现在可以访问所有表(包括新表),但明确拒绝的除外。

然后您可以将您的用户添加到“ROLE_READALLEXCEPT1”,他们将可以访问除了一个例外表之外的所有内容。

【讨论】:

  • 可能是愚蠢的问题,但我应该将必须有权访问所有表的用户置于哪个角色。我应该将有权访问除异常表之外的所有表的用户放在哪个角色中?
  • 我已经添加到我的答案中,以明确您应该将您的普通用户(需要访问除一张表之外的所有内容)添加到“ROLE_READALLTABLES”。如果您需要另一个可以访问所有内容的用户,您可以执行以下任何操作:1. 创建另一个角色(可能是最好的),2. 将它们直接添加到 db_datareader,或 3. 如果合适,将它们设为 dbo。
  • 我已更新示例中的角色名称,以使其更加清晰。希望有帮助!
  • 非常感谢,明天上班我会试试看的。
  • 感谢您更新的表格示例。有晶莹剔透。我有一个问题。由于每天都会重新创建表,我应该如何处理 ROLE_DENY。我是否应该使用每天运行的命令:“拒绝选择、插入、更新、删除 mytable 上的 ROLE_DENY”。因为如果我没有对 MYTable 的 DENY 权限,每天都会消失。
【解决方案2】:

没有关于排除表的信息,所以我假设总是相同的。
我还假设所有其他表都在架构 dbo 上;这不是一个相关的约束或限制,因为该逻辑可以很容易地应用于多个模式。

最简单的解决方案是授予permission at the schema level
将单个表移动到具有受限权限的单独架构上,并授予对用户表所在的整个架构的完全读取权限:

GRANT SELECT ON SCHEMA::dbo TO [relevant role/user];

现在开发人员可以在架构dbo 上创建他们喜欢的所有表,并且权限由架构继承。
如果您需要授予对多个架构的访问权限,则可以轻松应用一次权限,然后每个新表都将获得适当的权限。

这个解决方案的最大优点是它是一劳永逸的:一旦到位,就没有维护,没有工作,没有每天/每周/任何运行的脚本。

这个优势是针对排除表的移动进行评估和加权的(或相反:移动用户表):可能仅由几个内部应用程序使用,因此它是一个快速补丁或被使用而是通过全球范围内可访问的一大堆服务,这将是一场噩梦。

【讨论】:

  • 有一个例外。该表具有架构 [dbo]。像所有其他表一样
  • 这是我做出的假设之一,即使我没有把它写出来,这就是为什么我建议的第一个操作是将该表移动到不同的模式。不幸的是,问题中没有关于此的信息,所以我不得不做出很多猜测。那张桌子可以移动吗?
  • 不幸的是,这是无法回答的问题,因为我本人不负责更改表结构。我不允许这样做,
  • 但是我当然会接受您的建议,并会查看我们数据库中的可能性。谢谢
  • 我想到了另一个玩家:同义词。将排除的表移动到单独的架构并在 dbo 上创建同义词以保持旧路径“活动”:这样您就可以使用架构级别的权限来保持与现有应用程序的兼容性。
猜你喜欢
  • 2012-07-20
  • 2019-04-13
  • 2018-10-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多