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

[Sancho]

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

[rmv]

Цитата:

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

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

Можно и так, только это не мой путь.
Да и на психологическом уровне гораздно лучше срабатывает единожды заданный вопрос:
"Какого икса ты менял данные в такой-то учетной табличке, такого-то числа во столько часов?"

2 Redfox - см. BOL->app_name.

[artkashin]

Цитата:

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

2 Redfox - см. BOL->app_name.

Для умного админа - это возможность спихнуть всю ответственность на кого-нибудь.
Microsoft Query:
[attachment=980:Вход_на_сервер.JPG]
Все поля - редактируемые.

P.S. Строить отношения с АДМИНами лучше на доверии. :-)

[chans_max]

Никак не ожидал столь бурной дискуссии. Если честно думал напишут "нет нельзя" и все.
Ну чтож будем обсуждать.

Из всего вышеописаного уважаемыми форумчанами точно ясно 3 факта (повторюсь):

1) Навижн сам по себе не спасет
2) Админ(ы) должен(ы) быть правильный(ми)
3) Халявы не будет готовых прог нет

Тем не менее.
1) При всей правильности и идеальности админа выбраного генетическим отбором и проверенного электроникой, не исключается фактор ошибки (нажал не ту кнопку). Т.е. необходимость контроля всетаки есть.
2) одной из причин недовольства аудиторов являлась:

Цитата:

Потенциальный риск несанкционированного или ошибочного изменения данных

NOTE: to Mazzy разговор о высоком числе людей с правами администра был (снимаю шляпу перед опытом), но это совсем другая история, а тут речь все-таки об отслеживании изменения данных.

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

Да, квалифицированого суперзлодея это не остановит (его остановит СБ и ректотермоанализ), но поростые ошибки позволит обнаружить и исправить.
Я не предполагаю создания методов борьбы со злым гением который коварно внедрился в организацию с целью разрушить все до основания, захочет - внедрится и разрушит (если получится и это не этой темы задача, хотя отследить его тоже былобы неплохо), речь идет прежде всего о случайном, ошибочном изменеии данных, и об отслеживании этих ошибок и тех кто их допустил.

По поводу админов которые должны являтся профессионалами и которых без должного уровня знаний к работе подпускать нельзя:
К сожалению админы не выращиваются в коконах с питательной средой, им не вносится чип со знаниями в мозг, и по штрих-коду на затылке нельзя определить их квалификацию. Человека надо научить, в процессе обучения возникают ошибки и хорошо если человек, будучи не увереным в чем-то, спросит 2-5-10 раз об одном и том же (будет раздражать но это лучше чем потом базу востанавливать) хуже если он будучи неуверенным (или уверенным) сделает что-то не так, а потом будет молчать.

[artkashin]

я делал журналирование изменений в Наве на основе http://www.sql.ru/articles/mssql/2005/0307...esLogging.shtml.
Подобные доработки сразу исключают возможность бекапа стандартными средствами NAV.

[RedFox]

Цитата:

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

2 Redfox - см. BOL->app_name.

Извините, не понял зачем мне это? Если уж хотите поделитьсячем-то точнее, то пишите более расширенно, чем каткое сообщение об эмуляции

[mazzy]

Цитата:

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

1) Навижн сам по себе не спасет

Да.

Цитата:

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

2) Админ(ы) должен(ы) быть правильный(ми)

Нет.
Любой может ошибаться. Злоумышленник может появится везде.
Именно с этими предположениями нужно выстаивать схему работы, зоны ответственности и т.п.

НО: идеальное решение требует бесконечных ресурсов.
поскольку ресурсы обычно конечные, то приходится идти на компромисс и принимать некоторые допущения.

А вот теперь внимание: допущения должны быть ОСОЗНАННЫМИ.
Т.е. вы должны продумать что важно, а что неважно, что санкционировано, а что нет в вашем случае.
Прикрыть уязвимости, оставить только меньше наперед заданной степени уязвимости.

Цитата:

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

3) Халявы не будет готовых прог нет

Как всегда: Серебрянной пули нет.

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

[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]

Я считаю, что вопрос надо разбить на два:
1) Непосредственно, журналирование изменений системы.
2) Определение санкционированности тех или иных действий.

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

Можно выделить несколько уровней доступа к данным сверху вниз (применительно к Nav):
а) через формы клиента Navision (пользовательский уровень)
б) в таблицах напрямую через Object Designer и через программный код
в) непосредственно SQL - запросами на SQL Server
г) BULK INSERT - операции (FIRE_TRIGGERS OFF)
д) через HEX-редактор файлов баз данных.
е) прямой доступ к ячейкам данных винчестера.

Пункт а) журналируется стандартными средствами Nav (Change Log Management, функциональность регистров)
Пункты б) , в) журналируется через триггеры уровня SQL-сервера. При этом необходимо программировать триггеры.
Пункт г) можно отследить только через журнал транзакций SQL с предварительно установленным ПО стороннего производителя для анализа Журнала Транзакций.
Пункт д) может журналироваться только с помощью журналов уровня операционной системы (по-умолчанию, в Windows таких журналов нет).
Пункт е) - на большинстве винчестеров не журналируется впринципе, так как в винчестерах такой функции нет.

На каждом последующем уровне усложняется или становится вообще не возможным узнать, кто совершил изменения, теряются детали. Так на уровне а) можно узнать код аудита, с помощью которого можно определить вид задания, совершившего изменения, чего на уровне в) уже определить не возможно. А на уровне д) не возможно определить код пользователя SQL, совершившего изменения.

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

При внедрении стандартного Nav без доработок вполне достаточно пункта а), т.к. стандартный код достаточно отлажен, а доступ к таблицам имеют только администраторы (а от них, как уже доказано - защиты нет). При этом, если произошло изменение данных, а в Change Log этой информации нет, то можно с уверенностью говорить о ручном изменении через таблицы или программный код. Но определить источник изменения - не получится.

Но на большинстве проектов код пишется, и код, к сожалению, часто с ошибками. При долгосрочной эксплуатации системы накапливаются пользовательские и программные ошибки, и в какой-то момент времени стандартных средств журналирования просто перестает хватать. Возникает ситуация, когда администратор системы , как заинтересованное лицо (не вредитель), говорит : "Я не знаю кто изменил, почему и как произошло данное изменение и могу только предполагать".
И по-моему мнению, журналировать необходимо уровни а), б) и в), так как данные уровни покрывают 99,9% операций с данными и помогают самим администраторам более полно определить источник изменения.

[artkashin]

Цитата:

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

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

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

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

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

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

[artkashin]

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

[artkashin]

Цитата:

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

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

Да, квалифицированого суперзлодея это не остановит (его остановит СБ и ректотермоанализ), но простые ошибки позволит обнаружить и исправить.

Для обнаружения ошибок не надо отдельной машины, к которой админы доступа не имеют. А квалифицированного злодея, это не остановит. Например, имея права sysadmin на сервере я могу сохранить хеш пароля другого админа, заменить на другой пароль, залогиниться под другим админом, выполнить злодеяния, вернуть старый пароль админа на место. При этом все эти операции выполнить без срабатывания триггеров логирования. Или поставить firewall который закроет доступ к удаленному серверу логов на время "операций". Ищи - свищи. От Админа защиты нет.

[rmv]

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

[chans_max]

Спасибо всем большое за обсуждение.
выводы сделаны.
Тов. Kashin отдельное спасибо за подробное разложение рисков и мест возможного вскрытия и изменения БД
логи требуются только в пунктах Б)В) остальное в данный момент не интересует.

итог подведенный rmv считаю полным, тему можно закрывать. Поставленная задача решена логированием SQL запросов в самописной утилите.