Дорогие хабровчане,
Предлагаем вашему вниманию переведенный на русский язык фрагмент книги Дон Джонса, MVP, титулованного специалиста и просто очень популярного в США автора.
Существует три “А” безопасности Active Directory (AD) – аутентификация, авторизация, аудит. В этом посте мы приведем фрагмент перевода из книги Don Jones “Active Directory Troubleshooting, Auditing, and Best Practices”, посвященный аудиту AD.
Цели штатных инструментов аудита
Цель аудита довольно тривиальна: отслеживать все, что кто-либо делает. В контексте AD это означает, что нужно отслеживать использования всех привилегий, таких как изменения членства в группах или разблокировка учетных записей пользователей. Также это означает, что необходимо фиксировать действия пользователей, такие как успешные и неудачные входы в систему. Посмотрим шире – и для Windows это означает, что аудит включает еще и доступ к файлам и папкам, равно как и изменения разрешений доступа к файлам.
Ваша цель при осуществлении аудита может отличаться от тех, которые достигаются в рамках архитектуры аудита операционной системы. Помните, что система аудита, используемая в Windows – включая AD, которая представляет собой копию архитектуры файловой системы, пришла к нам из ранних 90-х, когда появилась Windows NT. В то же время, в Microsoft тогда не могли предположить, что будут существовать организации с тысячами файловых серверов, сотнями контроллеров доменов и тысячами других серверов, на которых работают Exchange, SQL Server, SharePoint и другие бизнес-платформы. Мы будем рассматривать ниже то, что штатные инструменты аудита Windows не всегда масштабируемы в крупных инфраструктурах или даже для компаний среднего размера. Может быть, Вы хотели бы, чтобы каждое событие в ИТ-инфраструктуре фиксировалось системой аудита, однако это может создать проблемы в производительности, управлении и даже логистике. Поэтому давайте предположим, что Ваша цель – аудит всего, что происходит в ИТ-инфраструктуре, и посмотрим, чего можно добиться штатными средствами.
Штатная система аудита
Разрешения применяются к списку разграничительного контроля доступа (DACL). Каждый DACL состоит из одного или более элементов управления доступом (ACE). Каждый такой элемент содержит разрешение или запрет определенного набора разрешений по отношению к пользователю или группе. DACL представляет собой часть “авторизации” в модели трех А: AD аутентифицирует вас и дает маркер безопасности (security token), содержащий уникальный идентификатор безопасности (SID). Такой SID сравнивается с ACE в списке разграничительного контроля доступа (DACL), чтобы определить, какими разрешениями Вы обладаете при доступе к данным ресурсам.
Аудит работает схожим образом. Список управления доступом к объектам (SACL) состоит из одной или нескольких записей. Каждая запись обозначает определенное действие для определенной активности, совершенной пользователем или группой. SACL привязан к определенному ресурсу, такому как файл или объект директории, и когда осуществляется определенное действие с ресурсом, оно фиксируется в журнале. По умолчанию, существует возможность записывать в журнал действия типа “успех” и/или “отказ”. Это значит, что Вы можете выбрать, чтобы в журнале фиксировалась запись, когда кто-то успешно использовал свои разрешения или когда он пытался это сделать и ему было в этом отказано. На рисунке 1 показана конфигурация SACL для AD. Как Вы можете видеть, этот ресурс – Контроллеры доменов подразделения – настроен так, что фиксируются некоторые виды успешных действий членов группы “Everyone”. То есть, когда кто-нибудь успешно осуществляет эти действия, создается запись в журнале.
Рис.1: SACL в AD.
Какие действия подлежат аудиту зависит от того, с какими ресурсами Вы работаете. Например, рисунок 2 показывает SACL файловой системы, и Вы можете видеть, что доступны различные виды действий.
Рис.2: SACL файловой системы.
Здесь Вы можете выбрать, что подлежит аудиту, например, создание папок, чтение атрибутов, удаление файлов и тому подобное. Таким образом, каждый ресурс, может иметь свой собственный SACL. На практике, большинство из нас назначает SACL на достаточно высоком уровне иерархии и тем самым позволяет этим настройкам распространиться на объекты более низкого уровня через наследование. Поэтому управление SACL осуществляется в относительно небольшом количестве мест. Но мы все равно должны конфигурировать их хотя бы по одному на каждый сервер и на главную систему. Что это значит: каждому серверу нужен будет свой список управления доступа к объектам хотя бы в корне каждого логического диска, нам нужен будет отдельный список в корне AD и так и далее.
Другие продукты могут подпадать под эту схему. А могут и не подпадать. Например, Exchange Server используется подобную структуру для аудита, а вот SQL Server и SharePoint – нет. Однако здесь мы рассматриваем исключительно AD.
Когда действие, на которое настроен аудит, происходит, Windows генерирует запись аудита. Все подобные записи хранятся в журнале событий безопасности, который показан на рисунке 3. Проблема с подобным журналом заключается в том, что туда попадает каждое событие. Хотя это вроде бы и неплохо, чтобы все события хранились в одном месте, проблема заключается в том, что когда из него необходимо извлечь отдельные записи, то это становиться проблематичным. Еще раз, это происходит вследствие того, что у Microsoft довольно узкий взгляд на систему аудита Active Directory.
Рис. 3: Журнал событий безопасности.
На каждом Windows сервере находятся свои журналы событий безопасности (security event logs), включая контроллеры доменов. Хотя списки управления доступа к объектам в AD могут быть настроены на любом контроллере домена и в дальнейшем реплицированы на остальные, только контроллер домен, который обрабатывает данное действие, создаст о нем запись в журнале. В результате: есть централизованно сконфигурированная политика аудита, однако журналы аудита сильно рассредоточены.
На рисунке 4. показано, как эти записи аудита выглядят. Они часто включают “сырые” идентификаторы безопасности и другую неочевидную информацию. В этом примере показаны успешные подключения доменов, обработанные с помощью штатного протокола Kerberos. Имя пользователя и домена пустые в этом примере, однако обычно они заполнены.
Рис.4: Пример записи аудита.
Со временем в Microsoft стали решать проблемы, связанные с наличием лишь одного журнала, в котором находится так много информации. В Windows Vista и Windows Server 2008 были представлена параллельная архитектура журнала событий, которая делала проще процесс ведения собственного журнала для каждого продукта или технологии. Это всегда было возможно – журналы приложений, системы и безопасности дополнялись, например, журналами службы каталогов. Но эта новая архитектура стала более целостной по ряду причин. На рисунке 5 показаны старые и новые журналы.
Рис.5: Новые и старые журналы.
В отличие от списка разграничительного контроля доступа (DACL) список управления доступа к объектам (SACL) не сразу же используется операционной системой. SACL просто обозначает, какие действия подлежат аудиту; система аудита сама по себе также должна быть включена для того, чтобы события записывались в журналы. На рисунке 6 показано, где это обычно конфигурируется в объекте групповых политик.
Большинство организаций будет конфигурировать аудит в высокоуровневых объектах групповых политик, таких, которые применяются ко всем контроллерам доменов или даже ко всем серверам в домене. Обозначенный объект групповых политик относится к настройке политики аудита, которая включает в себя включение аудита для события входа в систему/подключений, действия по управлению учетными записями, доступ к AD и так и далее. Политика аудита, так же как и ресурсов SACL, должна быть настроена для того, чтобы генерировались желаемые события аудита.
Рис. 6: Настройка аудита в объекте групповых политик.
Здесь нужно быть внимательным. Не думаю, что Вы хотите включить аудит всех событий, не приняв во внимание последствия. Контроллер домена может генерировать тысячи событий о подключениях каждую минуту (например, когда утром все заходят на свои компьютеры), а создание такого количества событий требует вычислительной мощности. Если аудит всех этих событий действительно нужен, то Вам нужно будет увеличить размер контроллера домена, чтобы справиться с нагрузкой. То же самое нужно сделать и для файловых серверов: если в журнал будут заноситься все события об успешном доступе к файлам, нужно увеличить вычислительную мощность, чтобы справиться с нагрузкой.
Создание такого количества событий может довольно серьезно “забить” журнал событий. Как показано на рисунке 7, Вы наверняка захотите совместить политику аудита с хорошо спланированной политикой журнала событий, настройкой размеров журналов событий, действиям по откату и другими настройками, чтобы обеспечить согласованность нагрузки на работу системы.
Рис.7: Конфигурирование журнала событий в объекте групповых политик.
В отличие от журнала приложений, с которым Вы можете быть спокойны, когда он перезаписывается по мере заполнения, в журнале безопасности такого допустить нельзя, так как важная информация может быть потеряна. Поэтому Вы должны задать подходящий размер журнала и настроить процедуры регулярного архивирования и очищения журнала – в зависимости от нагрузки на журнал.
За что обычно критикуют штатные журналы событий Windows, так это за то, что они сильно рассредоточены. Например, администратор может изменить членство в группах на одном контроллере домена, подключиться ко второму контроллеру домена, чтобы использовать учетную запись в этой группе, и подключить к третьему контроллеру, чтобы сбросить это членство в группах. Все три события будут записаны в трех различных журналах событий безопасности, что усложняет процесс установления взаимосвязи между этими событиями.
Решение, которое Microsoft предложил этой проблеме в Windows Server 2008, стала переадресация журнала событий (event log forwarding). На рисунке 8 обозначено, как отдельные серверы пересылают события на центральный сервер, который собирает все события в свой собственный журнал.
Рис. 8: Переадресация журнала событий.
Как обозначено, эта функция может быть сконфигурирована в групповых политиках, что делает ее централизованно контролируемой. Этот подход все равно имеет существенные недостатки, которые мы будем обсуждать далее.
Вот таким образом построена штатная система аудита. Давайте теперь поговорим о том, как организации хотят использовать эту систему, и где им необходимы усовершенствованные функции.
Общие цели бизнеса для аудита изменений
В отличие от 90-х, когда была разработана Windows NT, большинство компаний сегодня являются объектами определенных политик безопасности. Во многих случаях, когда политика безопасности подразумевает еще и выполнение требований нормативов и законодательных актов. Эти требования могут включать обязанность осуществлять аудит всех успешных и неудачных действий, происходящий в ИТ-инфраструктуре, и генерируют значительное количество трафика.
Также важно, чтобы те пользователи (включая администраторов), действия которые фиксируются в записях аудита, не могли удалить записи из журнала событий. Организации также хотят, чтобы присутствовала возможность поиска, фильтрации и формирования отчетов по записям в журнале событий. Например, аудитор захотел увидеть запись аудита, которая соответствует изменению конфигурации политики аудита AD, а затем соотнести эти события с одобренными действиями. Что позволяет ему видеть, что в AD только те изменения, которые были согласованы и документированы. Организациям также надо использовать штатные инструменты аудита для разрешения проблем. Когда что-то пошло не так в IT-инфраструктуре, ответ на вопрос: “А что изменилось?” позволяет быстро решить проблему – и журналы аудита должны помогать в поиске ответа на этот вопрос быстро и эффективно. Так в чем же проявляются недостатки штатных инструментов аудита?
Недостатки штатных инструментов аудита
К сожалению, штатная система аудита не слишком хорошо себя зарекомендовала. В конечном счете, это не вина Microsoft – в конце концов, их работа не состоит в том, чтобы предугадывать любую потребность бизнеса, а скорее предоставлять платформу, на основе которой другие компании могут разрабатывать ПО, которое может удовлетворять специфические потребности бизнеса. Именно это они и сделали. Штатная система аудита представляет собой базовое решение, которое подходит для самых небольших организаций, которые вряд ли могут позволить себе приобрести дополнительные программы.
Цель №1 – аудит всех событий – однозначно осуществима с помощью Windows, хотя необходимо принимать во внимание размеры журналов и производительность работы сервера. Штатная архитектура журнала событий не является прозрачной, какой мы хотели бы ее видеть, и запись десятков тысяч событий в час однозначно окажет влияние на работу сервера.
Цель №2 – возможность внесения изменений в журнал – узкое место системы. К сожалению, практически невозможно исключить возможность очистки журнала администраторами. Вы можете это сделать, тонко настроив привилегии, создав специальные учетные записи для работы с журналами и так и далее, однако это сложно и для многих организаций непрактично.
Предположим, что Вы сделали это. Перед Вами встает цель №3 – централизованное формирование отчетов, оповещений и фильтрация событий. Переадресация журналов событий, даже если она происходит, не осуществляется в режиме реального времени, возможны существенные задержки. Но даже если Вы осуществляете переадресацию журнала событий, то вся информация сваливается в одно место, откуда ее можно вытащить с помощью примитивного Event Viewer. На рисунке 9 показаны возможности фильтрации штатных инструментов, и они, конечно же, примитивны.
Рис.9: Штатные инструменты фильтрации журнала событий.
Как показано на рисунке, Вы можете осуществлять фильтрацию по типам событий или по специальному тексту в описании событий, равно как и по другим критериям. Но возможность установления взаимосвязи между различными связанными событиями отсутствует.
Что же касается использования этих событий для решения проблем – что ж, удачи! Это, конечно же, возможно, однако обычно это выглядит так: “посмотрите в журнал, посмотрите, что обозначает идентификатор события, и определите, имеет ли это отношение к настоящей проблеме”. Достаточно сложно, чтобы штатный Event Viewer дал ответ на вопрос “Все изменения в AD за последние 4 часа”. Хотя в журнале будут отображаться события, связанные с этими изменениями – Вы ведь настроили политику аудита, чтобы их фиксировать – журнал событий не предназначен для того, чтобы выполнять задачу управления изменениями или их аудита. Это не аудит изменений в собственном значении этого термина, а аудит того факта, что кто-то сделал изменение.
Как показано на рисунке 10, в AD Windows Server 2008 стали фиксироваться значения “до” и “после” каждого изменения, что делает более пригодным для аудита изменений. Однако эта функция не слишком распространена в AD и найти нужные события в большом журнале все равно проблематично.
Рис.10: Улучшенный вид событий в Windows Server 2008.
В большинстве инфраструктур, эффективная политика аудита подразумевает использование решений сторонних разработчиков.
Возможности сторонних решений
Инструменты для аудита сторонних разработчиков имеют ряд преимуществ.
Во-первых, они лучше (и быстрее) выполняют сбор информации из различных журналов серверов в централизованном хранилище. Часто такое централизованное хранилище является базой данных SQL сервера, хотя отдельные инструменты могут пересылать события в режиме реального времени во внешний механизм ведения журналов, таких как syslog server, как это показано на рисунке 11.
Рис.11: Пересылка событий на syslog server
Суть в том, что события из Windows должны как можно быстрее извлекаться и перемещаться в отдельную систему, где бы они были защищены отличным от журнала событий способом. Базы данных в данном случае довольно популярный выбор, потому что они могут быть защищены и к ним можно обращаться со сложными запросами. Ну и конечно же с их помощью можно формировать отчеты. Поэтому большинство решений для аудита Active Directory собирает события в базу SQL Server, чтобы использовать возможности формирования отчетов через SQL Server Reporting Services.
Сторонние решения могут также использовать API, чтобы собирать информацию аудита – в дополнение к (или вместо) штатным журналам событий. Эти API часто дают более детализированную информацию, включая значения “до” и “после”. В некоторых случаях, использование API может даже снизить нагрузку на серверы.
Используя централизованное хранение данных, сторонние инструменты могут генерировать оповещения в режиме реального времени, формировать отчеты, архивировать записи о событиях, проводить анализ данных и их сопоставление.
