Данная категория позволяет проследить, как сотрудники на деле используют свои полномочия. В терминологии Windows NT слова «привилегия» (privilege) и «полномочие» (right) имеют разные значения. Изменять полномочия пользователя можно в диалоговом окне настройки политики прав пользователя (см. Экран 1), которое вызывается через User Rights Policy из меню Policies программы User Manager, находящейся в группе Administrative Tools.

Если сотрудник успешно воспользовался своими полномочиями, например изменил системное время, то в журнал безопасности записывается событие №577 (см. Рисунок 1). Поле списка привилегий события определяет, какие полномочия были успешно использованы (в примере это SeSystemtimePrivilege). Здесь опять же можно заметить некоторое несоответствие названий привилегий с тем, как их показывает диалог настройки политики прав пользователя в программе User Manager, хотя эти пары названий легко сопоставить самостоятельно. Поле имени основного пользователя и поле имени клиента определяют, кто именно воспользовался полномочием. Имя клиента существенно только тогда, когда пользователь работает с удаленной системой через сеть. Если пользователь подключается к Windows NT по сети и меняет системное время, поле имени основного пользователя будет содержать имя той учетной записи, под которой запущено серверное приложение (в данном случае служба Server), а поле имени клиента зафиксирует имя подключенного к системе пользователя. В журнале событий фиксируется также номер сеанса пользователя, что позволяет определить конкретный сеанс его работы. О том, как это следует делать, рассказано в статье «Анализируем журнал безопасности Windows NT».

Некоторые привилегии свойственны только объектам. Так, например, привилегированная операция с объектом SeSecurityPrivilege выполняется каждый раз, когда с помощью программы Event Viewer открывается журнал безопасности. При работе с любым привилегированным объектом записывается событие №578, которое фиксирует все использованные привилегии.

При всяком обращении пользователя к привилегированному действию или объекту записываются события №№577 или 578, отмечающие попытку воспользоваться соответствующими полномочиями. В зависимости от полномочий пользователя, его запрос будет либо обработан, либо отвергнут.

Некоторые полномочия используются довольно часто, и, чтобы журнал безопасности не переполнялся, лучше не фиксировать каждый раз отдельное событие. Например, при резервном копировании и восстановлении двумя важнейшими полномочиями для администраторов и пользователей являются SeBackupPrivilege и SeRestorePrivilege. Они используются при всех операциях резервного копирования и восстановления объектов. Для аудита этих событий Windows NT просто записывает в виде события факт обладания данным полномочием всего один раз при входе пользователя в систему. Таким образом, после события №528 (успешный вход в систему) часто можно наблюдать событие №576 – присвоение особых привилегий новому сеансу (см. Рисунок 2). Это событие определяет имя пользователя и домен, а также номер сеанса, позволяющий сопоставить данное событие с соответствующим сеансом работы пользователя. Событие №576 сохраняет в поле все полномочия, которыми обладает пользователь. Помимо перечисленных здесь могут быть зафиксированы полномочия SeAuditPrivilege, SeCreateToken Privilege, SeAssignPrimaryToken Privilege и SeDebugPrivilege.

Рассматриваемая категория аудита позволяет контролировать действия администраторов и операторов учетных записей при поддержке пользователей и групп. Windows NT фиксирует, какая учетная запись была изменена, добавлена или удалена и кем именно. К сожалению, информация о том, какое именно свойство пользователя или группы было изменено, не сохраняется. Весьма полезными могут оказаться и некоторые детали. Следует помнить, что события этой категории аудита записываются на той системе, где хранится учетная запись. Так, при создании новой учетной записи в локальной базе SAM отдельного сервера Windows NT записывает соответствующие события в журнал безопасности данного сервера, а при изменении учетной записи пользователя домена – в журнале на контроллере PDC этого домена.

При назначении новой учетной записи в журнал записывается событие №624 (см. Рисунок 3). Это событие определяет создающего учетную запись администратора или оператора учетных записей по имени пользователя и домену. Кроме того, хранится номер его сеанса работы, что позволяет встроить данное событие в цепочку других действий в данном сеансе. Событие записывает имя и домен новой учетной записи, а также ее код (Account ID), который в дальнейшем будет использоваться для связи с кодом SID.

При удалении пользователя Windows NT записывает событие №630, которое хранит точно такую же информацию об удаляющем пользователе, как и событие №624. Фиксируется также информация об удаляемой учетной записи – ее имя, домен и код. При изменении учетной записи пользователя записывается событие №642, хранящее информацию о том, какая учетная запись менялась и кем. Никак не фиксируется, какое из свойств учетной записи (описание, разрешенное время для работы и т. д.) было изменено.

Windows NT записывает еще несколько действий с учетными записями. События №№626 и 629 отмечают соответственно факт разрешения и запрещения использования учетной записи. Если пользователь изменил свой пароль, записывается событие №627, при этом отмечается, успешно или нет завершена данная операция. Это зависит от права пользователя на смену пароля и от политики формирования паролей в домене. При смене пароля администратором записывается событие №628.

Категория аудита управления учетными записями также отслеживает работу с группами пользователей. Windows NT записывает все действия с группами, причем одного рода события имеют различные номера для локальных и глобальных групп. Так, при создании глобальной группы записывается событие №631, а при удалении глобальной группы – событие №634. При изменении любых свойств глобальной группы кроме списка входящих в нее членов фиксируется событие №641. Изменения состава групп отслеживаются двумя событиями – при добавлении нового члена в глобальную группу фиксируется событие №632, а при удалении – событие №633. К сожалению, эти события определяют пользователя или группу только по учетному коду SID. Для локальных групп соответственно записывается событие №635 при создании группы, №638 при удалении группы, №639 при изменении группы, №636 при добавлении члена и №637 при удалении.

Когда администратор с помощью User Manager наделяет какого-либо пользователя некоторыми полномочиями, Windows NT записывает событие №608 (см. Рисунок 4). Это событие сохраняет вид полномочия и того пользователя, которому оно предоставлено. В соответствующих полях хранится вся информация об администраторе, предоставившем данное полномочие, – его имя, домен и номер сеанса. Номер сеанса администратора позволяет встроить подобное событие в цепочку действий в конкретном сеансе работы администратора в системе. При аннулировании полномочий пользователя записывается событие №609, сохраняющее такую же информацию, как и событие №608. Не следует путать события №608 и №609 с событиями из категории аудита привилегий. Описанные ранее события №576, №577 и №578 фиксируют случаи реального использования полномочий пользователями, за исключением администраторов и операторов учетных записей.

Категория аудита учетных записей содержит еще два интересных события. При нескольких безуспешных попытках войти в систему, Windows NT блокирует учетную запись домена и записывает событие №644, а событие №643 записывается всякий раз при изменении администратором требований к паролям в домене или при изменении политики блокировки учетных записей. Событие №643 не хранит информацию о конкретных изменениях, зато оно позволяет отслеживать изменения в той области, которая обычно остается довольно статичной на протяжении длительного времени. Событие №643 записывается также на серверах и рабочих станциях в случае изменения локальной системной политики.

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