Luka w kontroli dostępu Amazon Bedrock mogła umożliwiać nieautoryzowany dostęp do modeli AI

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Amazon Bedrock to zarządzana usługa AWS umożliwiająca korzystanie z modeli generatywnej sztucznej inteligencji za pośrednictwem zunifikowanego API. W praktyce bezpieczeństwo tej platformy nie sprowadza się wyłącznie do ochrony danych, lecz także do ścisłej kontroli tego, kto może aktywować i wykorzystywać określone modele. Opisana przez badaczy luka dotyczyła mechanizmu egzekwowania polityk IAM powiązanych z subskrypcją modeli i mogła prowadzić do obejścia zamierzonych ograniczeń dostępu.

W skrócie

Badacze wykazali problem w interpretacji ograniczeń opartych o warunek aws-marketplace:ProductId używany przy akcji aws-marketplace:Subscribe. W efekcie część modeli mogła być błędnie dopuszczana lub blokowana w sposób niezgodny z intencją administratora. Taka sytuacja stwarzała ryzyko nieautoryzowanego włączenia modeli, naruszenia zasad zgodności, wzrostu kosztów oraz użycia usług AI, które nie zostały formalnie dopuszczone w organizacji.

Kontekst / historia

Kontrola dostępu do modeli w Amazon Bedrock była historycznie powiązana nie tylko z samą usługą Bedrock, ale również z mechanizmami AWS Marketplace. W starszym modelu działania aktywacja niektórych modeli wymagała subskrypcji realizowanej w tle, a ograniczenia mogły być wymuszane przez polityki IAM wskazujące dozwolone lub zabronione identyfikatory produktów.

Badacze z TrustOnCloud opisali niespójność w tym mechanizmie, wskazując, że warunek aws-marketplace:ProductId nie działał poprawnie dla wszystkich identyfikatorów produktów. Publiczne informacje sugerują, że problem został potwierdzony i usunięty przez AWS, a dotknięci klienci zostali poinformowani o incydencie.

Sprawa wpisuje się w szerszy trend analiz bezpieczeństwa usług chmurowych, w których pojedyncza operacja biznesowa zależy od kilku usług, procesów provisioningowych i warstw autoryzacji. W przypadku platform AI ma to szczególne znaczenie, ponieważ dostęp do modelu oznacza jednocześnie możliwość jego użycia, potencjalne zobowiązania licencyjne oraz wymierne koszty operacyjne.

Analiza techniczna

Sedno problemu dotyczyło relacji między Amazon Bedrock a AWS Marketplace. Aktywacja modelu mogła uruchamiać w tle operacje subskrypcyjne, generując zdarzenia związane z akceptacją umów, nadawaniem uprawnień i przygotowaniem dostępu do foundation models. Administratorzy próbowali ograniczać te działania za pomocą polityk IAM opartych na akcji aws-marketplace:Subscribe oraz warunku aws-marketplace:ProductId.

Badacze wykazali jednak, że egzekwowanie tego warunku było niespójne. Oznaczało to, że polityka typu allow lub deny nie zawsze przekładała się na rzeczywiste zachowanie platformy dla wszystkich modeli. W praktyce użytkownik posiadający odpowiedni zestaw uprawnień mógł uzyskać dostęp do modelu, który według założeń polityki powinien pozostać zablokowany.

Problem jest istotny z technicznego punktu widzenia z dwóch powodów. Po pierwsze, pokazuje, że bezpieczeństwo dostępu do modeli nie zależy wyłącznie od uprawnień z rodziny bedrock:*, ale również od towarzyszących operacji marketplace’owych. Po drugie, ujawnia ryzyko wynikające z rozproszonego modelu autoryzacji, w którym jedna czynność jest realizowana przez kilka usług działających równolegle.

Dodatkowym czynnikiem ryzyka było to, że sama aktywacja modelu mogła być inicjowana automatycznie w tle. Oznacza to, że klasyczne założenie o istnieniu jednego, w pełni skutecznego punktu kontroli dostępu nie zawsze sprawdza się w środowiskach AI opartych o usługi zarządzane.

Konsekwencje / ryzyko

Z perspektywy organizacji problem mógł prowadzić do kilku typów zagrożeń. Najbardziej oczywiste było nieautoryzowane użycie modelu, który nie został zaakceptowany przez zespoły bezpieczeństwa, compliance lub dział prawny. W wielu firmach dopuszczone modele są ściśle ograniczone ze względu na licencje, lokalizację przetwarzania danych, polityki retencji lub dopuszczalne przypadki użycia.

Drugim wymiarem były koszty. Różne modele w Bedrock są wyceniane odmiennie, więc możliwość aktywacji droższego modelu poza kontrolą administratora mogła skutkować znaczącym wzrostem wydatków. W praktyce oznacza to ryzyko nadużyć prowadzących do wysokich kosztów chmurowych, nawet jeśli nie dochodzi do klasycznego zakłócenia dostępności.

Trzecim obszarem pozostaje governance i audyt. Jeżeli organizacja zakłada, że polityka IAM skutecznie egzekwuje ograniczenia na poziomie modeli, a w rzeczywistości mechanizm działa inaczej, raportowanie zgodności może opierać się na błędnych przesłankach. Taka rozbieżność między polityką deklarowaną a realnym stanem kontroli bezpieczeństwa jest szczególnie niebezpieczna w środowiskach regulowanych.

Rekomendacje

Firmy korzystające z Amazon Bedrock powinny traktować kontrolę dostępu do modeli jako zagadnienie wielowarstwowe i regularnie testować rzeczywiste działanie polityk, a nie tylko ich zapis konfiguracyjny.

Zweryfikować wszystkie polityki IAM związane z Amazon Bedrock oraz AWS Marketplace, zwłaszcza uprawnienia dotyczące subskrypcji i aktywacji modeli.
Przeprowadzać testy autoryzacyjne dla każdego modelu dopuszczonego i niedopuszczonego, zamiast zakładać jednolite działanie polityki dla całego katalogu.
Włączyć szczegółowe monitorowanie zdarzeń związanych z aktywacją modeli, subskrypcjami Marketplace i pierwszym użyciem modeli.
Ograniczyć możliwość samodzielnej aktywacji modeli do wąskiej grupy ról administracyjnych.
Ustawić limity budżetowe, alerty kosztowe i mechanizmy wykrywania anomalii dla usług AI.
Regularnie przeglądać dokumentację AWS dotyczącą model access i zmian w sposobie udostępniania modeli.
Uwzględniać w przeglądach bezpieczeństwa nie tylko ryzyko wycieku danych, ale również ryzyko obejścia polityk i niekontrolowanego wzrostu kosztów.

Podsumowanie

Przypadek luki w Amazon Bedrock pokazuje, że bezpieczeństwo usług generatywnej AI w chmurze zależy nie tylko od ochrony danych wejściowych i wyjściowych, ale także od poprawnego egzekwowania polityk aktywacji modeli. Niespójność związana z warunkiem aws-marketplace:ProductId ujawniła, jak łatwo może dojść do rozjazdu między zamierzoną polityką IAM a rzeczywistym zachowaniem platformy.

Dla zespołów bezpieczeństwa najważniejsza lekcja jest praktyczna: kontrola dostępu do modeli AI musi być empirycznie testowana, monitorowana w logach i połączona z mechanizmami governance oraz kontroli kosztów. W środowiskach opartych o Bedrock oznacza to konieczność analizowania zależności nie tylko w samej usłudze AI, ale również w powiązanych procesach marketplace’owych i automatycznych ścieżkach aktywacji.