Лабораторная работа № 4

УПРАВЛЕНИЕ ДОСТУПОМ В WINDOWS

Аудит и журналы безопасности в Windows
1. Теоретические сведения.....................................................................................2
1.1. Классификация защиты семейства ОС Windows................................................................2
1.2. Идентификация пользователей..............................................................................................2
1.3. Защита объектов системы.......................................................................................................7
1.4. Аудит и журналы безопасности...........................................................................................11
1.5. Политики аудита...................................................................................................................11
1.6. События аудита.....................................................................................................................18
1.7. Управление аудитом.............................................................................................................23
2. Практическая часть.........................................................................................24
2.1. Порядок выполнения задания..............................................................................................24
2.2. Практические задания...........................................................................................................26
2.3. Вопросы по разделу..............................................................................................................30
2.4. Порядок отчетности и форма контроля выполнения работы..........................................32

~1~
 Лабораторная работа №4.
АУДИТ И ЖУРНАЛЫ БЕЗОПАСНОСТИ WINDOWS
1. Теоретические сведения
Цель работы: Изучить основные принципы аудита безопасности Windows,
управление политикой аудита, журналами безопасности системы.

1.1. Классификация защиты семейства ОС Windows

Защита конфиденциальных данных от несанкционированного доступа является
важнейшим фактором успешного функционирования любой
многопользовательской системы. ОС Windows не является исключением и
требования к защите объектов файловой системы, памяти, объектов ядра
операционной системы внесли существенный вклад в процесс ее проектирования и
реализации.
Так, например, версии Windows NT/2000 были сертифицированы по классу С2
критериев TSSEC («Оранжевая книга»). Требования к ОС, защищенной по классу
С2, включают:
- обязательную идентификацию и аутентификацию всех пользователей ОС.
Под этим понимается способность операционной системы идентифицировать всех
пользователей, которые получают санкционированный доступ к системе, и
предоставление доступа к ресурсам только этим пользователям;
- разграничительный контроль доступа — предоставление пользователям
возможности защиты принадлежащих им данных;
- системный аудит — способность системы вести подробный аудит всех
действий, выполняемых пользователями и самой операционной системой;
- защита объектов от повторного использования — способность системы
предотвратить доступ пользователя к информации ресурсов, с которыми до
этого работал другой пользователь.
ОС Microsoft Windows XP Professional (SP2/SP3) имеет действующие
сертификаты ФСТЭК России и может использоваться в составе автоматизированных
систем до класса защищенности 1Г включительно в соответствии с требованиями
руководящего документа «Автоматизированные системы. Защита от
несанкционированного доступа к информации. Классификация автоматизированных
систем и требований по защите информации» (Гостехкомиссия России, 1992).

1.2. Идентификация пользователей

Для защиты данных Windows использует следующие основные механизмы:
- аутентификация и авторизация пользователей;
- аудит событий в системе;
- шифрование данных;
- поддержка инфраструктуры открытых ключей;
- встроенные средства сетевой защиты.
Эти механизмы поддерживаются такими подсистемами Windows, как LSASS
(Local Security Authority Subsystem Service , подсистема локальной
аутентификации), SAM (Security Account Manager, диспетчер локальных записей
безопасности), SRM (Security reference Monitor, монитор состояния защиты), Active

~2~
Directory (служба каталогов), EFS (Encrypting File System, шифрующая файловая
система) и др.
Защита объектов и аудит действий с ними в ОС Windows организованы на
основе избирательного (дискреционного) доступа, когда права доступа (чтение,
запись, удаление, изменение атрибутов) субъекта к объекту задается явно в
специальной матрице доступа. Для укрупнения матрицы пользователи могут
объединяться в группы. При попытке субъекта (одного из потоков процесса,
запущенного от его имени) получить доступ к объекту указываются, какие
операции пользователь собирается выполнять с объектом.
Если подобный тип доступа разрешен, поток получает описатель (дескриптор)
объекта и все потоки процесса могут выполнять операции с ним. Подобная схема
доступа, очевидно, требует аутентификации каждого пользователя, получающего
доступ к ресурсам и его надежную идентификацию в системе, а также механизмов
описания прав пользователей и групп пользователей в системе, описания и
проверки дискреционных прав доступа пользователей к объектам.
Рассмотрим, как в ОС Windows организована аутентификация и авторизация
пользователей.
Все действующие в системе объекты (пользователи, группы, локальные
компьютеры, домены) идентифицируются в Windows не по именам,
уникальность которых не всегда удается достичь, а по идентификаторам защиты
(Security Identifiers, SID).
SID представляет собой числовое значение переменной длины:
S – R – I – S0 - S1 - … - Sn – RID,
где S - неизменный идентификатор строкового представления SID;
R – уровень ревизии (версия). На сегодня 1.
I - (identifier-authority) идентификатор полномочий – представляет собой
8-битную строку, идентифицирующую компьютер или сеть, который выдал SID
объекту.
Возможные значения:
- 0 (SECURITY_NULL_SID_AUTHORITY) — используются для сравнений, когда
неизвестны полномочия идентификатора;
- 1 (SECURITY_WORLD_SID_AUTHORITY) — применяются для конструирования
идентификаторов SID, которые представляют всех пользователей. Например,
идентификатор SID для группы Everyone (Все пользователи) - это S-1-1-0;
- 2 (SECURITY_LOCAL_SID_AUTHORITY) — используются для построения
идентификаторов SID, представляющих пользователей, которые входят на локальный
терминал;
- 5 (SECURITY_NT_AUTHORITY) — сама операционная система. То есть, данный
идентификатор выпущен компьютером или доменом.
Sn – 32-битные коды (количеством 0 и более) субагентов, которым было
передано право выдать SID. Значение первых подчиненных полномочий
общеизвестно. Они могут иметь значение:
- 5 — идентификаторы SID присваиваются сеансам регистрации для выдачи
прав любому приложению, запускаемому во время определенного сеанса
регистрации. У таких идентификаторов SID первые подчиненные полномочия
установлены как 5 и принимают форму S-1-5-5-x-y;
- 6 —когда процесс регистрируется как служба, он получает специальный
идентификатор SID в свой маркер для обозначения данного действия. Этот
идентификатор SID имеет подчиненные полномочия 6 и всегда будет S-1-5-6;

~3~
 - 21 (SECURITY_NT_NON_UNIQUE) — обозначают идентификатор SID
пользователя и идентификатор SID компьютера, которые не являются уникальными в
глобальном масштабе;
- 32 (SECURITY_BUILTIN_DOMAIN_RID) — обозначают встроенные
идентификаторы SID. Например, известный идентификатор SID для встроенной
группы администраторов S-1-5-32-544;
- 80 (SECURITY_SERVICE_ID_BASE_RID) — обозначают идентификатор SID,
который принадлежит службе.
Остальные подчиненные полномочия идентификатора совместно обозначают
домен или компьютер, который издал идентификатор SID.
RID – 32-битный относительный идентификатор. Он является
идентификатором уникального объекта безопасности в области, для которой был
определен SID. Например, 500 — обозначает встроенную учетную запись
Administrator, 501 — обозначает встроенную учетную запись Guest, а 502 — RID для
билета на получение билетов протокола Kerberos.
При генерации SID Windows использует генератор случайных чисел, чтобы
обеспечить уникальность SID для каждого пользователя. Для некоторого
произвольного пользователя SID может выглядеть так:
S-1-5-21-789336058-484763869-725345543-1003
Предопределенным пользователям и группам Windows выдает характерные
SID, состоящие из SID компьютера или домена и предопределенного RID. В
таблице 1 приведен перечень некоторых общеизвестных SID.
Таблица 1. Общеизвестные SID Windows
SID Название Описание
S-1-1-0 Все Группа, в которую входят все пользователи
S-1-5-2 Сеть Группа, в которую входят все пользователи,
зарегистрировавшиеся в системе из сети
S-1-5-7 Анонимный вход Группа, в которую входят все пользователи,
вошедшие в систему анонимно
S-1-5-домен-500 Администратор Учетная запись администратора системы.
По умолчанию только эта запись обеспечивает
полный контроль системы
S-1-5-домен-501 Гость Учетная запись пользователя - гостя

Полный список общеизвестных SID можно посмотреть в документации Platform

SDK. Узнать SID конкретного пользователя в системе, а также SID групп, в которые он
включен, можно, используя консольную команду whoami: whoami /user /sid.
Соответствие имени пользователя и его SID можно отследить также в ключе
реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList .

После аутентификации пользователя процессом Winlogon, все процессы,

запущенные от имени этого пользователя будут идентифицироваться
специальным объектом, называемым маркером доступа (access token). Если
процесс пользователя запускает дочерний процесс, то его маркер наследуются,
поэтому маркер доступа олицетворяет пользователя для системы в каждом
запущенном от его имени процессе. Основные элементы маркера представлены на
рис. 1.

~4~
 Рис. 1. Обобщенная структура маркера доступа.

Маркер доступа содержит идентификатор доступа самого пользователя и

всех групп, в которые он включен. В маркер включен также DACL по умолчанию -
первоначальный список прав доступа, который присоединяется к создаваемым
пользователем объектам. Еще одна важная для определения прав пользователя в
системе часть маркера – список его привилегий.
Привилегии - это права доверенного объекта на совершение каких-либо действий по
отношению ко всей системе.
В таблице 2 перечислены некоторые привилегии, которые могут быть
предоставлены пользователю.

Таблица 2. Привилегии, которыми могут быть наделены пользователи

Имя и идентификатор
привилегии
Увеличение приоритета
диспетчирования
SeIncreaseBasePriorityPrivilege
Закрепление страниц в памяти
SeLockMemoryPrivilege
Управление аудитом и журналом Пользователь получает возможность указывать
безопасности SeAuditPrivilege
Овладение файлами или иными
объектами SeTakeOwnershipPrivilege владельцем любых объектов безопасности системы,
Завершение работы системы
SeShutdownPrivilege
Обход перекрестной проверки
SeChangeNotifyPrivilege
Описание привилегии
Пользователь, обладающий данной привилегией,
может изменять приоритет диспетчирования
процесса с помощью интерфейса Диспетчера задач
Процесс получает возможность хранить данные в
физической памяти, не прибегая к кэшированию
данных в виртуальной памяти на диске
параметры аудита доступа к объекту для отдельных
ресурсов, таких как файлы, объекты Active Directory
и разделы реестра.
Пользователь получает возможность становиться
включая объекты Active Directory, файлы и папки
NTFS, принтеры, разделы реестра, службы, процессы
и потоки
Пользователь получает возможность завершать
работу ОС на локальном компьютере
Используется для обхода проверки разрешений для
промежуточных каталогов при проходе
многоуровневых каталогов

Управление привилегиями пользователей осуществляется в оснастке

«Групповая политика», раздел Конфигурация Windows/Локальные
политики/Назначение прав пользователя.
Чтобы посмотреть привилегии пользователя, можно также использовать
команду whoami /all. Остальные параметры маркера носят информационный
характер и определяют, например, какая подсистема создала маркер, уникальный
идентификатор маркера, время его действия. Необходимо также отметить
возможность создания ограниченных маркеров (restricted token), которые отличаются
от обычных тем, что из них удаляются некоторые привилегии и его SID-
идетификаторы проверяются только на запрещающие правила.

~5~
 Создать ограниченный маркер можно программно, используя API-функцию
CreateRestrictedToken, а можно запустить процесс с ограниченным маркером,
используя пункт контекстного меню Windows “Запуск от имени…” и отметив
пункт “Защитить компьютер от несанкционированных действий этой программы”
(рис.2).

Рис. 2. Запуск процесса с ограниченным маркером

Ограниченные маркеры используются для процессов, подменяющих клиента и

выполняющих небезопасный код. Маркер доступа может быть создан не только
при первоначальном входе пользователя в систему.
Windows предоставляет возможность запуска процессов от имени других
пользователей, создавая для этих процессов соответствующий маркер. Для этих
целей можно использовать:
- API-функции CreateProcessAsUser, CreateProcessWithLogon ;
- оконный интерфейс (рис.2), инициализирующийся при выборе пункта
контекстного меню «Запуск от имени…»;
- консольную команду runas: runas /user:имя_пользователя program , где
- имя_пользователя - имя учетной записи пользователя, которая будет
использована для запуска программы в формате пользователь@домен или
домен\пользователь;
- program – команда или программа, которая будет запущена с помощью
учетной записи, указанной в параметре /user.
В любом варианте запуска процесса от имени другой учетной записи
необходимо задать ее пароль.

1.3. Защита объектов системы.

Маркер доступа идентифицирует субъектов-пользователей системы. С другой
стороны, каждый объект системы, требующий защиты, содержит описание прав
доступа к нему пользователей. Для этих целей используется дескриптор
безопасности (Security Descriptor, SD). Каждому объекту системы, включая файлы,
принтеры, сетевые службы, контейнеры Active Directory и другие, присваивается

~6~
дескриптор безопасности, который определяет права доступа к объекту и содержит
следующие основные атрибуты (рис.3):
- SID владельца, идентифицирующий учетную запись пользователя-владельца
объекта;
- пользовательский список управления доступом (Discretionary Access Control
List, DACL), который позволяет отслеживать права и ограничения, установленные
владельцем данного объекта. DACL может быть изменен пользователем, который
указан как текущий владелец объекта;
- системный список управления доступом (System Access Control List, SACL),
определяющий перечень действий над объектом, подлежащих аудиту;
- флаги, задающие атрибуты объекта.
Авторизация Windows основана на сопоставлении маркера доступа субъекта
с дескриптором безопасности объекта. Управляя свойствами объекта,
администраторы могут устанавливать разрешения, назначать право владения и
отслеживать доступ пользователей.
Рис. 3. Структура дескриптора безопасности объекта Windows

Список управления доступом содержит набор элементов ( Access Control

Entries, ACE). В DACL каждый ACE состоит из четырех частей: в первой указываются
пользователи или группы, к которым относится данная запись, во второй – права
доступа, а третья информирует о том, предоставляются эти права, или отбираются.
Четвертая часть представляет собой набор флагов, определяющих, как
данная запись будет наследоваться вложенными объектами (актуально, например,
для папок файловой системы, разделов реестра).
Если список ACE в DACL пуст, к нему нет доступа ни у одного пользователя
(только у владельца на изменение DACL). Если отсутствует сам DACL в SD объекта –
полный доступ к нему имеют все пользователи.
Если какой-либо поток запросил доступ к объекту, подсистема SRM
осуществляет проверку прав пользователя, запустившего поток, на данный
объект, просматривая его список DACL. Проверка осуществляется до появления
разрешающих прав на все запрошенные операции.
Если встретится запрещающее правило хотя бы на одну запрошенную
операцию, доступ не будет предоставлен.

~7~
 Рассмотрим пример на рис.4. Процесс пытается получить доступ к
объекту с заданным DACL. В маркере процесса указаны SID запустившего его
пользователя, а также SID групп, в которые он входит. В списке DACL объекта
присутствуют разрешающие правила на чтение для пользователя с SID = 100, и на
запись для группы с SID = 205. Однако, в доступе пользователю будет отказано,
поскольку раньше встречается запрещающее запись правило для группы с SID = 201.

Рис. 4. Проверка прав доступа пользователя к объекту

Необходимо отметить, что запрещающее правило помещено в списке DACL на

рисунке не случайно. Запрещающие правила всегда размещаются перед
разрешающими, то есть являются доминирующими при проверке прав доступа.
Для определения и просмотра прав доступа пользователей к ресурсам можно
использовать как графические средства контроля, так и консольные команды.
Стандартное окно свойств объекта файловой системы (диска, папки,
файла) на вкладке Безопасность (рис. 5) позволяет просмотреть текущие
разрешения для пользователей и групп пользователей, редактировать их, создавать
новые или удалять существующие.
При определении прав доступа к объектам можно задать правила их
наследования в дочерних контейнерах. В окне дополнительных параметров
безопасности на вкладке Разрешения при выборе опции «Наследовать от
родительского объекта применимых к дочерним объектам разрешения, добавляя
их к явно заданным в этом окне» (рис. 6) можно унаследовать разрешения и
ограничения, заданные для родительского контейнера, текущему объекту

~8~
 Рис. 5. GUI-интерфейс Windows для изменения прав доступа к объектам

При выборе опции «Заменить разрешения для всех дочерних объектов

заданными здесь разрешениями, применимыми к дочерним объектам» разрешается
передача определенных для объекта-контейнера правил доступа его дочерним
объектам.

Рис. 6. Определение параметров наследования прав доступа к объектам

В этом же окне на вкладке Владелец допустимо узнать владельца объекта и

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

~9~
 Автоматизировать процесс определения разрешенных пользователю видов
доступа к объекту можно с использованием вкладки «Действующие разрешения»
окна дополнительных параметров безопасности объекта (рис. 7).

Рис. 7. Определение эффективных прав доступа пользователя (группы) к объекту

Для просмотра и изменения прав доступа к объектам в режиме командной

строки предназначена команда cacls (icacls в Windows Vista и Windows 7).

cacls имя_файла [/t] [/e] [/c] [/g пользователь:разрешение] [/r пользователь [...]]
[/p пользователь: разрешение [...]] [/d пользователь [...]]
Назначения параметров команды приведены в таблице 3.
Таблица 3. Параметры команды cacls
Атрибут команды Описание атрибута
<имя файла> Задаёт файл или папку, права доступа к которой
необходимо просмотреть или изменить (допустимо
использовать шаблоны с символами * и ?)
/t Изменение избирательных таблиц контроля
доступа (DACL) указанных файлов в текущем
каталоге и всех подкаталогах
/e Редактирование избирательной таблицы
управления доступом (DACL) вместо ее замены
/c Заставляет команду продолжить изменение прав
доступа при возникновении ошибки, связанной с
нарушениями прав доступа
/g <пользователь | группа: разрешение>
Предоставление прав доступа указанному
пользователю
/r <пользователь | группа> Отнимает права доступа указанного пользователя
/p <пользователь | группа: разрешение>
Заменяет права доступа указанного пользователя
/d <пользователь | группа> Отказывает в праве доступа указанному
пользователю или группе

Для указания добавляемых или отнимаемых прав используются следующие

значения:
F - полный доступ;
C - изменение (запись);
W - запись;
R - чтение;
N - нет доступа.

~ 10 ~
 Рассмотрим несколько примеров.
- cacls d:\test - выдаст список DACL для папки test.
- cacls d:\test /d ИмяКомпьютера\ИмяПользователя /e - запретит доступ к
объекту для указанного пользователя.
- cacls d:\test /p ИмяКомпьютера\ИмяГруппы:f /e /t - предоставит полный
доступ к папке d:\test и всем ее подпапкам для членов указанной группы.
Для программного просмотра и изменения списков DACL можно
использовать API-функции AddAccessAllowedAce, AddAccessDeniedAce,
SetSecurityInfo.

1.4. Аудит и журналы безопасности

Аудит — одно из средств защиты ОС Windows. Аудит позволяет отслеживать
и записывать в журнал, события, связанные с безопасностью. Примерами событий
для аудита можно назвать доступ к файлу, вход в систему или изменение системной
конфигурации.
Журнал безопасности ведется на каждом компьютере и на каждом
компьютере регистрирует происходящие на нем события.
Благодаря системе аудита, администратор может узнать, кто, каким образом
и когда пользовался (или пытался пользоваться, но получил отказ в доступе)
интересующими его ресурсами.
Настройка аудита позволяет выбрать типы событий, подлежащих
регистрации, и определить, какие именно параметры будут регистрироваться.
Наиболее общими типами событий для аудита безопасности являются:
доступ к файлам и папкам; управление учетными записями пользователей и групп;
вход пользователей в систему и выход из нее.
Фиксируются следующие параметры, касающиеся действий, совершаемых
пользователями: выполненное действие; имя пользователя, выполнившего действие;
дата и время выполнения.
Аудит приводит к дополнительной нагрузке на систему, поэтому
регистрируйте лишь события, действительно представляющие интерес.

1.5. Политики аудита

Перед выполнением аудита необходимо выбрать политику аудита, которая
указывает типы событий, регистрируемых в журнале безопасности. При первой
установке Windows XP SP2 все категории аудита выключены. Включая аудит
различных категорий событий, поэтому имеется непосредственная возможность
создавать политику аудита, удовлетворяющую необходимым требованиям.
Настройка политик аудита доступна в оснастке Групповая политика.
Существуют следующие категории аудита:
- Аудит событий входа в систему отслеживает события, связанные с
попытками пользователя войти в систему с другого компьютера или выйти из
нее (при условии, что компьютер используется для проверки подлинности
учетной записи);

~ 11 ~
 - Аудит управления учетными записями отслеживает все события,
связанные с управлением учетными записями. Записи аудита появляются при
создании, изменении или удалении учетной записи пользователя или группы;
переименовании, отключении или включении учетной записи пользователя; задании
или изменении пароля.;
- Аудит доступа к службе каталогов отслеживает события доступа к
каталогу Active Directory, для которого задана собственная системная таблица
управления доступом (SACL). Записи аудита создаются каждый раз при доступе
пользователей или компьютеров к каталогу.;
- Аудит входа в систему отслеживает события входа в систему или выхода
из нее, а также удаленные сетевые подключения;
- Аудит доступа пользователя к объектам (например, к файлам, папкам,
разделу реестра, принтеру и т. п., - для которых задана SACL - собственная
системная таблица управления доступом) отслеживает использование системных
ресурсов файлами, каталогами, общими ресурсами, и объектами Active Directory;
- Аудит изменения политики отслеживает изменения политик назначения
прав пользователей, политик аудита или политик доверительных отношений;
- Аудит использования привилегий отслеживает каждую попытку
применения пользователем предоставленного ему права или привилегии.
Примечание. Политика Аудит использования привилегий не отслеживает события,
связанные с доступом к системе, такие, как использование права на интерактивный вход в
систему или на доступ к компьютеру из сети. Эти события отслеживаются с помощью
политики Аудит входа в систему. 
- Аудит отслеживания процессов отслеживает системные процессы и
ресурсы, используемые ими. 
- Аудит системных событий отслеживает события включения,
перезагрузки или выключения компьютера, а также события, влияющие на
системную безопасность или отражаемые в журнале безопасности. Решения об
аудите конкретного типа событий безопасности принимаются в соответствии с
политикой аудита локальной системы. Политика аудита, также называемая
локальной политикой безопасности (local security policy), является частью политики
безопасности, поддерживаемой LSASS в локальной системе, и настраивается с
помощью редактора локальной политики безопасности (Оснастка gpedit.msc,
Конфигурация компьютера - Конфигурация Windows – Параметры безопасности
– Локальные политики – Политика аудита, рис. 8).
Для каждого объекта в SD содержится список SACL, состоящий из
записей ACE, регламентирующих запись в журнал аудита удачных или неудачных
попыток доступа к объекту. Эти АСЕ определяют, какие операции, выполняемые
над объектами конкретными пользователями или группами, подлежат аудиту.
Информация аудита хранится в системном журнале аудита. Аудиту могут
подлежать как успешные, так и неудачные операции.

~ 12 ~
 Рис. 8. Конфигурация политики аудита редактора локальной политики безопасности

Подобно записям ACE DACL, правила аудита объектов могут наследоваться

дочерними объектами. Процедура наследования определяются набором флагов,
являющихся частью структуры ACE. Настройка списка SACL может быть
осуществлена в окне дополнительных свойств объекта (пункт “Дополнительно”,
закладка “Аудит”, рис. 9).

Рис. 9. Интерфейс редактирования правил аудита для объекта

Для программного просмотра и изменения списков SACL можно

использовать API-функции GetSecutityInfo и SetSecutityInfo. При инициализации
системы и изменении политики LSASS посылает SRM сообщения,
информирующие его о текущей политике аудита. LSASS отвечает за прием
записей аудита, генерируемых на основе событий аудита от SRM, их редактирование
и передачу Event Logger (регистратору событий).
SRM посылает записи аудита LSASS через свое LPC-соединение. После этого
Event Logger заносит записи в журнал безопасности.

Рассмотрим перечисленные выше политики аудита более подробно.

~ 13 ~
 Аудит событий входа учетных записей в систему . Этот параметр политики
определяет необходимость аудита каждого входа пользователя в систему или
выхода из нее с другого компьютера, проверяющего учетную запись. При проверке
подлинности локального пользователя на локальном компьютере формируется
событие входа в систему, регистрируемое в локальном журнале безопасности.
События выхода из системы не регистрируются.
Аудит управления учетными записями. Этот параметр политики определяет
необходимость аудита каждого события управления учетными записями на
компьютере. Примеры событий управления учетными записями:
- создание, изменение или удаление учетной записи пользователя;
- переименование, отключение или включение учетной записи пользователя;
- задание или изменение пароля.
Организациям нужна возможность определения того, кто создает, изменяет и
удаляет учетные записи доменов и локальных систем. Несанкционированные
изменения могут быть как ошибками администраторов, не соблюдающих политики
организации, так и признаками умышленных атак.
Например, события отказов при управлении учетными записями часто
свидетельствуют о попытках расширения привилегий, предпринимаемых
администратором более низкого уровня или злоумышленником, получившим доступ
к его учетной записи. Соответствующие журналы помогают узнать, какие учетные
записи изменил, или создал хакер.
Наилучший подход к управлению доступом состоит в том, чтобы
предоставлять доступ группам, а не отдельным пользователям. С помощью
категории событий Управление учетными записями можно легко
идентифицировать случаи изменения членства в группах. Во многих случаях
злоумышленники, получившие права административного доступа к системе, сначала
создают новую учетную запись, а затем используют ее для дальнейших атак. С
помощью событий категории Управление учетными записями факт создания новой
учетной записи может быть легко выявлен.
Аудит доступа к службе каталогов. Категория Аудит доступа к службе
каталогов обеспечивает низкоуровневый аудит объектов ActiveDirectory (AD) и их
свойств. Поскольку данная категория имеет непосредственное отношение к AD, то
активировать аудит подобных событий на системах, которые не являются
контроллерами домена, не имеет ни малейшего смысла.
Аудит событий входа в систему. Этот параметр политики определяет
необходимость аудита каждого входа пользователя в систему или выхода из нее.
Параметр Аудит событий входа в систему регламентирует создание записей,
служащих для слежения за активностью локальных учетных записей.
Если присвоить параметру Аудит событий входа в систему значение Нет
аудита, будет сложно или невозможно узнать, какие пользователи входили на
компьютеры в организации или пытались это сделать. Если пользователь входит в
систему с локальной учетной записью, а параметр Аудит событий входа учетных

~ 14 ~
записей в систему имеет значение Включен, то при входе в систему формируются
два события.
Аудит доступа к объектам. Сам по себе этот параметр политики не запускает
аудита каких-либо событий. Параметр Аудит доступа к объектам определяет
необходимость аудита событий доступа к объекту (например к файлу, папке,
разделу реестра или принтеру), для которого задан системный список управления
доступом (SACL).
System Access-Control List (SACL) - список, похожий на ACL, но отвечающий
не за разрешение или запрет на доступ, а за аудит (протоколирование в журнале
безопасности) успешных и безуспешных попыток доступа к объекту.
SACL состоит из записей управления доступом. Каждая запись управления
доступом включает сведения трех типов:
- участник безопасности (пользователь, компьютер или группа), для
которого будет выполняться аудит;
- определенный тип доступа, для которого будет выполняться аудит
(маска доступа);
- флаг, указывающий на необходимость аудита событий сбоя доступа,
успешного доступа или того и другого вида событий.
Если параметр Аудит доступа к объектам настроен для регистрации
значений Успех, запись аудита создается каждый раз, когда пользователь успешно
получает доступ к объекту с указанным системным списком управления доступом.
Если этот параметр настроен для регистрации значений Отказ, запись аудита
создается каждый раз, когда пользователь безуспешно пытается получить доступ к
объекту с указанным системным списком управления доступом.
При настройке системных списков управления доступом организации
должны определять только те действия, которые необходимо включить. Например,
может потребоваться включить параметр Аудит записи и добавления данных для
EXE-файлов, чтобы отслеживать их изменение или замену, так как вирусы, черви и
«троянские кони» обычно воздействуют на EXE-файлы. Кроме того, может
потребоваться отслеживание доступа к конфиденциальным документам и их
изменения.
В принципе с помощью категории Аудит доступа к объектам можно
следить за доступом к файлам, папкам, принтерам, разделам реестра и системным
службам, но в большинстве случаев данная категория используется для
отслеживания доступа к файлам и папкам. Как только будет включен аудит по
данной категории, в журнале безопасности сразу же отобразится некоторое
количество событий, касающихся доступа к объектам в базе безопасности SAM.
Однако каких-либо других событий, связанных с доступом к файлам или другим
объектам, вы здесь не увидите, поскольку каждый объект имеет свои настройки
параметров аудита, а по умолчанию почти у всех объектов аудит отключен. Это
правильная практика, поскольку, если в системе будет включен аудит попыток
доступа к каждому файлу или объекту, то данная система до своей полной
остановки будет заниматься только обработкой этих событий, а ее журнал

~ 15 ~
безопасности быстро переполнится, вне зависимости от назначенного ему объема.
Рекомендуется применять эту категорию только к критически важным файлам,
действительно требующим механизмов слежения за доступом к ним.
Аудит изменения политики. Этот параметр политики определяет
необходимость аудита каждого изменения политик назначения прав пользователям,
политик доверия или самой политики аудита.
Если параметр Аудит изменения политики настроен для регистрации
значений Успех, запись аудита создается при каждом успешном изменении политик
назначения прав пользователям, политик доверия или политик аудита. Если этот
параметр политики настроен для регистрации значений Отказ, запись аудита
создается при каждой неудачной попытке изменения политик назначения прав
пользователям, политик доверия или политик аудита.
Рекомендованный способ настройки этого параметра позволяет узнать, какие
привилегии учетной записи злоумышленник пытается повысить или получить
(например, привилегии Отладка программ или Архивация файлов и каталогов).
Аудит использования привилегий. Для обеспечения контроля возможностей
выполнения пользователями функций системного уровня, таких как изменение
системного времени или выключение, в Windows применяется система прав
пользователей (привилегий).
Этот параметр политики определяет необходимость аудита каждого
применения права пользователя. Если параметр Аудит использования привилегий
настроен на регистрацию значений типа Успех, запись аудита создается при каждом
успешном применении права пользователя. Если этот параметр настроен на
регистрацию значений типа Отказ, запись аудита создается при каждой неудачной
попытке применения права пользователя.
При применении указанных ниже прав пользователя аудит не записывается,
даже если задан параметр Аудит использования привилегий, поскольку для этих
прав регистрируется большое число событий в журнале безопасности. Аудит
следующих прав пользователя отрицательно сказывался бы на производительности
компьютеров:
- обход перекрестной проверки;
- отладка программ;
- создание маркерного объекта;
- Замена маркера уровня процесса;
- создание аудитов безопасности;
- архивация файлов и каталогов;
- восстановление файлов и каталогов.

Примечание. Если нужно осуществлять аудит этих прав, необходимо включить в

групповой политике параметр Аудит: аудит прав на архивацию и восстановление.

Аудит отслеживания Этот параметр политики определяет

процессов.
необходимость аудита подробной информации о таких событиях, как активация

~ 16 ~
программ, завершение процессов, дублирование дескрипторов и косвенный доступ к
объектам. Если этот параметр настроен на регистрацию значений типа Успех, запись
аудита создается при каждой операции, успешно выполненной отслеживаемым
процессом. Если этот параметр настроен на регистрацию значений типа Отказ,
запись аудита создается при каждой неудачной попытке выполнения операции
отслеживаемым процессом.
Если параметр Аудит отслеживания процессов задан, регистрируется
большое количество событий, поэтому обычно ему присваивают значение Нет
аудита. Однако этот параметр может оказаться очень полезным при реагировании
на инциденты, потому что он позволяет получить подробные сведения о
запущенных процессах и времени запуска каждого из них.
Аудит системных событий. Этот параметр политики определяет
необходимость аудита, когда пользователь перезагружает или выключает
компьютер, либо когда происходит событие, влияющее на безопасность или журнал
безопасности компьютера (например, очистка журнала событий). Если этот
параметр настроен на регистрацию значений типа Успех, запись аудита создается
при успешном выполнении системного события. Если этот параметр настроен на
регистрацию значений типа Отказ, запись аудита создается при неудачной попытке
выполнения системного события.

1.6. События аудита

События аудита записываются в журналы следующих типов:
1. Журнал приложений (Application Log). В журнале приложений
содержатся данные, относящиеся к работе приложений и программ. Он содержит
сообщения об ошибках, предупреждения и другую информацию, выдаваемую
различными приложениями. Список событий, регистрируемых в этом журнале,
определяется разработчиками приложений. Журнал находится в файле Appevent.evt.
2. Журнал безопасности. Журнал безопасности содержит записи о таких
событиях, как успешные и безуспешные попытки доступа в систему, а также о
событиях, относящихся к использованию ресурсов. События, регистрируемые в
этом журнале, определяются заданной вами стратегией аудита. Журнал находится в
файле Secevent.evt.
3. Журнал системы. В журнале системы содержатся события системных
компонентов Windows. Он содержит сообщения об ошибках, предупреждения и
другую информацию, исходящую от ОС и компонентов сторонних производителей.
Список событий, регистрируемых в этом журнале, предопределен ОС и
компонентами сторонних производителей и не может быть изменен пользователем.
Журнал находится в файле Sysevent.evt. Например, в журнале системы
регистрируются сбои при загрузке драйвера или других системных компонентов
при запуске системы.
4. Журнал службы каталогов. В журнале службы каталогов содержатся
события, заносимые службой каталогов Windows (на контроллере домена AD).

~ 17 ~
 5. Журнал службы репликации. В журнале службы репликации файлов
содержатся события, заносимые службой репликации файлов Windows (на
контроллере домена AD).
Просмотр журнала безопасности осуществляется в оснастке «Просмотр
событий» (eventvwr.msc, рис. 10). Сами журналы хранятся в файлах
SysEvent.evt, SecEvent.evt, AppEvent.evt в папке %WinDir%\system32\config.

Рис. 10. Оснастка Windows «Просмотр событий»

В журнал записываются события 3 основных видов:

1. Информационные сообщения о событиях. Описывают успешное
выполнение операций, таких как запуск или некоторое действие системной службы.
2. Предупреждающие сообщения о событиях. Описывают неожиданные
действия, означающие проблему, или указывают на проблему, которая возникнет
в будущем, если не будет устранена сейчас .
3. Сообщения о событиях ошибок. Описывают ошибки, возникшие из-за
неудачного выполнения задач.
Как уже упоминалось ранее, Windows регистрирует в журналах
происходящие события, которые отслеживаются политикой аудита. Пользуясь
информацией журналов событий, можно получить сведения о неполадках
аппаратного и программного обеспечения, а также наблюдать за событиями
безопасности Windows. Управлять и просматривать содержимое журналов событий
можно с помощью утилиты Просмотр событий (Event Viewer).
Все журналы размещены в папке %Systemroot%\System32\Config. Журналы
событий можно просматривать с любого компьютера локальной сети, при наличии
прав администратора на компьютере, где расположен журнал. Нас будет
интересовать, прежде всего, Журнал безопасности, т.к. именно в нем
регистрируются события аудита безопасности.
При выборе событий для проведения аудита следует учитывать возможность
переполнения журнала. Чтобы иметь возможность просматривать содержимое
журналов за длительный промежуток времени, рекомендуется периодически
архивировать текущие журналы. Дополнительные журналы могут быть добавлены
при установке дополнительных служб.
В таблице 4 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
входа учетных записей в систему.

~ 18 ~
 Таблица 4. События входа учетных записей в систему
Код события Описание события
672 Билет службы проверки подлинности успешно выдан и проверен.
673 Билет службы предоставления билетов (TGS) предоставлен. Билет TGS
выдается службой TGS Kerberos версии 5, которая позволяет
пользователю подтвердить подлинность для конкретной службы в
674 домене.
Участник безопасности обновил билет службы проверки подлинности
или билет службы предоставления билетов.
675 Ошибка предварительной проверки подлинности. Это событие
формируется в центре распространения ключей (KDC) при вводе
неверного пароля.
676 Ошибка запроса билета проверки подлинности.
677 Билет службы предоставления билетов не предоставлен.
678 Учетная запись успешно сопоставлена с учетной записью домена.
682 Пользователь восстановил завершенный сеанс работы с сервером
терминалов.
683 Пользователь завершил сеанс работы с сервером терминалов, но не
вышел из системы.
В таблице 5 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
управления учетными записями.

Таблица 5. События управления учетными записями

Код события Описание события
624 Создана учетная запись пользователя.
627 Изменен пароль пользователя.
628 Задан пароль пользователя.
630 Удалена учетная запись пользователя.
635 Создана локальная группа.
636 В локальную группу добавлен член.
637 Из локальной группы удален член.
638 Удалена локальная группа.
639 Изменена учетная запись локальной группы.
642 Изменена учетная запись пользователя.
644 Учетная запись пользователя автоматически заблокирована.
645 Создана учетная запись компьютера.
646 Изменена учетная запись компьютера.
647 Удалена учетная запись компьютера.
668 Изменен тип группы.
685 Изменено имя учетной записи.
В таблице 6 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
входа в систему.

Таблица 6. События аудита входа в систему

~ 19 ~
Код события Описание события
528 Пользователь успешно вошел в систему.
529 Сбой при входе в систему. Предпринята попытка входа в систему с
использованием неизвестного имени пользователя или известного
имени пользователя с неправильным паролем.
530 Сбой при входе в систему. Предпринята попытка входа в систему вне
допустимого интервала времени.
531 Сбой при входе в систему. Предпринята попытка входа в систему с
отключенной учетной записью.
532 Сбой при входе в систему. Предпринята попытка входа в систему с
устаревшей учетной записью.
533 Сбой при входе в систему. В систему попытался войти пользователь,
не имеющий на это права.
534 Сбой при входе в систему. Пользователь попытался войти в систему
с использованием пароля недопустимого типа.
535 Сбой при входе в систему. Пароль указанной учетной записи
537 устарел.
Сбой при входе в систему. Попытка входа в систему завершилась
неудачей по иным причинам.
538 Процесс выхода пользователя из системы завершен.
539 Сбой при входе в систему. Ко времени попытки входа в систему
учетная запись была заблокирована.
540 Пользователь успешно вошел в сеть.
543 Работа в основном режиме завершена.
544 Проверка подлинности основного режима завершилась неудачей, так
как узел не предоставил действительный сертификат или подпись не
была проверена.
545 Проверка подлинности основного режима завершилась неудачей из-
за сбоя в протоколе проверки подлинности Kerberos или указания
неправильного пароля.
550 Уведомление, которое может свидетельствовать об атаке типа «отказ
в обслуживании».
551 Пользователь инициировал процесс выхода из системы.
552 Пользователь успешно вошел в систему с явно заданными учетными
данными, уже будучи зарегистрированным в системе в качестве
другого пользователя.
682 Пользователь восстановил завершенный сеанс работы с сервером
терминалов.
683 Пользователь завершил сеанс работы с сервером терминалов, но не
вышел из системы.
В таблице 7 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
доступа к объектам.

Таблица 7. События доступа к объектам

Код события Описание события
560 Предоставлен доступ к существующему объекту.
562 Закрыт дескриптор объекта.
563 Выполнена попытка открыть объект с целью его удаления.
564 Удален защищенный объект.
565 Предоставлен доступ к существующему типу объекта.

~ 20 ~
Код события Описание события
567 Использовано разрешение, связанное с дескриптором. Дескриптор
создается с определенными разрешениями (например разрешениями на
чтение и запись). При использовании дескриптора для каждого из
использованных разрешений может быть создана запись аудита.
570 Клиент попытался получить доступ к объекту. Это событие
формируется при каждой попытке выполнения операции над объектом.
В таблице 8 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
изменения политики безопасности.

Таблица 8. События аудита изменения политики

Код события Описание события
608 Предоставлено право пользователя.
609 Удалено право пользователя.
612 Изменена политика аудита.
618 Изменена политика восстановления зашифрованных данных.
621 Учетной записи предоставлен доступ к системе.
622 Для учетной записи заблокирован доступ к системе.
623 Политика аудита задана для каждого пользователя.
В таблице 9 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
использования привилегий.

Таблица 9. События использования привилегий

Код события Описание события
576 В маркер доступа пользователя добавлены указанные привилегии. Это
событие регистрируется при входе пользователя в систему.
577 Пользователь попытался выполнить привилегированную операцию
системной службы.
578 Привилегии использованы для уже открытого дескриптора
защищенного объекта.
В таблице 10 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита событий
отслеживания процессов.

Таблица 10. События отслеживания процессов

Код события Описание события
592 Создан процесс.
593 Процесс завершил работу.
594 Продублирован дескриптор объекта.
595 Получен косвенный доступ к объекту.
598 Включена защита данных, для которых проводится аудит.
599 Отключена защита данных, для которых проводится аудит.
600 Процессу назначен основной маркер.
601 Пользователь попытался установить службу.

~ 21 ~
 Код события Описание события
602 Создано задание планировщика.
В таблице 11 приведены основные события безопасности, которые
регистрируются в журнале безопасности, если задана политика аудита системных
событий.
Таблица 11. Сообщения о системных событиях для аудита системных событий
Код события Описание события
512 Запуск системы Windows.
513 Завершение работы системы Windows.
516 Внутренние ресурсы, выделенные очереди сообщений о событиях
безопасности, исчерпались, что привело к утрате некоторых
сообщений о событиях безопасности.
517 Очищен журнал аудита.
520 Изменено системное время.

1.7. Управление аудитом

Применение политик аудита существенно повышает безопасность и
целостность системы. Практически каждая компьютерная система в сети должна
быть настроена с ведением журналов безопасности.
Администраторам следует создать политику аудита, определяющую
содержимое отчетов о событиях безопасности и регистрирующую действия
пользователей или компьютеров, относящиеся к указанным категориям событий.
Перед реализацией политики аудита нужно решить, для каких категорий
событий следует выполнять аудит. От параметров аудита, заданных
администратором для категорий событий, зависит политика аудита организации.
Если параметры аудита для конкретных категорий событий определены,
администраторы могут создать политику аудита, соответствующую требованиям
организации.
Если политика аудита не задана, определить, что произошло при инциденте в
сфере безопасности, будет сложно или невозможно. Если же настроить параметры
аудита так, чтобы события регистрировались при многих санкционированных
действиях, журнал безопасности может быть заполнен бесполезными данными.
В сетях с минимальным требованиям к безопасности подвергайте аудиту:
- успешное использование ресурсов, только в том случае, если эта
информация вам необходима для планирования;
- успешное использование важной и конфиденциальной информации.
В сетях со средними требованиями к безопасности подвергайте аудиту:
- успешное использование важных ресурсов;
- удачные и неудачные попытки изменения стратегии безопасности и
административной политики;
- успешное использование важной и конфиденциальной информации.
В сетях с высокими требованиями к безопасности подвергайте аудиту:
- удачные и неудачные попытки регистрации пользователей;
- удачное и неудачное использование любых ресурсов;
~ 22 ~
 - удачные и неудачные попытки изменения стратегии безопасности и
административной политики.
Журналы сбоев часто оказываются более информативными, чем журналы
успешного выполнения операций, потому что сбои обычно свидетельствуют об
ошибках. Например, успешный вход пользователя в систему обычно считается
нормальным развитием событий. Если кто-то безуспешно пытается несколько раз
войти в систему, это может быть признаком использования чужих учетных данных.
События, происходящие на компьютере, регистрируются в журналах событий.
Перед реализацией политики аудита в организации следует определить
способы сбора, организации и анализа данных. От большого объема данных аудита
мало пользы, если отсутствует план их использования. Кроме того, аудит
компьютерных сетей может отрицательно сказываться на производительности
систем. Даже если влияние определенного сочетания параметров на компьютер
конечного пользователя практически незаметно, на сервере с высокой нагрузкой оно
может оказаться существенным. Таким образом, перед заданием новых параметров
аудита в рабочей среде следует проверить, не ухудшит ли это производительность
систем.
2. Практическая часть
2.1. Порядок выполнения задания
1. Изучить теоретический материал лабораторной работы.
2. Изучить управление политиками аудита в системе.
Управление политиками аудита можно осуществлять через оснастку
«Локальные параметры безопасности» или через оснастку «Групповая
политика».
Оснастка «Локальные параметры безопасности»
а) Для вызова оснастки «Локальные параметры безопасности » нажмите
«Пуск» - «Выполнить», наберите secpol.msc и нажмите «ОК».
б) Далее выберите «Локальные политики» - «Политика аудита»
Оснастка «Групповая политика»
в) Для вызова оснастки «Групповая политика» нажмите «Пуск» -
«Выполнить», наберите gpedit.msc и нажмите «ОК».
г) Далее выберите «Конфигурация компьютера» - «Конфигурация
Windows» - «Параметры безопасности» - «Локальные политики» - «Политика
аудита»
Очевидно, что использовать оснастку «Локальные параметры
безопасности» для этих целей проще. Более подробно оснастка «Локальные
параметры безопасности» будет рассмотрена в лабораторной работе « Локальная
политика безопасности Windows».
Изучить аудит событий Windows, объектов файловой системы и реестра.
После выбора политики аудита изучение процесса аудита следует осуществлять
экспериментальным путем в два этапа:

~ 23 ~
 - выполнение действия, подлежащего аудиту (например, добавление новой
учетной записи при включенной политике «Аудита управления учетными
записями»);
- просмотр зарегистрированного события в журнале безопасности Windows
При включении соответствующей политики аудита, регистрация событий аудита
начинается автоматически. Это справедливо для всех политик аудита, кроме
«Политики аудита доступа к объектам». Данная политика используется для
регистрации событий доступа к основным объектам ОС (файловой системе, реестру,
принтерам и т.д.). Для того, чтобы регистрация событий началась, необходимо явно
указать объект и виды доступа, подлежащие аудиту. Для файловой системы и
реестра это делается через закладку «Безопасность» диалогового окна свойств
объекта. На закладке «Безопасность» следует нажать кнопку «Дополнительно» и
далее перейти, а закладку «Аудит».
Изучить управление журналами событий и безопасности Windows. Для
просмотра и управления журналом безопасности Windows используют оснастку
«Просмотр событий».
Для вызова оснастки необходимо:
а) Нажать Пуск > Выполнить.
б) Набрать eventvwr.msc и нажать ОК.

~ 24 ~
 2.2. Практические задания

Задание 1. Планирование политики аудита

Спланируйте политику аудита для вашего компьютера. Затем
активизируйте аудит конкретных событий. Назначьте аудит файла и принтера.
Просмотрите файл журнала безопасности и задайте параметры в окне Event Viewer
(Просмотр событий) для перезаписи журнала событий после его заполнения.
Спланируете политику аудита для вашего компьютера. Вы должны
определить следующее:
- какие типы событий отслеживать;
- отслеживать успех события, неудачу, или и то, и другое.
Действуйте следующим образом:
- записывайте неудачные попытки регистрации в системе;
- записывайте попытки несанкционированного доступа к файлам из вашей
БД;
- отслеживайте использование цветного принтера;
- отслеживайте все попытки вмешательства в аппаратное обеспечение
компьютера;
- храните запись действий, выполняемых администратором для
отслеживания неразрешенных изменений;
- отслеживайте процедуры резервного копирования для предотвращения
кражи данных;
- отслеживайте неразрешенный доступ к важным объектам Active Directory.
Запишите ваши решения в следующую таблицу.

Таблица 9 – планирование политики аудита

Отслеживаемое действие Успешное Неудачное
Вход в систему
Управление учетными записями
Доступ к службе каталогов
События входа в систему
Доступ к объектам
Изменение политики
Использование привилегий
Отслеживание процессов
Системные события

Активизируйте аудит для выбранных событий.

1. Войдите в систему под учетной записью администратора. Все действия
выполняйте в системе, работающей на виртуальной машине.
2. Раскройте меню Start\Programs\Administrative Tools
(Пуск\Программы\Администрирование) и щелкните ярлык Local Security Policy
(Локальная политика безопасности).

~ 25 ~
 3. В дереве консоли окна Local Security Settings (Параметр локальной
политики безопасности) дважды щелкните Local Policies (Локальные
политики), а затем — Audit Policy (Политика аудита).
4. Дважды щелкните каждый тип события, затем пометьте флажок Success
(Успех) или Failure (Отказ) для настройки, как показано в следующей таблице.
5. Закройте окно Local Security Settings.
6. Перезагрузите компьютер.
Таблица 10 – настройка политик аудита
Событие Отслеживать Отслеживать
успешные попытки неудачные попытки
Вход в систему
Управление учетными записями
Доступ к службе каталогов
События входа в систему
Доступ к объектам
Изменение политики
Использование привилегий
Отслеживание процессов
Системные события

Задание 2: Назначение аудита файлов

Войдите в систему под учетной записью администратора. Все действия
выполняйте в системе, работающей на виртуальной машине.
Включите аудит для текстового файла.
1. В Windows Explorer (Проводник) создайте текстовый файл с именем Audit
в корневой папке системного диска (например, C:\Audit).
2. Щелкните созданный файл правой кнопкой мыши и выберите в
контекстном меню команду Properties (Свойства).
3. В окне свойств перейдите на вкладку Security (Безопасность) и щелкните
кнопку Advanced (Дополнительно).
4. В окне Access Control Settings (Параметры управления доступом)
перейдите на вкладку Auditing (Аудит).
5. Щелкните кнопку Add (Добавить).
6. В окне Select User, Computer, Or Group (Выбор: Пользователи,
Компьютеры или Группы) дважды щелкните Everyone (Все) в списке учетных
записей пользователей и групп.
7. В окне Audit Entry For Audit (Элемент аудита для Audit) пометьте флажки
Successful (Успех) и Failed (Отказ) для каждого из следующих событий:
- Create Files/Write Data (Создание файлов/Запись данных);
- Delete (Удаление);
- Change Permissions (Смена разрешений);
- Take Ownership (Смена владельца).

~ 26 ~
 8. Щелкните ОК. Группа Everyone(Все) появится в окне Access Control
Settings.
9. Щелкните OK, чтобы применить изменения.

Задание 3.
Войдите в систему под учетной записью администратора. Все действия
выполняйте в системе, работающей на виртуальной машине.
Создайте учетную запись нового пользователя testUser в оснастке
«Управление компьютером» (compmgmt.msc). При создании новой учетной
записи запретите пользователю смену пароля и снимите ограничение на срок
действия его пароля. Создайте новую группу ” testGroup” и включите в нее
нового пользователя. Удалите пользователя из других групп. Создайте на диске
С: папку forTesting. Создайте или скопируйте в эту папку несколько текстовых
файлов (*.txt).
С помощью команды runas запустите сеанс командной строки (cmd.exe)
от имени вновь созданного пользователя. Командой whoami посмотрите SID
пользователя и всех его групп, а также текущие привилегии пользователя.
Строку запуска и результат работы этой и всех следующих консольных
команд копируйте в файл протокола лабораторной работы.
Убедитесь в соответствии имени пользователя и полученного SID в реестре
Windows. Командой whoami определите перечень текущих привилегий
пользователя testUser. В сеансе командной строки пользователя попробуйте
изменить системное время командой time. Чтобы предоставить пользователю
подобную привилегию, запустите оснастку « Локальные параметры
безопасности» (secpol.msc). Добавьте пользователя в список параметров
политики «Изменение системного времени» раздела Локальные политики ->
Назначение прав пользователя.
После этого перезапустите сеанс командной строки от имени
пользователя, убедитесь, что в списке привилегий добавилась
SeSystemtimePriviege. Попробуйте изменить системное время командой time.
Убедитесь, что привилегия «Завершение работы системы»
(SeShutdownPrivilege) предоставлена пользователю testUser . После этого
попробуйте завершить работу системы из сеанса командной строки пользователя
командой shutdown –s. Добавьте ему привилегию « Принудительное удаленное
завершение» (SeRemoteShutdownPrivilege). Попробуйте завершить работу
консольной командой еще раз (отменить команду завершения до ее
непосредственного выполнения можно командой shutdown –a).
Ознакомьтесь с справкой по консольной команде cacls. Используя эту
команду, просмотрите разрешения на папку c:\forTesting. Объясните все
обозначения в описаниях прав пользователей и групп в выдаче команды.
а) Разрешите пользователю testUser запись в папку forTesting, но запретите
запись для группы testGroup. Попробуйте записать файлы или папки в forTesting от
имени пользователя testUser. Объясните результат.

~ 27 ~
 Посмотрите эффективные разрешения пользователя testUser к папке
forTesting в окне свойств папки.
б) Используя стандартное окно свойств папки, задайте для пользователя
testUser такие права доступа к папке, чтобы он мог записывать информацию в папку
forTesting, но не мог просматривать ее содержимое. Проверьте, что папка
forTesting является теперь для пользователя testUser “слепой”, запустив,
например, от его имени файловый менеджер и попробовав записать файлы в папку,
просмотреть ее содержимое, удалить файл из папки.
в) Для вложенной папки forTesting\Docs отмените наследование ACL от
родителя и разрешите пользователю просмотр, чтение и запись в папку. Проверьте,
что для пользователя папка forTesting\Docs перестала быть “слепой” (например,
сделайте ее текущей в сеансе работы файлового менеджера от имени пользователя и
создайте в ней новый файл).
г) Снимите запрет на чтение папки forTesting для пользователя testUser.
Используя команду cacls запретите этому пользователю доступ к файлам с
расширением txt в папке forTesting. Убедитесь в недоступности файлов для
пользователя.
д) Командой cacls запретите пользователю все права на доступ к папке
forTesting и разрешите полный доступ к вложенной папке forTesting\Docs.
Убедитесь в доступности папки forTesting\Docs для пользователя. Удалите у
пользователя testUser привилегию SeChangeNotifyPrivilege. Попробуйте получить
доступ к папке forTesting\Docs. Объясните результат.
е) Запустите файловый менеджер от имени пользователя testUser и создайте
в нем папку newFolder на диске C. Для папки newFolder очистите весь список
ACL командой cacls. Попробуйте теперь получить доступ к папке от имени
администратора и от имени пользователя. Кто и как теперь может вернуть доступ к
папке? Верните полный доступ к папке для всех пользователей.
ж) Создайте в разделе HKLM\Software реестра раздел testKey. Запретите
пользователю testUser создание новых разделов в этом разделе реестра.
Создайте для раздела HKLM\Software\testKey SACL, позволяющий
протоколировать отказы при создании новых подразделов, а также успехи при
перечислении подразделов и запросе значений (предварительно проверьте, что в
локальной политике безопасности соответствующий тип аудита включен).
Попробуйте от имени пользователя testUser запустить regedit.exe и создать раздел
в HKLM\Software. Убедитесь, что записи аудита были размещены в журнале
безопасности (eventvwr.msc).

2.3. Вопросы по разделу

1. Какие задачи нужно выполнить для аудита доступа к файлу?

2. Кто вправе назначить аудит для компьютера?
3. Как при просмотре журнала безопасности определить, успешно событие
или нет?

~ 28 ~
 4. Что произойдет, когда журнал заполнится, если выбрать параметр
«Не затирать события» в окне свойств журнала аудита?
5. К какому классу безопасности относится ОС Windows по различным
критериям оценки?
6. Каким образом пользователи идентифицируются в ОС Windows XP?
7. Каким образом пользователи идентифицируются в ОС Windows 7?
8. Что такое списки DACL и SACL?
9. Перечислите, каким образом можно запустить процесс от имени другого
пользователя.
10. Как происходит проверка прав доступа пользователя к ресурсам в
ОС Windows?
11. Что такое маркер безопасности, и какова его роль в модели безопасности
Windows?
12. Как с использованием команды cacls добавить права на запись для всех
файлов заданной папки?
13. Какие события подлежат аудиту в ОС Windows?
14. Цели и задачи аудита.
15. Что понимается под аудитом безопасности в ОС?
16. Для чего нужен аудит безопасности в ОС?
17. Типы событий, которые регистрируются в журналах ОС и их краткая
характеристика.
18. Типы журналов событий в Windows и их краткая характеристика.
19. Что такое монитор безопасности ОС?
20. Как задать политику аудита для доступа субъекта к объекту в Windows?
21. Планирование политики аудита.
22. Разработка политики аудита для таких объектов ОС Windows XP как
файлы.
23. Разработка политики аудита для таких объектов ОС Windows XP как
принтеры.
24.  Разработка политики аудита для таких объектов ОС Windows XP как
системные блоки.
25. Настройка и управление аудитом ОС Windows XP для таких объектов как
файлы и папки.
26. Настройка и управление аудитом ОС Windows XP для таких объектов как
принтеры.
27. Настройка и управление аудитом ОС Windows XP для таких объектов как
системные события.
28. Разработка политики аудита для таких объектов ОС Windows 7 как
файлы.
29. Разработка политики аудита для таких объектов ОС Windows 7 как
принтеры.
30. Разработка политики аудита для таких объектов ОС Windows 7 как
системные блоки.
31. Настройка и управление аудитом ОС Windows 7 для таких объектов как
системные события.
32. Настройка и управление аудитом ОС Windows 7 для таких объектов как
принтеры.
33. Настройка и управление аудитом ОС Windows 7 для таких объектов как
файлы и папки.

~ 29 ~
 34. Критерий выбора событий, подлежащих регистрации.
35. Конфигурация аудита – что необходимо сделать для установки и
администрирования?
36. Основные этапы настройки аудита.
37. Как устанавливается политика аудита на локальном компьютере?.
38. Типы событий регистрируемых ОС Windows.
39. События для файлов и папок, вызываемые действиями пользователей.
40. События для принтеров, вызываемые действиями пользователей.
41. Утилиты управления журналом безопасности (краткая характеристика).
42. Журналы ОС Windows и их краткая характеристика. 
43. Утилиты и команды просмотра журнала безопасности ОС Windows.
44. Управление журналами аудита ОС Windows.
45. Параметры для фильтрации и поиска событий (краткая характеристика).
46. Как изменить параметры журналов аудита?
47. Архивация журналов безопасности.
48. Варианты обработки заполненных файлов журнала аудита.
49. Последовательность выполняемых операций для архивации, очистки или
просмотра файла журнала.
50. Назовите, какие категории событий отслеживает ОС Windows XP?
51. Назовите, какие категории событий отслеживает ОС Windows 7?
52. Основные виды событий аудита, которые записываются в журнал
безопасности и их краткая характеристика.
53. Что такое «маска доступа»?
54. Журнал службы регистрации – структура и краткая характеристика.
55. Журнал службы каталогов – структура и краткая характеристика.
56. Журнал системы – структура и краткая характеристика.
57. Журнал безопасности – структура и краткая характеристика.
58. Журнал приложений – структура и краткая характеристика.
59. Журнал службы репликации – структура и краткая характеристика.
60. Аудит управления учетными записями – перечень и краткая
характеристика.

2.4. Порядок отчетности и форма контроля выполнения работы

Раздел 1. Теоретическая часть. Выполнение лабораторной работы

осуществляется в два этапа: на первом этапе дается письменный ответ на вопросы из
пункта 2.2. Каждый вариант предполагает ответы на вопросы согласно номеру
варианта, и перечню вопросов приведенных в соответствующем столбце таблицы 2.1.
Контроль выполнения задания производится по окончании занятия и на
консультациях в форме защиты выполненной работы, предоставленной в
электронном и в бумажном виде в форме «Отчет по лабораторной работе».

Таблица 2.1. Варианты заданий

Номер варианта
1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 18 1 20

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 1 2 3 4 5
9 1 1 1 13 1 1 1 8 9 1 1 1 1 1 1 1 14 1 16

~ 30 ~
 е 1 1 1 2 21 2 2 2 1 1 1 1 1 2 2 2 2 25 2 27
2 2 2 2 29 3 3 3 2 2 2 2 2 2 2 3 3 36 3 38
р
3 3 3 3 37 3 3 4 3 3 3 3 3 3 3 4 4 47 4 49
а 4 4 4 4 45 4 4 4 3 3 3 4 4 4 4 5 5 58 5 60
в 4 5 5 5 53 5 5 5 4 4 4 4 4 4 5 7 8 9 1 11
о 5 5 5 6 6 7 8 9 5 5 5 5 5 5 5 1 1 20 2 22
1 1 1 1 19 2 2 2 5 5 6 1 2 3 4 2 3 31 3 33
п 2 2 2 2 32 3 3 3 1 1 1 2 2 2 2 4 4 42 4 44
р

Раздел 2. Практическая часть.

Пользователь, выполняющий практическое задание (раздел 2.1) должен

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

~ 31 ~