Аутентификация базы данных для интранет-приложений

Question

Я ищу наилучшую практику сквозной аутентификации для внутренних веб-приложений на уровне базы данных.

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

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

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

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

Answer 1

Дейл - Точно. Если вы хотите предоставить доступ к базовому хранилищу данных этим пользователям, сделайте это с помощью сервисов. По моему опыту, именно опытные пользователи компьютеров, выходящие из Uni / College, больше всего повреждают. Как говорится, они знают достаточно, чтобы быть опасными.

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

Моя основная мысль заключается в том, что база данных - это общеизвестный святой Грааль приложения. Вы хотите как можно меньше пальцев в этом конкретном пироге.

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

Answer 2

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

Тогда доступ к приложению будет контролироваться через учетную запись домена пользователя (отключение анонимного доступа в IIS и т. Д.).

ЕСЛИ пользователю нужен прямой доступ к базе данных и он может это обосновать, тогда его учетной записи домена будет предоставлен доступ к базе данных, и он сможет войти в СУБД соответствующие инструменты.

Answer 3

Я согласен со Стивеном Райтоном. Безопасность домена - это путь. Если вы хотите использовать коллажи и что-то другое, вы можете открыть части базы данных через машиночитаемый интерфейс RESTful. SubSonic имеет один встроенный .

Answer 4

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

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

Затем с помощью делегирования вы можете разрешить департаментам контролировать доступ к своим собственным учетным записям через группы согласно сообщению Джонатана.

Answer 5

За последний год я отвечал за разработку нескольких внутренних веб-приложений.

Наше решение использовало проверку подлинности Windows (Active Directory или LDAP).

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

Хотя я не могу ответить на аргумент, касающийся Nhibernate или LINQ, если у вас нет конкретной функции-убийцы, которую могут реализовать эти вещи, Active Directory или LDAP достаточно просты для реализации и поддержки, которые стоит попробовать.