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

Question

Моя компания создает приложение ASP.NET HR, и мы решили создать одну базу данных для каждого клиента. Это гарантирует, что клиенты не могут случайно просмотреть данные другого клиента, а также обеспечивает легкую масштабируемость (среди других преимуществ, которые уже обсуждались здесь ).

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

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

Я что-то упустил? Должны ли мы добавить дополнительный уровень безопасности / аутентификации на уровне клиентской базы данных?

Обновление:
Одна из причин, по которой моя команда считала необходимым управление двумя пользователями, связана с контролем доступа. Все пользователи имеют роль по умолчанию (например, «Администратор», «Минимальный доступ», «Опытный пользователь» и т. Д.), Но администраторы клиента смогут уточнить разрешения для пользователей, имеющих доступ к своей базе данных. Мне все еще кажется возможным, чтобы это было в центральной базе данных, но моя команда не соглашается. Мысли?

Answer 1

У нас есть решение SaaS, которое использует одну БД для каждой модели клиента. У нас тоже есть общая база данных «Безопасность». Однако мы храним всю пользовательскую информацию в отдельных клиентских базах данных.

Когда пользователь входит в систему, он сообщает нам три части информации: имя пользователя, пароль и идентификатор клиента. Идентификатор клиента используется для поиска их домашней базы данных в базе данных «security», а затем код подключается к их домашней базе данных для проверки их имени пользователя / пароля. Таким образом, клиент полностью автономен в своей базе данных. Конечно, вам нужна некоторая информация помимо имени пользователя, чтобы определить их домашнюю базу данных. Это может быть наш подход с использованием идентификатора клиента или запрос имени домена, если вы используете субдомен для каждого клиента.

Преимущество здесь в том, что вы можете перемещать «клиентские» базы данных без необходимости синхронизировать их с базой данных безопасности. Кроме того, вам не нужно иметь дело с соединениями w / cross-db, когда вы пытаетесь найти информацию о пользователе.

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

Answer 2

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

Answer 3

Возможно, вы захотите использовать поставщика членства ASP.NET для обработки аутентификации. Это будет работать с вашим заявленным подходом, и вы все равно можете хранить все данные аутентификации в отдельной базе данных. Тем не менее, я согласен с Крисом в том, что хранение одной БД будет более легким в обслуживании.