Руководство оператора коннектора META#

Введение#

Интеграция IDMC с АС META предназначена для централизованного управления проектированием полномочий АС, снижения уровня неправомерного доступа к АС.

На текущем этапе реализации данной интеграции ролевые модели АС/ФП загружаются в IDM, полномочия маркируются в соответствии с жизненным циклом. В дальнейшем будет происходить сверка загруженных полномочий АС из META с полномочиями, загруженными из АС, результаты сверки будут отправляться в АС META.

Верхнеуровневое описание алгоритма#

Загрузка ролей в IDM из АС META происходит с помощью задач META Role Import. Задача содержит 3 activity - получение требований из МЕТА в виде shadow обьектов, сопоставление полученных shadow объектов с ролями, и сверка ролей с полномочиями на consistency. Роли загружаются в IDM в виде shadow-объектов (проекций). Для стенда ПСИ и ПРОМ разные условия по загрузке ролей АС, тип стенда определяется параметром IDM idmc.connector.meta.stand. Требования по загрузке приходят из АС META, с помощью коннектора META задача загружает полномочия в IDM и обрабатывает их данной задачей.

После импорта проекция сопоставляется с существующими ролями АС в IDM. Если соответствущая проекции роль АС находится в IDM (поиск происходит по атрибутам identifier и ci, либо по атрибутам identifier и service_desk_id), то проекция связывается с данной ролью. Если же сопоставление неуспешно, то проекция получит статус UNMATCHED (то есть несвязанная), и будет ожидать появления подходящей роли АС в IDM.

После успешного связывания с ролью, проекции проходят процедуру сверки. Проекция и роль АС сверяются по определенному набору атрибутов. В случае успешной сверки (то есть если проекция совпадает с ролью АС по списку атрибутов), то в роли АС заполняется в атрибут consistency проставляется значение "OK", и она обогащается дополнительными атрибутами, полученными из проекции МЕТА. Если же сверка неуспешна, то в роли отмечаются все типы несоответствия в атрибуте consistency.

Атрибут consistency является массивом, и может принимать несколько значений. Если consistency = OK и пришло сообщение META, в котором есть различие с ролью, то из consistency удаляется значение OK и остаются только значения различий. Если consistency = not_in_META и пришло сообщение META с этой ролью, то из consistency удаляется значение OK, и остаются только значения различий (либо остается только значение OK, если различий нет).

Получение и обработка полномочий#

Для обработки полномочий из АС META используется задача META Role Import. Задача вычитывает сообщения из входящего топика Kafka. Полномочия импортируются из АС META в IDM в виде shadow объектов. В созданном shadow содержится информация по всем переданным атрибутам из таблицы 1.

Если для созданного shadow объекта (проекции МЕТА) находится соответствующая роль АС, то shadow объект получает статус Situation = LINKED. Если объект не может быть связан (то есть не находится роль АС), то для него устанавливается Situation = UNMATCHED. Если в shadow объекте есть какие-либо ошибки в атрибутах либо их значениях - то объект получит метку Meta. Failed shadow и Situation = UNMATCHED.

Нет расписания. Однократное выполнение. Ручной запуск. Задачи вычитывают по 500 сообщений из каждой партиции.

Загрузка полномочий в IDM происходит по следующему алгоритму:

1. При передаче каждой ИТ-роли выполняется проверка всех передаваемых атрибутов в соответствии с таблицей 1 «Описание передаваемых атрибутов ИТ-роли из АС META» на предмет их соответствия следующим критериям:

   1. Обязательность заполнения: наличие обязательных полей (не пустых значений).

   2. Форматно-логический контроль: соблюдение формата данных (например, числовой тип, строковые ограничения длины и структуры) в соответствии с JSON-схемой.

      1. Если в процессе валидации атрибутов была обнаружена ошибка (название атрибута было записано неверно, какой-либо обязательный атрибут отсутствует), система выдает ошибку, и записывает ее в атрибут result.message shadow объекта, а также проставит метку Meta. Failed shadow и Situation = UNMATCHED.

      2. Если в передаваемом значении атрибута была допущена ошибка (было передано значение, которое не соответствует типу данных, заданному в схеме, или размер передаваемого атрибута превышает допустимое значение), то система выдает ошибку, и записывает ее в атрибут result.message shadow объекта, а также проставит метку Meta. Failed shadow и Situation = UNMATCHED.

   Версии ИТ-ролей обрабатываются индивидуально, каждая новая версия замещает предыдущую версию той же ИТ-роли.

2. Затем ИТ-роль в виде shadow объекта сопоставляется с ролями АС. Сопоставляются только shadow-объекты ролей с архетипами для роли АС (9c9c828a-dd8d-4cc7-9798-04c9c7ce14b2) и роли ФА (7b6c16e8-564e-4d98-bde3-e5384180f75b). Сопоставление происходит по следующему алгоритму:

   1. Сравниваются значения атрибутов identifier (идентификатор роли) и ci (КЭ) shadow объекта и ролей АС. При совпадении shadow объект связывается с ролью АС и получает статус Situation = LINKED.

   2. Если первое сравнение неуспешно, производится сравнение по атрибутам identifier и service_desk_id. При этом, атрибут service_desk_id принадлежит shadow объекту и сравнивается с атрибутом ci каталога ролей АС. При совпадении shadow объект связывается с ролью АС и получает статус Situation = LINKED.

   3. Для коммунальных служб по атрибуту ci находится каталог ролей. Из каталога берется oid интеграции (ресурса) из поля resourceOid. Среди ролей IDM ищется роль, совпадающая по значениям полей identifier и resourceOid. При совпадении shadow объект связывается с найденной ролью АС и получает статус Situation = LINKED.

   4. Если по итогу третьего условия по ИТ-услуге каталог не найден, либо найден, но с найденным oid интеграции не найден соответствующий код роли, то выполняется поиск каталога по объекту управления (service_desk_id). Затем, в соответствии с указанным в нем oid интеграции (resourceOid), выполняется поиск роли по идентификатору (identifier).

   5. В случае если сравнение неуспешно, проекция получит статус UNMATCHED (то есть несвязанная), и будет ожидать появления подходящей роли АС в IDM.

      • Если сравнение успешно неполностью (а именно не получилось точно определить соответствующую роль, но при этом часть атрибутов соответствует), то IDM создает заявку на корелляцию для ручной проверки оператором.

3. В ролях АС, которые были связаны с shadow объектами, проставлется триггер needToCheckRole. Также триггер needToCheckRole проставляется в случае импорта или изменения роли АС.

4. По триггеру needToCheckRole производится сверка shadow объектов (проекций МЕТА) и ролей. Сверка выполняется через сравнение определенного набора атрибутов shadow объекта и связанной с ним роли. Сравнение выполняется по следующему алгоритму:

   1. Проверка привязанной проекции META к роли:

      1. Если роль не имеет проекции META, то роли проставляется атрибут consistency = not_in_meta и обработка роли прекращается, задача переходит к обработке следующей роли.

      2. Если проекция META имеет метку Meta. Failed shadow (oid = 02dc0cb8-a558-4183-94ba-3f3346116404), то обработка роли прекращается, задача переходит к обработке следующей роли.

   2. Если version.id из роли совпадает с version.id из проекции META, то атрибуты роли сравниваются с атрибутами проекции. Если не совпадает, то атрибуты роли сравниваются с атрибутами проекции из атрибута mainVersion. Если version.id из роли не совпадает с version.id из mainVersion проекции META, то отправляется ошибка и обработка роли прекращается, задача переходит к обработке следующей роли.

   3. Если атрибут displayNameOrig в роли и role_Display_Name в проекции META отличается, то роли проставляется атрибут consistency = attr_displayname_not_consist и обработка роли прекращается, задача переходит к обработке следующей роли.

   4. Если атрибут incompatibleRoles в роли и в проекции META отличается, то роли проставляется атрибут consistency = attr_incompatibleRoles_not_consist и обработка роли прекращается, задача переходит к обработке следующей роли.

   5. Обработка административных статусов проекции META:

      1. Если статус PROJECT или APPROVAL, то роли проставляется атрибут consistency = attr_status_not_consist.

      2. Если статус CANCELLED, стенд psi и у роли effectiveStatus = enabled, то роли проставляется атрибут consistency = attr_status_not_consist. Если стенд prom, то роли всегда проставляется атрибут consistency = attr_status_not_consist.

      3. Если статус PREPARED и у роли атрибут archive = false или effectiveStatus = disabled, то роли проставляется атрибут consistency = attr_status_not_consist.

      4. Если статус DECOMMISSIONED и у роли атрибут archive = false или effectiveStatus = enabled, то роли проставляется атрибут consistency = attr_status_not_consist.

      5. Если статус PSI, стенд psi и у роли атрибут archive = true или effectiveStatus = disabled, то роли проставляется атрибут consistency = attr_status_not_consist. Если стенд prom, то роли всегда проставляется атрибут consistency = attr_status_not_consist.

      6. Если статус PROM и у роли атрибут archive = true или effectiveStatus = disabled, то роли проставляется атрибут consistency = attr_status_not_consist.

5. Если сверка прошла успешно, то роли проставляется атрибут consistency = OK и роль дополняется атрибутами из проекции META:

   • auditor_role;

   • administrator_role;

   • tuz_role;

   • insider_bitl;

   • insider_issuer;

   • insider_rcb;

   • insider_208_fz;

   • insider_controlling_org;

   • Признаки критичности. ПДн;

   • Признаки критичности. БТ;

   • Признаки критичности. ДПК.

6. После сверки формируется сообщение о результатах сверки и отправляется в топик Kafka, который указан в параметре IDM idmc.connector.meta.verification.result.topic. При этом у роли заполняются атрибуты sendVerification - был ли отправлен результат сверки, и date_last_verification - дата последней сверки.

7. У роли удаляется триггер needToCheckRole.

Таблица 1. Описание передаваемых атрибутов ИТ-роли из АС META

Технические атрибуты в топике

Описание массива version

Описание массива link

Обработка новой редакции полномочий#

Для обеспечения возможности внесения изменений в ИТ-роль, которая находится в промышленной эксплуатации, делается копия ИТ-роли, которая проходит по статусам жизненного цикла. Данная роль имеет аналогичный код роли, который невозможно редактировать, и id, при этом копии (новой версии) ИТ-роли присваивается новый id version (идентификатор версии в АС МЕТА).

Данная ИТ-роль будет иметь следующие особенности: в массиве version будет находиться две версии роли, одна из которых имеет main=true для версии со статусом prom (по такой роли и происходит редакция). Версия со статусом PROJECT/APPROVAL/PSI имеет main=false.

Также, если для роли приходит сообщение с двумя версиями, то в атрибут роли version будет заполняться массив данных, пришедший с параметром main=false, а в атрибут роли main.version будет заполняться массив данных, пришедший с параметром main=true. В случае, если пришло сообщение только с одной версий - всегда будет заполняться только атрибут version.

Процесс обработки сообщений с двумя версиями задачей META Role Import различается в зависимости от стенда:

• Если значение параметра IDM idmc.connector.meta.stand равно psi, то будут обрабатываться все статусы версий.

• Если же параметр имеет значение prom, то:

  • На ПСИ стенде, если приходит новая редакция (2 версии в сообщении), то загружается версия с main=false и в статусе psi. Остальные статусы не обрабатываются, такая версия не загружается.

  • На стенде ПРОМ сообщения с 2 версиями не обрабатываются. На стенде ПРОМ обрабатываются только сообщения с одной версией.

Реконсиляция ролей и сверка полномочий#

В процессе эксплуатаци интеграции с МЕТА может возникнуть ситуация, когда shadow объект (проекция МЕТА) был импортирован, но соответствующей ему роли АС еще не было создано (Situation = UNMATCHED). В таких случаях требуется реконсиляция ролей АС — получение изменений из ресурсов в IDM. В рамках реконсиляции роли АС получают новые значения атрибутов из ресурса, а также в IDM создаются новые роли, которые были созданы в ресурсе ранее, но не были загружены в IDM.

Для реконсиляции ролей и сверки полномочий используется задача META Role Reconcile. Задача производит реконсиляцию по стандартному алгоритму IDM, а затем выполняет сверку полномочий.

Сверка проекции META происходит только с ролями, у которых присутствует триггер needToCheckRole. Данный триггер проставляется при импорте или при изменении роли. Возможные сценарии сверки:

• Все атрибуты по полномочию совпадают и тогда роли проставляется атрибут consistency = ОК.

• Полномочие есть в управляемой АС, но нет в каталоге МЕТА и тогда роли проставляется атрибут consistency = not_in_META.

• Различие в атрибуте отображаемое имя и тогда роли проставляется атрибут consistency= attr_displayname_not_consist.

• Различие в атрибуте статус и тогда роли проставляется атрибут consistency = attr_status_not_consist.

• Различие в атрибуте конфликтующие полномочия и тогда роли проставляется атрибут consistency = attr_incompatibleRoles_not_consist.

Нет расписания. Однократное выполнение. Ручной запуск.

Реконсиляция ролей в IDM происходит по следующему алгоритму:

1. Запуск задачи.

2. Чтение ролей из указанного ресурса.

3. Выполнение реконсиляции ролей указанного ресурса. При выполнении реконсиляции роли проставляется триггер needToCheckRole.

4. Выбор ресурсных ролей, у которых присутствует триггер needToCheckRole.

5. Сверка ресурсной роли с тем, что указано в проекции META:

   1. Проверка привязанной проекции META к роли:

      1. Если роль не имеет проекции META, то роли проставляется атрибут consistency = not_in_meta и выполняется переход к следующей роли.

      2. Если проекция META имеет метку Meta. Failed shadow (oid = 02dc0cb8-a558-4183-94ba-3f3346116404), то выполняется переход к следующей роли.

   2. Если version.id из роли совпадает с version.id из проекции META, то атрибуты роли сравниваются с атрибутами проекции. Если не совпадает, то атрибуты роли сравниваются с атрибутами проекции из атрибута mainVersion. Если version.id из роли не совпадает с version.id из mainVersion проекции META, то отправляется ошибка и выполняется переход к следующей роли.

   3. Если атрибут displayNameOrig в роли и role_Display_Name в проекции META отличается, то роли проставляется атрибут consistency = attr_displayname_not_consist и выполняется переход к следующей роли.

   4. Если атрибут incompatibleRoles в роли и в проекции META отличается, то роли проставляется атрибут consistency = attr_incompatibleRoles_not_consist и выполняется переход к следующей роли.

   5. Обработка административных статусов проекции META:

      1. Если статус PROJECT или APPROVAL, то роли проставляется атрибут consistency = attr_status_not_consist.

      2. Если статус CANCELLED, стенд psi и у роли effectiveStatus = enabled, то роли проставляется атрибут consistency = attr_status_not_consist. Если стенд prom, то роли всегда проставляется атрибут consistency = attr_status_not_consist.

      3. Если статус PREPARED и у роли атрибут archive = false или effectiveStatus = disabled, то роли проставляется атрибут consistency = attr_status_not_consist.

      4. Если статус DECOMMISSIONED и у роли атрибут archive = false или effectiveStatus = enabled, то роли проставляется атрибут consistency = attr_status_not_consist.

      5. Если статус PSI, стенд psi и у роли атрибут archive = true или effectiveStatus = disabled, то роли проставляется атрибут consistency = attr_status_not_consist. Если стенд prom, то роли всегда проставляется атрибут consistency = attr_status_not_consist.

      6. Если статус PROM и у роли атрибут archive = true или effectiveStatus = disabled, то роли проставляется атрибут consistency = attr_status_not_consist.

   6. Если сверка прошла успешно, то роли проставляется атрибут consistency = OK и роль дополняется атрибутами из проекции META:

      • auditor_role;

      • administrator_role;

      • tuz_role;

      • insider_bitl;

      • insider_issuer;

      • insider_rcb;

      • insider_208_fz;

      • insider_controlling_org;

      • Признаки критичности. ПДн;

      • Признаки критичности. БТ;

      • Признаки критичности. ДПК.

   7. Удаление у роли триггера needToCheckRole.

6. После сверки формируется сообщение о результатах сверки и отправляется в топик Kafka, который указан в параметре IDM idmc.connector.meta.verification.result.topic. При этом у роли заполняются атрибуты sendVerification - был ли отправлен результат сверки, и date_last_verification - дата последней сверки.

7. Завершение задачи.

Отправка результатов сверки#

Для реализации возможности отправки сообщений с результатами сверки в отдельный топик Kafka используется второй ресурс, который наследуется из основного - resource-meta-2-send-verification. Это связано с архитектурными особенностями механизма работы коннекторов IDM, которые не позволяют указывать несколько топиков Kafka в одном коннекторе.

Подробнее о настройке этого ресурса смотрите в документе Руководство функционального администратора IDMC.

Обратите внимание.

Не изменяйте параметры, кроме указанных в инструкции, в конфигурации данного ресурса.

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

Назначение неконсистентных ролей#

Реализована возможность запрета назначения ролей МЕТА, имеющих в consistency любое значение, отличное от OK, либо имеющих пустой параметр consistency.

Для этого на обьект организации можно поставить метку «Prohibition on assigning an inconsistent role». В таком случае, при попытке назначить на любого участника организации неконсистентную роль, эта роль не будет назначена, а IDM выведет ошибку «Запрещено назначать роль, если признак consistency не заполнен или отличный от «ОК»».

Обратите внимание.

Если роль уже назначена и consistency поменялся на отличное от OK значение, то никаких изменений при назначении данной метки на организацию не происходит.

Анализ ролей в ситуации Disputed#

Реализована возможность находить все shadow-объекты ролей МЕТА с ситуацией Disputed и выполнять поиск объектов, которые были найдены по условиям сопоставления. Информацию о shadow и соответствующих им объектах ролей выводятся в отчет.

Для генерации отчета следует запустить в разделе Отчеты отчет Disputed meta roles analyse, дождаться окончания работы созданной задачи, и потом выгрузить созданный отчет с названием Disputed meta roles analyse из раздела Созданные отчеты.

В отчете присутствует следующие колонки:

• Shadow name;

• CI;

• service_desk_id;

• Identifier;

• Role displayNames;

• Role resource oids.

Технологическая учетная запись#

Технологическая учетная запись meta_technical_account обладает полномочиями назначать в карточки первичных ролей, прикладных ролей и ФОС автоматизированных систем, создавать и модифицировать проекций для УЗ в целевых ресурсах. Данная учетная запись является владельцем всех задач для работы с META. При выполнении задач META в поле Initiator журнала аудита (Audit Log Viewer) отображается значение ТУЗ, обозначающее автоматизированный запуск процесса системой. Учетная запись предоставляется в составе дистрибутива.

Переопределение статуса сверки ролей при создании интеграции#

В системную конфигурацию добавлен хук Meta send verification on org create, который срабатывает при загрузке в IDM организации.

Данный хук проверяет, существуют ли в IDM проекции МЕТА, имеющие в значении ci (либо в control_object_ci, либо в link.service_desk_id) то же значение, что и у загруженной организации, и при этом у организации в родительском каталоге находится Roles_catalog.

При выполнении условия хук создает и запускает шаблонную задачу Meta set verification mark template, которая проставляет на такие проекции МЕТА метку Meta. Send verification.

Задача для проставления метки не создается, если:

• Нет unmatched проекций META для загружаемого ci (проекции либо отсутствуют, либо в статусе linked).

• Есть unmatched проекции META для загружаемого ci, но в организации родительский каталог != Roles_catalog.

Задача для проставления метки создается, если:

• Есть unmatched проекции META для загружаемого ci (у организации ci совпадает со значением control_object_id проекции META).

• Есть unmatched проекции META для загружаемого ci (у организации ci совпадает со значением link.service_desk_id проекции META).

Просмотр логов#

Все действия, производимые компонентом IDMX (компонент idmx-engine) логируются, логи записываются в файлы на сервере. IDMX создает файлы журнала в директории /app/idmx-engine/var/log.

Основной файл для работы - idm-engine.log. В него вносятся все логи работы IDMX.

В случае, если нужно получить логи интеграции с META, то необходимо настроить категорию коннектора MetaConnector.

Настроить категорию можно вручную согласно инструкции ниже.

1. Перейдите в UI IDM > Система > Логирование.

2. Перейдите в пункт Class loggers.

3. Нажмите кнопку + и добавьте требуемые категории из списка ниже, выставив необходимый уровень логирования. В средах разработки и тестирования рекомендуется использование уровня TRACE. В PROD-среде рекомендуется использование уровня не ниже INFO

   Список доступных логгеров:

   • Логгеры коннектора МЕТА:

     • sber.platform.idm.connector.meta.MetaConnector - общие логи коннектора МЕТА.

     • sber.platform.idm.connector.meta.TopicReader - логи чтения топиков Kafka.

     • sber.platform.idm.connector.meta.KafkaConfiguration - логи конфигурации Kafka.

     • sber.platform.idm.connector.meta.MetaConfiguration - логи конфигурации МЕТА.

     • sber.platform.idm.connector.meta.SchemaHandler - логи обработки модели данных.

     • sber.platform.idm.connector.meta.JsonKafkaDeserializer - логи десериализации JSON-объектов Kafka.

     • sber.platform.idm.connector.meta.MetaConnectorUtils - логи утилит коннектора МЕТА.

     • sber.platform.idm.connector.meta.ValidateUtils - логи утилит валидации сообщений Kafka.

   • Логгеры интеграции с МЕТА:

     • com.evolveum.midpoint.expression.resource.meta.correlation - логи процесса сопоставления ролей МЕТА.

     • com.evolveum.midpoint.expression.task.metaRolesImportPSI.activity.import - логи импорта полномочий (задача META Role Import).

     • com.evolveum.midpoint.expression.task.metaRolesImportPSI.activity.checkRoles - логи сверки импортированных полномочий (задача META Role Import).

     • com.evolveum.midpoint.expression.task.metaRolesReconcile.activity.checkRoles - логи сверки полномочий в рамках реконсиляции (задача META Role Reconcile).

     • com.evolveum.midpoint.expression.metaLib.checkRole - логи функций библиотеки МЕТА по проверке ролей.

     • com.evolveum.midpoint.expression.metaLib.isDateLastChangeValid - логи функций библиотеки МЕТА по валидации даты последних изменений.