Zarządzanie kluczami API LLM dla zespołów: izolacja, rotacja, limity wydatków i reakcja na wycieki

Jeden współdzielony klucz LLM API jest wygodny aż do pierwszego wycieku, niewyjaśnionego rachunku lub przestoju w produkcji. Praktycznym celem zarządzania kluczami API jest nie tylko utrzymanie tajemnicy danych uwierzytelniających. Ma ograniczać promień wybuchu, użycie atrybutów, bezpieczną rotację, wykrywać nietypowe wydatki i cofać dostęp bez przerywania niepowiązanych aplikacji.

Ten przewodnik przedstawia zespołom model operacyjny kluczy API LLM u dostawców, bramek, aplikacji wewnętrznych, agencji i produktów przeznaczonych dla klientów. Oddziela zweryfikowane fakty dotyczące bezpieczeństwa od zalecanych wyborów wdrożeniowych i pozwala uniknąć założenia, że każdy dostawca udostępnia te same kontrole.

Model operacyjny: każdy klucz potrzebuje granicy

Przydatna strategia kluczowa zaczyna się od jednego pytania: co powinno zawieść, jeśli ten klucz zostanie nadużyty lub unieważniony? Jeśli odpowiedź brzmi „cała firma”, klucz jest zbyt ogólny.

Fakt: wytyczne dotyczące bezpieczeństwa kluczy API OpenAI zalecają, aby każdy członek zespołu używał unikalnego klucza API, twierdzą, że udostępnianie kluczy jest niezgodne z Warunkami użytkowania i zalecają przypisywanie uprawnień do poszczególnych kluczy, jeśli jest to możliwe. Wytyczne OpenAI odradzają również wdrażanie kluczy API w środowiskach po stronie klienta, takich jak przeglądarki lub aplikacje mobilne, ponieważ ujawnione klucze mogą zostać wykorzystane do wysyłania żądań w imieniu właściciela.

Zalecenie: utwórz klucze w oparciu o granice operacyjne, a nie wygodę. Typowe granice obejmują:

• Środowisko: produkcja, inscenizacja, rozwój, piaskownica.
• Aplikacja: backend chatbota, procesor dokumentów, asystent kodowania, przepływ pracy analitycznej.
• Właściciel: zespół, konto usługi, programista, klient agencji, najemca.
• Poziom ryzyka: przepływ pracy dostępny publicznie, automatyzacja wewnętrzna, zadanie wsadowe, integracja eksperymentalna.
• Dostawca lub trasa: dostawca wyższego szczebla A, dostawca B, zatwierdzona grupa modeli lub trasa pośrednia.

Dobrym ustawieniem domyślnym dla rozwijającego się zespołu jest: jeden klucz produkcyjny na aplikację lub usługę, jeden klucz nieprodukcyjny na środowisko i osobne klucze do automatyzacji wysokiego ryzyka lub użycia na poziomie klienta. Agencje i sprzedawcy powinni preferować klucze wirtualne na poziomie klienta, zamiast udostępniać dane uwierzytelniające dostawcy wyższego szczebla.

Nigdy nie umieszczaj kluczy dostawcy w klientach rozproszonych

Przeglądarki, aplikacje mobilne, rozszerzenia dla komputerów stacjonarnych, wtyczki publiczne i skrypty po stronie klienta to miejsca nieprzyjazne dla surowych danych uwierzytelniających dostawców. Nawet jeśli zaciemnisz klucz, rozproszone oprogramowanie może zostać sprawdzone, skopiowane lub przechwycone.

Fakt: OpenAI wyraźnie ostrzega, aby nie wdrażać kluczy API w środowiskach po stronie klienta. Badania aplikacji mobilnych wykazały również ciągły wyciek danych uwierzytelniających API LLM w aplikacjach na iOS, potwierdzając to samo praktyczne ostrzeżenie: dane uwierzytelniające osadzone w klientach rozproszonych mają tendencję do ucieczki.

Zalecenie: użyj wzorca zaplecza lub bramy:

1. Klient uwierzytelnia się w aplikacji przy użyciu sesji użytkownika, tokenu JWT, tokena klienta lub krótkotrwałego poświadczenia.
2. Twój backend sprawdza użytkownika, dzierżawcę, plan i żądaną operację.
3. Twój backend lub brama AI API wywołuje nadrzędnego dostawcę LLM przy użyciu chronionych danych uwierzytelniających po stronie serwera.
4. Odpowiedź jest zwracana do klienta po sprawdzeniu zasad, zarejestrowaniu i rozliczeniu kosztów.

Ten projekt umożliwia egzekwowanie reguł dotyczących produktu przed dokonaniem wydatków. Na przykład użytkownik korzystający z planu bezpłatnego może być ograniczony do mniejszych modeli, płatny najemca może otrzymać wyższe dzienne limity, a wewnętrzny przepływ pracy administratora może korzystać z osobnej trasy z bardziej rygorystycznym monitorowaniem.

Zbuduj kluczowy spis, zanim będziesz potrzebować reakcji na incydent

Podczas wycieku zespoły często odkrywają, że nikt nie wie, która usługa jest właścicielem ujawnionego klucza. To jest awaria inwentarza.

Fakt: 10 najważniejszych zabezpieczeń API OWASP w 2023 r. obejmuje niewłaściwe zarządzanie zapasami jako główne ryzyko bezpieczeństwa API. W przypadku infrastruktury LLM inwentaryzacja kluczy jest częścią inwentarza API: musisz wiedzieć, jakie dane uwierzytelniające istnieją, do czego mogą uzyskać dostęp i kto jest ich właścicielem.

Zalecenie: każdy klucz powinien mieć metadane. Śledź co najmniej:

• Nazwa klucza i identyfikator klucza wewnętrznego.
• Zespół właściciela i kontakt w sytuacjach awaryjnych.
• Środowisko: produkcja, staging, development, sandbox.
• Cel: aplikacja, przepływ pracy, najemca, integracja lub użycie przez programistę.
• Dozwoleni dostawcy, modele, punkty końcowe lub trasy, jeśli są obsługiwane.
• Data utworzenia, data ostatniego użycia i planowana data przeglądu.
• Pułap lub limit wydatków.
• Stan rotacji i połączona konfiguracja wdrożenia.

Zastosuj konwencję nazewnictwa, która będzie czytelna w alertach. Na przykład:

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platforma-lowcost-2026q3
najemca-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

Dokładny format ma mniejsze znaczenie niż spójność. Celem jest, aby alert mógł zawierać informację „tenant-acme-prod-standard przekroczył dzienny próg”, a odpowiedzialny właściciel wiedział, co robić.

Zastosuj najmniejsze uprawnienia, jeśli platforma na to pozwala

Nie każdy dostawca lub brama zapewnia identyczną kontrolę uprawnień, ale zasada jest spójna: klucz powinien móc wykonywać tylko to, czego potrzebuje jego obciążenie.

Zalecenie: ogranicz klucze za pomocą co najmniej jednego z następujących elementów sterujących, jeśli są obsługiwane:

• Projekt: powiąż klucze z projektem, a nie całą organizacją.
• Model: zezwalaj tylko na zatwierdzone modele; domyślnie blokuj drogie lub eksperymentalne modele.
• Punkt końcowy: zezwalaj na dokończenie czatu, ale odmawiaj niepowiązanych administracyjnych punktów końcowych.
• Trasa dostawcy: zezwalaj na trasę przez bramę zamiast bezpośredniego dostępu do każdego dostawcy wyższego szczebla.
• Część: ograniczenie liczby żądań na minutę lub jednoczesnych żądań.
• Budżet: egzekwuj limity wydatków na klucz, na zespół lub na dzierżawcę.

Na przykład klucz przejściowy zwykle nie wymaga dostępu do najdroższego modelu produkcyjnego. Osoba zajmująca się klasyfikacją dokumentów prawdopodobnie nie potrzebuje dostępu do generowania obrazów. Klucz dzierżawy skierowany do klienta nie powinien być w stanie pochłonąć budżetu innego dzierżawcy.

Zaprojektuj kontrolę wydatków w warstwach

Nakładanie się zabezpieczeń API LLM i kontroli kosztów. Wyciek klucza jest często wykrywany jako anomalia rozliczeniowa, zanim zostanie wykryty jako zdarzenie związane z bezpieczeństwem.

Fakt: wskazówki dotyczące bezpieczeństwa konta OpenAI zalecają rozsądne limity wydatków i zauważają, że oddzielne klucze API mogą ułatwić przeglądanie użycia według funkcji, zespołu, produktu lub projektu. Raporty dotyczące użytkowania OpenAI obsługują również szczegółową analizę za pomocą pól, takich jak identyfikator projektu, identyfikator użytkownika, identyfikator klucza API, model, partia i warstwa usług.

Zalecenie: używaj limitów warstwowych zamiast jednego globalnego limitu:

• Limit klucza: zapobiega wyczerpaniu całego budżetu przez jedno dane uwierzytelniające.
• Limit na zespół: zapewnia widoczność i rozliczalność wykorzystania działu.
• Limit na dzierżawcę: izoluje wykorzystanie klienta w scenariuszach SaaS i agencji.
• Dzienny próg anomalii: uruchamia alerty, gdy użycie odbiega od normalnego wzorca.
• Globalne zatrzymanie awaryjne: umożliwia szybkie zawieszenie, gdy aktywne jest nadużycie.

Twarde limity są przydatne, ale mogą przerwać prawidłowe zadania wsadowe. Bezpieczniejszy wzorzec produkcji to sekwencja kontroli:

1. Powiadomienie o osiągnięciu 50 procent oczekiwanych dziennych wydatków.
2. Eskaluj o 80 procent.
3. Zablokuj ruch niekrytyczny do 100 procent.
4. Zablokuj tylko klucz, dzierżawcę lub trasę powodującą naruszenie, zanim użyjesz globalnego zamknięcia.

Kompromis: rygorystyczne budżety zmniejszają ryzyko rozliczeniowe, ale mogą powodować ryzyko dostępności. Limity poziomów według obciążenia: interaktywny ruch produkcyjny, płatny ruch skierowany do klienta, zadania w tle, eksperymenty i piaskownice dla programistów nie powinny kończyć się niepowodzeniem w ten sam sposób.

Śledź użycie według kluczowego i logicznego aktora

Klucz identyfikuje dane uwierzytelniające. Może nie identyfikować rzeczywistego użytkownika, dzierżawcy, funkcji lub przepływu pracy, który spowodował żądanie. Aby uzyskać przydatne analizy wykorzystania sztucznej inteligencji, rejestruj zarówno wymiary techniczne, jak i biznesowe.

Zalecenie: dla każdego żądania, jeśli pozwala na to prywatność i zasady, zbierz następujące pola:

• Identyfikator żądania i sygnatura czasowa.
• Identyfikator klucza API lub identyfikator klucza wirtualnego.
• Identyfikator aplikacji, zespołu, dzierżawy, użytkownika lub przepływu pracy.
• Dostawca, model, trasa i poziom usług.
• Liczba tokenów monitów i ukończenia lub równoważne jednostki użycia.
• Szacowany koszt.
• Opóźnienie, kod stanu, liczba ponownych prób i klasa błędu.

Nie zamieniaj obserwowalności kosztów w niepotrzebne gromadzenie danych. Unikaj domyślnego przechowywania pełnych monitów, jeśli mogą zawierać dane osobowe, tajemnice klientów lub treści podlegające przepisom. W wielu przypadkach zaszyfrowane identyfikatory użytkowników, identyfikatory dzierżawców, liczba tokenów i nazwy modeli wystarczą do wykrycia obciążeń zwrotnych i anomalii.

Rotacja bez przestojów: bezpieczny przepływ pracy

Fakt: Wytyczne NIST dotyczące zarządzania kluczami traktują zarządzanie kluczami jako dyscyplinę cyklu życia, obejmującą wytwarzanie, przechowywanie, aktywację, rotację, zawieszanie, unieważnianie i niszczenie. W przypadku kluczy API LLM rotacja nie jest jednorazowym zadaniem związanym z bezpieczeństwem; jest to przepływ pracy operacyjnej.

Zalecenie: skorzystaj z tego procesu rotacji bez przestojów:

1. Utwórz klucz zastępczy. Dopasuj wymagane uprawnienia, budżet, trasę i metadane. Nie unieważniaj jeszcze starego klucza.
2. Przechowuj go w tajnym menedżerze. Unikaj plików lokalnych, wiadomości na czacie, zgłoszeń i wklejanych zmiennych środowiskowych.
3. Wdrażaj konfigurację stopniowo. Aktualizuj pojedynczo jedną usługę, region, grupę pracowników lub segment dzierżawy.
4. Sprawdź przepływ ruchu. Upewnij się, że żądania przychodzą pod nowym kluczem oraz że poziom błędów i opóźnienia pozostają normalne.
5. Zablokuj zapisywanie w starym kluczu. Zablokuj odwoływanie się do niego w nowych wdrożeniach.
6. Unieważnij stary klucz. Po przeniesieniu ruchu wyłącz go, zamiast pozostawiać jako zapomniany klucz zastępczy.
7. Osoby, które mają problemy z audytem. Przeszukuj dzienniki, manifesty wdrożeń, tajne magazyny, zmienne CI i błędy czasu wykonania pod kątem starego identyfikatora klucza.

W przypadku aplikacji, które nadal korzystają ze statycznych zmiennych środowiskowych, rotacja będzie delikatna. Przejdź w stronę dynamicznego ładowania kluczy tajnych, scentralizowanej konfiguracji lub kluczy wirtualnych zarządzanych przez bramę. Udokumentuj co najmniej, które wdrożenie musi zostać zmienione przed odwołaniem.

Element Runbook odpowiedzi na wyciek

Gdy klucz wycieka, liczy się szybkość. Odpowiedź powinna zostać napisana przed incydentem, a nie improwizowana w obliczu paniki związanej z rachunkami.

Natychmiastowe zabezpieczenie

1. Unieważnij lub zawieś odsłonięty klucz.
2. Jeśli cofnięcie spowodowałoby przerwanie produkcji, najpierw wyślij zamiennik i natychmiast przełącz ruch krytyczny.
3. Zablokuj trasę, dzierżawcę lub dostawcę, jeśli nadużycie jest nadal aktywne.
4. Zachowaj dzienniki potrzebne do zidentyfikowania nadużyć.

Dochodzenie

1. Określ, gdzie pojawił się klucz: repozytorium, pakiet frontonu, aplikacja mobilna, plik dziennika, zgłoszenie do pomocy technicznej, narzędzie dostawcy lub czat.
2. Znajdź ostatnie znane legalne użycie.
3. Porównaj użycie przed i po podejrzeniu narażenia.
4. Przejrzyj używane modele, liczbę żądań, koszt, lokalizację geograficzną, jeśli jest dostępna, i nietypowe kody stanu.
5. Sprawdź, czy mogą zostać ujawnione również zależne sekrety lub sąsiednie systemy.

Odzyskiwanie i zapobieganie

1. Zamień zależne dane uwierzytelniające, jeśli w tym samym środowisku mogło dojść do wycieku więcej niż jednego sekretu.
2. W stosownych przypadkach powiadom zespół właścicieli i interesariuszy, których to dotyczy.
3. Dodaj tajne skanowanie do repozytoriów i potoków CI.
4. Zapobiegaj powtarzaniu się, przenosząc wywołania po stronie klienta za backend lub bramę.
5. Udokumentuj harmonogram incydentu, pierwotną przyczynę, wpływ na koszty i ulepszenia kontroli.

Przewidywanie: w miarę jak zespoły będą łączyć coraz więcej agentów, wtyczek, narzędzi automatyzacji i przepływów pracy dostosowanych do potrzeb klienta z LLM, kluczowe wycieki będą w coraz większym stopniu dotyczyć przede wszystkim incydentów kosztowych, a w drugiej kolejności incydentów związanych z bezpieczeństwem. Zespoły z kontrolą przypisania poszczególnych kluczy i budżetem rozwiążą je szybciej niż zespoły korzystające z jednego wspólnego poświadczenia.

Klucze zarządzane przez bramę dla zespołów składających się z wielu dostawców

Jeśli Twoja organizacja korzysta z kilku dostawców LLM, klucze bezpośrednich dostawców mogą spowodować rozproszone zarządzanie: różne pulpity nawigacyjne, różne widoki rozliczeń, różne modele uprawnień i niespójne procesy rotacji.

Warstwa kluczy zarządzana przez bramę może to uprościć, wydając klucze skierowane do aplikacji, jednocześnie ukrywając poświadczenia dostawcy nadrzędnego. Aplikacje wywołują punkt końcowy API zgodny z OpenAI, podczas gdy brama obsługuje routing, analizę użycia, przypisywanie rozliczeń i egzekwowanie zasad.

Zalecenie: rozważ zastosowanie warstwy bramy lub serwera proxy, jeśli potrzebujesz:

• Jedno miejsce do zarządzania kluczami zespołu u wielu dostawców.
• Ujednolicone rozliczenia API AI i raportowanie wydatków według klucza.
• Klucze wirtualne na poziomie klienta dla agencji, sprzedawców i najemców SaaS.
• Centralne listy dozwolonych modeli, zasady tras i zawieszenie awaryjne.
• Przypisanie wykorzystania według najemcy, funkcji, przepływu pracy lub klienta-partnera.

Kompromis: brama usprawnia zarządzanie i ukrywa dane uwierzytelniające nadrzędne, ale staje się częścią ścieżki żądań. Monitoruj ją tak jak infrastrukturę produkcyjną: opóźnienia, dostępność, współczynniki błędów, kolejkowanie, zachowanie podczas ponownych prób i awarie specyficzne dla dostawcy – wszystko to ma znaczenie.

Lista kontrolna wdrożenia

• Zastąp klucze udostępnione dla całej organizacji kluczami o zakresie aplikacji, środowiska, dzierżawy lub przepływu pracy.
• Usuń nieprzetworzone klucze dostawcy z przeglądarek, aplikacji mobilnych, rozszerzeń komputerów i skryptów publicznych.
• Kieruj żądania klientów przez bramę zaplecza lub interfejsu API AI.
• Dołącz właściciela, cel, środowisko, dozwolone modele, budżet i metadane przeglądu do każdego klucza.
• Zastosuj najmniejsze uprawnienia: projekt, punkt końcowy, model, trasa, stawka i kontrola budżetu, jeśli to możliwe.
• Ustaw limity wydatków na klucz, na zespół, na dzierżawcę i globalne.
• Identyfikator klucza dziennika, aktor logiczny, model, użycie tokenu, szacowany koszt, opóźnienie i kod stanu.
• Utwórz przepływ pracy bez przestojów i przetestuj go przed sytuacją awaryjną.
• Napisz element Runbook reagujący na wyciek, zawierający kroki dotyczące ograniczania, badania i zapobiegania.
• Przejrzyj nieaktywne klucze i unieważnij wszystko, co nie miało właściciela ani niedawnego zgodnego z prawem użycia.

Wniosek, który można zastosować

Zacznij od klucza o najwyższym ryzyku: tego używanego w produkcji, udostępnianego przez wiele osób, umieszczonego w zbyt wielu miejscach lub odpowiedzialnego za największe wydatki. Daj mu właściciela, podziel go według granic, dodaj budżet, przenieś go za backend lub bramę, jeśli klienci mogą to zobaczyć, i udokumentuj, jak go obracać.

Następnie powtórz. Silne zarządzanie kluczami API LLM nie jest pojedynczą decyzją dotyczącą przechowywania sekretów. Jest to cykl życia: inwentaryzacja, izolacja, najmniejsze uprawnienia, przypisanie użycia, kontrola kosztów, rotacja i reakcja na wycieki. Zapłata jest prosta: gdy coś pójdzie nie tak, zagrożona powinna być tylko jedna aplikacja, najemca lub przepływ pracy, a nie cały budżet sztucznej inteligencji.

Powiązane lektury

• produkcyjny routing LLM API i projektowanie rozwiązań awaryjnych
• wcześniejsze notatki na blogu Model Gate
• wstępny artykuł dotyczący Model Gate