SQL Access для веб-приложений

Question

Фон: Наша команда создает внутреннее веб-приложение для интранет. Мы используем стандартный трехслойный подход. Уровень презентации (веб-приложение mvc), уровень доступа к бизнес-слоям и доступу к данным.

База данных Sql используется для настойчивости.

Веб-приложение/iis обрабатывает аутентификацию пользователей (проверка подлинности Windows). Ведение журнала выполняется на уровне бизнеса и доступа к данным.

учетной записи службы Вопрос против конкретных пользователей Sql счетов: Используйте сервис/приложение счет: Dev команда предлагает настроить учетную запись службы (настроить только для приложения). Эта учетная запись службы должна написать & читать доступ к db.

Vs

Pass учетных данных пользователя в SQL ИТ-опа говорит, что с помощью учетной записи службы (специально созданного для приложения только) для доступа к БД не считается лучшей практики. Настройте делегирование Kerberos с веб-сервера на сервер SQL, чтобы вы могли передать учетные данные Windows конечным пользователям & создать роль базы данных, которая предоставляет соответствующие уровни доступа к данным для конечных пользователей

Что такое наилучшая практика для настройки учетных записей в sql, где весь запрос на db будет поступать через клиентский интерфейс (то есть через уровень шины, а затем слой данных)

Answer 1

Лучшей практикой является наличие отдельных учетных записей. Это позволяет использовать базы данных для определения того, кто обращается к базе данных.

Это особенно важно, если данные изменяются. Вы можете регистрировать, кто изменяет, какие данные - как правило, являются жесткими требованиями в любой системе, где пользователи обладают этой способностью.

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

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

Answer 2

Лучшая практика заключается в том, чтобы позволить человеку/команде, ответственным за базу данных, принять решение. Похоже, команда разработчиков хочет передать (или выдавать себя) некоторые учетные данные в БД, которые я знаю, что некоторые небольшие команды любят делать, но да, это может оставить вещи слишком открытыми. Приложение может делать все, что ему нравится в базе данных, что не является чем-то вроде разделения, если вы занимаетесь такими вещами.

Лично, если я понимаю, о чем вы говорите выше, я делаю больше того, о чем думает ИТ-команда (я использую Postgres). Другими словами, мое приложение развертывается через SSH с использованием данной учетной записи (скажем, это учетная запись AppName). Это означает, что мне нужно, чтобы мои SSH-ключи выстроились в очередь для безопасного развертывания (используя PEM или known_keys или что-то еще).

В домашнем корне для AppName у меня есть a file called .pgpass, который имеет довольно определенную защиту на нем (0600). Это означает, что моя учетная запись AppName будет использовать локальную защиту для входа, а не имя пользователя/пароль.

Я делаю это, потому что в противном случае мне нужно будет хранить эту информацию в файле где-то - и эти вещи плохо обрабатываются pushed to github, for instance.

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