Решения класса Identity Management (IDM), или, если кому-то больше нравится, Identity&Access Management (IAM), призваны навести порядок в вопросах управления доступом. А именно — сделать управление учетными записями в разрозненных ИТ-системах централизованным, автоматизированным, контролируемым и, самое главное, удобным. Такие системы — не очередная новомодная тенденция, а острая необходимость. При этом сами IDM-решения появились на ИТ-рынке довольно давно — около десяти лет назад, но с тех пор так и не стали массовыми. Вернее, массовыми они не стали в России, а на Западе доля проникновения подобных систем в компании среднего и крупного масштаба достаточно высока и превосходит российские реалии на порядок. В чем же причина такого положения дел, и что нужно делать компании, решившей навести порядок в своей системе управления доступом к корпоративным ИТ-ресурсам? На эти вопросы мы и постараемся ответить в данной статье.

Две ключевые проблемы внедрения IDM

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

How To

Первое и, вероятно, главное, что необходимо сделать, — это решить, как именно будет происходить переход от текущей анархичной структуры к строгой ролевой модели. На мой взгляд, для ИТ- и ИБ-специалистов компании, решившей внедрить 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-продукта, не нужно руководствоваться только ценой и функциональностью, важно смотреть на методологию внедрения. Ведь, как показала практика, именно методология внедрения и политика создания ролевых моделей в конечном итоге влияют на финальный результат больше, чем все остальные факторы вместе взятые.

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