В предыдущей части нашего цикла статей мы рассказали, как определить, нужен ли компании IdM (т.е. управление доступом) и стоит ли внедрять IdM-решение. Определили, какие признаки указывают на то, что стόит над этим вопросом, как минимум, задуматься. Что дальше?
Есть несколько вещей, которые важно определить, чтобы приступить к работе над темой IdM:
Итак, пойдем по пунктам.
Допустим, стало очевидно, что с темой IdM «нужно что-то делать». Что именно? Какие функции реализовать? Какие политики вводить и контролировать? И чего вообще мы ожидаем от работы с этой темой: приведения в порядок процессов, налаживания контроля и проведения аудита? А может, нужна автоматизация?
Первый ответ, который приходит в голову – IdM должен быть таким, какой востребован именно в вашей компании.
Популярные стандарты, своды знаний и общепринятые практики, будь то ITIL, Cobit, ISO/IEC 2700х и прочие, всеми силами стараются донести до всех простую истину: внедрять нужно только то, что подходит каждой конкретной компании, согласуясь с её миссией, стратегией, культурой и организационной структурой. Нужно учитывать влияние каждого внедряемого сервиса и системы на конкретный бизнес, как то:
Напомню: под IdM’ом мы понимаем совокупность мер, процессов и технических средств, а значит – далеко не каждой компании нужно сложное и дорогостоящее техническое IdM-решение. Кому-то достаточно правильно построить процессы, причём – не на бумаге, а реально работающие. Процессы ради процессов, безопасность ради безопасности и ИТ ради ИТ не нужны, они должны лишь выполнять отведённую им функцию, а значит – помогать в достижении бизнес-целей.
Какой из этого вывод? Нужно найти тот участок, внося изменения на котором, мы улучшим жизнь пользователей и будем приносить пользу бизнесу. Придётся провести полноценное исследование, чтобы понять, что нужно делать. Возникает закономерное: «С чего начать»?
Начать стоит с трёх простых вопросов:
Если ответ возникает сразу, – хорошо. Ответы на вопросы полезно зафиксировать, только не надо думать, что на этом этап определения целей и задач завершён. В ответах вы изложили только свою точку зрения и ровно то, что пришло в голову в момент прочтения вопросов. Очень важно узнать мнение и потребности других участников процесса, а также – более чётко осознать свои мотивы заниматься этим проектом. И зафиксировать каким-то образом эти сведения.
Отдельно акцентируем фиксацию результатов исследования:
Если просто пообщаться с большим количеством людей, каждый из которых сообщит и запросит что-то своё, иногда – неожиданное, впоследствии вряд ли припомнишь, кто и что именно сказал, предложил или попросил. Не надейтесь только на собственную память. Записывайте, пусть не формально на бланках организации, а просто – в блокнотик. Оно того стоит.
Приступим к процессу сбора информации, на основе которой определим цели и задачи разработки и внедрения IdM’а, а также поймём требования к процессам, мерам и техническим решениям.
Первое, что стоит сделать – прочитать стратегию развития бизнеса (если таковая имеется). Иногда это может быть лишь формальный документ, иногда он вовсе отсутствует. Если такого нет, нужно идти к руководителям компании и обсуждать, каковы наиболее актуальные потребности бизнеса, каким видится развитие компании в ближайшем будущем, есть ли какие-то отдельные ожидания от работы служб ИТ и ИБ.
Подобный сбор обратной связи желательно осуществлять на регулярной основе. С одной стороны, это обеспечивает контакт с руководством компании, и вас не шокируют их «вдруг возникшие» пожелания или требования. С другой стороны, полученная информация даёт возможность видеть меру удовлетворённости работой подразделения и построить действительно отлаженную и гармоничную систему, работающую на благо бизнеса.
Вряд ли стоит ожидать, что сообщать и жаловаться пользователи станут в привычных специалисту терминах. Готовьтесь услышать что-то про «качество» и «скорость работы» (которое чаще всего непонятно как и в чём измеряется), про «сокращение затрат», «удобство использования» и «простоту», и даже – «чтоб красивенько было и не раздражало». Или просто: «Идите работайте!» Разбираться со всем услышанным придётся вам, но, установив контакт один раз, будет проще понимать пожелания руководства в дальнейшем. Ну, и: «Кто не пытается, тот…» (сами знаете – что).
Второй шаг – коммуникация с пользователями, ИТ/ИБ-службами и вовлечёнными в процесс бизнес-службами (например, с отделом кадров). Нужно понять, как выглядит процесс глазами пользователя, «пройти» его вместе с ними. Чтобы построить удобный сервис и обеспечить безопасность, нужно знать своих пользователей:
При этом каждый пользователь важен. Стоит выслушивать горести и трудности и рядовых пользователей, и менеджеров среднего звена, и руководства.
Похожий подход полезно применить и в работе с коллегами – ИТ и ИБ (на какой бы стороне вы ни были). Желательно обратиться за советом и выслушать мнение ИТ/ИБ-специалистов, причем и руководителей, и исполнителей. Руководители знают общую концепцию ИТ/ИБ-сервисов: кто за что отвечает, какие есть планы по введению в эксплуатацию новых систем, какие есть «подводные камни», требования регуляторов и ещё многое, многое другое. При этом никто лучше администратора не расскажет и не покажет вам весь процесс предоставления и отзыва доступа, создания учётных записей, работы с пользователями, забывшими пароль, а также – с теми, кто звонит в техподдержку со словами: «Ой, у меня что-то нажалось, и всё исчезло…». Они же вам и расскажут, как тормозят формы в ServiceDesk’е или СЭД’е, что замедляет их работу и ещё много всего интересного.
Третий шаг – это работа с заинтересованными бизнес-подразделениями.
Чаще всего заинтересованы в наведении порядка с управлением доступом следующие лица:
С руководителем каждого подразделения (начиная с верхушки иерархии, спускаясь вниз по её ступеням) полезно пообщаться. Поверьте, узнаете много нового и неожиданного. Например, такого: некоторые сотрудники могут на неделю-другую оказаться без доступа, т.к. непосредственный руководитель в отпуске (на больничном), не может подписать форму, и поэтому лишившиеся доступа сотрудники работают под незаблокированной «учёткой» уже уволенного специалиста… (Это – реальный сценарий).
Кроме того, важно помнить о подразделениях, которые привлекают к работе в своих системах сторонних специалистов (чаще всего это ИТ, но и бизнес-подразделения также могут функционировать с подобными сценариями): сотрудников компаний-партнёров, сотрудников сторонних организаций-подрядчиков (аутсорс, интеграторы, разработчики ПО, техподдержка и т.п.). С ними также нужно выстроить диалог, понять, как именно они ведут работу, к чему, кому и как предоставляют доступ.
Четвёртый шаг приближает нас к финишной прямой – анализ собранной информации.
Если в это момент вы всё ещё полны решимости и готовы к свершениям, тогда продолжим.
Собранную и зафиксированную информацию (Повторю: обязательно всё записывайте и документируйте, это существенно облегчит вам жизнь!) нужно освежить в памяти, проанализировать и сформулировать основные выявленные проблемы и пожелания.
Постарайтесь отразить цели, задачи, вовлечённость в процесс и выгоды каждой из сторон от работы над темой IdM.
Какими могут быть цели и задачи? Приведу здесь некоторые примеры, их стоит воспринимать не как догму, а как направление для размышления:
Цель: внедрение контроля доступа всех сотрудников компании.
Некоторые задачи:
Цель: разработка и введение новой процедуры предоставления прав доступа сотрудникам компаний-партнёров к системам А и Б.
Некоторые задачи:
Цель: внесение изменений в доменные политики для обеспечения соответствия требованиям корпоративного стандарта безопасности.
Некоторые задачи:
Цель: автоматизация процедуры создания учётных записей в информационных системах компании.
Цель: введение процедуры согласования предоставляемых прав доступа.
Цель: разработка и введение в эксплуатацию IdM-решения на базе существующих процедур управления доступом.
При работе с управлением доступом цель не обязательно должна быть глобальной. Лучше идти к желаемому состоянию постепенно: если цели, которые определены, кажутся недостижимыми, значит недостаточно детально продуман план, рассчитаны время и ресурсы на проект. Ценно другое – чтобы цель оправдывала средства, т.е. была «живой», востребованной в вашей компании.
Если есть возможность, стоит презентовать результаты своих изысканий группе, которая потенциально будет заниматься IdM’ом.
Почему – «потенциально»? Потому что решение о том, что этой темой нужно заниматься, на данном этапе ещё не принято высшим руководством компании. Если выйти с идеей внедрения сразу к высшему руководству, можно столкнуться с тем, что кто-то из ключевых руководителей или сотрудников будет утверждать, что «и так всё нормально», т.к. участвовать в проекте внедрения IdM’а ей/ему не хочется («Ну что вы… Это ж что-то делать придётся, привыкать к изменениям… Вот если бы всё само магическим образом преобразилось!»). В результате такие персонажи в лучшем случае не будут делать ничего, в худшем – явно и неявно саботировать ваши благие начинания.
Каков выход из данной ситуации? Заручиться поддержкой. Важно понять, кто заинтересован в проекте, и обсудить с ними потенциальную пользу от внедрения, а также варианты и условия их участия. Но просто разговор из серии «А давай IdM внедрим!» не поможет. Перед тем, как идти к каждому потенциальному участнику проекта и союзнику, нужно подготовить аргументы, которые помогут донести, как именно внедрение IdM (т.е. – процессов и процедур управления доступом и сопровождающих их технических решений) облегчит жизнь каждого, с кем будете общаться.
Полезно и показать выгоды от внедрения IdM, и – что особенно важно! – расписать степень вовлечённости и роль каждого участника. Больше всего людей пугает неопределённость. Не стоит умышленно приуменьшать или преувеличивать значимость, роль или трудозатраты каждого из участников. Полезно предупредить, что именно и как изменится. Так складывается готовность всех сторон к участию в проекте.
Автор: Мария Ерохина, CISM
Есть несколько вещей, которые важно определить, чтобы приступить к работе над темой IdM:
- Цели и задачи. Заинтересованные стороны.
- Какие подходы и практики использовать при внедрении системы управления доступом сотрудников, какие процедуры и процессы вводить, как встраивать нужные операции в бизнес-деятельность компании?
- Какие технические решения использовать (начиная от доменных политик и заканчивая IdM-решениями) и как определить, какой нужен функционал?
- К кому идти за техническими решениями?
- Как сформировать и обосновать бюджет? (Это самая интересная и животрепещущая тема)
- Презентация руководству.
- Что нужно учитывать при запуске проекта?
Итак, пойдем по пунктам.
1. Цели и задачи. Заинтересованные стороны.
Допустим, стало очевидно, что с темой IdM «нужно что-то делать». Что именно? Какие функции реализовать? Какие политики вводить и контролировать? И чего вообще мы ожидаем от работы с этой темой: приведения в порядок процессов, налаживания контроля и проведения аудита? А может, нужна автоматизация?
Первый ответ, который приходит в голову – IdM должен быть таким, какой востребован именно в вашей компании.
Популярные стандарты, своды знаний и общепринятые практики, будь то ITIL, Cobit, ISO/IEC 2700х и прочие, всеми силами стараются донести до всех простую истину: внедрять нужно только то, что подходит каждой конкретной компании, согласуясь с её миссией, стратегией, культурой и организационной структурой. Нужно учитывать влияние каждого внедряемого сервиса и системы на конкретный бизнес, как то:
- Удобство пользователя (в данном случае внутреннего) и непрерывность бизнеса. (Во многих случаях это неразрывно связанные понятия: если операционист в банке с трудом может оформить платёжку из-за ужасного интерфейса и непродуманных функций, то сколько клиентов из очереди плюнут и уйдут в другой банк?).
- Финансовая составляющая (сервис не должен быть в тягость).
- Надёжность системы (SLA с возможностью простоя системы не более 1 часа в месяц для некоторых систем очень востребован).
- Уровень информационной безопасности должен быть достаточным. Т.е. не нужно пытаться строить SOC в компании, торгующей пирожками, «просто чтобы попробовать». При этом не следует пренебрегать самыми простыми решениями и политиками в компании, где водится значимая и дорогая информация, например, в банке. В данном случае будем рассматривать ИБ в парадигме IdM.
Напомню: под IdM’ом мы понимаем совокупность мер, процессов и технических средств, а значит – далеко не каждой компании нужно сложное и дорогостоящее техническое IdM-решение. Кому-то достаточно правильно построить процессы, причём – не на бумаге, а реально работающие. Процессы ради процессов, безопасность ради безопасности и ИТ ради ИТ не нужны, они должны лишь выполнять отведённую им функцию, а значит – помогать в достижении бизнес-целей.
Какой из этого вывод? Нужно найти тот участок, внося изменения на котором, мы улучшим жизнь пользователей и будем приносить пользу бизнесу. Придётся провести полноценное исследование, чтобы понять, что нужно делать. Возникает закономерное: «С чего начать»?
Начать стоит с трёх простых вопросов:
- Чего мы хотим?
- Почему мы этого хотим?
- Зачем нам это нужно?
Если ответ возникает сразу, – хорошо. Ответы на вопросы полезно зафиксировать, только не надо думать, что на этом этап определения целей и задач завершён. В ответах вы изложили только свою точку зрения и ровно то, что пришло в голову в момент прочтения вопросов. Очень важно узнать мнение и потребности других участников процесса, а также – более чётко осознать свои мотивы заниматься этим проектом. И зафиксировать каким-то образом эти сведения.
Отдельно акцентируем фиксацию результатов исследования:
- Заранее продумайте, как будете проводить опрос и фиксировать ответы.
- Подготовьте анкеты и шаблоны для заполнения.
- Создайте удобную форму протокола или таблицу учёта результатов.
Если просто пообщаться с большим количеством людей, каждый из которых сообщит и запросит что-то своё, иногда – неожиданное, впоследствии вряд ли припомнишь, кто и что именно сказал, предложил или попросил. Не надейтесь только на собственную память. Записывайте, пусть не формально на бланках организации, а просто – в блокнотик. Оно того стоит.
Приступим к процессу сбора информации, на основе которой определим цели и задачи разработки и внедрения IdM’а, а также поймём требования к процессам, мерам и техническим решениям.
Первое, что стоит сделать – прочитать стратегию развития бизнеса (если таковая имеется). Иногда это может быть лишь формальный документ, иногда он вовсе отсутствует. Если такого нет, нужно идти к руководителям компании и обсуждать, каковы наиболее актуальные потребности бизнеса, каким видится развитие компании в ближайшем будущем, есть ли какие-то отдельные ожидания от работы служб ИТ и ИБ.
Подобный сбор обратной связи желательно осуществлять на регулярной основе. С одной стороны, это обеспечивает контакт с руководством компании, и вас не шокируют их «вдруг возникшие» пожелания или требования. С другой стороны, полученная информация даёт возможность видеть меру удовлетворённости работой подразделения и построить действительно отлаженную и гармоничную систему, работающую на благо бизнеса.
Вряд ли стоит ожидать, что сообщать и жаловаться пользователи станут в привычных специалисту терминах. Готовьтесь услышать что-то про «качество» и «скорость работы» (которое чаще всего непонятно как и в чём измеряется), про «сокращение затрат», «удобство использования» и «простоту», и даже – «чтоб красивенько было и не раздражало». Или просто: «Идите работайте!» Разбираться со всем услышанным придётся вам, но, установив контакт один раз, будет проще понимать пожелания руководства в дальнейшем. Ну, и: «Кто не пытается, тот…» (сами знаете – что).
Второй шаг – коммуникация с пользователями, ИТ/ИБ-службами и вовлечёнными в процесс бизнес-службами (например, с отделом кадров). Нужно понять, как выглядит процесс глазами пользователя, «пройти» его вместе с ними. Чтобы построить удобный сервис и обеспечить безопасность, нужно знать своих пользователей:
- Их привычки (например, у сотрудников бухгалтерии может быть привычка звонить «админу Васе», а не оформлять заявку в непонятном ServiceDesk).
- Их потребности (например, доступ нужен срочно, сроки горят, пришла проверка, а согласовывать – некогда и некому).
- Их требования (например, всё должно быть понятно и прозрачно, выполняться в срок).
- Их трудности (если нужно собрать 10 подписей на бумаге, чтобы оформить доступ к сетевой папке, где хранятся фоточки с корпоратива, то процесс явно работает как-то не так…) и т.д.
При этом каждый пользователь важен. Стоит выслушивать горести и трудности и рядовых пользователей, и менеджеров среднего звена, и руководства.
Похожий подход полезно применить и в работе с коллегами – ИТ и ИБ (на какой бы стороне вы ни были). Желательно обратиться за советом и выслушать мнение ИТ/ИБ-специалистов, причем и руководителей, и исполнителей. Руководители знают общую концепцию ИТ/ИБ-сервисов: кто за что отвечает, какие есть планы по введению в эксплуатацию новых систем, какие есть «подводные камни», требования регуляторов и ещё многое, многое другое. При этом никто лучше администратора не расскажет и не покажет вам весь процесс предоставления и отзыва доступа, создания учётных записей, работы с пользователями, забывшими пароль, а также – с теми, кто звонит в техподдержку со словами: «Ой, у меня что-то нажалось, и всё исчезло…». Они же вам и расскажут, как тормозят формы в ServiceDesk’е или СЭД’е, что замедляет их работу и ещё много всего интересного.
Третий шаг – это работа с заинтересованными бизнес-подразделениями.
Чаще всего заинтересованы в наведении порядка с управлением доступом следующие лица:
- Отдел кадров. Тут важно: для новых сотрудников быстро организовать рабочее место, уволенным заблокировать доступ, правильно реагировать на отпуск специалистов и т.д… (Про процессы поговорим в следующих статьях.)
- Подразделения, где много сотрудников, которые должны быстро приступить к работе (например: операционисты, колл-центр, кассиры и т.д.).
- Работающие с чувствительной информацией, доступ к которой следует выдавать по строгим правилам и постоянно контролировать.
С руководителем каждого подразделения (начиная с верхушки иерархии, спускаясь вниз по её ступеням) полезно пообщаться. Поверьте, узнаете много нового и неожиданного. Например, такого: некоторые сотрудники могут на неделю-другую оказаться без доступа, т.к. непосредственный руководитель в отпуске (на больничном), не может подписать форму, и поэтому лишившиеся доступа сотрудники работают под незаблокированной «учёткой» уже уволенного специалиста… (Это – реальный сценарий).
Кроме того, важно помнить о подразделениях, которые привлекают к работе в своих системах сторонних специалистов (чаще всего это ИТ, но и бизнес-подразделения также могут функционировать с подобными сценариями): сотрудников компаний-партнёров, сотрудников сторонних организаций-подрядчиков (аутсорс, интеграторы, разработчики ПО, техподдержка и т.п.). С ними также нужно выстроить диалог, понять, как именно они ведут работу, к чему, кому и как предоставляют доступ.
Четвёртый шаг приближает нас к финишной прямой – анализ собранной информации.
Если в это момент вы всё ещё полны решимости и готовы к свершениям, тогда продолжим.
Собранную и зафиксированную информацию (Повторю: обязательно всё записывайте и документируйте, это существенно облегчит вам жизнь!) нужно освежить в памяти, проанализировать и сформулировать основные выявленные проблемы и пожелания.
Постарайтесь отразить цели, задачи, вовлечённость в процесс и выгоды каждой из сторон от работы над темой IdM.
Какими могут быть цели и задачи? Приведу здесь некоторые примеры, их стоит воспринимать не как догму, а как направление для размышления:
Цель: внедрение контроля доступа всех сотрудников компании.
Некоторые задачи:
- получение актуальной информации по всем учётным записям сотрудников и правам доступа в каждой из информационных систем,
- получение отчётов, содержащих информацию для сравнения прав доступа сотрудников в информационных системах.
Цель: разработка и введение новой процедуры предоставления прав доступа сотрудникам компаний-партнёров к системам А и Б.
Некоторые задачи:
- проектирование и согласования новой процедуры,
- обучение вовлечённых сторон и пользователей,
- введение новой процедуры в пользование.
Цель: внесение изменений в доменные политики для обеспечения соответствия требованиям корпоративного стандарта безопасности.
Некоторые задачи:
- выявление и устранение несоответствий корпоративному стандарту,
- разработка и внедрение механизма контроля соответствия доменных политик корпоративному стандарту.
Цель: автоматизация процедуры создания учётных записей в информационных системах компании.
Цель: введение процедуры согласования предоставляемых прав доступа.
Цель: разработка и введение в эксплуатацию IdM-решения на базе существующих процедур управления доступом.
При работе с управлением доступом цель не обязательно должна быть глобальной. Лучше идти к желаемому состоянию постепенно: если цели, которые определены, кажутся недостижимыми, значит недостаточно детально продуман план, рассчитаны время и ресурсы на проект. Ценно другое – чтобы цель оправдывала средства, т.е. была «живой», востребованной в вашей компании.
Если есть возможность, стоит презентовать результаты своих изысканий группе, которая потенциально будет заниматься IdM’ом.
Почему – «потенциально»? Потому что решение о том, что этой темой нужно заниматься, на данном этапе ещё не принято высшим руководством компании. Если выйти с идеей внедрения сразу к высшему руководству, можно столкнуться с тем, что кто-то из ключевых руководителей или сотрудников будет утверждать, что «и так всё нормально», т.к. участвовать в проекте внедрения IdM’а ей/ему не хочется («Ну что вы… Это ж что-то делать придётся, привыкать к изменениям… Вот если бы всё само магическим образом преобразилось!»). В результате такие персонажи в лучшем случае не будут делать ничего, в худшем – явно и неявно саботировать ваши благие начинания.
Каков выход из данной ситуации? Заручиться поддержкой. Важно понять, кто заинтересован в проекте, и обсудить с ними потенциальную пользу от внедрения, а также варианты и условия их участия. Но просто разговор из серии «А давай IdM внедрим!» не поможет. Перед тем, как идти к каждому потенциальному участнику проекта и союзнику, нужно подготовить аргументы, которые помогут донести, как именно внедрение IdM (т.е. – процессов и процедур управления доступом и сопровождающих их технических решений) облегчит жизнь каждого, с кем будете общаться.
Полезно и показать выгоды от внедрения IdM, и – что особенно важно! – расписать степень вовлечённости и роль каждого участника. Больше всего людей пугает неопределённость. Не стоит умышленно приуменьшать или преувеличивать значимость, роль или трудозатраты каждого из участников. Полезно предупредить, что именно и как изменится. Так складывается готовность всех сторон к участию в проекте.
UPD. Читайте далее:
- Часть 3.2. Как построить модель доступа?
- Часть 3.3. Процедуры и технические средства — от базовых до IdM.
- Часть 3.4. К кому идти за решением проблем?
Автор: Мария Ерохина, CISM
