Лог действий администратора в Navision

[rmv]

Mazzy - спорить не буду, пусть каждый останется при своем мнении.

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

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

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

[RedFox]

Цитата:

Сообщение от rmv

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

Вы сами написали возможный ответ на свой вопрос, именно "логировать несанкционнированные действия". Отсюда следует определить:
- - каким образом определять что действия несанкционированные?
- как нужно их блогировать или блокировать (триггеры, откаты, корректировка ЛОГа транзакций (если используется Recovery Model, отличный от Simple)?
- когда именно это нужно делать?

[rmv]

Цитата:

Сообщение от RedFox

Вы сами написали возможный ответ на свой вопрос, именно "логировать несанкционнированные действия". Отсюда следует определить:
- - каким образом определять что действия несанкционированные?
- как нужно их блогировать или блокировать (триггеры, откаты, корректировка ЛОГа транзакций (если используется Recovery Model, отличный от Simple)?
- когда именно это нужно делать?

RedFox для ответа на п. 1 специально для вас повторяю в моем контексте - минуя Навижн.
По п.2. Видимо блогирование - действительно свежая мысль, автоматом выложить в открытый доступ и устроить публичную порку, спасибо задумался . Корректировка лога транзакий - тоже интересная идея, видимо нужно писать парсер .
По п. 3 - Думаю нужно делать в момент совершения действия, так сказать в рамках одной транзакции. Если есть другие работающие идеи - с удовольствием выслушаю.

[RedFox]

Цитата:

Сообщение от rmv

RedFox для ответа на п. 1 специально для вас повторяю в моем контексте - минуя Навижн

Хорошо, тогда я тоже Вам уточняю, каким образом в SQL система должна определять, что ЭТО действия несанкционированные (извините, но в моём вопросе это подразумевалось!!!)?

[mazzy]

Цитата:

Сообщение от rmv

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

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

Я абсолютно не хотел создавать такой миф.
Наши программисты и наши пользователи ошибаются (свои ошибки мы исправляем бесплатно).

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

Надежно - это резервирование и контроль. Контроль и резервирование.

Надежная разработка - это значит что:
1. программисты ваяют в девелоперской базе,
2. модификации тестируются и верифицируются (соответственно есть соответствующие процедуры)
3. есть специальный ответственный чел, который занимается процедурой переноса кода в рабочую (соответственно есть процедура переноса)
4. и т.п.

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

Надежная работа пользователей означает:
1. есть бизнес-проверки входящих данных
2. для важных участков включены процедуры одобрения
и т.п.

Но надо понимать, что "надежность" требует больших ресурсов, нежели "быстро и дешево".
Повторюсь, что "идеальное решение требует бесконечных ресурсов".
Повторюсь, что выбор должен быть осознанным.

И еще раз повторюсь: "лог действий администратора" не повысит надежность системы.

См. также
http://axapta.mazzy.ru/lib/org_prog_team/
http://axapta.mazzy.ru/lib/unsuccess/
http://axapta.mazzy.ru/lib/pamyatka/

[artkashin]

Цитата:

Сообщение от mazzy

Надежно - это резервирование и контроль. Контроль и резервирование.

Надежная разработка - это значит что:
1. программисты ваяют в девелоперской базе,
2. модификации тестируются и верифицируются (соответственно есть соответствующие процедуры)
3. есть специальный ответственный чел, который занимается процедурой переноса кода в рабочую (соответственно есть процедура переноса)
4. и т.п.

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

Надежная работа пользователей означает:
1. есть бизнес-проверки входящих данных
2. для важных участков включены процедуры одобрения
и т.п.

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

[rmv]

Kashin + 1.
Если позволите подведу краткий итог нашей дискуссии:
1. Серебренной пули нет. Ни в разработке, ни в тестировании, ни в защите от администратора .
2. Желание все логировать (в том числе действия админа) может быть потребностью можно быстрее локализовать потенциальную ошибку, а не жаждой найти злоумышленника.
3. Варианты логирования описаны достаточно подробно и в этой ветке и на www.sql.ru.
Можно закопаться глубоко в философию и поговорить о теории управляемого хаоса, однако предлагаю закончить священные войны.
Думаю топикстартер сделал для себя необходимые выводы.