Роль приложения SQL Server против обычных пользователей и пользователей

В чем преимущество использования роли приложения SQL Server для управления разрешениями по сравнению с использованием стандартных имен входа / пользователей и предоставления необходимых разрешений указанным пользователям?

Мы использовали роли приложений, которые требуют следующего сценария:

  1. Подключитесь к SQL Server, используя логин и пароль SQL Server.
  2. Активируйте роль приложения, передав имя роли и другой пароль в sp_setapprole.

Я не понимаю, как это может быть лучше или безопаснее, чем просто предоставление разрешений роли приложения логину / пользователю. Оба пароля должны быть доступны приложению, и любой, кто получит доступ к паролю входа в систему, может получить доступ к паролю роли приложения и вызвать sp_setapprole из своей собственной программы или в SSMS. Правильно?

РЕДАКТИРОВАТЬ: Как предположил Эд Харпер, все экземпляры приложения используют один и тот же логин в моем сценарии.

Источник

2 ответа

Решение

Это не совсем понятно из вашего описания, но звучит так, как будто вы используете имя входа SQL, назначенное на уровне приложения - т.е. все экземпляры приложения (при условии, что существует более одного экземпляра) используют один и тот же логин / пароль. В этом случае использование роли приложения добавляет очень мало пользы.

Насколько я понимаю, роли приложений предназначены для использования в тех случаях, когда каждый пользователь имеет свой собственный логин в SQL Server (возможно, в случае, когда доступ к базе данных предоставляется посредством аутентификации AD), но вы не хотите предоставлять пользователям то же самое. права в качестве приложений, которые они используют; это предполагает, что приложение подключается к базе данных с идентификатором пользователя AD, а затем повышает свои разрешения с помощью sp_setapprole, Я никогда не видел, чтобы этот подход использовался в производственной системе.

Источник

Я никогда не использовал роли приложений (CREATE APPLICATION ROLE).
Я действительно не вижу смысла их

Я использовал роли базы данных и добавил пользователей в качестве участников

CREATE ROLE WebUsers AUTHORIZATION dbo;
ALTER ROLE WebUsers ADD MEMBER Tom;
ALTER ROLE WebUsers ADD MEMBER Dick;
ALTER ROLE WebUsers ADD MEMBER Harry;

CREATE ROLE WebAdmins AUTHORIZATION dbo;
ALTER ROLE WebAdmins ADD MEMBER Tom;

Роли имеют разрешения, а не пользователь

GRANT EXEC TO WebAdmins;

GRANT EXEC On SCHEMA::WebCode TO WebAdmins;
Источник

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

Источник
Другие вопросы по тегам