Magazyny danych uwierzytelniających dostawcy dla wielomodelowych bram AI: oddzielny dostęp do środowiska wykonawczego, administratora, rozliczeń i BYOK

Klucze API dalszego łańcucha i poświadczenia dostawcy wyższego szczebla rozwiązują różne problemy. Klucz programisty wydany przez bramę identyfikuje aplikację, zespół, dzierżawę, budżet i kontekst zasad. Klucz dostawcy nadrzędnego umożliwia bramie wydawanie pieniędzy i dostęp do modeli na koncie dostawcy. Traktowanie ich jako tego samego rodzaju tajemnicy powoduje, że zespoły uzyskują jeden nieograniczony klucz we współdzielonym projekcie, dane uwierzytelniające administratora w usługach wykonawczych i brak niezawodnego sposobu na określenie, który najemca spowodował daną opłatę po stronie dostawcy.

Praktyczny wzorzec to skarbiec referencji dostawcy: dedykowana płaszczyzna kontroli do importowania, klasyfikowania, przechowywania, wybierania, rotacji i kontrolowania nadrzędnych poświadczeń. Powinien znajdować się za routerem, księgą rozliczeniową, silnikiem zasad i przepływem operacji – a nie wewnątrz kodu aplikacji, plików konfiguracyjnych modelu, rekordów dzierżawców lub zdarzeń analitycznych.

Problem czytnika: dane uwierzytelniające nadrzędne stają się niewidoczną infrastrukturą

Większość wdrożeń obejmujących wiele modeli rozpoczyna się od prostego celu: skierowania jednego żądania zgodnego z OpenAI do najlepszego dostępnego dostawcy. Następnie pojawia się więcej kont: jeden projekt dostawcy do celów produkcyjnych, drugi do oceny, obszar roboczy Anthropic dla jednostki biznesowej, projekt Google Cloud dla Gemini i kilka kluczy dostarczonych przez klientów do umów BYOK.

Ryzyko nie polega jedynie na tajnym wycieku. Jest to utrata kontekstu autoryzacji. Prawidłowy klucz dostawcy może technicznie być w stanie wywołać punkt końcowy, ale brama nadal musi wiedzieć, czy ten klucz jest dozwolony dla tej dzierżawy, tej rodziny modeli, tej zasady przechowywania danych, tego budżetu, tego regionu i tej ścieżki automatyzacji.

Fakt: platformy dostawców udostępniają różne granice kont i typy danych uwierzytelniających. Dokumenty OpenAI i konta usług oraz uprawnienia klucza API konta usługi domyślnie umożliwiają dostęp do odczytu i zapisu zasobów API projektu. OpenAI udostępnia także kluczowe obiekty Admin API niezależnie od zwykłego użycia API projektu/środowiska wykonawczego. Anthropic dokumentuje obszary robocze jako granice organizacyjne i stwierdza, że ​​punkty końcowe Admin API wymagają kluczy Admin API innych niż standardowe klucze API; Anthropic zauważa również, że klucze API są powiązane z obszarem roboczym, w którym zostały utworzone i nie można ich przenosić między obszarami roboczymi. Dokumentacja klucza Google Gemini API mówi, że każdy klucz Gemini API jest powiązany z projektem Google Cloud i zaleca ograniczenia API, aby zmniejszyć szkody w przypadku naruszenia bezpieczeństwa klucza.

Zalecenie: nie twórz jednego ogólnego pola „klucz_dostawcy” i nie zamykaj go. Zbuduj spis danych uwierzytelniających, który zachowuje granice specyficzne dla dostawcy, jednocześnie udostępniając bramie znormalizowany model zasad.

Zdefiniuj taksonomię danych uwierzytelniających przed zaakceptowaniem kluczy

Sejf powinien odrzucać niejednoznaczne poświadczenia. W czasie importu operator lub przepływ pracy automatyzacji musi sklasyfikować dane uwierzytelniające. Użyj przynajmniej tych kategorii:

• Poświadczenia wnioskowania w czasie wykonywania: używane przez bramę do wywoływania punktów końcowych wnioskowania modelu, takich jak czat, odpowiedzi, osadzanie, moderowanie, transkrypcja lub generowanie obrazów, w zależności od wsparcia dostawcy.
• Poświadczenia automatyzacji administratora: używane do zarządzania organizacjami po stronie dostawcy, obszarami roboczymi, projektami, użytkownikami, kluczami lub zasobami administracyjnymi. Nie powinny one nigdy znajdować się w ścieżce żądań środowiska wykonawczego.
• Dane uwierzytelniające do rozliczeń i raportowania: używane do pobierania raportów o użyciu, fakturach, kosztach lub raportach organizacji, jeśli dostawcy obsługują te interfejsy API. Trzymaj je oddzielnie od kluczy wnioskowania, aby zadania raportowania nie mogły generować użycia modelu.
• Poświadczenia służące wyłącznie do oceny: używane w procesach testów porównawczych, kontroli jakości, migracji lub przemieszczaniu. Powinny mieć niskie limity, jasne etykiety środowiskowe i brak uprawnień do produkcji zastępczej.
• Poświadczenia klienta BYOK: klucze dostarczone przez klienta powiązane z konkretnym najemcą, kontem dostawcy, umową i zasadami dotyczącymi danych. Nie należy ich łączyć w ramach routingu współdzielonego, chyba że klient wyraźnie wyrazi na to zgodę.

Ta taksonomia to nie tylko dokumentacja. Powinien sterować przepływami pracy związanymi z kontrolą dostępu, uprawnieniami do routingu, alertami i rotacją. Jeśli dane uwierzytelniające zostaną zaimportowane bez kategorii, właściciela, granic konta dostawcy i dozwolonego użycia, powinny pozostać wyłączone.

Przechowuj tajemnice w skarbcu, a nie w rekordach produktów

Skarbiec powinien być jedynym komponentem, który może odszyfrować poświadczenia nadrzędne. Inne systemy mogą przechowywać odniesienia, skróty, pola stanu i metadane zasad, ale nie samą wartość poświadczeń.

Nie przechowuj sekretów nadrzędnych w tych miejscach

• Wiersze profilu najemcy.
• Modeluj pliki konfiguracyjne routingu.
• Wyświetlaj dzienniki monitów lub zakresy śledzenia.
• Ładunki zdarzeń Analytics.
• Zmienne CI przeznaczone dla programistów.
• Zgłoszenia do pomocy, narzędzia czatu i zrzuty ekranu.

Użytkowy projekt skarbca składa się z dwóch płaszczyzn. Tajna płaszczyzna przechowuje zaszyfrowane dane uwierzytelniające i ściśle kontroluje operacje deszyfrowania. Płaszczyzna metadanych przechowuje jawne atrybuty używane przez routing i zarządzanie. Router powinien zwykle potrzebować jedynie identyfikatora uwierzytelniającego i krótkotrwałego pobrania sekretu z pamięci w momencie wysyłki, a nie szerokiego dostępu do bazy danych dla każdego klucza dostawcy.

Chroń skarbiec jako infrastrukturę o wysokiej wartości: szyfrowanie kopert lub zarządzany KMS, ścisła tożsamość usług, procedury łamania szkła, testowanie tworzenia kopii zapasowych i przywracania, sprawdzanie dostępu i alerty w przypadku nietypowego wolumenu odszyfrowania. Skarbiec centralny upraszcza zarządzanie, ale także koncentruje ryzyko. Na tym polega kompromis.

Dołącz metadane zasad do każdego poświadczenia

Model metadanych powinien być na tyle przejrzysty, aby brama mogła zdecydować, czy dane uwierzytelniające są odpowiednie, zanim dotkną punktu końcowego dostawcy.

Praktyczny zapis referencji obejmuje:

• credential_id: wewnętrzny, niezmienny identyfikator.
• dostawca: OpenAI, Anthropic, Gemini, Azure OpenAI lub inny adapter.
• provider_account_boundary: organizacja, projekt, obszar roboczy, projekt w chmurze, subskrypcja lub odpowiednik.
• credential_class: środowisko wykonawcze, administrator, rozliczenia, ocena lub BYOK.
• środowisko: produkcja, inscenizacja, rozwój, ocena, piaskownica.
• tenant_binding: poświadczenia platformy współdzielonej, pojedynczy dzierżawca, grupa dzierżawców lub dzierżawca BYOK klienta.
• allowed_model_families: na przykład generowanie tekstu, osadzanie, wizja, obraz, dźwięk lub profile konkretnych modeli.
• allowed_endpoints: znormalizowane możliwości bramy mapowane na punkty końcowe dostawcy.
• data_policy: dozwolona klasa przechowywania, klasa rejestrowania, wymagania dotyczące miejsca zamieszkania i ograniczenia funkcji.
• budget_scope: centrum kosztów, klient-sprzedawca, dział wewnętrzny lub umowa.
• właściciel: wyznaczony zespół lub osoba odpowiedzialna.
• utworzono_o, wygasa_o, rotacja_due_o, ostatnio_użyte_o.
• health_status: nieznany, zdrowy, zdegradowany, nieautoryzowany, quota_exhausted, wyłączony.
• emergency_disable: natychmiastowa blokada routingu niezależna od normalnego stanu zasad.

Zachowaj ten model jako neutralny wobec dostawcy, ale nie wymazuj rzeczywistości dostawcy. Klucza Anthropic powiązanego z obszarem roboczym i klucza Gemini powiązanego z projektem Google Cloud nie można stosować zamiennie tylko dlatego, że oba mogą generować tekst. Brama potrzebuje tego pochodzenia do celów audytów, obciążeń zwrotnych i bezpiecznego przełączania awaryjnego.

Oddzielny dostęp do środowiska wykonawczego, administratora i rozliczeń

Najważniejsza zasada jest prosta: klucz używany do wnioskowania w czasie wykonywania nie powinien zarządzać organizacjami dostawców, obszarami roboczymi, użytkownikami, projektami ani zasobami administracyjnymi.

Ruch w czasie wykonywania charakteryzuje się dużym natężeniem i jest eksponowany na największej powierzchni operacyjnej. Przechodzi przez routery żądań, logikę ponawiania prób, procedury obsługi przesyłania strumieniowego, adaptery modeli i przepływy pracy incydentów. Poświadczenia administratora mają niską częstotliwość i duży wpływ. Powinny podlegać oddzielnej ścieżce zatwierdzania z krótkimi czasami TTL, w stosownych przypadkach nazywanej zatwierdzaniem przez człowieka, silnym rejestrowaniem i brakiem uprawnień do routingu w czasie wykonywania.

Dane uwierzytelniające również zasługują na oddzielenie. Zadanie raportowania uzgadniające faktury nie powinno umożliwiać generowania uzupełnień, a klucz wnioskowania środowiska wykonawczego nie powinien być jedynym sposobem pobierania raportów użycia. Jeśli dostawca nie oferuje szczegółowej separacji, zrekompensuj to w bramie: odizoluj dane uwierzytelniające, ogranicz tożsamość usługi wewnętrznej, która może je pobrać, i rejestruj każde użycie.

Zalecenie: uczyń klasę danych uwierzytelniających twardą granicą autoryzacji, a nie etykietą. Program rozsyłający środowisko wykonawcze nie powinien być w stanie zażądać odszyfrowania danych uwierzytelniających administratora, nawet jeśli błąd konfiguracji odwołuje się do jego identyfikatora.

Utwórz silnik zasad wyboru poświadczeń

Wybór danych uwierzytelniających powinien nastąpić po uwierzytelnieniu przez bramę osoby dzwoniącej na dalszym etapie i przed próbą połączenia się z jakimkolwiek dostawcą. Silnik polityki powinien łączyć kilka danych wejściowych:

• Identyfikator dzierżawcy i zakres kluczy API dalszego łańcucha.
• Żądany profil modelu lub identyfikator modelu specyficzny dla dostawcy.
• Możliwości punktu końcowego: czat, osadzanie, obraz, dźwięk, wsad, pliki, narzędzia lub automatyzacja administracyjna.
• Wymogi dotyczące przechowywania danych i miejsca zamieszkania.
• Budżet, rezerwacja kredytu i centrum kosztów.
• Stan limitu szybkości i presja przydziału.
• Metadane poświadczeń, kondycja, środowisko i powiązanie dzierżawy.

Wyszukiwarka powinna zwrócić jeden z trzech wyników: zezwolić z wybranymi danymi uwierzytelniającymi, odmówić ze względu na zasady lub wymagać zatwierdzenia. Odmowy powinny być na tyle precyzyjne, aby zespoły operacyjne mogły rozwiązać problem bez ujawniania programistom tajnych materiałów.

Przykładowa decyzja:

{
  "ident_dzierżawcy": "dzierżawca_42",
  "requested_profile": "szybki-tekst-prod",
  "endpoint": "zakończenia czatu",
  "data_policy": "no_prompt_logging",
  „wymagania_poświadczeń”: {
    "klasa": "środowisko wykonawcze",
    „środowisko”: „produkcja”,
    "tenant_binding": "tenant_42",
    "allowed_model_family": "tekst",
    "health_status": "zdrowy"
  },
  „decyzja”: „zezwól”,
  "credential_id": "cred_8f2...",
  "audit_reason": "poświadczenia BYOK dzierżawcy odpowiadają profilowi tekstowemu środowiska wykonawczego i zasadom danych"

Nie wdrażaj powrotu w trybie „wypróbuj następny klucz”. Rozwiązanie awaryjne musi ponownie uruchomić zasady. Poświadczenie platformy współdzielonej może być ważne w przypadku dostępu dostawcy, ale nieważne w przypadku klienta korzystającego wyłącznie z BYOK. Poświadczenie w innym projekcie może mieć limit, ale może naruszać wymagania dotyczące alokacji kosztów lub przechowywania.

Obsługuj BYOK jako dostęp należący do dzierżawcy, a nie wolną pojemność

BYOK zmienia model zaufania. Klient dostarczył dane uwierzytelniające, aby jego ruch mógł być obciążany, zarządzany lub izolowany w ramach konta dostawcy. Poświadczenia te powinny być powiązane z pochodzeniem konta dzierżawcy klienta i dostawcy.

Zalecane elementy sterujące BYOK:

• Jeden rekord skarbca na klienta, dostawcę, granicę konta i środowisko.
• Brak routingu między dzierżawcami za pośrednictwem poświadczeń BYOK.
• Nie można używać jako współdzielonej mocy rezerwowej, chyba że klient wyraźnie wyrazi na to zgodę.
• Stan widoczny dla klienta, który nie ujawnia surowego klucza.
• Oddzielny proces rotacji, który umożliwia klientowi dodanie zamiennika przed wyłączeniem starego klucza.
• Wyraźne przypisanie w analizach użytkowania i fakturach: dzierżawca bramy, granica konta dostawcy, identyfikator danych uwierzytelniających, profil modelu i identyfikator śledzenia żądania.

W przypadku agencji, sprzedawców i automatyzacji Partner API BYOK może być bardziej złożony, ponieważ usługa może programowo udostępniać najemców i dane uwierzytelniające. Ta sama zasada nadal obowiązuje: automatyzacja może importować i wiązać dane uwierzytelniające, ale nie powinna zamazywać własności najemcy.

Dodaj kontrolę stanu przed inspekcją bez pojawiania się monitów

Poświadczenie może zakończyć się niepowodzeniem z wielu powodów: unieważnienia klucza, nieprawidłowego obszaru roboczego, braku dostępu do modelu, wyłączenia rozliczeń, wyczerpania przydziału, ograniczenia punktu końcowego, niezgodności z zasadami regionalnymi lub awarii dostawcy. Odkrycie tego dopiero po otrzymaniu żądania produkcyjnego powoduje hałaśliwe incydenty.

Korzystaj z kontroli stanu sprawdzających możliwości bez wysyłania monitów do klientów. Kontrola syntetyczna może wywołać minimalny punkt końcowy, w stosownych przypadkach wyświetlić listę dozwolonych modeli lub wysłać nieszkodliwy, naprawiony monit, jeśli jest to jedyna praktyczna opcja. Niech te czeki będą tanie, ograniczone stawkami i oznaczone jako ruch syntetyczny w telemetrii i rozliczeniach.

Powinny zostać przeprowadzone kontrole stanu:

• Podczas importu danych logowania.
• Przed włączeniem poświadczeń do routingu produkcyjnego.
• Po zmianach ograniczeń po stronie dostawcy.
• Podczas przełączania rotacji.
• Okresowo w celu uzyskania poświadczeń kwalifikujących się do produkcji.

Kompromis: automatyczne kontrole wcześnie wychwytują klucze, które utraciły ważność lub mają zbyt mały zakres, ale źle zaprojektowane kontrole mogą powodować niepotrzebne wezwania do dostawcy, szumy związane z rozliczeniami lub fałszywe alarmy w przypadku przerw w dostawie. Przechowuj wynik kondycji z sygnaturą czasową, klasą błędów dostawcy, przetestowanym punktem końcowym i przetestowaną rodziną modeli. Nie przechowuj tajnych wartości ani wrażliwych podpowiedzi.

Rotacja z dwoma miejscami, a nie z jedną ryzykowną wymianą

Rotacja danych uwierzytelniających nie powinna polegać na operacji usuwania i modyfikowania. Użyj modelu rotacji z dwoma miejscami:

1. Importuj dane uwierzytelniające zastępcze jako nieaktywne, z pełnymi metadanymi i właścicielem.
2. Uruchom syntetyczne kontrole stanu dla zamierzonych punktów końcowych, rodzin modeli i granic konta.
3. Włącz kwalifikację cienia dla małego fragmentu bezpiecznego ruchu syntetycznego lub ruchu niskiego ryzyka, tam gdzie to konieczne.
4. Stopniowo przenoś ruch produkcyjny ze starych danych uwierzytelniających na nowe.
5. Monitoruj błędy, opóźnienia, limity i przypisanie kosztów według identyfikatora danych uwierzytelniających.
6. Zablokuj powrót do starych danych uwierzytelniających, gdy nowe dane uwierzytelniające będą stabilne.
7. Unieważnij stare dane uwierzytelniające u dostawcy i oznacz rekord skarbca jako unieważniony.
8. Sprawdź, czy po unieważnieniu nie doszło do odszyfrowania ani wywołań dostawcy za pośrednictwem starych danych uwierzytelniających.

Terminy rotacji powinny być widoczne w widokach operacyjnych i alertach. Rotacja awaryjna wymaga krótszej ścieżki: wyłącz poświadczenia, zablokuj routing, włącz zatwierdzoną wymianę i zachowaj wszystkie zapisy audytu do przeglądu incydentów.

Ogranicz klucze dostawcy, jeśli dostawca je obsługuje

Zasady dotyczące bramy są konieczne, ale ograniczenia po stronie dostawcy zmniejszają promień wybuchu w przypadku naruszenia bezpieczeństwa lub niewłaściwego użycia klucza. W przypadku Gemini i innych kluczy API platformy chmurowej użyj ograniczeń API/usług oraz odpowiednich ograniczeń aplikacji, jeśli są dostępne. W przypadku projektów dostawców, obszarów roboczych i kont usług unikaj szerokich uprawnień organizacyjnych, gdy wystarczający jest klucz wykonawczy o zasięgu projektu.

Zalecenie: prowadź listę kontrolną ograniczeń po stronie dostawcy dla każdej klasy danych uwierzytelniających. Lista kontrolna powinna stanowić część zatwierdzania importu i rotacji, a nie oddzielne zadanie bezpieczeństwa, które można pominąć pod presją.

Kompromis: ograniczenia po stronie dostawcy zwiększają obciążenie operacyjne. Nowe punkty końcowe, rodziny modeli, regiony lub funkcje automatyzacji mogą wymagać zmian zasad i ograniczeń. Jest to lepsze niż odkrycie po wycieku, że jeden klucz może uzyskać dostęp do wszystkich zadań we współdzielonym projekcie.

Prowadź dziennik kontroli danych uwierzytelniających, w którym można tylko dołączać

Ścieżka audytu powinna odpowiadać na pytanie, kto zaimportował dane uwierzytelniające, co mógł zrobić, jakie decyzje dotyczące routingu je wybrały, kiedy się nie powiodło oraz kiedy zostały obrócone lub unieważnione.

Zapisz te zdarzenia:

• Utworzono lub zaimportowano dane uwierzytelniające.
• Zmieniono metadane, w tym dozwolone punkty końcowe, powiązanie dzierżawy lub zasady dotyczące danych.
• Przeprowadzono kontrolę stanu i zapisano wyniki.
• Poświadczenia wybrane przez zasady routingu dla żądania.
• Odszyfrowanie danych uwierzytelniających wymagane przez wewnętrzną tożsamość usługi.
• Wywołanie dostawcy nie powiodło się z powodu błędu uwierzytelnienia, autoryzacji, limitu lub ograniczenia.
• Rozpoczęto rotację, zmieniono ruch, stare dane uwierzytelniające zostały unieważnione.
• Wyłączenie awaryjne włączone lub wyczyszczone.
• Uzyskano dostęp do danych uwierzytelniających administratora lub tłuczonego szkła.

Nie umieszczaj surowych wartości poświadczeń w zdarzeniach kontroli. Użyj identyfikatorów poświadczeń, granic kont dostawców, identyfikatorów śledzenia żądań, tożsamości aktorów i powodów decyzji politycznych. W przypadku ruchu o dużym natężeniu w czasie wykonywania możesz pobrać szczegółowe dane telemetryczne dotyczące odszyfrowywania, ale wybór routingu i przypisanie kosztów powinny pozostać wystarczające, aby umożliwić rozliczenia i reakcję na incydenty.

Lista kontrolna wdrożenia

• Utwórz taksonomię danych uwierzytelniających i odrzuć niesklasyfikowany import.
• Przenieś wszystkie sekrety dostawców do dedykowanego zaszyfrowanego skarbca.
• Przechowuj metadane routingu oddzielnie od tajnych materiałów.
• Ustaw poświadczenia wykonawcze, administracyjne, rozliczeniowe, ewaluacyjne i BYOK jako oddzielne klasy autoryzacji.
• Powiąż poświadczenia BYOK z pochodzeniem konta dzierżawcy i dostawcy.
• Wymagaj zgody silnika zasad przed wybraniem jakichkolwiek danych uwierzytelniających wyższego szczebla.
• Przeprowadź szybkie i bezpieczne kontrole stanu przed kwalifikacją do produkcji.
• Korzystaj z rotacji dwóch slotów ze stopniową zmianą ruchu i odwoływaniem po stronie dostawcy.
• Zastosuj ograniczenia po stronie dostawcy, jeśli są dostępne.
• Prowadź dzienniki kontrolne umożliwiające tylko dołączanie dotyczące importowania, użytkowania, błędów, rotacji i unieważniania.
• Trzymaj dane administratora za kontrolką typu break-glass: krótki czas TTL, nazwane zatwierdzanie, silne rejestrowanie, brak użycia środowiska wykonawczego.

Wniosek, który można zastosować

Zacznij od spisania wszystkich danych uwierzytelniających dostawcy usług nadrzędnych aktualnie używanych przez bramę, skryptów, zadań CI, zestawów ewaluacyjnych i automatyzacji partnerów. Do każdego z nich przypisz klasę, właściciela, granicę konta dostawcy, powiązanie dzierżawy, dozwolone punkty końcowe, dozwolone rodziny modeli, termin rotacji i stan wyłączenia awaryjnego. Wszystko, czego nie można sklasyfikować, powinno zostać wyłączone lub poddane kwarantannie, dopóki nie będzie miało jasnego celu.

Następnie egzekwuj jedną zasadę architektoniczną: programiści podrzędni otrzymują klucze o zasięgu bramy; sama brama kontroluje dostęp dostawcy nadrzędnego. To rozdzielenie pozwala zachować najniższe uprawnienia, przypisanie dzierżawców, dokładność rozliczeń, routing zasad danych i bezpieczną automatyzację nawet w przypadku mnożenia się dostawców, projektów, obszarów roboczych i klientów BYOK.

Powiązane lektury

• Zarządzanie kluczami API zorientowanymi na zespół i reagowanie na wycieki
• Zasady routingu uwzględniające przechowywanie danych
• rozliczenia kontrola księgi i przypisania kosztów