безопасность данных с помощью Java и Hibernate

Question

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

Однако существует также требование к данным security. То есть какая информация видна конечному пользователю.

Это фактически означает уменьшение видимости строк (и, возможно, даже столбцов) в базе данных.

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

Для защиты на основе строк это означает, что мы можем добавить аннотацию, такую ​​как @Secured на уровне объекта, что приведет к добавлению дополнительного столбца в базовую таблицу, чтобы ограничить наши выборки?

Для безопасности на основе столбцов у нас может быть @Secured, чтобы либо помочь в создании запроса, либо, возможно, использовать аспект для фильтрации возвращаемой информации?

Мне любопытно узнать, как это может повлиять и на механизмы кэширования hibernate?

Я уверен, что у многих других была такая же проблема, и мне было интересно, как вы подошли к этому?

Очень ценится ...

Answer 1

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

Ваша база данных также может иметь поддержку этой функции. Например, у Oracle есть виртуальная частная база данных 1006 * (VPD), которая переписывает ваши запросы на уровне базы данных. Это решение имеет дополнительное преимущество, заключающееся в том, что любая внешняя программа (например, инструменты отчетности), которая идет вразрез с вашей базой данных, будет применять ваши ограничения безопасности. VPD также поддерживает маскирование ограниченных столбцов с NULL.

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

Обычно мы создаем объекты запроса / поиска / DAO, где передаем значения, необходимые для обеспечения безопасности, а затем создаем запрос соответствующим образом.

Надеюсь, это поможет

Answer 2

При использовании фильтров Hibernate вы должны знать, что дополнительные ограничения не будут применяться к операторам SQL, генерируемым методами load() или get().