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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

В этом случае доступ к приложению будет контролироваться через доменную учетную запись пользователя (отключить анонимный доступ в IIS и т. д.).

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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