Klucze AWS Bedrock są teraz chronione przez wewnętrzny gateway LLM, który pozwala każdemu zespołowi w firmie fintech wywoływać modele, przy czym każde żądanie jest powiązane z budżetem tokenów przypisanym do danego zespołu. Ta zmiana kładzie kres praktyce rozpraszania poświadczeń IAM w repozytoriach i notatnikach – nawykowi, który już wcześniej groził wyczerpaniem budżetu firmy na AI w ciągu jednego popołudnia.

Dlaczego rozdawanie kluczy AWS szybko zamienia się w chaos

Grupy nietechniczne w organizacji prosiły o bezpośredni dostęp do modeli językowych firmy. Na papierze najprostszym rozwiązaniem było włączenie modeli w AWS i przyznanie każdej grupie uprawnień IAM. Dziesięć minut pracy, kilka edycji polityk i zadanie wykonane – przynajmniej w teorii.

W praktyce rozdawanie poświadczeń IAM generuje trzy ukryte koszty:

  • Rozproszenie poświadczeń (Credential sprawl) – Klucze trafiają do plików .env, potoków CI, notatników Jupyter i skryptów ad-hoc. Każda kopia staje się punktem awarii, gdy wymagana jest rotacja.
  • Brak widoczności – Pojedynczy współdzielony klucz nie daje żadnej wskazówki, który zespół lub który fragment kodu generuje użycie. Gdy uruchomi się niekontrolowana pętla, cały budżet może zostać wyczerpany, zanim ktokolwiek to zauważy.
  • Narzut operacyjny – Śledzenie, kto ma jakie uprawnienia, cofanie dostępu i audytowanie użycia szybko zmienia się w proces manualny i podatny na błędy.

Zespół fintech zdał sobie sprawę, że „szybka poprawka” wkrótce stanie się koszmarem pod względem bezpieczeństwa i kosztów.

Zamiast tego zbudowano gateway typu reverse-proxy

Rozwiązaniem było umieszczenie lekkiego reverse proxy między każdą wewnętrzną aplikacją a AWS Bedrock. Proxy przechowuje rzeczywiste poświadczenia AWS w jednym, zabezpieczonym sejfie (vault) i wystawia krótkotrwałe, czytelne dla człowieka tokeny (na przykład lllkey_9f3c) dla wywołujących.

Kluczowe założenia projektowe:

  • Żadne poświadczenia AWS nie opuszczają gatewaya – Deweloperzy i usługi nigdy nie widzą rzeczywistych kluczy IAM.
  • Egzekwowanie polityk na poziomie tokena – Każdy token może być ograniczony do konkretnej rodziny modeli lub maksymalnej liczby tokenów.
  • Pełna ścieżka audytu – Każde żądanie jest logowane wraz z nazwą.

Jak gateway przetwarza żądanie

  1. Odbiór tokena – Klient dołącza swój token llmkey_… w nagłówku HTTP.
  2. Walidacja tokena – Gateway sprawdza status tokena (aktywny, nie wygasł) oraz czy żądanie mieści się w przydzielonym budżecie.
  3. Biała lista modeli – Potwierdza, czy żądany model jest dozwolony dla danego tokena.
  4. Przekazanie do Bedrock – Żądanie jest wysyłane do AWS przy użyciu zapisanych poświadczeń IAM.
  5. Logowanie i rozliczanie – Użycie tokena, nazwa modelu i szacowany koszt są zapisywane w centralnej bazie danych w celach raportowych.

Ponieważ firma fintech musi trzymać wszystkie dane wewnątrz własnej sieci, oferta SaaS od zewnętrznego dostawcy nie wchodziła w grę.

Co zyskała firma

  • Kontrola modeli – Zespoły, które potrzebują jedynie taniego modelu, mogą zostać do niego ograniczone, co zapobiega przypadkowemu użyciu drogich wariantów o większej wydajności.
  • Ochrona budżetu – Tokeny mają sztywny limit tokenów. Po osiągnięciu limitu gateway zwraca błąd zamiast po cichu zużywać kolejne środki.
  • Przypisanie kosztów dla działu finansowego – Pulpit nawigacyjny zbudowany na logach użycia pokazuje dokładnie, który zespół lub usługa wydał ile na AI, zmieniając niejasny arkusz kalkulacyjny w przejrzysty raport.

Zmienił się również przepływ pracy (workflow). Brak nowych polityk IAM, brak rotacji sekretów i brak ryzyka wycieku kluczy do kontroli wersji.

Kontrargument: dlaczego nie użyć usługi zarządzanej

Częstym zarzutem jest to, że budowa własnego gatewaya zwiększa nakład pracy inżynieryjnej i koszty utrzymania. W przypadku fintechu konieczność utrzymania całego ruchu AI i danych o użyciu za korporacyjnym firewallem przeważyła nad wygodą rozwiązania zewnętrznego. Wewnętrzne proxy wymagało weekendu pracy programistycznej, ale wyeliminowało miesiące czyszczenia poświadczeń i przekroczeń budżetu, które nastąpiłyby przy naiwnym podejściu do dystrybucji kluczy.

Wnioski

Rozdawanie kluczy AWS Bedrock to droga na skróty, która szybko zamienia się w koszmar bezpieczeństwa i budżetowania. Skromny gateway typu reverse-proxy — zbudowany w jeden weekend — centralizuje poświadczenia, egzekwuje limity dla zespołów i zapewnia ścieżkę audytu niezbędną dla działu finansowego. Dla każdej organizacji, która chce pozwolić wielu grupom eksperymentować z LLM bez utraty kontroli, podejście oparte na gatewayu zwraca się dzięki unikniętym incydentom i większej przejrzystości wydatków.