Скрываем данные

Windows_Networking

Скрываем данные в Active Directory с помощью разряда конфиденциальности.
Active Directory (AD) имеет неплохие возможности для назначения объектам разрешений. Эти разрешения можно использовать для предоставления любому субъекту безопасности прав делегированного администрирования учетных записей пользователей, групп или компьютеров. Это позволяет освободить администраторов домена от необходимости выполнять многие повседневные операции. Однако с помощью стандартных разрешений AD сложно сделать конкретные данные видимыми лишь для узкого круга специалистов, в то время как обычные пользователи не должны видеть определенную информацию, либо если данные являются строго конфиденциальными.
В данной серии публикаций, состоящей из четырех статей, рассматриваются методы сокрытия данных в 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 SPI — механизма перемещения учетных данных 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? Конфиденциальные данные могут включать атрибуты, хранящие главные ключи, номера социального страхования сотрудников или их идентификаторы, а также любые сведения, которые в компании считаются секретными. Именно здесь находит применение разряд конфиденциальности.