Active Directory и безопасность. Часть 5. Обзор служб каталогов компании Microsoft

 ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, CCEE. shapiro_leonid@yahoo.com

Active Directory и безопасность
Часть 5. Обзор служб каталогов компании Microsoft

Обеспечение безопасности службы каталога Active Directory (AD) складывается из множества компонентов [1-5]. Крайне важно обеспечить безопасность контроллеров доменов (DC)

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

Прежде чем разобраться с тем, как же все-таки следует защищать контроллеры доменов, сделаем небольшой исторический обзор развития служб каталога компании Microsoft, что позволит нам лучше понять, с какими сложностями нам предстоит встретиться и каким угрозам безопасности придется противостоять. Начнем мы не с AD, а с ее предшественницы – Directory Services (DS).

Windows NT 4.0

Понятие леса отсутствовало, служба каталога имела плоскую структуру, иерархические структуры, привычные нам от AD, отсутствовали, доверительные отношения были только односторонние [6]. Читатель, знакомый с DS, может сказать: «А как же с моделями single master и multiple master в DS Windows NT 4.0? Ведь это же своего рода иерархия».

Тем не менее мы понимаем, что представленные на рис. 1 модели трудно сопоставить с тем, что предлагает служба каталога AD начиная с Windows 2000. Что касается типов доменных контроллеров, то нам предлагалось два варианта: Primary Domain Controller (PDC), который обеспечивал аутентификацию и авторизацию, отвечал за внесение изменений в базу данных каталога и являлся источником репликации, и Backup Domain Controller (BDC), также обеспечивающий аутентификацию и авторизацию, но при этом не имеющий возможности внесения изменений в базу данных, а получающий их в результате репликации с PDC.

Рисунок 1. Single master domain (левая часть рисунка) и multiple master domain (рисунок целиком)

Основной контроллер (PDC) мог быть лишь единственным на весь домен, что соответственно создавало единую точку сбоя. Количество резервных контроллеров (BDC) не лимитировалось. Контроллеры доменов часто приходилось размещать «ближе» к клиентам во избежание избыточного трафика аутентификации и авторизации, не будем забывать о возможностях каналов связи, доступных в то время. Все это не добавляло безопасности системам, кроме того, существовало большое количество программных продуктов, которые при наличии физического доступа к серверу предоставляли возможность сброса пароля любой учетной записи и захвата административного контроля над всей системой. А при необходимости размещения контроллеров на удаленных площадках это создавало огромную проблему службам информационной безопасности (ИБ). Как обеспечить физическую безопасность контроллеров доменов? Можно ли доверять сотрудникам компании, имеющим доступ в серверную? Не станет ли сам администратор угрозой безопасности? Как защитить данные на контроллере домена? Приходилось искать решения третьих фирм.

Windows Server 2000/2003

В 2000 году появляется служба каталога AD, которая, во-первых, предоставляет нам иерархическую модель [7] (см. рис. 2), а во-вторых, использует другой подход к внесению изменений в базе данных службы каталога. Вместо модели Single master с PDC и BDC появляется модель Multiple master, где все контроллеры должны быть равноправны с этой точки зрения, и каждый из них может вносить изменения в БД каталога. Строго говоря, это не совсем так, поскольку ряд возможностей все равно доступен лишь некоторым контроллерам домена – мастерам (хозяевам) операций, но в конце концов теперь у нас стала менее актуальна проблема единой точки сбоя. Эта же схема была унаследована и в Windows Server 2003. Разумеется, сама AD претерпела ряд изменений, но сейчас для нас это не так важно.

Рисунок 2. Иерархическая модель AD

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

Компания Microsoft предлагает алгоритм размещения DC для повышения уровня безопасности компании (см. рис. 3). Глядя на представленную блок-схему, мы понимаем, что контроллеры просто нельзя размещать на удаленных площадках, если мы не можем гарантировать их физическую безопасность и возможность централизованного управления из главного офиса компании. При этом штатные средства, которые позволили бы обеспечить эффективную защиту контроллеров доменов, не слишком эффективны. То есть по-прежнему остается актуальной проблема физической безопасности контроллеров. Может быть, стоит прибегнуть к виртуализации AD и зашифровать виртуальные машины? Однако это решение невозможно ввиду особенностей репликации AD на основе Windows Server 2000/2003 в виртуальной среде [9]. Таким образом, мы видим, что миграция на новые версии ОС – это не только вопрос возможностей ОС и окончания поддержки устаревших версий, но и вопрос безопасности инфраструктуры предприятия.

Рисунок 3. Размещение контроллеров доменов в филиалах [8]

Windows Server 2008/2012

Только с выходом Windows Server 2008 у нас появляется возможность более эффективной защиты от компрометации AD. На помощь приходят технологии RODC, Core server, BitLocker. С одной стороны, у нас сохраняется модель multiple master, появившаяся еще в Windows Server 2000, а с другой – есть возможность построить однонаправленную репликацию на контроллеры, доступные только для чтения (RODC). Теперь можно существенно снизить риски для всей системы при размещении контроллеров домена на площадках, где не гарантируется физическая безопасность.

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

1. Москалев С., Шапиро Л. Active Directory и безопасность. Часть 1. Построение защищенных служб каталога. //«Системный администратор», №7-8, 2014 г. – С. 44-45 (http://samag.ru/archive/article/2737).
2. Москалев С., Шапиро Л. Active Directory и безопасность. Часть 2. Вопросы защиты. //«Системный администратор», №9, 2014 г. – С. 44-45 (http://samag.ru/archive/article/2770).
3. Москалев С., Шапиро Л. Active Directory и безопасность. Часть 3. Методика защиты. //«Системный администратор», №10, 2014 г. – С. 47-49 (http://samag.ru/archive/article/2795).
4. Москалев С., Шапиро Л. Active Directory и безопасность. Часть 4. Принцип наименьших привилегий. //«Системный администратор», №11, 2014 г. – С. 44-46 (http://samag.ru/archive/article/2818).
5. Best Practices for Securing Active Directory Microsoft IT Information Security and Risk Management – http://www.microsoft.com/en-us/download/details.aspx?id=38785.
6. Минаси М., Криган Э., Андерсон К. Windows NT 4.0.
7. Зубанов Ф. Windows 2000. Планирование, развертывание, управление.
8. Windows Server 2003 Active Directory Branch Office Guide – http://www.microsoft.com/en-us/download/details.aspx?id=5838.
9. Работа контроллеров домена в среде Hyper-V – http://technet.microsoft.com/ru-ru/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx.

Комментарии могут оставлять только зарегистрированные пользователи