Предоставление доступа – это процесс
Казалось бы, мысль банальная. Но за этой мыслью скрывается огромный фронт работ. Во-первых, если это процесс, он должен быть описан и понятен. У процесса есть начало (вход процесса) и конец (выход процесса). Давайте изобразим для начала процесс предоставления доступа на примере одного из банков, в котором IDM так и не был внедрен. Банк крупный, более 5 тыс. человек, 7/8 из которых работают в двух основных информационных системах. Всего систем не более десятка. IT-департамент хотел бы, чтобы процесс предоставления доступа начинался из кадровой системы, далее переходил на этап согласования со всеми заинтересованными сторонами, заявке назначалась соответствующая роль и предоставлялся соответствующий доступ к целевым системам. В то же время ИБ-департамент контролирует процесс согласования и выполняет верификацию выполненных прав доступа.
На рис. 1 представлена желаемая автоматизация процесса предоставления доступа при приеме и увольнении сотрудников.
Если же у нас происходит изменение роли пользователя (рис. 2), то IDM должна получать управляющее воздействие из Service Desk после этапа согласования.
Вроде все просто, но решение о внедрении IDM 
не принято (о чем мы подробнее поговорим ниже). В данный момент процесс работает без IDM, хоть и не без проблем. Таким образом, IDM должна легко адаптироваться в существующую схему работы.
Во-вторых, процессы динамически развиваются. То есть IDM должна изменяться вместе с другими элементами процесса – информационными системами и организационной частью.
В-третьих, автоматизация процесса должна оптимизировать время (и расходы) обслуживания процесса.
К сожалению, у IDM по всем пунктам появляются сложности.
Организационные проблемы
Все IDM используют ролевую модель предоставления доступа. Это хорошо и правильно. Каждый сотрудник должен иметь права, соответствующие его роли и должностным обязанностям.
И здесь появляется «но». Разработка ролевой модели – чрезвычайно трудоемкий процесс, который может не закончиться никогда. Суть модели в том, что для каждой уникальной должности нужно составить свою роль, обладающую необходимым набором прав доступа к информационным системам. Причем в идеальной ситуации одинаковые должности соответствуют одной роли. На практике же сотрудники, занимающие одинаковые должности, могут иметь разные роли за счет дополнительных должностных обязанностей. Поэтому для того, чтобы определить соответствующие роли, необходимо получить соответствующую техническую информацию, «выгрузку» по правам из информационных систем, опросить администраторов информационных систем (или их отдельных модулей), администраторов информационной безопасности и владельцев ресурсов (руководителей бизнес-подразделений). А затем свести все в единую матрицу и согласовать ее со всеми участниками предыдущего процесса и с руководством заказчика.
Например, в банке трижды пробовали составить ролевую модель. И каждый раз она становилась неактуальной после ее создания. Многие компании тяжело укладываются в строго определенные рамки, и причины этого самые разные.
Если вы можете создать актуальную ролевую модель, значит вы можете описать процесс предоставления доступа. И вы переходите к выбору решения.
Проблемы внедрения
Необходимо сказать сразу, IDM-решения – не «коробочный» продукт. Из «коробки» IDM работает с узким кругом систем. Если вам необходимо управлять учетными записями в AD, почте и СУБД, вам скорее всего хватит базового функционала. Но, например, в банке необходима интеграция с 1С, не самым популярным Service Desk, и программой, которая не поддерживает даже LDAP-каталоги, не говоря уже о большем.
А ведь IDM должен быть глубоко интегрирован в информационные системы. Подключение разнообразных систем, конечно, производится с помощью коннекторов, через которые ядро IDM работает с информационными системами. Лучше, если коннектор разрабатывает сам вендор. Вы верите, что крупный западный вендор будет разрабатывать коннектор для отечественных систем? Или что стоимость такого коннектора будет разумной?
Также не стоит забывать, что информационные системы иногда обновляются. Как быстро обновится коннектор? За месяц? Квартал? Лично я знаю лишь одного вендора, который обновляет коннекторы в течение месяца, но этот вендор не производит IDM-решения. Получается, что нам уже приходится выбирать: либо автоматизация управления учетками, либо новый функционал и/или исправленные ошибки в ПО. Думаю, бизнес выберет последнее, ему работать надо.
Таким образом, IDM-решение должно быть кастомизированным, доработанным специально под заказчика. И тут в полный рост встает проблема целесообразности.
Проблема цены
IDM стоит дорого. Несмотря на то что IDM-решения присутствуют на рынке довольно давно, стоят они как самолет. Высокая стоимость лицензий на программное обеспечение дополняется стоимостью работ по внедрению и касто-мизации. Сюда же необходимо добавить техническое сопровождение.
Рынок не стоит на месте – уже сейчас есть предложения даже от отечественных вендоров. Тренд рынка IDM устремился в средний бизнес. Давайте вернемся к нашему примеру. Один из отечественных вендоров произвел оценку стоимости внедрения IDM и сделал выводы, что для компании в тысячу человек проект IDM будет стоить $200 тыс. и окупится за 2–3 года. В зависимости от курса цена этого решения 6–8 млн руб. в год. Сумма не такая уж и большая. Но в банке управление доступом занимает 6 человек full time. Как вы понимаете, для создания учетных записей не требуется высокой квалификации, а несложная арифметика подсказывает, что за те же деньги можно было бы нанять еще несколько человек. Это уже сомнительная экономия. А если учесть затраты на поддержание в актуальном состоянии ролевой модели (а учетные записи могут занимать многие и многие книги в Excel), то не проще ли оставить все на ручной обработке, написать пару скриптов, согласование доступа переложить на пользователей и т.п.? Тут требуется серьезное финансовое обоснование и учет специфики каждой отдельной компании.
После решения этих вопросов переходим к вопросам безопасности.
Необходимый функционал
IDM должен включать механизмы контроля и верификации предоставленных прав в целевых системах. Данный функционал заявлен в самой идеологии IDM, но часто либо не реализован, либо поставляется отдельно.
IDM должен избавить нас от «мертвых душ», убрать лишние права пользователей и т.п. Но все это уже при внедренной IDM. Но все угрозы безопасности существуют в уже работающих системах. Следовательно, должны быть:
- механизм выгрузки существующей картины;
- механизм наложения ее на необходимую ролевую политику;
- коррекция прав доступа и удаление лишних прав.
Увы, но зачастую IDM-решения могут сделать лишь один пункт из трех. Все остальное дается на откуп консультантам и интеграторам, то есть все опять же будет делать человек.
Заключение
IDM-системы необходимы. Большинство описанных проблем кроется в том, что в самом начале, при планировании инфраструктуры и создании бизнес-процессов, никто не задумывался об управлении доступом.
Если вы планируете создание новой инфраструктуры или капитальную модернизацию старой, обязательно внесите в план решение вопросов, связанных с управлением доступом, согласованием выдачи прав и созданием ролевой модели.
Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #2, 2014