На прошедшем в прошлый четверг вебинаре про управление запросами и управление доступом один из слушателей задал мне вопрос – а как организовать управление доступом в компании. С чего начать? В каком направлении двигаться? Попробую рассказать, как бы я поступал, находясь "внутри" компании.

Итак, я штатный сотрудник организации. Руководство поставило передо мной задачу организации процесса управления доступом. Что делать, к чему приступать в первую очередь?

Я бы для начала уточнил, а что сейчас, при текущей организации процесса (а он явно существует, поскольку в организации есть информационные ресурсы, права доступа к ним выдаются и отзываются), не устраивает в процессе. Собрал бы замечания и отметил бы для себя проблемные области. Какими они могут быть:

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

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

Следующим шагом начал бы планировать изменения текущей деятельности по управлению доступом для устранения обнаруженных разрывов. Тут бы мне пригодился и понадобился успешный сторонний опыт: стандарты, примеры организации процессов в других компаниях, консультации (подробнее об  этом в нашем вебинаре). На этом шаге будут изменения двух типов: организационного плана и изменения, посвящённые автоматизации. Организационная часть – это те новые виды деятельности, которые ранее не выполнялись, а теперь они необходимы для достижения целей процесса. Например, ранее ресертификация (уточнение и подтверждение востребованности выданных сотрудникам прав доступа / ролей) в организации не проводилась или была ad-hock активностью. А теперь она должна будет выполняться регулярно. Аналогично – по управлению ролевой моделью предприятия. Также я начал бы заранее смотреть и планировать организационную структуру будущего процесса. Вопрос важный, поскольку это люди, что будут данную активность в ходе процесса выполнять. И заранее провёл бы с ними подготовительные встречи, рассказав о процессе и их роли в нём.

Автоматизация – тоже важная часть. При поиске средства автоматизации я бы смотрел на охват решением задач процесса. Понимая, что есть два разных мира: процесс управления запросами и процесс управления доступом, – я бы не стал строить отдельный конвейер по обработке запросов на предоставление доступа в IDM-системе, а передавал бы запросы в систему Service Desk для обработки (подробнее об этом здесь). Скорее всего, здесь мне явно понадобилась бы помощь внешней компании, которая помогла бы интегрировать разные системы, решающие разные задачи, между собой. К тому же создавать коннекторы к управляемым в охвате процесса ИТ-системам – тоже весьма специфическое занятие, на которое внутренних ресурсов и компетенций может и не найтись.

Что дальше? Заручился бы поддержкой руководства, постарался бы заранее найти побольше если уж не сторонников, то по крайней мере, заинтересованных участников спроектированного процесса. Убедился бы в готовности средства автоматизации, в завершении настройки интеграции систем. И запустил бы процесс, наблюдая, как он себя ведёт, корректировал бы деятельность задействованных в процессе участников.

Понятно, что множество деталей скрыто внутри каждого шага (например, создание и актуализация ролевой модели, перенос её в систему автоматизации, подержание в актуальном состоянии, настройка системы автоматизации под специфичные виды запросов на доступ ("множественные заявки", "множество ИТ-ресурсов и т.д.) и т.п.), но направление моего движения для решения поставленной задачи было бы таким.