Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
AWS Bedrock jest platformą do budowy aplikacji opartych na modelach foundation models, agentach AI, bazach wiedzy, przepływach orkiestracji i mechanizmach ochronnych. Jej siłą jest ścisła integracja z danymi przedsiębiorstwa oraz usługami chmurowymi, ale właśnie ta rozbudowana łączność tworzy nową, złożoną powierzchnię ataku.
W praktyce zagrożenie nie ogranicza się do samego modelu językowego. Ryzyko obejmuje cały ekosystem: uprawnienia IAM, konektory do źródeł danych, logowanie interakcji, funkcje wykonawcze, szablony promptów, guardrails oraz komponenty odpowiedzialne za przetwarzanie i przechowywanie danych.
W skrócie
Badacze bezpieczeństwa opisali osiem wektorów ataku w AWS Bedrock, które mogą umożliwić przejęcie kontroli nad środowiskiem generatywnej AI. Scenariusze te obejmują m.in. manipulację logami, kompromitację baz wiedzy, przejęcie agentów, modyfikację przepływów, osłabienie guardrails i zatrucie współdzielonych promptów.
- ataki na logowanie promptów i odpowiedzi modeli,
- kompromitacja źródeł danych oraz magazynów wiedzy,
- przejęcie agentów i ich komponentów wykonawczych,
- manipulacja przepływami orkiestracji,
- osłabienie mechanizmów ochronnych,
- trwałe prompt poisoning w wielu aplikacjach jednocześnie.
Kontekst / historia
Rozwój architektur RAG, agentów AI i integracji modeli z systemami biznesowymi zmienił sposób patrzenia na bezpieczeństwo. Klasyczne zabezpieczanie pojedynczego interfejsu API czy aplikacji webowej przestaje wystarczać, ponieważ nowoczesne wdrożenia AI obejmują wiele powiązanych usług i zależności.
Środowiska tego typu korzystają z bucketów S3, sekretów, baz wektorowych, funkcji Lambda, repozytoriów dokumentów, konektorów SaaS i mechanizmów filtrowania treści. W efekcie nawet pozornie ograniczone uprawnienie może stać się punktem wyjścia do eskalacji dostępu, eksfiltracji danych lub obejścia zabezpieczeń.
To oznacza, że atakujący nie musi łamać samego modelu. Często wystarczy modyfikacja konfiguracji otaczającej model, aby wpłynąć na jego zachowanie, przejąć dane lub wykorzystać integracje do dalszego ruchu bocznego w infrastrukturze organizacji.
Analiza techniczna
Pierwsza grupa scenariuszy dotyczy logów wywołań modeli. Jeśli prompty i odpowiedzi są zapisywane do S3 lub systemów logowania, osoba z dostępem do odczytu może pozyskać dane poufne. Jeszcze groźniejsza jest możliwość przekierowania logowania na zasób kontrolowany przez napastnika, co zamienia mechanizm audytowy w kanał cichej eksfiltracji.
Drugi obszar obejmuje bazy wiedzy Bedrock i ich źródła danych. W modelu RAG źródłem mogą być systemy takie jak S3, SharePoint, Salesforce czy Confluence. Uzyskanie dostępu do tych źródeł pozwala ominąć warstwę AI i pobrać surowe dane bezpośrednio z zaplecza informacyjnego organizacji.
Trzeci wektor dotyczy magazynów danych wykorzystywanych po ingestii, takich jak bazy wektorowe i systemy relacyjne. Jeśli napastnik uzyska dostęp do endpointów, kluczy API lub sekretów integracyjnych, może modyfikować indeksy, usuwać dane albo przygotować zatrucie wiedzy wpływające na odpowiedzi generowane przez model.
Czwarta grupa ataków skupia się na agentach. Uprawnienia do tworzenia lub aktualizacji agenta umożliwiają zmianę promptu bazowego, a tym samym przejęcie kontroli nad logiką działania. Może to prowadzić do ujawnienia instrukcji wewnętrznych, manipulacji zadaniami i wykonywania działań niezgodnych z założeniami projektu.
Piąty scenariusz obejmuje ataki pośrednie przez infrastrukturę zależną, zwłaszcza funkcje Lambda. Zamiast modyfikować samego agenta, napastnik zmienia kod funkcji lub warstwę zależności, z której korzysta agent. Taka ingerencja może zostać przeoczona, a mimo to skutkować eksfiltracją danych lub wykonywaniem nieautoryzowanych operacji.
Szósty obszar to przepływy Bedrock, które definiują sekwencje przetwarzania, warunki biznesowe i połączenia między komponentami. Uprawnienia do ich aktualizacji umożliwiają wstrzyknięcie dodatkowych węzłów zapisujących dane, przekierowujących ruch lub zmieniających logikę autoryzacji. Ryzyko rośnie także wtedy, gdy możliwa jest podmiana klucza szyfrującego na taki, do którego napastnik posiada dostęp.
Siódmy wektor obejmuje guardrails, czyli mechanizmy ograniczające szkodliwe treści, wspierające redakcję danych wrażliwych i utrudniające prompt injection. Ich osłabienie lub usunięcie zwiększa podatność modelu na manipulację i odbiera organizacji jedną z ostatnich warstw ochrony.
Ósmy scenariusz dotyczy zarządzanych promptów współdzielonych przez wiele aplikacji, agentów i przepływów. Ich modyfikacja pozwala zmienić zachowanie całego środowiska bez wdrażania nowej wersji aplikacji. To otwiera drogę do trwałego prompt poisoning, masowej eksfiltracji danych i ukrytego wpływania na wiele komponentów jednocześnie.
Konsekwencje / ryzyko
Najważniejszą konsekwencją opisanych scenariuszy jest przesunięcie ciężaru bezpieczeństwa z samego modelu na jego otoczenie operacyjne. Nawet dobrze chroniony model może stać się narzędziem ataku, jeśli jego integracje mają zbyt szerokie uprawnienia lub są słabo monitorowane.
Ryzyko obejmuje wyciek danych z promptów, logów i baz wiedzy, przejęcie sekretów integracyjnych, manipulowanie odpowiedziami modeli, osłabienie ochrony przed prompt injection oraz trwałe skażenie konfiguracji wykorzystywanej w wielu aplikacjach jednocześnie.
W organizacjach korporacyjnych i hybrydowych skutkiem może być także lateral movement z warstwy AI do systemów SaaS, baz danych, usług chmurowych, narzędzi automatyzacji, a nawet zasobów lokalnych. Szczególnie niebezpieczne jest to, że część zmian konfiguracyjnych może przez długi czas pozostać niezauważona.
Rekomendacje
Podstawą ochrony powinno być ścisłe stosowanie zasady najmniejszych uprawnień. Role wykorzystywane przez agentów, przepływy, bazy wiedzy i mechanizmy logowania muszą mieć wyłącznie minimalny zakres dostępu potrzebny do realizacji konkretnego zadania.
Równie ważne jest rozdzielenie uprawnień administracyjnych od operacyjnych. Modyfikacja promptów, guardrails, agentów, konektorów, logowania oraz przepływów powinna podlegać pełnemu audytowi, kontroli zmian i zatwierdzaniu przez więcej niż jedną osobę.
- inwentaryzacja wszystkich komponentów Bedrock i ich zależności,
- monitorowanie zmian w agentach, promptach, flows i guardrails,
- kontrola dostępu do sekretów, kluczy KMS i parametrów integracyjnych,
- wersjonowanie konfiguracji i kontrola integralności promptów,
- monitorowanie aktualizacji funkcji Lambda oraz warstw zależności,
- regularne testy odporności na prompt poisoning i nadużycia w łańcuchu wykonawczym.
Organizacje powinny również przyjąć podejście całościowe i traktować platformy generatywnej AI jak krytyczny element infrastruktury, a nie jedynie narzędzie aplikacyjne. Dopiero połączenie kontroli IAM, audytu zmian, ochrony danych i testów bezpieczeństwa daje realną odporność na opisane scenariusze.
Podsumowanie
Osiem opisanych wektorów ataku pokazuje, że bezpieczeństwo AWS Bedrock nie kończy się na modelu językowym. Najpoważniejsze zagrożenia wynikają z integracji modeli z danymi, narzędziami, logiką biznesową i usługami chmurowymi przedsiębiorstwa.
Dla zespołów bezpieczeństwa oznacza to konieczność monitorowania całego ekosystemu AI: od logów i źródeł danych, przez agentów i przepływy, po guardrails, prompty i funkcje wykonawcze. W praktyce to właśnie bezpieczeństwo otoczenia operacyjnego zdecyduje o realnej odporności wdrożeń generatywnej AI.
Źródła
- We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them — https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html
- Amazon Bedrock Documentation — https://docs.aws.amazon.com/bedrock/
- AWS Identity and Access Management Documentation — https://docs.aws.amazon.com/iam/
- AWS Lambda Documentation — https://docs.aws.amazon.com/lambda/
- AWS Key Management Service Documentation — https://docs.aws.amazon.com/kms/