Опасявам се, че или вашето описание, или вашата концепция за веригата на собствеността са неясни, така че позволете ми да започна с това:
„Верига на собствеността“ просто се отнася до този факт, че при изпълнение на съхранена процедура (или изглед) на SQL Server, текущо изпълняваният пакет временно придобива правата/разрешенията на собственика на sProc (или собственика на схемата на sProc), докато изпълнява този SQL код. Така че в случай на sProc, потребителят не може да използва тези privs, за да направи нещо, което sProc кодът не имплементира за тях. Имайте специално предвид, че никога не придобива Идентичност на Собственика, само неговите права, временно (обаче, EXECUTE AS... прави това).
Така че типичният подход за използване на това за сигурност е:
-
Поставете всички таблици с данни (и всички изгледи, които не са свързани със сигурността) в тяхната собствена схема, нека я наречем [данни] (въпреки че обикновено [dbo] се използва, защото вече е там и е твърде привилегирован за схемата на потребителя). Уверете се, че съществуващи потребители, схеми или собственици нямат достъп до тази схема [данни].
-
Създайте схема, наречена [exec] за всички sProcs (и/или евентуално всички изгледи за защита). Уверете се, че собственикът на тази схема има достъп до схемата [data] (това е лесно, ако направите dbo собственик на тази схема).
-
Създайте нова db-роля, наречена „Потребители“ и й дайте достъп EXECUTE до схемата [exec]. Сега добавете всички потребители към тази роля. Уверете се, че вашите потребители имат само права за свързване и нямат предоставен достъп до друга схема, включително [dbo].
Сега вашите потребители имат достъп до данните само чрез изпълнение на sProcs в [exec]. Те нямат достъп до други данни или да изпълняват други обекти.
Не съм сигурен дали това отговаря на въпроса ви (защото не бях сигурен какъв точно е въпросът), така че не се колебайте да ме пренасочите.
Що се отнася до сигурността на ниво ред, ето как винаги го правя със схемата за сигурност по-горе:
-
Винаги прилагам сигурност на ниво ред като поредица от изгледи, които огледално обгръщат всяка таблица и сравняват самоличността на потребителя (обикновено с Suser_Sname() или някой от другите) със списък за сигурност, въведен от код за сигурност в самия ред. Това са изгледите за защита.
-
Създайте нова схема, наречена [редове], дайте на нейния собственик достъп до схемата [данни] и нищо друго. Поставете всички изгледи за сигурност в тази схема.
-
Отменете достъпа на собственика [exec] до схемата [data] и вместо това му дайте достъп до данни до схемата [rows].
Свършен. Сега сигурността на ниво ред е внедрена чрез прозрачно плъзгане между sProcs и таблиците.
И накрая, ето съхранена доставка, която използвам, за да си спомня каква част от тези неясни неща за сигурност работят и взаимодействат със себе си (опа, коригирана версия на кода ):
CREATE proc [TestCnxOnly].[spShowProc_Security_NoEX] as
--no "With Execute as Owner" for this version
--create User [UserNoLogin] without login
--Grant connect on database :: TestSecurity to Guest
--alter database TestSecurity set trustworthy on
--Show current user context:
select current_user as current_
, session_user as session
, user_name() as _name
, suser_name() as [suser (sproc)]
, suser_sname() as sname
, system_user as system_
--Execute As Login = 'UserNoLogin'
select current_user as current_
, session_user as session
, user_name() as _name
, suser_name() as [suser (after exec as)]
, suser_sname() as sname
, system_user as system_
EXEC('select current_user as current_
, session_user as session
, user_name() as _name
, suser_name() as [suser (in Exec(sql))]
, suser_sname() as sname
, system_user as system_')
EXEC sp_ExecuteSQL N'select current_user as current_
, session_user as session
, user_name() as _name
, suser_name() as [suser (in sp_Executesql)]
, suser_sname() as sname
, system_user as system_'
--Revert
select current_user as current_
, session_user as session
, user_name() as _name
, suser_name() as [suser (aftr revert)]
, suser_sname() as sname
, system_user as system_
[РЕДАКТИРАНЕ:коригирана версия на кода)