Является ли безопасность SQL Server/Windows полезной для чего-либо?
Различия между разрешениями пользователей Windows и любым набором грантов SQL Server кажутся несвязанными понятиями. Похоже, что часто это происходит с помощью псевдожурналов для ролей базы данных; но это не подходит обратно к разрешениям Windows. При условии проверки личности при едином входе, почему бы просто не пойти с простейшими ролями базы данных?
РЕДАКТИРОВАТЬ:
До сих пор мы получили единственное преимущество: вам не нужно хранить пароль в вашем приложении; но это больше похоже на тривиальное полезное последствие, чем на цель дизайна; Есть много других, более прямых способов достижения этого, без тесной связи всех устройств безопасности обеих вселенных.
ИЗМЕНИТЬ СНОВА:
Кто-нибудь еще может предложить что-то еще, кроме единого входа в систему и возможности SD поддерживать группы, дублируя тем самым возможность для групп (на основе того же имени пользователя), уже существующих в SQL Server?
Проблема группы имеет несколько недостатков, в том числе предположение, что менеджер AD предполагается одинаково квалифицированным, чтобы поддерживать оба; и он исключает любые сетевые подключения, которые не являются частью AD (тем самым блокируя вас в технологии MS).
И чтобы выразить это с точки зрения наилучшей практики, вы встроили соединение систем, которое обычно считается плохим.
14 ответов
Многие из них были сказаны или похожи на предыдущие ответы... С интеграцией AD:
а) Мне не нужно беспокоиться о пользователях, которые имеют доступ к любому приложению, я могу передать это парням из службы безопасности.
б) я могу ограничить доступ к таблице на уровне таблицы на основе уже существующих групп, а также заставить обычных пользователей иметь возможность только вызывать хранимые процедуры.
c) Когда разработчик покидает мою группу, нам не нужно менять все пароли БД (например, если вы заботитесь о безопасности данных...)
г) Легко сделать пользовательскую регистрацию на основе пользователя, который вносит изменения. Есть и другие способы сделать это, но я все о том, чтобы быть ленивым.
e) Интегрируется с аутентификацией IIS. Если вы уже используете IE & IIS для своей интрасети, это просто делает жизнь намного проще.
Примечание: Есть гораздо больше причин, чтобы не использовать его, и я никогда не использовал его до моей нынешней должности. Здесь, где все уже выстроено в AD... Это просто самое легкое время, которое я когда-либо имел с безопасностью базы данных.
При использовании встроенной защиты вашему приложению не нужно ничего знать или обращаться с безопасностью, а также, если пользователь уже вошел в ваш домен, ему также не нужно заходить в ваше приложение (при условии, что у вас есть олицетворение) настроен правильно).
Самым большим преимуществом должно быть использование группы AD в качестве имени входа в SQL Server. Таким образом, вы можете дать доступ каждому в группе "Учетные записи" доступ к набору sprocs, таблицам и т. Д., А всем в группе "Менеджеры" - доступ к другому набору, все с помощью AD. Системным администраторам не нужно заходить в Management Studio, чтобы предоставить пользователям права доступа к вашему приложению.
Я предполагаю, что это в основном сводится к тому, чтобы "не изобретать велосипед" и не использовать эффект "многих глаз".
Используя аутентификацию Windows, вы используете возможности встроенной безопасности Windows, поверх которой вы можете добавлять свои собственные материалы, если хотите. Это уже зрелая система, которая была проверена миллионы раз, избавляя вас от усилий (и от ваших клиентов, от стоимости) делать свои собственные ошибки и обнаруживать / исправлять их позже.
А затем множество людей постоянно сканируют процесс проверки подлинности Windows, проверяют его на наличие уязвимостей, ищут способы его обойти и т. Д. Когда уязвимость открыто раскрывается и создается ее исправление, ваше приложение просто получает "бесплатное" повышение безопасности.,
В моей текущей работе у нас есть группы AD в качестве логинов SQL, поэтому мы назначаем разрешения SQL на основе членства в группах AD. Таким образом, у всех членов инженерной группы sys есть некоторые разрешения, у администраторов баз есть другие, обычные пользователи - другие, контролеры - другие и т. Д. Добавление новых пользователей или изменение их разрешений - это простая вещь, которую можно сделать только один раз в AD, и они сразу же получают разрешения, которые они должны получить в базе данных.
Редактировать сообщение:
Немного подробнее о "изобретении велосипеда": для учетной записи AD я могу отказать в праве войти в систему на конкретном компьютере или заблокировать его для каждой машины, кроме одного или двух. Я могу помешать им войти на более чем 2 рабочих станции одновременно. Я могу заставить их сменить пароли через некоторое время, а также ввести в них минимальную силу. И некоторые другие приемы, все из которых улучшают безопасность в моей системе.
С пользователями SQL S. у вас ничего этого нет. Я видел людей, пытающихся заставить их выполнять сложные задания SQL или что-то вроде доморощенного демона, который, по моему мнению, заново изобретает колесо, уже изобретенное.
И тогда вы не сможете остановить вход SA пользователя (или привилегированного пользователя) с любого компьютера. Однажды мне рассказали о том, как остановить грубую атаку на SQL S. У него был открыт порт для удаленного входа через Интернет - администраторы сайта реализовали задание, которое каждые полчаса меняло пароль SA. Если бы это был SQL + Windows, они могли бы просто сказать, что они хотят, чтобы администратор входил только из определенного бокса, или напрямую использовал только аутентификацию Windows, тем самым вынуждая любого сначала пройти через VPN.
Поскольку все остальные обсуждали преимущества аутентификации Windows, я думаю, что я буду играть в Devil's Advocate...
Разрешение учетной записи "Joe User" иметь доступ к серверу означает, что он не только может быть подключен к вашему приложению, но он также может подключаться любым другим способом (инструменты SQL, Excel, вредоносные программы и т. Д.).
С помощью SQL-аутентификации ваше приложение может работать от имени определенного пользователя, а затем приложение может обрабатывать доступ к базе данных. Поэтому, когда "Joe User" запускает ваше приложение, приложение имеет доступ к SQL… Но сам "Joe User" не имеет, что означает, что вышеупомянутые приложения не смогут иметь неявный доступ к базе данных.
Да, конечно, если у вас уровень доступа к данным уровня приложения работает как служба, вы можете использовать встроенную защиту для связи с базой данных, используя "учетную запись службы" приложения для входа на сервер... Тогда у вас нет; хранить пароли пользователей в файле конфигурации приложений, и вы не передаете пароли по сети при каждом новом подключении к базе данных
Логины SQL: обфусцированные пароли в виде открытого текста по сети
Интегрированный вход в Windows с NTLM: хэши передаются по проводам
Интегрированный вход в Windows через Kerberos: правильная безопасная аутентификация
Есть только один выбор, если вы заботитесь о безопасности.
Интегрированная безопасность действительно полезна только для приложений в интрасети. Я видел псевдо логины в основном для интернет-приложений.
В любом случае, это больше, чем просто не хранить пароль в вашем приложении, так как, надеюсь, вы все равно будете солить и хэшировать свой пароль. Есть также:
Пользователю не нужно входить в систему, что очень важно, если вы скачете в веб-приложение время от времени или работаете где-то с несколькими внутренними веб-приложениями.
Управление пользователями бесплатное, так как ИТ-администратору нужно только редактировать пользователя в Active Directory.
Имена пользователей и имена ролей едины во всей организации.
Олицетворение пользователя - более безопасный метод при доступе к внутреннему веб-сервису. (например, интернет-сайт обращается к интрасети веб-службы)
Веб-приложению не нужно делать никаких дополнительных авторизаций пользователя в базе данных, поскольку все это обрабатывается без проблем.
[EDIT] Вы также знаете пользователя в ваших объектах базы данных. Таким образом, вы можете иметь представление, возвращающее только строки, связанные с ними. (если вы не создадите нового пользователя SQLServer для каждого пользователя приложения, это будет невозможно, и создание нового пользователя SQLServer для каждого пользователя приложения также нецелесообразно)
Интегрированная безопасность подходит не для всех, но для предприятия существует большая добавленная стоимость.
По моему опыту, время отклика запросов, выполняемых к базе данных большинства приложений, значительно быстрее при подключении через проверку подлинности SQL. Удаляет задержку, возникающую при постоянном запросе AD на проверку безопасности.
Аутентификация SQL с точки зрения производительности >> встроенная безопасность Windows.
Независимо от того, что относится к грантовой таблице / etc, сторона входа в систему очень полезна, потому что ваше приложение может подключаться к SQL-серверу с помощью аутентификации Windows, что означает
Вам не нужно помещать имя пользователя и пароль вашей базы данных в файл в вашем приложении
Каждый раз, когда вы помещаете пароль в простой текстовый файл, это угроза безопасности. Избегать это здорово.
Как насчет того, что если вы используете аутентификацию сервера sql, информация о пароле передается по сети в виде открытого текста. Интегрированная безопасность не имеет этой проблемы.
База данных может иметь детальный доступ с множеством настроек, отличающихся для каждого пользователя. Это не только сценарий, когда у вас есть один пользователь для доступа к приложению, и это все безопасность данных.
Если мы говорим о командной разработке, то, вероятно, будет группа пользователей, которой предоставлен доступ для разработки к базе данных. Каждый пользователь в этой группе будет членом вашего внутреннего домена и имеет собственные пароли, которыми администратор базы данных не должен управлять, и даже знает, что он разрешает доступ к базе данных.
Я думаю, что встроенная безопасность хороша, если она используется правильно. По какой-то причине я не могу понять, что многие компании, в которых я работал, не используют AD, разрешения SQL и модель безопасности IIS.
Если бы вам пришлось проектировать систему разрешений SQL Server с ключевым требованием ее интеграции в AD, вы, вероятно, могли бы придумать нечто очень похожее. ПО МОЕМУ МНЕНИЮ.
Мне нравится группировать пользователей в группы AD, а затем создавать групповые имена входа на SQL Server с различными разрешениями. Люди не должны иметь больше доступа к данным только потому, что у них есть инструменты для подключения к базе данных. Они должны иметь одинаковые права доступа к данным независимо от того, как они подключаются.
Гостевые пользователи (как и у анонимных веб-пользователей) должны быть в группе AD сами по рекомендациям по настройке IIS. Предоставление этой группе только доступа к тому, к чему они должны иметь доступ в базе данных, может однажды спасти данные от катастрофы. Трудно прочитать исходный код, чтобы выяснить, защищены ли данные, гораздо проще проанализировать разрешения базы данных и конфигурацию безопасности.
Кроме того, неинтегрированная безопасность вредна, потому что пароли всегда распределяются, помещаются в конфигурационные файлы и т. Д.
Интегрированная безопасность дает большую гибкость в доступе пользователей IMO. Например, если моя организация хочет ограничить часы, в течение которых группа разработчиков может получить доступ к серверу, лучшим выбором будет встроенная защита.
Но это не подходит для всего.
[РЕДАКТИРОВАТЬ] Также это отлично подходит для регистрации доступа. Если бы мне нужно было создать учетную запись SQL для каждого нового разработчика в большой организации... это, вероятно, прекратило бы происходить, и вход в систему стал бы общим, тогда я бы никогда не поверил в возможность указать пальцем на тупицу, которая бросила Таблица.
Для корпоративного приложения, которое будет работать в среде AD, использование интегрированной безопасности Windows, безусловно, является правильным подходом. Вы не хотите, чтобы пользователи, которые уже прошли проверку подлинности в среде, должны были управлять отдельным набором учетных данных только для вашего приложения. Обратите внимание, что мы говорим об аутентификации... для авторизации вы все равно используете безопасность на основе ролей сервера SQL.