Каморка

Есть таблицы которые надо аудитить. Для этого пишем триггеры и заносим все изменения в аудитные таблицы.
Задача - идентифицировать автора изменений. Триггеру параметр не передашь, придется пользоваться внутренними функциями БД. Поэтому на application level после успешной идентификации делаем SET ROLE rolename и в триггерах используем current_user.
На таблицу Employee пишем триггер и следим за соответствием employee и rolename.

Есть в этом подходе какие изъяны, или это вообще как-то по-другому делается?


Спасибо

StS писал(а): Есть в этом подходе какие изъяны

Конечно есть, если юзверь законнектится напрямую, то хрен узнаешь кто что сделал.
А в этом и состоит, я так понимаю, задача нормального аудита.
По хорошему, если нужен нормальный аудит, каждый юзверь должен работать со своими credentials.
А если так не получается, то остаётся надеятся на "авось пронесёт"...

Marmot писал(а): Конечно есть, если юзверь законнектится напрямую, то хрен узнаешь кто что сделал.

Ну законнектится напрямую, ну и что? Триггеры ведь.

Marmot писал(а): По хорошему, если нужен нормальный аудит, каждый юзверь должен работать со своими credentials.
А если так не получается, то остаётся надеятся на "авось пронесёт"...

В том то и фишка - перенести контроль за credentials (permissions) на БД.

StS писал(а):

Marmot писал(а): Конечно есть, если юзверь законнектится напрямую, то хрен узнаешь кто что сделал.

Ну законнектится напрямую, ну и что? Триггеры ведь.

Ну а кто мешает сделать SET ROLE какой угодно?

StS писал(а):

Marmot писал(а): По хорошему, если нужен нормальный аудит, каждый юзверь должен работать со своими credentials.
А если так не получается, то остаётся надеятся на "авось пронесёт"...

В том то и фишка - перенести контроль за credentials (permissions) на БД.

Ничего не понимаю, нафига извращаться если юзер коннектится со своими собственными credentials???
или нет?

Marmot писал(а): Ничего не понимаю, нафига извращаться если юзер коннектится со своими собственными credentials???
или нет?

Да, все понял. Был неправ. посыпаю голову пеплом.
Действительно, можно же коннекшн к БД делать с usename and password которые ввел пользователь.

Thanks.

StS писал(а):Действительно, можно же коннекшн к БД делать с usename and password которые ввел пользователь.

Thanks.

Ну к сожалению это не всегда возможно...
На мой взгляд лучше всего все updates делать через stored procedures, вызывать которые может только the application user connected from predefined IP range.
+ невожзможность остальным юзераm заходить/коннектится с application server boxes.
К томуже, во многих случаях, такой подход будет намного удобнее для девелопмента чем триггеры.

StS писал(а):Есть таблицы которые надо аудитить. Для этого пишем триггеры и заносим все изменения в аудитные таблицы.
Задача - идентифицировать автора изменений. Триггеру параметр не передашь, придется пользоваться внутренними функциями БД. Поэтому на application level после успешной идентификации делаем SET ROLE rolename и в триггерах используем current_user.
На таблицу Employee пишем триггер и следим за соответствием employee и rolename.

Есть в этом подходе какие изъяны, или это вообще как-то по-другому делается?


Спасибо

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

папа Карло писал(а):триггеры сакс... и не правильно это... мои два цента.

Вoобщем согласен, но зависит от DB , У Oracle они сосут не так сильно...
Проблема с middle-tier как защищатся от прямых коннекшинов.
На самом деле всё зависит от уровня надёжности системы.
Чем выше требования, тем сложнее оно будет...

Marmot писал(а):Ну к сожалению это не всегда возможно...

Почему? Определить что все работы с БД ведутся только через приложение(я). Для работы с приложением нужно залогиниться, т.е. ввести username/password.

Marmot писал(а): + невожзможность остальным юзераm заходить/коннектится с application server boxes.

А вот это, к сожалению действительно не всегда возможно. что если пользователь захочет поработать с приложением (БД) из дома, где у него динамический IP?
Не нравится мне ограничение коннектится с application server boxes. Допустим пропала сеть и на UPSах сидят только сервера.

Marmot писал(а):К томуже, во многих случаях, такой подход будет намного удобнее для девелопмента чем триггеры.

Чем? Какие в этом случае у триггеров отличия?

папа Карло писал(а): обычно... пользователи ходят через мидл тир и в базу ходит толльо один пользователь - бизнесс логика. если это так, то БЛ должна сама логи писать... триггеры сакс... и не правильно это... мои два цента.

Запарюсь я писать логи на 2-3 десятка таблиц плюс еще репорты по изменениям.
Все примеры (ну или большинство) аудита написаны на триггерах.

StS писал(а):

папа Карло писал(а): обычно... пользователи ходят через мидл тир и в базу ходит толльо один пользователь - бизнесс логика. если это так, то БЛ должна сама логи писать... триггеры сакс... и не правильно это... мои два цента.

Запарюсь я писать логи на 2-3 десятка таблиц плюс еще репорты по изменениям.
Все примеры (ну или большинство) аудита написаны на триггерах.

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

StS писал(а):Почему? Определить что все работы с БД ведутся только через приложение(я). Для работы с приложением нужно залогиниться, т.е. ввести username/password.

Вот у нас например 3М юзеров

StS писал(а):

Marmot писал(а): + невожзможность остальным юзераm заходить/коннектится с application server boxes.

А вот это, к сожалению действительно не всегда возможно. что если пользователь захочет поработать с приложением (БД) из дома, где у него динамический IP?
Не нравится мне ограничение коннектится с application server boxes. Допустим пропала сеть и на UPSах сидят только сервера.

Ага, так и запишем, используется идеологически устаревшая clent-server architecture...

StS писал(а):

Marmot писал(а):К томуже, во многих случаях, такой подход будет намного удобнее для девелопмента чем триггеры.

Чем? Какие в этом случае у триггеров отличия?

Ну во-первых, как уже сказали, производительность
Во-вторых, stored procedures allow to log business transactions в целом а не только отдельные записи в таблицах.
А в-третьих, из собственного опыта, отлаживать (unit test, etc) их (stored procedures) намного проще...

Marmot писал(а):Вот у нас например 3М юзеров

It's not the case. У нас от силы - сотня.

Marmot писал(а): Ага, так и запишем, используется идеологически устаревшая clent-server architecture...

Не, я имел в виду прямой коннекшн к базе с application server в случае пропажи лепестричества. Но, наверное, это уже крайности. Паранойя.

Marmot писал(а): Во-вторых, stored procedures allow to log business transactions в целом а не только отдельные записи в таблицах.

А как насчет per-statement triggers?

Ага, так и запишем, используется идеологически устаревшая clent-server architecture...

не знаю на счет устаревшая, но про 100 пользователях даст результаты лучше чем новая н-тир... да и работы меньше, и тестить меньше и так далее.

StS писал(а): А как насчет per-statement triggers?

А пофиг, например у нас бывают транзакции у которых на входе всего пара параметров, а в результате мы апдейтим 15 разных таблиц, и в некоторых у них намного больше чем одны запись.
Если бы нам был нужен аудит, то логить надо только кто, когда, и эти самые два параметра.
А на триггерах я даже не представляю как это всё делать в этом случае, что-бы не создавать кучу мусора в логах.