|
Я считаю, что вопрос надо разбить на два:
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% операций с данными и помогают самим администраторам более полно определить источник изменения.
|