Как можно предоставить все права и привилегии фиксированной роли базы данных db_owner для роли приложения?
Короткая версия
Команда:
GRANT CONTROL ON [DatabaseName] TO [ApplicationRoleName];
было бы то, что я хочу, но это не с:
Msg 15151, Level 16, State 1, Line 23
Cannot find the object 'DatabaseName', because it does not exist or you do not have permission.
Усилия по исследованию
Я исследую с помощью SQL Server Роли приложений .
- это как пользователь (в том смысле, что у него есть имя пользователя и пароль)
- и это как роль
После подключения к серверу ваше приложение запускает хранимую процедуру для "логин" сам как приложение:
EXECUTE sp_SetAppRole @rolename='Contoso.exe', @password='Tm8gaSBkaWRuJ3QganVzdCBiYXNlNjQgZW5jb2RlIGEgcGFzc3dvcmQuIEl0J3Mgb25seSBhbiBleGFtcGxlIQ=='
Права доступа db_owner
Обычно приложение входит в систему как пользователь , который является участникомфиксированной роли db_owner .Роль db_owner имеет разрешение:
- на все
- на каждую таблицу
- на каждое представление
- на каждую хранимую процедуру, функция
- для всех существующих объектов
- и всех объектов, которые будут существовать в будущем
А пока:
- можно разместить пользователь в роли базы данных
- вы можете поместить пользователя в роль приложения
Вы не можете поместить роль приложения в роль базы данных
Таким образом, вопрос в том, как предоставить моей роли приложения все разрешения для всего.
Разрешения для роли
Итак, пришло время предоставить разрешения для роли.Следуя советам на этой странице:] 2
GRANT SELECT, INSERT, UPDATE, DELETE ON Users TO "Contoso.exe";
Это интересно и все, но не все привилегии - только 10 *, INSERT, UPDATEи DELETE.Я хочу предоставить все - особенно, когда я не знаю, каковы все привилегии (или могут быть).
Я слепо пытаюсь:
GRANT ALL ON Users to "Contoso.exe";
The ALL permission is deprecated and maintained only for compatibility. It DOES NOT imply ALL permissions defined on the entity.
Хорошо, поэтому предоставление ALL не дает ALL.Это ... страшно.
Так что я вернулся к:
GRANT SELECT, INSERT, UPDATE, DELETE ON Users TO "Contoso.exe";
За исключением того, что не дает все.Например, я случайно узнал, что есть возможность затем предоставлять привилегии другим (привилегия, которой обладает db_owner).Поэтому я должен изменить свою вещь на:
GRANT SELECT, INSERT, UPDATE, DELETE ON Users TO "Contoso.exe" WITH GRANT OPTION;
Хорошо, так что это ближе, но это относится только к одной таблице.
Мне нужно что-то, что относится ко всем таблицам:
EXECUTE sp_msForEachTable 'GRANT SELECT, INSERT, UPDATE, DELETE ON ? TO "Contoso.exe" WITH GRANT OPTION;'
Хотя оказывается, что я упустил некоторые привилегии:
- SELECT ✔️
- INSERT ✔️
- UPDATE ✔️
- DELETE ✔️
- ССЫЛКИ ❌
- ALTER ❌
Конечно, я могу обновить свой сценарий:
EXECUTE sp_msForEachTable 'GRANT SELECT, INSERT, UPDATE, DELETE, REFERENCES, ALTER ON ? TO "Contoso.exe" WITH GRANT OPTION;'
Но вместо того, чтобы угадывать кошки-мышкиигра: я хочу предоставить ВСЕ разрешения.
ALL - это почти все
В приведенном выше предупреждении SQL Server отмечает, что ALL не предоставляет все.Но они документируют то, что все делает предоставить:
| Permission | Table | View | SP | Scalar UDF | Table UDF |
|------------|-------|------|----|------------|-----------|
| SELECT | ✔️ | ✔️ | | | ✔️ |
| INSERT | ✔️ | ✔️ | | | ✔️ |
| UPDATE | ✔️ | ✔️ | | | ✔️ |
| DELETE | ✔️ | ✔️ | | | ✔️ |
| REFERENCES | ✔️ | ✔️ | | ✔️ | ✔️ |
| EXECUTE | | | ✔️ | ✔️ | |
| ALTER | ❌ | ❌ | ❌ | ❌ | ❌ |
УПРАВЛЯТЬ всеми разрешениями
Оказывается, что все они были обмануты.Для другого разрешения были созданы.Одно разрешение управлять ими всеми:
Предоставляет грантоподобные возможности для получателя.Получатель фактически имеет все определенные разрешения на защищаемый объект.Принципал, которому был предоставлен КОНТРОЛЬ, может также предоставлять разрешения на защищаемый объект.Поскольку модель безопасности SQL Server является иерархической, в конкретной области управления CONTROL неявно включает в себя CONTROL для всех защищаемых объектов в этой области.Например, CONTROL для базы данных подразумевает все разрешения для базы данных, все разрешения для всех сборок в базе данных, все разрешения для всех схем в базе данных и все разрешения для объектов во всех схемах в базе данных.
Они продолжают перечислять разрешения, которые подразумеваются, когда у вас есть CONTROL :
- ALTER
- CONTROL
- DELETE
- ВЫПОЛНИТЬ
- ВСТАВИТЬ
- ПОЛУЧИТЬ
- ССЫЛКИ
- УПРАВЛЕНИЕ
- ПОЛУЧИТЬ ВЛАДЕНИЕ
- ОБНОВИТЬ
- ПОСМОТРЕТЬ ИЗМЕНЕНИЕ ОТСЛЕЖИВАНИЯ
- СМОТРЕТЬ ОПРЕДЕЛЕНИЕ
Это намного лучше.Вместо того, чтобы знать все разрешения, я просто предоставляю одно.И вместо того, чтобы знать, какие разрешения применимы к каким объектам, я даю только один.И из-за строки:
Принципал, которому предоставлен КОНТРОЛЬ, может также предоставлять разрешения для защищаемого объекта.
Мне не нужно GRANT WITH GRANT:
EXECUTE sp_msForEachTable 'GRANT CONTROL ON ? TO [Contoso.exe];' --when you have CONTROL you also get WITH GRANT for free
Для всех объектов
Моя проблема заключается в том, что мне нужно дать разрешение CONTROL для каждого объекта в базе данных.И каждый раз, когда добавляется любой новый объект, я должен обязательно вернуться и добавить его к роли приложения.
Что мне нужно, это то, что намекнуло моему Microsoft:
Например, CONTROL для базы данных подразумевает все разрешения для базы данных, все разрешения для всех сборок в базе данных, все разрешения для всех схем в базе данных и все разрешения для объектов во всех схемах в базе данных.
Если пересказать, если вы предоставите CONTROL для базы данных , то у вас будут все разрешения:
- для базы данных
- для всех объектов
- все сборки в базе данных
- все схемы
Это то, что я хочу.Я хочу предоставить разрешение GRANT CONTROL для базы данных Grobber на роль приложения [Contoso.exe]:
GRANT CONTROL ON Grobber TO "Contoso.exe";
Msg 15151, Level 16, State 1, Line 23
Cannot find the object 'Grobber ', because it does not exist or you do not have permission.
Возможно, я почти решил свою проблему, но меня остановили на линии 1 ярд.
Или я могу быть совсем рядом.Поэтому я спрашиваю о SO:
Как предоставить разрешения db_owner другой роли?
Редактировать: Предупреждение: Не использовать роли приложения -это нарушает все
Когда ваш клиент входит в роль приложения, эта идентичность является постоянным свойством этого соединения.А при включенном пуле соединений (как это является предпочтительным вариантом по умолчанию в ADO.net, ADO и ODBC) это соединение остается открытым в течение long времени - даже после закрытия соединения.
Когда ваше приложение (т.е. веб-сервер) пытается открыть новое соединение, оно получает его из пула соединений.Первое, что делает SqlConnection , это пытается сбросить состояние соединения обратно в состояние по умолчанию (используя sp_reset_connection).
Одна из вещей, которые sp_reset_connection пытается сделать, этоотменить тот факт, что вы роль приложения пользователь.Это недопустимо (потому что сервер не знает, кем вы были раньше).Таким образом, при использовании ролей приложений вы внезапно получите ошибки при попытке подключения к серверу.
Единственный способ «исправить» - это отключить соединение
Это то, что вы не хотите делать.
Таким образом, решение состоит в том, чтобы не использовать роли приложений в производственной среде.установка.