存储过程安全设置

Stored Procedures Security Set Up

我们目前正在迁移到 SQL 服务器并正在为我们的环境设置初始权限。有没有人有任何最佳实践来设置:

出于安全目的,我们计划为应用程序提供自己的用户,然后允许该用户访问所需内容。

我们如何设置它,以便开发人员可以开发他们的存储过程并获得他们需要的权限,而不会被权限问题阻止。

有没有办法允许属于特定模式的任何存储过程具有执行权限?

基本上我们有 4 个数据库,其中有许多表,还有许多访问各种表的应用程序。我们想让它易于管理,但也很容易知道每个应用程序有什么权限。例如,我们只希望对那些应用程序只需要只读的表进行只读访问,我们希望 update/delete/insert 访问那些需要它的表..

有关于最佳实践的文档吗?我们有很多存储过程也可以从所有不同的数据库访问表。

应用程序用户应该有什么安全措施,以便在添加新存储过程时他们不需要被授予对新存储过程的特定权限?那有可能吗?如果我创建一个新模式并在其中添加此应用程序的所有存储过程会怎样?我可以将执行授予架构级别吗?想法?

提前致谢。

在我说什么之前,我建议为您的应用程序用户创建一个数据库角色,将应用程序用户放入其中,然后将权限授予该角色(而不是直接授予用户)。为什么?有一天,应用程序用户的凭据将需要轮换(例如,密码泄露到日志中,不满 ex-employee,等等)。如果您授予该角色,则在没有应用程序停机的情况下执行此操作的过程是:

  1. 创建一个新的应用程序用户
  2. 将新用户放入数据库角色
  3. 更新您的应用程序以使用新用户
  4. 确认老用户不再使用
  5. 放弃老用户

除此之外:

Is there a way to allow any stored procedures to have execute permissions if it belongs to a specific schema.

是的。假设您的架构名为 app。你可以做到

grant execute on schema::[app] to yourAppRole;

How do we set it up so that developers can develop their stored procedures and get permission to what they need without getting blocked by permissions issues.

查看 ALTER PROCEDURE 的文档,上面写着:

Requires ALTER permission on the procedure or requires membership in the db_ddladmin fixed database role.

也就是说,对过程的 ALTER 权限可以是 隐含的。也就是说,如果您执行以下操作:

grant alter on schema::[app] to yourDevelopers;

应该 允许他们对应用架构中的任何存储过程授予 ALTER 权限。但这可能会产生意想不到的后果,因为它还会授予他们更改任何其他 schema-owned 对象(例如表、视图等)的能力。您必须决定这是否适合您的环境。您可以通过将 proc 和表放在单独的模式中来解决这个问题,此时对 proc 模式的 ALTER 权限应该具有相当有限的爆炸半径。