В первой части нашего цикла статей про IdM мы обсудили, что такое IdM. Сегодня будет минимум теории: я расскажу о том, как понять, нужно ли вообще вашей компании IdM-решение — с точки зрения задач бизнеса, ИТ, ИБ, аудита и т.д. Под катом — несколько чек-листов, составленных на основании моего опыта внедрений IdM. Они помогут вам определиться, пора ли выбирать IdM-решение, или ваша компания пока может обойтись существующими процессами.
Стоит сразу обозначить, чтобы избежать путаницы: термин «IdM» отсылает нас именно ко всему комплексу мер управления доступом, а «IdM-решение» – к классу систем и технических средств.
В каком-то виде у вас точно существует набор процессов управления доступом. И часто он требует массы ручной работы:
Всё это, как правило, сопровождается необходимостью не просто заглядывать в разные консоли, но также – идти к администраторам каждой из систем и просить предоставить нужное. Иногда имеются осложнения в виде непростых отношений между подразделениями и претензий типа: «Будет тут всякий ставить задачи моему сотруднику!» и «У нас нет времени делать за вас вашу работу».
Не всегда всё так мрачно, но, если вы узнали хоть одну из указанных ситуаций – вам нужен IdM. А точнее – вам нужно заняться наведением порядка в области управления учётными данными и правами пользователей. Для неопределившихся приведу чек-лист ситуаций-маркеров, которые свидетельствуют о необходимости задуматься об изменении ситуации (разумеется, его можно расширять бесконечно).
Если вы узнаете описанные ситуации, отмечаете как имеющиеся и готовы что-то менять, идём дальше.
Теперь важно определить, какие процессы управления доступом чаще всего нужны.
Список можно продолжать до бесконечности и как угодно детализировать и масштабировать. Но никто, кроме вас, знающих свою компанию и ту среду, в которой приходится работать, не скажет точно, что делать однозначно нужно, а что – нет. Мы можем вместе с вами проанализировать это и предоставить направление развития и варианты.
Процесс внедрения чего-нибудь, включая процесс управления доступом, у меня чётко ассоциируется с внедрением стандартов и «лучших практик» и оценкой рисков. В ряде случаев компании берут стандарт и пытаются методично и последовательно, пункт за пунктом внедрить всё, что в нём написано (а такие мне встречались). При этом не отдают себе отчёта в том, что по каждому «требованию» стандарта нужно проводить анализ и оценивать: «ляжет» ли данное требование в контекст бизнеса вашей компании или нет, не будет ли следование каждому конкретному пункту стоить, как крыло Боинга, не принося какой бы то ни было пользы.
Бремя принятия решения о том, внедрять ли комплекс процессов управления учётными данными и правами пользователей, лежит на представителях бизнеса. В процессе подготовки такого решения команде (да, без команды тут не обойтись) ИТ- и ИБ-специалистов важно составить план перехода на новую модель управления, где учтены все актуальные процессы, роли сотрудников, технические средства и организационные меры.
Технические средства (в частности IdM-решения, самостоятельно или в сочетании с системами других классов) могут облегчить жизнь ИТ- и ИБ-служб за счёт автоматизации многих операций. Они обеспечивают контроль над происходящим и возможность отреагировать на произошедшее в системе событие в кратчайшие сроки, позволяют быстро получить информацию по учётным записям и правам доступа сотрудников в одной консоли, помогают провести аудит и получить автоматически сгенерированный отчёт по форме, заданной в системе.
IdM-решение — инструмент для ИТ и ИБ. И при этом им могут пользоваться все сотрудники компании — в таком случае он становится сервисом, предоставляемым службами ИТ и ИБ. Он позволит пользователям запрашивать согласовывать доступ, вносить изменения в свой профиль для актуализации информации, получить доступ к сервисам самообслуживания. Для руководителей, сотрудников кадровой службы и владельцев бизнес-систем могут формироваться отчёты по доступу и использованию систем сотрудниками компании. Потому подход к внедрению IdM-решения и процессов управления доступом должен быть продуман в том числе с точки зрения удобства и пользы для всех сотрудников компании (и бизнес-подразделений, и ИТ, и ИБ).
В следующей статье мы рассмотрим, как подойти планированию и внедрению процессов управления доступом и разберемся где в этой истории место IdM-решения.
Автор: Мария Ерохина, CISM
Стоит сразу обозначить, чтобы избежать путаницы: термин «IdM» отсылает нас именно ко всему комплексу мер управления доступом, а «IdM-решение» – к классу систем и технических средств.
В каком-то виде у вас точно существует набор процессов управления доступом. И часто он требует массы ручной работы:
- Обработка заявок на предоставление доступа.
- Блокировка доступа сотрудников в связи с увольнением или сменой служебных обязанностей.
- Реагирование на различные инциденты, связанные с недостаточным или чрезмерным доступом сотрудников к информационным системам, ресурсам и их содержанию.
- Аудит прав доступа сотрудников в каждой из информационных систем и т.д.
Всё это, как правило, сопровождается необходимостью не просто заглядывать в разные консоли, но также – идти к администраторам каждой из систем и просить предоставить нужное. Иногда имеются осложнения в виде непростых отношений между подразделениями и претензий типа: «Будет тут всякий ставить задачи моему сотруднику!» и «У нас нет времени делать за вас вашу работу».
Не всегда всё так мрачно, но, если вы узнали хоть одну из указанных ситуаций – вам нужен IdM. А точнее – вам нужно заняться наведением порядка в области управления учётными данными и правами пользователей. Для неопределившихся приведу чек-лист ситуаций-маркеров, которые свидетельствуют о необходимости задуматься об изменении ситуации (разумеется, его можно расширять бесконечно).
1. С точки зрения пользователей и бизнеса:
- Непонятно, как запросить доступ.
- Форма заявки на доступ для «непродвинутого пользователя» сложна и непонятна.
- Процесс обработки запросов, связанных с доступом, непрозрачен: исполнителю непонятно, кто и как определяет, что запрашиваемые параметры доступа можно предоставить.
- Сроки обработки заявок невозможно определить (т.е. могут сделать за 5 минут, а могут — за 5 дней).
- Бизнес-владелец ресурса исключён из процесса принятия решения по запросам пользователей и не может отвечать за возможные последствия для бизнеса.
- Чтобы получить любой доступ, можно просто позвонить «админу Васе» и попросить.
- Сотрудников могут временно включать в проекты с разной мерой ответственности, их периодически обязывают выполнять задачи за отсутствующих коллег, им предоставляют доступ к системе Х. …По завершении проекта закрыть доступ забывают.
2. С точки зрения ИТ:
- Заявки оформляются в свободной форме и через несколько каналов (почта, ServiceDesk, СЭД и т.д.).
- Сложно понять, какой доступ просит пользователь («как у Петра Ивановича», «чтобы отображалась кнопка «Пуск»», «чтобы работать» и т.д.).
- Создание учётных записей, предоставление, изменение и отзыв прав доступа занимает значительную часть рабочего времени администратора.
- Периодически приходится обрабатывать массовые запросы от пользователей на предоставление доступа (аудит, новый функционал в системе и т.д.).
- В некоторых случаях администратору сложно понять, кто какой доступ предоставил пользователю и – на каком основании.
- Администратор не всегда понимает, по какому принципу заявка прошла одобрение.
3. С точки зрения ИБ:
- Доступ к некоторым системам ограничен (в буквальном смысле: нет доступа даже на чтение, и получить быстро достоверную и полную информацию невозможно).
- Аудит прав доступа и попытки наведения порядка не проводятся ввиду трудоёмкости и длительности процесса или проводятся в течение необъятно длительного времени (информация, собранная в начале аудита, успевает устареть к моменту его окончания).
- Нет четких процедур и правил обработки заявок (информация по запросам приходит, но нет понимания – предоставлять доступ или нет).
- Отсутствует матрица доступа или ролевая модель, и очень хочется, чтобы они были хотя бы на некоторых участках. (Доступ на основе ролей удобно предоставлять, если понятно, какой минимум сотруднику нужен для выполнения своих обязанностей. Однако это не отменяет предоставления более широких полномочий в системах параллельно с ролями. Опять же, это – история про наведение порядка.)
- Процедуры управления и контроля есть, они даже прописаны в документах, но не исполняются.
4. Инциденты:
- При инцидентах, связанных с правами пользователей в информационных системах, нет полной картины происходящего, нет и информации о состоянии прав на момент инцидента (и вообще в любой момент прошлого с актуальной на тот момент ролевой моделью или матрицей доступа).
- Нет свидетельств согласования предоставления или отзыва прав доступа у сотрудников.
- Нет возможности выявить несанкционированное (несогласованное) изменение прав доступа сотрудника.
5. Аудит и комплаенс:
- Требования регуляторов и стандарты говорят о необходимости управления доступом.
- Аудиторы выносят предписание об устранении несоответствия (например, есть незаблокированные учётные записи давно не работающих в компании сотрудников), а инструмента для исправления нет.
- Внутренний аудит проводится, в том числе, для контроля соответствия требованиям (внутренним, регуляторов, стандартов и т.д.), но расхождения обнаруживаются каждый раз, т.к. нет процессов управления.
Если вы узнаете описанные ситуации, отмечаете как имеющиеся и готовы что-то менять, идём дальше.
Теперь важно определить, какие процессы управления доступом чаще всего нужны.
1. Процессы, связанные с ротацией кадров:
- Процесс выхода на работу нового сотрудника (организация рабочего места, создание учётных записей в информационных системах, выдача паролей, предоставление первичного доступа и доступа, согласно ролевой модели).
- Процесс увольнения сотрудника (блокировка/отзыв/ограничение доступа, блокировка учётных записей и т.д.).
- Перевод сотрудника на другую должность (повышение, перевод в другое подразделение, компанию холдинга или в филиал).
- Отсутствие сотрудника на рабочем месте (отпуск, больничный, командировка и т.д.).
- Обновление информации о сотрудниках (смена фамилии, изменение должности, номера телефона, офиса и т.д.)
2. Процессы, связанные с доступом сотрудников к информационным ресурсам и системам
- Процесс предоставления доступа (запрос пользователя, согласование, исполнение, контроль).
- Процесс отзыва доступа (по запросу, по политике, при переводе, при увольнении, при выводе системы из эксплуатации и т.д.).
- Процесс пересмотра прав доступа (при переводе, при увольнении, по расписанию и т.д.).
- Процесс аудита прав доступа
3. Процессы, связанные с предоставлением пользователям сервисов
- Процесс подачи заявки (в какой форме, по какой процедуре и т.д.).
- Процесс согласования заявки (кем, в какой последовательности, в какой срок и т.д.).
- Процесс обработки расхождений («Доступ был, а потом его не стало. Я ещё вчера мог это делать...», «У Петрова кнопка активна, а у меня нет, доступ одинаковый запрашивали...» и т.д.).
- Процесс контроля предоставления запрошенных и согласованных прав доступа (удовлетворенность пользователей).
4. Процессы, связанные с реагированием на инциденты и обработкой рисков
- Процесс получения информации о доступе сотрудника в момент инцидента
- Процесс исследования прав доступа сотрудников (SoD-конфликты, изменение ролевой модели и матрицы доступа и т.д.)
5. Процессы, связанные с аудитом
- Процесс аудита на соответствие требованиям (внутренних стандартов и политик, регуляторов, международных стандартов и т.д.)
- Процесс аудита для исследовательских или иных целей.
Список можно продолжать до бесконечности и как угодно детализировать и масштабировать. Но никто, кроме вас, знающих свою компанию и ту среду, в которой приходится работать, не скажет точно, что делать однозначно нужно, а что – нет. Мы можем вместе с вами проанализировать это и предоставить направление развития и варианты.
Процесс внедрения чего-нибудь, включая процесс управления доступом, у меня чётко ассоциируется с внедрением стандартов и «лучших практик» и оценкой рисков. В ряде случаев компании берут стандарт и пытаются методично и последовательно, пункт за пунктом внедрить всё, что в нём написано (а такие мне встречались). При этом не отдают себе отчёта в том, что по каждому «требованию» стандарта нужно проводить анализ и оценивать: «ляжет» ли данное требование в контекст бизнеса вашей компании или нет, не будет ли следование каждому конкретному пункту стоить, как крыло Боинга, не принося какой бы то ни было пользы.
Бремя принятия решения о том, внедрять ли комплекс процессов управления учётными данными и правами пользователей, лежит на представителях бизнеса. В процессе подготовки такого решения команде (да, без команды тут не обойтись) ИТ- и ИБ-специалистов важно составить план перехода на новую модель управления, где учтены все актуальные процессы, роли сотрудников, технические средства и организационные меры.
Технические средства (в частности IdM-решения, самостоятельно или в сочетании с системами других классов) могут облегчить жизнь ИТ- и ИБ-служб за счёт автоматизации многих операций. Они обеспечивают контроль над происходящим и возможность отреагировать на произошедшее в системе событие в кратчайшие сроки, позволяют быстро получить информацию по учётным записям и правам доступа сотрудников в одной консоли, помогают провести аудит и получить автоматически сгенерированный отчёт по форме, заданной в системе.
IdM-решение — инструмент для ИТ и ИБ. И при этом им могут пользоваться все сотрудники компании — в таком случае он становится сервисом, предоставляемым службами ИТ и ИБ. Он позволит пользователям запрашивать согласовывать доступ, вносить изменения в свой профиль для актуализации информации, получить доступ к сервисам самообслуживания. Для руководителей, сотрудников кадровой службы и владельцев бизнес-систем могут формироваться отчёты по доступу и использованию систем сотрудниками компании. Потому подход к внедрению IdM-решения и процессов управления доступом должен быть продуман в том числе с точки зрения удобства и пользы для всех сотрудников компании (и бизнес-подразделений, и ИТ, и ИБ).
В следующей статье мы рассмотрим, как подойти планированию и внедрению процессов управления доступом и разберемся где в этой истории место IdM-решения.
UPD. Читайте далее:
- Часть 3.1. Понятно, что IdM нужен – что дальше? Цели, задачи, заинтересованные стороны.
- Часть 3.2. Как построить модель доступа?
- Часть 3.3. Процедуры и технические средства — от базовых до IdM.
- Часть 3.4. К кому идти за решением проблем?
Автор: Мария Ерохина, CISM
