Внедрение IdM. Часть 3.1. Понятно, что IdM нужен – что дальше? Цели, задачи, заинтересованные стороны

в 7:00, , рубрики: IdM, IT-стандарты, Блог компании Solar Security, Внедрение, информационная безопасность, права доступа, управление проектами

В предыдущей части нашего цикла статей мы рассказали, как определить, нужен ли компании IdM (т.е. управление доступом) и стоит ли внедрять IdM-решение. Определили, какие признаки указывают на то, что стόит над этим вопросом, как минимум, задуматься. Что дальше?

Есть несколько вещей, которые важно определить, чтобы приступить к работе над темой IdM:

  1. Цели и задачи. Заинтересованные стороны.
  2. Какие подходы и практики использовать при внедрении системы управления доступом сотрудников, какие процедуры и процессы вводить, как встраивать нужные операции в бизнес-деятельность компании?
  3. Какие технические решения использовать (начиная от доменных политик и заканчивая IdM-решениями) и как определить, какой нужен функционал?
  4. К кому идти за техническими решениями?
  5. Как сформировать и обосновать бюджет? (Это самая интересная и животрепещущая тема)
  6. Презентация руководству.
  7. Что нужно учитывать при запуске проекта?

Итак, пойдем по пунктам.

image

1. Цели и задачи. Заинтересованные стороны.

Допустим, стало очевидно, что с темой IdM «нужно что-то делать». Что именно? Какие функции реализовать? Какие политики вводить и контролировать? И чего вообще мы ожидаем от работы с этой темой: приведения в порядок процессов, налаживания контроля и проведения аудита? А может, нужна автоматизация?

Первый ответ, который приходит в голову – IdM должен быть таким, какой востребован именно в вашей компании.

Популярные стандарты, своды знаний и общепринятые практики, будь то ITIL, Cobit, ISO/IEC 2700х и прочие, всеми силами стараются донести до всех простую истину: внедрять нужно только то, что подходит каждой конкретной компании, согласуясь с её миссией, стратегией, культурой и организационной структурой. Нужно учитывать влияние каждого внедряемого сервиса и системы на конкретный бизнес, как то:

  • Удобство пользователя (в данном случае внутреннего) и непрерывность бизнеса. (Во многих случаях это неразрывно связанные понятия: если операционист в банке с трудом может оформить платёжку из-за ужасного интерфейса и непродуманных функций, то сколько клиентов из очереди плюнут и уйдут в другой банк?).
  • Финансовая составляющая (сервис не должен быть в тягость).
  • Надёжность системы (SLA с возможностью простоя системы не более 1 часа в месяц для некоторых систем очень востребован).
  • Уровень информационной безопасности должен быть достаточным. Т.е. не нужно пытаться строить SOC в компании, торгующей пирожками, «просто чтобы попробовать». При этом не следует пренебрегать самыми простыми решениями и политиками в компании, где водится значимая и дорогая информация, например, в банке. В данном случае будем рассматривать ИБ в парадигме IdM.

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

Какой из этого вывод? Нужно найти тот участок, внося изменения на котором, мы улучшим жизнь пользователей и будем приносить пользу бизнесу. Придётся провести полноценное исследование, чтобы понять, что нужно делать. Возникает закономерное: «С чего начать»?

Начать стоит с трёх простых вопросов:

  1. Чего мы хотим?
  2. Почему мы этого хотим?
  3. Зачем нам это нужно?

Если ответ возникает сразу, – хорошо. Ответы на вопросы полезно зафиксировать, только не надо думать, что на этом этап определения целей и задач завершён. В ответах вы изложили только свою точку зрения и ровно то, что пришло в голову в момент прочтения вопросов. Очень важно узнать мнение и потребности других участников процесса, а также – более чётко осознать свои мотивы заниматься этим проектом. И зафиксировать каким-то образом эти сведения.

Отдельно акцентируем фиксацию результатов исследования:

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

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

Приступим к процессу сбора информации, на основе которой определим цели и задачи разработки и внедрения IdM’а, а также поймём требования к процессам, мерам и техническим решениям.

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

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

Вряд ли стоит ожидать, что сообщать и жаловаться пользователи станут в привычных специалисту терминах. Готовьтесь услышать что-то про «качество» и «скорость работы» (которое чаще всего непонятно как и в чём измеряется), про «сокращение затрат», «удобство использования» и «простоту», и даже – «чтоб красивенько было и не раздражало». Или просто: «Идите работайте!» Разбираться со всем услышанным придётся вам, но, установив контакт один раз, будет проще понимать пожелания руководства в дальнейшем. Ну, и: «Кто не пытается, тот…» (сами знаете – что).

Второй шаг – коммуникация с пользователями, ИТ/ИБ-службами и вовлечёнными в процесс бизнес-службами (например, с отделом кадров). Нужно понять, как выглядит процесс глазами пользователя, «пройти» его вместе с ними. Чтобы построить удобный сервис и обеспечить безопасность, нужно знать своих пользователей:

  • Их привычки (например, у сотрудников бухгалтерии может быть привычка звонить «админу Васе», а не оформлять заявку в непонятном ServiceDesk).
  • Их потребности (например, доступ нужен срочно, сроки горят, пришла проверка, а согласовывать – некогда и некому).
  • Их требования (например, всё должно быть понятно и прозрачно, выполняться в срок).
  • Их трудности (если нужно собрать 10 подписей на бумаге, чтобы оформить доступ к сетевой папке, где хранятся фоточки с корпоратива, то процесс явно работает как-то не так…) и т.д.

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

Похожий подход полезно применить и в работе с коллегами – ИТ и ИБ (на какой бы стороне вы ни были). Желательно обратиться за советом и выслушать мнение ИТ/ИБ-специалистов, причем и руководителей, и исполнителей. Руководители знают общую концепцию ИТ/ИБ-сервисов: кто за что отвечает, какие есть планы по введению в эксплуатацию новых систем, какие есть «подводные камни», требования регуляторов и ещё многое, многое другое. При этом никто лучше администратора не расскажет и не покажет вам весь процесс предоставления и отзыва доступа, создания учётных записей, работы с пользователями, забывшими пароль, а также – с теми, кто звонит в техподдержку со словами: «Ой, у меня что-то нажалось, и всё исчезло…». Они же вам и расскажут, как тормозят формы в ServiceDesk’е или СЭД’е, что замедляет их работу и ещё много всего интересного.

Третий шаг – это работа с заинтересованными бизнес-подразделениями.

Чаще всего заинтересованы в наведении порядка с управлением доступом следующие лица:

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

С руководителем каждого подразделения (начиная с верхушки иерархии, спускаясь вниз по её ступеням) полезно пообщаться. Поверьте, узнаете много нового и неожиданного. Например, такого: некоторые сотрудники могут на неделю-другую оказаться без доступа, т.к. непосредственный руководитель в отпуске (на больничном), не может подписать форму, и поэтому лишившиеся доступа сотрудники работают под незаблокированной «учёткой» уже уволенного специалиста… (Это – реальный сценарий).

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

Четвёртый шаг приближает нас к финишной прямой – анализ собранной информации.

Если в это момент вы всё ещё полны решимости и готовы к свершениям, тогда продолжим.

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

Постарайтесь отразить цели, задачи, вовлечённость в процесс и выгоды каждой из сторон от работы над темой IdM.

Какими могут быть цели и задачи? Приведу здесь некоторые примеры, их стоит воспринимать не как догму, а как направление для размышления:

Цель: внедрение контроля доступа всех сотрудников компании.

Некоторые задачи:

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

Цель: разработка и введение новой процедуры предоставления прав доступа сотрудникам компаний-партнёров к системам А и Б.

Некоторые задачи:

  • проектирование и согласования новой процедуры,
  • обучение вовлечённых сторон и пользователей,
  • введение новой процедуры в пользование.

Цель: внесение изменений в доменные политики для обеспечения соответствия требованиям корпоративного стандарта безопасности.

Некоторые задачи:

  • выявление и устранение несоответствий корпоративному стандарту,
  • разработка и внедрение механизма контроля соответствия доменных политик корпоративному стандарту.

Цель: автоматизация процедуры создания учётных записей в информационных системах компании.

Цель: введение процедуры согласования предоставляемых прав доступа.

Цель: разработка и введение в эксплуатацию IdM-решения на базе существующих процедур управления доступом.

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

Если есть возможность, стоит презентовать результаты своих изысканий группе, которая потенциально будет заниматься IdM’ом.

Почему – «потенциально»? Потому что решение о том, что этой темой нужно заниматься, на данном этапе ещё не принято высшим руководством компании. Если выйти с идеей внедрения сразу к высшему руководству, можно столкнуться с тем, что кто-то из ключевых руководителей или сотрудников будет утверждать, что «и так всё нормально», т.к. участвовать в проекте внедрения IdM’а ей/ему не хочется («Ну что вы… Это ж что-то делать придётся, привыкать к изменениям… Вот если бы всё само магическим образом преобразилось!»). В результате такие персонажи в лучшем случае не будут делать ничего, в худшем – явно и неявно саботировать ваши благие начинания.

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

Полезно и показать выгоды от внедрения IdM, и – что особенно важно! – расписать степень вовлечённости и роль каждого участника. Больше всего людей пугает неопределённость. Не стоит умышленно приуменьшать или преувеличивать значимость, роль или трудозатраты каждого из участников. Полезно предупредить, что именно и как изменится. Так складывается готовность всех сторон к участию в проекте.

Автор: Мария Ерохина

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js