Аутентификация пользователя с использованием MySQL и GRANT или специализированное программное решение - PullRequest
1 голос
/ 23 сентября 2011

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

Описание

У меня будет несколько (от 10 до 20) клиентов, хранящих конфиденциальные данные на моем удаленном сервере. Клиент - это организация, в которой есть пользователи. Доступ осуществляется через часть программного обеспечения Java, работающего на сервере, обращающемся к серверу MySQL. Отдельная клиентская Java-программа обращается к серверу и осуществляет обмен.

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

Самая большая проблема заключается в том, что пользователи-администраторы клиента должны иметь возможность добавлять (или удалять) дополнительных пользователей, которые имеют доступ только к базе данных клиента. Пользователи должны быть уникальными для БД, но не для экземпляра MySQL. Например, у каждого клиента должен быть пользователь с именем «bob».

Вопрос

Итак, у меня есть два способа приблизиться к этому. В настоящее время я предпочитаю, чтобы каждый пользователь был настоящим пользователем MySQL, который может иметь привилегии GRANTed. Это гарантирует, что они могут выполнять только то, что указывает их роль, прямо на уровне MySQL. Проблема заключается в конфликте имен, поскольку имена пользователей MySQL являются глобальными для всех БД. Я решил это, имея «корневую» таблицу, которая отображает идентификатор пользователя (уникальный для каждого клиента, а не каждого пользователя) пользователя в БД, затем таблица в этой базе данных отображает имя пользователя в идентификатор пользователя, который затем является действительным пользователем MySQL. , Программное обеспечение java-сервера будет подключаться к БД с использованием сопоставленного идентификатора пользователя и пароля пользователя и заниматься бизнесом. Для этого нужно приложить немало усилий и прыгнуть с обручем, но мне это нравится с точки зрения безопасности.

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

Обратная связь

Так есть ли у ветеранов БД какие-нибудь отзывы по этому поводу? Кто-нибудь решил проблему лучше? Попытка получить некоторые идеи, прежде чем мы совершим что-то.

Спасибо, Мэтт

1 Ответ

1 голос
/ 23 сентября 2011

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

Использование LDAP для хранения пользователей, связей схем,привилегии, роли, полномочия и т. д. и т. д.

Это всегда в зависимости от программного обеспечения - с помощью правил авторизации - чтобы убедиться, что изменены только нужные БД, только нужныевызываются функции и т. д.

Базовые пользователи должны будут иметь соответствующие разрешения для определенных типов пользователей,

, чтобы программный сбой или компромисс в программном обеспечении Java мог привести к плохим последствиямБД.

Это всегда так.Поэтому используйте тестирование, чтобы предотвратить этот таинственный «сбой».

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

Используйте авторизацию на уровне приложений.Используйте LDAP.

Не приписывайте магические силы схемам авторизации СУРБД.Они не "лучше" или "более надежны".

Проверки авторизации приложений - в большинстве языков и сред - это декораторы одной строки кода (или операторы if), которые явно определяют, какая группа пользователей имеет доступ к функциональности.Это не сложно.Это не подвержено "глюкам".

...