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), обычно, юзеров либо групп, имеющих права на данный объект, и прав либо разрешений, сопоставленных каждому участнику безопасности. Каждое разрешение может быть 1-го из 2-ух видов: 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 и 2-ух дочерних 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 высочайший уровень безопасности.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.

скачать Discord торрент бесплатно и без регистрации