Интеграция контроллеров RODC в Active Directory

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

Отказ от выполнения рекомендаций в сфере защиты данных может вызвать опасность взлома или разрушения данных. Разумеется, вы должны защищать свою сеть от катастрофических сбоев, но при этом ваши контроллеры доменов должны сохранять способность предоставлять необходимые услуги. Если в организационной структуре компании имеются филиалы или дополнительные офисы либо если вам нужно делиться данными AD с другими пользователями, находящимися по ту сторону сетевого экрана, лучшее решение будет состоять в том, чтобы включить в структуру AD контроллеры доменов только для чтения read-only domain controller (RODC). В этой статье я хочу рассмотреть ситуации, в которых применение контроллеров RODC наиболее целесообразно, и познакомить вас с решениями, которые нужно будет принять для корректной реализации контроллеров RODC.

Ограничения на использование DC с возможностью записи

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

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

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

Каждый наделенный полным набором средств для записи контроллер домена в лесу AD содержит копии всех атрибутов AD, поскольку контроллер домена главного офиса автоматически реплицирует сведения, такие как идентификаторы служащих, на контроллеры доменов филиалов вскоре после ввода этих данных в каталог AD. Это обстоятельство не создает проблем для контроллеров доменов, которые содержатся под замком в центре обработки данных центрального офиса. А вот к размещенным в филиалах контроллерам доменов, не имеющим физической защиты, сказанное не относится. Если намеревающиеся совершить атаку злоумышленники или конкуренты решат выкрасть данные, касающиеся вашей организации, им достаточно будет взломать один из филиалов фирмы и «дать тягу» с плохо защищенным контроллером домена. В базе данных, хранящейся на контроллере домена, злоумышленники обнаружат информацию по всем сотрудникам, включая персонально идентифицируемые данные, утрата которых немедленно создаст проблемы в плане соблюдения требований регулирующих органов (если, конечно, в вашей организации такие данные хранятся в базе данных AD). Но хуже всего то, что в распоряжении потенциального взломщика окажутся все имена пользователей и пароли сотрудников. Чтобы защитить внутренние ИТ-ресурсы, вам пришлось бы повторно создать пароль для каждой учетной записи.

Решения с использованием RODC

Разработчики Microsoft впервые реализовали контроллеры RODC в версии Windows Server 2008. И хотя многие администраторы акцентируют внимание на том, что RODC предназначены только для чтения, главное достоинство этих систем проистекает из того обстоятельства, что любой контроллер RODC можно настроить таким образом, чтобы он содержал лишь ограниченное число паролей AD.

Основное назначение данного подмножества паролей — минимизировать ущерб, который может быть нанесен фактом утери контроллера домена. Посмотрим на рисунок 2, иллюстрирующий замену контроллеров доменов филиалов системами RODC. Администратор домена может использовать встроенную в систему RODC политику репликации паролей Password Replication Policy (PRP), чтобы идентификация учетных записей осуществлялась только для тех лиц, которые фактически работают на данном сайте (скажем, для Джима и Бренды на сайте A и для Боба и Джейн на сайте B). Пароли для этих пользователей кэшируются только на локальном RODC. По умолчанию на самом контроллере RODC пароли не кэшируются, хотя на нем кэшируются некоторые атрибуты.

Отдельные атрибуты фактически кэшируются на контроллере RODC. Эти атрибуты необходимы для того, чтобы соответствующий RODC мог выполнять свою работу и четко отслеживал все, что происходит в пределах его полномочий. Атрибуты LastLogon, LogonCount и BadPwdCount записываются на локальном RODC для того, чтобы обеспечивать успешную регистрацию в системе. Благодаря этим атрибутам политики в области безо­пасности могут измеряться на базе операций, выполняемых на локальном контроллере RODC. Дополнительные атрибуты, записываемые на контроллерах RODC по умолчанию, включают атрибуты Last Interactive Login (если он активирован), ms-DS-Site-Affinity и LastLogonTimeStamp. На случай неудачных попыток регистрации в системе в базу данных локального RODC записываются атрибуты BadPwdTime, BadPwdCount, Last (failed) Interactive Login (если он активирован) и ms-DSSite-Affinity.

По умолчанию PRP контроллера RODC создает два многозначных атрибута AD, которые содержат участников безопасности, таких как учетные записи пользователей, компьютеры или группы: атрибут msDS-Reveal-OnDemandGroup, который рассматривается как группа Allowed RODC Password Replication Group в контейнере Users и в более общем виде считается атрибутом Allowed List, и атрибут msDS-NeverRevealGroup, который рассматривается как группа Denied RODC Password Replication Group в контейнере Users и нередко именуется списком Denied List. К числу участников безопасности в списке Allowed List относятся те учетные записи пользователей, пароли которых могут кэшироваться на контроллере RODC. В общем случае этот список должен содержать пользователей (обычно посредством указания их членства в группах), которые работают в том же филиале, где установлен соответствующий контроллер RODC. Другой набор участников безопасности включает в себя тех участников, которые ни в коем случае не должны реплицироваться на контроллерах RODC, включая старших администраторов, учетные записи служб и все учетные записи доменов, такие как общедоменная учетная запись Kerberos KRBTGT, ибо все они предполагают использование дополнительных мер защиты.

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

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

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

Защита от искажений

Односторонняя репликация с контроллеров доменов с возможностью записи на контроллеры RODC обеспечивает дополнительную защиту против непреднамеренного или умышленного включения искаженных данных в AD. Возьмем ситуацию, когда потенциальный злоумышленник не планирует собирать имена пользователей и учетные записи, а намеревается вместо этого заполнить ваш домен AD «мусором» или поврежденными данными. Или представим себе опасения администраторов тестовых сетей на изолированных узлах AD, которым необходимо вступить во взаимодействие с AD. В каждом из этих случаев загрязнение базы данных AD осуществляется с необычайной легкостью. Если потенциальный взломщик или тестовая сеть внесет в данные хотя бы одно изменение, это изменение быстро распространится по всему лесу. Непреднамеренная или умышленная перезапись данных может произойти в мгновение ока, а встроенные средства репликации AD разнесут поврежденные данные по всей организации.

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

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

Имейте в виду, что описанная выше защита папки SYSVOL в полной мере реализуется лишь в том случае, когда ваше средство репликации AD обновлено до уровня DFS Replication (DFSR), то есть не использует более старое решение на базе технологии File Replication Service (FRS). Потенциальный взломщик (или неловкий локальный администратор, опечатки которого приводят к непредсказуемым последствиям) все еще сможет внести в папку SYSVOL те или иные изменения, но, если вы обновите средство репликации AD до уровня DFSR, механизм репликации SYSVOL распознает такое изменение и удалит представляющие опасность данные.

По этой причине (хотя и по другим тоже) обновление механизма репликации SYSVOL с уровня FRS до уровня DFSR лучше всего осуществлять при первой же возможности. Информацию об обновлении SYSVOL, включая подробное описание этапов реализации, можно найти в материалах Microsoft SYSVOL Migration Series, размещенных в Интернете по адресу go.microsoft.com/fwlink/? LinkId=119296.

Свобода маневра для администраторов

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

Такие люди могут представлять угрозу для ИТ-среды, если в круг их обязанностей входит административное управление локальными контроллерами доменов. Напомню, что зарегистрироваться на контроллере домена можно лишь в том случае, если вы входите в состав групп Administrators или Domain Administrators. «Помощник ИТ-профи» из филиала, где расположены контроллеры домена с возможностью записи, для выполнения своих задач по перезагрузке, установке исправлений или осуществления других регулярных процедур обслуживания компьютеров может потребовать для себя широчайшие полномочия по доступу к объектам домена.

Так вот, контроллеры RODC предоставляют нам дополнительную свободу маневра — свободу делегировать административные полномочия для управления контроллерами доменов только для чтения. Получающий такие полномочия сотрудник, в сущности, имеет привилегии локального администратора на данном сервере, но не имеет дополнительных привилегий администратора домена, которые необходимы для управления службой AD. Эта возможность делегирования прав администратора открывает дорогу для использования RODC просто в целях совершенствования управления — даже в тех ситуациях, в которых защита учетных записей и паролей необязательно входит в число основных приоритетов. Более подробные сведения об обеспечиваемой контроллерами RODC гибкости в вопросах администрирования можно найти в статье «Утилита Ntdsutil в составе Windows Server 2008», опубликованной в этом же номере журнала.

Защита персональных данных с помощью отфильтрованных наборов атрибутов

Используемый по умолчанию экземпляр RODC получает полную копию раздела службы каталогов домена, включая все объекты и связанные с ними значения атрибутов. По умолчанию RODC необязательно защищает от компрометации пользовательских данных. Однако контроллеры RODC оснащены встроенной службой, которая определяет, какие атрибуты и значения реплицируются на все контроллеры доменов для чтения. Этот механизм строится на принципе «все или ничего» в том смысле, что если мы исключаем какой-либо атрибут из репликации, это исключение будет применяться сразу же ко всем контроллерам RODC.

Данный механизм использует отфильтрованный набор атрибутов Filtered Attribute Set (FAS), который состоит из динамического списка атрибутов, не реплицируемых ни на один контроллер RODC в лесу AD. Назначение атрибутов, являющихся частью набора FAS, — защита конфиденциальных пользовательских данных, таких как идентификаторы служащего или номера социального страхования. Добавление таких значений в набор FAS означает, что в случае компрометации какого-либо RODC в офисе филиала такие значения не будут присутствовать на этом контроллере.

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

Active Directory в демилитаризованной зоне

Наконец, контроллеры RODC могут применяться в ситуациях, когда данные AD требуются по ту сторону традиционных барьеров, защищающих корпоративные сети. Организации, приложения которых размещаются в Интернете, или организации, которым требуются службы аутентификации, действующие в Сети, могут укрепить защиту этих служб с помощью контроллеров RODC, размещенных внутри демилитаризованной зоны DMZ. Хотя обычно проникновение AD в DMZ допускается лишь в крайних случаях, размещение контроллеров RODC в DMZ может способствовать повышению защиты данных, связанных с пользователями, их паролями и со значениями их атрибутов.

Внедрение RODC в DMZ представляет собой сложный процесс, который во многих случаях может привести к нарушению сложившихся политик безопасности — в первую очередь в связи с большим числом исключений брандмауэра, необходимых для осуществления трафика AD. Сведения об использовании контроллеров RODC в DMZ можно найти в статье Microsoft «Active Directory Domain Services in the Perimeter Network (Windows Server 2008)», опубликованной по адресу technet.microsoft.com/en-us/library/dd728034 (WS.10).aspx.

Безопасность AD — прежде всего

Работа любого участка сети Windows обеспечивается инфраструктурой AD, поэтому полная безопасность данной инфраструктуры имеет первостепенное значение. Когда в состав вычислительной среды входят офисы филиалов, лишенные необходимых средств физической защиты, обеспечение безопасности сети требует перестройки представлений о контроллерах доменов. Контроллеры доменов только для чтения — превосходное решение для уменьшения уязвимости контроллеров доменов, а также для снижения ущерба от утраты такого контроллера. Системы RODC не являются необходимыми для каждой сети, поэтому, прежде чем принимать решение об их использовании, следует тщательно проанализировать структуру вашей службы AD.

Грег Шилдс (virtualgreg@concentratedtech.com) — независимый автор и консультант по вопросам ИТ. Имеет сертификат Microsoft MVP, является партнером и главным технологом компании Concentrated Technology