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

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

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

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

1. Итак, IDM-система, в которой выполнена первичная реконсиляция, знает:

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

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

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

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

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

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

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

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

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

Читайте продолжение на habr.ru