"безопасность" данных с помощью java и hibernate

Question

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

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

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

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

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

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

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

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

Очень признателен...

Answer 1

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

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

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

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

Я надеюсь, что это поможет

Answer 2

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