Домены, леса и опасность доверительных отношений

Доверительные отношения — эффективный способ ограничить число учетных записей и реализовать единую процедуру регистрации (single sign-on — SSO) в лесах Active Directory (AD), доменах Windows NT и AD и даже в областях Kerberos на платформах, отличных от Windows. Но за доверие приходится платить. В лесу с доменами, связанными отношениями доверия, есть где развернуться недобросовестным администраторам, а физически уязвимые контроллеры домена (DC) представляют собой угрозу для всего леса. В данной статье рассматриваются основы доверительных отношений и потенциальные опасности, связанные с такими отношениями. Затем объясняется, как снизить риск для различных типов доверительных отношений, применяемых в современных системах Windows Server 2003 и Windows 2000.

Оптимальный уровень разделения

Существует много вариантов высокоуровневой организации AD (структурного деления на леса и домены). Одно из ключевых требований к высокоуровневой структуре AD — обеспечить оптимальное разделение между различными частями организации. В идеальном случае организация представляет собой единый лес с одним или несколькими доменами. Если AD реализована как единый лес, то пользователи получают ясную картину сети, и каждый из них может иметь единственную учетную запись. Одновременно лес можно разделить на несколько доменов, чтобы выделить различные группы администраторов или пользователей.

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

Простой вопрос доверия

Рассмотрим простейший вариант доверительных отношений: односторонние нетранзитивные отношения между двумя доменами. Домен A доверяет домену Б, но домен A не доверяет любому домену, которому доверяет домен Б. На рис. 1 показана сравнительная картина нетранзитивных и транзитивных отношений. О проблеме безопасности при различных видах доверительных отношений рассказано во врезке «Типы доверительных отношений». Что происходит, если домен A доверяет домену Б? Кому в действительности доверяет домен A? Получают ли пользователи домена Б автоматический доступ к ресурсам домена A? Имеют ли администраторы домена Б права доступа к домену A?

Рисунок 1. Транзитивные и нетранзитивные доверительные отношения

Прежде всего, выясним, что происходит при доверительных отношениях? В данном случае домен A — доверяющий (trusting), а домен Б — доверенный (trusted). Для домена A направление доверительных отношений — исходящее. Компьютеры в домене A доверяют контроллерам домена в домене Б, которые аутентифицируют учетные записи пользователей и компьютеров, и определяют членство в группах. Если администратор в домене A открывает список управления доступом (ACL) файла или папки и выбирает новые учетные записи и группы, чтобы добавить их в ACL, то администратор видит учетные записи и группы как домена Б, так и домена A. Администратор может сделать учетные записи и группы домена Б членами групп домена A, и в целом может использовать учетные записи и группы домена Б всюду, где применимы учетные записи и группы домена A. Пользователи домена Б могут обращаться к ресурсам в домене A, для которых у них имеются соответствующие полномочия.

Кому в действительности доверяет домен A? Пользователям домена Б? Администраторам домена Б? Если установлены доверительные отношения, в соответствии с которыми домен A доверяет домену Б, то, очевидно, желательно, чтобы пользователи домена Б получили доступ к определенным ресурсам домена A. Доступ можно обеспечить, предоставив соответствующие полномочия группам домена Б после установления доверительных отношений. Но получат ли администраторы домена Б дополнительные права в домене A? Очевидный ответ — администраторы домена Б получают такие же права доступа, как и другие пользователи домена Б, за исключением права добавлять и удалять пользователей групп домена Б, имеющих доступ к ресурсам домена A. Другими словами, если администратор домена A предоставляет какие-нибудь права доступа группе домена Б, то администратор домена Б может предоставить или отменить эти права для пользователей домена Б, просто изменив членство в группе домена Б. Поэтому на первый взгляд доверительные отношения не несут серьезной опасности. Однако у администраторов домена Б есть документированный способ незаконно получить административный доступ к домену A. Этот способ будет описан в следующем разделе.

Подводные камни доверительных отношений

Одна из опасностей отношений доверия с другим доменом связана с управлением разрешениями в ситуациях, когда необходимо предоставить всем пользователям домена доступ к определенному ресурсу. Часто для этой цели используется группа Everyone или Authenticated Users. Однако состав группы Authenticated Users изменяется при добавлении доверенного домена. Если домен A не доверяет ни одному другому домену, то в группу Authenticated Users входят только пользователи домена A; если разрешения на доступ к объектам заданы на автономных серверах и рабочих станциях — то локальные пользователи этих компьютеров. Но если домен A доверяет домену Б, то группа Authenticated Users автоматически расширяется и охватывает всех пользователей домена Б. Поэтому любые файлы и другие объекты, в ACL которых есть записи, предоставляющие доступ группе Authenticated Users, становятся доступными и пользователям домена Б. Если доверие домена A домену Б транзитивное, то доверительные отношения распространяются на пользователей всех доменов, которым доверяет домен Б.

В зависимости от типа доверительных отношений, Windows может использовать Kerberos или NT LAN Manager (NTLM) в качестве протокола аутентификации для обработки запросов регистрации между двумя доменами. Проанализировать пакеты и разгадать пароли пользователей можно с помощью любого протокола, но расшифровать информацию NTLM проще и быстрее. Наиболее уязвимые места NTLM можно защитить, если внедрить стандарт NTLMv2 на всех DC и рабочих станциях в доверенном домене и на всех компьютерах в доверяющем домене, но Kerberos все равно надежнее.

Устранить технические препятствия значительно проще, чем главную опасность доверительных отношений с другим доменом: доверие к администраторам другого домена. Если домен A доверяет домену Б, то администраторы домена Б должны выполнять свою работу профессионально и честно. Если домен Б подвергся нападению, то под угрозой оказываются все ресурсы домена A, доступные домену Б. Например, предположим, что Боб имеет учетную запись в домене Б и доступ к важной базе данных в домене A. Если взломщик попытается разгадать пароль Боба путем повторных попыток регистрации, то уровень надежности политики блокировки домена A не имеет значения, и преградой для доступа взломщика к базе данных в домене A служит лишь политика блокировки домена Б. Кроме того, только администраторы домена Б могут обнаружить неудачные попытки регистрации в журнале безопасности контроллера домена. Хотя, если взломщик напрямую атакует один из компьютеров домена A с учетной записью Боба, то неудачные попытки локальной регистрации будут отражены в журнале безопасности атакуемого компьютера. Поэтому, если администраторы в доверенном домене не смогут защитить свои учетные записи, отслеживать попытки несанкционированного доступа или уязвимые места, своевременно устанавливать исправления или принимать другие меры обеспечения безопасности, то доверяющий домен (по крайней мере, его ресурсы, доступные пользователям доверенного домена) подвергается такой же опасности, как домен, которому он доверяет.

Кроме того, всегда существует опасность присутствия непорядочного администратора в доверенном домене. Администраторы могут манипулировать учетными записями и группами по-разному, в том числе действовать от лица пользователя, которому был предоставлен доступ. Конечно, та же опасность существует и внутри доверяющего домена. Поэтому, отвечая на вопрос, можно ли доверять другому домену, следует спросить себя, заслуживают ли доверия администраторы того домена. Однако альтернатива доверительным отношениям между доменами, пользователям которых необходимо предоставить доступ к ресурсам, также не лишена риска. Если не доверять домену, то нужно создать учетные записи для его пользователей. Можно быть уверенным, что эти учетные записи защищены в соответствии с требованиями, действующими внутри домена. Однако нужно предусмотреть меры на случай увольнения или изменения служебных обязанностей пользователей — а может быть, у администраторов домена, с которым установлены отношения доверия, больше возможностей блокировать учетные записи и менять членство в группах при должностных изменениях?

Еще одна опасность заключается в том, что доверенные DC не только аутентифицируют пользователей, но и предоставляют доверяющим DC информацию о членстве в группах. Внутри леса DC доверяет всем SID, назначенным пользователю доверенным DC. Поэтому злоумышленник-администратор в домене Б (при наличии достаточной квалификации и программы, составленной умелым хакером), может заставить DC в домене Б указать, что администратор домена Б принадлежит к группе Administrators домена A, и домен A предоставит ему административные полномочия (см. «Facts about Directory Structures and Directory Structure Owners» в «Design Considerations for Delegation of Administration in Active Directory» по адресу http://www.microsoft.com/ windows2000/docs/addeladmin.doc).

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

Администратор доверяющего домена должен применить фильтрацию SID к домену, которому он доверяет. Например, с помощью следующей команды Netdom можно фильтровать SID из домена Jonescorp:

C:winnt>netdom /filtersids yes

jonescorp

Доверяй, но проверяй

Каким образом можно уменьшить опасность того, что доверенный администратор-злоумышленник вставит SID внутри леса? На первый взгляд единственное решение — создать отдельный лес для каждого домена. Допустим, Acme — международная компания со штаб-квартирой в США и офисами по всему миру. Доменами в лесу Acme управляют администраторы американских и иностранных офисов. Acme также выполняет секретные заказы правительства США, доступ к которым для иностранных граждан запрещен. Если просто перенести секретные ресурсы в «секретный» домен в лесу Acme, есть опасность, что доступ к ним получат иностранцы с административными полномочиями в других доменах леса. Безусловно, реальное и самое концептуально простое решение — создать отдельный «секретный» лес.

Однако у Acme есть другой выход, который позволит сохранить преимущества единственного леса. Лишь немногие пользователи доменов AD действительно нуждаются в административных полномочиях. Высокодетализированная модель безопасности AD позволяет делегировать фрагменты административных полномочий в соответствии с потребностями конкретного предприятия. Если уделить время идентификации различных ролей в ИТ-подразделении и разобраться в механизме делегирования AD, то можно организовать домены так, чтобы для повседневного администрирования никто не регистрировался в качестве членов групп Administrators, Domain Admins, Enterprise Admins или Schema Admins. Детализированное делегирование полномочий AD позволяет снизить остроту проблемы администраторов-злоумышленников, допуская в число членов групп Administrators, Domain Admins, Enterprise Admins и Schema Admins только граждан США. Благодаря такой мере иностранный сотрудник ИТ-подразделения не сможет вставить SID внутри леса.

Однако ограничение административных полномочий препятствует лишь одному из двух возможных способов вставки SID внутри леса. Другой метод состоит в физическом доступе. Лицо, которое получает физический доступ к DC, может изменить системные файлы при отключенной системе Windows. Физическая уязвимость представляет более сложную проблему для такой компании, как Acme, поскольку ей необходимо устанавливать DC за рубежом для обслуживания производственной деятельности. Единственный способ защититься от вставки SID внутри леса в результате физического проникновения злоумышленника — полностью удалить секретный домен из основного леса. Для связи между пользователями в секретном домене и остальной компанией можно организовать внешние доверительные отношения между специальными доменами основного и секретного лесов (рис. 2). Чтобы компенсировать отсутствие единого, унифицированного глобального каталога (Global Catalog — GC), можно задействовать Microsoft Identity Integration Server (MIIS), который публикует данные пользователей одного леса как объекты «контакт» в другом лесу.

Пояснения. Пунктирными линиями показано, как администратор-злоумышленник присваивает административные полномочия в других доверяющих доменах в том же лесу. На диаграмме также показан другой доверенный лес и внешний домен, связанный доверительными отношениями непосредственно с доменом администратора-злоумышленника. Знак показывает, что администратор-злоумышленник не может присвоить административные полномочия в этих доменах.
Рисунок 2. Возможности доступа администратора- злоумышленника в доверяющих доменах

Домены Windows 2003 и Windows 2000 — не такая непреодолимая граница административных полномочий, как в NT. Роль административной границы в AD отведена лесу. Следование принципу минимальных полномочий и ограничение административных прав могут существенно уменьшить опасность вставки SID внутри леса, но не устранить ее полностью. Нежелательно строить несколько лесов, так как это неудобно для пользователей и создает дополнительную работу для администраторов, которые должны предоставить пользователям унифицированный каталог. Помочь в этом могут такие инструменты, как MIIS. Проектирование лесов и доменов для организации связано с поиском баланса между удобством использования и риском при управлении.

Типы доверительных отношений

Внутри леса можно установить доверительные отношения родитель-потомок (parent-child), дерево-корень (tree-root) или с помощью указателей (shortcut). Все доверительные отношения внутри леса являются двусторонними и транзитивными. Указательные отношения могут быть односторонними, но они не влияют на безопасность. Принимая решение о создании домена внутри леса, следует учитывать несколько факторов. Все домены в лесу доверяют друг другу, поэтому в новом домене должны быть реализованы минимальные меры безопасности, соответствующие уровню остального леса. Кроме того, по умолчанию все домены относятся к ведению группы Administrators корневого домена леса в силу полномочий, по умолчанию назначаемых группе Enterprise Admins. Следует ли оставить в силе эти полномочия, учитывая особенности ресурсов нового домена? И наконец, хотя официально у администраторов одного домена нет полномочий в других доменах леса, в Active Directory (AD) есть уязвимое место, через которое администраторы одного домена потенциально могут получить административные полномочия в другом. Отдельные подразделения некоторых компаний (например, выполняющие секретные правительственные заказы) должны быть строго недоступны для других администраторов. Для секретного подразделения можно организовать отдельный лес, вместо того чтобы строить отдельный домен в том же лесу.

Внешние, лесные и областные (realm) доверительные отношения расширяют сферу доверия за пределы леса. Внешние связи позволяют установить одностороннее и двухстороннее доверие с доменом в другом лесу или унаследованным доменом Windows NT 4.0. Внешние доверительные отношения нетранзитивны (ограничены двумя доменами, напрямую связанными друг с другом). Внешние отношения ограничены сравнительно ненадежным протоколом аутентификации NT LAN Manager (NTLM), но уровень защиты от анализа пакетов и разгадывания пароля можно повысить, если использовать NTLMv2 вместо NTLM для настройки конфигурации контроллеров домена и клиентских компьютеров в доверенном домене и DC и серверов — в доверяющем домене. Доверяющие домены уязвимы для манипуляций с SID администраторами доверяемого домена. Если фильтрация SID не активизирована, то администратор доверенного домена может вставлять фальшивые SID в свойство предыстории SID учетной записи, которое соответствует SID группы (например, Administrators, Domain Admins и Enterprise Admins) леса доверяющего домена. Если для доверительного отношения активизирована SID-фильтрация, то доверяющий DC фильтрует фальшивые SID, получаемые в составе запросов аутентификации из доверенного домена.

Доверительные отношения между лесами — новшество лесов в Windows Server 2003. Двусторонние доверительные отношения между лесами Windows 2003 расширяют изначальное доверие, обычно существующее между всеми доменами в лесу, распространяя его на оба леса. Одностороннее доверие между лесами означает, что все домены в доверяющем лесу доверяют всем доменам в доверенном лесу, но не наоборот. Лесные доверительные отношения поддерживают как NTLM, так и Kerberos, поэтому вновь возникает потребность в реализации NTLMv2 между двумя участниками доверительных отношений. Лесные доверительные отношения уязвимы к тем же манипуляциям с SID, что и внешние домены, поэтому следует активизировать фильтрацию SID. Посредством доверительных отношений между лесами можно добиться одинакового уровня доверия между всеми доменами двух лесов, не опасаясь кражи административных полномочий одного домена администраторами второго домена в другом, доверенном лесу.

Однако домены, соединенные межлесными доверительными отношениями, не разделяют двух ресурсов AD, общих для всех доменов леса: Global Catalog (GC) и схемы. Изменения схемы в одном лесу не выходят за границу леса. В большинстве случаев это не представляет серьезной проблемы, так как при необходимости можно просто соответствующим образом изменить схему другого леса. Труднее компенсировать отсутствие единого, унифицированного GC. Именно благодаря GC границы домена прозрачны для пользователей, которым нужно найти других пользователей, группы рассылки, серверы и другие ресурсы. Если организация разделена на несколько лесов, то пользователи должны знать границы лесов, а также пользователей, подразделения и ресурсы, принадлежащие конкретным лесам. Для восстановления прозрачности в среде со многими лесами можно синхронизировать объекты между лесами с помощью бесплатного пакета Microsoft Identity Integration Server (MIIS) Feature Pack for Windows Server Active Directory. Например, если есть два леса, A и Б, то можно установить MIIS Feature Pack, чтобы опубликовать учетные записи пользователей леса A в качестве контактов в лесу Б и учетные записи пользователей леса Б в качестве контактов леса A. В результате пользователи смогут отыскать друг друга и общаться через Microsoft Exchange Server.

Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@monterey techgroup.com