Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог
Сергей Солдатов, CISA, CISSP, эксперт по ИБ
Как организовать проект создания корпоративной системы управления правами доступа к информационным ресурсам, часто обозначаемой аббревиатурой IAM (Identity and Access manager) или IDM (Identity manager)? Автор подробно рассматривает конкретные аспекты и последовательность реализации такого проекта, не затрагивая архитектурные особенности обсуждаемых решений. И хотя речь идет исключительно об IDM, большинство из предлагаемых подходов применимы к проектированию и других сложных систем.
IDM – это ИС, которая решает следующие задачи: импорт данных о пользователях из источников данных и технических ролей из управляемых ИС; обеспечение бизнес-процессов создания, изменения и удаления бизнес-ролей, присвоения пользователям ролей и их удаления, аудита прав доступа по разным требованиям и сценариям; предоставление отчетов о текущем состоянии доступа пользователей и истории процессов контроля над доступом. Мы обсуждаем IDM, в интерфейсе которой рассматриваются заявки и выполняются операции согласования и отклонения.
Проект внедрения IDM – непростой. Эта ИС должна быть интегрирована со всеми значимыми для бизнеса управляемыми системам и источниками кадровых данных. Кроме того, автоматизация контроля над доступом подразумевает большую организационную составляющую, а налаживать взаимодействие людей труднее, чем настраивать любую ИС.
Бизнес-аргументы и поиск союзников
Для получения финансирования с целью внедрения IDM необходимо сформулировать и предоставить бизнесу веские аргументы. Назовем некоторые из них:
Правда, эти «плюсы» не всегда можно выразить количественно, поэтому вам понадобятся и доводы, связанные с экономией ресурсов. Например:
При внедрении IDM бизнес-эффект ощутят многие подразделения. Стоит им об этом рассказать, чтобы они стали вашими союзниками при защите финансирования.
Например, на ИТ-службу обычно валятся все шишки, связанные с реализацией правил безопасности. IDM облегчает процессы контроля доступа, что влечет за собой положительную оценку пользователями работы ИТ-службы. Кроме того, значительно сократится объем ее рутинной работы.
На крупных предприятиях анализом корпоративных бизнес-процессов, оценкой связанных с ними рисков и проблемами внутреннего контроля может заниматься специализированное подразделение. Обычно конфликты полномочий (SoD-конфликты) представляют в виде гигантских матриц, проверять которые вручную при каждом согласовании заявки на доступ невозможно. Однако данную задачу прекрасно автоматизирует IDM, что, безусловно, заинтересует подразделение внутреннего контроля.
Залог успеха проекта – четкое понимание его границ и постоянный контроль над их неизменностью. При определении функциональных границ не следует включать в них «впрок» все потенциально полезные свойства. Эти затраты сложно обосновать: они необходимы сейчас, а востребованность «запасных» функций в будущем туманна. К тому же расширение границ проекта отнимает ресурсы, которые можно направить на реализацию 20% функционала, дающих, по закону Парето, 80% эффекта внедрения. При «адаптации» функциональных требований в ходе проекта для обеспечения их постоянной адекватности, скорее всего, вы этот проект вообще не реализуете. Функционал должен «закрывать» только актуальные задачи, а временные рамки проекта – составлять не больше года!
Плодотворен подход к сложным проектам, заключающийся в их разбиении на совокупность простых задач и последовательном их решении. Главное – не реже, чем раз в полгода, получать ощутимые результаты. Если вам нужно запустить IDM с широким функционалом во множестве подразделений компании, применяйте функциональную и географическую этапность.
Например, весь функционал IDM поделен на первостепенный, второстепенный и остальной, а структурные подразделения – на Центр, ключевые и остальные. На I этапе первостепенный функционал разрабатывается и внедряется в Центре. На II этапе он тиражируется в ключевых подразделениях. На III этапе второстепенный функционал разрабатывается и внедряется там, где уже действует первостепенный; одновременно первостепенный функционал тиражируется в остальных подразделениях. На IV этапе второстепенный функционал тиражируется в остальных подразделениях, а остальной функционал разрабатывается и внедряется в Центре. На V этапе остальной функционал тиражируется в тех подразделениях, в которых завершилось внедрение второстепенного.
Этапность может быть иной в зависимости от обеспеченности проекта ресурсами, длительности периодов разработки и реализации функциональных этапов и множества других факторов. Но мы всегда должны параллельно разрабатывать новый функционал и тиражировать уже имеющийся.
Одна из важнейших задач – быстрое получение максимально возможного результата, поэтому разумно сначала внедрять то, что сразу дает ощутимый эффект. Результаты реализации проекта должны стать совокупностью «быстрых дешевых побед».
Полезно вспомнить, как вы обосновывали внедрение IDM. Нужно снизить стоимость процессов контроля доступа и сократить время простоя пользователей в ожидании доступа? Значит, первыми ИР в последовательности функциональной реализации должны стать те, по которым больше всего заявок и/или которые характеризуются наибольшей трудоемкостью их обработки. Хотите устранить денежные потери из-за простоя новых сотрудников и ожидания изменения доступа уже работающих? Тогда первыми реализуйте бизнес-процессы «прием на работу» (передача данных о работнике из кадровой службы в наиболее востребованные корпоративные ИС) и «назначение роли пользователю» (обеспечение маршрутизации заявки между согласующими и ее исполнения).
Теперь определим наиболее востребованные отчеты и займемся ими. Проанализируем требования к пользовательскому интерфейсу и поступим так же. В итоге все требования следует распределить по функциональным этапам.
Аналогичный подход применим и к географии: определим структурные подразделения, внедрение в которых IDM даст наиболее заметный эффект. Например, это подразделения с наиболее дорогими трудовыми ресурсами или те, чья специфика работы обусловливает максимально большое количество заявок на изменение прав доступа.
Команда экспертов
При выборе программного продукта лучше пользоваться методикой его оценки по критериям, которую проводят эксперты в разных предметных областях. Все решения принимаются коллективно: идет поиск вариантов с помощью «мозгового штурма» и отсеивание непригодных предложений.
Выбирать экспертов следует с учетом следующих требований: полное «покрытие» интересов каждого заказчика функционала IDM, личная заинтересованность экспертов в сервисах IDM, компетентность каждого эксперта в своей предметной области и наличие у него представления о функционале IDM. Примерный состав экспертной группы таков: архитектор, обладающий достаточными компетенциями во всех функциональных областях IDM и вопросах интеграции со смежными системами; эксперт по интеграции каждой смежной системы; эксперт по поддержке рабочих мест; эксперт по внутреннему контролю, ответственный за разрешение конфликтов полномочий; эксперт по ИТ-инфраструктуре, который отвечает за интеграцию IDM с инфраструктурными системами: сервисами резервного копирования, обновления, службы каталога, антивирусного обеспечения и т.п.; эксперт по организационным и техническим вопросам обеспечения ИБ.
Выбор критериев оценки
К набору критериев оценки IDM предъявляются следующие требования:
Рассмотрим этапы формирования списка критериев.
Каждый из критериев, выработанных командой экспертов, следует снабдить весовым коэффициентом. Он характеризует значимость требования, подтверждаемого данным критерием. Выбор весовых коэффициентов проводится на основе коллегиального решения. Если у экспертов возникают противоречия, выбирается наибольший вес – чтобы не снизить по ошибке значимость важного требования.
Стратегии выбора и порядок оценки решений
Возможны следующие стратегии выбора нужных решений.
Возможны, например, такие этапы оценки предлагаемых на рынке решений.
Экспертная оценка i-го требования j-ым экспертом ( ) представляет собой целое число от 0 до 100 (0 – полное неисполнение требования, 100 – полное соответствие ему). Рекомендуется задать критерии выбора экспертных оценок, что позволит защититься от субъективизма:
Результирующую оценку (S) можно представить как