SQL Server: Как к схемам разрешения?
Вдохновленный различными связанными со схемой вопросами я видел...
Цепочка принадлежности позволяет мне ПРЕДОСТАВЛЯТЬ, ВЫПОЛНЯЮТСЯ на хранимой процедуре без явных полномочий на таблицах, которые я использую, если и хранимая процедура и таблицы находятся в той же схеме.
Если бы мы используем отдельные схемы затем, я должен был бы явно ПРЕДОСТАВИТЬ XXX на таблицы различной схемы. Пример цепочки принадлежности демонстрирует это. Это означает сохраненный proc, выполняющийся пользователь может чтение-запись Ваши таблицы непосредственно.
Это было бы похоже на прямой доступ наличия к Вашим переменным экземпляра в классе, обойдя метод считывания/методы set, повредив инкапсуляцию.
Мы также используем безопасность уровня строки для ограничения то, что кто-то видит, и мы применяем это в хранимых процедурах.
Так, как мы можем поддержать разделение схемы и предотвратить прямой доступ таблицы?
Конечно, вопрос не будет применяться, если Вы будете использовать ORM или не будете использовать сохраненный procs. Но я не спрашиваю, должен ли я использовать ORM или сохраненный proc в случае, если любой чувствует потребность просветить меня...
Редактирование, пример
CREATE USER OwnsMultiSchema WITHOUT LOGIN
GO
CREATE SCHEMA MultiSchema1 AUTHORIZATION OwnsMultiSchema
GO
CREATE SCHEMA MultiSchema2 AUTHORIZATION OwnsMultiSchema
GO
CREATE USER OwnsOtherSchema WITHOUT LOGIN
GO
CREATE SCHEMA OtherSchema AUTHORIZATION OwnsOtherSchema
GO
CREATE TABLE MultiSchema1.T1 (foo int)
GO
CREATE TABLE MultiSchema2.T2 (foo int)
GO
CREATE TABLE OtherSchema.TA (foo int)
GO
CREATE PROC MultiSchema1.P1
AS
SELECT * FROM MultiSchema1.T1
SELECT * FROM MultiSchema2.T2
SELECT * FROM OtherSchema.TA
Go
EXEC AS USER = 'OwnsMultiSchema'
GO
--gives error on OtherSchema
EXEC MultiSchema1.P1
GO
REVERT
GO
CREATE PROC OtherSchema.PA
AS
SELECT * FROM MultiSchema1.T1
SELECT * FROM MultiSchema2.T2
SELECT * FROM OtherSchema.TA
Go
GRANT EXEC ON OtherSchema.PA TO OwnsMultiSchema
GO
EXEC AS USER = 'OwnsMultiSchema'
GO
--works
EXEC OtherSchema.PA
GO
REVERT
GO
Редактирование 2:
- Мы не используем "перекрестную цепочку принадлежности базы данных"
- Безопасность уровня строки является отвлекающим маневром и не важный: мы не используем его везде
3 ответа
Боюсь, что ваше описание или ваша концепция цепочки владения неясны, поэтому позвольте мне начать с этого:
«Цепочка владения» просто относится к тот факт, что при выполнении хранимой процедуры (или представления) на SQL Server выполняемый в данный момент пакет временно получает права / разрешения владельца sProc (или владельца схемы sProc) при выполнении этого кода SQL. Таким образом, в случае sProc, Пользователь не может использовать эти привилегии для выполнения чего-либо, что код sProc для них не реализует. Обратите особое внимание на то, что он никогда не получает Identity Владельца, только права временно (однако EXECUTE AS ... делает это).
Таким образом, типичный подход к использованию этого для безопасности заключается в следующем:
Поместите все таблицы данных (и все представления, не связанные с безопасностью) в их собственную схему, назовем ее [данные] (хотя обычно [dbo ] используется, потому что он уже существует и слишком привилегирован для схемы пользователя). Убедитесь, что существующие пользователи, схемы или владельцы не имеют доступа к этой схеме [data].
Создайте схему с именем [exec] для всех sProc (и / или, возможно, любых представлений безопасности).Убедитесь, что владелец этой схемы имеет доступ к схеме [data] (это легко, если вы сделаете dbo владельцем этой схемы).
Создайте новую db-роль с именем «Пользователи» и предоставьте ей доступ EXECUTE к схеме [exec]. Теперь добавьте всех пользователей в эту роль. Убедитесь, что ваши пользователи имеют только права на подключение и не имеют доступа к какой-либо другой схеме, включая [dbo].
Теперь ваши пользователи могут получить доступ к данным, только выполнив sProc в [exec]. Они не могут получить доступ к другим данным или выполнять какие-либо другие объекты.
Я не уверен, отвечает ли это на ваш вопрос (потому что я не знал, в чем именно был вопрос), поэтому не стесняйтесь перенаправить меня.
Что касается безопасности на уровне строк, вот как я всегда это делаю со схемой безопасности, описанной выше:
Я всегда реализую безопасность на уровне строк в виде серии представлений, которые зеркально переносят каждую таблицу и сравнивают личность пользователя ( обычно с Suser_Sname () или одним из других) в список безопасности, введенный из кода безопасности в самой строке. Это Security-Views.
Создайте новую схему с именем [rows], предоставьте ее владельцу доступ к схеме [data] и ничего больше. Поместите все Security-Views в эту схему.
Отменить доступ владельца [exec] к схеме [data] и вместо этого предоставить ему доступ к данным к схеме [rows].
Готово. Теперь безопасность на уровне строк реализована путем прозрачного переключения между sProcs и таблицами.
Наконец, вот хранимая процедура, которую я использую, чтобы помочь мне вспомнить, сколько из этих непонятных средств защиты работает и взаимодействует с собой ( упс, исправленная версия кода ):
{{1 }}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_
[РЕДАКТИРОВАТЬ: исправленная версия кода)
Вы можете:
Grant Execute On Schema::[schema_name] To [user_name]
позволить пользователю выполнить любые процедуры в схеме. Если вы не хотите, чтобы он мог выполнить все из них, вы можете явно отказать пользователю в выполнении определенной процедуры. Отказ будет иметь преимущественную силу в этом случае.
Haskell: 212 211 208 символы
a=" | "
b=" ### "
d=concat.cycle
e=d[b,b,a,b,b,a,b]
f=d[a]
t x s m n=map(take(5*read s+m).drop(5*length['@'..x]-n))[e,e,e,e,e,f,f,f,d["__|__"]]
u(x:'#':s)=t x s 2 4
u(x:s)=t x s 1 8
main=interact$unlines.u
Он по-прежнему предполагает ascii-совместимые буквы (в частности, последовательность «@ ABCDEFG»), но больше не требует Char.ord
-121--778761-Попробуйте
type TCallback = procedure(val: integer); stdcall;
My 2c: Ownership chaining is legacy. Он датируется днями, когда не было альтернатив, и по сравнению с сегодняшними альтернативами является небезопасным и грубым.
Я говорю, что альтернатива - это не разрешения схемы, а подписывание кода. При подписании кода можно предоставить необходимые разрешения на подпись процедуры и предоставить широкий доступ к выполнению процедуры, в то время как доступ к данным строго контролируется. Подписание кода обеспечивает более детальный и точный контроль, и нельзя злоупотреблять способом, которым может быть цепочка владения. Он работает внутри схемы, он работает по всей схеме, он работает по всей базе данных и не требует, чтобы огромное отверстие безопасности цепочки владения между базами данных было открыто. И не требует угона объекта собственности в целях доступа: владельцем процедуры может быть любой пользователь.
Что касается вашего второго вопроса о безопасности на уровне строк: безопасность на уровне строк в SQL Server версий 2014 и более ранних на самом деле не существует, как функция, предлагаемая механизмом. У вас есть различные обходные пути, и эти обходные пути работают на самом деле лучше с подписыванием кода, чем с цепочкой владения. Поскольку маркер sys.login _ содержит сигнатуры контекста и контрасначертания, можно выполнить более сложные проверки, чем в контексте цепочки владения.
Начиная с версии 2016 SQL Server полностью поддерживает безопасность на уровне строк .