问授予自身执行权限的Server存储过程

EN

不..。你什么都没错过。对于许多“开发人员”来说，这实际上是一件很常见的事情，开发人员需要在地毯上为它做些什么。CTO、Dev Manager和DBA应该加入它们，如果其中一个通过了，这是为什么.

不应该允许

1. 开发人员部署代码到暂存、UAT或Prod
2. 为什么应该有一个100%的代码评审过程
3. 为什么应该有关于这类事情的编写规则而绝对不容忍这种事情。IMHO，“一完成，你就在这里”。

公司有足够的安全问题，没有他们付钱的人做这种愚蠢的事情。这类事情应该是零容忍的。

如果这一切让我在这个问题上听起来很残忍，那么我已经成功地说出了在这个问题上需要说的话，但是你(读者)可能是问题的一部分。

{编辑}让我再限定一下.

作为部署脚本的一部分，这可能是合法的，但它永远不应该是实际存储过程的一部分，因为没有理由不断地将相同的privs授予给定的存储过程。这对我来说仍然是一种“违反”行为，因为开发人员不应该通过代码或任何其他方式分配privs。只有DBA应该分配这样的特权，并且需要有一张票或一些其他的可追溯性来说明为什么枢密院是必要的，这样才能通过安全审核。

也没有理由将DBO级别的执行权限授予给定用户。您应该只向用户授予EXECUTE，并且存储过程应该在其中有一个适当的EXECUTE AS xxxxx语句，以便能够完成存储过程需要做的事情。

如果授予代码中的"user1“是开发人员，那么是时候让开发人员知道他们为什么要这样做了。但是，就像我说的，这个代码不应该真的存在。应由DBA批准这类枢密院。

如果它是一个现有的存储过程，合法用户需要它使用"dbo“级别特权执行，则可能需要使用execute作为xxxxx来修复存储过程，而不是授予个人这样的特权。

与Server中的其他内容一样，"IT取决于“，我的声明可能有一个非常罕见的例外，但我会找到一种不同的方法来使它工作，特别是如果引用的"user1”是一个公开的应用程序。

99.999%的可能性这是一个错误。存储过程仅在批处理结束时结束。开发人员可能使用这样的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脚本中包含授权是一种很好的做法，但是为每个对象提供单独的授权是一种可以追溯到好工具之前(比如SSDT)和用户模式分离之前的做法。

现在更好的做法是在模式级别授予权限，因此不需要为每个对象设置权限。虽然授予应该是模式设计的一部分，并且在不同的环境中是相同的，但是这些授予通常应该是对模式上的角色的授权。然后，在不同的环境中，角色可能有不同的成员，但赠款永远不会改变。

所以生产DBA可能会运行

ALTER ROLE APP_FRONT_END ADD MEMBER [MyDomain\AppPoolIdentity]

但不是

GRANT EXECUTE ON FOO TO [MyDomain\AppPoolIdentity]