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

Question

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

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

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

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

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

Answer 1

Многие из них были сказаны или похожи на предыдущие ответы ... С интеграцией AD:

a) Мне не нужно беспокоиться о пользователях, имеющих доступ к какому-либо конкретному приложению, я могу передать это парням из службы безопасности.

b) Я могу ограничить доступ к таблице на уровне таблицы на основе уже существующих групп, а также заставить обычных пользователей иметь возможность только вызывать хранимые процедуры.

в) Когда разработчик покидает мою группу, нам не нужно менять все пароли БД (т. Е. Если вы заботитесь о безопасности данных ...)

d) Легко сделать пользовательскую регистрацию на основе пользователя, который вносит изменения. Есть и другие способы сделать это, но я все о том, чтобы быть ленивым.

e) Интегрируется с аутентификацией IIS. Если вы уже используете IE & IIS для своей интрасети, это только облегчит жизнь.

Примечание: есть гораздо больше причин не использовать его, и я никогда не использовал его до моей нынешней должности. Здесь, где все выстроено в очередь уже в AD ... Это просто самое легкое время, которое я когда-либо имел с безопасностью базы данных.

Answer 2

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

Самым большим преимуществом должно быть использование группы AD в качестве имени входа в SQL Server. Таким образом, вы можете предоставить доступ каждому в группе «Учетные записи» доступ к набору sprocs, таблицам и т. Д., А всем членам группы «Менеджеры» - доступ к другому набору, все с помощью AD. Системным администраторам не нужно заходить в Management Studio, чтобы предоставить пользователям права доступа к вашему приложению.

Answer 3

Полагаю, это сводится к тому, чтобы "не изобретать велосипед" и не использовать эффект "многих глаз".

Используя аутентификацию Windows, вы используете возможности встроенной безопасности Windows, помимо которой вы можете добавлять свои собственные, если хотите. Это уже зрелая система, которая была проверена миллионы раз, избавляя вас от усилий (и от ваших клиентов, от затрат) на то, чтобы делать свои собственные ошибки и обнаруживать / исправлять их позже.

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

В моей текущей работе группы AD используются как логины SQL, поэтому мы назначаем разрешения SQL на основе членства в группах AD. Таким образом, у всех членов инженерной группы sys есть некоторые разрешения, у администраторов есть другие, обычные пользователи - другие, контролеры - другие и т. Д. Добавление новых пользователей или изменение их разрешений - простая задача, которую можно выполнить только один раз в AD, и они сразу же получают разрешения, которые они должны получить в базе данных.

Редактировать сообщение :

Несколько слов о "изобретении велосипеда". В учетной записи AD я могу отказать в праве войти в систему на определенном компьютере или заблокировать его для каждой машины, за исключением одного или двух. Я могу запретить им входить в систему более чем на 2 рабочих станциях одновременно. Я могу заставить их сменить пароли через некоторое время, а также ввести в них минимальную силу. И некоторые другие приемы, все из которых улучшают безопасность в моей системе.

С пользователями SQL S. у вас ничего этого нет. Я видел людей, которые пытались заставить их выполнять сложные задания SQL или что-то вроде доморощенного демона, который, по моему мнению, изобретает колесо, изобретенное ранее.

И тогда вы не сможете остановить вход SA пользователя (или привилегированного пользователя) с любого компьютера. Однажды мне рассказали о том, как остановить грубую атаку на SQL S. У него был открыт порт для удаленного входа через Интернет - администраторы сайта реализовали задание, которое каждые полчаса меняло пароль SA. Если бы это был SQL + Windows, они могли бы просто сказать, что они хотят, чтобы администратор входил только с определенного ящика, или напрямую использовал только аутентификацию Windows, тем самым заставляя любого сначала пройти через VPN.

Answer 4

Поскольку все остальные обсуждали преимущества аутентификации Windows, я думаю, что я сыграю в Devil's Advocate ...

Разрешение учетной записи 'Joe User' иметь доступ к серверу означает, что он не только может быть подключен к вашему приложению, но и может подключаться любым другим способом (SQL Tools, Excel, вредоносное ПО и т. Д.).

С помощью аутентификации SQL ваше приложение может работать от имени определенного пользователя, а затем приложение может обрабатывать доступ к базе данных. Поэтому, когда «Joe User» запускает ваше приложение, приложение имеет доступ к SQL… Но сам «Joe User» не имеет, что означает, что вышеупомянутые приложения не смогут иметь неявный доступ к базе данных.

Answer 5

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

Аутентификация SQL с точки зрения производительности >> встроенная защита Windows.

Answer 6

логины SQL: обфусцированные незашифрованные пароли по сети

Интегрированный вход в Windows с NTLM: хэши переданы по проводам

Интегрированный вход в Windows с Kerberos: правильная безопасная аутентификация.

Есть только один выбор, если вы заботитесь о безопасности.

Answer 7

Встроенная защита действительно полезна только для приложений в интрасети. Псевдо логины, которые я видел, в основном предназначены для интернет-приложений.

В любом случае, это больше, чем просто сохранение пароля в вашем приложении, так как, надеюсь, вы все равно будете солить и хэшировать свой пароль. Там же:

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

2. Управление пользователями бесплатное, поскольку ИТ-администратору необходимо только редактировать пользователя в Active Directory.

3. Имена пользователей и имена ролей едины во всей организации.

4. Олицетворение пользователя - более безопасный метод при доступе к внутреннему веб-сервису. (например, интернет-сайт обращается к веб-сервису интрасети)

5. Веб-приложению не требуется выполнять дополнительную авторизацию пользователя в базе данных, поскольку все это обрабатывается без проблем.

6. [EDIT] Вы также знаете пользователя в ваших объектах базы данных. Таким образом, вы можете иметь представление, возвращающее только строки, связанные с ними. (если вы не создадите нового пользователя SQLServer для каждого пользователя приложения, это будет невозможно, и создание нового пользователя SQLServer для каждого пользователя приложения также нецелесообразно)

Интегрированная безопасность подходит не для всех, но для предприятия существует большая добавленная стоимость.

Answer 8

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

Answer 9

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

Answer 10

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

Но это не для всех.

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