Скрываем данные в Active Directory с помощью разряда конфиденциальности

.

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

Использование разряда конфиденциальности

Последний из упомянутых выше методов сокрытия конфиденциальных данных в AD основан на применении разряда конфиденциальности. Этот компонент был введен в AD специально для поддержки другого относящегося к безопасности компонента Windows Server 2003 SP1 – механизма перемещения учетных данных Credential Roaming, официально именуемого «службой управления цифровыми удостоверениями» Digital Identity Management Service (DIMS).

DIMS расширяет возможности хранения главного ключа пользователя, применяемого для зашифрованных данных, например в шифрующей файловой системе EFS. Ключ обычно хранится в профиле пользователя, что создает проблемы, если пользователь работает на нескольких компьютерах и, следовательно, имеет несколько главных ключей. Перемещаемые профили позволяют задействовать один и тот же главный ключ на нескольких компьютерах, но такие профили имеют свои недостатки. Благодаря введению DIMS файлы главных ключей можно хранить в AD, расширив схему путем ввода дополнительных атрибутов (например, ms-PKI-DPAPIMasterKey и ms-PKI-AccountCredentials) для объекта схемы userClass. Расширение схемы не происходит автоматически, атрибуты следует добавить отдельно.

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

Как говорилось в предыдущих статьях серии, каждый пользователь обладает правом чтения всех атрибутов своего пользовательского объекта через разрешение Read All Properties, предоставляемое по умолчанию субъекту безопасности SELF. Кроме того, во многих компаниях разрешение Read All Properties предоставляется специальной группе в отношении целого дерева объектов (если не всего домена или леса). Используя такой подход, можно, например, разрешить определенным учетным записям служб, не обладающим полномочиями администратора домена, считывать любые данные из AD.

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

Разряд конфиденциальности был введен в Windows Server 2003 SP1. Как видно из названия, он позволяет настраивать определенные атрибуты в AD как конфиденциальные. При этом для получения доступа на чтение этих атрибутов обычных привилегий для чтения оказывается недостаточно.

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

1. Разряд конфиденциальности устанавливается как разряд 7 (=128 в десятичном коде) для свойства searchFlags соответствующего объекта attributeSchema в схеме AD. Чтобы обозначить атрибут как конфиденциальный, к любому существующему значению добавляется 128.

2. Для предоставления права доступа к конфиденциальному атрибуту ограниченному кругу пользователей или групп необходимо дать им разрешение CONTROL_ACCESS в отношении данного атрибута. При этом в AD применяются дополнительные проверки безопасности в рамках контроля доступа на чтение выбранных атрибутов.

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

Атрибутами базовой схемы являются объекты attributeSchema категории 1, идентифицируемые по включенному биту 4 (= 16 в десятичном коде) атрибута SystemFlags. Однако не все стандартные атрибуты принадлежат категории 1. В Windows 2000 схема AD насчитывала 863 стандартных атрибута; в Windows Server 2003 – уже 1070. В Windows Server 2003 R2 был введен еще 81 атрибут (главным образом, для служб для UNIX (SFU) и репликации DFS (DFSR)). С тех пор каждая версия Windows Server пополняет базовую схему новыми атрибутами. В Windows Server 2012 базовая схема насчитывает 1264 атрибута.

Чтобы выяснить, какие атрибуты принадлежат категории 1, воспользуемся инструментом LDAP-запросов LDP.exe, с помощью которого найдем все объекты attributeSchema с включенным разрядом 4. Можно просто вывести все объекты attributeSchema вместе со свойством systemFlag, применив фильтр (например, ObjectCategory = attributeSchema), и проанализировать результаты с помощью другого инструмента, например Microsoft Excel. Однако удобнее составить LDAP-запрос, который сразу выдаст конечный результат. Однако нельзя выполнить поиск для простого десятичного значения в свойстве systemFlag, ведь атрибут может иметь и другие разряды, установленные в systemFlags. Поэтому LDAP-запрос необходимо дополнить поразрядным тестом, добавив в поисковый фильтр идентификатор RuleOID 1.2.840.113556.1.4.803. Для поразрядных операций существует два идентификатора RuleOID, различаемых по правилам сопоставления: 1.2.840.113556.1.4.803 (условие «И», то есть «истина» только при совпадении всех разрядов десятичного значения) и 1.2.840.113556.1.4.804 (условие «ИЛИ», то есть «истина» при совпадении любого разряда десятичного значения). В результате наш поисковый фильтр LDAP будет выглядеть так:

(&(objectCategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=16))

Ожидаемое значение превышает 1000, поэтому запрос нужно сделать постраничным в программе LDP. Откройте окно параметров поиска Search Options и в качестве типа поискового запроса Search Call Typ) выберите Paged, как показано на экране 1.

Экран 1. Указание вывода результатов постранично

В поле Attributes введите идентификатор объекта (OID) 1.1, чтобы возвращались только отличительные имена (DNS) без атрибутов. В зависимости от используемой версии LDP, поле Attributes может присутствовать только в окне поиска, где также можно ввести значение 1.1 и получить аналогичный результат.

Результат постраничного запроса к контексту именования схемы AD Windows Server 2003 с применением фильтра, показанного на экране 1, содержит 1 007 атрибутов категории 1 (см. экран 2). В Windows Server 2003 R2 число атрибутов категории 1 в AD не увеличилось.

Экран 2. Результат постраничного запроса к контексту именования схемы AD Windows Server 2003

Результаты выполнения этого запроса говорят о том, что многие потенциальные кандидаты в конфиденциальные атрибуты AD принадлежат категории 1 и поэтому не могут применяться в комбинации с разрядом конфиденциальности. Сюда относятся атрибуты, перечисленные в таблице 1.

Изменим запрос LDAP так, чтобы выводились только атрибуты, не относящиеся к категории 1 (то есть без включенного разряда 4 systemFlags). Это можно сделать путем добавления к фильтру отрицания NOT:

(&(objectCategory=attributeSchema)(!(systemFlags:1.2.840.113556.1.4.803:=16)))

В случае Windows Server 2003 результат запроса включает 63 атрибута, а в случае Windows Server 2003 R2 – 144 атрибута, каждый из которых можно применять с разрядом конфиденциальности. Для Windows Server 2012 запрос возвращает 164 атрибута. В таблице 2 приведены только те атрибуты в лесу AD Windows Server 2003, которые могут использоваться с объектом класса пользователя, что сводит их число к 25.

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

Однако некоторым компаниям может потребоваться, скажем, хранить в AD идентификаторы сотрудников (employeeID) и сделать атрибут, хранящий эти данные, конфиденциальным, чтобы только авторизованные пользователи могли его читать и редактировать. В этом случае организация может предпочесть для хранения этих данных вместо атрибута employeeID использовать атрибут employeeNumber, который не принадлежит категории 1 и поэтому может быть настроен как конфиденциальный. Поскольку свойство searchFlag атрибута employeeNumber пусто, достаточно записать в него значение 128, как показано на экране 3.

Экран 3. Сокрытие атрибута employeeNumber

Если свойство searchFlags не пусто, то число добавляется к существующему. Свойство searchFlags определяет различные характеристики атрибута, в частности, индексирован ли он (разряд 1) или остается в объекте-захоронении при удалении (разряд 3). Подробнее о searchFlags рассказано в статье Microsoft «Search-Flags Attribute (Windows)» (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679765(v=vs.85).aspx).

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

Экран 4. Сообщение об ошибке при попытке установить разряд конфиденциальности для атрибута категории 1

Как только этот флаг установлен (и кэш схемы обновлен), заполненный атрибут становится невидимым для обычного пользователя, наделенного правом чтения всех атрибутов (Read All Attributes) через стандартные разрешения, предоставляемые субъекту безопасности SELF. На экране 5 показано содержимое атрибута до (слева) и после (справа) активации разряда конфиденциальности.

Экран 5. Содержимое атрибута до (слева) и после (справа) активации разряда конфиденциальности

Сразу возникает другой вопрос: как установить разрешение CONTROL_ACCESS для доступа к скрытому атрибуту? В Windows Server 2003 SP1 не предусмотрены средства командной строки, позволяющие устанавливать такое право доступа на уровне атрибута. Однако в Windows Server 2008 и более новых версиях обновленный вариант Dsacls полностью поддерживает такую возможность, как показало тестирование на DC под управлением Windows Server 2012.

Синтаксис добавления разрешения CONTROL_ACCESS с помощью Dsacls выглядит так:

DSACLS /G: CA;

При назначении пользователю или группе разрешения CONTROL_ACCESS на уровне свойства необходимо указать отображаемое имя этого свойства (в нашем случае, employeeNumber):

DSACLS «CN=Root-User1,OU=UserAccounts,DC=root,DC=net»
/G rootHR-users:employeeNumber

К сожалению, со времени появления CONTROL_ACCESS отсутствует удобный пользовательский интерфейс для управления этим разрешением. В Windows Server 2012 в этом отношении ничего не изменилось. Однако с момента выхода Windows Server 2003 R2 программа LDP.exe включает мощный редактор безопасности, позволяющий видеть и устанавливать флаг CONTROL_ACCESS для определенного атрибута объекта.

Перейдите к объекту, для которого требуется изменить разрешения. Щелкните на объекте правой кнопкой и выберите «Дополнительно» (Advanced), «Дескриптор безопасности» (Security Descriptor). Всплывает диалоговое окно, где можно задать параметры отображения дескриптора безопасности. Не следует выбирать установку «Дамп текста» (Text dump), при которой дескриптор выгружается в окно вывода. Новый редактор безопасности запускается при использовании установок по умолчанию (см. экран 6).

Экран 6. Новый редактор безопасности

Чтобы предоставить атрибуту employeeNumber разрешение на доступ к управлению, выберите Add ACE (см. экран 7).

Экран 7. Предоставление атрибуту employeeNumber разрешения на доступ к управлению

Управление разрешениями для атрибутов в списке отдельных объектов в AD из пользовательского интерфейса работает не слишком эффективно. Если вам нужно управлять разрешениями доступа к конфиденциальным атрибутам, но вы все еще работаете с AD под управлением версии более ранней, чем Windows Server 2008, рассмотрите вопрос об организации вспомогательного сервера с более новой версией Windows Server. Это позволит вам задействовать более новую версию Dsacls, а дело того стоит!

Набор атрибутов, отфильтрованный по репликации в RODC

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

Для обеспечения этого дополнительного инструмента управления безопасностью логика репликации RODC была дополнена отфильтрованным набором атрибутов (FAS). Этот компонент позволяет снабжать флагами атрибуты в схеме AD, содержание которых не должно реплицироваться на RODC в лесу. Как разряд конфиденциальности, разряд FAS устанавливается через свойство searchFlags контролируемого атрибута; в данном случае это разряд 9 (= 512 в десятичном коде). После этого открытые для чтения и записи DC в лесу будут запрещать репликацию данных соответствующих атрибутов на RODC. Заметим, что для FAS действует то же ограничение, что и для разряда конфиденциальности: его нельзя использовать для атрибутов базовой схемы. Однако FAS отлично работает для любого атрибута, добавленного для расширения схемы AD.

Сохраняйте конфиденциальность

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

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

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

Специалистам Microsoft потребовалось время, чтобы сделать инструмент командной строки Dsacls способным эффективно управлять необходимыми разрешениями на доступ к атрибутам, однако с выходом последних версий серверных продуктов ничто не мешает правильно настроить разрешения AD для сокрытия конфиденциальных данных.