Назад | Перейти на главную страницу

Проблема стратегии аутентификации SQL Server только для Windows

Я хотел бы использовать аутентификацию только для Windows в SQL Server для наших веб-приложений. Раньше мы всегда создавали мощный 1 SQL Login для веб-приложения. После начального тестирования мы решили создать группы Windows Active Directory, которые имитируют роли безопасности приложения (т. Е. Администраторы, менеджеры, пользователи / операторы и т. Д.). Мы создали сопоставленные имена входа в SQL Server с этими группами. и предоставил им доступ к базе данных для приложения. Кроме того, мы создали роли базы данных SQL Server и назначили каждой группе соответствующую роль. Это отлично работает. Моя проблема заключается в том, что для большинства приложений каждый в компании должен иметь доступ для чтения к отчетам (и, следовательно, к данным). Насколько я могу судить, у меня есть 2 варианта: 1) Создать "роль" группы AD только для чтения / просмотра для каждого приложения и поместить в нее всех. 2) Используйте группы «домен \ пользователи домена» и назначьте им правильные роли в SQL. Каков наилучший и / или самый простой способ разрешить каждому доступ для чтения к определенным объектам базы данных с использованием метода проверки подлинности только для Windows?

Вариант 1 - ваш лучший выбор.

Предоставление доступа к Public - не лучшая идея. Может случиться так, что пользователь изменит должностные функции, и в этот момент вы не захотите, чтобы роль Public имела доступ к вашим данным. Если только это не тот случай, когда буквально КАЖДЫЙ человек в вашей организации получает доступ к вашему приложению.

Создание группы и последующее присвоение ей роли читателя данных не обязательно является хорошей идеей, потому что могут быть данные, которые вы не хотите, чтобы все участники этой роли читали (таким образом, ваша спецификация «конкретных объектов базы данных»).

Если вы создадите группу, а затем предоставите ей доступ SELECT / EXECUTE / etc к рассматриваемым объектам, это должно сделать это за вас.

Вы всегда можете предоставить доступ к различным защищаемым объектам роли публичного сервера. Если специально не предоставлены или отклонены привилегии, каждый пользователь наследует разрешения, предоставленные Public.