Глава 18. Аудит и мониторинг Active Directory

Содержание

Каркас кибербезопасности NIST (National Institute of Standards and Technology) зиждется на трёх основных моментах: защите, выявлении и отклике. Все эти составляющие связаны друг с другом. Когда мы реализуем некую систему, нам вначале требуется понять что защищать и как это защищать. До сих пор в этой книге я объяснял важность некой инфраструктуры идентификации, а также как и что мы моем делать для защиты этого от возникающих угроз. Основываясь на этом мы можем строить некую защищённую инфраструктуру идентификации, но мы должны понимать, что мы не можем закрывать все имеющиеся двери. Мы обязаны ожидать взлома в любой момент. Однако если он произойдёт, нам следует иметь готовой некую систему для его выявления и нашего уведомления. Это позволит нам быстро и отвечать на возникающую ситуацию и минимизировать разрушения. Для выявления аналогичных происшествий важно иметь в готовности надлежащие системы и процессы. Именно здесь вступают в дело аудит и мониторинг. Они способствуют нам в том, чтобы гарантировать, что построенная нами система защиты работает как ожидалось; а, если имеется неожиданное и не авторизованное поведение, он записывается и о нём выдаются отчёты. Такие находки помогают инженерам действовать на опережение и предотвращать взломы.

Прежде чем воспользоваться Лондонской подземкой, я всегда проверяю текущее состояние вебсайта TFL (Transport for London) для просмотра значения состояния службы нужной мне линии метро.Это некая предоставляемая TFL служба, которая гарантирует своим пользователям, что они надлежащим образом спланируют свою поездку во избежание задержек. Сама система должна быть готовой для отслеживания состояния конкретной линии, предлагая нам два преимущества. В качестве поставщика службы, TFL способна выявлять имеющуюся проблему и немедленно начинает её решать. В то же самое время некие фильтруемые сведения предаются гласности, что будет важно для ваших поездок.

Аналогично, аудит и мониторинг позволяют инженером не только выявлять проблемы. Они также должны проводить фильтрацию, компонуя сведения по различным частям в общем деле, что важно для их ролей и ответственностей. Как пример, определённый ИТ управляющий желал бы знать общую доступность службы домена за последний месяц. Но ему не важно знать обо всех всевозможных событиях , которые происходили в этой системе на протяжении всех последних 30 дней, хотя это может быть важным для инженеров ИТ.

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

В данной главе мы рассмотрим следующее:

Мониторинг относящихся к службе домена AD (Active Directory) событий и регистрационных записей
Расширенный аудит инфраструктуры AD
Применение Microsoft ATA (Advanced Threat Analytics) для отслеживания угроз инфраструктуре идентификации
Мониторинг AD с помощью Azure Monitor
Azure AD Connect Health

Аудит и мониторинг AD с помощью встроенных инструментов и технологий Windows

В действительности Microsoft располагает встроенными свойствами и инструментами мониторинга и аудита сред AD. В этом разделе мы намерены выполнить обзор этих функциональностей и инструментов.

Обозреватель событий Windows

В качестве инженера, я уверен, вам хорошо знаком Обозреватель событий Windows (Windows Event Viewer). Это встроенный инструмент, который можно применять для просмотра и фильтрации зарегистрированных событий в локальном или удалённом компьютере. События здесь вырабатываются самой операционной системой, службами, ролями сервера, а также приложениями. Это наиболее распространённый инструментарий в системах Windows для целей аудита и устранения неисправностей.

Совет

Мы также имеем возможность записывать в журналы событий и индивидуальные события. Это полезно когда вы планируете запускать некий сценарий или действие на основании конкретного идентификатора событий. Это можно сделать при помощи cmdlet Write-Eventlog.

Как показывается на следующем снимке экрана, Event Viewer (Local) Windows имеет четыре различные категории для группирования журналов событий:

Рисунок 18-1

Индивидуальные представления

Обозреватель событий позволяет создавать Индивидуальные представления (Custom Views) на основании уровня события, времени, типа регистрации, типа источника, идентификатора события, категории задачи, ключевых слов, пользователей или компьютеров. Обозреватель событий перехватывает тысячи разнообразных событий. Применяя Custom Views, мы можем фильтровать события и получать доступ к нужным нам сведениям. Все такие индивидуальные обзоры будут перечисляться в разделе Custom Views. Он также имеет предварительно заданные индивидуальные обзоры.

Подобные предварительно определённые индивидуальные обзоры основываются на установленных ролях. При добавлении ролей Active Directory Domain Services также создаются некоторые индивидуальные обзоры в имеющемся журнале событий, причём все они сгруппированы в разделе, относящемся к событиям Active Directory Domain Services, как это показано на следующем снимке экрана:

Рисунок 18-2

Журналы Windows

Раздел Журналов Windows (Windows Logs) содержит пять файлов журналов Windows. Это в основном события, связанные с операционной системой:

Application log: Данный журнал содержит события, собираемые из различных приложений, запущенных в данной системе. Это могут быть приложения Microsoft или иные прочие.
Security log: Этот журнал содержит такие события, как успешные регистрации в системе или отказы в ней. Инженеры имеют возможность задавать какие события безопасности нужно записывать при помощи этой политики аудита.
Setup log: Содержит связанные с установкой и добавлением/ удалением ролей сервера события.
System log: Этот журнал содержит события, относящиеся к компонентам системы Windows. В качестве примера, в этом журнале могут перечисляться отказы в автоматическом запуске службы.
Forwarded Events: Применяя Обозреватель событий, мы можем подключаться к прочим удалённым компьютерам и просматривать их события. Однако, может потребоваться отслеживать особые события из множества источников. Как пример, давайте допустим, что нам требуется собирать события с идентификатором 4321 из трёх компьютеров. Применяя событие Subscriptions (Подписка), мы можем собирать события и переправлять их в соответствующий журнал Forwarded Events.

	Замечание
	Forwarded Events это установленное по умолчанию местоположение для активной доставки событий подписки. Тем не менее, если требуется, эти события также могут переправляться в иные файлы журналов.

Журналы приложений и служб

Категория Application and Services Logs была введена после Windows Server 2008. Она хранит все события, относящиеся к приложениям и их компонентам. Большинство из перечисляемых здесь событий более подходят разработчикам для отладки и выявления неисправностей уровня приложения.

Данная категория имеет четыре типа журналов:

Admin (Администратора): Перечисляемые в этом журнале события понятны конечным пользователям и профессионалам ИТ. Эти сведения могут применяться для выявления основных неисправностей приложения. Большинство из этих записей журнала будут содержать инструкции или ссылки на статьи по основным понятиям от поставщика приложения.
Operational (Рабочие): Рабочие события содержат информацию относительно изменений конфигурации или состояния для некого приложения/ службы. Эти события полезны для диагностики приложения.
Analytic(Аналитические): Данный журнал по умолчанию скрыт и отключён. Он как правило включается в процессе диагностики приложения или службы, так как он вырабатывает большой объём событий.
Debug: Целиком применяется для целей устранения неисправностей разработчиками и производителями приложений. Аналогично Analytic, он, по умолчанию, скрыт и отключён.

Подписки

Эта категория полностью перечисляет все подписки событий, созданные для удалённых компьютеров. Здесь мы можем создавать/ изменять/ отключать подписки событий, проверять их состояние времени исполнения, а также принудительно запускать задания подписок.

Когда мы открываем какое- то событие, оно выдаёт различные уровни сведений, например, такие:

Некое общее описание данной проблемы
Само название файла журнала
Значение источника события для указания того откуда оно произошло
Идентификационный номер этого события
Значение уровня данной ошибки (критическая, информационная или предупреждение)
Тот пользователь, который является обладателем этой ошибки
Ссылки на TechNet, KB или прочие источники для получения дополнительных сведений об этом событии
Время возникновения данного события
Имя хоста компьютера источника

Журналы событий AD DS

Помимо событий в самой категории Windows Logs category, Active Directory Domain Services и связанные с ней службы событий могут быть найдены в приводимых ниже журналах. Они расположены в категории Applications and Services Logs:

Active Directory Web Services
DFS Replication
Directory Service
DNS Server
File Replication Service (только при использовании FRS)

Файлы журналов AD DS

Кроме событий, Active Directory Domain Service и относящиеся к ней службы другие файлы системной регистрации, которые записывают данные относительно установки/ деинсталляции служб, производительности, ошибок/ отказов службы и тому подобное. Эти файлы журналов можно применять для целей аудита, выявления неисправностей или отладки.

Определённым по умолчанию местоположением этих файлов выступает %SystemRoot%\Debug:

DCPromo.log: Этот файл журнала создаётся в процессе процесса продвижения (promotion) данного AD. Он также записывает события в процессе снижения (demotion). Этот журнал будет содержать события, такие как:
- Настройки конфигурации Active Directory Domain Service
- Сведения о подготовке схемы
- Информацию о создании/ изменении раздела каталога
- Сведения о репликации данных
- Состояние конфигурации службы
- Сведения относительно создания баз данных Active Directory и каталога SYSVOL
DCPromoUI.log: Этот файл журнала может рассматриваться как некий отчёт относительно прохождения процесса продвижения/ снижения Active Directory Domain Service. Он запускает такой процесс регистрации как только открывается мастер настройки Active Directory Domain Service и завершается когда он успешно оканчивает такую установку (пока не будет принят запрос на перезагрузку) или когда он прерывается по причине ошибок. Он содержит все результаты абсолютно всех действий системы в процессе установки или удаления данной службы. Данный журнал содержит такие полезные сведения:
- Временной штамп момента начала процесса установки или удаления
- Подробные результаты каждого теста удостоверения
- Само название того контроллера домена, который использовался для первоначальной репликации
- Перечень реплицированных разделов каталога
- Значение числа объектов, которые реплицируются в абсолютно всех разделах
- Резюме конфигурации
- Информация об изменениях реестра, связанных с конфигурированием

DFSR.log: Этот файл журнала содержит относящиеся к репликации DFS события. Он может применяться для устранения проблем репликации SYSVOL и самого процесса отладки (когда SYSVOL применяет репликацию DFS).

	Замечание
	После Windows Server 2008 AD применяет по умолчанию репликацию DFS, однако если контроллеры домена были введены в Windows Server 2003, по умолчанию будет применяться RFS.

Аудит AD

Один единственный способ выявления потенциальных угроз безопасности и взломов безопасности в инфраструктуре состоит в непрерывных мониторинге и аудите. Что касается аудита, система Windows сама по себе предоставляет расширенные возможности аудита для идентификации таких проблем безопасности. Тем не менее, по умолчанию аудит выполняется только для определённых видов действий. Данные настройки аудита обрабатываются политиками аудита Windows.

	Замечание
	Здесь мы намерены рассмотреть расширенные политики аудита безопасности, которые были впервые введены в Windows Server 2008 R2.

Существует 10 категорий событий, для которых мы можем выполнять аудит в некой системе Windows:

События системы
События регистрации/ выхода из системы
События доступа к объекту
События привилегированного использования
Подробное отслеживание событий
События изменения политики
События управления учётной записи
События доступа к Службе каталога (DS, Directory service)
События регистрации учётной записи
Аудит доступа к глобальному объекту

Абсолютно все категории также имеют подчинённые категории.

Замечание

Наследуемый аудит Windows предоставляет девять категорий и все категории также имеют подчинённые. Они расположены под Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policies. Кроме того категории и подчинённые категории могут быть перечислены при помощи auditpol /get /category:\*. Расширенные политики аудита предоставляют 53 варианта для настройки необходимых требований аудита и вы можете собирать сведения более гранулированного уровня относительно событий вашей инфраструктуры чем при помощи наследуемого аудита.

Аудит этих категорий может быть включён при помощи групповых политик. Они расположены под Computer Configuration | Windows Settings | Security Settings | Advanced Audit Policy Configuration | Audit Policies, как это показано на следующем снимке экрана:

Рисунок 18-3

Все эти категории способны собирать множество событий системы и служб, относящихся к действиям инфраструктуры AD. Однако в данном разделе мы намерены сосредоточиться лишь на конкретной категории событий DS Access (Доступа DS) и её подчинённых категорий. Она отслеживает события, относящиеся к доступу к объектам AD и изменению объектов AD. Кроме того, все установки из этой категории применяются только к самим контроллерам домена.

Такая категория событий DS Access содержит четыре подчинённые категории:

Audit Directory Service Access (Аудит доступа к Службе Каталога)
Audit Directory Service Changes (Аудит изменений в Службе Каталога)
Audit Directory Service Replication (Аудит репликации Службы Каталога)
Audit Detailed Directory Service Replication (Аудит подробностей репликации Службы Каталога)

Аудит доступа к службе AD

Данная категория записывает события при доступе к некоторому объекту AD DS. Она будет работать только когда настроен SACL (system access control list, Список системного управления доступом) и были добавлены соответствующие объекты. Это аналогично доступу к службе каталога при наследуемом аудите.

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

Когда в этой категории включён аудит, в журнале безопасности можно обнаружить такое событие:

Таблица 18-1. Событие в журнале безопасности при включённом аудите доступа к службе AD
Идентификатор события	Сообщение события
`4662`	An operation was performed on an object (Над объектом была выполнена некая операция)

Аудит изменений в службе AD

Данная категория записывает события, которые относятся к изменениям объекта AD DS,а именно:

Create (создание)
Delete (удаление)
Modify (изменение)
Move (перемещение)
Undelete (восстановление)

При изменение значения некого объекта записывается старое значение, а вместо него также изменяется новое значение. И снова, данное событие будет вырабатываться только для событий, перечисленных в SACL. После того как аудит включён, в журналах безопасности можно обнаружить такие события:

Таблица 18-2. События в журнале безопасности при включённом аудите изменений в службе AD
Идентификатор события	Сообщение события
`5136`	A directory service object was modified. (Объект службы каталога был изменён.)
`5137`	A directory service object was created. (Объект службы каталога был создан.)
`5138`	A directory service object was undeleted. (Объект службы каталога был восстановлен.)
`5139`	A directory service object was moved. (Объект службы каталога был перемещён.)
`5141`	A directory service object was deleted. (Объект службы каталога был удалён.)

Аудит репликации службы AD

Эта категория регистрирует события при начале и завершении репликации между двумя контроллерами домена. При включённом аудите мы можем отыскать такие события в соответствующих журналах:

Таблица 18-3. События в журнале безопасности при включённом аудите репликации службы AD
Идентификатор события	Сообщение события
`4932`	Synchronization of a replica of an AD naming context has begun. (Начата синхронизация реплики контекста имён AD.)
`4933`	Synchronization of a replica of an AD naming context has ended. (Завершена синхронизация реплики контекста имён AD.)

Аудит подробностей репликации Службы каталога

Данная категория записывает подробные сведения относительно реплицируемых данных между контроллерами домена. При включённом аудите будет вырабатываться большой объём событий и это будет полезно для устранения проблем репликации. Он будет регистрировать такие типы событий:

Таблица 18-4. События в журнале безопасности при включённом аудите подробностей репликации службы AD
Идентификатор события	Сообщение события
`4928`	An AD replica source naming context was established. (Был установлен источник реплики контекста имён AD.)
`4929`	An AD replica source naming context was removed. (Был удалён источник реплики контекста имён AD.)
`4930`	An AD replica source naming context was modified. (Был изменён источник реплики контекста имён AD.)
`4931`	An AD replica destination naming context was modified. (Был изменён получатель реплики контекста имён AD.)
`4934`	Attributes of an AD object were replicated. (Атрибуты объекта AD были реплицированы.)
`4935`	Replication failure start. (Запущен отказ репликации.)
`4936`	Replication failure end. (Завершё отказ репликации.)
`4937`	A lingering object was removed from a replica.. (Затянувший репликацию объект был удалён из реплики.)

Демонстрация аудита AD

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

Просмотр событий

Обозреватель событий можно запросто открыть, исполнив eventvwr.msc. Ту же самую оснастку MMC можно также применить для подключения к некому удалённому компьютеру при помощи варианта Connect to Another Computer..., как это выделено в следующем снимке экрана:

Рисунок 18-4

Мы можем упростить это, создав в Диспетчере сервера (Server Manager группу серверов. Группа серверов позволит нам запускать аналогичные роли сервера или действовать как часть некой распределённой системы.

Прежде чем мы двинемся далее и создадим группы серверов, нам следует сделать замечание относительно следующих сведений:

Нам потребуется некая учётная запись, которая имеет полномочия администратора для всех участвующих серверов чтобы создавать группы серверов и применять группы серверов.
Нам требуется включить WinRM (Windows Remote Management). После Windows Server 2012, WinRM включается по умолчанию. Существующие настройки WinRM можно просмотреть при помощи команды PowerShell winrm get winrm/config. Если они не включены, мы можем их включить воспользовавшись командой winrm quickconfig.
Даже когда мы зарегистрированы в качестве администратора домена или администратора предприятия, по умолчанию, не допускается сбор событий с удалённых компьютеров. Для выполнения этого нам требуется добавить некую учётную запись компьютера коллектора (тот сервер, в котором создаётся данная группа сервера) в группу Event Log Readers. Это встроенная локальная группа. Участники этой группы могут считывать журналы событий со своей локальной машины. Мы можем добавить некую учётную запись компьютера в эту группу при помощи следующей команды:
```
Add-ADGroupMember –identity 'Event Log Readers' –members REBELNET-PDC01$
 	   
```
Замечание

REBELNET-PDC01 можно заменить установленной учётной записью компьютера коллектора.
Для создания группы сервера, проследуйте в Диспетчер сервера (Server Manager) в своей инструментальной панели и выберите Создать новую группу (Create a server group), как это показано на следующем снимке экрана:

Рисунок 18-5
Во вновь полученном окне мы можем предоставить название для этой группы и добавить в созданную группу участников. Это предоставит различные методы для выбора чтобы выполнять поиск таких участников, как это показано на снимке экрана ниже:

Рисунок 18-6
После создания группы вы можете получать к ней доступ при помощи панели с левой стороны в Диспетчере сервера (Server Manager). Внутри этого окна группы имеется отдельный раздел с названием Выбранное (EVENTS). Когда мы перемещаемся по участникам, он будет отображать нам связанные с каждым участником события в этом окне событий, как это показано на снимке экрана внизу:

Рисунок 18-7

Мы можем настраивать данные этого события и менять их следующим образом:

Уровни продолжительности события
Временные кадры события
Файлы журнала событий, в которые будут получаться собираемые данные, как это показано на приводимом экране:

Рисунок 18-8

Наш следующий снимок экрана поясняет как мы можем настраивать как мы можем настраивать данные события при помощи различных параметров:

Рисунок 18-9

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

Рисунок 18-10

Ещё один наш снимок экрана показывает как после создания единожды такого запроса, к нему можно обращаться всякий раз, когда это потребуется:

Рисунок 18-11

Настройка подписок на события

Обозреватель событий содержит большое число разнообразных записей событий. Может иметься несколько тысяч событий в день. Даже когда событие и предоставляет какие- то полезные сведения, нам не требуется проходить их абсолютно все когда мы заинтересованы в устранении неисправности конкретного приложения или осуществления аудита службы. Существуют конкретные события, относящиеся ко всяким ролям сервера, приложениям, службам и системным компонентам. При некоторых обстоятельствах, когда нам требуется аудит или устранение неисправности, нам требуется просмотреть события на множестве компьютеров. Обозреватель событий позволяет нам подключаться за раз только к одному компьютеру в определённый момент времени. Это может быть локальный или удалённый компьютер. Подписки на события позволяют нам собирать журналы событий с удалённых компьютеров и просматривать их в одной консоли.

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

Включить WinRM.
Добавить некую учётную запись компьютера коллектора в соответствующую группу Event Log Readers.

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

После того как удовлетворены предварительные требования, выполните такую последовательность:

Зарегистрируйтесь в Сервере коллектора.
Откройте Обозреватель событий и проследуйте в Actions | Create Subscription.
В полученном новом окне введите следующие подробности:
- Subscription name: Название этого задания подписки.
- Destination log: Тот файл журнала, в котором собираются события, которые должны появляться. По умолчанию это файл журнала Forwarded Events. Мы можем выбирать любой доступный в ниспадающем меню файл журнала, как это показано на следующем снимке экрана:
  
  Рисунок 18-12
- Collector initiated: Здесь мы можем перечислить все исходные компьютеры. Это не соединение один- к- одному. Может иметься любое число компьютеров, как показано на снимке экрана внизу:
  
  Рисунок 18-13
- Source computer initiated: Позволяет вам определять подписку без задания необходимых исходных компьютеров. Далее исходные компьютеры будут определяться пр помощи установок групповой политики, находящейся в Computer Configuration | Policies | Administrative Templates | Windows Components | Event Forwarding | Configure Target Subscription Manager.
  
  Здесь следует добавлять соответствующий коллектор в формате Server=http://<eventcollector FQDN>:5985/wsman/SubscriptionManager/WEC,Refresh=10.
- Event to collect: Применяя данный параметр мы можем определять какие события должны выбираться с исходных компьютеров. Оно аналогично обычному окну фильтрации событий, как мы можем видеть на следующем снимке экрана:
  
  Рисунок 18-14
- Change user account or configure advanced settings: В этом параметре мы можем задать некую отдельную учётную запись, которую можно применять коллектором для выделения событий с исходных компьютеров. Он также даёт нам параметры для оптимизации настроек доставки события. Это важно при большом числе собираемых событий. Некий образец можно увидеть на следующем снимке экрана:
  
  Рисунок 18-15

Журналы событий безопасности из контроллеров домена

Для сбора журналов безопасности с удалённых контроллеров домена нам требуется добавить некую учётную запись сетевой службы в привилегии данного журнала событий безопасности для доступа к этому каналу. Это обусловлено тем, что сама служба WinRM запущена под определённой учётной записью сетевой службы. Это можно выполнить при помощи такого кода:


wevtutil sl security /ca:'O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)'

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20) содержит настройки полномочий чтения (READ) для учётной записи сетевой службы (A;;0x1;;;). В нашем предыдущем коде указано значение SID для учётной записи необходимой сетевой службы (S-1-5-20) и значение доступа к необходимому каналу (O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)). После того как мы это выполним, через несколько минут мы можем наблюдать получаемые Forwarded Events (Передаваемые события).

Включение расширенных политик аудита безопасности

Как мы видели ранее, для успешного аудита нам требуется иметь настроенным некий SACL под соответствующие объекты AD. Если нет никакой записи SACL, для такого объекта не будут вырабатываться никакие события. Чтобы настроить необходимый SACL осуществите следующие шаги:

Откройте Active Directory Users and Computers.
Кликните по View | Advanced Features.
Щёлкните правой кнопкой по необходимому OU или тому объекту, который мы желаете включить для аудита. Затем кликните по Properties. В своём примере я использую контейнер самого корня, поскольку я желаю разрешить его глобально.
Кликните по появившейся закладке Security, а вслед за этим по Advanced.
Кликните по закладке Auditing, а потом по кнопке Add для добавления некого нового принципа безопасности в полученном SACL. В нашем сценарии я применяю Everyone, поскольку я желаю выполнять аудит всего.
Для данного Type я выбрал тип события Success. Кроме того, я применил его к This object and all descendant objects, как это можно видеть на следующем снимке экрана:

Рисунок 18-16

После размещения логического элемента SACL мы способны включить настройку расширенной политики аудита. Для этого предпримите такие шаги:

Пройдите в Group Policy Management.
В соответствующем MMC {gpedit.msc} раскройте необходимый Domain Controllers OU.
Кликните правой кнопкой по Default Domain Controller Policy и выберите Edit.
Затем переместитесь в Computer Configuration | Policies | Windows Settings | Security Settings | Advanced Audit Policy Configuration | Audit Policies.
Здесь мы можем обнаружить 10 категорий аудита. В данной демонстрации мы намерены выполнять аудит только DS Access.
Перейдите к DS Access и дважды кликните по записи Subcategory. Для включения аудита выберите Configure the following audit events, а затем выберите те события, для которых вы бы хотели выполнять аудит. Рекомендуется выполнять аудит как для Success, так и для Failure, что отображено на следующем снимке экрана:

Рисунок 18-17

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

Рисунок 18-18

После того как групповая политика успешно применена, она начнёт регистрировать новые события согласно установленной политике аудита.

Принудительный расширенный аудит

Вплоть до Windows Server 2008 существовало девять основных категорий и подчинённых категорий аудита. Они продолжают оставаться и под Windows Server 2016. Рекомендуется впредь не смешивать их и применять вместо них исключительно современные. Мы можем принуждать свою систему применять только современные настройки политик аудита когда к той же самой категории применимы наследуемые настройки политики.

Это можно сделать включив соответствующие установки Групповой политики в Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings (Аудит: Принудительно применять настройки политик аудита - Windows Vista или последующие версии - для перекрытия настроек категории политик аудита).

Просмотр событий с помощью PowerShell

Для обзора журналов событий или их фильтрации в локальных или удалённых компьютерах мы также можем применять команды PowerShell без каких бы то ни было дополнительных настроек службы. Первейшим cmdlet, который мы можем использовать для этой задачи выступает Get-EventLog, как это показано в примере ниже:


Get-EventLog -List

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


Get-EventLog -LogName 'Directory Service' | fl

Эта предыдущая команда перечислит все события в соответствующем файле журнала Directory Service. Мы также можем ограничить подлежащих перечислению общее число событий. В качестве примера нам могут требоваться лишь самые последние 5 событий из своего файла журнала Directory Service и мы можем воспользоваться такой командой:


Get-EventLog -Newest 5 -LogName 'Directory Service'

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


Get-EventLog -Newest 5 -LogName 'Directory Service' -EntryType Error

Наша предыдущая команда перечислит самые первые 5 ошибок из файла журнала Directory Service. К тому же мы можем добавить некий временной придел для дальнейшей фильтрации таким манером:


Get-EventLog -Newest 5 -LogName 'Directory Service' -EntryType Error –After (Get-Date).AddDays(-1)

Наша предыдущая команда выведет перечень событий с ошибкой, имеющей тип Error в пределах последних 24 часов из соответствующего файла Directory Service. Мы также способны следующим образом получать и события с удалённого компьютера:


Get-EventLog -Newest 5 -LogName 'Directory Service' -ComputerName 'REBEL-SRV01' | fl -Property *

Наша предыдущая команда перечислит самые первые 5 событий из файла журнала Directory Service с удалённого компьютера REBEL-SRV01, как это показано на снимке экрана ниже:

Рисунок 18-19

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


Get-EventLog -Newest 5 -LogName 'Directory Service' -ComputerName "localhost","REBEL-SRV01"

Наша предыдущая команда перечислит все записи журнала с нашего локального компьютера и с удалённого компьютера REBEL-SRV01. Когда дело доходит до фильтрации, мы можем и далее фильтровать события, применяя надлежащий источник событий так:


Get-EventLog -LogName 'Directory Service' -Source "NTDS KCC"

Предыдущая команда перечислит события из источника NTDS KCC. Это также позволит нам выполнять поиск определённых идентификаторов событий, как это показано в нашем следующем примере:


Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 1000}

Наша предыдущая команда перечислит события с eventID равным 1000.

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

Microsoft ATA

Если и появляется взлом инфраструктуры идентификации, порой может потребоваться продолжительное время для его выявления по таким причинам:

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

Microsoft построил AD и сопровождает его к настоящему времени более 20 лет. Многие инженеры ежедневно работают с этим продуктом для выполнения последующих улучшений. Каждый день они имеют дело с квитанциями, относящимися к связанным с инфраструктурой AD проблемами, включая безопасность. У них к тому же имеется Azure AD, которую люди используют через открытые сетевые среды. Поэтому если кто- то и знает соответствующие угрозы входам и выходам безопасности инфраструктуры идентификации, так это должен быть сам Microsoft. Основываясь на том гигантском объёме данных и знаний относительно угроз инфраструктуре идентификации, Microsoft продолжает вводить новые инструменты и службы для защиты локальных, исключительно облачных и гибридных инфраструктур идентификации. Microsoft ATA также выступает одним из таких инструментов, который предоставляет некий простой, быстрый и точный способ выявления угроз инфраструктуре идентификации на некой ранней стадии отлавливая подозрительных пользователей и активности устройств при помощи встроенного интеллекта. Он также предоставляет ясные сведения в виде уведомлений электронной почтой и обзором временного ряда, причём через веб интерфейс.

Что такое Microsoft ATA?

Microsoft ATA является некой локальной платформой, способствующей нам в защите нашей инфраструктуры идентификации от современных целевых атак путём автоматического анализа, изучения и выявления обычного и не естественного поведения (со стороны пользователей, устройств и ресурсов). Он также применяет технологию глубокого анализа пакетов, а также данные из дополнительных источников, таких как События, для выявления угроз в реальном масштабе времени.

Преимущества ATA

Минимум настроек: ATA имеет необходимый встроенный интеллект безопасности. Следовательно нет нужды для настройки правил или политик по выявлению угроз безопасности. Его настройка достаточно прямолинейна. Сопровождающая его поддержка также минимальна.
Простые уведомления: При использовании ATA больше нет дополнительных отчётов и журналов для анализа. Система сама по себе выполняет весь анализ сведений и информирует нас о критических уведомлениях, либо в виде сообщений электронной почты, или в виде некой временной линии атак через свой веб интерфейс. Если вы работали с такими продуктами как SCOM (System Center Operation Manager, Диспетчер работы Системного центра), вы можете понимать как чувствительные уведомления способны отвлекать вас от реальных проблем. ATA минимизирует неверные уведомления и позволяет персоналу в точности знать то что они желают знать.
Снабжена знаниями для выявления появляющихся в отрасли угроз: Имеющийся диаграмма безопасности Microsoft постоянно усиливается различными источниками сведений, которые позволяют нам выявлять проблемы безопасности в инфраструктурах идентификации по мере их возникновения. Такие находки будут применяться ATA и это гарантирует более быстрое выявление по сравнению с традиционными инструментами безопасности.
Поддержка мобильности: ATA не волнует будут ли устройства и пользователи подключаться из внутренней или из внешней сетевой среды; когда вовлечены аутентификация и авторизация, они трактуют все подключения как равнозначные. Нет никаких изменений в настройках, необходимых для отслеживания подключений из внешних сетевых сред.

Какие угрозы выявляет ATA?

Вот типы угроз, которые способен определять ATA:

Изыскание применения перечислений учётных записей
Перечисление сетевых сеансов
Разведка использования DNS
Зондирование применения перечисления DS
Прямые силовые атаки
Выставление чувствительных учётных записей в аутентификации открытым текстом
Службы, выставляющие учётные записи с аутентификацией открытым текстом
Подозрительные действия с привлекательными учётными записями
Необычные реализации протокола
Защита от вредоносных данных через запрос персональных данных
Необычное поведение
Атаки передачи значения квитанции (Pass-the-ticket)
Атаки передачи значения хэша (Pass-the-hash)
Атаки обхода значения кэша (Overpass-the-hash)
Эксплуатация MS14-068
Эксплуатация MS11-013
Ключ скелета вредоносной программы
Золотые квитанции
Удалённое исполнение
Вредоносные запросы репликаций

Компоненты ATA

Имеются три компоненты ATA, вовлечённые в развёртывание:

Центр ATA
Шлюз ATA
Облегчённый шлюз ATA ( ATA Lightweight Gateway)

Центр ATA

Именно он выступает основным компонентом общего развёртывания ATA. Центр ATA выполняет такие вещи:

Настройку шлюза ATA.
Получение синтаксически разобранного обмена Шлюзов ATA и Облегчённых шлюзов ATA.
Выявляет вызывающие подозрения действия.
Запускает алгоритмы поведения машинного обучения ATA на предмет определения необычного поведения.
Запускает разнообразные детерменированные алгоритмы выявления современных атак на основе имеющейся цепочки уничтожения атак.
Пользователи могут использовать имеющуюся веб консоль для обзора временной линии атак, настроек установок и уведомлений.
Установка настроек уведомлений по электронной почте.

Такой Центр ATA рекомендуется устанавливать на неком обособленном сервере. Для одного леса рекомендуется один Центр ATA. Настройки между лесами не поддерживаются.

Шлюз ATA

Шлюз ATA является неким обособленным сервером, который отслеживает обмен контроллера домена при помощи мониторинга порта. Настройки мониторинга порта зависят от имеющегося для вашего применения решения визуализации. Если он реализован как физически обособленный, он требует изменений уровня коммутатора.

Облегчённый шлюз ATA

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

Оба шлюза выполняют следующие вещи:

Перехватывают и инспектируют сетевой обмен Контроллера домена.
Получают События Windows от различных источников данных, таких как SIEM (Security information and event management , Управление сведениями и событиями безопасности), серверов syslog, а также WEF (Windows Event Forwarding, Передачи Событий Windows).
Выполняет выборку сведений относительно пользователей и компьютеров из домена AD.
Осуществляет разборку логических сетевых элементов (пользователей, групп и компьютеров).
Передаёт существенные данные в свой Центр ATA.

Развёртывание ATA

Развёртывание ATA поддерживает три топологии:

Только с Шлюзом ATA: В этом режиме обмен AD просто перехватывается имеющимся Шлюзом ATA. Все контроллеры домена передают свой обмен в установленный шлюз посредством зеркалирования порта.
Только с Облегчённым шлюзом ATA: В таком режиме применяется только Облегчённый шлюз ATA. Этот компонент следует установить в абсолютно всех контроллерах домена.
Смешанный режим Шлюза ATA и Облегчённого шлюза ATA: При данном режиме будут использоваться оба типа Шлюзов. Но при этом один Контроллер домена должен применять лишь один компонент Шлюзов.

Предварительные требования развёртывания ATA

Прежде чем запускать развёртывание ATA, следует выполнить такие предварительные требования:

Самую последнюю установку файлов ATA.
Допустимую лицензию ATA.
Учётную запись Администратора домена или Администратора предприятия для установки как Центра ATA, так и Шлюза ATA.
Некая учётная запись с доступом по чтению для всех объектов в AD.
Центр ATA требует как минимум Windows Server 2012 R2 с самыми последними обновлениями. Рекомендуется иметь по крайней мере 4ГБ ОЗУ и 2 ядра ЦПУ.
Центр ATA обязан иметь дополнительный адрес IP для своей консоли.
Облегчённый шлюз ATA минимально требует Windows Server 2012 R2 с самыми последними обновлениями. Рекомендуется применять как минимум 6ГБ ОЗУ и 2 ядра ЦПУ.
Для Шлюза ATA и Центра ATA должны применяться сертификаты SSL. Для упрощения установки всё ещё допускается применение самостоятельно подписываемых сертификатов, которые впоследствии могут быть заменены общедоступным SSL или выпускаемыми внутренним CA сертификатами.

Демонстрация Microsoft ATA

В этом разделе я намерен продемонстрировать как установить ATA Microsoft. В своей демонстрационной среде мы выполним следующее:

Функциональные уровни домена и леса установлены в Windows Server 2016.
Будет применяться лишь Облегчённый шлюз ATA. Все контроллеры домена будут иметь установленным некий шлюз.
Наши Центр ATA и Облегчённый шлюз ATA будут устанавливаться в системах Windows Server 2016.

Установка ATA центра

Сам Центр ATA может быть развёрнут при помощи такой последовательности:

Зарегистрироваться в выбранном сервере в качестве Администратора домена или предприятия.
Запустить файл setup.exe Центра ATA.
В самом первом окне выберите подходящий язык и кликните Next.
Примите лицензионное соглашение и кликните Next для продолжения.
Затем вы будете запрошены относительно того как бы вы желали узнавать об обновлениях. Я рекомендую применять для этого Обновления Microsoft. Выберите вариант Use Microsoft Update when I check for updates (Для проверки обновлений использовать Обновления Microsoft) и затем кликните Next.
После этого в следующем окне мы можем задать Installation Path, Database Data Path своего приложения (ATA применяет MongoDB), Center Service IP Address: Port, Center Service SSL Certificate и Console IP Address. По окончанию этих корректировок нажмите Install для начала установки, как это показано на снимке экрана ниже:

Рисунок 18-20
По завершению установки вам будет предоставлена возможность запуска полученного Центра ATA.
После запуска Центра ATA зарегистрируйтесь в нём применяя ту учётную запись, которую вы использовали для его установки. Она будет установленной по умолчанию учётной записью Администратора ATA. В этой системе впоследствии вы сможете добавить дополнительные учётные записи Администратора.
После того как вы зарегистрировались, вы получите некое окно для предоставления сведений учётной записи и домена для подключения к AD. Эта учётная запись пользователя работает как обычная учётная запись сервера. Не требуются никакие дополнительные полномочия (за исключением полномочий на чтение всех объектов AD). После ввода подробностей учётной записи кликните по вариантуTest connection для проверки установленного соединения , а затем кликните по Save, как это показано на снимке экрана ниже:

Рисунок 18-21
Это завершает начальную настройку Центра ATA - нашим следующим шагом будет получение установленным необходимого Облегчённого шлюза ATA.

Установка облегчённого шлюза ATA

Установка Облегчённого шлюза ATA проста. Мы можем установить его воспользовавшись такой последовательностью:

Зарегистрироваться в соответствующем Контроллере домена в качестве Администратора домена или предприятия.
Запустить IE {или другой браузер} и подключиться к URI своего Центра ATA.
Зарегистрироваться в Центре ATA в качестве Администратора как на приведённом ниже снимке экрана:

Рисунок 18-22
При вашей самой первой регистрации это предоставит вам приводимую далее страница. Кликните по Download gateway setup and install the first Gateway (Выгрузка установки Шлюза и установка самого первого Шлюза), как иллюстрирует снимок экрана ниже.

Рисунок 18-23
Затем это предоставляет вам возможность Download Gateway Setup (Выгрузки установки шлюза). Кликните по имеющейся кнопке для начала, на которую указывает стрелка на следующем снимке экрана:

Рисунок 18-24
По завершению выгрузки раскройте полученный файл ZIP и запустите соответствующий файл Setup.exe Шлюза ATA Microsoft.
В самом начальном окне выберите подходящий язык и кликните по Next для продолжения.
В своём следующем окне будет представлено подтверждение относительно Gateway deployment type (Тип развёртывания шлюза). По умолчанию оно указывает на Lightweight Gateway (Облегчённый шлюз). Кликните по Next для продолжения установки, как показано на следующем снимке экрана:

Рисунок 18-25
В своём следующем окне Installation Path, Gateway Service SSL Certificate (Установка Пути, SSL сертификата Службы шлюза) и подробностей учётной записи для регистрации этого Шлюза в установленном Центре ATA. Данная учётная запись должна быть участницей группы administrator ATA. После набора своих сведений кликните по Install для начала установки, как показано на снимке экрана ниже:

Рисунок 18-26
По завершению установки мы сможем обнаружить Шлюз успешно соединённым с нашим Центром ATA, как это показано на снимке экрана внизу:

Рисунок 18-27

Это завершает начальное развёртывание ATA - он готов к работе.

Проверка ATA

Самый простой способ проверки функционирования ATA состоит в имитации атаки с разновидностью разведки DNS следующим образом:

Зарегистрируйтесь в каком- нибудь компьютере домена.
Откройте Приглашение командной строки, наберите nslookup – REBELNET - PDC01.therebeladmin.com и нажмите Enter. Указанное здесь имя сервера следует заменить каким- то FQDN (fully qualified domain name) Контроллера домена.
Затем наберите ls live.com.
Потом зарегистрируйтесь в Центре ATA и проверьте имеющуюся временную линию. Там мы можем отметить выявленное событие, как на показанном далее снимке экрана:

Рисунок 18-28
Это предоставляет подробное объяснение относительно той проблемы с тем, чтобы инженеры были способны запросто её понять. Эти события также можно экспортировать в виде некого файла Microsoft Excel.
ATA также позволяет нам отправлять уведомления в виде электронных писем. Такую настройку можно сделать при помощи ATA Center | Configuration | Mail Server Settings and Notification Settings (Установок Сервера электронной почты и уведомлений), как это отображено на следующем снимке экрана:

Рисунок 18-29

Как мы можем видеть, сам процесс установки и настройки ATA достаточно прост. Однако те преимущества, которые она предоставит, экстраординарны. Этот продукт только сообщает о возникающих угрозах в некой среде AD. Исправление и предотвращение подобных отчётов об угрозах всё ещё зависит от навыков инженеров.

Монитор Azure

До сих пор мы изучали инструменты, которые мы можем применять для мониторинга локальной среды AD. Microsoft также имеет решения для отслеживания прочих приложений и систем. Прекрасным примером этого является SCOM. Он может применяться для отслеживания приложений, служб, операционных систем, оборудования и сетевых устройств Windows. Если вы когда либо применяли какой- нибудь продукт системного центра, вы уже знаете насколько сложно его настраивать, применять и сопровождать. SCOM также способен отслеживать имеющуюся текущую жизнеспособность установленной среды AD. Это достойный инструмент, но я не думаю что он подходит для мониторинга современных инфраструктур.

Microsoft уже осознал это и ввёл Монитор Azure для предоставления всеобъемлющего решения по сбору, анализу и представлению приложений, служб и системных данных, получаемых из локальных и облачных сред. Первоначально был известен под названием OMS (Operations Management Suite). Это основанное целиком на облаке решение. Монитор Azure сбор и анализ измерений и регистрационных сведений от различных источников, таких как приложения, операционные системы, ресурсы Azure, подписки Azure, а также арендаторов Azure. Metrics (Измерения) являются численными значениями, описываемыми как определённое состояние службы, системы или приложения в определённый момент времени. В качестве примера, конкретное состояние (то есть поднято или остановлено) службы в некий заданный момент времени является Измерением. Оно определённо и просто для анализа. Метрики в основном применяются со сведениями производительности. Logs (Регистрационные данные) содержат сведения событий. Этот тип данных подлежит анализу при помощи запросов для фильтрации определённых данных.

Преимущества Монитора Azure

Монитор Azure включает такие преимущества, которые дополнительно увеличивают его значимость:

Минимум настройки и сопровождения: Если вы ранее работали с SCOM, вы можете представлять как много различных компонентов нам требуется настраивать, например, управление серверами, SQL серверами, серверами шлюзов, сертификатами авторизации и тому подобным. Но применяя Монитор Azure всё что нам требуется, это некая подписка и самая начальная настройка агентов мониторинга или определённого шлюза; больше нет никакой рутины сложного сопровождения.
Он масштабируем: Последние отчёты Microsoft показывают, что Монитор Azure уже применяется более чем 50 000 пользователей. Было собрано 20ПБ данных и в неделю обрабатывалось более 188 миллионов запросов. Применяя решения на основе облака нам больше не требуется беспокоиться относительно ресурсов при расширении. Сама подписка основывается на тех свойствах и тех объёмах данных, которые вы загружаете. Вам не надо платить за вычислительную мощность. Я уверен, что Microsoft далёк от исчерпания ресурсов!

Интеграция с SCOM: Монитор Azure целиком поддерживает интеграцию с SCOM. Это позволяет инженерам определять какие системы и сведения следует анализировать Монитором Azure. Это также делает возможной гладкую поэтапную миграцию с SCOM в Монитор Azure. И Монитор Azure, и SCOM применяют один и тот же агент (Агент мониторинга Microsoft), а следовательно настройка стороны клиента минимальна.

	Замечание
	Некоторые составляющие Монитора Azure, такие как монитор сетевой производительности, WireData 2.0 и Service Map требуют дополнительных файлов агента, системных изменений и прямого подключения к Монитору Azure.

Частые обновления свойств: Microsoft выпускает новую версию Системного центра раз в четыре года. Однако обновления Монитора Azure регулярны и новые службы поступают более часто. Это позволяет Microsoft быстрее решать требования отрасли.
Инструментальные панели: Одним из величайших свойств Монитора Azure является его богатство визуализации сведений. SCOM в целом ориентированная на уведомления система и имеет очень ограниченные возможности визуализации. Визуализация данных способствует инженерам в более быстром доступе к существенным данным. Они к тому же позволяют нам создавать индивидуальные заголовки на основе своих собственных запросов. Такая инструментальная панель способна представлять Изменения и Регистрационные данные.
Обзоры: Обзоры применяются для визуализации регистрационных сведений. Мы можем создавать свой собственный обзор для отображения особых данных от некого приложения, системы или службы на основе запроса. Если потребуется, обзоры также можно добавлять в имеющуюся инструментальную панель.

Монитор Azure в гибридной среде

В некой гибридной среде мы способны интегрировать локальные системы с Монитором Azure применяя три таких метода:

Агент аналитики регистраций: Этот агент требуется устанавливать абсолютно во всех системах и он будет напрямую соединяться с Монитором Azure для выгрузки получаемых данных и выполнения запросов. Эта система общается с Монитором Azure через порт 443.
SCOM: Если у вас уже имеется в вашей инфраструктуре установленный и настроенный SCOM, вы можете отправлять сведения через его шлюз Регистрационной аналитики (Log Analytics). Дополнительные сведения доступны по ссылке.
Шлюз Регистрационной аналитики (Log analytics gateway): В наши дни Монитор Azure поддерживает сбор сведений и запуск запросов через свой собственный шлюз. Он работает аналогично шлюзам SCOM. Не всем системам требуется иметь прямое подключение к Монитору Azure, а имеющийся шлюз Регистрационной аналитики будет собирать и выгружать значимые сведения из своей инфраструктуры. Дополнительную информацию относительно шлюза Регистрационной аналитики можно найти по ссылке.

Какие преимущества будут иметься в AD?

В некой среде SCOM мы способны отслеживать компоненты и службы AD применяя важные пакеты управления. Они собирают гигантский объём сведений. Однако для выявления потенциальных проблем инженерам требуется анализировать такие получаемые данные. Монитор Azure предоставляет два пакета решений, которые собирают сведения из некой среды AD и анализируют их за вас. После анализа они будут визуализированы в дружественном пользователю виде. Они также предоставит вам суть того как исправить выявленные проблемы, а также предоставит руководства относительно того как улучшить производительность, безопасность и высокую доступность имеющейся среды следующим образом:

Проверка жизнеспособности AD (AD Health Check): Это решение будет анализировать значения рисков и жизнеспособности сред AD через регулярные промежутки времени. Оно предоставит перечень рекомендаций для улучшения вашей имеющейся инфраструктуры AD.
Состояние репликации AD (AD Replication Status): Данное решение проводит анализ имеющегося состояния репликации вашей среды AD.

Демонстрация Монитора Azure

В этом разделе мы намерены изучить как мы можем отслеживать некую среду AD при помощи Монитора AD. Прежде чем начать, нам потребуются следующие элементы:

Действительная подписка Монитора Azure: Монитор Azure имеет различные уровни подписки. Какая именно является более подходящей зависит от объёма загружаемых данных и ваших политик сохранности сведений. Дополнительные сведения доступны по ссылке.
Непосредственное подключение к Монитору Azure: В эой демонстрации я намерен воспользоваться прямой интеграцией с Монитором Azure через своего агента Аналитик журнала (Log Analytics).
Учётная запись администратора: Для установки необходимого агента в Контроллере домена нам требуется иметь полномочия Администратора домена.

Включение решений AD Монитора Azure

Самый первый этап настройки состоит во включении модулей AD в Мониторе Azure. Мы можем разрешить их, воспользовавшись такой последовательностью шагов:

Зарегистрируйтесь в портале Azure при помощи https://portal.azure.com/.

После этого кликните по Monitor, как это показано на следующем снимке экрана:

Рисунок 18-30

Совет

Прежде чем применять Монитор Azure вам необходимо получить действующую среду рабочего пространства Аналитик журнала (Log Analytics). Именно в нём вы определяете необходимые подробности подписки. В данной демонстрации вы уже обладаете действующей установкой рабочего пространства.

В своём следующем окне кликните по More, как это показано на снимке экрана ниже:

Рисунок 18-31
Затем во вновь полученном окне кликните по + Add.
Это перечислит все доступные решения. Отыщите Active Directory Health Check (Проверку жизнеспособности AD).
Это загрузит необходимую страницу решения. Для добавления этого решения в Монитор Azure кликните по Create, как это показано на идущем далее снимке экрана:

Рисунок 18-32
Пройдите те же самые шаги и добавьте решение AD Replication Status (Состояние репликации AD), как это отображено на снимке внизу:

Рисунок 18-33

Установка агентов аналитики журналов

Наш следующий этап конфигурирования состоит в установке необходимых агентов аналитик в своих контроллерах домена и их подключения к Монитору Azure. Это делается следующим образом:

Зарегистрируйтесь в своём контроллере домена в качестве Администратора домена.
Зарегистрируйтесь в портале Azure/
Проследуйте в All Services и затем отыщите Log Analytics workspaces.
Кликните по подходящему рабочему пространству в данном списке.
Затем пройдите в Advanced Settings, как это показано на следующем снимке экрана:

Рисунок 18-34
После этого перейдите в Windows Servers и кликните по Download Windows Agent (64 bit) для получения необходимого агента. Кроме того, выпишите идущие следом WORKSPACE ID и PRIMARY KEY, так как они потребуются в процессе установки этого агента, как показывает наш следующий снимок экрана:

Рисунок 18-35
После выгрузки необходимого агента запустите его от имени Администратора. В появившемся окне Agent Setup Options выберите вариант Connect the agent to Azure Log Analytics (OMS) и кликните по Next, как это показано на снимке экрана внизу:

Рисунок 18-36
В появляющемся следом окне предоставьте Workspace ID и Workspace Key. Кроме того, выберите подходящее Azure Cloud. Если вы расположены за посредником (прокси), вам следует в этом окне также задать и установки этого посредника. По завершению кликните по Next, как это показано на снимке экрана далее:

Рисунок 18-37
Это подводит к концу настройку вашего агента - пройдите последующие окна, оставляя в покое все выборы в значениях по умолчанию для завершения данной установки.
Через несколько минут, перейдя в Advanced Settings | Connected Sources | Windows Servers мы можем обнаружить приводимый ниже снимок экрана в котором вновь добавленные серверы подключены в качестве источников сведений:

Рисунок 18-38

Просмотр результатов анализа

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

Через несколько минут Монитор Azure начнёт сбор данных и визуализировать всё найденное.
Для просмотра полученных сведений, зарегистрируйтесь в портале Azure и проследуйте в Monitor, кликнув по More в разделе Insights.
Там мы можем обнаружить все связанные с добавленными нами решениями фрагменты. Когда мы кликаем по соответствующему фрагменту, он привнесёт нам свои сведения анализа, как это показывает следующий снимок экрана:

Рисунок 18-39
Как я уже пояснял ранее, он не просто отображает ошибки; он также предоставляет некие RECOMMENDATION по поводу того как исправить имеющиеся проблемы, что показано на снимке экрана внизу:

Рисунок 18-40

Я надеюсь, теперь вы обладаете базовыми сведениями относительно того как Монитор Azure отслеживает некую среду AD. Существует великое множество моментов, которые мы можем обнаружить при помощи Монитора Azure и очень сложно осветить все эти возможности в короткой главе. Я настоятельно призываю вас ознакомиться с доступной документацией по Монитору Azure, чтобы получить из неё всё самое необходимое.

Жизнеспособность соединения с Azure AD

В своей предыдущей главе мы изучили что из себя представляет Azure AD Connect и как он работает в гибридной среде Azure AD. Azure AD Connect отвечает за синхронизацию между Azure AD и локальным AD. Следовательно важно отслеживать состояние жизнеспособности службы Azure AD Connect чтобы быть уверенным что он работает как ожидалось. В вычислительной инфраструктуре в определённый момент времени может быть активным лишь один экземпляр Azure AD Connect, поэтому на жизнеспособность данной службы оказывается большая нагрузка. Такая служба Azure AD Connect является службой Windows, поэтому для отслеживания состояния этой службы имеется множество инструментов, например SCOM и Монитор Azure. Однако даже когда эта служба поднята и запущена, это ещё не означает жизнеспособность синхронизации.

Для отслеживания жизнеспособности Azure AD Connect имеется служба Azure AD Connect Health, поставляемая в Azure AD Premium. Azure AD Connect Health способна выполнять мониторинг следующих типов ошибок синхронизации:

Дублирование атрибутов
Несоответствие данных
Отказы в достоверности данных
Большие атрибуты
Изменения федеративных доменов
Конфликты имеющихся ролей Администраторов
Прочие ошибки (которые не категоризованы)

Внутренние сведения Azure AD Connect Health собираются через агентов жизнеспособности. Имеются три типа агентов, применяемых Azure AD Connect Health:

Azure AD Connect (sync): Он устанавливается как часть Azure AD Connect. Данный агент будет получать сведения, относящиеся к Azure AD Connect, такие как состояние службы, правила синхронизации, название службы, время последней синхронизации, ошибки синхронизации и предупреждения.
Azure AD Connect Health Agent for Active Directory Federation Services (AD FS): Этот агент способен получать дополнительные сведения для отслеживания жизнеспособности Azure AD Connect в некой федеративной среде. Такой агент будет получать такие сведения, как общее число обработанных AD FS запросов, основанных на доверительной стороне запросов, применяемых запросами методов аутентификации, предупреждения, отказов в запросах и тому подобное.
Azure AD Connect Health Agent for Active Directory Domain Services (AD DS): Этот агент способен получать дополнительные сведения от некой локальной средф AD, которая будет предоставлять больше внутренней информации для выявления лежащих в основе каталога проблем в гибридной среде. Данный агент получает такие сведения как: уровни функционирования леса и домена, держатели роли FSMO (Flexible Single Master Operation), состояние репликации, число обработанных запросов аутентификации и тому подобное.

Предварительные требования

Для применения Azure AD Connect Health нам требуются такие предварительные условия:

Подписка Azure AD Premium.
Установленные на целевых компьютерах надлежащие агенты Azure AD Connect Health.
Исходящий TCP 443 для оконечных точек AZure с целевых серверов.
.
Установка PowerShell 4.0 или выше в целевых компьютерах.
Должны быть отключены FIPS (Federal Information Processing Standards, Стандарты обработки федеративных сведений).

Демонстрация

В этом разделе мы намерены рассмотреть работу Azure AD Connect Health. В своей демонстрационной среде у меня имеется установленной самая последняя версия Azure AD Connect. Azure AD Connect Health (sync) поставляется как его часть, что показано на снимке экрана ниже:

Рисунок 18-41

Однако я хочу установить Azure AD Connect Health Agent for AD DS для получения дополнительных сведений из своей локальной среды AD. Для этого выполните следующие шаги:

Зарегистрируйтесь в целевом компьютере в качестве Администратора домена/ предприятия.
Воспользовавшись https://portal.azure.com/ проследуйте в портал Azure и зарегистрируйтесь в нём в качестве глобального администратора.
Затем перейдите в Azure Active Directory | Azure AD Connect and click on Azure AD Connect Health, как это показано на снимке далее:

Рисунок 18-42
Во вновь полученном окне кликните по Download Azure AD Connect Health Agent for AD DS, как на снимке экрана далее:

Рисунок 18-43
После завершения выгрузки запустите ADHealthAddsAgentSetup.exe от имени Администратора.
Выполните эту установку, а затем подпишитесь применив учётную запись глобального администратора в окне регистрации, как это показано на следующем снимке экрана:

Рисунок 18-44

Позвольте своей системе завершить регистрацию агента, как показано на снимке экрана далее:

Рисунок 18-45

	Совет
	Если имеется размещённым посредник (прокси), нам придётся импортировать настройки этого посредника из Internet Explorer выполнив `Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings`.

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

Когла агенты начнут выдавать отчёты, мы можем выполнить просмотр Azure Active Directory Connect (Sync) в Sync errors и Sync services, как это отображено на следующем снимке экрана:

Рисунок 18-46

Следующая загруженная страница покажет самый высокий уровень состояния жизнеспособности соединения Azure AD.

Рисунок 18-47

На страницах ошибок мы можем наблюдать подробные описания событий.

Рисунок 18-48
Аналогично, к собранным в Azure AD Connect Health Agent for AD DS сведениям можно выполнить доступ через Active Directory Domain Services как это показывают последующие снимки экранов:

Рисунок 18-49

Загруженные страницы отображают значение общей жизнеспособности репликации.

Рисунок 18-50

Azure AD Connect Health в целом сосредоточен на мониторинге жизнеспособности синхронизации каталога. Дополнительные внутренние сведения, собираемые из агентов AD FS и AD DS в основном помогают устранять неисправности проблемы жизнеспособности синхронизации каталога. Тем не менее, жизнеспособность синхронизации не означает что у нас запущена жизнеспособная гибридная среда Azure AD. Это можно гарантировать только путём мониторинга угроз безопасности инфраструктуры идентификации. Microsoft обладает разнообразными службами, которые способны выполнять мониторинг угроз безопасности инфраструктуры идентификации. Хорошими примерами этого выступают Azure Security Center и Azure Sentinel. Я настоятельно рекомендую ознакомиться с этими решениями для дальнейшего улучшения общей жизнеспособности вашей инфраструктуры идентификации.

Выводы

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

В этой главе мы начали с рассмотрения инструментов локального Windows и тех методов, которые могут применяться для отслеживания и аудита сред AD. Прежде всего мы начали с инструментов GUI, а затем перешли к аудиту на основе PowerShell. Далее мы рассмотрели ATA Microsoft и то как он способен выявлять угрозы идентификации в инфраструктуре, которые невозможно выявлять обычными инструментами и методами. Позднее мы рассмотрели современный мониторинг на основании Облачного решения Microsoft и решения аналитик журналов, Монитора Azure. Воспользовавшись демонстрацией, я также пояснил как мы можем настраивать и отслеживать жизнеспособность конкретной среды AD. И наконец, последнее, но не менее важное, мы также изучили как Azure AD Connect Health способен помогать жизнеспособности синхронизации установленной гибридной среды Azure AD.

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

	Замечание
	`REBELNET-PDC01` можно заменить установленной учётной записью компьютера коллектора.