Безопасность
AWS призывает к обнаружению на скорости машин, поскольку ИИ-агенты получают корпоративные полномочия
AWS заявляет, что автономные агенты требуют собственных идентичностей, постоянного мониторинга поведения и многоуровневого автоматического реагирования. Предупреждение касается не нового продукта безопасности, а изменения того, за чем предприятия должны следить, когда программное обеспечение может действовать без ожидания человека.
Автор: Лео У ·
Amazon Web Services призывает команды корпоративной безопасности рассматривать автономные ИИ-агенты как новый класс идентичности, а не как еще одну функцию приложения. В руководстве, опубликованном совместно с Институтом SANS, AWS утверждает, что агенты аутентифицируются от имени пользователей, объединяют инструменты и выполняют многоэтапные задачи достаточно быстро, чтобы периодические проверки и реагирование на инциденты на человеческой скорости больше не были достаточными. Рекомендация прямолинейна: предоставляйте каждому агенту учетные данные с ограниченными правами, постоянно наблюдайте за поведением и автоматизируйте локализацию угроз, если есть убедительные доказательства.
Сдвиг легко недооценить, потому что агенты часто входят в компанию через привычные интерфейсы. Разработчик включает помощника по кодированию. Финансовая команда подключает модель к счетам-фактурам. Группа поддержки позволяет помощнику обновлять записи клиентов. Каждая интеграция выглядит узкой. Однако объединённая система теперь может читать конфиденциальные данные, отправлять внешние сообщения и изменять состояние производства. Эти три возможности в одном компоненте создают значительно большую поверхность атаки, чем у чат-бота, который лишь возвращает текст.
AWS указывает на большой разрыв между внедрением и управлением, отмечая, что 80% организаций приняли ИИ, в то время как только 10% управляют им. Эти данные взяты из исследований, связанных с поставщиками, и не должны восприниматься как универсальная статистика. Направление, однако, заслуживает доверия: инструменты с низким уровнем кода и API моделей позволяют командам развертывать агентов до того, как центральная служба безопасности их каталогизирует. Следовательно, обнаружение является первым контролем. Компания не может обезопасить агента, о существовании которого она не знает.
Идентичность должна сопровождать агента во всех его действиях
AWS рекомендует использовать временные, узкоспециализированные учетные данные для каждого агента вместо постоянных общих секретов. Это звучит как обычный принцип наименьших привилегий, и так оно и есть. Реализация становится сложнее, когда агент делегирует работу. Родитель может попросить другого агента просмотреть записи, третьего — подготовить ответ, а четвертого — выполнить изменение. Цепочка авторизации должна сохранять информацию о том, кто инициировал задачу, какой компонент принял каждое решение и какой объем прав был унаследован или уменьшен.
Короткоживущие учетные данные ограничивают ущерб от кражи, но они не делают авторизованное действие безопасным. Агент с внедренным приглашением может использовать действительный токен для выполнения неправильного задания. Поэтому политика должна оценивать как личность, так и контекст: какой репозиторий, клиент, транзакция или среда находятся в зоне действия; можно ли отменить запрошенное действие; и мог ли пользователь, инициировавший действие, выполнить его напрямую. Агент не должен становиться обходным путем вокруг контроля, ограничивающего человека, который его использует.
Мониторинг поведения обеспечивает второй уровень. Статические сигнатуры плохо подходят для вероятностных систем, потому что один и тот же ввод может вызывать разные последовательности, а легитимный агент может изменяться по мере эволюции его модели, инструментов или запроса. Командам безопасности нужны базовые показатели частоты использования инструментов, объёма данных, направлений и использования привилегий. Внезапный экспорт, необычный запрос учётных данных или новая цепочка инструментов могут вызвать проверку, даже если ни одно событие не нарушает простое правило.
AWS указывает на GuardDuty, Inspector и Security Hub как на части этой операционной модели. Продукты могут выявлять угрозы в облаке, уязвимости и агрегированные результаты, но контекст агента все равно должен до них доходить. Логи должны связывать решения модели с обычными событиями в облаке. В противном случае аналитик видит роль, которая получает доступ к бакету, не зная, какая цель пользователя, подсказка или вызов инструмента это вызвали. Наблюдаемость агента и телеметрия безопасности не могут оставаться отдельными потоками.
Автоматический отклик нуждается в тормозной системе
Если агенты могут действовать за секунды, процесс ответа, который ждет очередь тикетов, потерпит неудачу. AWS рекомендует многоуровневую автоматизацию: немедленно нейтрализовать явные угрозы, в то время как сомнительные события передавать человеку. Сложная часть заключается в выборе действий с ограниченными последствиями. Отзыв одной сессии агента или блокировка исходящего назначения может быть безопасной. Отключение общей производственной роли или удаление созданных ресурсов может усилить нарушение, которое этот контроль был призван остановить.
Лучшие меры реагирования обратимы, узки и отрепетированы. Команды безопасности могут изолировать рабочее пространство, сменить одну учетную запись, приостановить работу инструмента или потребовать повторного одобрения для действий с высоким воздействием. Они должны тестировать эти меры контроля во время обычной работы, а не обнаруживать во время инцидента, что сдерживание также нарушает обслуживание клиентов. Каждый автономный рабочий процесс должен иметь известное безопасное состояние и способ, позволяющий оператору возобновить работу без полной перестройки всей системы.
Многоагентные системы делают атрибуцию более сложной. Один агент может создавать план, другой выбирать инструмент, а третий выполнять его. Если результат оказывается вредоносным, журнал аудита должен показывать больше, чем просто финальный вызов API. Необходим граф делегирования, решения по политике и преобразования, которые к этому привели. Это важно для отладки, но также влияет на ответственность и внутренний контроль. Команда не может улучшить контроль, если система фиксирует только то, что машина что-то сделала.
Безопасность агента также требует защиты управляющей плоскости от самого агента. Модель не должна иметь возможность переписывать собственную политику, подавлять свои логи или выбирать монитор, который её оценивает. Административные инструменты, телеметрия и правила утверждения должны находиться под отдельными идентичностями. Такое разделение может показаться неудобным во время разработки. Оно становится решающим, как только агенту разрешено изменять продукционный код, финансовые записи или коммуникации с клиентами.
Сотрудничество SANS рассматривает эти практики как расширение зрелой облачной безопасности, а не как замену. Это полезно, потому что команды уже понимают инвентаризацию, принцип наименьших привилегий, оборону в глубину, резервное копирование и реагирование на инциденты. Ошибкой будет применение этих принципов только на границе инфраструктуры, оставляя при этом подсказки, вызовы инструментов и делегированные решения непрозрачными. Облачная учетная запись может быть хорошо настроена, в то время как агент, работающий внутри неё, остаётся фактически не наблюдаемым.
Обновления моделей заслуживают такого же управления изменениями, как и обновления инструментов. Поставщик может изменить способ того, как агент интерпретирует инструкции, не меняя при этом окружающий код приложения. Это может повлиять на то, какие API он вызывает, как часто повторяет запросы и что считает достаточным подтверждением. Следовательно, базовые стандарты безопасности должны учитывать версии. Новая модель должна пройти через противодействующие тесты и поэтапное тестирование трафика, прежде чем она получит производственные полномочия старой модели.
Классификация данных должна влиять на проектирование инструментов. Агент, читающий общедоступную документацию, не требует тех же средств контроля, что агент, совмещающий данные о зарплате с исходящей электронной почтой. Команды могут снизить риск, создавая отдельные агенты или зоны выполнения, вместо того чтобы давать одному помощнику все возможности. Предупреждение AWS о комбинировании конфиденциальных данных, внешней коммуникации и ненадежного контента полезно, потому что оно превращает абстрактный риск в конкретный обзор архитектуры.
Разработчикам также необходима обратная связь, объясняющая заблокированное действие. Если система безопасности просто отклоняет вызов инструмента, команды будут создавать обходные пути или запрашивать широкие исключения. Политический движок должен определить нарушенную границу, показать соответствующую область действия и предложить безопасный путь, например, удаление внешнего доступа или запрос одобрения. Удобные в использовании контроли сохраняют намерения при одновременном ограничении возможностей. Это более надежно, чем повсеместный запрет, который бизнес в конечном итоге игнорирует.
Учения красной команды должны проверять последовательности, а не только запросы. Агент может начать с разрешённого запроса, столкнуться со злонамеренным текстом в документе и постепенно расширять свои действия через делегированные инструменты. Упражнение должно проверять, связывает ли мониторинг эти события, охватывает ли ограничение каждого дочернего агента и могут ли следователи восстановить цепочку. Безопасный ответ в одном окне чата мало что говорит о рабочем процессе, который охватывает часы и различные сервисы.
Метрики должны различать действия по обеспечению безопасности и результаты безопасности. Большее количество оповещений, заблокированных запросов или проверенных агентов может отражать лучшую видимость, чрезмерную чувствительность или более крупный неконтролируемый массив. Полезными показателями являются время обнаружения аномального поведения, радиус поражения, время восстановления и процент действий с высоким воздействием, для которых сохраняется полный след авторизации. Безопасность агентов требует доказательств того, что организация может остановить и объяснить событие, а не только доказательств того, что продукт сгенерировал уведомления.
Предприятиям не нужно ждать идеальной платформы безопасности для агентов. Они могут начать с назначения идентификаторов, удаления широких учетных данных, ведения журналов всех вызовов инструментов, разделения прав на чтение и запись и требования подтверждения человеком для необратимых действий. Эти меры делают ранних агентов менее магическими и более операционными. В этом суть. Как только программное обеспечение сможет действовать на скорости машины, безопасность должна заменить предполагаемые намерения доказательствами, которые могут действовать столь же быстро.
Темы: AWS, агенты ИИ, облачная безопасность, идентичность, реагирование на инциденты