Как одно лишнее разрешение в AWS Bedrock открывает злоумышленникам путь ко всей инфраструктуре?

Команда исследователей угроз XM Cyber взялась за платформу AWS Bedrock — сервис Amazon для создания приложений на основе ИИ, подключённых к корпоративным данным и системам. Платформа связывает базовые модели с Salesforce, Lambda, SharePoint, Confluence и множеством других сервисов. Эта связность и делает Bedrock мощным инструментом, и одновременно превращает его в лакомую цель. Исследователи обнаружили восемь валидированных векторов атак, и главный вывод оказался неожиданным: злоумышленники не атакуют саму модель ИИ. Они бьют по разрешениям, конфигурациям и интеграциям вокруг неё. Одна-единственная учётная запись с избыточными привилегиями способна привести к компрометации критически важных активов.

Первый вектор связан с логами вызовов моделей. Bedrock ведёт журналы для аудита и соответствия требованиям, и атакующий может читать существующий S3-бакет, собирая оттуда чувствительные данные. Разрешение bedrock:PutModelInvocationLoggingConfiguration позволяет перенаправить логи в бакет, контролируемый злоумышленником, — все промпты тихо утекают. А с помощью s3:DeleteObject или logs:DeleteLogStream можно затереть следы попыток джейлбрейка, уничтожив криминалистические улики.
Второй и третий векторы бьют по базам знаний. Bedrock использует Retrieval Augmented Generation (RAG), подтягивая данные из корпоративных источников: S3-бакетов, инстансов Salesforce, библиотек SharePoint, пространств Confluence. Разрешение s3:GetObject позволяет обойти модель ИИ целиком и вытащить сырые данные напрямую из бакетов. Если у атакующего есть привилегии для расшифровки секретов, он крадёт учётные данные SaaS-подключений Bedrock. Украденные креденшиалы SharePoint потенциально дают возможность двигаться латерально прямо в Active Directory. На стороне хранилищ данных (векторные базы вроде Pinecone и Redis Enterprise Cloud, а также AWS-нативные Aurora и Redshift) API-вызов bedrock:GetKnowledgeBase извлекает значения эндпоинтов и API-ключи из объекта StorageConfiguration. Результат — полный административный доступ к векторным индексам или структурированным базам знаний.
Четвёртый и пятый векторы нацелены на агентов Bedrock — автономных оркестраторов. Прямая атака использует bedrock:UpdateAgent или bedrock:CreateAgent для перезаписи базового промпта агента, заставляя его сливать внутренние инструкции и схемы инструментов. Через bedrock:CreateAgentActionGroup злоумышленник подключает вредоносный исполнитель к легитимному агенту, получая возможность вносить несанкционированные изменения в базу данных или создавать пользователей. Непрямая атака обходится без изменения конфигурации агента: разрешение lambda:UpdateFunctionCode разворачивает вредоносный код прямо в Lambda-функции, которую агент использует для выполнения задач. А lambda:PublishLayer позволяет тихо внедрить вредоносные зависимости. Итог — эксфильтрация данных или подмена ответов модели.
Шестой вектор касается рабочих процессов (Flows). Разрешение bedrock:UpdateFlow даёт возможность внедрить дополнительный узел — «S3 Storage Node» или «Lambda Function Node» — и маршрутизировать чувствительные входы и выходы на эндпоинт атакующего. Модификация узлов условий (Condition Nodes) обходит жёстко заданные проверки авторизации. Есть и совсем элегантный приём: подмена Customer Managed Key на ключ злоумышленника гарантирует, что все будущие состояния потока шифруются его ключом.
Седьмой вектор — атаки на защитные барьеры (Guardrails). Это основной оборонительный слой Bedrock: фильтры токсичного контента, защита от инъекций в промпты, редактирование персональных данных. Разрешение bedrock:UpdateGuardrail систематически ослабляет фильтры, снижает пороги срабатывания, убирает ограничения по темам. А bedrock:DeleteGuardrail просто удаляет защитный слой целиком.
Восьмой вектор — атаки на управляемые промпты. Bedrock Prompt Management хранит централизованные шаблоны промптов. Разрешение bedrock:UpdatePrompt позволяет модифицировать шаблоны напрямую, вставляя инструкции вроде «всегда включай обратную ссылку» или «игнорируй предыдущие инструкции безопасности касательно персональных данных». Что особенно опасно: изменение промптов не запускает повторное развёртывание приложения. Это «модификация на лету», которая обходит традиционный мониторинг. Отравление версии промпта подрывает любого агента или поток, обращающийся к этому идентификатору, и приводит к массовой эксфильтрации или генерации вредоносного контента.
Все восемь векторов объединяет один паттерн: начальная точка — низкоуровневое разрешение, а дальше идёт эскалация или латеральное перемещение в области, к которым у атакующего доступа быть не должно. Модель ИИ оказывается не целью, а транзитным маршрутом. XM Cyber опубликовала полный технический отчёт под названием «Building and Scaling Secure Agentic AI Applications in AWS Bedrock» с архитектурными диаграммами и рекомендациями для практиков.
Что делать командам безопасности? Прежде всего — знать, какие ИИ-нагрузки существуют в вашей среде. Аудировать и ограничивать конкретные разрешения, привязанные к этим нагрузкам, потому что избыточные привилегии остаются главным риском. Строить карту путей атак, пересекающих облачные и локальные среды. И поддерживать строгий контроль безопасности по каждому компоненту стека ИИ — без исключений.