AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Администрирование
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.02.2009, 21:43   #21  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
а если с другой стороны посмотреть?
были прецеденты "исправления" данных админами?
это была их инициатива, или налицо т.н. "преступный сговор"?
а почему не повесить за рабочим местом админа камеру, направленную прямо в монитор (можно муляж)? это на психологическом уровне снизит вероятность подобного рода происшествий
Старый 25.02.2009, 10:57   #22  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Цитата:
Сообщение от Sancho Посмотреть сообщение
а почему не повесить за рабочим местом админа камеру, направленную прямо в монитор (можно муляж)? это на психологическом уровне снизит вероятность подобного рода происшествий
Можно и так, только это не мой путь.
Да и на психологическом уровне гораздно лучше срабатывает единожды заданный вопрос:
"Какого икса ты менял данные в такой-то учетной табличке, такого-то числа во столько часов?"

2 Redfox - см. BOL->app_name.
Старый 25.02.2009, 12:25   #23  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от rmv Посмотреть сообщение
2 Redfox - см. BOL->app_name.
Для умного админа - это возможность спихнуть всю ответственность на кого-нибудь.
Microsoft Query:
[attachment=980:Вход_на_сервер.JPG]
Все поля - редактируемые.

P.S. Строить отношения с АДМИНами лучше на доверии. :-)
Изображения
 
Старый 25.02.2009, 14:44   #24  
chans_max is offline
chans_max
Участник
 
11 / 10 (1) +
Регистрация: 20.02.2009
Никак не ожидал столь бурной дискуссии. Если честно думал напишут "нет нельзя" и все.
Ну чтож будем обсуждать.

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

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

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

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

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

По поводу админов которые должны являтся профессионалами и которых без должного уровня знаний к работе подпускать нельзя:
К сожалению админы не выращиваются в коконах с питательной средой, им не вносится чип со знаниями в мозг, и по штрих-коду на затылке нельзя определить их квалификацию. Человека надо научить, в процессе обучения возникают ошибки и хорошо если человек, будучи не увереным в чем-то, спросит 2-5-10 раз об одном и том же (будет раздражать но это лучше чем потом базу востанавливать) хуже если он будучи неуверенным (или уверенным) сделает что-то не так, а потом будет молчать.
Старый 25.02.2009, 15:20   #25  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
я делал журналирование изменений в Наве на основе http://www.sql.ru/articles/mssql/2005/0307...esLogging.shtml.
Подобные доработки сразу исключают возможность бекапа стандартными средствами NAV.
Старый 25.02.2009, 16:46   #26  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от rmv Посмотреть сообщение
2 Redfox - см. BOL->app_name.
Извините, не понял зачем мне это? Если уж хотите поделитьсячем-то точнее, то пишите более расширенно, чем каткое сообщение об эмуляции
Старый 25.02.2009, 17:41   #27  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от chans_max Посмотреть сообщение
1) Навижн сам по себе не спасет
Да.

Цитата:
Сообщение от chans_max Посмотреть сообщение
2) Админ(ы) должен(ы) быть правильный(ми)
Нет.
Любой может ошибаться. Злоумышленник может появится везде.
Именно с этими предположениями нужно выстаивать схему работы, зоны ответственности и т.п.

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

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

Цитата:
Сообщение от chans_max Посмотреть сообщение
3) Халявы не будет готовых прог нет
Как всегда: Серебрянной пули нет.

В вашем конретном случае "лог действий администратора" не поможет, поскольку:
1. вы, похоже, и сами не знаете какие действия являются несанкционированными
2. вы с легкостью идете на подмену понятий: обратите внимание, что на самом деле вы собираетесь следить за действиями учетной записи администратора, а не человека-администратора. Обратите внимание, что человек-администратор может выполнять действия и из-под чужой учетной записи. Одно осознание этого факта выведет вас на следующий уровень.
__________________
полезное на axForum, github, vk, coub.
Старый 25.02.2009, 17:59   #28  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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/
__________________
полезное на axForum, github, vk, coub.
Старый 25.02.2009, 19:09   #29  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Я считаю, что вопрос надо разбить на два:
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% операций с данными и помогают самим администраторам более полно определить источник изменения.
Старый 25.02.2009, 19:19   #30  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
Надежно - это резервирование и контроль. Контроль и резервирование.

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

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

Надежная работа пользователей означает:
1. есть бизнес-проверки входящих данных
2. для важных участков включены процедуры одобрения
и т.п.
Все эти действия лишь фильтр. Фильтр позволяет минимизировать количество ошибок, которые попадут в продуктовую базу. И этот фильтр важен, но не заменяет журнал изменений, так как прошедшая все процедуры контроля ошибка имеет все шансы проявиться через полгода или позже.
Старый 25.02.2009, 19:27   #31  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Особенно, если коснуться вопроса верификации и тестирования, то тут тоже не все гладко.
Ведь можно протестировать только разработанный функционал, а можно протестировать весь функционал Nav, на предмет, не поломала ли разработка что-то еще.
"Исправили одну ошибку, добавили новые две".
Поэтому, полноценная верицикация и тестирование - это долго и дорого. И не абсолютная гарантия защиты от ошибок.
Старый 25.02.2009, 19:58   #32  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от chans_max Посмотреть сообщение
3)Не вижу никаких смертельных сложностей в том чтобы, логи изменений велись на машине к которой сам админ(ы) доступа не имеет (а имеет некий "сторож" который имеет доступ к логу но не имеет доступа к базе, это не исключает сговор но тем не менее).

Да, квалифицированого суперзлодея это не остановит (его остановит СБ и ректотермоанализ), но простые ошибки позволит обнаружить и исправить.
Для обнаружения ошибок не надо отдельной машины, к которой админы доступа не имеют. А квалифицированного злодея, это не остановит. Например, имея права sysadmin на сервере я могу сохранить хеш пароля другого админа, заменить на другой пароль, залогиниться под другим админом, выполнить злодеяния, вернуть старый пароль админа на место. При этом все эти операции выполнить без срабатывания триггеров логирования. Или поставить firewall который закроет доступ к удаленному серверу логов на время "операций". Ищи - свищи. От Админа защиты нет.
Старый 25.02.2009, 20:42   #33  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Kashin + 1.
Если позволите подведу краткий итог нашей дискуссии:
1. Серебренной пули нет. Ни в разработке, ни в тестировании, ни в защите от администратора .
2. Желание все логировать (в том числе действия админа) может быть потребностью можно быстрее локализовать потенциальную ошибку, а не жаждой найти злоумышленника.
3. Варианты логирования описаны достаточно подробно и в этой ветке и на www.sql.ru.
Можно закопаться глубоко в философию и поговорить о теории управляемого хаоса, однако предлагаю закончить священные войны.
Думаю топикстартер сделал для себя необходимые выводы.
Старый 26.02.2009, 15:13   #34  
chans_max is offline
chans_max
Участник
 
11 / 10 (1) +
Регистрация: 20.02.2009
Спасибо всем большое за обсуждение.
выводы сделаны.
Тов. Kashin отдельное спасибо за подробное разложение рисков и мест возможного вскрытия и изменения БД
логи требуются только в пунктах Б)В) остальное в данный момент не интересует.

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

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.