使用存储过程访问数据可以带来哪些安全性好处？

Question

我已经看到一些指导建议您通过分层存储过程的所有数据访问来保护数据库.

我知道对于SQL Server,您可以保护表,甚至是针对CRUD操作的列.

例如:

 --// Logged in as 'sa'
 USE AdventureWorks;
 GRANT SELECT ON Person.Address(AddressID, AddressLine1) to Matt;
 GRANT UPDATE ON Person.Address(AddressLine1) to Matt;

 --// Logged in as 'Matt'
 SELECT * from Person.Address;                       --// Fail
 SELECT AddressID, AddressLine1 from Person.Address; --// Succeed
 UPDATE Person.Address SET AddressLine1 = '#____ 2700 Production Way' 
        WHERE AddressID = 497;                       --// Succeed

鉴于您可以针对CRUD操作保护表甚至列,使用存储过程如何提供额外的安全性或安全性管理？

Answer 1

因为通过限制对那些存储过程的所有访问,您已经建立了一个定义的数据库接口,通过该接口必须进行所有访问...因为您将对表和视图进行DENY'd Direct选择,插入,更新和删除操作,没有人可以直接编写自己设计的sql,做任何他们想做的事情......如果你想限制插入到员工表中,员工被分配到三个以上的项目,只有那些得分大于85在熟练度测试中,然后你可以将该约束写入SaveEmployee sproc,并让它为尝试这样做的任何客户端代码抛出异常......

当然你可以使用客户端代码做同样的事情,但使用sProcs使得这个过程更容易设计和管理,因为它在一个地方,并且所有试图访问这个数据库系统的应用程序都必须符合任何约束条件和/或者您在SProcs中定义的安全性规定...如果SProc是插入或更新数据库的唯一方式,那么编写一个新的单独客户端应用程序来攻击数据库的流氓开发人员可以忽略或解决SProc中的约束或安全性规定.记录...

Answer 2

您可能不想让Matt carte-blanc直接更新某些表或列.如果马特决定这样做怎么办:

UPDATE Person.Address SET AddressLine1 = NULL

哎呦.Matt忘记了WHERE子句并且只是管理了你的数据库.或者也许马特对他的老板很生气,并决定在一天结束时退出.或者也许Matt的密码不像以前那样安全,现在黑客就拥有了它.

这只是一个简单的例子.对表和列的控制可能变得更加复杂,并且可能通过存储过程以外的任何其他方式无法维护.

Answer 3

存储过程允许用户执行 CRUD 操作（插入、更新、删除），但只能以有限的方式执行，从而提供额外的安全性。例如，允许用户 Matt 更新某些行的地址，但不更新其他行的地址。

它允许您添加数据检查，以确保插入的数据是有效数据，而不是随机垃圾。对于大多数事情，您可以使用约束和/或触发器来完成某些工作，但有一些限制。存储过程通过确保用户允许正在执行的操作来增强安全性。

通过由应用程序控制的单点访问，而不是通过任意数量的接口，可以更轻松地跟踪数据库的更改。并且该过程可以更新审核日志。