Контакты
Подписка
МЕНЮ
Контакты
Подписка

Что нужно знать для успешного внедрения IdM?

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Что нужно знать для успешного внедрения IdM?

Рассмотрим, какое место IdM занимает в системе информационной безопасности предприятия на примере банка и на что следует обратить особое внимание уже на этапе планирования, чтобы сделать дальнейшую эксплуатацию системы максимально эффективной
Анатолий Скородумов
Начальник Управления по обеспечению информационной
безопасности Банка "Санкт-Петербург"

Планируя внедрять IdM в Банке "Санкт-Петербург" шесть лет назад, мы попросили трех лидирующих на тот момент вендоров, которые входили в квадрант Гартнера и были ведущими производителями IdM-систем, о референс-визитах, чтобы наглядно увидеть примеры лучших внедрений. Однако, съездив в три крупные московские компании и изучив их проекты, мы ни один из них не могли бы назвать успешным.

Внедрение IdM действительно очень сложное и трудоемкое, и здесь многое зависит от поставщика, интегратора и компании-заказчика.

Цели внедрения системы IdM

Наиболее часто указываемые в литературе цели внедрения системы IdM:

  • сокращение времени предоставления сотруднику необходимых прав доступа;
  • снижение нагрузки на администраторов;
  • повышение уровня информационной безопасности;
  • повышение прозрачности управления доступом;
  • упрощение процедур оформления и согласования прав доступа.

На самом деле это никуда не годные цели. Для научно-популярной статьи они, возможно, и неплохи, но для проекта по внедрению IdM совершенно не подходят.

Давайте посмотрим внимательнее на каждую из вышеуказанных целей.

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

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

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

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

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

Снижение нагрузки на администраторов автоматизированных систем

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

Повышение уровня информационной безопасности

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

Повышение прозрачности уровня доступа

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

Думаю, мысль понятна. Прежде чем что-то внедрять, тем более систему IdM, стоит четко определить цели, которые необходимо достигнуть. Существует такое понятие, как смарт-цели – конкретные и измеримые. Именно такие и необходимо ставить при внедрении IdM.

Скоуп проекта

Следующий этап – содержание проекта. Какие системы нужно включать в проект по IdM, то есть в каких системах через IdM будут предоставляться права доступа?

Однозначно одна из них – кадровая система, из которой нужно забирать данные. Далее нужно сразу подумать об источнике данных о внештатных сотрудниках. И затем стоит еще одна немаловажная задача – определиться с тем:

  • для каких систем будут запрашиваться данные через IdM;
  • в каких системах через IdM будут автоматически назначаться права доступа.

Последний пункт наиболее сложный, так как существуют два варианта реализации:

  1. Идеальный вариант: сотрудник запрашивает в системе IdM права доступа, эта заявка согласовывается в установленном порядке, после чего IdM в автоматическом режиме заводит учетную запись пользователя в системе и назначает ему права доступа.
  2. Наиболее распространенный вариант: заводится заявка в IdM, она проходит нужное согласование, после чего выгружается задача на администратора либо на сервис-деск и дальше права доступа предоставляются администратором системы.

Не уверен, что при внедрении системы IdM надо полностью отказаться от того варианта, когда права предоставляются автоматически, но следует максимально сузить число таких систем. Это резко упростит реализацию проекта по внедрению IdM-системы.

Формирование функциональных требований

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

Вот только некоторые из функциональных требований:

  1. Наличие готовых коннекторов к эксплуатируемым АС. Большинство вендров заявляют, что у них 300, 500 и больше готовых коннекторов к каким-то определенным системам. Стоит сразу посмотреть, насколько этот список покрывает то, что реально эксплуатируется в инфраструктуре.
  2. Наличие порталов самообслуживания. Тоже очень важный элемент, где есть выбор:
    • вообще не пользоваться порталом самообслуживания и действовать по варианту, когда IdM прописывает данные в автоматическом режиме в определенные системы;
    • пользоваться порталом самообслуживания IdM, и тогда к этому вопросу нужно подойти очень серьезно, потому что им будут пользоваться все сотрудники организации. Как минимум необходим быстрый и понятный интерфейс. Хорошо, если он будет похож на те, которыми уже пользуются сотрудники.
    • не использовать то, что предлагает вендор, и реализовать портал самообслуживания на собственных системах (например, на корпоративном портале, интегрируя его с выбранной платформой IdM).

Стоит обратить внимание и на другие функциональные требования:

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

Критерии выбора IdM

Приведу критерии, которые мы определили в 2010 г. при внедрении проекта и которые при желании можно расширить, углубить и улучшить:

  • соответствие сформированным функционально-техническим требованиям;
  • политика лицензирования и стоимость лицензий;
  • стоимость внедрения и владения;
  • наличие готовых коннекторов к эксплуатируемым АС;
  • наличие успешных внедрений (прежде всего в России);
  • наличие русскоязычного интерфейса и техподдержки;
  • оценка рейтинговых агентств;
  • заявленные сроки внедрения.
  • требования к аппаратной платформе;
  • удобство использования.

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

Чтобы реализовать технологию, при которой автоматизированная система не входит непосредственно в скоуп (то есть IdM не предоставляет автоматизированной системе автоматически права доступа), важно иметь реализованные ИТ-процессы по управлению изменениями и управлению инцидентами. Как минимум должен быть сервис-деск, на который можно отбрасывать заявки с IdM и который будет их распределять в соответствии с инструкциями. Если этого нет, то в целом вся схема будет работать очень криво и требовать много внимания. Особое внимание хотел бы обратить на наличие ролевых моделей. Что такое ролевая модель? Ролевая модель формируется для группы сотрудников, имеющих примерно одинаковый функционал. Соответственно, прописываются права для этой группы во всех АС, входящих в проект. Задача очень сложная и нетривиальная. По факту оказывается, что даже у сотрудников в одном отделе отличающиеся права доступа. При этом организация – это живой организм, постоянно происходят какие-то изменения.

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

О чем стоит подумать заранее?

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

1. Сразу стоит оценить объем доработок в прикладных системах. Их стоимость в нашем проекте была сопоставима со стоимостью внедрения IdM.

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

3. Учет системных и технологических учетных записей. Необходимо сразу решить, будут ли они учитываться в IdM или нет. Конечно, с точки зрения информационной безопасности их учитывать надо, но стоит ли управлять ими – большой вопрос.

4. Обработка отпускных, декретного отпуска, больничных. Будет ли блокироваться учетная запись сотрудника в системах на период отпуска или нет?

5. Оргштатные мероприятия. На мой взгляд, это очень сложный процесс. Ведь даже простое переименование подразделения может привести к тому, что на следующий день ни у одного сотрудника не будет никаких прав доступа. Например, в "1С: Предприятие" используются "1С: Зарплата и кадры", и если директор по персоналу создал новое подразделение и перевел в него всех сотрудников, то формально это переименование, а в системе – создание новой структуры с новыми штатными единицами. И получается, что у сотрудников старого подразделения все права отобрали, а ни у одного сотрудника нового подразделения прав доступа нет, так как для него нет ролевой модели.

Место IdM в системе информационной безопасности банка

На рис. 1 представлен цикл Деминга, или цикл PDCA, описывающий правильное построение процесса. А обеспечение информационной безопасности – это, прежде всего, правильно выстроенные процессы.


Когда мы говорим о системе IdM, то имеем в виду процесс управления правами доступа. Рассмотрим четыре составляющие цикла Деминга с точки зрения IdM:

  1. Планирование. Проводятся организационные и технические мероприятия, разработка проектной документации на внедрение IdM.
  2. Внедрение. Реализация требований документов, внедрение IdM.
  3. Контроль. В рамках согласования заявок осуществляется текущий контроль предоставления прав доступа через IdM-систему, и с помощью отчетов и других механизмов IdM-системы обеспечивается проверка корректности и правильности выданных прав доступа.
  4. Совершенствование. Улучшение организационной составляющей, внесение изменений в инструкции и положения, проведение дополнительных настроек, а иногда и доработок в IdM-системе.

Взаимодействие IdM с другими продуктами по обеспечению ИБ

С какими системами, на наш взгляд, было бы правильно интегрировать IdM-систему?

  1. SIEM – система по сбору логов и корреляции событий ИБ. Хорошей практикой является отбрасывание на SIEM-систему логов из всех систем безопасности (и не только безопасности).
  2. Single Sign-On – система аутентификации. Помимо того, что учетная запись в системе заведена, ей нужно назначить аутентификационные данные. Если используется внешняя система SSO, ей нужно сказать, что под определенной учетной записью будет входить тот человек, который в этой системе SSO уже заведен. Для этого нужна интеграция с IdM.
  3. PIM – система управления привилегированными учетными записями. Обычно PIM используется в том числе для контроля удаленного подключения в корпоративную сеть. Соответственно, функционировать все должно примерно так: в IdM запрашивается заявка на удаленный доступ, она проходит согласование в портале PIM, и у сотрудника сразу появляется новый компьютер в списке компьютеров, к которым он должен получить удаленное подключение.
  4. DLP – система защиты от утечек. Практически обязательным объектом в любой DLP-системе является так называемое досье клиента. Очень удобно, когда в этой же системе можно сразу посмотреть, какие права доступа у определенного сотрудника к различным системам, чтобы понять, откуда он мог скачать ту или иную информацию, которую отправляет вовне.

Мифы об IdM

Развеем некоторые мифы, связанные с IdM.

1. IdM обеспечивает контроль за действиями администраторов. Не обеспечивает. Так как в большинстве систем IdM автоматически не прописывает права доступа, соответственно, никогда не увидит, что там делает администратор по собственному желанию в обход IdM. Но даже для систем, где IdM автоматически не прописывает права доступа, это тоже не работает. Цикл обновления данных у IdM – около 1–2 часов. Соответственно, все, что происходит в системе в течение этого времени, IdM не видит. Какие-то ошибки администрирования через систему можно выявить, например, что администратор по доброте душевной включил пользователя в какую-то группу доступа в обход IdM. Но если администратор хочет произвести какие-то действия так, что бы IdM этого не заметил, для него не составит большого труда это сделать.

Для контроля администраторов нужны другие системы, такие как SIEM и PIM.


2. IdM отбирает у пользователей излишние права доступа. Не отбирает, примерно по тем же причинам, что и в первом мифе. Следует также отметить, что управление пользователями в большинстве систем осуществляется на уровне групп доступа. И именно составом групп управляет IdM. Соответственно, если пользователя в обход IdM поместили в какую- то группу пользователей, то он его оттуда "вычистит". Но если права доступа предоставлены непосредственно учетной записи, IdM об этом не узнает.

3. Применение IdM позволяет реализовать принцип предоставления минимальных прав доступа сотруднику. Это не работает. Внедрение IdM связано с формированием ролевых моделей. Если формировать ролевые модели для каждого сотрудника и пытаться предоставить ему исключительно те права, которые нужны для исполнения функциональных обязанностей, будет такое количество ролей и привилегий, что никогда не получится ими управлять. Поэтому формирование ролевой модели – это всегда компромисс, кто бы что ни говорил. Ролевая модель всегда будет избыточна, и только владельцу решать – насколько. Чем более она будет избыточна, тем меньше будет ролей и тем проще будет ими управлять. И, соответственно, чем более точные права доступа предоставлять, тем больше будет ролей и тем сложнее будет всем этим управлять и сопровождать.

Залог успеха

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

Опубликовано: Журнал "Системы безопасности" #3, 2018
Посещений: 4701

  Автор

Анатолий Скородумов

Анатолий Скородумов

Начальник Управления по обеспечению информационной
безопасности Банка "Санкт-Петербург"

Всего статей:  3

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций