Oracle Security - как запретить пользователю DROP TABLE свои собственные таблицы - PullRequest
Новая
       11

Oracle Security - как запретить пользователю DROP TABLE свои собственные таблицы

3 голосов
/ 12 января 2012

В качестве упражнения по повышению безопасности я удаляю все системные привилегии у пользователя базы данных oracle.Теперь этот пользователь имеет ТОЛЬКО следующие системные привилегии:

  • CREATE SESSION
  • UNLIMITED TABLESPACE

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

Oracle документация говорит, что предварительным условием для DROP TABLE является "Таблица должна быть вашей собственнойили у вас должна быть системная привилегия DROP ANY TABLE ".Только то!!!Я не понимаю логику безопасности Oracle, но есть ли способ, с помощью которого пользователи могут удалять свои собственные таблицы?

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

1 Ответ

11 голосов
/ 12 января 2012

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

Поскольку вы смотрите на ужесточение мер безопасности, создание нового пользователя и предоставление ему любых привилегий для манипулирования данными является правильным ответом. Единственные люди, которые должны войти в производственную базу данных как пользователь, владеющий объектами приложения, - это администраторы баз данных, и только тогда, когда они находятся в процессе развертывания изменений в схеме. Все остальные должны войти в базу данных как пользователи, отличные от владельца схемы.

При этом, если правильное решение - это больше работы, чем вы готовы предпринять прямо сейчас, потенциальным временным ограничением будет создание в базе данных триггера DDL, который выдает исключение, если DROP выдается против объект в указанной схеме. Это менее безопасно, чем правильное решение. Вы можете что-то пропустить при реализации триггера, вы или кто-то другой можете сбросить или отключить триггер и забыть повторно включить его и т. Д. И это значительно усложняет создание отчетов по безопасности, поскольку у вас есть нестандартное решение, которое не собирается быть очевидным в различных представлениях словаря данных, связанных с безопасностью, которые могут создавать проблемы для аудиторов.

...