Как стать автором
Обновить
89.97
Солар
Безопасность за нами

Внедрение IdM. Часть 3.2. Как построить модель доступа?

Время на прочтение 7 мин
Количество просмотров 10K
В предыдущих материалах мы рассмотрели, что такое IdM, каковы признаки необходимости внедрения IdM, а также обозначили необходимость постановки целей и задач (т.е. — чего вы и бизнес хотите от системы управления доступом).

А ещё в предыдущей части мы отметили, насколько важно предложить бизнесу подготовленное и продуманное решение. Оно должно быть основано на исследовании проблемы, должно согласовываться с потребностями именно этого бизнеса, включать определённый подход к достижению поставленных целей и описывать уровень вовлечённости каждой из заинтересованных сторон.

Однако перед тем, как представить руководству готовый вариант (или несколько вариантов на выбор), следует понять, «на какой козе подъехать» к решению проблемы, выявленной при первичном аудите ситуации в компании.

image

Подходов к управлению учётными записями и правами пользователей масса, равно как и вариаций внедрения IdM-решений (да-да, их много, но об этом – в другой статье). Сосредоточимся на том, что чаще всего используется, и определим подходящие вам варианты.

В первую очередь обратимся к тому, что упоминают различные стандарты, библиотеки и своды знаний в отношении управления доступом. Здесь фундаментальные понятия – это «confidentiality» (конфиденциальность), «integrity» (целостность) и «availability» (доступность).

«CIA» – триада информационной безопасности.

Почему об этом вообще нужно помнить? Обыкновенно из триады ИБ одно из понятий определяют в качестве фокуса:

  • Мы в первую очередь должны обеспечить конфиденциальность, т.е. максимально ограничить доступ к информации?
  • Или нужна целостность данных, и мы не будем абы кому давать права на модификацию?
  • А, может, важнее всего доступность бизнес-приложений и риски, связанные с конфиденциальностью и целостностью, мы готовы принять?

По каждой информационной системе или бизнес-процессу решение может быть принято самостоятельно. Главное – потом не запутаться, что и где было выбрано.

Также стоит помнить про следующие понятия: «identification» (идентификация), «authentication» (аутентификация), «authorization» (авторизация), «accountability» (ответственность за свои действия/подотчётность) и «nonrepudiation» (невозможность отказаться от авторства).

Зачем? Важно понимать:

  • как пользователь проходит идентификацию и аутентификацию (по логину, токену с сертификатом, отпечатку пальца и т.д.),
  • нужна ли строгая (многофакторная) аутентификация,
  • как проходит авторизация,
  • может ли сотрудник натворить что-то, а потом сказать, что это не он (например, ситуация, когда несколько сотрудников работают под одной учётной записью, встречается чаще, чем хотелось бы и чем вам кажется).

После прояснения указанных базовых вопросов перейдём собственно к тому, с чего стоит начать работу по управлению доступом.

Основные позиции, на которые полезно обратить внимание, — это модель зрелости процессов управления доступом и подход к построению модели доступа.

Хочется сделать процесс управления доступом действительно прозрачным и контролируемым, выявить и обработать соответствующие риски, поставить процесс на поток? Чтобы прийти к этому, сначала нужно разобраться с тем, как на текущий момент сотрудники используют свои учётные записи, как они их получают, после каких событий доступ блокируется и т.д.

Когда мы зафиксировали (лучше, конечно, как-то записывать то, что удалось узнать) полученные данные, нужно составить план по достижению цели.

Можно опираться на модель зрелости процессов управления доступом: (на базе исследования EY)

image

Для начала отметьте, на каком уровне зрелости находится ваша компания, и определите, как можно улучшить существующие позиции.

Пример 1. Переход с начального уровня на повторяемый.
Дано: в компании 650 сотрудников, доступ предоставляется вручную администраторами. Администраторов 5 человек: двое отвечают за доступ к файловым серверам, один за сети, один поддерживает базы данных и один обслуживает 3 бизнес-системы. Пользователи обращаются к администраторам преимущественно по телефону, журналы звонков и обращений не ведутся, периодически возникает путаница с доступом к сетевым папкам («не туда доступ дали», «доступ был и пропал», «не могу найти свою папку», «пропал файл» и т.д.)

Возможное решение: Пересмотреть структуру файловых серверов и папок и оптимизировать ее. Далее – разграничить доступ группами, прописать или хотя бы договориться о правилах предоставления доступа, донести правила до пользователей. Ввести фиксацию обращений пользователей (вариации — от ведения журнала администраторами по факту обращения пользователя по телефону до внедрения Service Desk и IdM).

Пример 2. Переход с установленного уровня на управляемый.
Дано: в компании 2000 сотрудников. Процесс предоставления доступа фиксирован, пользователи его соблюдают, но периодически возникают ситуации, когда заявок слишком много и доступ предоставляется с колоссальными задержками. Аудит периодически выявляет, что учётные записи уже уволенных сотрудников вопреки политикам безопасности остаются активными.

Возможное решение: Автоматизировать рутинные операции (создание учётных записей, предоставление некоторых прав доступа). Выработать процедуры по управлению доступом с понятным и выполняемым SLA (процессы, задачи, исполнители, ответственные, сроки и условия выполнения). Рассмотреть варианты внутреннего аудита доступа пользователей (от контроля соблюдения процедур до внедрения IdM и смежных решений). Разработать и реализовать программу обучения исполнителей и пользователей (от ознакомления с инструкциями до обучающих роликов и образовательной платформы).

(!) Важно: не стоит «перепрыгивать» через уровень, лучше идти к более зрелым процессам постепенно. Можно составить долгосрочный план по совершенствованию процессов, постепенно и поступательно ему следовать.

Помимо модели зрелости стоит учитывать и подход по формированию модели доступа.

Пожалуй, про необходимость ролевой модели в контексте внедрения IdM-решения нас спрашивают чаще всего, хотя есть и другие подходы. Рассмотрим сначала, что такое роль и ролевая модель.

  • Роль – набор прав и функциональных обязанностей, характерных для сотрудника на определённой позиции, который проецируется на доступ этого сотрудника к информационным системам компании.
  • Ролевая модель – совокупность ролей сотрудников компании, позволяющая каждому из них выполнять работу в соответствии со своими трудовыми обязанностями наиболее эффективным способом.

На мой взгляд, в масштабах компании построение такой ролевой модели, где у каждого сотрудника есть одна-единственная роль, обусловленная должностными обязанностями и не имеющая каких бы то ни было дополнительных прав доступа, – это утопия. Есть шанс определить наиболее типовые роли в компании: для банка нормально иметь большое число операционистов и кассиров, в ритейле – продавцы, менеджеры по продвижению, завскладом и т.д., для производств – инженеры и аналитики. Но и здесь всё не так просто. Мы достаточно легко определим, к какой бизнес-системе должен иметь доступ пользователь (например, менеджеру по продажам нужна доменная учётная запись, почта, CRM и СЭД), но не всегда можно определить, какие права доступа нужны в каждой из систем.

Поэтому, исходя из реалий, я бы предложила следующие шаги, которые помогут составить модель доступа:

Шаг 1. Минимальный набор прав. Определяем, какими системами пользуются все сотрудники (кроме персонала, который вообще не имеет доступа к ИТ-системам). Так мы поймём, какие учётные записи заводить всем.

Пример
Самое типовое: доменная (AD), почтовый ящик, электронный документооборот. На этом уровне определяем минимальный набор прав, характерный для учётных записей в каждой из систем.

Шаг 2. Базовый доступ. Смотрим на большие группы пользователей (формально они могут быть не из одного подразделения): рекламщики/маркетологи/PR, ИТ/ИБ, бухгалтерия, менеджеры по продажам и т.д. Этим сотрудникам определяем типовые системы для создания учётных записей и минимальных прав в каждой из систем.

Пример
Все сотрудники ИТ и ИБ имеют доступ Service Desk, а все менеджеры по продажам имеют доступ к CRM, бухгалтерия и кадры имеют доступ к кадровой и бухгалтерской системе (скажем, «1С: Зарплата и управление кадрами» или SAP).

Шаг 3. Стараемся типизировать доступ в разрезе подразделений (укрупнение можно выбрать – департамент, управление, отдел и т.д.)

Пример
Почти у каждого подразделения есть общий сетевой ресурс (диск, папка, облако и т.д.), общие группы доступа AD или в бизнес-системах.

Шаг 4. Теперь разберёмся с тем, какие типовые роли есть внутри подразделений. Их может быть немного. В ряде случаев можно руководствоваться названиями должностей, но не для каждой компании это сработает. Сами знаете, бывает сложно отличить функционал сидящих за соседними столами специалистов, один из которых по должности ведущий, а другой – главный. Часто они выполняют одинаковую работу, а разница лишь в том, какие должности были вакантны на момент их трудоустройства в компанию. Встречается и обратная ситуация – два аналитика работают в одном подразделении, но по разным направлениям деятельности, и доступ к системам у них не пересекается (кроме ресурсов из шага 1).

Пример
В подразделении есть руководитель, который отправляет отчётность через СЭД, и ему нужна не только учётная запись к СЭД’у, но и соответствующие права на отправку отчёта. В данном случае мы можем руководствоваться должностью как фактором, определяющим должностные обязанности и права доступа.

В том же подразделении есть аналитики и инженеры, доступ к определенным системам (наличие учётных записей в одинаковых системах) необходим всем, но уровень прав доступа (права, роли, группы доступа) должен различаться. В данном случае конкретные наборы прав доступа в нескольких информационных системах и составляют роль для аналитика и роль для инженера.

Разумеется, в роль собираются только права доступа, характерные для всех аналитиков и всех инженеров рассматриваемого подразделения.

Шаг 5. Выявление лишних и конфликтующих прав. В первых четырёх шагах мы смотрели на фактически существующие права доступа. Но надо учитывать, что некоторые права могут быть избыточными или конфликтующими. Значит, нужно полученный результат подвергнуть проверке (и не одной) с целью выявить устаревшие права доступа, которые выдают «на всякий случай» и «потому что всем так выдаём».

При этом важно рассматривать не только отдельные права доступа (права, группы прав, роли в каждой целевой системе), но и всю совокупность, чтобы понять, не позволяет ли набор прав сделать то, что выходит за рамки полномочий сотрудника.

Пример
Мы хотим провести платёж по реквизитам. Для этого обращаемся в банк (представим, что у нас нет онлайн-банкинга). Первый шаг – операционист проверяет документы и формирует платёжное поручение. Второй шаг – операционист приглашает второго сотрудника (контролёра), чтобы он тоже проверил ваши документы и подтвердил введённые данные и проведение операции. Третий шаг – касса, где кассир снова проверяет все данные и документы и наконец-то принимает у вас деньги и проводит платёж. Зачем всё так сложно? Для безопасности. С точки зрения прав доступа к АБС (системе, где проводят платежи и ведут учёт) каждый из сотрудников может выполнять только свои операции, а чтобы украсть деньги клиента, нужен сговор или широкие права доступа в АБС, позволяющие одному сотруднику совершить все указанные операции.

На первый взгляд всё просто. Только как собрать всю нужную информацию? Аудит проводить можно долго, а данные, которые требуются с 3-4 шага, быстро устаревают.

В данном случае может помочь IdM-решение, в котором будет аккумулирована информация о правах доступа каждого сотрудника, и которое предоставит инструмент, позволяющий проанализировать наличие учётных записей (а в ряде случаев – и частоты их использования) и прав доступа по всем пяти срезам, описанным выше.

Таким образом, IdM-решение – это не только средство автоматизации рутинных операций, но и важный инструмент для контроля и анализа прав доступа сотрудников. Подробнее об этом – в следующей статье.



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



Автор: Мария Ерохина, CISM
Теги:
Хабы:
+15
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
rt-solar.ru
Дата регистрации
Дата основания
2015
Численность
1 001–5 000 человек
Местоположение
Россия