20.02.2009, 16:40 | #1 |
Участник
|
Имеется система Navision работающая на MS SQL Server 2008
Возможно ли ввести отслеживание действий администрора, т.е. каким-либо образом вести лог (или создать таблицу) действий совершенных администратором(и) (в частости внесение изменений). Если да то как, и как сделать это малой кровью (ну или ткните где почитать). Заранее благодарен. |
|
20.02.2009, 16:46 | #2 |
Administrator
|
если администратор изменяет что-то в Наве, то есть стандартный "Протокол Изменений".
если администратор меняет что-то в SQL Server (или данные непосредственно через SQL), то даже и не знаю... |
|
24.02.2009, 12:56 | #3 |
Участник
|
Мда это все-таки наверно на sql.ru надо обращатся. Неужели под навижн нет отдельной утилиты котороя бы вела логи действий админа в базе SQL?
|
|
24.02.2009, 14:03 | #4 |
Участник
|
|
|
24.02.2009, 14:32 | #5 |
Участник
|
Цитата:
Вам же ответили "Протокол Изменений" (Change Log) Вы ответ не поняли или вас не устраивает, что это встроенная функция? Вы хотите именно отдельную утилиту? Зачем? И почему только для админа? Мне кажется, что ты отвечаешь на вопрос, который еще не был задан |
|
24.02.2009, 14:49 | #6 |
Участник
|
та же тема этого же автора на форуме sql.ru
http://sql.ru/forum/actualthread.aspx?tid=641196 про change log уже сказано Лог действий администратора в Navision |
|
24.02.2009, 15:32 | #7 |
Участник
|
Цитата:
Здраствуйте Mazzy, дело в том, что "Протокол Изменений" (Change Log), если я правильно все понимаю, не ведет лог изменений сделаных напрямую в базе (я ведь прав???) сторонняя утилита виделась мне наиболее безболезненным вариантом выполнения задачи. Существование отдельной утилиты показалось мне вероятным ввиду явной не уникальности задачи. Зачем это надо? все очень просто, пришел аудитор и задал вопрос: у вас 3 человека с правами администратора как вы проследите что никто из них не внес изменений и не спровоцировал диверсию. Оно понятно что грамотного админа уличить в диверсии можно только при последновательном термо-ректальном анализе..., кроме как доверение тут ничегоне поделаеш но тем не менее. Если есть задача - значит должно быть и решение, Если есть решение - то значит кто-то его уже сделать и сделал лучше тебя (в 90%)... поэтому вопрос и встал. Если ответа нет значит делать все буду своими ручками, для чего и открыл тему на sql.ru Всем большое спасибо. |
|
24.02.2009, 15:55 | #8 |
Участник
|
Цитата:
Сообщение от chans_max
Зачем это надо? все очень просто, пришел аудитор и задал вопрос: у вас 3 человека с правами администратора как вы проследите что никто из них не внес изменений и не спровоцировал диверсию. Оно понятно что грамотного админа уличить в диверсии можно только при последновательном термо-ректальном анализе..., кроме как доверение тут ничегоне поделаеш но тем не менее. Если есть задача - значит должно быть и решение, Если есть решение - то значит кто-то его уже сделать и сделал лучше тебя (в 90%)... поэтому вопрос и встал.
У вас в компании все имеют доступ к бумаге для принтера. Как вы отследите кто ее спер себе домой или, еще коварнее, исчиркал ручкой и оставил в принтере? Ну сделайте так, что у вас 3 админа и только 1 из них имеет право (на бумаге) вносить изменения в базу. А остальные два только через него. |
|
24.02.2009, 16:08 | #9 |
Участник
|
|
|
24.02.2009, 16:37 | #10 |
Участник
|
Цитата:
Цитата:
Но и они не дадут 100% гарантии, поскольку изменения можно записать на диск напрямую в указанный сектор Цитата:
Сообщение от chans_max
Зачем это надо? все очень просто, пришел аудитор и задал вопрос: у вас 3 человека с правами администратора как вы проследите что никто из них не внес изменений и не спровоцировал диверсию. Оно понятно что грамотного админа уличить в диверсии можно только при последновательном термо-ректальном анализе..., кроме как доверение тут ничегоне поделаеш но тем не менее. Если есть задача - значит должно быть и решение, Если есть решение - то значит кто-то его уже сделать и сделал лучше тебя (в 90%)... поэтому вопрос и встал.
Действительно ли только 3 человека имеют подобные полномочия? Пересекаются ли полномочия этих людей во времени? Думали ли вы о том, что некоторым людям даны излишние полномочия? Кто будет виноват, если? Т.е. аудитор спрашивал у вас скорее об административных мерах, а не об утилитке. Что вы должны были ответить: = права администратора только у 3 человек (другие не имеют подобных прав) = права database creator у стольки то человек (другие не имеют подобных прав) = права на непосредственную правку средствами SQL у стольки то человек (другие не имеют подобных прав) = права на непосредственную правку при помощи Excel(!), Access(!) или других ODBC инструментов есть у стольки то человек (другие не имеют подобных прав) = других возможностей несанкционированной правки данных нет(!) по правам администраторов вы должны были ответить: = администраторы работают круглосуточно, сменами по 8 часов. = поэтому за несанкционированные изменения, выполненные любым образом с 8:00 по 16:00 отвечает Администратор1, с 16:00 по 24:00 отвечает Администратор2, а с 24:00 по 8:00 отвечает Администратор3 = меньшее количество администраторов невозможно для обеспечения заданного уровня надежности (хорошо бы ссылку на приказ) Также вы должны были рассказать про мониторинг: = в пересменку делается снапшот/бэкап = такие-то настроечные таблицы сравниваются скриптом, при обнаружении расхождений алерт рассылается... Что интересует аудитора: не гребанная(!) утилитка, а будут ли администраторы переводить стрелки друг на друга или для каждого администратора будет четко определена зона ответственности. В т.ч. уголовной. Аудитора также интересует: есть ли у вас вообще процедура обнаружения несанкционированных изменений (для этого в вашей компании должно быть понимание какие изменения являются санкиоцнированными, а какие не являются) Вот о чем спрашивает аудитор. А не о "сторонней утилите". Цитата:
Вы что именно будете делать? Вы напишете определение несанкционированных измений? Вы напишите утилитку, которая будет записывать ВСЕ изменения? Не мучайтесь - она уже есть. Называется Transaction log. Вот только он большой очень. И никто туда не смотрит. Вы лучше закройте возможность пользователям непосредственно править данные через Excel/Access Еще раз: аудитор спрашивает не утилиту. аудитор спрашивает - есть ли у вас понимание и предусмотрели ли вы процедуры обнаружения несанкционированных изменений. Ваш ответ четко показывает: понимания у вас нет. процедур тоже. |
|
24.02.2009, 16:51 | #11 |
Участник
|
Обычные аудиторы. У них опросники есть.
Похоже компания автора вопроса проходит какую-нибудь сертификацию типа ISO9000 или что-нибудь в этом духе. Не. Нормальные инструменты. Предпосылка1: = администратор - царь, и бог, и воинский начальник в своем домене/зоне = если человек не должен выполнять некоторых действий, значит он не должен иметь права администратора для этих действий. Следствие1: = действия администратора всегда санкционированы = отслеживать действия администратора бесполезно = отслеживать можно и нужно только действия обычного юзверя Предпосылка2: = код ERP-системы имеет права администратора над данными ERP-системы (это плохо, но в Навижине так) = см. Предпосылка1 и Следствие1: действия кода отслеживать бесполезно Следствие2: = любой программист, который может изменить код, автоматически получает права администратора над данными, с которыми работает этот код. Что делает Навижин: Отслеживает юзверей. Но даже не пытается отслеживать администраторов и код ПРОГРАММНЫМИ средствами. Потому что администраторов и код надо отслеживать внепрограммными. |
|
24.02.2009, 17:14 | #12 |
Участник
|
Mazzy - красиво написано, тем не менее не думаю что проблема высосана из пальца.
К примеру, при тиражировании системы порой приходится сталкиваться как с открытым саботажем со стороны сотрудников, так и попытками администратора руками поправить кривые на его взляд (или взгляд главбуха) данные. Естественно изменение данных в учетных таблицах напрямое запрещено лицензией, отсюда прямой путь к SQL. Обвинять админа сложно , внедренцы сами порой чистия руками со своей лицензией, а бывают оставляют продвинутым админам инструкции на этот счет. Ну а в результате имеем обвинения в невозможности работы в системе с одной стороны и крики "Нечего лазить руками в базу" с другой. Доказательная база - это как раз лог, который так упорно пытается реализовать chans_max. Общие рекомендации на sql.ru уже приведены, от себя хочу добавить: 1. Дырки в номерах операции - признак того, что операции удаляли. 2. Подозрение на ручную правку в записи учетной таблице можно проверить сравнив таймстампы подозрительной и соседних записей - cast(timestamp as bigint). Для того чтобы получить точное время модификации записи можно также сравнить с ближайшим по значению тайстамптом в change log entry. |
|
24.02.2009, 17:24 | #13 |
Участник
|
Цитата:
Даже если в самом объекте прописать разрешения (свойство Permissions), то пока пользователю не будет дано разрешение (полное или косвенное), он с данными сделать ничего не сможет. |
|
24.02.2009, 17:44 | #14 |
Участник
|
Да уж без 7300 гранулы никак таблицу фин. операций из NAV не покоцать. Только напрямую через SQL если идти....
http://blogs.technet.com/alexef/archive/20...ectedTable.aspx http://blogs.technet.com/alexef/archive/20...7200vs7300.aspx |
|
24.02.2009, 17:45 | #15 |
Участник
|
Цитата:
Сообщение от rmv
К примеру, при тиражировании системы порой приходится сталкиваться как с открытым саботажем со стороны сотрудников, так и попытками администратора руками поправить кривые на его взляд (или взгляд главбуха) данные. Естественно изменение данных в учетных таблицах напрямое запрещено лицензией, отсюда прямой путь к SQL. Обвинять админа сложно , внедренцы сами порой чистия руками со своей лицензией, а бывают оставляют продвинутым админам инструкции на этот счет.
Смотрите: аудитор задал вопрос не про "проследите", а про 3 человека. Действительно ли только 3 человека имеют подобные полномочия? Пересекаются ли полномочия этих людей во времени? Думали ли вы о том, что некоторым людям даны излишние полномочия? Кто будет виноват, если? Цитата:
Цитата:
Это ж пестня! А кто даст гарантию, что его реализация не позволяет модифицировать лог Админ - царь, бог и воинский начальник. В своем домене. Если человек может программить, то он может вставить кусок, который выполняется во время действий администратора. Администратор зашел пользователя добавить, а при открытии формы с пользователями выполняется злой код Поэтому лучше исходить из того, что любой программист и любой код в Навижине может получить привелегии Администратора. |
|
24.02.2009, 17:50 | #16 |
Участник
|
Значит, если хочется свалить вину на другого, нужно сделать такой код, который будет выполняться при заходе разработчика с такой гранулой. И позвать партнера.
Еще раз: аудитора скорее всего не волнует, можно или нельзя сделать в принципе! аудитора волнует, есть ли определение несанкционированного доступа в компании, есть ли процедура надежного обнаружения несанкционированного доступа, продуманы ли мероприятия, которые снижают риски несанкционированного доступа. "попытка реализовать лог неким chans_max" НЕ снижает риск несанкционированного доступа. Наоборот, даже повышает. |
|
24.02.2009, 18:05 | #17 |
Участник
|
Mazzy - спорить не буду, пусть каждый останется при своем мнении.
Очень рад, что Ваш код и проекты не содержат программных ошибок. Вдвойне рад за пользователей, работающих в идеальной базе и не допускающих ошибок. Рад втройне за клиентскую службу поддержки, все задачи которые видимо сводятся к своевременному созданию бэкапов. Мне как разработчику продукта, потенциально содержащего ошибки, гораздо проще работать зная источник ошибки. Ради таких целей и создаются механизмы, позволяющие хотя на 90 процентов логировать несанкционнированные действия с данными (в моем контексте - минуя Навижн), либо хотя бы понимать что такие действия произошли. PS. Вариантов защиты от действительно продвинутых администратов разумеется не существует, но как показывает практика это и не нужно. |
|
24.02.2009, 18:30 | #18 |
Участник
|
Цитата:
Сообщение от rmv
Мне как разработчику продукта, потенциально содержащего ошибки, гораздо проще работать зная источник ошибки. Ради таких целей и создаются механизмы, позволяющие хотя на 90 процентов логировать несанкционнированные действия с данными (в моем контексте - минуя Навижн), либо хотя бы понимать что такие действия произошли.
- - каким образом определять что действия несанкционированные? - как нужно их блогировать или блокировать (триггеры, откаты, корректировка ЛОГа транзакций (если используется Recovery Model, отличный от Simple)? - когда именно это нужно делать? |
|
24.02.2009, 20:09 | #19 |
Участник
|
Цитата:
Сообщение от RedFox
Вы сами написали возможный ответ на свой вопрос, именно "логировать несанкционнированные действия". Отсюда следует определить:
- - каким образом определять что действия несанкционированные? - как нужно их блогировать или блокировать (триггеры, откаты, корректировка ЛОГа транзакций (если используется Recovery Model, отличный от Simple)? - когда именно это нужно делать? По п.2. Видимо блогирование - действительно свежая мысль, автоматом выложить в открытый доступ и устроить публичную порку, спасибо задумался . Корректировка лога транзакий - тоже интересная идея, видимо нужно писать парсер . По п. 3 - Думаю нужно делать в момент совершения действия, так сказать в рамках одной транзакции. Если есть другие работающие идеи - с удовольствием выслушаю. |
|
24.02.2009, 20:38 | #20 |
Участник
|
|
|