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

    В предыдущей части нашего цикла статей мы рассказали, как определить, нужен ли компании 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, и – что особенно важно! – расписать степень вовлечённости и роль каждого участника. Больше всего людей пугает неопределённость. Не стоит умышленно приуменьшать или преувеличивать значимость, роль или трудозатраты каждого из участников. Полезно предупредить, что именно и как изменится. Так складывается готовность всех сторон к участию в проекте.



    UPD. Читайте далее:


    Ростелеком-Solar 177,08
    Безопасность по имени Солнце
    Поделиться публикацией
    Комментарии 0

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