Обзор One Identity Active Roles. Часть 1

1. Введение
2. История возникновения и развития продукта One Identity Active Roles
3. Архитектура Active Roles
4. Пользовательский интерфейс
5. Функциональные возможности Active Roles
1. 5.1. Обеспечение жизненного цикла учетных записей пользователей
2. 5.2. Контроль содержимого атрибутов объектов
3. 5.3. Репозиторий скриптов
4. 5.4. Рабочие процессы
5. 5.5. Назначение прав доступа и полномочий
1. 5.5.1. Разграничение прав доступа и полномочий к объектам и системам при помощи Active Roles
2. 5.5.2. Контроль членства в группах Active Directory
3. 5.5.3. Профиль полномочий
4. 5.5.4. Управляемые ресурсы
6. 5.6. Средства интеграции с другими системами
7. 5.7. Аудит и отчетность
8. 5.8. Расширение функциональности Active Roles
6. Выводы

Введение

C 2003 года заказчиками и пользователями Active Roles компании One Identity являются более 2500 мировых компаний. Размеры внедрений варьируются от 250 до 800+ тысяч учетных записей в каталоге Active Directory.

Продукт Active Roles многогранен. Он может быть использован в качестве легкой платформы для управления идентификационными данными пользователей в компании — light-weight IDM с быстрым циклом внедрения. Внедрение Active Roles в такой ипостаси может быть первым шагом для компаний в направлении Identity Management / Identity Governance (IDM/IGA). Классические функции IDM-решения доступны в Active Roles при помощи функций жизненного цикла учетных записей пользователей, контроля атрибутов объектов, управления членством в группах Active Directory и др.

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

Рисунок 1. Позиционирование продукта One Identity Active Roles

История возникновения и развития продукта One Identity Active Roles

Первые версии продукта вышли в свет давно. В начале 2000-х годов компания Aelita Software, основной офис разработки которой находился в Санкт-Петербурге, выпустила на рынок продукт под названием Enterprise Directory Manager (EDM), предназначенный в первую очередь для безопасного и контролируемого управления средами на основе каталога Microsoft Active Directory и автоматизации ручных операций управления. Продукт быстро стал очень популярным на западном рынке. Ключевыми заказчиками являлись компании enterprise-уровня: средние и крупные коммерческие, промышленные, финансовые компании (банки), компании госсектора, которые остаются клиентами One Identity и поныне. Служба каталога Active Directory тогда еще только начинала бурно развиваться и захватывать рынок, решение для эффективного управления ею появилось как раз вовремя.

В 2004-м году компания Quest Software приобрела компанию Aelita Software со всеми ее активами. Продукт Enterprise Directory Manager был переименован в Active Roles Server. Череда дальнейших приобретений — в 2012 году Quest Software (в том числе One Identity как ее составная часть) была куплена компанией Dell, в рамках которой было создано подразделение Dell Software. Но в конце 2016 года появилась новая, самостоятельная компания One Identity, флагманским продуктом которой является система управления идентификацией и доступом One Identity Manager — ее мы подробно рассматривали и описывали в наших предыдущих обзорах (часть 1, часть 2, часть 3). Продукт Active Roles также принадлежит компании One Identity и продолжает активно развиваться (текущая версия продукта — 7.3.1). Ему мы и посвятим наш текущий обзор.

Архитектура Active Roles

Ключевой особенностью Active Roles является то, что продукт, будучи ориентирован на работу c каталогом Active Directory, никоим образом не хранит в себе (в своей конфигурационной базе) «копию» Active Directory. Работа ведется с живым Active Directory, напрямую. Но все операции, которые будут выполняться над объектами Active Directory через интерфейсы Active Roles, — в ручном режиме или автоматически — полностью контролируются сервисом Active Roles в реальном времени. Таким образом, Active Roles является некой надстройкой, прокси-сервисом, виртуальным фаерволом — можно назвать по-разному, над службой каталога Active Directory компании. О преимуществах такого подхода (прокси-администрирования) и возможностях, которые он дает, мы более подробно поговорим в статье ниже.

Конфигурационная база продукта (на Microsoft SQL Server) содержит только настройки. Она не является сильно нагруженной, ее объем относительно невелик.

Рисунок 2. Функциональная диаграмма продукта One Identity Active Roles

Такая архитектура дает ряд преимуществ. Одно из них — практически неограниченная масштабируемость. Active Roles прекрасно работает как с маленькими, так и с огромными по количеству объектов средами Active Directory. Среди заказчиков One Identity, которые используют Active Roles для управления своим Active Directory, много таких, служба каталога которых насчитывает сотни тысяч учетных записей пользователей. Здесь стоит также отметить, что никаких ограничений по количеству лесов Active Directory, подключенных к решению Active Roles, количеству доменов в этих лесах, у продукта Active Roles нет. Наличие или отсутствие доверительных отношений между лесами и доменами также роли не играет.

Продукт не требует расширения схемы Active Directory. С другой стороны, он прекрасно работает со средами, где схема Active Directory была расширена (см. более подробно в секции виртуальная схема). Единственное требование — это наличие так называемого функционального аккаунта (на рисунке 2 — func_accnt), который будет использоваться сервисом Active Roles Administration Service для выполнения всех операций в домене (ручных — от имени конечного пользователя либо автоматических). Данный функциональный аккаунт обычно наделяют административными правами в Active Directory. Для каждого управляемого домена (т. е. домена, зарегистрированного для управления в Active Roles) можно указать свой собственный функциональный аккаунт.

Сервис Active Roles Administration Service устанавливается на стандартный сервер под управлением операционной системы Microsoft Windows (2008/2012/2016). Входящий в состав продукта тонкий клиент (веб-интерфейс) требует установки серверной части приложения на Microsoft Internet Information Server (IIS). Как мы уже упомянули, для конфигурационной базы данных используется Microsoft SQL Server (2008/2012/1014/2016/2017). В продуктивной среде рекомендуется использовать отказоустойчивые решения для базы данных Active Roles, такие как Microsoft Cluster Services или SQL AlwaysOn. Для отказоустойчивости и «географического» масштабирования также обычно устанавливают несколько сервисов Active Roles Administration Service, работающих с одной и той же конфигурационной базой.

Пользовательский интерфейс

Для работы пользователей Active Roles предлагает два типа графических интерфейсов: так называемые толстый — на основе технологии Microsoft Management Console (MMC) и тонкий — веб-интерфейс. Оба интерфейса являются полнофункциональными, они работают с Active Directory и другими системами через один и тот же сервис Active Roles Administration Service. Основное отличие в функциональности заключается в том, что настройка продукта осуществляется в основном через MMC-интерфейс. Однако веб-интерфейс является значительно более гибким в плане практической работы, его очень легко кастомизировать (подстраивать) под свои нужды (менять существующие, добавлять собственные формы, команды, поля, настраивать видимость элементов, менять последовательность действий при выполнении каких-то операций, менять внешний облик и т. д.).

MMC-интерфейс

MMC-клиент Active Roles очень похож на всем знакомый Active Directory Users and Computers (ADUC), входящий в комплект стандартной поставки Microsoft Windows. Вид каталога Active Directory, свойства объектов, принцип выполнения действий над ними и пр. выглядят практически одинаково. Никакого обучения использованию нового клиента для администрирования Active Directory (а также Exchange, Skype for Business) не потребуется.

Веб-интерфейс

Как мы уже упоминали, веб-приложение тонкого клиента Active Roles базируется на Microsoft Internet Information Server (IIS). Для работы с ним официально поддерживаются следующие интернет-обозреватели:

• Firefox (версии 36 и выше) на Windows
• Google Chrome (версии 61 и выше) на Windows
• Windows Internet Explorer 11
• Microsoft Edge на Windows 10

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

Локализация

Дистрибутив Active Roles включает в себя языковой пакет для локализации веб-интерфейса продукта. В языковой пакет входят 14 языков, включая русский.

Рисунок 3. Поддержка языков в продукте Active Roles

Функциональные возможности Active Roles

В Active Roles заложено множество функций. Коротко, в общих чертах, их можно описать следующим списком:

• Безопасное и контролируемое управление объектами в каталоге Active Directory. Этому способствуют:
• Проверка эффективных прав доступа в режиме реального времени (т.е. в момент проведения какой-либо операции).
• Гранулярное назначение (делегирование) прав доступа сотрудникам к объектам Active Directory (Exchange, Azure Active Directory, Office 365) на уровне атрибутов через настраиваемые шаблоны.
• Отзыв избыточных прав доступа, их вычистка из Active Directory.
• Наглядность и прозрачность назначения прав доступа. Абстрагирование от иерархической структуры каталога Active Directory — возможность использования динамических выборок нужных объектов и назначения прав доступа к ним.
• Следование и соответствие модели «минимально необходимого набора прав доступа» (least-privilege access model) при разграничении прав доступа к ресурсам и полномочий для выполнения тех или иных задач.
• Полный, подробный аудит действий пользователей и отчетность
• Обеспечение целостности и должного качества данных в Active Directory (в атрибутах объектов) при помощи настраиваемых политик.
• Стандартизация и контроль действий при помощи настраиваемых рабочих процессов (workflow) с возможностью затребовать подтверждение третьих лиц перед внесением изменений (выполнением операции) — согласование изменений.
• Обеспечение жизненного цикла учетных записей пользователей: автоматизация процессов приема сотрудников на работу, кадрового перевода, увольнения с сопутствующей автоматической перенастройкой прав доступа, блокировкой учетных записей.
• Динамически настраиваемый веб-интерфейс под нужды каждой конкретной группы пользователей (администраторов, операторов службы поддержки, рядовых пользователей, руководителей, владельцев ресурсов, систем, серверов и т. п.) — без необходимости кодирования (скриптинга).

Некоторые из упомянутых практических аспектов использования продукта мы более подробно рассмотрим ниже.

Обеспечение жизненного цикла учетных записей пользователей

Active Roles позволяет организовать полноценный жизненный цикл учетных записей сотрудников, включая такие базовые процессы как прием сотрудника на работу, кадровый перевод и увольнение. В западной литературе данные кадровые события часто обозначают аббревиатурой JML — Joiners, Movers, Leavers. Им соответствуют процессы provisioning, update и de-provisioning.

При помощи встроенного механизма синхронизации данных между Active Directory и сторонними системами (например, с источником кадровых данных) эти операции можно полностью автоматизировать. Подробнее подсистема синхронизации данных описана в разделе «Средства интеграции с другими системами» ниже.

Сценарий «Прием нового сотрудника на работу»

В качестве примера рассмотрим такой сценарий: при создании новой учетной записи пользователя (например, при приеме нового сотрудника на работу), необходимо, чтобы:

• Логон-имя учетной записи (sAMAccountName) был создан по шаблону: <первая буква имени> + <фамилия>
• Для дубликатов (Иван Иванов…) автоматически использован суффикс (001, 002…)
• Создан случайный временный пароль из 8-ми символов
• Обязательно указан:
  • отдел, в который принимается сотрудник (выбор из списка допустимых значений)
  • офис (филиал), в котором будет работать сотрудник (выбор из списка)
  • табельный номер (по формату – 8 цифр)
  • занимаемая должность
  • Автоматически создан почтовый алиас (mailnickname) и, соответственно, почтовый адрес согласно шаблона <имя>.<фамилия> с обработкой дубликатов
  • Автоматически создан почтовый ящик на сервере Microsoft Exchange, находящемся в регионе указанного филиала
  • Учетная запись создана в контейнере Active Directory, соответствующем отделу, в который принимается сотрудник
  • Учетная запись автоматически добавлена в группы доступа и списки рассылки Active Directory согласно членства сотрудника в отделе, занимаемой должности и географического положения
  • Создана домашняя папка на файловом сервере, который находится в регионе сотрудника а также предоставлен полный доступ к данной папке для его учетной записи

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

Рисунок 4. Настройка объекта политики в Active Roles для операций первичного создания учетной записи пользователя

Подготовленный объект политики далее связывается с контейнерами Active Directory либо с динамическими контейнерами (в терминологии Active Roles они называются «управляемые единицы» — Managed Units). Правила, заданные в политике, начинают действовать немедленно, после сохранения изменений в объекте политики.

Дополнительно функциональность так называемых динамических групп используется для автоматической настройки членства учетной записи в группах Active Directory.

Сценарий «Кадровый перевод»

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

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

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

Сценарий «Увольнение»

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

• Блокировка учетных записей сотрудника в системах.
• Перемещение учетной записи Active Directory в другой контейнер (Блокированные учетные записи, ожидающие удаления через определенный срок).
• Переименование учетной записи, добавление описания (изменение description).
• Удаление учетной записи из групп безопасности и списков рассылки.
• Очистка атрибутов (выборочно).
• Удаление почтового ящика из «Адресной книги».
• Установка автоответчика (Out-of-Office).
• Перенаправление почты на другой почтовый ящик.

Все эти действия, а также многие другие полностью автоматизируются в Active Roles при помощи тех же самых объектов политик.

Рисунок 5. Настройка объекта политики в Active Roles для операций блокировки доступа

Контроль содержимого атрибутов объектов

При помощи набора правил, которые объединяются в объектах политик — Active Roles Policy Objects, можно контролировать содержимое любых атрибутов объектов, включая генерацию этих значений (например, при создании объекта).

Политики в Active Roles могут быть двух типов:

• Provisioning Policies
• De-provisioning Policies

Первые действуют при операциях создания объектов и изменения их свойств (т. е. используются в таких сценариях, как «прием нового сотрудника на работу», «кадровый перевод»), вторые — при блокировках (сценарий «увольнение»).

Набор правил, которые можно использовать в политиках, достаточно широк. В случаях же, когда встроенных средств настройки правил недостаточно, всегда можно использовать правило script execution. В дополнение к этому продукт поддерживает расширение политик через создание Policy Extension (добавление новых типов правил). Это удобно, т. к. позволяет использовать их многократно, в разных объектах политик, при этом унифицировав их настройку через графический интерфейс.

В качестве примера — реализация следующего сценария при помощи политик Active Roles:

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

Результат действия политики после ее применения в толстом клиенте будет выглядеть следующим образом:

Рисунок 6. Обзор свойств учетной записи пользователя в MMC-интерфейсе Active Roles

В тонком клиенте:

Рисунок 7. Обзор свойств учетной записи пользователя в веб-интерфейсе Active Roles

Выпадающий список формируется автоматически. Никаких действий по кастомизации форм производить не требуется.

Как уже было отмечено, Active Roles полностью поддерживает использование скриптов (VB, Jscript, Perl, PowerShell) в рамках политик, а также предоставляет программный интерфейс (API) для создания новых типов политик (Policy Types) и их расширений (Policy Extensions).

Рисунок 8. Пример настройки скриптовой политики в Active Roles

Программный интерфейс (API), предоставляемый продуктом Active Roles, более подробно рассмотрен в разделе Software Development Kit ниже.

Репозиторий скриптов

Active Roles поддерживает выполнение скриптов (VB, Pearl, PowerShell) как в рамках рабочих процессов, так и в рамках применения объектов политик. Это позволяет использовать платформу Active Roles для консолидации разрозненных скриптовых решений, которые с большой долей вероятности используются в продуктивной среде для автоматизации тех или иных задач. Это позволит обеспечить полный контроль за модификацией и работой скриптовых решений, а также лучшую организацию и прозрачность процессов.

Рисунок 9. Консолидация скриптов в Active Roles — «скриптинг-центр»

Рабочие процессы

Active Roles содержит в себе унифицированный механизм организации и выполнения рабочих процессов (workflow). Данный механизм не требует написания кода (скриптинга) и предлагает очень гибкие настройки. Напротив, нужный процесс может быть настроен при помощи графического интерфейса. С другой стороны, в продукте нет никаких ограничений на использование скриптов, в частности, в рамках рабочих процессов.

Рисунок 10. Пример настройки рабочего процесса в Active Roles

Рабочие процессы Active Roles могут быть двух типов:

• Стартующие по событию
• Стартующие по расписанию

Рассмотрим их более подробно, на примерах.

Согласование изменений

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

Рисунок 11. Запрос на согласование изменений в веб-интерфейсе Active Roles

Согласование изменений выполняется при помощи веб-интерфейса Active Roles. Каждый согласующий (например, сотрудник, который был назначен владельцем объекта — основным или дополнительным) получит уведомление об изменении, которое он может подтвердить или отклонить, зайдя в веб-интерфейс и проведя анализ. Только после одобрения данное изменение вступит в силу.

Рисунок 12. Заявка на согласование в веб-интерфейсе Active Roles

Рисунок 13. Согласование изменения в веб-интерфейсе Active Roles

Автоматизация процессов

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

Назначение прав доступа и полномочий

Разграничение прав доступа и полномочий к объектам и системам при помощи Active Roles

В терминологии Active Roles предоставление каких-либо прав на выполнение действий над объектами Active Directory (и связанных с ним систем) называется «Делегированием» (Delegation). Суть его в следующем.

Благодаря используемой в продукте архитектуре прокси-администрирования (когда все действия в Active Directory выполняются сервисным/функциональным аккаунтом от имени делегированного пользователя — инициатора) отпадает необходимость назначать права доступа тем или иным конечным пользователям напрямую в Active Directory (т. е. модифицировать дескрипторы безопасности объектов Active Directory, будь то organizational units или конечные объекты) — хотя Active Roles никоим образом этого делать не запрещает. Вместо этого необходимые права доступа можно выдать пользователю «внутри» Active Roles, используя шаблоны доступа (Access Templates). В этом случае учетная запись пользователя может не иметь каких-то административных полномочий в самом Active Directory (через членство в административных группах Active Directory, например Domain Admins), но при этом пользователь будет иметь возможность выполнять те или иные привилегированные действия с объектами (разрешенные ему в назначенных шаблонах доступа) через интерфейсы Active Roles. Т. е. продукт по сути позволяет оставить учетные записи пользователей, которым нужны повышенные привилегии в Active Directory — в группе Domain Users (наряду со всеми остальными пользователями) и выдать им необходимые права доступа в Active Roles. Помимо более гибкого и назначения прав доступа и эффективного контроля это позволяет избежать необходимости создания дополнительных «административных» учетных записей сотрудникам (и добавления их в Domain Admins). Тем самым обеспечивается:

• Прозрачность — всегда можно понять, кто, к каким объектам и какие права доступа имеет.
• Безопасность — делегированные пользователи будут видеть только те объекты, к которым у них есть фактические права (и не увидят все остальные).
• Эффективный контроль — права доступа проверяются сервисом Active Roles при выполнении каждого действия над любым объектом.

Делегирование прав доступа в продукте осуществляется через MMC-интерфейс по команде Delegate Control:

Рисунок 14. Делегирование прав доступа в MMC-интерфейсе Active Roles

Далее выбирается учетная запись сотрудника или группа Active Directory, которой нужно предоставить права, шаблон доступа (т. е. какие права нужно предоставить) и объект Active Directory, на который нужно дать права (Organizational Unit), либо динамическая выборка объектов (Managed Unit) — еще один интересный вид объектов Active Roles, позволяющий при выдаче прав доступа (Delegate Control) и применении политик Active Roles (Enforce Policy) абстрагироваться от физической структуры каталога Active Directory. В момент делегирования прав также указывается, нужно ли выдать права только внутри Active Roles, или же синхронизировать их в живой Active Directory (native security).

Особо отметим, что все права доступа, делегированные тем или иным сотрудникам в Active Roles через шаблоны доступа, в любой момент можно перенести (синхронизировать) в Active Directory — в этом случае делегированный сотрудник сможет выполнять те же действия, указанные в шаблоне, через стандартную оснастку Active Directory Users and Computers. Также в любой момент можно забрать права из Active Directory обратно, оставив их только в Active Roles.

Рисунок 15. Выбор режима синхронизации прав доступа из шаблона Active Roles в Active Directory

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

Контроль членства в группах Active Directory

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

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

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

Динамические правила членства в группах

В терминологии Active Roles данная функциональность называется просто — Динамические группы (Dynamic Groups). Смысл в следующем. В консоли Active Roles можно выбрать любую группу Active Directory и задать для нее правила (критерии) членства других объектов в данной группе. Например: включать в группу только сотрудников, у которых атрибут «Отдел» (department) содержит значения «Отдел кадров», «Бухгалтерия» и «Отдел снабжения».

Рисунок 16. Настройка динамических правил членства в группе Active Directory

Рисунок 17. Варианты динамических правил членства в группе Active Directory и результат их применения

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

Выдача прав доступа на время

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

Рисунок 18. Настройка временного членства в группе Active Directory

Active Roles произведет добавление объектов в группу и удаление их из группы в строго указанное время.

Профиль полномочий

Для каждого сотрудника (учетной записи пользователя) в Active Roles легко можно посмотреть, какими ресурсами и каким полномочиями он обладает — так называемый «Профиль полномочий» (Entitlement Profile).

Рисунок 19. Просмотр «профиля разрешений» пользователя в веб-интерфейсе Active Roles

Управляемые ресурсы

Active Roles для каждого конкретного пользователя также легко позволяет вывести список объектов (учетных записей, групп, других ресурсов), для которых он является владельцем.

Рисунок 20. Отображение списка «управляемых ресурсов» для владельца в веб-интерфейсе Active Roles

При этом в Active Roles поддерживается назначение как «Основного владельца» (Primary Owner), так и «Дополнительных владельцев» (Secondary Owners).

Каждый владелец может видеть все «свои» объекты по команде «Управляемые ресурсы» (Managed Resources) в веб-интерфейсе и производить с ними какие-то действия (разрешенные при помощи функциональности делегирования прав доступа и полномочий). Функциональность назначения владельцев учетных записей, групп и других типов объектов часто используется при настройке процессов согласования.

Средства интеграции с другими системами

Active Roles предлагает широкий набор средств для интеграции решения с другими системами, который включает встроенный полнофункциональный сервис синхронизации (Synchronization Service), PowerShell модуль с набором командлетов (Management Shell), а также ряд программных интерфейсов, таких как SPML-провайдер и ADSI-провайдер. Программные интерфейсы и способы интеграции детально, с примерами описаны в Software Development Kit (SDK), который также включен в продукт.

Synchronization Service

Встроенный сервис синхронизации — Active Roles Synchronization Service — позволяет подключаться и работать со следующими типами систем:

• Microsoft Active Directory Domain Services с функциональным уровнем домена или леса от Windows Server 2008 и выше;
• Microsoft Active Directory Lightweight Directory Services (AD LDS);
• Microsoft Exchange Server 2016, 2013 или 2010;
• Microsoft Lync Server version 2013;
• Microsoft Skype for Business 2015 или 2016;
• Microsoft Windows Azure Active Directory (AAD) используя Azure AD Graph API version 1.6;
• Microsoft Office 365 directory;
• Microsoft Exchange Online service;
• Microsoft Skype for Business Online service;
• Microsoft SharePoint Online service;
• Microsoft SQL Server — любой версии, поддерживаемой компанией Microsoft;
• Microsoft SharePoint 2016 или 2013;
• One Identity Manager version 7.х и 8.х;
• любые другие источники данных, доступные через OLE DB provider;
• файлы с разделителями (delimited text files) — CSV.

Рисунок 21. Выбор коннектора в сервисе синхронизации Active Roles Synchronization Service

Таким образом, при помощи встроенного сервиса синхронизации очень легко автоматизировать процесс жизненного цикла учетных записей. Под каждый сценарий («прием нового сотрудника на работу», «кадровый перевод», «увольнение») в рамках рабочего процесса синхронизации заводится шаг, соответствующий процедуре provisioning, update или de-provisioning:

Рисунок 22. Пример рабочего процесса «жизненного цикла учетных записей сотрудников» в сервисе синхронизации Active Roles Synchronization Service

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

Management Shell

Active Roles включает в себя набор собственных командлетов PowerShell для управления конфигурацией самого продукта, так и объектами Active Directory. Все командлеты имеют префикс QAD-, они появились еще до того, как компания Microsoft выпустила свой собственный набор командлетов для работы с объектами Active Directory.

Рисунок 23. Active Roles Management Shell

SPML Provider

Позволяет осуществить взаимодействие с сервисом Active Roles (для проведения каких-то действий над объектами Active Directory и связанных с ним систем) используя механизм веб-сервисов по протоколу Service Provisioning Markup Language (SPML) version 2 — т. е. путем обмена XML-документами в стандартном формате Simple Object Access Protocol (SOAP-запросами).

Веб-сервис SPML-провайдера Active Roles описан в Web Services Description Language (WSDL) — файле, доступном по ссылке http://<HostName>/ARServerSPML/SPMLProvider.asmx?WSDL. Полное описание функциональности и настройки SPML-провайдера Active Roles можно найти в прилагающейся к продукту документации.

ADSI Provider

Active Directory Services Interface (ADSI) Provider, присутствующий в Active Roles, позволяет использовать стандартный интерфейс Microsoft ADSI 2.5 для взаимодействия с сервисом Active Roles из сторонних приложений, скриптов и пользовательских интерфейсов, включая веб-приложения, которые используют Active Server Pages (ASP). В дополнение к этому ADSI-провайдер Active Roles поддерживает стандартный, системный провайдер OLE DB. Таким образом, OLE DB и ActiveX Data Objects (ADO) могут использоваться для запросов к сервису Active Directory через сервис Active Roles.

Примеры использования ADSI-провайдера Active Roles подробно описаны в прилагающемся к продукту Software Developer Kit (SDK).

Software Development Kit (SDK)

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

Рисунок 24. Active Roles Software Development Kit

Аудит и отчетность

Любые операции, осуществляемые через интерфейсы Active Roles (как из графических клиентов, так и через программные интерфейсы — например, SPML, ADSI), журналируются. Уровень журналирования очень детальный, но при этом понятный и читаемый. Для проведения аудита действий пользователей и изменений объектов Active Roles предлагает целый набор средств:

• Просмотр истории изменения объектов — доступен из графического интерфейса (толстый и тонкий клиент), в любое время по кнопке мыши.
• Анализ активности пользователя — какие операции над какими объектами проводил тот или иной сотрудник, также доступен в любое время в графическом интерфейсе.
• Полный журнал всех операций над объектами по всем системам, включая сам Active Roles (конфигурацию, операционную активность и пр.).
• Набор готовых отчетов (Report Pack).

История изменений объекта

Полная история изменений объекта доступна в Active Roles по клику мышки: нужно просто выбрать объект и нажать «Журнал изменений» (Change History). После этого на экран будет выведена информация обо всех операциях над объектом, в каком порядке и кем они были проведены, с полной детализацией (вплоть до значений атрибутов «до» и «после»).

Рисунок 25. Отображение «журнала изменений» объекта в MMC-интерфейсе Active Roles

Рисунок 26. Отображение «журнала изменений» объекта в веб-интерфейсе Active Roles

Аудит действий пользователя

Помимо аудита изменений объектов Active Directory (и связанных с ним систем) в Active Roles доступен аудит действий (т. е. кто и что делал, над каким объектами) — по команде «Действия пользователей» (User Activity).

Рисунок 27. Отображение информации об активности пользователя в веб-интерфейсе Active Roles

Журналирование операций

Все операции, производимые через интерфейсы Active Roles (включая программные), протоколируются. Active Roles Administration Service ведет в системе свой собственный, одноименный журнал — он доступен в любое время через оснастку «Просмотр журнала событий» (Event Viewer) и может быть сохранен в стандартном .evt формате.

Рисунок 28. Журнал событий сервиса Active Roles Administration Service в консоли Event Viewer

У любой операции есть поле «Инициатор» (Initiator), которое показывает, кто именно выполнил данную операцию, будучи авторизованным в Active Roles.

Данный журнал событий — это полный источник аудит-информации. Благодаря стандартному формату его при необходимости можно легко подключить и использовать в любой SEIM-системе.

Отчетность

В состав продукта Active Roles входит пакет готовых отчетов (Report Pack) с возможностью создания собственных отчетов по требованию.

Расширение функциональности Active Roles

Виртуальная схема и виртуальные атрибуты

При старте Сервис Active Roles Administration Service полностью вычитывает (кеширует в своей памяти) схему всех доменов, зарегистрированных для управления через данный сервис в данный момент. Т. е. абсолютно все атрибуты всех классов объектов, которые есть в физической, реальной схеме каждого домена, доступны для управления сервису.

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

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

Кастомизация веб-интерфейса

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

Выводы

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

Достоинства:

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

Недостатки:

• Графический интерфейс толстого клиента Active Roles в силу использованной технологии Microsoft Management Console (MMC) тяжело кастомизировать. Но наличие гибкого веб-интерфейса спасает ситуацию.
• Делегирование прав (полномочий), как и большинство «внутренних» настроек продукта, выполняется в MMC-интерфейсе. Настроек много, потребуется некоторое время, чтобы понять и запомнить, где и что настраивается. Хотя, по нашим данным, в One Identity ведется работа по переносу настроечной части в веб-интерфейс с сопутствующей оптимизацией и улучшением процесса настройки и использования.

В следующих частях обзора, посвященного Active Roles, мы расскажем о функциональности запроса доступа (членства в группе) через портал самообслуживания, а также возможностях Active Roles по управлению гибридной средой — облачными сервисами Microsoft Azure Active Directory и Office 365 (Exchange Online, SharePoint Online).

За помощь в создании материала автор благодарит Романа Каляпичева, консультанта по корпоративным решениям компании One Identity.