Как развернуть IDM правильно

Почему же российский бизнес так неохотно внедряет решения класса IDM, ведь плюсы от подобной системы очевидны (более того, экономический эффект от внедрения IDM легко просчитать)? Первая и главная причина — высокая стоимость подобного решения. Дело в том, что на заре IDM флагманами сегмента были западные компании-гиганты, такие как Oracle, Sun и IBM, что и отразилось на стоимости. Для огромного количества российских компаний ценовая политика этих вендоров является не самой гуманной. Но в то время IDM-системы не испытывали особой конкуренции со стороны более доступных продуктов.
Правда, несмотря на дороговизну некоторые российские компании, особенно из сектора крупного и очень крупного бизнеса, решались на внедрение IDM. И что увидели в итоге? Картина получилась весьма прискорбная: успешными становятся один-два кейса из десяти стартовавших проектов. Это не точная статистика, а приблизительное отражение ситуации, сложившейся на российском рынке IDM в 2006—2008 гг.
Почему же успешных внедрений так мало? Причина — в избыточной сложности таких решений, не позволившей многим компаниям довести дело до финального этапа. Причем основная сложность заключается даже не в трудностях интеграции IDM с российскими ИТ-системами, хотя и это тоже было сдерживающим фактором; главная сложность состояла в методологии (или, если угодно, идеологии), применявшейся при внедрении. А ее краеугольным камнем являлась идея построения полной ролевой модели. В принципе ролевая модель (и матрица доступа) — знакомые слова для любого ИТ- или ИБ-специалиста. Все понимают, что без этого — никуда, и любое наведение порядка в системе управления доступом начинается именно с них. И вот тут наступает коллапс, ведь сама по себе IDM-система не решает эту задачу автоматически, создать же ролевую модель в компании из 5—10 тысяч человек, у которой штатное расписание сотрудников едва умещается на двадцати листах формата А4, — задача просто неподъемная.
Пожалуй, не будет преувеличением назвать эту область ИТ и ИБ одной из наиболее сложных. Поэтому заказчику исключительно важно отнестись к данной проблеме предельно серьезно, продумав наперед весь алгоритм построения ролевой модели в своей организации. Давайте рассмотрим шаги, которые нам помогут не погрязнуть во внедрении на многие и многие годы.

Первое и, вероятно, главное, что необходимо сделать, — это решить, как именно будет происходить переход от текущей анархичной структуры к строгой ролевой модели. На мой взгляд, для ИТ- и ИБ-специалистов компании, решившей внедрить IDM, эта задача даже важнее, нежели финансовый вопрос.

1. Определите точное количество информационных систем, с которыми потребуется интегрировать IDM-решение.
Важно понимать, что интеграция нужна не со всеми ИТ-системами, используемыми в компании. Из их множества необходимо выделить лишь те, в которых присутствует собственная аутентификация. То есть вас должны интересовать только такие инфраструктурные и прикладные элементы ИС, в каких существуют свои собственные учетные записи и соответственно используются свои группы безопасности и роли для управления доступом. Это важно, поскольку любое современное IDM-решение интегрируется с внешними системами посредством так называемых «коннекторов» (модулей интеграции). И нужно быть готовым к тому, что к некоторым вашим системам, особенно очень кастомизированным или вообще самописным, готовых коннекторов у производителя не будет, а значит, потребуется их разработка.

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

2. Выработайте план создания ролевой модели. Как я уже отметил, для любой IDM-системы ролевая модель обязательна, а методология ее построения может стать ключевым моментом в выборе того или иного продукта и даже определяющим в решении, внедрять IDM или нет.

Несмотря на это еще несколько лет назад, когда IDM-системы только начали завоевывать рынок, созданию ролевой модели, на мой взгляд, не уделяли должного внимания. Обычно все это отдавалось на откуп интегратору, ведущему проект по внедрению, или даже самому заказчику. В результате в ряде случаев мы стали свидетелями колоссальных по трудозатратам консалтинговых работ, при этом не всегда имеющих на выходе работающую ролевую модель. Дело в том, что в крупной компании создание ролевой модели в ручном режиме не только крайне трудно, но и практически бессмысленно, поскольку условия бизнеса, оргструктура, должностные обязанности и сами информационные системы постоянно меняются, вследствие чего инвентаризационные сведения устаревают намного раньше завершения разработки ролевой модели. Соответственно и матрица доступа, на создание которой нередко требуется от полугода до года, не может быть введена в действие по причине ее устаревания. Единственным выходом из этого тупика являются автоматизированные инструменты, ускоряющие эту работу. И такие инструменты существуют в линейках компаний Oracle и «Аванпост».

3. Используйте инструменты, автоматизирующие процесс построения ролевой модели. Принцип работы этого модуля приблизительно следующий. Сначала IDM-решение разворачивается в режиме, как некоторые любят говорить, «пылесоса», поскольку на этом этапе модуль Role Manager, используя стандартные коннекторы, извлекает из кадровой системы предприятия информацию о сотрудниках и их должностях, а из прикладных и инфраструктурных элементов ИС — текущую информацию по предоставленным правам. На выходе получается огромный «черновой» массив информации, который точно отражает реальную ситуацию с правами доступа всех пользователей на текущий момент.

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

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

В итоге получается компактная ролевая модель, близкая к идеальной, а на ее создание требуется так мало времени, что эффект изменчивости организации просто не успевает проявиться!

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

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

Большинство неудачных попыток внедрения IDM, на мой взгляд, потерпели фиаско именно из-за того, что люди начинали планирование сразу с последнего шага. Как говорится, определились с бюджетом — и вперед. Но не всё можно решить деньгами, их количество не определяет напрямую качество и сроки внедрения IDM. Далеко не факт, что дорогой западный продукт автоматически решит ваши проблемы. Как, впрочем, совсем не факт, что более бюджетное решение не оправдает все ваши ожидания.

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

Александр Санин, коммерческий директор компании Аванпост

Avanpost — российский вендор-новатор в области безопасности идентификационных данных, развивает свою экспертизу с 2007 г.
Avanpost предлагает как комплексное решение безопасности Identity Security Platform для защиты цифровых идентичностей пользователей, устройств и приложений от различных угроз для крупных предприятий и нагруженных инфраструктур, так и более легкие стандартизированные продукты для среднего бизнеса:

• Avanpost IDM/IGA — система управления учетными записями и доступом к корпоративным ресурсам предприятия;
• Avanpost SmartPAM для контроля привилегированного доступа;
• Avanpost DS — российская служба каталогов, предназначенная для управления Linux-инфраструктурами и замены MS AD, каталог для промышленных нагрузок, протестированный на 30 млн объектах);
• Avanpost CA (российский доменный сервис сертификации; универсален для различных доменов, включая MS),
• Avanpost PKI (управление жизненным циклом объектов инфраструктуры открытых ключей из единого центра),
• Продукты линейки аутентификации Avanpost Access: FAM, MFA+, USSO, WSSO,  Device Control.

Экосистема программного обеспечения по управлению доступом построена на базе полностью собственного программного обеспечения, лучшего в своем классе, не зависящего от сторонних решений и Open Source компонентов.
Архитектура продуктов предполагает использование в отказоустойчивых, геораспределенных, высоконагруженных инфраструктурах.
Avanpost придерживается идеологии максимальной открытости. Технологически совместимы с отечественным ПО, интегрируем и объединяем программные компоненты различных вендоров.