Управление идентификацией в эпоху ИИ: шесть принципов защиты от атак

Атаки на сервисы идентификации с использованием ИИ усиливают риски

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

В мае Meta столкнулась с атакой, в ходе которой чат-боты использовались для изменения email-адресов нескольких высокопрофильных пользователей. Это позволило злоумышленникам получить доступ к учетным записям, изменить пароли и взять их под контроль. Хакеры обращались к ИИ-ассистенту поддержки Instagram с просьбой привязать новый email к аккаунту и отправить верификационный код. Бот выполнил запрос, отправив код злоумышленнику, что позволило ему сменить пароль.

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

Нечеловеческие идентификаторы требуют такого же уровня защиты, как и человеческие

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

Инцидент с Meta стал ярким примером чат-ботов с чрезмерными, недостаточно управляемыми разрешениями, которым разрешалось выполнять конфиденциальные изменения в профилях идентификации, включая сброс email и пароля. Такие действия не должны были выполняться без подтверждения человеком. Это можно рассматривать как пробел в IAM, который должен был применяться как к человеческим, так и к нечеловеческим сущностям. Отсутствие одобрения со стороны человека создало уязвимость, которую мог использовать злоумышленник.

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

Применяйте принцип наименьших привилегий и JIT для всех сущностей

IBM провела обширную работу по управлению идентификацией агентов и подчеркивает, что агенты часто накапливают привилегии с течением времени, создавая скрытые пути доступа, которые обычно не понимаются командами по идентификации. Они рекомендуют применять принцип наименьших привилегий к каждому агенту, разрешая только те API, области действия и действия, которые необходимы для выполнения задачи в конкретный момент времени. Кроме того, они выступают за строгое использование учетных данных Just-in-Time (JIT), которые предоставляют краткосрочные токены и эфемерные роли вместо долгосрочных секретов, которыми трудно управлять. Это значительно снижает риск кражи учетных данных, злоупотребления привилегиями и бокового перемещения, поскольку доступ существует только в течение выполнения конкретной задачи и автоматически истекает после ее завершения.

Внедряйте строгие механизмы контроля для ботов поддержки и клиентских ботов

Ботам поддержки ИИ никогда не следует разрешать выполнять конфиденциальные действия с учетной записью без дополнительных мер безопасности. Организации должны запрещать сценарии захвата учетной записи одним действием и гарантировать, что ни один бот не сможет самостоятельно изменить основной адрес электронной почты, сбросить многофакторную аутентификацию (MFA) или выдать ссылки для сброса пароля без подтверждения второго фактора или требования одобрения человека. Политики в виде кода (Policy-as-code) должны использоваться для последовательного применения этих элементов управления. Например, если запрашивающим лицом является агент ИИ, а действие включает изменение учетных данных учетной записи или информации об идентификации, должно автоматически требоваться одобрение человека.

Обеспечьте строгий контроль над секретами, токенами и активностью во время выполнения

IBM и Cloud Security Alliance определяют неуправляемые токены и жестко закодированные секреты как основной источник уязвимостей в средах ИИ. Организации должны централизовать управление ключами API, учетными данными и токенами в выделенной платформе управления секретами и автоматически и часто их ротировать. Организации также должны внедрить мониторинг и принудительное применение во время выполнения для отслеживания поведения агентов и ответа на вопросы, такие как: Какие API вызывает агент? К каким данным получает доступ агент? Какие изменения вносит агент? Действует ли агент в рамках своих разрешенных областей действия и разрешений? Пытается ли агент выполнить действия, которые являются необычными или не соответствуют его обычному поведению? Следует использовать обнаружение аномалий для выявления подозрительной активности, такой как бот поддержки, внезапно пытающийся изменить несколько учетных записей высокого уровня или получить доступ к данным за пределами своих обычных операционных границ.

Источник: ISACA