Мне нужно защитить пользователя oracle для вставки/обновления/удаления из внешних программ, написанных мной.Аудит на oracle schema для операторов dml
Я немного погулял, чтобы найти то, что мне нужно. Я знаю, что вы можете использовать собственные триггеры db. И теперь у меня две основные системы оракула (по крайней мере, это то, что я нашел). Вы можете использовать мелкозернистый аудит. И вы можете использовать контрольный журнал.
Я думаю, что в моем случае контрольный след приближается, но я просто не то, что ищу. Потому что мне нужно сейчас, из какой программы происходит соединение с БД. Например, мне нужно зарегистрировать все подключения, которые вставляют/обновляют/удаляют с помощью выполняемых заявлений, которые исходят от разработчика или жаба sql. Но все остальные соединения могут проходить без аудита.
На ежедневной основе у меня много соединений, поэтому регистрация всего перегружена.
Надеюсь, у одного из вас есть хорошая идея о том, как настроить это.
С уважением
Ваше название и бирки говорят об изменениях в ревизии. Но тогда ваше описание говорит о «обеспечении безопасности» и, по-видимому, подразумевает, что вы хотите предотвратить DML, если он не приходит из приложения. Является ли цель разрешить DML и проводить аудит DML, исходящий от чего-то другого, кроме приложения? Или цель предотвратить запуск DML? Насколько безопасно должно быть решение? Поскольку имя приложения должно поступать из приложения, которое выполняется на клиентской машине, компетентный пользователь может легко взломать эти данные, манипулируя их машиной. –
Это не должно быть безопасным. Пользователи могут делать некоторые вставки/обновления и удалять, но нам просто нужно их отслеживать. Раньше у некоторых кто-то делал обновление, и что-то забыл в своей статье. Если мы сможем отслеживать эти изменения, мы можем увидеть, какие записи могли быть заражены. Таким образом, это чистый аудит и отсутствие безопасности, поэтому я упомянул только тег аудита – nightfox79
OK. Является ли цель знать, что SQL-оператор был запущен? Или какие строки были обновлены? Предполагая, что строки становятся модифицированными другими процессами и что через какое-то время между действием пользователя и обнаруженной проблемой знание команды SQL может не указывать, какие строки удовлетворяли критериям оператора в момент его выполнения. В чем разница между пользователем, допустившим ошибку, и выявленной проблемой? Не могли бы вы использовать технологию flashback, а не аудит? –