Является ли безопасность SQL Server / Windows полезной для чего-либо?

Question

Различия между разрешениями пользователей Windows и любым набором грантов SQL Server кажутся несвязанными понятиями. Похоже, что часто это делается с помощью псевдожурналов для ролей базы данных; но это не подходит обратно к разрешениям Windows. При условии проверки личности при едином входе, почему бы просто не пойти с простейшими ролями базы данных?

РЕДАКТИРОВАТЬ:
Пока что мы получили единственное преимущество: вам не нужно хранить пароль в вашем приложении; но это больше похоже на тривиальное полезное последствие, чем на цель дизайна; Есть много других, более прямых способов достижения этого, без тесного соединения всех устройств безопасности обеих вселенных.

ИЗМЕНИТЬ СНОВА:
Кто-нибудь еще может предложить какую-либо выгоду, кроме единого входа в систему и возможности SD поддерживать группы, дублируя тем самым возможность для групп (на основе того же имени пользователя), уже существующих в SQL Server?

Групповая проблема имеет несколько недостатков, в том числе предположение, что менеджер AD предполагается одинаково квалифицированным, чтобы поддерживать оба; и он исключает любые сетевые подключения, которые не являются частью AD (тем самым блокируя вас в технологии MS.)

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

Answer 1

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

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

Answer 2

Независимо от того, что относится к таблице грантов и т. Д., Сторона входа в систему очень полезна, потому что ваше приложение может подключаться к SQL-серверу с помощью аутентификации Windows, что означает

Вам не нужно указывать имя пользователя и пароль вашей базы данных в файле где-то в приложении

Каждый раз, когда вы помещаете пароль в простой текстовый файл, это угроза безопасности. Избегать это здорово.

Answer 3

Я думаю, что встроенная защита хороша, если она используется правильно. По какой-то причине я не могу понять, что многие компании, в которых я работал, не используют AD, разрешения SQL и модель безопасности IIS.

Если бы вам пришлось проектировать систему разрешений SQL Server с ключевым требованием, чтобы она была интегрирована в AD, вы, вероятно, могли бы придумать нечто очень похожее. ИМХО.

Мне нравится группировать пользователей в группы AD, а затем создавать групповые имена входа на SQL Server с различными разрешениями. Люди не должны иметь больше доступа к данным только потому, что у них есть инструменты для подключения к базе данных. Они должны иметь одинаковые права доступа к данным независимо от того, как они подключаются.

Гостевые пользователи (как и у анонимных веб-пользователей) должны быть в группе AD сами, в соответствии с рекомендациями по настройке IIS. Предоставление этой группе только доступа к тому, к чему они должны иметь доступ в базе данных, может однажды спасти данные от катастрофы. Трудно прочитать исходный код, чтобы узнать, защищены ли данные, гораздо проще изучить разрешения базы данных и конфигурацию безопасности.

Кроме того, неинтегрированная безопасность вредна, потому что пароли всегда распространяются, помещаются в конфигурационные файлы и т. Д.

Answer 4

Для корпоративного приложения, которое будет работать в среде AD, использование интегрированной безопасности Windows, безусловно, является правильным подходом. Вы не хотите, чтобы пользователи, которые уже прошли проверку подлинности в среде, должны были управлять отдельным набором учетных данных только для вашего приложения. Обратите внимание, что речь идет о аутентификации ... для авторизации вы все равно будете использовать безопасность на основе ролей сервера SQL.