Снижаем риски компании с помощью системы управления доступом IdM/IGA

Снижаем риски компании с помощью системы управления доступом IdM/IGA

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

Какие задачи нужно решать в первую очередь

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

  • Как снизить риски, когда много сотрудников и систем
  • У сотрудника может быть много разнообразных полномочий в разных информационных системах. Не всегда по названию полномочий можно понять, насколько серьёзные действия может предпринять тот или иной работник. Например, у коммерческого директора может быть широкий доступ в системы CRM (система управления клиентами), ERP (система управления предприятием), 1C (бухгалтерская система), СЭД (система электронного документооборота). У старшего эксперта финансового отдела – доступ ко всем финансовым операциям и установке курсов валют. У специалиста группы ИТ – права на администрирование основных систем компании, включая вывод из эксплуатации, установку обновлений, создание и удаление объектов в этих системах.

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

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

  • Можно ли выявить высокий риск заранее
  • Довольно часто сотрудникам компании не хватает предоставленных стандартных прав доступа для выполнения определённых рабочих задач. Представьте, что руководитель финансового подразделения заболел, и некому подтверждать платёжные операции. Тогда одному из старших специалистов расширяют полномочия и дают права руководителя. Он оформляет заявку на расширение прав и перечисляет необходимые полномочия. И вот в этой ситуации обязательно нужен механизм, который позволит контролировать, какие права получит сотрудник, насколько они высокорисковые и на какой срок они будут согласованы. Например, можно открыть доступ только к функции подтверждения операций на 2-3 часа в день и затем отозвать такие права. Или же, наоборот, можно предоставить доступ бессрочно и забыть про него, и тогда возможны злоупотребления: например, использование контрольных функций для совершения кражи через перевод денег на подставной счёт.

    Все перечисленные проблемы вполне решаемы, если использовать автоматизированные механизмы подсчёта уровня риска по каждому сотруднику, анализировать и предупреждать накопление излишних высокорисковых прав.

Как мы решаем эти задачи с помощью модели рисков системы Solar inRights

  • Присваиваем индексы риска
  • Для начала каждому полномочию, к которому мы можем предоставить доступ, мы присвоим числовой параметр (индекс), или вес. Предположим, у нас будет четыре градации, где 0 – нет риска, 1 – низкий риск, 2 – средний и 3 – высокий. Например, полномочие, которое даёт полный доступ к базе данных клиентов, будет иметь высокий уровень риска, а полномочие, которое предоставляет доступ в почтовую систему Microsoft Exchange, будет иметь низкий уровень риска.

    Рис.1 Пример уровней риска, присвоенные полномочиям

  • Считаем интегральный уровень риска по сотруднику
  • После присвоения числовых индексов каждому полномочию можно рассчитать интегральный (суммарный) уровень риска (ИУР) для сотрудника. Он включает сумму всех рисков по отдельным полномочиям, которые доступны конкретному работнику. Эти полномочия сотрудник может получить на основании занимаемой должности или по отдельным заявкам. Вся информация по интегральному уровню риска, т.е. оценка риска пользователя, представлена в виде атрибута его профиля и отражается в карточке пользователя. Например, на рисунке 2 показан фрагмент карточки сотрудника Семенова Рустама Анатольевича, который является специалистом по обслуживанию клиентов. Ему доступны три полномочия с высоким уровнем риска и одно –с низким.

    Рис.2 Фрагмент карточки пользователя с информацией о доступных полномочиях

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

    Весовые коэффициенты можно устанавливать не только на роли/полномочия, но и на другие объекты, например, учётные записи в определённых системах. Развитие модели рисков предполагает реагирование не только на различные объекты, но и на события: большое количество запросов на доступ в определённый промежуток времени, нарушения политики SoD (Segregation of Duties), длительное отсутствие ресертификации прав и т.п.

    Для перехода ИУР от низкого уровня к среднему и от среднего к высокому каждая компания может настроить свои пороговые значения ИУР сотрудника в соответствии с действующей политикой. В нашем примере значение «3» и более — это средний уровень, а начиная с «9» —высокий.

    Рис.3 Пороговые значения уровня риска

    Каждый раз при изменении прав доступа пользователя система пересчитывает его ИУР. При переходе заданного порога и попадания ИУР в красную зону настраивается почтовое уведомление ответственного сотрудника. Это может быть офицер безопасности или руководитель подразделения. Ответственный сотрудник, получая такое уведомительное письмо, может либо принять решение о допустимости высокого уровня риска, либо запустить процедуру пересмотра прав доступа пользователя.

    Как мы видим в карточке пользователя у сотрудника Семенова Рустама Анатольевича, которого мы взяли в пример (рис.2), текущий интегральный уровень риска равен 10, и это будет высокий уровень.

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

    Поскольку оценка рисков представлена в виде атрибутов и заданы определённые пороговые значения, можно построить консолидированный отчёт – карту рисков. Такой отчёт наглядно покажет интегральные уровни риска по сотрудникам. Цветом будут отмечены ИУР пользователей, находящихся в той или иной зоне риска, в соответствии с заданными порогами. Отчёт можно выгрузить на компьютер и работать с ним в любом удобном формате.

    Рис. 4 Отчёт: карта рисков

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

    Рис. 5. Бизнес процесс – работа с ИУР

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

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

    Рис. 6 Оформление заявки на дополнительный доступ

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

    Рис. 7 Процесс согласования заявки на дополнительный доступ

    Исторически сложилось, что решения по автоматизированному управлению доступом всегда отвечают на вопрос: «Кто имеет доступ и к каким ресурсам?». Однако в современном мире, когда внешние атаки нацелены на получение доступа к учётным записям с расширенными правами, этого уже недостаточно. Необходимо знать, понимать и оценивать, что с этим доступом можно сделать. Для этого в IdM/IGA необходимы отдельные функции расширенной аналитики для работы с рисками. Модуль управления рисками позволяет вовремя определять источник риска, принимать меры по удалению излишних полномочий, препятствовать накоплению высокорисковых прав и своевременно корректировать политику контроля доступа.

Заглядывая в будущее

Забегая вперед, можно предположить, что работа с рисками будет занимать центральное место в обеспечении безопасности данных, а функционал решений IdM/IGA в этой части будет только расширяться. Решения по управлению доступом будут включать не только статическую оценку рисков (учетные записи и права, предоставленные пользователю), но и динамическую, например, поведенческую аналитику, полученную из системы DLP, или информацию, полученную из системы управления уязвимостями.

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

Автор: Людмила Севастьянова, эксперт Центра компетенций управления доступом Solar inRights «РТК-Солар»

Наш канал защищен лучше, чем ваш компьютер!

Но доступ к знаниям открыт для всех

Получите root-права на безопасность — подпишитесь