Майклу Дрейгону, инженеру-системотехнику из компании Titleserv (шт. Нью-Йорк), которая специализируется на страховании прав и операциях с недвижимостью, не так уж часто приходится заниматься проблемами безопасности. Но когда руководство компании предложило ему разработать механизм мониторинга процессов регистрации сотрудников в сети и завершения сеанса работы, Майклу пришлось искать решение, не связанное с использованием журнала регистрации событий Active Directory (AD), ведь этот журнал лишь на короткое время фиксирует регистрацию и завершение сеансов пользователей в системе, назначение полномочий и другие события, после чего эти данные замещаются новыми записями. Майкл рассказал мне о том, как он выполнил поручение руководства с помощью несложного сценария и пакетного файла. Данные о регистрации и завершении сеанса работы с системой фиксировались на клиентских компьютерах, а затем перемещались в текстовые файлы и папки, откуда их легко было извлечь.
Что натолкнуло вас на идею создания механизма регистрации входа пользователей в систему и выхода из нее?
Наша внутренняя производственная система — это Web-приложение на базе Microsoft .NET Framework. В нее входит внутренний регистрирующий компонент, который содержит информацию о том, когда пользователи регистрировались в системе, когда они завершали сеанс работы с системой, что делали и т.д. К нам поступало множество запросов от администраторов, которые хотели бы, чтобы аналогичными функциями были наделены персональные компьютеры наших конечных пользователей. К примеру, если кто-то из сотрудников настаивает на оплате сверхурочных за прошлый месяц, менеджеру, возможно, потребуются сведения о том, действительно ли этот сотрудник работал сверхурочно. Чтобы подтвердить это обстоятельство, администратор хочет иметь информацию о том, когда сотрудник регистрировался в системе, или о том, работал ли тот или иной сотрудник за конкретным компьютером в то или иное время. Сведения такого рода регистрируются в AD, но они попадают в журнал регистрации событий безопасности, который может содержать не более 50 Мбайт данных; к тому же журнал должен наряду с событиями, интересующими руководство, фиксировать и другие события. Чтобы найти то, что нужно менеджерам, потребовалось бы долго ворошить журналы регистрации.
И поэтому вы разработали альтернативный метод получения сведений о регистрации?
Да. Я решил написать команду для пакетного файла, которая выполнялась бы на всех наших клиентах и серверах при регистрации пользователя в системе и фиксировала данные о регистрации и завершении сеанса работы с системой для наших клиентов Windows XP, а также для серверов (Windows Server 2003, Windows 2000 Server, Microsoft Windows Server 2003 и Windows 2000 Server Terminal Services). При регистрации пользователя в системе выполняется один сценарий, при завершении сеанса работы с системой — другой. Сценарий присоединяет данные о регистрации и о завершении сеанса работы с системой к текстовому файлу. Текстовые файлы содержат кумулятивные данные: например, в одной строке может быть записано: logged out of computer name on; далее следует дата и время. В следующий раз, когда пользователь регистрируется в системе, сценарий записывает в текстовый файл новую строку с новыми сведениями.
Еще один сценарий в виде пакетного файла извлекает сведения о регистрации и о завершении сеанса работы с системой для компьютера. Если мы хотим узнать, кто зарегистрировался на компьютере, мы можем проверить в текстовом файле компьютера сведения, касающиеся имени пользователя, а также времени регистрации и завершении сеанса системы. Сценарий копирует текстовый файл в одну из нескольких папок в зависимости от того, на какой системе выполняется сценарий. Сведения обо всех пользователях попадают в одну папку, а события регистрации, фиксируемые в привязке к компьютеру, попадают в папку для систем соответствующего типа (таких, как серверы и клиенты). Сценарии выполняются через существующие объекты Group Policy Object (GPO), которые разделяются по системам. Мы используем объекты GPO в режиме повторного запуска, так что все пользовательские настройки конфигурации (включая данный сценарий) применяются вне зависимости от того, кто регистрируется в системе.
Как руководство получает данные о регистрации и завершении сеанса пользователей в системе?
По состоянию на сегодня менеджеры просто обращаются к нам (сотрудникам ИТ-подразделения), и мы направляем им нужный текстовый файл. На просмотр ресурсов и каталогов, где размещаются эти файлы, у нас уходят буквально секунды. В нашей организации всего лишь 150 пользователей, так что этот метод нас вполне устраивает. Мы получаем от менеджеров множество таких, например, запросов: «Мне нужно знать, регистрировался ли в сети такой-то и такой-то сотрудник из дома. Проделал ли он какую-либо работу вчера вечером?». Мы можем проверить по журналу Terminal Services и выяснить, что сотрудник, о котором идет речь, зарегистрировался в сети в 22:00 и вышел через пять минут. Мы архивируем текстовые файлы, и они могут храниться сколь угодно долго.
Рассматривали ли вы возможность приобретения у независимых поставщиков программы, предоставляющей
такого рода данные?
Я познакомился с несколькими утилитами от независимых поставщиков, а надо сказать, что имеется множество утилит, предназначенных для регистрации событий. Однако мне нужно было всего-навсего вести мониторинг начала и завершения сеанса пользователей в системе, тогда как утилиты независимых поставщиков предоставляют намного больше сведений, чем мне нужно. Так что у меня не было желания приобретать утилиту только для получения интересующих меня данных, ведь, приложив некоторые усилия, я мог бы получать их бесплатно.
Сколько времени ушло у вас на написание пакетного файла, на создание папок и на тестирование вашего решения?
Написание сценариев пакетного файла и их тестирование заняло у меня всего несколько часов. Больше времени понадобилось для того, чтобы создать все каталоги и добиться, чтобы в зависимости от того, где именно в каталоге AD размещается данный пользователь компьютера, нужный сценарий выполнялся и хранился в определенной папке, т.е. чтобы, к примеру, клиентские компьютеры не отображались в папке для серверов.
Отмечалось ли в вашей организации повышение производительности труда пользователей после того, как вы ввели в эксплуатацию систему мониторинга начала и завершения сеанса работы?
Не думаю, что наше решение изменило привычки пользователей. Оно просто облегчает жизнь ИТ-специалистов. Если раньше в случае, когда кому-то нужна была такого рода информация, нам приходилось просеивать содержимое журналов регистрации событий, то теперь мы переходим в нужный каталог, находим требуемый файл и по каналам электронной почты пересылаем его администратору, направившему запрос. Это помогает сэкономить массу времени.