Скрытые данные в Active Directory. Часть 1

Гвидо Грилленмайер (guido.grillenmeier@hp.com) — главный инженер группы Enterprise Services Group компании HP. Имеет сертификаты Microsoft Directory Services MVP, Microsoft Certified Architect

В Active Directory (AD) предусмотрены функции назначения объектам разрешений с целью делегирования административных полномочий пользователями, группами или компьютерами любому субъекту безопасности. Но с помощью обычных разрешений AD довольно сложно добиться, чтобы определенные данные были видны только узкому кругу пользователей.

.

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

Суть проблемы

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

Компании постепенно осознают широкие возможности разрешений на чтение (и запись), предоставляемых всем учетным записям пользователей в корпоративных реализациях AD. Большинство компаний хотели бы провести различия между сотрудниками, которым разрешается направлять запросы ко всем учетным записям в AD, и внешними пользователями (например, подрядчиками). Кроме того, предприятиям, желающим применять AD не просто как каталог сетевой операционной системы (который проверяет подлинность пользователей в сети), но и каталог LDAP (используемый другими приложениями), требуются более глубокий контроль над информацией, видимой разным участникам. Кроме того, в тех компаниях, где требуется делегировать административные полномочия, видимость и доступ к важным учетным записям — критический аспект, требующий тщательного планирования. Это особенно актуально при аутсорсинге, когда необходимо размещать пользователей из разных компаний в одном лесу AD.

По умолчанию всем прошедшим проверку подлинности пользователям в лесу AD назначаются явные разрешения на чтение в любой организационной единице (OU), созданной администратором домена или делегированным администратором. В этом случае любой выполнивший регистрацию пользователь может увидеть все объекты в любой OU в лесу AD. Ситуация не упрощается, если посмотреть на разрешения по умолчанию для объектов AD различных типов (например, объект user-Class). Как показано в таблице 1, пользователям, прошедшим проверку подлинности, предоставляются различные разрешения на чтение, но SELF (то есть пользователь, который обращается к собственной учетной записи) имеет право читать все свойства и изменять многие из них.

Помимо явных разрешений для каждого нового объекта, различные разрешения наследуются из родительских организационных единиц. Весьма важные разрешения по умолчанию, в частности, на чтение всех свойств объектов пользователя, предоставляются группе Pre-Windows 2000 Compatible Access. Одна из основных трудностей — ограничить разрешения для прошедших проверку подлинности пользователей таким образом, чтобы они не могли увидеть все объекты по умолчанию. Крайне важно разобраться во всех тонкостях разрешений AD и их настройке.

Обратите внимание, что я использовал термин «явные разрешения» (explicit permissions). Явные разрешения назначаются непосредственно на объектах, в отличие от наследуемых разрешений, устанавливаемых на объекте контейнера и настраиваемых для применения к объектам внутри этого контейнера и его субконтейнеров.

Явные и наследуемые разрешения

Как явные, так и наследуемые разрешения необходимы для эффективной модели авторизации AD. Если пользователь пытается получить доступ к объекту AD, монитор безопасности должен проанализировать список разрешений в списках управления доступом (ACL) и сравнить их с идентификатором безопасности пользователя (SID) и идентификаторами SID группы в маркере безопасности, чтобы определить, следует ли разрешить или запретить доступ. Для этого монитор безопасности обрабатывает список ACL, начиная сверху. Когда монитор обнаруживает достаточно записей управления доступом (ACE) для принятия решения о запрете или разрешении доступа, обработка ACL прекращается и выдается результат авторизации (разрешить или запретить) запросившему процессу. Порядок, в котором записи ACE расположены в списке ACL, определяют эффективные разрешения. В таблице 2 указаны приоритеты анализа и упорядочения записей ACE.

Запреты имеют приоритет перед разрешениями, но явные разрешения отменяют унаследованные запреты. Если дочерние объекты наследуют явное разрешение, то это разрешение также отменяет запрет, унаследованный с более высоких ступеней иерархии OU. Это значит, что даже если администратор запретил доступ к определенному атрибуту пользователя (например, номеру телефона) для всех внешних пользователей в корневом объекте домена в AD, эти разрешения обычно отменяются явными разрешениями на чтение, предоставляемыми по умолчанию всем прошедшим проверку подлинности пользователям в лесу.

Рисунок 1 иллюстрирует этот пример. Хотя группе ExtUsers запрещено чтение на верхнем уровне OU или в узле домена, в некоторых организационных субъединицах все же применяются разрешения по умолчанию, открывающие пользователям доступ на чтение к большинству объектов и атрибутов. Эти разрешения также применяются к новым созданным объектам. Запрет на верхнем уровне не может распространяться вниз до конца дерева, если на пути встречается OU, которая блокирует наследование разрешений из родительского OU. В следующих статьях серии будет показано, как устранить проблемы, возникающие из-за такого поведения.

Рисунок 1. Образцовые явные разрешения отменяют запреты верхнего уровня

Наборы свойств разрешений

Многие атрибуты AD сгруппированы в наборы свойств разрешений. Наборы свойств позволяют одной записи ACE предоставить или отменить разрешения на объекте AD для коллекции атрибутов. Без наборов свойств пришлось бы применять много отдельных записей ACE для каждого атрибута. Хороший пример набора свойств — набор Personal Information. В Server 2008 R2 он содержит 47 атрибутов, в том числе адрес и номер телефона пользователя.

Атрибут определяется как принадлежащий к определенному набору свойств по свойству attribute-SecurityGUID, соответствующему свойству rightsGUID набора свойств. На рисунке 2 показано, как разрешения свойства представлены в редакторе безопасности AD и как они применяются и проверяются для нескольких атрибутов объекта пользователя.

Рисунок 2. Разрешения AD могут применяться к нескольким атрибутам через наборы свойств

Наборы свойств введены с целью как упростить администрирование, так и сэкономить пространство для хранения данных в AD. Последнее обстоятельство не следует недооценивать. Каждая запись ACE, применяемая к объекту, должна храниться в AD. Разрешение, назначенное набору свойств, отображается и хранится в одной записи ACE, что позволяет экономить место. Помните, что любой атрибут в AD может принадлежать только одному набору свойств (важное ограничение при настройке безопасности AD). Определения всех типовых наборов свойств можно найти на странице Microsoft Property Sets по адресу msdn.microsoft.com/en-us/library/ms683990.

Большинство наборов свойств одинаковы во всех версиях Windows Server (как показано в таблице 3), но только в Windows 2003 и более новых версиях реализована важная возможность — изменять типовые наборы свойств. Более подробно о редактировании наборов будет рассказано в следующей статье.

В таблице 3 также показано, что большинство типовых наборов свойств по-прежнему содержат такое же число атрибутов, как и в первоначальной версии AD. Однако несколько наборов были обновлены в процессе обновления схемы, когда появились такие новшества, как LastLogonTimeStamp (в Windows 2003) и ManagedAccounts (в Server 2008 R2).

Схема Microsoft Exchange Server также расширена благодаря различным атрибутам; некоторые из них добавлены к типовым наборам свойств. Но лишь с выпуском Exchange Server 2007 специалисты Microsoft подготовили новые наборы свойств разрешений для Exchange. Довольно любопытно, что в Exchange не используется набор свойств Phone and Mail Options, казалось бы, предназначенный для систем обработки сообщений. До Exchange 2007 все соответствующие атрибуты (их всего 120) входили в один набор свойств — Public Information. В этот набор свойств также входят все extensionAttributes, предназначенные для хранения только общедоступной информации, так как пользователи, прошедшие проверку подлинности, по умолчанию имеют доступ на чтение к этому свойству. Набор свойств Personal Information в Exchange остался неизменным.

Из четырех наборов свойств, для которых разрешение на чтение предоставляется по умолчанию проверенным пользователям на объектах пользователей (то есть General Information, Personal Information, Web Information и Public Information), набор свойств Personal Information представляет наибольший интерес для администраторов, желающих скрыть доступ к определенным данным учетной записи. Этот набор содержит потенциально конфиденциальную информацию, например номер домашнего телефона и адрес сотрудника. Компании не всегда автоматически вносят эти данные в AD, но каждый пользователь может сделать это через разрешения, предоставляемые по умолчанию субъекту безопасности SELF. На рисунке 3 перечислены 47 атрибутов, принадлежащих набору Personal Information в Server 2008 R2.

Рисунок 3. Атрибуты набора свойств Personal Information

Так почему же наборы свойств столь важны для сокрытия данных в AD? Ответ прост. Взгляните на таблицу 1, в которой перечислены разрешения, предоставляемые по умолчанию каждому новому объекту пользователя в AD. Четыре явных разрешения на чтение для прошедших проверку подлинности пользователей (General Information, Personal Information, Web Information и Public Information) назначаются наборам свойств. Вспомните и о более высоком приоритете явных разрешений перед унаследованными запретами, и вам станет ясно, что скрыть данные атрибутов, которые являются частью набора свойств, — непростая задача. Нельзя просто назначить запрет для атрибута объекта на уровне OU и ввести принудительное наследование для соответствующих объектов. Поэтому администраторам необходимо хорошо знать наборы свойств и принадлежащие им атрибуты, чтобы понимать влияние предоставленных разрешений или запретов для определенных атрибутов в AD.

Обратите внимание, что использование сторонних инструментов для управления разрешениями AD обычно помогает только при назначении новых разрешений. Но для сокрытия данных часто требуется удалить разрешения, назначаемые по умолчанию. Эти разрешения необходимо скорректировать в собственных разрешениях каталога (конечно, после проверки и тестирования в лаборатории).

Когда необходимо скрыть данные?

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

* разрешения на чтение по умолчанию, предоставляемые новым объектам AD;

* приоритет унаследованных разрешений в процессе проверки списка ACL;

* группирование атрибутов AD в наборы свойств.

Большинство структур OU ориентированы на группирование объектов одного типа или местонахождение в одной OU. На рисунке 4 показано, каким образом у компании может быть одна OU для управления объектами в Атланте (ATL) и другая для управления объектами в Фениксе (PHX). Обратите внимание, что обе организационные единицы уровня местонахождения имеют вложенные OU, обеспечивающие дальнейшие разделение объектов для каждого региона. Эти подразделения позволяют делегировать различные административные права или применять групповые политики.

Рисунок 4. Образец архитектуры OU

Обратите также внимание на особую вложенную OU с именем Local Admins на рисунке 4. Она должна содержать данные специальной учетной записи для делегированных администраторов региона. Чтобы защитить этих пользователей от потенциальных злоупотреблений и атак с отказом от обслуживания (DOS), полезно скрыть от конечных пользователей организационные единицы Local Admins.

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

Существуют и технические причины скрывать данные в AD, особенно если требуется ограничить способность делегированных администраторов связывать объекты AD. Добавляя пользователя как члена группы, вы связываете этого пользователя с группой. Вы не изменяете свойства объекта пользователя, только атрибут членства группы (ссылка вперед). Предположим, что в нашей образцовой структуре OU делегированный администратор располагает всеми нужными разрешениями для управления группами и пользователями в Фениксе (OU PHX), но не в Атланте (OU ATL). По умолчанию этот администратор все же может добавлять пользователей из ATL OU (или из другого места в лесу AD) в группы в OU PHX. Компании обычно мирятся с этой особенностью, которая обеспечивает простой способ доступа через границы к общим ресурсам, таким как файловые серверы, или позволяет заменить администратора сайта на время отпуска.

Однако Интернет-провайдеры и другие компании, к конфиденциальности которых предъявляются повышенные требования, часто запрещают администраторам добавлять пользователей из-за пределов их зоны ответственности (то есть находящихся вне управляемых ими организационных единиц) в свои группы. В таких случаях необходимо также скрыть пользователей, находящихся вне организационных единиц, управляемых делегированным администратором, чтобы он не мог добавить этих пользователей в свои группы или к любым другим связанным атрибутам, таким как атрибут manager пользователя или атрибут managedBy таких объектов, как принтеры, группы или OU.

Наконец, компании могут пожелать скрыть данные, сохраненные в специфических атрибутах различных типов объектов в AD, вместо того чтобы скрывать объект целиком. Такая необходимость зависит от конфиденциальности данных. Например, если компания хранит номера сотрудников в AD, то эти сведения полезно скрыть от всех пользователей, кроме инспекторов отдела кадров. Аналогично, компания может ограничить доступ к атрибуту, содержащему номер домашнего телефона. Чаще компании добавляют собственные атрибуты в схему AD для хранения дополнительной информации, относящейся к другим приложениям. Среди типичных расширений схемы — атрибуты для центров затрат или особых ролей, специфических для приложений, или даже атрибуты, хранящие идентификаторы маркеров, в которых AD используется как LDAP-сервер. Многие из таких специальных атрибутов видны конечным пользователям и администраторам с низким уровнем полномочий, например операторам справочной службы. Информация в таких специальных атрибутах, если она попадет в руки злоумышленников, может представлять угрозу для компании.

Подводя итог, перечислим наиболее распространенные причины для сокрытия данных в AD:

* защита административных учетных записей от злоупотреблений и атак с отказом от обслуживания (DOS);

* юридические обязательства, приводящие к необходимости скрыть определенные объекты;

* соблюдение принципа минимальных полномочий для специальных административных задач, в частности предоставление делегированным администраторам групп права изменять членство для пользователей только в своей административной области;

* стремление обеспечить предоставление конфиденциальных данных в атрибутах только авторизованным пользователям.

Возможные подходы к сокрытию данных

Как правило, данные в AD требуется скрыть от неавторизованных пользователей, предоставляя доступ только тем, кто имеет явные разрешения на просмотр, например через членство в соответствующей группе безопасности. Поэтому предпочтительное решение — ограничить доступ (запрет по умолчанию) к объектам или атрибутам, предоставляя права доступа только определенным субъектам безопасности (например, группам безопасности). Это лучше, чем открыть общий доступ (разрешить по умолчанию) к объекту (например, всем пользователям, прошедшим проверку подлинности), а затем пытаться запретить доступ неавторизованным пользователям. Также необходимо различать, какие данные требуется скрыть: объект целиком или только определенные его атрибуты?

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

Как и везде, здесь важно понять проблему, прежде чем приступать к разработке решения. В данной статье я рассказал о том, почему сокрытие данных в AD представляет собой такую трудную задачу, привел примеры ситуаций, в которых сокрытие необходимо, и представил обзор возможных решений. В следующих статьях серии будет подробно описано, как использовать доступные средства для сокрытия данных в AD или данных, хранящихся в определенных атрибутах объектов AD. Во второй статье будет рассказано, как применять обычные разрешения объектов и атрибутов AD, активировать режим перечисления объектов (List Object Mode) в лесу и корректировать назначаемые по умолчанию параметры безопасности объектов в AD. В третьей статье будет описана корректировка встроенных наборов свойств. И четвертая статья будет посвящена тому, как использовать бит конфиденциальности и настроить фильтрованный набор атрибутов, чтобы указать, какие атрибуты реплицируются в контроллеры домена только для чтения (RODC).