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

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

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

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

Также есть имя для этого типа установки?

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

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

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

Если логин и пароль есть в клиентском приложении, его можно взломать. Если домен, вы можете использовать встроенную безопасность.

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

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

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

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

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

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

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

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

Единый аккаунт для всех - отличный источник вопросов здесь и в других местах: «Запись x была удалена, как мне узнать, кто это сделал?» - ответ вы не можете - без индивидуальных счетов и аудита .

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

Вам нужны триггеры в вашей системе, которые регистрируют действия, чтобы иметь возможность отследить до индивидуального уровня, кто выполнил действие X (если у вас нет СУБД, такой как Oracle, где это можно сделать автоматически).

В любом случае, вы должны всегда делать свою безопасность как можно более детализированной, как можно скорее - дать людям доступ к таблицам только на основе «необходимости знать». И всегда включайте временные метки для действий в таблицы - люди часто сообщают свои идентификаторы другим - если вы можете сказать: «Джимми, ты был единственным в офисе в 17:49 ...» - опять же, это не железно, просто еще одна стрела в твоем колчане.

Может быть, если бы вы дали нам свою СУРБД, вы могли бы получить совет, более конкретный / соответствующий вашей ситуации?

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

Обычно это делается из-за невежества, ради простоты или иногда из-за производительности.

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

Вы хотели бы выбрать сервер БД, который поддерживает безопасность строк, безопасность столбцов и олицетворение / аутентификацию через прокси-сервер (который поддерживает реальных пользователей БД + пул соединений)

Это также было бы более безопасно для приложений на основе плагинов, таких как Wordpress, где трудно избежать SQL-инъекций из-за неквалифицированных авторов плагинов. Каждый плагин получает логин db, а не приложение в целом.