Главная » Софт » Внедрение IdM. Процедуры и технические средства — от базовых до IdM

Внедрение IdM. Процедуры и технические средства — от базовых до IdM

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

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

Что мы хотим? image
Пойдём от желаемого.

  • Систему, которая нам сама скажет о нарушениях и SoD-конфликтах?
  • Систему, которая сама построит ролевые модели?
  • Управлять доступом?
  • Всё контролировать?
  • Обеспечить физический и логический доступ пользователей с биометрической аутентификацией и т.д.?

Здесь можно придумать еще много всего, и все это даже может быть реализуемо. Но (!) с большой вероятностью это будет индивидуальная разработка, долгая и дорогая.

А что у нас есть?

  • Политики доступа,
  • процесс предоставления доступа (по заявке пользователя или без неё),
  • встроенные права и роли в каждой системе.

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

Чем больше различных условий и ветвлений неавтоматизированного процесса, тем чаще будут случаться ошибки. При проектировании процессов стоит помнить: чем проще и «прозрачнее» система, тем легче её контролировать.

Возьмём в качестве примера процесс предоставления доступа, при котором пользователю для выполнения некой задачи нужны новые права в системе.

Какие факторы нужно учитывать при создании такого бизнес-процесса?

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

Сначала определимся с тем, кто у нас в данном процессе участвует:

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

В процессе может быть гораздо больше участников, например: владелец ресурса, дополнительный контролёр от ИТ и т.д. А пока для разбора построения процесса нам достаточно указанных персонажей.

Сначала для нас процесс выглядит так: Теперь определимся с полем действий.

Сотрудник запрашивает права доступа, их согласует его руководитель, потом согласует офицер ИБ, после чего администратор системы выполняет запрос.

image

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

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

Значит, нужно выбрать самые быстрые и удобные для пользователя варианты. Все описанные опции, как правило, доступны, но это занимает некоторое время. На данном этапе важно просто сравнить имеющиеся опции выявления нужных прав доступа по выделенным ранее параметрам. (Мы же стремимся оказывать качественные услуги бизнесу.) Можно оставить актуальными 1-2 варианта, а можно – все.

image

Как пользователь может запросить права доступа? Следующий шаг – интерфейс запроса прав доступа.

Важно, чтобы способ подачи заявки был достаточно простым и понятным для пользователя. Среди вариантов, что приходят в голову: телефон, почта, СЭД (система электронного документооборота), Service Desk, интерфейс IdM или просто заявка на бумаге.

Нужно помнить, что на следующем шаге заявку будут согласовывать, и это тоже нужно сделать оперативно. Опять-таки надо учитывать временной фактор: что быстрее – написать письмо или нажать пару кнопок в Service Desk?

image

После выбора интерфейса запроса прав доступа, рассмотрим интерфейс согласования.
Варианты: на бумаге (мы же закладывали изначально такой вариант), по почте, через СЭД или Service Desk, интерфейс IdM.

Мы сейчас рассматриваем линейный процесс с 2 шагами согласования. Здесь стоит учесть сложность маршрута согласования. Соответственно, все связанные с маршрутами согласования параметры также стоит учитывать. Но в жизни всё обычно сложнее, и различается в зависимости от того, к каким системам какой доступ запрашивается. Например: руководитель согласует заявку на бумаге, поставив свою подпись, а офицер ИБ работает со сканом заявки в СЭД'е. Могут совмещаться несколько способов согласования, и такие случаи требуют повышенного внимания и поддержки. Потому рассмотрим здесь единый интерфейс для всех согласующих. Это добавляет сложности и неудобства и для пользователя, и для согласующих.

image

Далее рассмотрим варианты исполнения.
Из вариантов – ручное исполнение или автоматизированное.

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

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

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

image

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

Для начала посмотрим, каковы варианты для данного процесса:

image

Важно выбирать комбинации, при которых наименьшими будут затраты времени и стоимость, а наибольшим – удобство пользователей (включая согласующих и исполнителей). Количество связей изрядное. При этом стоит учитывать, что «стоимость» перехода от шага к шагу зависит от особенностей выбранных шагов.

Рассмотрим для примера три процесса.

Процесс 1.

Допустим, мы построим процесс следующим образом:

image

В результате они смогут выбрать, как именно им удобнее формировать заявку – на бумаге или посредством электронной почты. При такой конфигурации пользователи, которые привыкли коммуницировать по почте, выяснят процедуру и формат правильной заявки по требуемым правам доступа. Согласовываться заявка будет через почту, а исполнение запроса произведёт администратор вручную.

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

Процесс 2.

Выберем другую конфигурацию:

image

Там же заявка будет согласована. Здесь мы видим, что сотрудник для составления корректного запроса звонит владельцу ресурса, после чего формирует заявку в СЭД'е или Service Desk’е. Исполнение будет зависеть от того, что именно запрошено – вручную администратором или скриптами.

В СЭД и Service Desk, как правило, можно настроить эскалацию в случае длительного непринятия решения согласующим, или в случае отсутствия согласующего по той или иной причине.

Тем не менее, возникает вопрос: формализована ли заявка? Процесс выглядит более удобным и быстрым, чем первый рассмотренный нами.

Если пользователь пишет «хочу доступ к системе как у Иванова», то исполнение может быть только вручную.

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

Процесс 3.

Рассмотрим вариант с IdM:

image

В данном случае пользователь может узнать о том, какой доступ ему необходим, у руководителя или — просто посмотрев в форму запроса (в каталоге ролей IdM можно для удобства пользователей выводить бизнес-роли или роли с понятным описанием).

Запрос прав и ролей происходит в IdM’е, равно как и согласование заявок.

Поскольку не все системы необходимо подключать для управления (можно подключить для контроля в режиме получения данных), исполнитель получит чёткое задание на исполнение. Предоставление прав будет осуществлено IdM’ом автоматически по завершении процедуры согласования для тех систем, что подключены для управления через IdM. При этом, в случае ошибки администратора, система выявит расхождение между заявкой и предоставленным доступом и сообщит об этом заинтересованным лицам (например, офицеру ИБ и администратору системы).

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

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

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

При таком подходе можно оценить использование каждого организационного и технического решения:

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

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

Предыдущие статьи цикла:


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Философия Джефа Безоса: «День 1»

13 сентября Джеф Безос стартовал филантропический проект «День 1». Копнем, что же стоит за этим названием. Какова философия «Дня 1» Джеффа Безоса? Изначально этот вопрос появился на ‘Quora’: месте для получения и обмена знаниями, позволяющим людям учиться у других и ...

Very Special Event: как мы смотрели презентацию Apple и что об этом думаем

Тем не менее, мы в Авито не могли пропустить это событие. От презентации Apple, которая должна была пройти 12 сентября, ничего особенного не ждали: три новых модели iPhone и новую версию Apple Watch — об этих новинках знали заранее. Посмотреть ...