Портал №1 по управлению цифровыми
и информационными технологиями

Как построить управление доступом «изнутри»?

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

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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Комментариев: 1

  • Андрей другой

    Здравствуйте!

    Я что-то не уверен, что построение процесса организации доступа «изнутри» принципально отличается от постороения "снаружи". Есть уже давно сложившаяся область — Identity Management и принципы её реализации не отличатся для случаев когда вы сами внутри компании за это беретесь или приглашаете консультантов. Но тут есть прнципиально важный пункт. Identity and Access Management — это про ролевое управление. Так что по-хорошему начинать надо именно с этого. Необходима модель бизнесс процессов компании из которой вы получите список ролей и список ИТ систем, которые исполнители этих ролей будут использовать для выполнения Activities в бизнесс процессе. По описанию Activities вы также получите информацию о необходимом типе доступа к ИТ системе/ресурсу(на пример отчету). Итого, не основе модели процессов вы получаете: список ролей, для каждой роли — список ИТ систем/ресуров с необходимыми типами доступа к ним. Процесс обеспечения доступа в этом случае сводится к назначению роли на конкретного сотрудника для выполнения конкретного бизнес процесса. Только в этом случае вы сможете доходчиво объяснить аудитору зачем этому сотруднику дали доступ. Также осознанные формы примет процесс согласования, появится вознможность осмысленного анализа совместимости ролей и т.д. Что касается ServiceDesk, то я бы пошел еще дальше — не отправлял бы запросы на выполнение в SericeDesk, а сразу бы автоматически выполнял их из BPM системы, сейчас почти все продукты это позволяют.


Добавить комментарий

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT