В предыдущих материалах мы рассмотрели, что такое IdM, каковы признаки необходимости внедрения IdM, а также обозначили необходимость постановки целей и задач (т.е. — чего вы и бизнес хотите от системы управления доступом).
А ещё в предыдущей части мы отметили, насколько важно предложить бизнесу подготовленное и продуманное решение. Оно должно быть основано на исследовании проблемы, должно согласовываться с потребностями именно этого бизнеса, включать определённый подход к достижению поставленных целей и описывать уровень вовлечённости каждой из заинтересованных сторон.
Однако перед тем, как представить руководству готовый вариант (или несколько вариантов на выбор), следует понять, «на какой козе подъехать» к решению проблемы, выявленной при первичном аудите ситуации в компании.
Подходов к управлению учётными записями и правами пользователей масса, равно как и вариаций внедрения IdM-решений (да-да, их много, но об этом – в другой статье). Сосредоточимся на том, что чаще всего используется, и определим подходящие вам варианты.
В первую очередь обратимся к тому, что упоминают различные стандарты, библиотеки и своды знаний в отношении управления доступом. Здесь фундаментальные понятия – это «confidentiality» (конфиденциальность), «integrity» (целостность) и «availability» (доступность).
«CIA» – триада информационной безопасности.
Почему об этом вообще нужно помнить? Обыкновенно из триады ИБ одно из понятий определяют в качестве фокуса:
По каждой информационной системе или бизнес-процессу решение может быть принято самостоятельно. Главное – потом не запутаться, что где было выбрано.
Также стоит помнить про следующие понятия: «identification» (идентификация), «authentication» (аутентификация), «authorization» (авторизация), «accountability» (ответственность за свои действия/подотчётность) и «nonrepudiation» (невозможность отказаться от авторства).
Зачем? Важно понимать:
После прояснения указанных базовых вопросов перейдём собственно к тому, с чего стоит начать работу по управлению доступом.
Основные позиции, на которые полезно обратить внимание это модель зрелости процессов управления доступом и подход к построению модели доступа.
Хочется сделать процесс управления доступом действительно прозрачным и контролируемым, выявить и обработать соответствующие риски, поставить процесс на поток? Чтобы прийти к этому, сначала нужно разобраться с тем, как на текущий момент сотрудники используют свои учётные записи, как они их получают, после каких событий доступ блокируется и т.д.
Когда мы зафиксировали (лучше, конечно, как-то записывать то, что удалось узнать) полученные данные, нужно составить план по достижению цели.
Можно опираться на модель зрелости процессов управления доступом: (на базе исследования EY)
Для начала отметьте, на каком уровне зрелости находится ваша компания, и определите, как можно улучшить существующие позиции.
(!) Важно: Не стоит «перепрыгивать» через уровень, лучше идти к более зрелым процессам постепенно. Можно составить долгосрочный план по совершенствованию процессов, постепенно и поступательно ему следовать.
Помимо модели зрелости стоит учитывать и подход по формированию модели доступа.
Пожалуй, про необходимость ролевой модели в контексте внедрения IdM-решения нас спрашивают чаще всего, хотя есть и другие подходы. Рассмотрим сначала, что такое роль и ролевая модель.
На мой взгляд, в масштабах компании построение такой ролевой модели, где у каждого сотрудника есть одна-единственная роль, обусловленная должностными обязанностями и не имеющая каких бы то ни было дополнительных прав доступа, – это утопия. Есть шанс определить наиболее типовые роли в компании: для банка нормально иметь большое число операционистов и кассиров, в ритейле – продавцы, менеджеры по продвижению, завскладом и т.д., для производств – инженеры и аналитики. Но и здесь всё не так просто. Мы достаточно легко определим, к какой бизнес-системе должен иметь доступ пользователь (например, менеджеру по продажам нужна доменная учётная запись, почта, CRM и СЭД), но не всегда можно определить, какие права доступа нужны в каждой из систем.
Поэтому, исходя из реалий, я бы предложила следующие шаги, которые помогут составить модель доступа:
Шаг 1. Минимальный набор прав. Определяем, какими системами пользуются все сотрудники (кроме персонала, который вообще не имеет доступа к ИТ-системам). Так мы поймём, какие учётные записи заводить всем.
Шаг 2. Базовый доступ. Смотрим на большие группы пользователей (формально они могут быть не из одного подразделения): рекламщики/маркетологи/PR, ИТ/ИБ, бухгалтерия, менеджеры по продажам и т.д. Этим сотрудникам определяем типовые системы для создания учётных записей и минимальных прав в каждой из систем.
Шаг 3. Стараемся типизировать доступ в разрезе подразделений (укрупнение можно выбрать – департамент, управление, отдел и т.д.)
Шаг 4.Теперь разберёмся с тем, какие типовые роли есть внутри подразделений. Их может быть немного. В ряде случаев можно руководствоваться названиями должностей, но не для каждой компании это сработает. Сами знаете, бывает сложно отличить функционал сидящих за соседними столами специалистов, один из которых по должности ведущий, а другой – главный. Часто они выполняют одинаковую работу, а разница лишь в том, какие должности были вакантны на момент их трудоустройства в компанию. Встречается и обратная ситуация – два аналитика работают в одном подразделении, но по разным направлениям деятельности, и доступ к системам у них не пересекается (кроме ресурсов из шага 1).
Шаг 5. Выявление лишних и конфликтующих прав. В первых четырёх шагах мы смотрели на фактически существующие права доступа. Но надо учитывать, что некоторые права могут быть избыточными или конфликтующими. Значит, нужно полученный результат подвергнуть проверке (и не одной) с целью выявить устаревшие права доступа, которые выдают «на всякий случай» и «потому что всем так выдаём».
При этом важно рассматривать не только отдельные права доступа (права, группы прав, роли в каждой целевой системе), но и всю совокупность, чтобы понять, не позволяет ли набор прав сделать то, что выходит за рамки его полномочий сотрудника.
На первый взгляд всё просто. Только как собрать всю нужную информацию? Аудит проводить можно долго, а данные, которые требуются с 3-4 шага, быстро устаревают.
В данном случае может помочь IdM-решение, в котором будет аккумулирована информация о правах доступа каждого сотрудника, и которое предоставит инструмент, позволяющий проанализировать наличие учётных записей (а в ряде случаев – и частоты их использования) и прав доступа по всем пяти срезам, описанным выше.
Таким образом, IdM-решение – это не только средство автоматизации рутинных операций, но и важный инструмент для контроля и анализа прав доступа сотрудников. Подробнее об этом – в следующей статье.
А ещё в предыдущей части мы отметили, насколько важно предложить бизнесу подготовленное и продуманное решение. Оно должно быть основано на исследовании проблемы, должно согласовываться с потребностями именно этого бизнеса, включать определённый подход к достижению поставленных целей и описывать уровень вовлечённости каждой из заинтересованных сторон.
Однако перед тем, как представить руководству готовый вариант (или несколько вариантов на выбор), следует понять, «на какой козе подъехать» к решению проблемы, выявленной при первичном аудите ситуации в компании.
Подходов к управлению учётными записями и правами пользователей масса, равно как и вариаций внедрения IdM-решений (да-да, их много, но об этом – в другой статье). Сосредоточимся на том, что чаще всего используется, и определим подходящие вам варианты.
В первую очередь обратимся к тому, что упоминают различные стандарты, библиотеки и своды знаний в отношении управления доступом. Здесь фундаментальные понятия – это «confidentiality» (конфиденциальность), «integrity» (целостность) и «availability» (доступность).
«CIA» – триада информационной безопасности.
Почему об этом вообще нужно помнить? Обыкновенно из триады ИБ одно из понятий определяют в качестве фокуса:
- Мы в первую очередь должны обеспечить конфиденциальность, т.е. максимально ограничить доступ к информации?
- Или нужна целостность данных, и мы не будем абы кому давать права на модификацию?
- А, может, важнее всего доступность бизнес-приложений и риски, связанные с конфиденциальностью и целостностью мы готовы принять?
По каждой информационной системе или бизнес-процессу решение может быть принято самостоятельно. Главное – потом не запутаться, что где было выбрано.
Также стоит помнить про следующие понятия: «identification» (идентификация), «authentication» (аутентификация), «authorization» (авторизация), «accountability» (ответственность за свои действия/подотчётность) и «nonrepudiation» (невозможность отказаться от авторства).
Зачем? Важно понимать:
- как пользователь проходит идентификацию и аутентификацию (по логину, токену с сертификатом, отпечатку пальца и т.д.),
- нужна ли строгая (многофакторная) аутентификация,
- как проходит авторизация,
- может ли сотрудник натворить что-то, а потом сказать, что это не он (например, ситуация, когда несколько сотрудников работают под одной учётной записью, встречается чаще, чем хотелось бы и чем вам кажется)
После прояснения указанных базовых вопросов перейдём собственно к тому, с чего стоит начать работу по управлению доступом.
Основные позиции, на которые полезно обратить внимание это модель зрелости процессов управления доступом и подход к построению модели доступа.
Хочется сделать процесс управления доступом действительно прозрачным и контролируемым, выявить и обработать соответствующие риски, поставить процесс на поток? Чтобы прийти к этому, сначала нужно разобраться с тем, как на текущий момент сотрудники используют свои учётные записи, как они их получают, после каких событий доступ блокируется и т.д.
Когда мы зафиксировали (лучше, конечно, как-то записывать то, что удалось узнать) полученные данные, нужно составить план по достижению цели.
Можно опираться на модель зрелости процессов управления доступом: (на базе исследования EY)
Для начала отметьте, на каком уровне зрелости находится ваша компания, и определите, как можно улучшить существующие позиции.
Пример 1. Переход с начального уровня на повторяемый.
Дано: в компании 650 сотрудников, доступ предоставляется вручную администраторами. Администраторов 5 человек: двое отвечают за доступ к файловым серверам, один за сети, один поддерживает базы данных и один обслуживает 3 бизнес-системы. Пользователи обращаются к администраторам преимущественно по телефону, журналы звонков и обращений не ведутся, периодически возникает путаница с доступом к сетевым папкам («не туда доступ дали», «доступ был и пропал», «не могу найти свою папку», «пропал файл» и т.д.)
Возможное решение: Пересмотреть структуру файловых серверов и папок и оптимизировать ее. Далее – разграничить доступ группами, прописать или хотя бы договориться о правилах предоставления доступа, донести правила до пользователей. Ввести фиксацию обращений пользователей (вариации — от ведения журнала администраторами по факту обращения пользователя по телефону до внедрения Service Desk и IdM).
Возможное решение: Пересмотреть структуру файловых серверов и папок и оптимизировать ее. Далее – разграничить доступ группами, прописать или хотя бы договориться о правилах предоставления доступа, донести правила до пользователей. Ввести фиксацию обращений пользователей (вариации — от ведения журнала администраторами по факту обращения пользователя по телефону до внедрения Service Desk и IdM).
Пример 2. Переход с установленного уровня на управляемый.
Дано: в компании 2000 сотрудников. Процесс предоставления доступа фиксирован, пользователи его соблюдают, но периодически возникают ситуации, когда заявок слишком много и доступ предоставляется с колоссальными задержками. Аудит периодически выявляет, что учётные записи уже уволенных сотрудников вопреки политикам безопасности остаются активными.
Возможное решение: Автоматизировать рутинные операции (создание учётных записей, предоставление некоторых прав доступа). Выработать процедуры по управлению доступом с понятным и выполняемым SLA (процессы, задачи, исполнители, ответственные, сроки и условия выполнения). Рассмотреть варианты внутреннего аудита доступа пользователей (от контроля соблюдения процедур до внедрения IdM и смежных решений). Разработать и реализовать программу обучения исполнителей и пользователей (от ознакомления с инструкциями до обучающих роликов и образовательной платформы).
Возможное решение: Автоматизировать рутинные операции (создание учётных записей, предоставление некоторых прав доступа). Выработать процедуры по управлению доступом с понятным и выполняемым SLA (процессы, задачи, исполнители, ответственные, сроки и условия выполнения). Рассмотреть варианты внутреннего аудита доступа пользователей (от контроля соблюдения процедур до внедрения IdM и смежных решений). Разработать и реализовать программу обучения исполнителей и пользователей (от ознакомления с инструкциями до обучающих роликов и образовательной платформы).
(!) Важно: Не стоит «перепрыгивать» через уровень, лучше идти к более зрелым процессам постепенно. Можно составить долгосрочный план по совершенствованию процессов, постепенно и поступательно ему следовать.
Помимо модели зрелости стоит учитывать и подход по формированию модели доступа.
Пожалуй, про необходимость ролевой модели в контексте внедрения IdM-решения нас спрашивают чаще всего, хотя есть и другие подходы. Рассмотрим сначала, что такое роль и ролевая модель.
- Роль – набор прав и функциональных обязанностей, характерных для сотрудника на определённой позиции, который проецируется на доступ этого сотрудника к информационным системам компании.
- Ролевая модель – совокупность ролей сотрудников компании, позволяющая каждому из них выполнять работу в соответствии со своими трудовыми обязанностями наиболее эффективным способом.
На мой взгляд, в масштабах компании построение такой ролевой модели, где у каждого сотрудника есть одна-единственная роль, обусловленная должностными обязанностями и не имеющая каких бы то ни было дополнительных прав доступа, – это утопия. Есть шанс определить наиболее типовые роли в компании: для банка нормально иметь большое число операционистов и кассиров, в ритейле – продавцы, менеджеры по продвижению, завскладом и т.д., для производств – инженеры и аналитики. Но и здесь всё не так просто. Мы достаточно легко определим, к какой бизнес-системе должен иметь доступ пользователь (например, менеджеру по продажам нужна доменная учётная запись, почта, CRM и СЭД), но не всегда можно определить, какие права доступа нужны в каждой из систем.
Поэтому, исходя из реалий, я бы предложила следующие шаги, которые помогут составить модель доступа:
Шаг 1. Минимальный набор прав. Определяем, какими системами пользуются все сотрудники (кроме персонала, который вообще не имеет доступа к ИТ-системам). Так мы поймём, какие учётные записи заводить всем.
Пример
Самое типовое: доменная (AD), почтовый ящик, электронный документооборот. На этом уровне определяем минимальный набор прав, характерный для учётных записей в каждой из систем.
Шаг 2. Базовый доступ. Смотрим на большие группы пользователей (формально они могут быть не из одного подразделения): рекламщики/маркетологи/PR, ИТ/ИБ, бухгалтерия, менеджеры по продажам и т.д. Этим сотрудникам определяем типовые системы для создания учётных записей и минимальных прав в каждой из систем.
Пример
Все сотрудники ИТ и ИБ имеют доступ Service Desk, а все менеджеры по продажам имеют доступ к CRM, бухгалтерия и кадры имеют доступ к кадровой и бухгалтерской системе (скажем, «1С: Зарплата и управление кадрами» или SAP).
Шаг 3. Стараемся типизировать доступ в разрезе подразделений (укрупнение можно выбрать – департамент, управление, отдел и т.д.)
Пример
Почти у каждого подразделения есть общий сетевой ресурс (диск, папка, облако и т.д.), общие группы доступа AD или в бизнес-системах.
Шаг 4.Теперь разберёмся с тем, какие типовые роли есть внутри подразделений. Их может быть немного. В ряде случаев можно руководствоваться названиями должностей, но не для каждой компании это сработает. Сами знаете, бывает сложно отличить функционал сидящих за соседними столами специалистов, один из которых по должности ведущий, а другой – главный. Часто они выполняют одинаковую работу, а разница лишь в том, какие должности были вакантны на момент их трудоустройства в компанию. Встречается и обратная ситуация – два аналитика работают в одном подразделении, но по разным направлениям деятельности, и доступ к системам у них не пересекается (кроме ресурсов из шага 1).
Пример
В подразделении есть руководитель, который отправляет отчётность через СЭД, и ему нужна не только учётная запись к СЭД’у, но и соответствующие права на отправку отчёта. В данном случае мы можем руководствоваться должностью как фактором, определяющим должностные обязанности и права доступа.
В том же подразделении есть аналитики и инженеры, доступ к определенным системам (наличие учётных записей в одинаковых системах) необходим всем, но уровень прав доступа (права, роли, группы доступа) должен различаться. В данном случае конкретные наборы прав доступа в нескольких информационных системах и составляют роль для аналитика и роль для инженера.
Разумеется, в роль собираются только права доступа, характерные для всех аналитиков и всех инженеров рассматриваемого подразделения.
В том же подразделении есть аналитики и инженеры, доступ к определенным системам (наличие учётных записей в одинаковых системах) необходим всем, но уровень прав доступа (права, роли, группы доступа) должен различаться. В данном случае конкретные наборы прав доступа в нескольких информационных системах и составляют роль для аналитика и роль для инженера.
Разумеется, в роль собираются только права доступа, характерные для всех аналитиков и всех инженеров рассматриваемого подразделения.
Шаг 5. Выявление лишних и конфликтующих прав. В первых четырёх шагах мы смотрели на фактически существующие права доступа. Но надо учитывать, что некоторые права могут быть избыточными или конфликтующими. Значит, нужно полученный результат подвергнуть проверке (и не одной) с целью выявить устаревшие права доступа, которые выдают «на всякий случай» и «потому что всем так выдаём».
При этом важно рассматривать не только отдельные права доступа (права, группы прав, роли в каждой целевой системе), но и всю совокупность, чтобы понять, не позволяет ли набор прав сделать то, что выходит за рамки его полномочий сотрудника.
Пример
Мы хотим провести платёж по реквизитам. Для этого обращаемся в банк (представим, что у нас нет онлайн-банкинга). Первый шаг – операционист проверяет документы и формирует платёжное поручение. Второй шаг – операционист приглашает второго сотрудника (контролёра), чтобы он тоже проверил ваши документы и подтвердил введённые данные и проведение операции. Третий шаг – касса, где кассир снова проверяет все данные и документы и наконец-то принимает у вас деньги и проводит платёж. Зачем всё так сложно? Для безопасности. С точки зрения прав доступа к АБС (системе, где проводят платежи и ведут учёт) каждый из сотрудников может выполнять только свои операции, а чтобы украсть деньги клиента, нужен сговор или широкие права доступа в АБС, позволяющие одному сотруднику совершить все указанные операции.
На первый взгляд всё просто. Только как собрать всю нужную информацию? Аудит проводить можно долго, а данные, которые требуются с 3-4 шага, быстро устаревают.
В данном случае может помочь IdM-решение, в котором будет аккумулирована информация о правах доступа каждого сотрудника, и которое предоставит инструмент, позволяющий проанализировать наличие учётных записей (а в ряде случаев – и частоты их использования) и прав доступа по всем пяти срезам, описанным выше.
Таким образом, IdM-решение – это не только средство автоматизации рутинных операций, но и важный инструмент для контроля и анализа прав доступа сотрудников. Подробнее об этом – в следующей статье.