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