授予自身EXECUTE权限的SQL Server存储过程

Question

尝试搜索此内容，但找不到任何内容。我在生产数据库中有一些存储过程，开发人员最后在其中添加了a

GRANT EXECUTE ON [ProcName] to [USER1] AS [dbo]

我的间谍意识告诉我，不应该这样做，因为所有用户访问都应该在适当级别的SSMS中进行管理。如果数据库开始真正忙起来，这也可能会导致死锁，并且每次都不必连续授予此访问权限。

我一生无法想到一个合理的理由，为什么除了确保用户在开发过程中获得许可之外，还需要这样做。我打算删除它，但我只是想知道我是否缺少什么？

Answer 1

99.999％的机会，这是一个错误。存储过程以批处理结尾only结束。开发人员可能使用DDL批处理创建了该过程，如下所示：

create procedure foo
as
begin
  print 'foo'
end

grant execute on foo to User1 as dbo  --this is still part of the procedure!
go

并且存储过程默认情况下以调用方的身份执行，如果没有管理员，则调用方将无法运行该GRANT。

在您的DDL脚本中包括GRANT是一种很好的做法，但是对每个对象使用单独的GRANT的做法可以追溯到使用好的工具（如SSDT）之前以及在用户模式分离之前。

今天，在架构级别授予GRANT是更好的做法，因此无需为每个对象设置权限。虽然GRANT应该是架构设计的一部分，并且在整个环境中都是相同的，但是这些授予通常应该是SCHEMA上ROLE的GRANT。然后，在不同的环境中，角色可能具有不同的成员，但授权不会改变。

因此生产DBA可能会运行

ALTER ROLE APP_FRONT_END ADD MEMBER [MyDomain\AppPoolIdentity]

但不是

GRANT EXECUTE ON FOO TO [MyDomain\AppPoolIdentity]

Answer 2

不...您没有丢失任何东西。对于许多“开发人员”来说，这实际上是很常见的事情，因此需要将开发人员拉上地毯。如果其中之一能够通过，那么CTO，开发经理和DBA应该加入他们，这也是为什么...

1. 绝不应该允许开发人员将代码部署到登台，UAT或产品中
2. 为什么要进行100％的代码审查过程
3. 为什么应该对此类事情制定书面规则，而绝对不能容忍此类事情。恕我直言，“一个完成，您就在这里”。

公司在没有付钱给他们做这种愚蠢的事情的人的情况下，在安全方面存在足够的问题。这种事情的容忍度应该为零。

如果这一切使我在这个主题上听起来很残酷，那么我已经成功地说出了关于这个主题需要说些什么，但是您（读者）可能就是问题的一部分。