Active Directory: Защитите свои данные Active Directory

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

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

Проблемы защиты Active Directory

Управление моделью защиты Active Directory — не такое уж простое дело. Природа иерархической службы каталогов, которая служит многим целям (каталоги приложений, каталоги данных для аутентификации, каталоги данных для управления рабочими столами и т.д.) подразумевает, что может быть несколько моделей защиты. Еще более важно то, что если вы заранее не выработаете подход к управлению защитой Active Directory, ситуация быстро выйдет из-под контроля.

Рассмотрим, например, простую функцию — делегирование управления учетными записями пользователей в Active Directory. Поскольку модель защиты Active Directory имеет детализированную структуру, казалось бы, простая функция управления учетными записями пользователей может вырасти в невообразимый список операций по делегированию разрешений:

• Разрешение создавать объекты «пользователь»
• Разрешение удалять объекты «пользователь»
• Разрешение перемещать объекты «пользователь»
• Разрешение на свойства объектов «пользователь» (которые могут делиться на ценные свойства, такие как отдел, руководитель или членство в группах, и малозначимые свойства, такие как номер телефона и адрес офиса)
• Разрешение сбрасывать пароль пользователя или разблокировать его учетную запись
• Разрешение управлять тем, кто может изменять разрешения пользователя

Конечно, этот список не является исчерпывающим, но он показывает потенциальную сложность управления делегированием всего лишь одной функции. Учтите, что каждая из этих операций (или как минимум их группы) может делегироваться разным подгруппам. Кроме того, эти наборы разрешений могут варьироваться в зависимости от организационных подразделений (organizational unit, OU), к которым относятся пользователи. Добавьте в этот коктейль то, что родительские объекты в Active Directory могут наследовать разрешения от своих потомков (например, можно переместить разрешения из OU Marketing в OU Users, находящийся в Marketing). Можно видеть, что все, в самом деле, запутается, если вы не будете осторожны.

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

Введение в модель защиты Active Directory

Для знакомства с моделью защиты Active Directory необходимо полностью разобраться, как структурирована Active Directory. Как и реляционные базы данных, Active Directory содержит схему, определяющую доступные классы объектов и связанные с ними атрибуты. Объект «пользователь» в Active Directory — экземпляр класса «пользователь», определенного в схеме. Этот объект «пользователь» согласно схеме содержит набор таких атрибутов как имя, фамилия, отдел, руководитель, номер телефона и т. д.

Кроме того, с каждым объектом в Active Directory связан дескриптор защиты (security descriptor). Дескриптор защиты определяет разрешения на объект. Например, это может быть набор разрешений (или список управления доступом — Access Control List, ACL) на объект «пользователь», показываемый в Active Directory Users and Computers.

ACL состоит из набора участников безопасности (security principals), как правило, пользователей или групп, имеющих права на данный объект, и прав или разрешений, сопоставленных каждому участнику безопасности. Каждое разрешение может быть одного из двух видов: Allow или Deny. Allow используется по умолчанию. В этом случае участник безопасности получает разрешение. Если выбрано значение Deny, это означает явный запрет для участника безопасности. В сущности, если объект наследует разрешения от своего родителя и для какого-то разрешения происходит смешение записей управления доступом (Access Control Entries, ACE) Allow и Deny, как правило, побеждает Deny.

Стандартные и расширенные права

Не все классы объектов Active Directory имеют одинаковые наборы разрешений. Это замечательно, поскольку означает, что можно адаптировать разрешения к типу объекта, к которому они относятся. Рассмотрим следующий пример: разрешение  «запуск репликации» (trigger replication) объекта «контекст именования» Active Directory позволяет делегировать полномочия тем, кто вправе запускать репликацию между контроллерами домена. Однако запуск репликации не имеет отношения к объекту «пользователь». По сути, с каждым объектом связан набор «стандартных прав». В него входят следующие знакомые права:

• Read (чтение)
• Write (запись)
• List (выводить в списках)
• Create (создание)
• Delete (удаление)
• Read и Write Properties (чтение и запись свойств)

Помимо стандартных прав, у класса схемы могут быть расширенные права. Знакомый пример расширенных прав — разрешения объекта «компьютер». У компьютера имеются такие разрешения как «Read и Write host name attributes» (чтение и запись атрибутов имени хоста), специфичные для объектов класса «компьютер».

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

Введение в наследование разрешений

Еще один аспект, который усложняет модель защиты Active Directory, — понятие наследования разрешений в иерархии Active Directory. Набор разрешений для вершины домена может «просочиться» через вложенные OU в объекты, находящиеся на самых низких уровнях иерархии домена.

Этим наследованием можно управлять, причем как сверху вниз, так и снизу вверх. Например, предположим, что вы задаете разрешения для объектов «пользователь» в иерархии OU, состоящее из OU верхнего уровня Marketing и двух дочерних OU с именами Users-East и Users-West. Вы хотели бы воспользоваться наследованием и задать разрешения для всех объектов «пользователь» на уровне OU Marketing и распространить их на все объекты «пользователь» в обоих дочерних OU. Это можно сделать, создав новую ACE в ACL OU Marketing (например, с помощью Active Directory Users and Computers) и после задания разрешений применить их ко всем Descendant User Objects (потомкам объектов «пользователь»).

Если вы обслуживаете OU Users-East, вы можете решить, что разрешения, заданные на верхнему уровне, вам не подходят. Если у вас достаточно разрешений, вы можете отключить наследование, заданное на уровне OU   Marketing. Для этого достаточно просто снять флажок в разделе Advanced редактора ACL в Active Directory Users and Computers. И тогда цепочка наследования разорвется.

Введение в делегирование

В контексте Active Directory делегирование — процесс предоставления разрешений на объекты Active Directory. Оно позволяет пользователям и группам выполнять те или иные операции с объектами Active Directory. Делегирование подразумевает, что вас должен быть четко проработанный план предоставления «правильным» пользователям «правильных» разрешений на «правильные» объекты Active Directory в масштабе всей вашей структуры Active Directory.

Примером делегирования может быть группа Help Desk Admins (администраторы справочной службы), к которой относятся все сотрудники службы поддержки. Вы можете предоставить этой группе право сбрасывать пользовательские пароли для всех объектов «пользователь» вашего домена Active Directory. Это позволит им выполнять одну из своих основных должностных функций. Другой типичный пример делегирования — разрешение администраторам присоединять компьютеры к домену. Это делегируемое разрешение на объекты «компьютер», обычно применяемое к OU, в котором находятся объекты «компьютер».

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

Имеется множество данных Active Directory, которые можно и нужно защитить, но не все они относятся к системе идентификации. Ниже перечислен список самых важных областей, с которых надо начать защиту идентификационных данных Active Directory:

Свойства пользователей: Атрибуты ваших пользователей могут быть ценными и требовать делегирования, а могут и не быть. Имеются определенные атрибуты пользователя, такие как Job Title (должность), Department (подразделение) и Manager (руководитель), которыми часто управляет отдел кадров. Если Active Directory интегрирована с системой отдела кадров, этими атрибутами может управлять система отдела кадров. В таком случае следует запретить всем пользователям модифицировать эти атрибуты по своему усмотрению.

Членство в группах: группы можно использовать для управления доступом к различным ресурсам — от общедоступных файловых серверов до ценной информации в базах данных. Управление тем, кто имеет разрешения на изменение членства в группах, — пожалуй, один из первых шагов, которые вы должны предпринять, приступив к делегированию разрешений в Active Directory. Оно заключается в задании того, кто может записывать в атрибут Members (члены) объектов Active Directory «группа». Пользователь с таким разрешением может изменять членство в группах.

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

Инструменты делегирования

При делегировании вы получите кое-какую помощь. Она придет в виде мастера Active Directory Users and Computers Delegation of Control (DoC) Wizard. DoC Wizard будет доступен всякий раз, когда вы щелкаете правой кнопкой мыши объект-контейнер (такой как домен или OU) в Active Directory Users and Computers. По сути, он превращает набор стандартных операций, которые могут потребоваться при делегировании в Active Directory, в шаблон.

Кроме того, он позволяет создавать собственные операции делегирования, выбирая классы объектов и задавая, какие права нужны для этих классов. DoC Wizard «штампует» набор разрешений, запрошенных вами для контейнера, с которым вы работаете.

DoC Wizard упрощает простые операции делегирования Wizard, но имеет несколько недостатков:

• Поддерживает только небольшой набор операций делегирования (хотя вы можете его расширить).
• Это одномоментное делегирование. Другими словами, состояние делегирования, которое вы только что выполнили, не сохраняется. Разрешения просто проставляются для объектов Active Directory, которые вы выбрали. После выполнения делегирования вы не можете модифицировать его с помощью мастера. Вы должны работать на уровне объектов и вручную редактировать разрешения прямо в ACL.
• DoC Wizard не позволяет получить общее представление о делегировании в масштабе всей структуры Active Directory. Поскольку он, в конечном счете, просто проставляет привилегии, нет возможности «сохранить следы» того, какие делегирования вы выполнили, без просмотра ACL каждого интересующего вас объекта Active Directory.

Наилучшие методики делегирования в Active Directory

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

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

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

Примите во внимание все эти аспекты и то, как они влияют на общий уровень безопасности  данных, хранящихся в Active Directory. Комбинируя и анализируя все эти методики, вы сможете обеспечить для своих данных Active Directory высокий уровень безопасности.