SQL Server: как разрешить схемы?

Вдохновленный различными вопросами, связанными со схемой, я видел ...

Цепочка владения Позволяет мне выполнить команду GRANT EXECUTE для хранимой процедуры без явных разрешений для таблиц, которые я использую, если хранимая процедура и таблицы находятся в одной и той же схеме.

Если мы будем использовать отдельные схемы, то мне придется явно GRANT XXX для таблиц с различными схемами. Пример цепочки владения демонстрирует это. Это означает, что пользователь, выполняющий хранимую процедуру, может напрямую читать / записывать ваши таблицы.

Это все равно, что иметь прямой доступ к переменным вашего экземпляра в классе, обходя getter / setters, нарушая инкапсуляцию.

Мы также используем безопасность на уровне строк, чтобы ограничить то, что кто-то видит, и применяем это в хранимых процедурах.

Итак, как мы можем поддерживать разделение схем и предотвращать прямой доступ к таблицам?

Конечно, этот вопрос не будет применяться, если вы используете ORM или не используете хранимые процедуры. Но яне спрашиваю, должен ли я использовать ORM или сохраненный процесс на случай, если кто-то почувствует необходимость просветить меня ...

Изменить, пример

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)

Ваш ответ на вопрос