Привет, Хабр! Бывают случаи, когда приходят заказчики, которые до тебя уже «хлебнули сполна». Проект, о котором пойдет речь ниже, один из таких. Заказчик – крупное производственное предприятие, а если быть точным, то целая группа компаний. И хотя изначально мы обсуждали с ним систему защиты от утечек Solar Dozor и сервис мониторинга и реагирования на кибератаки Solar JSOC, гораздо большее внимание в тот момент привлекла наша IGA-система Solar inRights. Почему? Расскажем под катом.

Небольшая предыстория (разбираемся, чего хлебнул заказчик)

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

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

Так заказчик обратился к компании «Бублик» (все названия вымышлены, любое совпадение с реальными являются случайностью). Итак, «Бублик» продал свое IDM-решение и, утвердив детали, взялся за проект. Шло время, «Бублик» что-то делал, а результата все не было и не было видно. Продукт не оправдывал возложенных на него надежд. Когда силы, инвестированные заказчиком в этот проект, стали подходить к концу, мы обсудили внедрение нашей системы IGA. ИТ-отдел заинтересовался предложением и дал нам два месяца на пилотное тестирование.

Стоит сказать, что в тот момент производственное предприятие также посматривало в сторону SAP GRC в качестве инструмента автоматизации прав доступа и полномочий в системах SAP. Но стоимость SAP GRC сильно уменьшила привлекательность этого решения в глазах заказчика.

Интеграция

MS Active Directory

Первое, что должен узнать заказчик до внедрения IGA — если автоматизировать хаос, мы получим автоматизированный хаос. Компании зачастую этого просто не понимают, а мы слишком хорошо знакомы с такими кейсами, поэтому всегда стартуем с приведения в порядок информации в AD. Стоит сделать комплимент заказчику, потому что данные в кадровом источнике и AD велись структурно, орг.юниты упорядочены, карточки пользователей заполнены. Используется система идентификации по СНИЛС — очень элегантное решение для исключения ошибок при сопоставлении данных КИ и AD. Например, если в качестве идентификатора используют табельный номер и, допустим, какой-то сотрудник совмещает несколько должностей, учетные записи могут задваиваться. В общем, таких проблем не было, все довольно аккуратно лежало на своих местах, и это позволило нам быстро проскочить этот этап.

До этой интеграции внешний скрипт получал информацию из кадровой системы и создавал учетные записи в AD. После — эту функцию взяла система IGA, позволив задавать разные базовые права для пользователей разных подразделений, причем через визуальный интерфейс. Новые сотрудники по умолчанию наделялись как стандартными для всех правами доступа, так и правами конкретных подразделений (например, диск, SharePoint, корпоративная рассылка и т.д.).

Кстати, подробнее о том, как построить ролевую модель управления доступом, мы писали ранее (здесь и здесь).

MS Exchange

Интеграция с Exchange позволила заводить почтовые адреса сотрудникам через IGA. Раньше это тоже делалось через скрипт, но Solar inRights в дополнение дал возможность настраивать уровни дифференциации в зависимости от категории пользователя и автономно наделять адреса ограничениями по объему хранения. Для руководителей отделов и департаментов — один объем памяти, для сотрудников без подчиненных — другой. При этом настройки позволяют наделять определенным объемом почтовые адреса не только на основании иерархичности должностей, но и на основании принадлежности к определенному подразделению.

MS Skype for business

При создании учетной записи в AD пользователям автоматически создаются учетные записи в Skype и выдаются права звонить друг другу в корпоративной версии системы.

Четыре SAP-системы. Подходим к самому интересному

У заказчика было четыре системы SAP: ERP, CRM, SRS, TM. Как раз для них он рассматривал SAP GRC, чтобы централизованно управлять учетными записями всех систем и автоматически каталогизировать структуру ролей.

1. Вычитка данных из внешних источников

Команда заказчика приняла решение отказаться от внедрения системы управления учетными записями от SAP в пользу IGA от «Ростелеком-Солар». Был один нюанс: наша система не могла автоматически каталогизировать структуру ролей из внешних файлов. Она позволяла создавать каталоги ролей и назначать их пользователям вручную, но не умела вычитывать данные о структуре каталогов из внешних источников.

По запросу заказчика мы доработали IGA, добавив загрузку иерархии каталогов из внешних источников. Появилось два новых скрипта. Первый втягивает каталог с информацией о базовых ролях подразделений и должностей. Второй отмечает, какая роль SAP к какому каталогу и к какому бизнес-процессу относится, и воссоздает необходимую иерархию в IGA. Оба скрипта проверяли загружаемые данные на корректность и полноту. Механизмы валидации ловят ошибочки: скрипт находит некорректные названия каталогов, неправильно составленные каталоги и др. За несколько итераций загружаемые файлы привели в порядок.

У заказчика появилась возможность согласовывать набор базовых ролей (допустим, в .excel) и загружать файл через удобный пользовательский интерфейс в IGA. После этого система автоматически пересчитывает состав базовых ролей, если возникает необходимость в его обновлении, и выдает пользователям измененный состав ролей.

2. Прорабатываем все нюансы с доступом

Совместно с SAP-командой заказчика мы разработали проектное решение по интеграции IGA. Описали те методы, которые необходимо реализовать, и те данные, которыми должны обмениваться системы. Мы проработали набор штатных правил по предоставлению доступов, но внештатных кейсов, которые тоже нужно было учесть, оказалось много.

Обычно админы систем управления доступом делятся деталями штатной работы системы, но всегда есть нюансы. Эти нюансы сидят в них как скрытые знания, которые открываются только по случаю. Администраторы понимают, что если придет такой запрос, то конкретно этому пользователю именно этого отдела и только в этом случае надо предоставить доступ вот к этому (?).

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

3. Пишем коннектор к SAP

У нас не было штатного коннектора к SAP – инструмента, который позволял бы централизованно взаимодействовать нескольким SAP-системам – и поэтому мы его написали сами. Чтобы не плодить четыре типовых коннектора к каждой из SAP-систем, мы сделали интеграцию одним коннектором через шину SAP PI/PO, которая маршрутизирует запросы, к системам SAP, по ряду критериев определяет, в какую из систем его отправить, и возвращает ответ.

Два экземпляра 1С в WMS

Мы провели обследование, согласовали протокол взаимодействия систем, разработали коннектор 1С и провели интеграцию. В тот момент, когда мы первый раз показали заказчику, как все это работает, помимо ролей он попросил указывать также номер склада, к которому эти роли относятся. Поскольку номер склада – это атрибут пользователя, пришлось дорабатывать концепцию интеграции и коннектор к 1С.

На выручку пришла гибкость нашей системы, которая позволила за счет метаролей сделать управление полем склада. Поскольку сам склад – это не роль, а просто атрибут, мы на стороне IGA создали 5 ролей, которые назывались «склад 1», «склад 2», «склад 3» и т.д. При назначении пользователю роли «склад» в атрибут прописывался конкретный идентификатор склада, в котором он выполняет операции под теми ролями, которые ему назначены. Таким образом, на стороне IGA была информация о том, на каком складе работает пользователь, которая передавалась автоматически в 1C.

Эта интеграция подтолкнула нас к разработке собственного функционального расширения для платформ 1С и прохождению сертификации совместимости коннектора IGA Solar inRights с разными конфигурациями 1С, которую мы получили в конце 2020.

Кадровые источники – две системы кадрового учета на платформе 1С версии 7

У заказчика несколько источников кадровых данных, поэтому ему требовалось автоматизированное объединение информации в единую кадровую выгрузку. Наш механизм, каждые 30 минут обрабатывал кадровые источники и обновлял выгрузку.

Послесловие

Пост начинался с рассказа о негативном опыте заказчика, и несмотря на то, что процесс интеграции не бывает простым, нам удалось преодолеть скептицизм, который сформировался после затянувшейся и в итоге несостоявшейся интеграции IDM от другого вендора. Подводя итоги проекта, заказчик оценил работу нашей команды на 9 баллов из 10. Мы остались довольны взаимодействием с ИТ-командой компании и результатами интеграции.

Итоги проекта в цифрах:

Мораль истории: правильно выстроенная работа команд интегратора и заказчика – половина успешного внедрения :)

Автор: Максим Мордачев, руководитель проектов Solar inRights компании «Ростелеком-Солар»