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

Question

Я слишком много думал об этом сейчас без явно правильного решения. Это может быть реальная ситуация «дрова за деревьями», поэтому мне нужна помощь stackoverflow.

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

Проще говоря, мое приложение: Java App -> JPA (hibernate) -> MySQL

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

1) изменить все запросы к базе данных, чтобы они читали что-то вроде select * from tablex, где region = "myregion". Это противно Это плохо работает с JPA, например, метод entitymanager.find () принимает только первичный ключ. Конечно, я могу перейти на родной язык, но мне нужно пропустить только одно утверждение, и моя безопасность снята

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

3) использовать отдельные схемы для каждого региона. да, просто, я использую Spring, чтобы я мог использовать RoutingDataSource для маршрутизации запросов через правильный источник данных (1 источник данных на схему). Конечно, проблема сейчас в том, что я хочу фильтровать по регионам и некоторым другим категориям. OHPs.

4) ACL - не совсем уверен в этом. Если a сделал выбор * из таблицы; будет ли он тихо отфильтровывать объекты, к которым у меня нет доступа, или будет выдано множество исключений доступа?

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

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

Answer 1

Я только что внедрял нечто подобное (REALbasic в разговоре с MySQL) в последние пару недель для иерархического расширения нескольких компаний для пакета учета.

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

Существует опасность разглашения скрытой информации, например, о том, что Acme Pornstars являются клиентами какого-либо подразделения компании; -)

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

Единственный шаблон, который я придумал, чтобы сделать это более обобщенным в будущем, - это не явный поиск типа region = currentRegionVar с использованием произвольного entityID, который предоставляется глобальной функцией CurrentEntityForRole ("blah").

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

Я не знаю достаточно о Java и Spring, чтобы иметь возможность сказать, но есть ли способ, которым вы могли бы использовать представления для обеспечения поиска одним ключом, где представления ограничены фильтром региона?

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

Answer 2

Хороший вопрос.

Похоже, что № 1 является лучшим, поскольку он самый гибкий.

Регион - это то, что вы фильтруете сегодня, но это может быть регион + департамент + цвет волос завтра.

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

Answer 3

Я предлагаю вам использовать ACL. Это более гибкий, чем другие варианты. Используйте Spring Security. Вы можете использовать его без использования Spring Framework. Прочитайте учебник из текст ссылки

Answer 4

У меня такая же проблема. Трудно поверить, что такая общая задача (фильтрация списка объектов модели на основе профиля пользователя) не имеет «стандартного» способа, шаблона или наилучшей практики для ее решения.

Я нашел pgacl , модуль PostgreSQL. По сути, вы делаете свой запрос, как обычно, а затем добавляете предикат acl_access () для работы в качестве фильтра.

Может быть, есть что-то подобное для MySQL.