Каковы преимущества каждого подхода для сопоставления конечных пользователей приложения с пользователями базы данных?

Question

Существует три распространенных подхода для сопоставления конечного пользователя приложения и пользователя базы данных.

1. Сопоставление один к одному: Каждый пользователь приложения (Боб, Нэнси и Фред) также получает соответствующую учетную запись пользователя базы данных (Боб Нэнси и Фред).
2. Отображение N-M: Каждый пользователь приложения сопоставляется с пользователем базы данных, который представляет их роль. Боб и Нэнси отображаются на пользователя базы данных clerk, а fred на пользователя базы данных manager.
3. Отображение N-1: Каждый пользователь приложения сопоставляется с одним пользователем базы данных (app_user), а идентификация осуществляется только на уровне приложения.

Кажется, что # 3 является наиболее распространенным в разработке веб-приложений. Почему не уделяется больше внимания двум другим вариантам?

Oracle поощряет методы, подобные # 2, используя свои функции аутентификации по доверенности по следующей причине:

Модель ограниченного доверия -контроль пользователей, от имени которых могут соединяться промежуточные уровни, и роли, которые средние уровни могут выполнять для пользователя

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

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

Документация Oracle по аутентификации прокси

Answer 1

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

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

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

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

Answer 2

Некоторые причины, по которым N к 1 отображению так широко используется, могут быть из-за

1. В обычной базе данных разработки программного обеспечения рассматривается как простой репозиторий, а не за его пределами.

2. Программисты рассматривают базу данных как черный ящик, а права доступа рассматриваются как одноразовое действие.

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

4. В типичном приложении, где для пользователя-администратора предусмотрен экран «Обслуживание пользователя / роли», легко иметь таблицы типа USER, SECURITY_ROLE, USER_SECURITY_ROLE и т. Д., Чтобы поддерживать информацию о пользователе приложения, а не создавать пользователя , записи безопасности в самой базе данных.

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

Answer 3

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

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

Очевидно, что для веб-приложения, где пользователи могут зарегистрироваться самостоятельно, 1) нецелесообразно. У меня есть сайт с 500 000 или более пользователей. Хотел бы я иметь столько учетных записей в БД? Я так не думаю!

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

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

Answer 4

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

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

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

В обычном интернет-настройке 3 - единственный реалистичный выбор.

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

Answer 5

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

Answer 6

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

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

Answer 7

Также см. Хорошо ли интегрированная безопасность SQL Server / Windows? .

Answer 8

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

Answer 9

Поскольку роли базы данных (по объектам, CRUD и т. Д.) Обычно не применяются к именам пользователей, если они не являются разработчиками базы данных. И AD, и база данных имеют роли, но между ними существует одно и то же несоответствие. Единственные наполовину оправданные сопоставления были бы для ролей администратора, но даже это небрежно.

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