Внедрение IdM. Часть 3.2. Как построить модель доступа? +15
Информационная безопасность, IT-стандарты, Управление проектами, Блог компании Solar Security, IT-инфраструктура
Рекомендация: подборка платных и бесплатных курсов системных администраторов - https://katalog-kursov.ru/
В предыдущих материалах мы рассмотрели, что такое IdM, каковы признаки необходимости внедрения IdM, а также обозначили необходимость постановки целей и задач (т.е. — чего вы и бизнес хотите от системы управления доступом).
А ещё в предыдущей части мы отметили, насколько важно предложить бизнесу подготовленное и продуманное решение. Оно должно быть основано на исследовании проблемы, должно согласовываться с потребностями именно этого бизнеса, включать определённый подход к достижению поставленных целей и описывать уровень вовлечённости каждой из заинтересованных сторон.
Однако перед тем, как представить руководству готовый вариант (или несколько вариантов на выбор), следует понять, «на какой козе подъехать» к решению проблемы, выявленной при первичном аудите ситуации в компании.
Подходов к управлению учётными записями и правами пользователей масса, равно как и вариаций внедрения IdM-решений (да-да, их много, но об этом – в другой статье). Сосредоточимся на том, что чаще всего используется, и определим подходящие вам варианты.
В первую очередь обратимся к тому, что упоминают различные стандарты, библиотеки и своды знаний в отношении управления доступом. Здесь фундаментальные понятия – это «confidentiality» (конфиденциальность), «integrity» (целостность) и «availability» (доступность).
«CIA» – триада информационной безопасности.
Почему об этом вообще нужно помнить? Обыкновенно из триады ИБ одно из понятий определяют в качестве фокуса:
- Мы в первую очередь должны обеспечить конфиденциальность, т.е. максимально ограничить доступ к информации?
- Или нужна целостность данных, и мы не будем абы кому давать права на модификацию?
- А, может, важнее всего доступность бизнес-приложений и риски, связанные с конфиденциальностью и целостностью мы готовы принять?
По каждой информационной системе или бизнес-процессу решение может быть принято самостоятельно. Главное – потом не запутаться, что где было выбрано.
Также стоит помнить про следующие понятия: «
identification» (идентификация), «
authentication» (аутентификация), «
authorization» (авторизация), «
accountability» (ответственность за свои действия/подотчётность) и «nonrepudiation» (невозможность отказаться от авторства).
Зачем? Важно понимать:
- как пользователь проходит идентификацию и аутентификацию (по логину, токену с сертификатом, отпечатку пальца и т.д.),
- нужна ли строгая (многофакторная) аутентификация,
- как проходит авторизация,
- может ли сотрудник натворить что-то, а потом сказать, что это не он (например, ситуация, когда несколько сотрудников работают под одной учётной записью, встречается чаще, чем хотелось бы и чем вам кажется)
После прояснения указанных базовых вопросов перейдём собственно к тому, с чего стоит начать работу по управлению доступом.
Основные позиции, на которые полезно обратить внимание это
модель зрелости процессов управления доступом и
подход к построению модели доступа.
Хочется сделать процесс управления доступом действительно прозрачным и контролируемым, выявить и обработать соответствующие риски, поставить процесс на поток? Чтобы прийти к этому, сначала нужно разобраться с тем, как на текущий момент сотрудники используют свои учётные записи, как они их получают, после каких событий доступ блокируется и т.д.
Когда мы зафиксировали (лучше, конечно, как-то
записывать то, что удалось узнать) полученные данные, нужно составить план по достижению цели.
Можно опираться на
модель зрелости процессов управления доступом: (
на базе исследования EY)
Для начала отметьте, на каком уровне зрелости находится ваша компания, и определите, как можно улучшить существующие позиции.
Пример 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-решение – это не только средство автоматизации рутинных операций, но и важный инструмент для контроля и анализа прав доступа сотрудников. Подробнее об этом – в следующей статье.
К сожалению, не доступен сервер mySQL