Доброго времени суток форумчане ! Задачу поставили сделать аудит изменений конкретных таблиц,так чтоб ни один из девелоперов не смог бы обойти его т.к менеджер боится что кто-то может изменить какието данные рукой в таблице. Сделал тригера (AFTER DELETE,BEFORE UPDATE,AFTER UPDATE) выглядят примерно так :




Создал базу audit где только дал права на select юзеру менеджера.Проблема в том что у некоторых девелоперов есть права SUPER и они могут дропнут тригер -> изменить значение в таблице -> создать тригер заново. Можно както записать в аудит базу все drop и create команды ? (например в других СУБД можно сделать DDL тригером). На крайняк можно отобрать права SUPER но хочеться сделать так чтоб они не знали что за ними следят.

AkinaNewBie77Проблема в том что у некоторых девелоперов есть права SUPER и они могут дропнут тригер -> изменить значение в таблице -> создать тригер заново.Отобрать. Делов-то...

Ну отобрать это последнее дело

UP ! Тема актуальна.

Как записать в таблицу все DROP и CREATE команды ?

miksoftNewBie77,

Selecting General Query and Slow Query Log Output Destinations

Но он не сильно будет грузить базу ?


Кто нибудь использовал McAfee audit plugin ? Поделитесь опытом

miksoftNewBie77пропущено...


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

Спасибо за совет. Думаю проще будет отнять права SUPER

miksoftNewBie77Думаю проще будет отнять права SUPERА что сложного в команде SET GLOBAL general_log = 'ON' ?

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

miksoftNewBie77пропущено...


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

Спасибо еще раз .

miksoftNewBie77пропущено...


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

Искал в гугле но не нашел, можно отфильтровать что записать в general log а что нет ? Например мне нужно только записывать DROP и CREATE

miksoftNewBie77можно отфильтровать что записать в general log а что нет ? Например мне нужно только записывать DROP и CREATEНет, насколько я в курсе.

Еще один вопрос который логически не смог связать.

Есть юзер и пароль для приложения которая подключается к базе. Изменения этим приложением в базе мне не интересны, интересно только если девелопер подключится этим юзером и паролем и изменит данные. Можно как-то различить изменения девелопером и приложением ? IP у обоих одинаковое при
по идее выдаст user@ip одинаковое для обоих случаев.

MasterZivNewBie77пропущено...


Но он не сильно будет грузить базу ?


Поделитесь опытом


грузить будет, но не очень сильно.
у тебя собственно выбора то нет. будет грузить, не будет грузить.... -- раз тебе это надо, надо включать.

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

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

Вот одна проблема у меня которую логически связать не смог.

Есть юзер и пароль для приложения которая подключается к базе. Изменения этим приложением в базе мне не интересны, интересно только если девелопер подключится этим юзером и паролем и изменит данные. Можно как-то различить изменения девелопером и приложением ? IP у обоих одинаковое при


по идее выдаст user@ip одинаковое для обоих случаев.

Думаю не возможно различить

miksoftNewBie77IP у обоих одинаковоеПочему? У вас девелоперы и юзеры работают с одного компа? Или все сидят за общим NAT-ом?
Если со своего компа запустят то будут разные IP , а если с сервера запустят где сама апликация каким - нибудь PHP скриптом то IP будт сервера, или я ошибаюсь ?

miksoftNewBie77если с сервера запустят где сама апликация каким - нибудь PHP скриптомВы используете термин "приложение", которое как-то не очень применимо к PHP-скриптам в моем представлении. У меня оно ассоциируется с десктопными приложениями.
Там веб приложение. Пользователь может зайти на сайт ,зарегистрироваться и заплатить то что ему нужно(комунальные,пополнить счет и т.д) типа веб терминала.

miksoftNewBie77,

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

Создал хранимую процедуру(где делается инсерт и селект) и юзера с правами только на EXECUTE. Вызываю этим юзером хранимку и все отлично работает. Я новый в mysql больше работал с sql server-ом и там только EXECUTE прав не хватает нужны еще права на селект и инсерт ,а в mysql это не так ?