Bezkluczowe uwierzytelnianie nadrzędne dla bram AI API: wzorzec federacji tożsamości obciążenia

Pracownicy bramy produkcyjnej nie powinni nosić długowiecznych kluczy API wyższego szczebla, jeśli dostawca może sam uwierzytelnić obciążenie. Bezpieczniejszym wzorcem jest wymiana istniejącej tożsamości w chmurze, Kubernetes, CI lub SPIFFE na krótkotrwałe dane uwierzytelniające dostawcy, prawidłowe buforowanie tych danych uwierzytelniających i ograniczenie ich do najmniejszej użytecznej granicy autoryzacji.

Trudną częścią nie jest wymiana tokenów. Obsługuje nierówną obsługę dostawców, równoczesne odświeżanie, mapowanie tożsamości, wyjątki w płaszczyźnie kontrolnej, awarie i migrację bez tworzenia ukrytego powrotu do szeroko uprzywilejowanego klucza współdzielonego.

Zacznij od możliwości uwierzytelniania, a nie od globalnych ustawień systemu bezkluczykowego

Fakt: Obsługa uwierzytelniania różni się w zależności od dostawcy i operacji. OpenAI i Anthropic obsługują federację tożsamości obciążeń dla API obciążeń. Platforma Azure OpenAI obsługuje identyfikator Microsoft Entra ID i tożsamości zarządzane. Google Chmura obsługuje dołączone konta usług, domyślne poświadczenia aplikacji i federację Workload Identity Federation w przypadku obciążeń zewnętrznych. Jednak wnioskowanie w czasie wykonywania i administracyjne interfejsy API niekoniecznie akceptują te same typy danych uwierzytelniających.

Na przykład OpenAI tokeny tożsamości obciążenia nie mogą obecnie wywoływać punktów końcowych administratora API. Dlatego brama nie może bezpiecznie reprezentować uwierzytelniania w postaci jednego pola na poziomie dostawcy, takiego jak auth_mode: federated.

Zalecenie: Zbuduj macierz możliwości opartą na koncie dostawcy, rodzinie punktów końcowych, środowisku i klasie operacji:

Zapisz tę macierz jako konfigurację wersjonowaną. Dopuszczenie trasy powinno odrzucić operację, gdy jej skonfigurowana tożsamość nie może spełnić wymaganych możliwości uwierzytelniania. Należy to do płaszczyzny kontroli AI API dla zespołów programistów, a nie do nieudokumentowanych zmiennych środowiskowych poszczególnych pracowników.

Umieść brokera danych uwierzytelniających pomiędzy adapterami routingu i dostawców

Adaptery dostawców nie powinny pobierać poświadczeń metadanych, konstruować asercji ani niezależnie zarządzać odświeżaniem tokenów. Przedstaw brokera danych uwierzytelniających z jednym wąskim interfejsem:

Credential acquire(CredentialRequest request)

CredentialRequest {
  provider_account_id
  workload_identity_id
  operation_class
  target_service_account
  audience
  scopes
}

Credential {
  value
  expires_at
  authorization_context
  provenance
}

Wartość danych uwierzytelniających jest poufna i musi pozostać w pamięci lub zatwierdzonej tymczasowej pamięci podręcznej. Kontekst autoryzacji rejestruje projekt dostawcy, konto usługi, zakresy, role lub ograniczenia wdrożenia reprezentowane przez token. Pochodzenie określa sposób nabycia, np. oidc_exchange, managed_identity, adc lub break_glass.

Ta umowa zapewnia neutralność routingu w stosunku do dostawcy, zachowując jednocześnie szczegóły potrzebne do kontroli autoryzacji i telemetrii. Zapobiega także traktowaniu przez wielomodelową API bramę dla zespołów każdego tokenu okaziciela jako wymiennego.

Użyj adapterów akwizycji specyficznych dla dostawcy

Każdy adapter pozyskiwania powinien wykonywać tylko czynności wymagane przez jego dostawcę:

• Uzyskaj zewnętrzne potwierdzenie z lokalnego źródła tożsamości, takie jak przewidywany token konta usługi Kubernetes, usługa metadanych w chmurze lub obciążenie SPIFFE API.
• Zażądaj dokładnej liczby odbiorców oczekiwanej przez dostawcę lub skonfigurowaną regułę federacji.
• Wymień potwierdzenie, gdy dostawca wymaga wymiany tokenu.
• Zwróć wynik czas wygaśnięcia danych uwierzytelniających i autorytatywnych.
• Klasuj awarie jako błędy lokalnej tożsamości, wymiany, autoryzacji, konfiguracji lub dostępności dostawcy.

Punkt końcowy Vertex AI zgodny z OpenAI jest użytecznym przykładem separacji: aplikacja może uzyskać token dostępu Google poprzez domyślne poświadczenia aplikacji i dostarczyć ten token jako poświadczenie klienta OpenAI. Adapter protokołu pozostaje kompatybilny z OpenAI, a pozyskiwanie danych uwierzytelniających pozostaje specyficzne dla Google.

Włącz obsługę autoryzacji pamięci podręcznej tokenów

Fakt: Poświadczenia federacyjne są krótkotrwałe. OpenAI Tokeny dostępu do tożsamości obciążenia roboczego trwają nie dłużej niż godzinę, nie mogą przetrwać zewnętrznego tokena podmiotu ani zweryfikowanego certyfikatu i są wydawane bez tokenów odświeżania. Obciążenie musi powtórzyć wymianę przed wygaśnięciem.

Klucz pamięci podręcznej musi zawierać każdy wymiar, który może zmienić wynikowe uprawnienia:

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

Pominięcie konta docelowego, odbiorców lub zakresów może spowodować, że pracownik ponownie użyje prawidłowego tokena w niewłaściwym kontekście autoryzacji. To jest bardziej niebezpieczne niż chybienie w skrytce.

Odśwież przed wygaśnięciem, korzystając z marginesu bezpieczeństwa i losowego wahania. Jedna z praktycznych zasad to:

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

Dokładny margines powinien uwzględniać przesunięcie zegara, opóźnienie wymiany, czas ponownej próby i najdłuższy oczekiwany żądanie. Nie odświeżaj wyłącznie przy ustalonym zegarze odłączonym od expires_at.

Zapobiegaj burzom wymiany dzięki odświeżeniu w ramach jednego lotu

Kiedy wiele żądań napotyka ten sam token, który wkrótce wygaśnie, wymianę powinno przeprowadzić tylko jedno wykonanie. Inni dzwoniący powinni nadal korzystać z istniejących danych uwierzytelniających, dopóki pozostają one w dozwolonym oknie, lub poczekać krótko na udostępniony wynik odświeżenia.

Użyj jednorazowej blokady dla każdego klucza pamięci podręcznej. W przypadku wdrożenia wieloprocesowego lub wielowęzłowego należy zdecydować, czy każdy proces roboczy może utrzymywać własną pamięć podręczną, czy też należy rozprowadzić koordynację odświeżania. Lokalna pamięć podręczna jest prostsza, ale zwiększa wolumen wymiany. Rozproszona pamięć podręczna ogranicza wymianę, ale rozszerza granicę wrażliwych tokenów i wymaga szyfrowanego transportu, ścisłej kontroli dostępu i ostrożnej eksmisji.

Zalecenie: Preferuj wewnętrzne pamięci podręczne, chyba że ograniczenia dostawcy lub wielkość floty wskazują na potrzebę korzystania z usługi współdzielonego tokena. Najpierw koordynuj odświeżanie w ramach każdego procesu, a następnie mierz wielkość wymiany.

Powiąż tożsamości z dokładnymi żądaniami dotyczącymi obciążenia

Federacja przenosi zaufanie z przechowywanego klucza na oświadczenia dotyczące tożsamości. Mapowanie zezwalające może być zatem równie niebezpieczne jak wyciek udostępnionych danych uwierzytelniających.

Zweryfikuj wydawcę i zamierzoną grupę odbiorców, a następnie powiąż mapowanie z niezmiennymi lub ściśle kontrolowanymi oświadczeniami. W przypadku Kubernetes uwzględnij przestrzeń nazw i konto usługi, zamiast ufać jakiemukolwiek obciążeniu w klastrze. W przypadku CI ogranicz repozytorium, przepływ pracy, środowisko i chronioną gałąź lub kontekst wdrożenia. W przypadku tożsamości w chmurze mapuj konkretny podmiot główny obciążenia, a nie całą dzierżawę lub organizację.

Utwórz osobne konta usług nadrzędnych lub tożsamości zarządzane na potrzeby produkcji, przemieszczania, zadań w tle i automatyzacji administracyjnej. Ogranicz każdą tożsamość do potrzebnych modeli, projektów, obszarów roboczych, wdrożeń i API operacji.

Fakt: OpenAI może ograniczać mapowanie tożsamości zadań za pomocą uprawnień API. Anthropic kojarzy wymienione poświadczenia z kontem usługi i ostrzega, że ​​federacja jest tak bezpieczna, jak konfiguracja tożsamości nadrzędnej. Tożsamości zarządzane i uprawnienia w chmurze w podobny sposób zależą od prawidłowo przypisanych ról.

Oddziel dane wykonawcze od danych administracyjnych

Proces roboczy wnioskowania nigdy nie powinien dziedziczyć tokenu administratora organizacji tylko dlatego, że jakieś zadanie na płaszczyźnie sterującej nadal go potrzebuje. Podziel system na dwie granice bezpieczeństwa:

• Płaszczyzna uruchomieniowa: Obsługuje żądania modelu i odbiera tylko poświadczenia stowarzyszone lub zarządzane w zakresie wnioskowania.
• Płaszczyzna kontroli: Wykonuje administrację projektami, obszarami roboczymi, rozliczeniami lub kontami usług poprzez izolowane zadania z oddzielnie przechowywanymi poświadczeniami i silniejszą kontrolą zatwierdzania.

Poświadczenia administracyjne nie powinny mieć ścieżki do zmiennych środowiskowych środowiska wykonawczego, specyfikacji podów, pakietów debugowania ani pamięci podręcznych tokenów. Rejestruj ich użycie w tym samym systemie audytu z możliwością dołączenia, który jest używany do zmian konfiguracji.

Awaria zamknięta bez konieczności improwizowania odzyskiwania

Zalecenie: Nie zastępuj automatycznie nieudanej wymiany federacyjnej wspólnym kluczem statycznym. Automatyczne przywracanie może ominąć odwołane mapowanie, ukryć nieprawidłowych odbiorców lub przywrócić dostęp, który administrator tożsamości celowo usunął.

Zwróć tajny błąd uwierzytelniania nadrzędnego, zatrzymaj wysyłanie do konta dostawcy, którego to dotyczy, i zezwól na normalne zasady routingu na wybranie innego dostawcy tylko wtedy, gdy ta alternatywa jest dozwolona dla dzierżawcy i obciążenia. Rezerwa modelu i rezerwa danych uwierzytelniających to różne decyzje.

Klucz typu break-glass może być nadal uzasadniony w przypadku poważnych awarii dostawcy tożsamości. Niech będzie wyłączony lub niedostępny podczas normalnej pracy. Aktywacja powinna wymagać uwierzytelnionej zgody, mieć ustaloną datę wygaśnięcia, ograniczać konto dostawcy i operacje, których to dotyczy, oraz powiadamiać o każdym złożonym za jego pośrednictwem żądaniu. Jego pochodzenie musi być widoczne w telemetrii żądania.

Migruj jedną pulę routingu na raz

1. Poświadczenia wykonawcze i administracyjne dotyczące zasobów reklamowych. Zidentyfikuj, które procesy mogą odczytać każdy z nich.
2. Utwórz dedykowaną tożsamość obciążenia i konto usługi dostawcy o wąskim zakresie.
3. Skonfiguruj dokładne mapowania wystawców, odbiorców, tematów i uprawnień.
4. Dodaj kontrolę wstępną, która pozyskuje token i wywołuje dozwolony punkt końcowy o niewielkim wpływie.
5. Udostępnij małą pulę routingu wyłącznie przy użyciu federacji. Nie zostawiaj włączonego automatycznego przywracania klucza podczas testu.
6. Porównaj błędy uwierzytelnienia, opóźnienia wymiany, wiek tokena i wyniki autoryzacji dostawcy z istniejącą ścieżką.
7. Zwiększaj stopniowo ruch i obserwuj co najmniej jeden pełny cykl odświeżania tokena.
8. Usuń stary klucz z dostępu w czasie wykonywania, a następnie unieważnij go po zdefiniowanym okresie obserwacji.

Powtórz ten proces dla każdego konta dostawcy i środowiska. Globalne przejście utrudnia odróżnienie błędu mapowania tożsamości od zachowania tokena specyficznego dla dostawcy.

Oprzyrząduj i przetestuj tryby awarii

Rejestruj opóźnienia wymiany tokenów, próby odświeżenia, niepowodzenia odświeżania, wiek danych uwierzytelniających, wystawcę, mapowanego podmiotu zabezpieczeń, konto dostawcy, klasę operacji i kategorię błędu uwierzytelniania. Nigdy nie zapisuj tokenów dostępu, potwierdzeń zewnętrznych, kluczy tajnych klienta ani pełnych nagłówków autoryzacji.

Zanim federacja stanie się jedyną ścieżką produkcyjną, przetestuj:

• Przesunięcie zegara między procesami roboczymi, dostawcami tożsamości i usługami tokenów dostawcy.
• Niedostępność serwera metadanych lub punktu końcowego tożsamości obciążenia.
• Wygasłe potwierdzenia i nieprawidłowi odbiorcy.
• Usunięcie roli i wyłączenie reguły federacyjnej.
• Ograniczenie wymiany tokenów i tymczasowy dostawca błędy.
• Wspólne odświeżanie w godzinach szczytu.
• Rotacja kluczy podpisujących, dopóki stare tokeny pozostają ważne.

W przypadku rotacji wydawców OIDC publikuj stare i nowe klucze podpisujące z wystarczającym pokryciem dla pamięci podręcznych weryfikatorów i wydanych tokenów. OpenAI dokumentuje 600-sekundowe buforowanie na potrzeby wykrywania i zdalnych danych JWKS, z odświeżeniem JWKS, gdy token odwołuje się do nieznanego identyfikatora klucza. Nie zakładaj, że każdy weryfikator zachowuje się identycznie; przetestuj rotację z żywymi kanarkami.

Zastosuj uwierzytelnianie bezkluczowe w środowisku wykonawczym jako migrację ograniczoną

Celem nie jest twierdzenie, że brama nie kryje żadnych tajemnic. Ma na celu usunięcie długotrwałych kluczy dostawców z masowych procesów wykonawczych i ograniczenie nieuniknionych poświadczeń administracyjnych do mniejszej granicy płaszczyzny kontrolnej.

Zacznij od macierzy możliwości, poświadczeń brokera za pośrednictwem jednego interfejsu, buforuj według kontekstu autoryzacji, używaj dokładnych mapowań tożsamości i zamykaj w przypadku błędów wymiany. Zakończ migrację dopiero po zaobserwowaniu pomyślnych testów odświeżania, unieważniania, przestoju i rotacji klucza podpisującego. Tworzy to bezkluczową ścieżkę środowiska wykonawczego, której dostępność i zachowanie autoryzacji są rozumiane, a nie zakładane.

Powiązane lektury

• weryfikacja danych uwierzytelniających dostawcy przed skierowaniem ruchu produkcyjnego