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