В прошлый раз мы рассмотрели подходы к построению модели доступа. Теперь нужно подумать о процедурах и технических средствах: как простроить процессы, которые помогут управлять доступом, и как это можно реализовать.
В первую очередь стоит задуматься о том, от чего вы будете отталкиваться – от того, что есть, или от того, чего хочется. Полученный результат будет сильно зависеть от отправной точки. У каждого подхода есть свои плюсы и минусы, и стоит рассмотреть оба, чтобы понять перспективы и реалии.
Пойдём от желаемого. Что мы хотим?
- Систему, которая нам сама скажет о нарушениях и SoD-конфликтах?
- Систему, которая сама построит ролевые модели?
- Управлять доступом?
- Всё контролировать?
- Обеспечить физический и логический доступ пользователей с биометрической аутентификацией и т.д.?
Здесь можно придумать еще много всего, и все это даже может быть реализуемо. Но (!) с большой вероятностью это будет индивидуальная разработка, долгая и дорогая.
А что у нас есть?
- Политики доступа,
- процесс предоставления доступа (по заявке пользователя или без неё),
- встроенные права и роли в каждой системе.
Я не зря писала в прошлой статье про модель зрелости. Создать идеальный процесс в мгновение ока не получится, но при хорошо спланированной работе можно достичь и описанного выше желаемого результата, если он востребован в вашей компании.
При проектировании процессов стоит помнить: чем проще и «прозрачнее» система, тем легче её контролировать. Чем больше различных условий и ветвлений неавтоматизированного процесса, тем чаще будут случаться ошибки.
Возьмём в качестве примера процесс предоставления доступа, при котором пользователю для выполнения некой задачи нужны новые права в системе.
Какие факторы нужно учитывать при создании такого бизнес-процесса?
- удобство для пользователей, согласующих и исполнителей,
- время
- затрачиваемое на каждый из этапов процесса,
- совокупное время осуществления процесса,
- стоимость реализации каждого шага,
- влияние на дальнейшие шаги
Сначала определимся с тем, кто у нас в данном процессе участвует:
- сам пользователь – запрашивает права доступа,
- его руководитель – согласовывает запрос, подтверждая производственную потребность,
- сотрудник информационной безопасности – согласовывает доступ, отслеживая конфликты полномочий (не у всех компаний это так, но предположим…),
- администратор информационной системы – выполняет заявку.
В процессе может быть гораздо больше участников, например: владелец ресурса, дополнительный контролёр от ИТ и т.д. А пока для разбора построения процесса нам достаточно указанных персонажей.
Теперь определимся с полем действий. Сначала для нас процесс выглядит так:
Сотрудник запрашивает права доступа, их согласует его руководитель, потом согласует офицер ИБ, после чего администратор системы выполняет запрос.
Это простой линейный процесс, выглядит он несложно, но всё же давайте разберёмся с деталями. Прошу воспринимать последующее как пример рассуждения при построении процесса. Для вашей компании и пользователей значимость отдельных факторов – удобства, временных затрат, скорости и влияния на дальнейшие шаги – могут отличаться.
Как сотрудник узнает, какой доступ ему нужен и что именно запросить? Иногда есть возможность связаться с человеком, который может подсказать, как оформить заявку правильно – спросить у руководителя, позвонить владельцу ресурса или администратору, написать письмо в техподдержку. Иногда помогает сама форма запроса доступа, в которой предложены понятные варианты на выбор, или есть поле для описания ситуации.
Все описанные опции, как правило, доступны, но это занимает некоторое время. Значит, нужно выбрать самые быстрые и удобные для пользователя варианты. (Мы же стремимся оказывать качественные услуги бизнесу.) Можно оставить актуальными 1-2 варианта, а можно – все. На данном этапе важно просто сравнить имеющиеся опции выявления нужных прав доступа по выделенным ранее параметрам.
Следующий шаг – интерфейс запроса прав доступа. Как пользователь может запросить права доступа?
Среди вариантов, что приходят в голову: телефон, почта, СЭД (система электронного документооборота), Service Desk, интерфейс IdM или просто заявка на бумаге. Важно, чтобы способ подачи заявки был достаточно простым и понятным для пользователя.
Опять-таки надо учитывать временной фактор: что быстрее – написать письмо или нажать пару кнопок в Service Desk? Нужно помнить, что на следующем шаге заявку будут согласовывать, и это тоже нужно сделать оперативно.
После выбора интерфейса запроса прав доступа, рассмотрим интерфейс согласования.
Варианты: на бумаге (мы же закладывали изначально такой вариант), по почте, через СЭД или Service Desk, интерфейс IdM.
Здесь стоит учесть сложность маршрута согласования. Мы сейчас рассматриваем линейный процесс с 2 шагами согласования. Но в жизни всё обычно сложнее, и различается в зависимости от того, к каким системам какой доступ запрашивается. Соответственно, все связанные с маршрутами согласования параметры также стоит учитывать. Могут совмещаться несколько способов согласования, и такие случаи требуют повышенного внимания и поддержки. Например: руководитель согласует заявку на бумаге, поставив свою подпись, а офицер ИБ работает со сканом заявки в СЭД'е. Это добавляет сложности и неудобства и для пользователя, и для согласующих. Потому рассмотрим здесь единый интерфейс для всех согласующих.
Далее рассмотрим варианты исполнения.
Из вариантов – ручное исполнение или автоматизированное.
При этом автоматическое исполнение в ряде случаев может быть достигнуто не только при помощи внедрения IdM, но и выполнено, скажем, при помощи скриптов.
Преимущество ручного исполнения – человек, который в некоторых случаях незаменим, т.к. может проанализировать ситуацию и, внеся коррективы, выдать пользователю нужные права. Однако это и делает процесс уязвимым: ведь человек может ошибиться или забыть задокументировать то, что было сделано.
Автоматическое исполнение спасает от ошибок, связанных с человеческим фактором, но имеет свои ограничения. В ряде случаев (особенно, если мы говорим о несистемной автоматизации ряда действий скриптами) администратору всё равно придётся или задавать какие-то параметры, или контролировать исполнение. IdM в данном случае может оперировать теми параметрами, которые были заданы при проектировании процессов в процессе внедрения системы, и атрибутами заявки (если мы используем IdM как заявочную систему по вопросам доступа).
Мы проделали определённую работу с каждым элементом процесса отдельно, теперь необходимо оценить, что у нас получается, если совместим выбранные шаги подобно тому, как собирают паззл.
Для начала посмотрим, каковы варианты для данного процесса:
Количество связей изрядное. Важно выбирать комбинации, при которых наименьшими будут затраты времени и стоимость, а наибольшим – удобство пользователей (включая согласующих и исполнителей). При этом стоит учитывать, что «стоимость» перехода от шага к шагу зависит от особенностей выбранных шагов.
Рассмотрим для примера три процесса.
При такой конфигурации пользователи, которые привыкли коммуницировать по почте, выяснят процедуру и формат правильной заявки по требуемым правам доступа. В результате они смогут выбрать, как именно им удобнее формировать заявку – на бумаге или посредством электронной почты. Согласовываться заявка будет через почту, а исполнение запроса произведёт администратор вручную.
Этот процесс имеет право на жизнь, если нет других, более современных средств. Однако: сколько времени займёт вся цепочка действий, и как предусмотреть эскалацию при отсутствии реакции согласующего?
Здесь мы видим, что сотрудник для составления корректного запроса звонит владельцу ресурса, после чего формирует заявку в СЭД'е или Service Desk’е. Там же заявка будет согласована. Исполнение будет зависеть от того, что именно запрошено – вручную администратором или скриптами.
В СЭД и Service Desk, как правило, можно настроить эскалацию в случае длительного непринятия решения согласующим, или в случае отсутствия согласующего по той или иной причине.
Процесс выглядит более удобным и быстрым, чем первый рассмотренный нами. Тем не менее, возникает вопрос: формализована ли заявка?
Если пользователь пишет «хочу доступ к системе как у Иванова», то исполнение может быть только вручную.
Если заявка формализована (т.е. есть некоторое ограниченное количество вариантов на выбор), мы можем говорить о возможностях автоматизации. При этом снова нужно смотреть, как будет реализована автоматизация – кем, с каким качеством и как будет поддерживаться.
В данном случае пользователь может узнать о том, какой доступ ему необходим, у руководителя или — просто посмотрев в форму запроса (в каталоге ролей IdM можно для удобства пользователей выводить бизнес-роли или роли с понятным описанием).
Запрос прав и ролей происходит в IdM’е, равно как и согласование заявок.
Предоставление прав будет осуществлено IdM’ом автоматически по завершении процедуры согласования для тех систем, что подключены для управления через IdM. Поскольку не все системы необходимо подключать для управления (можно подключить для контроля в режиме получения данных), исполнитель получит чёткое задание на исполнение. При этом, в случае ошибки администратора, система выявит расхождение между заявкой и предоставленным доступом и сообщит об этом заинтересованным лицам (например, офицеру ИБ и администратору системы).
По каждому из процессов можно предположить и стоимость поддержки.
При этом не стоит забывать о том, что, помимо выстраивания процесса предоставления прав доступа, который мы выбрали для простоты рассмотрения, для оптимальной работы нужны также процессы:
- пересмотра прав доступа при кадровом перемещении (повышение, линейное перемещение, переход из одной компании холдинга в другую),
- пересмотр прав доступа по расписанию (по мере востребованности в вашей компании — ежеквартально, ежегодно),
- отзыва прав при увольнении сотрудника и блокировки учётных записей,
- аудита и т.д.
Поэтому в процессе принятия решения необходимо снова «сделать шаг назад» для того, чтобы взглянуть на всю систему процессов управления доступом.
При таком подходе можно оценить использование каждого организационного и технического решения:
- как оно влияет на бизнес-процессы компании,
- удобно ли пользователям,
- не увеличится ли время простоя сотрудников из-за непредоставленного вовремя доступа,
- не будет ли сказываться простой на получении прибыли компании,
- не будет ли в результате такого набора процессов коллизий,
- сможем ли мы провести аудит прав доступа,
- достаточно ли у нас задокументирована информация, чтобы ею воспользоваться в спорных ситуациях или при расследовании инцидента,
- сможем ли мы осуществить пересмотр прав доступа сотрудника и т.д.
Оценив складывающуюся мозаику процессов управления доступом, можно более смело выбирать организационные меры и технические решения.
Предыдущие статьи цикла:
- Внедрение IdM. Часть 1: что такое IdM и какая функциональность к нему относится.
- Внедрение IdM. Часть 2. Как определить, что стоит задуматься о внедрении IdM?
- Внедрение IdM. Часть 3.1. Понятно, что IdM нужен – что дальше? Цели, задачи, заинтересованные стороны.
- Внедрение IdM. Часть 3.2. Как построить модель доступа?
Автор: Selesta
