Имеется ирбис2003.1 в котором "идентификация" работника, работающего с электронным каталогом осуществляется на уровне выставления нужных параметров в настройках, которые затем сохраняются в ini-файле, что никак не может идентифицировать работника и соответственно не оставляет на нем никакой ответственности за "проделанную работу". Хотелось бы узнать как с этим обстоят дела в более свежих версиях ирбиса? На мой взгляд, остутствие элементарных средств за контролем действий, выполняемых работником, сводит на нет всю значимость программного продукта, претендующего на то чтобы стать одним и единственным каталогом в библиотеке. Ваша точка зрения? :)

Вы высказываете свои идеи?
Вы генерируете новые решения?

К чему этот пост? Чтобы сказать, что Вы не можете определить АДМИНИСТРАТИВНУЮ ответственность в коллективе?
За всю мою историю работы на ИРБИС32 мне только 6 раз пришлось смотреть историю mst файла для вычисления того, кто сделал неправильное действие. И это определяется простым анализом mst файла в просмотрщике. Там (в mst файле) прямая временная последовательность обращений к массиву записей. Вся остальная работа - управление административной ответственностью, которую должен далать зав.отделом каталогизации. Вы планируете за нее работать всегда? И просить новые технические решения и реализации лишь потому, что навести обычный порядок с доверием между работниками сложно?

Во-первых, я всего лишь хотел услышать чужую точку зрения на существующую проблему, во-вторых, можно поподробнее рассказать где что нужно смотреть в mst-файле (хотя бы ссылку)? В-третьих, на счет идей - почему бы не брать информацию о текущем пользователе средствами того же ntlm (естественно, при наличии домена, хотя в большинстве случаев оно так и есть при наличии более 10 машин в сети)(как вариант). А информацию о том же удалении/создании записей записывать в отдельный лог-файл? Неужели это так сложно? По каким критериям я должен определять административную ответственность того или иного человека если для этого нет никаких прямых оснований?

> Вы планируете за нее работать всегда? И просить новые технические решения и реализации лишь потому, что навести обычный порядок с доверием между работниками сложно?

Зачастую, реализовать новое техническое решение один раз куда проще чем постоянно наводить порядок с доверием между работниками, не находите?

PS. Если следовать вашей логике, то и доступ в интернет, и прочие платные для библиотеки вещи проще всего предоставлять в надежде на благоразумность пользователя, так?

> Во-первых, ...
Логика наполнения mst файла следующая: в момент нажатий кнопки "сохранить" в конец файла mst дописывается последняя версия записи. Т.е. формируется избыточность, по которой можно однозначно сказать, когда были проведены те или иные деструктивные изменения данных в записи. Просмотреть это можно обычным просмотрщиком, например FAR.
Что касается вопросов определения "деструктивного инсайдера", то достаточно один раз найти такого человека и доказать ему, что это вычисляется, после этого желания у всех остальных действовать не "по правилам" отпадают сами собой.
Придумывать же интерфейсы с системами - дело сложное и глючное, да и неблагодарное. Кто работал под каким паролем на машине можно определить и по логам сервера.
В моей практике таких случаев анализа было, всего лишь, шесть.

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

> Если следовать вашей логике, ...
Я написал лишь то, что написал, основываясь на опыте. Работа оператора данных - тонкая настройка и придумать все правила анализа не столько неэффективно, сколько сложно.

> то касается вопросов определения "деструктивного инсайдера", то достаточно один раз найти такого человека и доказать ему, что это вычисляется

В принципе, согласен, но это не столь тривиальная задача на мой взгляд с учетом того что со стороны ирбиса для этого нет никаких средств, не находите? И вполне может быть что получится как раз обратный прецедент. Работник в настройках выставляет не свои данные, портит записи в ЭК или удаляет их (мало ли, может у него с утра с начальством разговор не заладился по поводу продолжения совместной деятельности), при этом, файловый сервер записывает время входа пользователя в сеть, время инициирования доступа к сетевому ресурсу, в лучшем случае, если на нем включен отладочный лог, время доступа к конкретному файлу, все. А теперь представим, что в этот момент в сети именно с этим сетевым ресурсом работает достаточно большое количество пользователей. Да, в принципе, они не могут абсолютно одновременно изменить требуемый файл и, может быть, в итоге, сравнив время редактирования записи в mst-файле с временем его модификации в логах сервера может быть и можно что-то выиграть, но опять же, время на рабочей станции и сервере должно быть абсолютно синхронизировано, на сколько я понимаю. К тому же, той же самбе нужно принудительно говорить вести достаточно детальный лог (не знаю как в случае с окнами, скорее всего тоже самое) , ведение такого детального лога постоянно, в свою очередь, создает довольно ощутимый прирост операций ввода/вывода на сервере, т.к. кроме этого протоколируется достаточно большой объем информации. Да, это параноидальная ситуация, процент возникновения которой минимален, но, тем не менее, он есть. Собственно, я не на пустом месте завел этот разговор и не зря, опять же на мой взгляд, упомянул тот момент, что сейчас в библиотеках доверия электронному каталогу практически ноль.

Как вариант решения этой проблемы, на мой взгляд, можно просто сравнивать текущее имя пользователя, полученное от ОС со своим справочником сотрудников, перекладывая всю ответственность за аутентификацию/авторизацию пользователя на средства ОС, обслуживающий персонал и на владельца аккаунта, я не думаю, что подобная доработка повлечет существенное изменение кода продукта.

> Придумывать же интерфейсы с системами - дело сложное и глючное, да и неблагодарное.
Тем не менее, ирбис в своей работе плотно сотрудничает с тем же ms office, а не реализует его функциональность, да и права доступа к той или иной базе/компоненту ирбиса полностью перекладывает на ОС, двойные стандарты, однако :))

PS. к тому же, пункт "ФИО исполнителя" в настройках не менее смешен нежели ситуация описанная выше. Для какой цели он существует если его достоверность никак нельзя подтвердить? Лишний элемент интерфейса получается. :(

Вопрос в данном случае решается не решением поставленных "уязвимостей", а напоминанием функциональности, которая изначально была заложена в структуру "файл-серверной" технологии. И ни какой возможной работе по идентификации там задач и не ставилось. Поднимите историю программирвоания пятнадцати-двадцати-летней давности, когда "бились" сторонники файл- и клиент-серверной технологий.
В настоящее время так же существуют 2 направления. Если Вам не подходят основные принципы работы одной ветки программного обеспечения - выберите другую ветку - ИРБИС64.
Несколько лет назад такие же вопросы логирования действий решались в рамках подготовки к выпуску ИРБИС64. На сегодня, там все это есть и работает нормально со всеми логами и пр. инструментами слежки. Тем более, что всем было в свое время предложено обновить ИРБИС на ИРБИС64 по разности в цене.

Согласитесь, что странно требовать функцию "круиз-контроля" на жигулях, при сохранении постоянной цены?

> Несколько лет назад такие же вопросы логирования действий решались в рамках подготовки к выпуску ИРБИС64. На сегодня, там все это есть и работает нормально со всеми логами и пр. инструментами слежки. Тем более, что всем было в свое время предложено обновить ИРБИС на ИРБИС64 по разности в цене.

Собственно, с чего я и начал этот разговор - именно услышать как эта проблема решается в других версиях Ирбис. Спасибо, будем смотреть ирбис64 :)

> Согласитесь, что странно требовать функцию "круиз-контроля" на жигулях, при сохранении постоянной цены?

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

> ... функция четкой идентификации и авторизации сотрудников, выполняющих определенные действия с программным обеспечением организационного значения должны быть доступны ...

Каждый пользователь, покупая конкретный товар, может ознакомится с функциональностью и качеством. И каждый вправе относить на конкретном отрезке времени любой товар к той категории, которой сам решит. Публиковать свои мысли конституция не запрещает. Но функциональность написанного ПО от это не меняется и остается постоянной величиной ;)
Вы забываете, что ИРБИС32 предполагал взаимодействие с другим ПО, в т.ч. и анализ логов системы другими средствами. В то время - 1996 год - этого было достаточно. Сейчас - с 2001 года - ИРБИС64. Потом потребуются новые решения и будет - новая линейка.