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

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

我知道对于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操作保护表甚至列,使用存储过程如何提供额外的安全性或安全性管理？

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

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

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

UPDATE Person.Address SET AddressLine1 = NULL

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

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