В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций
Планируя внедрять IdM в Банке "Санкт-Петербург" шесть лет назад, мы попросили трех лидирующих на тот момент вендоров, которые входили в квадрант Гартнера и были ведущими производителями IdM-систем, о референс-визитах, чтобы наглядно увидеть примеры лучших внедрений. Однако, съездив в три крупные московские компании и изучив их проекты, мы ни один из них не могли бы назвать успешным.
Внедрение IdM действительно очень сложное и трудоемкое, и здесь многое зависит от поставщика, интегратора и компании-заказчика.
Наиболее часто указываемые в литературе цели внедрения системы IdM:
На самом деле это никуда не годные цели. Для научно-популярной статьи они, возможно, и неплохи, но для проекта по внедрению IdM совершенно не подходят.
Давайте посмотрим внимательнее на каждую из вышеуказанных целей.
На первый взгляд, хорошая цель. Предположим, что сейчас права доступа в организации выдаются системному сотруднику в течение семи дней. После реализации проекта IdM это время сократится до пяти дней. Формально цель достигнута. Но следует оценить реально, сколько времени нужно на выдачу прав доступа.
Допустим, необходимо выдать все права доступа новому сотруднику после приема на работу в течение одного рабочего дня, но при этом по рабочему процессу установка компьютера на рабочее место и его настройка осуществляются в течение двух дней. Зачем тогда выдавать права доступа за один день?
Другой пример: если в банке сотрудник проходит недельное обучение в учебном центре по работе с теми программными продуктами, в которых ему предстоит выполнять свои функциональные обязанности, то ему предоставление прав доступа в течение одного дня не нужно.
Поэтому необходимо трезво оценить те технологические процессы, которые проходят в организации, и четко понимать, до какого уровня нужно сократить время предоставления прав доступа, и, возможно, внести изменения.
Нагрузка на определенных администраторов домена и конкретных автоматизированных систем в какой-то степени снизится. Но нужно понимать, что новая автоматизированная система тоже требует администрирования и технической поддержки. IdM обычно используется всеми сотрудниками банка, соответственно, требуется обучение. Возрастает нагрузка на сервис-деск, потому что достаточно часто сотрудник не понимает, какую роль ему надо запросить в системе IdM, и звонит в сервис-деск. Таким образом, если рассмотреть совокупность затрат времени ИT-специалистов, которые получатся в результате внедрения IdM, возможно, никакого сокращения нагрузки и не будет.
Хорошая цель, но и здесь следует четко понимать, что именно в части обеспечения информационной безопасности необходимо от IdM. Это не так просто сделать в количественном выражении. Например, в нашей компании точно решилась проблема с отбором прав доступа у увольняемых и переводимых из подразделения в подразделение сотрудников.
Казалось бы, при наличии IdM каждый руководитель может посмотреть, какие права доступа есть у его сотрудника. Может, но не хочет. Во всяком случае, я таких руководителей еще не встречал.
Думаю, мысль понятна. Прежде чем что-то внедрять, тем более систему IdM, стоит четко определить цели, которые необходимо достигнуть. Существует такое понятие, как смарт-цели – конкретные и измеримые. Именно такие и необходимо ставить при внедрении IdM.
Следующий этап – содержание проекта. Какие системы нужно включать в проект по IdM, то есть в каких системах через IdM будут предоставляться права доступа?
Однозначно одна из них – кадровая система, из которой нужно забирать данные. Далее нужно сразу подумать об источнике данных о внештатных сотрудниках. И затем стоит еще одна немаловажная задача – определиться с тем:
Последний пункт наиболее сложный, так как существуют два варианта реализации:
Не уверен, что при внедрении системы IdM надо полностью отказаться от того варианта, когда права предоставляются автоматически, но следует максимально сузить число таких систем. Это резко упростит реализацию проекта по внедрению IdM-системы.
Чем тщательнее и грамотнее подойти к формированию функциональных требований, тем легче будет проходить этап внедрения и тем меньше грабель будет собрано на этапе внедрения и эксплуатации.
Вот только некоторые из функциональных требований:
Стоит обратить внимание и на другие функциональные требования:
Приведу критерии, которые мы определили в 2010 г. при внедрении проекта и которые при желании можно расширить, углубить и улучшить:
Для формирования ролевой модели нужен перечень информационных активов с точки зрения информационной безопасности с понятным описанием (что там хранится, кому это нужно и т.д.).
Чтобы реализовать технологию, при которой автоматизированная система не входит непосредственно в скоуп (то есть IdM не предоставляет автоматизированной системе автоматически права доступа), важно иметь реализованные ИТ-процессы по управлению изменениями и управлению инцидентами. Как минимум должен быть сервис-деск, на который можно отбрасывать заявки с IdM и который будет их распределять в соответствии с инструкциями. Если этого нет, то в целом вся схема будет работать очень криво и требовать много внимания. Особое внимание хотел бы обратить на наличие ролевых моделей. Что такое ролевая модель? Ролевая модель формируется для группы сотрудников, имеющих примерно одинаковый функционал. Соответственно, прописываются права для этой группы во всех АС, входящих в проект. Задача очень сложная и нетривиальная. По факту оказывается, что даже у сотрудников в одном отделе отличающиеся права доступа. При этом организация – это живой организм, постоянно происходят какие-то изменения.
Я бы настоятельно не рекомендовал реализовывать проекты по IdM, когда компания не находится в относительно стабильном состоянии. Например, если идет бурный рост организации, организационные штатные мероприятия по сокращению и оптимизации, смена программно-аппаратной платформы и т.д., не следует начинать процессы по внедрению IdM. Лучше закончить начатое и затем в более спокойной обстановке приступать к внедрению IdM-системы. Иначе не получится нормально реализовать ролевую модель, а без нее IdM – это просто система по учету заявок на предоставление доступа и ничего более.
Основные функциональные требования достаточно просто сформировать или найти в научно-популярных статьях. Но все же стоит подумать и об огромном количестве сопутствующих вещей. Это те грабли, на которые мы наступили в процессе эксплуатации. И сейчас, по прошествии шести лет, я понимаю, что об этом нужно было подумать до того, как мы начали внедрять IdM-систему. Остановимся на некоторых из них.
1. Сразу стоит оценить объем доработок в прикладных системах. Их стоимость в нашем проекте была сопоставима со стоимостью внедрения IdM.
2. Управление учетными записями внештатных сотрудников. Нужно понять, как с помощью IdM управлять учетными записями внештатных сотрудников, потому что автоматически из кадровой системы подгружать их, скорее всего, не получится. Речь идет прежде всего об учетных записях тех работников и контрагентов, которые имеют доступ к информационным системам (как минимум удаленный доступ в корпоративную сеть).
3. Учет системных и технологических учетных записей. Необходимо сразу решить, будут ли они учитываться в IdM или нет. Конечно, с точки зрения информационной безопасности их учитывать надо, но стоит ли управлять ими – большой вопрос.
4. Обработка отпускных, декретного отпуска, больничных. Будет ли блокироваться учетная запись сотрудника в системах на период отпуска или нет?
5. Оргштатные мероприятия. На мой взгляд, это очень сложный процесс. Ведь даже простое переименование подразделения может привести к тому, что на следующий день ни у одного сотрудника не будет никаких прав доступа. Например, в "1С: Предприятие" используются "1С: Зарплата и кадры", и если директор по персоналу создал новое подразделение и перевел в него всех сотрудников, то формально это переименование, а в системе – создание новой структуры с новыми штатными единицами. И получается, что у сотрудников старого подразделения все права отобрали, а ни у одного сотрудника нового подразделения прав доступа нет, так как для него нет ролевой модели.
На рис. 1 представлен цикл Деминга, или цикл PDCA, описывающий правильное построение процесса. А обеспечение информационной безопасности – это, прежде всего, правильно выстроенные процессы.
Когда мы говорим о системе IdM, то имеем в виду процесс управления правами доступа. Рассмотрим четыре составляющие цикла Деминга с точки зрения IdM:
С какими системами, на наш взгляд, было бы правильно интегрировать 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
Посещений: 4640
Автор
| |||
В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций