Управление рисками в IdM/IGA

Управление рисками в IGA-решениях всегда было той самой «темной стороной», на которую предпочитали не заходить российские пользователи. Даже для крупных компаний этот функционал казался чем-то космическим.

Отчасти так сложилось по той причине, что за комплаенс, которому, как правило, принадлежит функция управления рисками в крупных организациях, отвечают подразделения, не близкие к ИБ и уж тем более ИТ, а контролирующие их. В такой конъюнктуре посягать на зону ответственности вышестоящего органа владельцы систем управления доступом, как правило, не решались. Подразделения и руководители, ответственные за управление рисками, в большинстве своем о подобных функциях информационных систем не знали и не проявляли к ним интерес в качестве внутреннего заказчика. В настоящий момент мне известно лишь одно по-настоящему эффективное внедрение на территории РФ, в котором модель управления рисками продумана и выстроена по требованиям внутреннего аудита.

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

Какими рисками может управлять IdM

Для того чтобы понять, какими рисками может управлять IdM, нужно рассмотреть, какими данными он обладает и какие инциденты умеет выявлять. Уровень качества данных и, соответственно, оценки сильно зависят от стадии внедрения и организации базовых процессов управления доступом. Рассмотрим качество и полноту данных на разных этапах внедрения системы:
Итак, IdM-система, в которой выполнена первичная реконсиляция, знает:

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

2. IdM, в котором выполнена первичная сертификация прав доступа и учетных записей, а также настроен аудит, дополнительно обладает сведениями:

• Кто подтвердил принадлежность учетной записи.
• Кто подтвердил необходимость прав доступа.
• Когда пользователь получил доступ.
• Когда пользователь лишился доступа.

3. IdM, в котором настроены процессы самообслуживания или проведена интеграция с ITSM, знает:

• На основании какого запроса пользователь получил права, кто создал запрос, и кто его подтвердил.
• На каком основании и в соответствии с какой должностью был сделан запрос.

4. IdM, в котором построены процессы аттестации прав по расписанию и событиям, знает, когда в последний раз пересматривался доступ.

5. IdM, в котором построена ролевая модель, знает:

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

Приведенного перечня знаний достаточно, как минимум для определения следующих рисков:

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

Управление рисками — это сложно?

Сложность модели оценки рисков сильно зависит от сценариев использования, в которых планируется применять данные оценки. Давайте рассмотрим, какие переменные и по какой причине могут быть использованы в модели оценки:

• Риск обладания правом доступа. Базовая переменная, которая является индикатором уровня привилегии, предоставляемой правом. Именно от нее идет дальнейший скоринг.
• Риск совмещения прав. В зависимости от прав доступа отдельная оценка уровня их риска может быть низкой, но их совместная комбинация у одного лица, или, в частном случае у одной учетной записи, может быть критична значительно больше, нежели просто их сумма.
• Способ получения права. Если право было получено на основании ролевой модели, это менее критично, чем по дополнительному запросу, и уж тем более, чем в обход IdM.
• Неиспользование учетной записи. «Забытые» учетные записи в значительно больше подвержены компрометации, соответственно, крайне нежелательно, чтобы неиспользуемые учетные записи обладали.
• Статус сотрудника. Долгосрочный отпуск, к примеру, также повышает риск компрометации учетных записей работника, соответственно, как и в предыдущем пункте, высокие привилегии для таких УЗ не желательны.
• Положение пользователя относительно периметра организации. Риск злонамеренного использования привилегий пользователями, работающими удаленно, значительно выше, чем у офисных работников.
• Тип пользователя. Обладание критичным набором полномочий подрядчиком также несет больший риск, нежели работником компании.

Построение модели, правильно учитывающей все вышеперечисленные аспекты — достаточно сложная задача, кроме того, не нужно забывать, что эта модель будет требовать поддержки, поэтому подойдут к этому не многие «избранные» организации с высоким уровнем корпоративной культуры.

Использование уровня риска как индикатора привилегированных пользователей

Однако, чтобы функция оценки риска в IdM начала приносить пользу, далеко не обязательно делать сложную модель и согласовывать ее внутри организации.

Для того, чтобы знать привилегированных пользователей и их учетные записи, в простейшем случае достаточно задать оценку для критичных прав доступа и обозначить граничные показатели суммарного уровня риска. Данных мероприятий хватит для того, чтобы получить от IdM отчет по привилегированным сотрудникам и учетным записям. Это уже не маленькое подспорье для ИБ в задаче контроля администраторов, но если немного развить эту простейшую модель, можно получить гораздо больше пользы без особых вложений.

Базовая модель определения уровня риска

Базовая модель оценки риска предполагает наличие следующих правил:

• Уровня риска отдельного права.
• Правило повышения уровня риска для несертифицированного полномочия (предоставленного с обход IdM).
• Правило повышения риска при нарушении SoD, к примеру, это может быть перемножение уровней риска несовместимых прав (r1' * r2') или повышение коэффициента ((r1' + r2') * k).

Этих правил будет достаточно для относительно точной индикации пользователей с повышенными привилегиями и, соответственно, усиления контроля за ними. С задачами контроля IdM-решения также могут помочь.

Компенсация рисков

Компенсация риска — это комплекс мероприятий, направленных на предотвращение наступления рискового события или снижение вероятности его наступления.

Применительно к рассматриваемым рискам это могут быть:

• Усложнение процедуры согласования при запросе доступа с высоким уровнем риска.
• Усиление парольной политики для привилегированной учетной записи.
• Планирование пересмотра привилегированного доступа.
• Назначение владельца риска и планирование аттестации привилегированного пользователя по расписанию.
• И еще множество мер, которые могут быть настроены с использованием конструктора бизнес-процессов.

Кроме мер, которые можно предпринять в самой системе управления доступом, можно значительно повысить эффективность контроля в смежных системах, таких как SIEM. Например, попытка подбора пароля к привилегированной учетной записи, да и любая нетипичная активность этой записи, заслуживают гораздо более пристального внимания, нежели действия любой другой.

Функция оценки и управления рисками в IdM не так страшна и сложна, как ее представляет большинство текущих владельцев систем или будущих заказчиков. С минимальными вложениями трудозатрат она поможет определить и взять под контроль привилегированных пользователей.

Александр Махновский, руководитель департамента разработки компании Аванпост