Нужно ли иметь отдельные учетные записи SQL для разных типов запросов?

Question

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

Мне было интересно, если бы это веб-приложение стало общедоступным, должны ли мы иметь отдельные учетные записи на сервере БД для разных типов запросов? Например. есть одна учетная запись SQL для запросов SELECT, а другая для UPDATE / DELETE? Я не могу убедить себя в этом как-то особом преимуществе, но я слышал о технике раньше, поэтому должна быть какая-то ценность.

Answer 1

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

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

В этих двух отношениях полезно иметь пользователя «только для чтения», но только если ваше приложение не выполняет запись.

Answer 2

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

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

Answer 3

Да. См. Принцип наименьших привилегий .

В области информационной безопасности, компьютер наука и другие области, принцип наименьших привилегий, также известный как принцип минимального привилегия или просто наименьшая привилегия, требует, чтобы в конкретном уровень абстракции вычислений окружение, каждый модуль (такой как процесс, пользователь или программа на основу слоя мы рассматриваем) должен иметь возможность доступа только к таким информация и ресурсы, которые необходимо его законным цель. 1 [2] Применительно к пользователям, условия наименьшего доступа пользователя или учетная запись пользователя с наименьшими привилегиями (LUA) также используются, ссылаясь на Концепция, что все пользователи во все времена должен работать с минимальным количеством привилегий можно и запускать приложения с как можно меньшим количеством привилегий.

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

«Кто такой« настоящий »пользователь»?

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

Примеры технологий в этом пространстве включают, но не ограничиваются:

1. Билет Kerberos или X.509 сертификат (SSL).
2. Аутентификация прокси-сервера - позволяет продолжать пул соединений, но прокси-сервер в качестве разных ролей для каждого сеанса.

Есть и другие преимущества использования принципа наименьших привилегий, помимо безопасности. Во многих базах данных соединение «только для чтения» может работать лучше, поскольку ему не нужно знать и / или участвовать в транзакциях.

Answer 4

были оба эти типа учетных записей, используемых приложением, я думаю, что практика, на которую вы ссылаетесь, является попыткой отразить sql инъекционные атаки . это, вероятно, не нужно, если вы убедитесь, что ваши данные дезинфицируют. помните Бобби таблицы !

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

Answer 5

В «общедоступном» приложении рекомендуется использовать служебную учетную запись для доступа к базе данных (выполнять запросы, выполнять хранимые процедуры) и вычислять контроль доступа пользователя на уровне кода.

Это предотвращает необходимость добавления новых пользователей в диспетчер безопасности базы данных.

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

• Предоставить выбор в ReportService
• Предоставить выбор, обновление, удаление в TransactionService

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

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

Answer 6

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