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