AWS Bedrock стал одной из ключевых платформ для построения корпоративных AI-приложений: он предоставляет доступ к foundation-моделям и позволяет напрямую подключать их к данным и бизнес‑системам. Именно эта глубокая интеграция делает Bedrock не только мощным инструментом, но и привлекательной целью для атак. Исследователи XM Cyber проанализировали стек AWS Bedrock и выделили восемь практических векторов атак, показывающих, как злоумышленник может начать с минимальных прав и закончить доступом к критическим активам компании.
Как AWS Bedrock превращается в узел инфраструктуры атак
При интеграции Bedrock‑агентов с Salesforce, Lambda‑функциями, SharePoint, базами знаний и внутренними API, каждый агент фактически становится узлом инфраструктуры с собственными правами доступа, сетевой достижимостью и путями к облачным и локальным системам. По данным отраслевых отчётов, именно неправильно настроенные разрешения и «избыточные» IAM‑права остаются одной из главных причин компрометаций в облаке. Bedrock не исключение: вектор атаки чаще всего лежит не в самой модели, а в том, что к ней «подвешено».
Векторы 1–2: манипуляции журналами Bedrock и сокрытие активности
По умолчанию Bedrock логирует каждое обращение к модели в S3 или CloudWatch для аудита и соответствия требованиям. Это создает дополнительную, часто недооценённую поверхность атаки. Злоумышленник, обладающий доступом к S3‑бакету с логами (например, через s3:GetObject), может пассивно собирать промпты и ответы, включая конфиденциальные данные пользователей и фрагменты внутренней логики приложений.
Если прямое чтение логов недоступно, атакующий может использовать право bedrock:PutModelInvocationLoggingConfiguration, чтобы перенастроить журналирование на управляемый им S3‑бакет. С этого момента все новые запросы и ответы моделей «утекают» к атакующему незаметно для команд эксплуатации. Отдельный вариант атаки — полное скрытие следов: права s3:DeleteObject или logs:DeleteLogStream позволяют удалить журналы, уничтожив доказательства jailbreak‑промптов, эскалации привилегий и иных действий.
Векторы 3–4: компрометация Knowledge Bases и связанных хранилищ
Knowledge Bases в AWS Bedrock реализуют подход Retrieval Augmented Generation (RAG), связывая модель с корпоративными данными в S3, Salesforce, SharePoint, Confluence и других системах. Важно понимать, что эти источники доступны не только через модель: при наличии прав s3:GetObject к бакету‑источнику злоумышленник может читать «сырые» данные напрямую, обходя все фильтры и guardrails.
Больший риск связан с секретами и учётными данными интеграций. Если атакующий получает возможность извлечь и расшифровать секрет, который Bedrock использует для подключения к SaaS‑сервису (например, SharePoint), он может применить эти凭ведения для бокового смещения: перехода из облака в инфраструктуру Active Directory и другие внутренние сервисы.
После первичной загрузки данные попадают в специализированные хранилища — векторные БД (Pinecone, Redis Enterprise Cloud) или AWS‑сервисы вроде Aurora и Redshift. В ряде конфигураций уязвимым звеном оказываются именно учётные данные хранилищ. Злоумышленник с доступом к API bedrock:GetKnowledgeBase и к соответствующим секретам может извлечь объект StorageConfiguration, получить endpoint‑адреса и ключи API и, как следствие, полный административный доступ к индексам и структурированным данным Knowledge Base.
Векторы 5–6: захват Bedrock Agents и их Lambda-инфраструктуры
Bedrock Agents — это автономные оркестраторы, которые принимают запрос, планируют шаги и вызывают внешние инструменты. При наличии прав bedrock:UpdateAgent или bedrock:CreateAgent злоумышленник может изменить базовый промпт агента, вынудив его раскрыть внутренние инструкции, схемы инструментов и даже скрытые системные промпты. В сочетании с правом bedrock:CreateAgentActionGroup становится возможным добавить к легитимному агенту «злонамеренный» executor, получающий возможность создавать пользователей, модифицировать БД или вызывать чувствительные API под видом нормального AI‑процесса.
Косвенные атаки на агентов нацелены на инфраструктуру, от которой они зависят. Если агент использует AWS Lambda для выполнения действий, права lambda:UpdateFunctionCode позволяют внедрить в функцию произвольный вредоносный код. Альтернатива — lambda:PublishLayer и скрытая подмена зависимостей через слой. В обоих случаях каждый вызов инструмента становится вектором утечки данных, подмены ответов модели или генерации вредоносного контента.
Вектор 7: манипуляция Bedrock Flows и бизнес-логикой
Bedrock Flows описывают цепочку шагов, через которые проходит запрос: вызовы моделей, маршрутизация, обращения к Lambda и S3, ветвления по условиям. При наличии прав bedrock:UpdateFlow атакующий может встроить в критический сценарий «побочный» узел — например, S3 Storage Node или Lambda Function Node, который будет копировать входные и выходные данные на контролируемый им endpoint, не нарушая основной логики приложения.
Тот же доступ позволяет изменять Condition Nodes, отвечающие за проверку бизнес‑правил: можно обойти жёстко закодированные проверки авторизации и пропустить несанкционированные запросы к чувствительным backend‑системам. Дополнительный риск — подмена Customer Managed Key, связанного с потоком: если злоумышленник заменит KMS‑ключ на свой, все будущие состояния Flow будут шифроваться ключом, находящимся под его контролем.
Вектор 8: ослабление guardrails и отравление промптов
Guardrails: снятие последней линии защиты
Guardrails в AWS Bedrock отвечают за фильтрацию токсичного контента, блокировку prompt injection и маскирование персональных данных. При наличии прав bedrock:UpdateGuardrail злоумышленник может поэтапно ослаблять фильтры: снижать пороги, снимать ограничения по тематикам, отключать маскирование PII, делая модель гораздо более восприимчивой к атакующим промптам. Право bedrock:DeleteGuardrail фактически означает полное снятие этого слоя защиты.
Prompt Management: массовое отравление поведения моделей
Сервис Prompt Management централизует шаблоны промптов, которые используют разные приложения и модели. Доступ bedrock:UpdatePrompt открывает возможность точечной подмены этих шаблонов. В промпт можно внедрить инструкции вида «всегда добавляй ссылку на [домен атакующего]» или «игнорируй предыдущие указания по защите PII», причём во всех приложениях, использующих данный шаблон.
Опасность усиливает то, что обновление промпта не требует релиза приложения: изменения вступают в силу мгновенно и остаются незаметными для традиционного мониторинга. Достаточно сменить используемую версию промпта на «отравленный» вариант — и любой агент или Flow, вызывающий этот идентификатор, немедленно начинает работать в интересах атакующего, вплоть до массовой утечки данных или генерации вредоносного контента.
Практические выводы и рекомендации по защите AWS Bedrock
Все описанные векторы атак демонстрируют общий принцип: злоумышленники целятся в права доступа, конфигурацию и интеграции вокруг модели, а не в саму LLM. Один «перепривилегированный» сервисный аккаунт достаточен, чтобы перенастроить логирование, перехватить агента, отравить промпты или получить доступ к внутренним SaaS‑ и on‑prem‑системам через Bedrock.
Защита AWS Bedrock должна начинаться с инвентаризации AI‑нагрузок и строгого анализа того, какие IAM‑права выданы агентам, Flows, Lambda‑функциям и сервисным ролям. Рекомендуется применять принцип наименьших привилегий, жёстко ограничивать доступ к секретам и KMS‑ключам, отслеживать изменения конфигураций через CloudTrail, сегментировать сеть и регулярно ревьюировать все Guardrails, Prompts, Knowledge Bases и Flows на предмет несанкционированных модификаций.
Организациям стоит включить AI‑сервисы, такие как AWS Bedrock, в модели угроз наравне с традиционными облачными ресурсами, а также периодически строить и анализировать потенциальные пути атаки между облаком и локальной инфраструктурой. Чем раньше будут выявлены избыточные права и слабые места в интеграциях, тем сложнее будет злоумышленнику превратить ваши AI‑агенты в точку входа к критически важным активам.
