Обзор "Практических указаний по защите Active Directory" Microsoft

Сотрудникам группы реагирования на инциденты информационной безопасности (ГРИИБ) часто нужно ответить не только на вопросы о том, как, когда, где, по чьей вине произошел инцидент, но и на то, как организация может защитить себя от подобных инцидентов в будущем. Другими словами, нужно понять, какой урок был извлечен из инцидента, и какие можно дать рекомендации, основываясь на обнаруженных проблемах.

Новый документ от Microsoft, который называется "Практические указания по защите Active Directory" ("Best Practices for Securing Active Directory"), содержит большое количество информации и инструкций, которые сотрудники службы безопасности могут использовать для ответа на вышеперечисленные вопросы. Документ можно скачать по следующей ссылке:http://blogs.technet.com/b/security/archive/2013/06/03/microsoft-releases-new-mitigation-guidance-for-active-directory.aspx.

Я ознакомился с этим документом и считаю его содержание блестящим. Как говорит во вступлении руководитель отдела информационной безопасности Microsoft, этот документ "содержит набор практических методов, которые помогут руководителям IT-отделов (и системным архитекторам) защитить корпоративную среду Active Directory". Он основан на опыте команды Microsoft по информационной безопасности и управлению рисками, которая консультирует как внутренних (MS IT), так и внешних потребителей компании, входящих в список Global Fortune 500.

Для сотрудников ГРИИБ документ может быть полезен по двум причинам:

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

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

Учитывая все сказанное, я рекомендую прочитать этот документ целиком. Однако, в нем более 120 страниц, и быстро ознакомиться с ним не получится. Так что, если вы не располагаете достаточным временем, я советую просмотреть, по меньшей мере, 5 страниц "Основных положений" (Executive Summary), которые включают таблицу с 22 практическими указаниями, грубо упорядоченными в приблизительном порядке убывания приоритета. Основные положения представлены в такой форме, что могут использоваться в вашей организации в качестве отдельного документа.

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

Мои выдержки из "Практических указаний по защите Active Directory"

Следующие подразделы названы так же, как соответствующие разделы документа.

Пути компрометации системы

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

Уменьшение поверхности атаки Active Directory

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

Уменьшение количества административных учетных записей и членов в группе администраторов

• Уменьшите количество учетных записей в наиболее привилегированных группах. Стандартные привилегированные группы включают в себя администраторов всей корпоративной сети, администраторов домена и локальных администраторов. В идеале нужно добиться того, чтобы в данных группах отсутствовали постоянные члены. При этом пользователи добавляются в эти группы только при необходимости и удаляются после того, как ими выполнена соответствующая задача. Этого можно добиться с помощью пары решений для управления привилегированными учетными записями от Cyber-Ark и Lieberman (существуют и другие).

Создание выделенных административных хостов

• Значительный акцент делается на создании выделенных, защищенных административных систем для доступа к наиболее доверенным хостам. Идея здесь заключается в том, чтобы пользователи с привилегированными учетными записями использовали свои аккаунты только в данных выделенных заблокированных защищенных системах (то есть, без использования RunAs на своих машинах). Предложенные решения включают использование выделенных физических рабочих станций, использование ВМ и/или использование выделенных серверов типа "jump point" (как правило, через удаленный рабочий стол).

Борьба с физическими атаками на контроллер домена

• Не стоит недооценивать возможность физической компрометации, в том числе, контроллеров домена. При усилении компьютерной безопасности самым слабым звеном может стать физическая безопасность, особенно это касается офисов, находящихся на большом расстоянии. Одно из предложенных решений состоит в использовании для таких контроллеров домена режима "только чтение" (сам контроллер при этом называется read only domain controller – RODC). "Режим только чтение – это способ более безопасного развертывания контроллера домена в местах, где требуется быстрая и надежная аутентификация сервисов, но где физическая безопасность недостаточна для выдачи контроллеру права записи."
• Возможности RODC включают:
  • По умолчанию RODC не хранит учетные данные пользователя или компьютера. Чтобы настроить на RODC аутентификацию, администратор задает репликацию учетных записей определенных пользователей на определенные RODC. Так что, например, если вы хотите, чтобы все пользователи пекинского офиса могли аутентифицироваться на своих локальных RODC, вы можете указать, что на эти локальные RODC должны реплицироваться только учетные данные пекинских пользователей. Для любого другого пользователя, пришедшего в пекинский офис, запрос аутентификации будет перенаправляться локальным RODC на DC с правом записи.
  • За исключением учетных записей, по умолчанию RODC содержит все те же объекты и атрибуты Active Directory, что и контроллер с правом записи. Это поведение, однако, можно изменить, поскольку некоторые приложения хранят свои специальные учетные данные или другую конфиденциальную информацию в виде атрибутов AD. При необходимости эти важные атрибуты можно фильтровать.
  • Как следует из названия, в базу данных, хранящуюся на RODC, нельзя записывать изменения. Изменения должны производиться на доменном контроллере с правом записи и реплицироваться на RODC.
  • Ссылка для более подробной информации по RODC: http://blogs.technet.com/b/askds/archive/2008/01/18/understanding-read-only-domain-controller-authentication.aspx.

Создание белого списка приложений

• Фильтрация приложений по белому списку – эффективный инструмент для борьбы с вредоносными программами. Bit9 – крупный игрок на рынке подобных решений и, возможно, лучший выбор для корпоративных сред (так думаю я, а не Microsoft). Однако, AppLocker от Microsoft может также неплохо подойти для некоторых организаций, включая компании, которые предпочитают медленный старт, изначально применяя решение только к критичным серверам.

Использование контроля механизма аутентификации смарт-карт

• Двухфакторная аутентификация должна быть нормой, а не исключением, особенно для привилегированных пользователей. В данном разделе обсуждаются некоторые преимущества смарт-карт. Мои собственные исследования подтверждают, что смарт-карты не могу решить всех вашех проблем, в особенности потому что учетные данные пользователя хранятся в виде обычного парольного хэша, и этот хэш может использоваться в некоторых атаках. Тем не менее, смарт-карты во многих ситуациях являются гораздо большим препятствием для злоумышленников, чем другие средства аутентификации.
• "Authentication Mechanism Assurance" (контроль механизма аутентификации) – относительно новая возможность, о которой я до этого не слышал,– может стать еще большим препятствием на пути злоумышленника. Эта возможность, появившаяся в Windows Server 2008 R2, позволяет фиксировать для маркера доступа пользователя факт аутентификации на основе сертификата. "Это позволяет администраторам сетевых ресурсов контролировать доступ к таким ресурсам как файлы, папки и принтеры, учитывая, вошел ли пользователь, воспользовавшись сертификатом, и тип этого сертификата. Например, пользователь, зашедший с помощью смарт-карты, может иметь иные права доступа к сети, нежели пользователь, зашедший другим способом (то есть, путем ввода логина и пароля)".

Использование шаблонов для безопасных настроек

• Для систем, требующих повышенной безопасности, вроде системы доменного контроллера или рабочих станций для привилегированных аккаунтов, воспользуйтесь Microsoft Security Compliance Manager (диспетчер соответствия требованиям безопасности). Это свободно распространяемая утилита, которая включает в себя шаблоны настроек безопасности, рекомендованные Microsoft. Шаблоны доступны для всех основных версий ОС и сервис-паков, а также для Exchange, IE и офисного пакета. Доступные шаблоны перечислены здесь: http://technet.microsoft.com/en-us/library/cc677002.aspx. Более того, для применения этих шаблонов можно использовать групповые политики.
• От себя я также советую вам подумать о развертывании EMET по меньшей мере на критичных рабочих станциях и, возможно, на серверах. Брайан Кребс написал неплохой обзорпоследней версии (4.0) EMET в своем блоге.

Примите меры в отношении плохо написанных программ

• Не пропустите содержащееся в данном документе обсуждение плохо написанных приложений и их влияния на безопасность системы. Здесь предлагается включать эффективный аудит безопасности в цикл разработки ПО (Software Development Lifecycle, SDL). В противном случае, либо ваши программы будут уязвимыми, либо вам придется делать дорогостоящие исправления.
• К вопросу стоимости: "По оценкам некоторых организаций полная стоимость исправления одной проблемы безопасности в релизной версии составляет порядка $10.000, и приложения, разработанные вне эффективного цикла разработки, могут иметь в среднем более 10 серьезных проблем на каждые 100 тысяч строк кода. С увеличением масштаба приложения стоимость ошибок разработки стремительно нарастает."

Сделайте концепцию безопасности понятной для конечных пользователей

• Упрощение понимания безопасности для конечных пользователей всегда должно быть в приоритете. В качестве примера в документе рассматривается реализация доступа привилегированных пользователей к важным файлам только из специально выделенных систем. Это позволяет одновременно дать привилегированным пользователям доступ к требуемым файлам, а аналитикам – хорошую возможность обнаруживать неправомочный доступ из прочих систем. Для пользователей такое решение может быть не слишком удобным, но зато простым для понимания.

Отслеживание признаков компрометации Active Directory

Данный раздел начинается с обсуждения различных категорий аудита, доступных в системах до Windows Vista и новых подкатегорий, доступных, начиная с Vista. Если у вас Windows версии Vista и выше, вы можете просмотреть конфигурацию подкатегорий аудита, открыв командную строку от имени администратора и запустив каманду "auditpol.exe /get /category:*".

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

Документ включает в себя подробную таблицу, содержащую рекомендации для каждой из подкатегорий аудита и типа ОС (то есть, набор рекомендаций для Windows 7 и 8 отличаетя от набора рекомендаций для Windows Server 2008, 2008 R2, и 2012). Таблица включает настройки по умолчанию, набор базовых рекомендаций по аудиту (которые, я полагаю, перекочевали из Windows Security Resource Kit), а также набор новых, "сильных" рекомендаций.

Хотел бы я сказать "Вперед, реализуйте наиболее сильные рекомендации Microsoft по аудиту и все будет замечательно!". К сожалению, это был бы плохой совет. Суровая правда в том, что вам нужно тестировать совместимость рекомендаций с вашей собственной средой. Я бы предложил использовать наиболее сильные рекомендации как отправную точку, а затем ослаблять их там, где этого требуют ограничения ресурсов. Не забывайте, что для поддержки высоких уровней аудита вам понадобится не только надежное оборудование (особенно быстрые диски для поддержки увеличенного объема ввода-вывода), но также больше дискового пространства, чтобы события не перезаписывались слишком быстро. События серверов в идеале будут перенаправляться на централизированный сервер логирования, и в данном случае дисковое пространство не будет помехой. Для рабочих станций и ноутбуков, с другой стороны, перенаправление журнала становится логистически трудной задачей, требующей более дорогой реализации, так что придется найти золотую середину между подробным журналом событий и ограничениями локального хранилища данных.

За таблицей рекомендаций следует обсуждение типов событий, подлежащих отслеживанию. Это довольно короткое обсуждение всего с парой примеров. Советую просмотреть подробное приложение L: "События для отслеживания", содержащее сотни индивидуальных идентификаторов, которые стоит включить в список.

Действия в случае компрометации

Если в результате атаки ваша AD была полностью скомпрометирована, вам не останется ничего другого, как заменить ее полностью. Как говорится в документе, если только "у вас нету записей о каждом изменении, сделанном злоумышленником, или доверенной резервной копии, вы не сможете восстановить содержимое AD до полностью доверенного состояния".

Более того, "даже восстановление доверенного состояния не устраняет тех изъянов среды, которые позволили скомпрометировать ее в первый раз."

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

В документе рассмотрены следующие руководящие принципы для создания нового леса AD, который выступает в роли "безопасной ячейки" для основной инфраструктуры бизнеса.

1. Принципы сегрегации и защиты критических ресурсов:
   • Настройки не должны позволять новому лесу AD доверять старому лесу. Это означает, что старые учетные записи не должны иметь возможность входить в новый лес. Однако, в документе сказано, что вы можете настроить доверие в обратную сторону: старый лес может доверять новому. Я бы поспорил с такой рекомендацией, поскольку в результате ваши новые учетные записи смогут заходить в скомпрометированный домен и, если в это время в нем будут функционировать вредоносные программы, учетные записи окажутся под угрозой. Новые аккаунты будут подвержены особому риску, если в старый домен разрешены интерактивные входы.
   • Используйте "немиграционные" подходы, предотвращающие копирование истории SID. (Подробнее об этом в пункте 3).
   • Устанавливайте ОС и приложения заново, не перемещайте системы из старого леса в новый.
   • Не разрешайте в использование старых версий ОС и программ в новом лесу. Для улучшения защиты используйте новейшие версии ОС и приложений.
2. Разработайте ограниченный, основанный на анализе рисков, план миграции:
   • Определитесь со стратегией. Хотите ли вы на первом этапе перенести лишь привилегированные аккаунты, определенный регион, отдел или всех пользователей разом?
   • Выделите то, что действительно является критичным для бизнеса и должно естественным образом определять расстановку приоритетов в вашем плане миграции.
3. Используйте "немиграционные" миграции там, где необходимо.
• Не поддерживайте историю SID из старых доменов. Используйте инструменты, которые задают соответствие между новыми аккаунтами и аккаунтами из старого леса.
• "Приложение J: Сторонние производители средств RBAC" (ролевого разграничения доступа) и "Приложение K: Сторонние производители PIM" (решений для управления привилегированными аккаунтами) перечисляют некоторые продукты, которые могут производить "немиграционные" миграции.
4. Реализуйте "креативное избавление":
   • Избавляйтесь от старых программ и систем не путем их обновления, а путем создания новых защищенных приложений и систем, замещающих прежние. Переносите данные, но не устаревшие приложения.
5. Изолируйте старые системы и приложения:
   • Для поддержки тех старых приложений и систем, которые не могут быть заменены новыми версиями, используйте небольшой выделенный домен.
   • Не разрешайте новому домену доверять старому домену приложений. В идеале доверие в обратную сторону также должно быть исключено, хоть возможно вам все же понадобится разрешить старому домену приложений доверять новому чистому домену. В таком случае не разрешайте интерактивных входов новых учетных записей в старый домен (мой совет).
6. Упростите безопасность для конечных пользователей.
   • Используйте простые методы вроде выделенных защищенных систем для доступа к важным файлам.
   • Подумайте об альтернативных методах аутентификации вроде смарт-карт, биометрии или даже "аутентификационных данных, защищенных TPM-чипами в компьютерах пользователей".

Создание бизнес-центрированных реализаций защиты Active Directory

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

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

"По мере того, как технологии развивались и распространялись, мечта о 'компьютере на каждом рабочем столе' стала реальностью для большей части мира, а сегодня мы можем говорить о гораздо большем. В наши дни информационные технологии перестали играть лишь поддерживающую роль и перешли из инфраструктуры в ядро бизнеса. Если ваша организация не может продолжать функционировать в случае недоступности всех ИТ-сервисов, то ваш бизнес, по меньшей мере частично, принадлежит к сфере ИТ."

Вот несколько более существенных пунктов из данного раздела:

• Помимо определения уровня сервиса в зависимости от аптайма (относительной доли рабочего времени) системы, вам следует подумать об определении уровней контроля безопасности и отслеживании на основе важности информационного ресурса.
• Выработайте четкие процессы определения владельцев данных, приложений, учетных записей пользователей и компьютерных аккаунтов.
• Чем более рутинной для владельца бизнеса является проверка достоверности данных в Active Directory, тем проще вам будет выявлять аномальности, говорящие о сбоях или о компрометации системы.
• Классифицируйте не только данные, но и сервера, на которых эти данные располагаются. Отслеживайте сервера в зависимости от классов расположенных на них данных. То же касается и приложений.
• Для большинства организаций попросту невозможно непрерывно отслеживать всех пользователей. Классифицируйте учетные записи пользователей и тщательно отслеживайте лишь наиболее важные аккаунты.

Сводка практических рекомендаций

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

Надеюсь, данный обзор был вам полезен, и вы найдете время, чтобы ознакомиться со всем содержимым документа. Я считаю, что "Практические указания по защите Active Directory" предоставляют солидную дорожную карту и набор рекомендаций, которые могут быть использованы во многих организациях для предотвращения, обнаружения атак и устранения их последствий.