КАК ПОДГОТОВИТЬСЯ К ВНЕДРЕНИЮ IGA

Когда пора задуматься об автоматизации управления доступом? Как подготовиться к внедрению решения по управлению доступом?

10 лет назад даже аббревиатура IdM (Identity management – «Управление учетными данными») была мало кому знакома – но сегодня, когда заходит речь об управлении доступом, мы все чаще сталкиваемся с понятием IGA (Identity Governance and administration – «Управление учетными данными и администрирование»).

Задача IdM-систем состояла в том, чтобы упорядочить и централизовать управление и администрирование учетными записями, автоматизировать жизненный цикл учетных записей и предоставить пользователям необходимый доступ в системы. IGA-системы сосредоточены на управлении процессами с помощью правил и политик – они позволяют организовывать процессы и контролировать доступы массово, а не по каждому отдельному случаю. Функции политики предоставления доступов встречались и в классических IdM-решениях, но в какой-то момент их количество переросло в качество, в результате появилось решение IGA.

Развитие компаний в чем-то похоже на эволюцию живых организмов – в определенный момент у клиентов и потребителей возникают потребности, для удовлетворения которых нужны новые технологии. Маленькие организации развиваются, превращаясь в большие корпорации, количество сотрудников стремительно увеличивается, каждая компания обрастает информационными системами, число которых переваливает за сотни. Как правило, об управлении доступом в компании задумываются, лишь когда организация достигает внушительного размера и накапливает массу различных бизнес-систем. К этому моменту процессы получения прав и контроля полномочий не структурированы и плохо поддаются анализу:

1. сотрудники оформляют заявки на доступ как вздумается, используя разные системы (почта, СЭД, бумажная форма); 
2. процесс согласования отсутствует или не формализован; 
3. невозможно быстро разобраться, какие доступы есть у сотрудника, кто их согласовал и на каком основании; 
4. время ожидания доступа не фиксировано и может доходить до 3-5 рабочих дней; 
5. сотрудники ИТ-подразделения тратят слишком много времени на предоставление/изменение прав доступа и на обработку запросов; 
6. аудит прав доступа отнимает слишком много ресурсов, он неэффективен и проводится редко.

Когда возникает ощущение хаоса в вопросах регламентации доступа, значит, пора задуматься об автоматизации. В таких случаях на помощь приходят решения класса IGA.

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

Поскольку система IGA интегрируется с кадровыми источниками и управляемыми системами, для корректного взаимодействия основные требования предъявляются именно к этим элементам.

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

1. Анализ кадровых процессов и оптимизация сопровождения БД сотрудников в кадровых системах. 
2. Анализ данных о пользователях и правах, а также актуализация способов управления доступом в целевых информационных системах, которые планируется подключить к IGA. 
3. Организационные мероприятия и вовлечение персонала в процесс подготовки к внедрению IGA.

Кадровые данные

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

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

Часто бывает так, что в кадровом источнике отмечаются не все события (а еще чаще они отмечаются несвоевременно и не совсем корректно). Вот несколько типичных примеров:

1. не фиксируются отпуска, их категории и сроки (очередные или длительные); не фиксируется частичная занятость: например, находясь в длительном отпуске по уходу за ребенком, сотрудник может одновременно работать на неполной ставке;
2. фактический статус кандидата или работника уже изменился (прием/перевод/ увольнение), а приказ об этом событии выходит с задержкой;
3. сотрудника переводят на новую штатную позицию через увольнение, при этом в кадровой системе не фиксируется информация о том, что это техническое увольнение

Формат ввода данных в кадровую базу организации нужно стандартизировать. Параметры ввода ФИО, должностей и подразделений должны быть четко определены. Оптимальный вариант – когда кадровый работник не вбивает данные вручную, а выбирает их из заранее созданного справочника структуры подразделений и должностей (функция select).

Чтобы избежать ошибок в синхронизации и не заниматься ручным исправлением расхождений в отчетах, нужно ввести ID для каждого работника организации. Идентификатор присваивается каждому новому работнику и фигурирует в кадровой системе и в информационных системах организации как обязательный атрибут учетной записи. Неважно, состоит он из цифр или букв, — главное, чтобы для каждого работника он был уникален (например, многие используют табельный номер сотрудника). В дальнейшем введение этого атрибута серьезно облегчит связывание данных о сотруднике в кадровом источнике с его учетными записями и полномочиями в информационных системах.

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

Целевые системы

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

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

Где-то управление происходит через API (application programming interface) — набор уже готовых разработанных функций и процедур для взаимодействия с внешними программами. Во многих системах такой инструмент уже присутствует или его можно настроить.

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

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

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

У ролевого управления доступом есть много преимуществ:

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

Построить ролевую модель, на 100% покрывающую все возможные потребности пользователей просто невозможно, да это и не требуется, т.к. на практике ролевые модели должны быть достаточно гибкими, чтобы соответствовать меняющейся организационной структуре и функциональной модели. Обычно ролевая модель покрывает от 20 до 80% прав, необходимых для базового доступа. Т.е. сотрудник при назначении на должность получит минимально необходимый набор прав для работы и выполнения функционала, а остальное сможет дозапросить позже, если возникнет такая необходимость и она будет подтверждена необходимым согласованием.

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

Использование заранее определенных ролей позволяет давать привилегии на проведение целого комплекса операций со сложными составными данными. С использованием ролевого управления доступ предоставляется не к отдельным операциям или объектам системы, а к их совокупности, сгруппированной по определенному функциональному принципу, например «пользователь кредитного модуля» (роль 1), «пользователь расчетного модуля» (роль 2) или «администратор системы N» (роль N).

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

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

Используя такой подход, в дальнейшем при внедрении IGA-системы достаточно будет автоматизировать процесс предоставления прав доступа на основе созданных ролей первого этапа.

Кроме того, для многомерной структуры доступа с тысячами пользователей и разрешений хорошей практикой является использование иерархии ролей и наследования привилегий. Это существенно упрощает ролевую модель. Например, для кредитного модуля созданы три отдельные роли:

Эти роли можно организовать в иерархию, в которой роль «администратор» будет наследовать привилегии ролей пользователя и читателя. Аналогично роль «пользователь» будет наследовать привилегии от роли «читатель», плюс иметь права на проведение операций.

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

N.B. Не стоит пытаться сразу включить в интеграцию как можно больше систем. Системы с более сложной архитектурой и многомерной структурой управления правами доступа на первом этапе рекомендуется подключать к IGA в полуавтоматическом режиме. То есть реализовать на основании кадровых событий только автоматическое формирование заявки на доступ, которая поступит на выполнение администратору, и он настроит права вручную. Иначе есть риск из «ручного» хаоса получить автоматизированный, последствия которого могут быть куда серьезнее.

После успешного прохождения первого этапа можно распространить функции системы IGA на новые расширенные заранее проработанные бизнес-процессы, полную автоматизацию и масштабирование с подключением дополнительных информационных систем. Для систем со сложной структурой доступа и большим количеством прав проанализировать доступ и выстроить корректную ролевую модель в ручном режиме сложно, поэтому рекомендуем использовать средства автоматизации. Развитые системы IdM/IGA имеют в своем арсенале достаточно удобные инструменты по сравнению полномочий пользователей, а также поддерживают Role mining – т. е. автоматизированный анализ имеющихся прав доступа и объединение прав в роли. Применение таких средств на втором этапе будет оправданным и даст положительный результат.

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

Организационные мероприятия

Не стоит сбрасывать со счетов и организационные моменты. В некоторых случаях они могут играть решающую роль, потому что от эффективного взаимодействия между подразделениями зачастую зависит результат всего проекта. Для этого мы обычно советуем создать в организации команду участников процесса, в которую войдут все задействованные подразделения. Поскольку для людей это дополнительная нагрузка, постарайтесь заранее разъяснить всем участникам будущего процесса их роль и значимость в структуре взаимодействия. Если «продать» коллегам идею IGA на этом этапе, можно будет избежать многих сложностей в дальнейшем.

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

Часто владельцами проекта внедрения IGA в компании выступают подразделения информационной безопасности или ИТ, а мнение бизнес-подразделений не учитывается. Это большая ошибка, ведь только они знают, каким образом и в каких бизнес-процессах используется каждый ресурс, кому надо давать к нему доступ, а кому нет. Поэтому на этапе подготовки важно обозначить, что именно бизнес-владелец отвечает за функциональную модель, на основании которой разрабатываются наборы прав (роли) пользователей в информационной системе, а также за то, чтобы эти роли поддерживались в актуальном состоянии. Ролевая модель – это не статичная матрица, которую один раз выстроили и можно на этом успокоиться. Это живой организм, который должен постоянно меняться, обновляться и развиваться, следуя за изменениями структуры организации и обязанностей сотрудников. Иначе либо начнутся проблемы, связанные с задержками в предоставлении доступа, либо возникнут риски информационной безопасности, связанные с избыточными правами доступа.

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

1. навести порядок в кадровых данных; ввести уникальный идентификационный параметр для каждого работника; 
2. оценить готовность информационных систем к внедрению IGA; 
3. выбрать несколько систем для первоначального подключения к IGA;
4. разработать ролевые модели в информационных системах, если их нет; 
5. разработать интерфейсы взаимодействия с информационными системами для управления доступом, если они отсутствуют, и выделить ресурсы на эти работы; 
6. создать рабочую группу, включающую представителей заинтересованных сторон; 
7. подготовить процесс управления доступом на основе ролевого управления и включить в него кураторов от каждого бизнес-направления;
8. заручиться поддержкой руководства компании; 
9. обучить персонал.

Процесс подготовки может быть нелегким, поэтому, если есть возможность, привлекайте сторонних консультантов.

Внедрение IGA-решения – непростой и ответственный шаг. Для его успешной реализации важны как усилия каждой стороны в отдельности – сотрудников бизнес-подразделений, ИТ и ИБ-служб, – так и взаимодействие всей команды в целом. Но усилия стоят того: после внедрения IGA в компании снижается число инцидентов, связанных с избыточными полномочиями и несанкционированными правами в информационных системах, исчезают простои сотрудников по причине отсутствия/долгого ожидания необходимых прав, за счет автоматизации снижаются трудозатраты и повышается производительность труда ИТ- и ИБ-служб.

В следующем выпуске вы узнаете:

1. какой подход к внедрению решений по автоматизации управления доступом выбрать; 
2. как правильно поставить цели по выстраиванию процессов и получить желаемый результат; 
3. какие способы внедрения IdM можно использовать и что они дадут компании.