Sql Server 2008 схема разделения и разрешения

Question

В настоящее время я работаю над инфраструктурой, которая позволит нам иметь единую базу данных для нескольких приложений, где все они совместно используют общий набор сущностей (таблиц).Каждая из схем сопоставляется с набором объектов домена через ORM.

Идея состоит в том, чтобы иметь одно приложение типа администратора для администрирования общего набора объектов.Каждое из других приложений имеет свою собственную схему для своих собственных сущностей, но кроме того, оно может читать только сущности из общего набора.Поскольку каждое из этих приложений имеет свой собственный вход в базу данных и владение схемой по назначенной схеме, вначале это приводит к общей схеме, предоставляющей разрешения только для чтения всем этим входам в систему.

Возможно, проще говоря, у нас естьследующие три схемы:

• Общие
• Schema_A
• Schema_B

и приложения:

Приложение администратора:

• Вход в систему Admin
• владение схемой Common
• Модель домена Common

Приложение A:

• Вход в систему A
• Владение Schema_A
• Только для чтения и владение схемой Common
• Модель домена Model_A
• Модель домена Common

Приложение B:

• Логин B
• Владение Schema_B
• Только для чтения по схеме Common
• Модель домена Model_B
• Модель домена Common

Вышеприведенный сценарий довольно прост: добавьте SELECT permissСхема общего над логинами A и B.

Но, скажем, теперь я хочу предоставить Application A разрешение INSERT, DELETE, UPDATE определенной таблицы в схеме Common.Для ясности предположим, что у нас есть таблица с именем Files, в которую может вставлять любое приложение.

Единственный способ, которым мне удалось это сделать, - это предоставить для входа A все эти разрешения схемы.Если бы я дал ему только те разрешения для таблицы «Файлы» в общей схеме, было бы отказано в разрешении во время выполнения.Однако, делая это теперь, вы получаете права входа A для всех таблиц в схеме - что на самом деле нежелательно.

Как или где предоставить необходимые разрешения, чтобы они применялись только к конкретной таблице?

Answer 1

Прежде всего: вы можете предоставить разрешения отдельным таблицам, см. Самый первый пример в Разрешения объекта GRANT :

GRANT SELECT ON OBJECT::Person.Address TO RosaQdM;

Таким образом, вы можете просто предоставить INSERT / UPDATE / DELETEразрешение для конкретной таблицы Common.Files на User A и User B (это пользователи, а не логины, поскольку вы говорите о принципалах базы данных ).

ДляСамое долгое время рекомендуемое решение состояло в том, чтобы иметь набор хранимых процедур, которые контролируют доступ, и предоставлять EXECUTE и эти хранимые процедуры.См. Управление разрешениями с помощью хранимых процедур в SQL Server .Ваш ORM может использовать эти хранимые процедуры вместо доступа к необработанным таблицам. Это хорошо работает для операций записи, но для операций чтения не работает с ORM, который позволяет передавать произвольные запросы в базу данных (например, LINQ), потому чтонабор результатов вывода хранимой процедуры не может быть обработан как прямая таблица.Но поскольку ваш макет в любом случае разрешает R / O-доступ к общей схеме, вы можете использовать его для всех SELECT и использовать только хранимые процедуры для операций записи.

Таким образом, вы можете использовать любое из этих двух решений: либо предоставить разрешения на запись в таблицы (таблицы), либо использовать хранимые процедуры и предоставить разрешение EXECUTE для них.Хранимая процедура добавляет уровень проверки и заставляет приложение подчиняться определенному API при использовании таблиц (например, они не могут выполнить DELETE FROM Common.Files и стереть всю таблицу).С другой стороны, прямой доступ к таблице для записи легче использовать в ORM.