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

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

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

Model operacyjny: każdy klucz potrzebuje granicy

Przydatna strategia kluczy 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: OpenAI wytyczne dotyczące bezpieczeństwa kluczy API zalecają, aby każdy członek zespołu używał unikalnego klucza API, stwierdzają, ż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ą także 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 bramy.

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 LLM API 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 limity dzienne, a przepływ pracy administratora wewnętrznego może korzystać z oddzielnej 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: OWASP API 10 najważniejszych zabezpieczeń w 2023 r. niewłaściwe zarządzanie zapasami stanowi główne API ryzyko bezpieczeństwa. W przypadku infrastruktury LLM spis kluczy jest częścią API inwentarza: 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 zawierać metadane. Co najmniej utwór:

• Nazwa klucza i identyfikator klucza wewnętrznego.
• Zespół właściciela i kontakt w nagłych wypadkach.
• Środowisko: produkcja, inscenizacja, rozwój, piaskownica.
• Cel: aplikacja, przepływ pracy, dzierżawa, integracja lub użycie przez programistę.
• Dozwoleni dostawcy, modele, punkty końcowe lub trasy, jeśli są obsługiwane.
• Data utworzenia, ostatnio używany znacznik czasu 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-2026q3
stg-docprocessor-platform-lowcost-2026q3
tenant-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 tam, gdzie pozwala na to platforma

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ą jednego lub większej liczby 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 nadrzędnego.
• Stawka: ograniczenie liczby żądań na minutę lub żądań jednoczesnych.
• Budżet: wymuszaj 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

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

Fakt: OpenAI wskazówki dotyczące bezpieczeństwa konta zalecają rozsądne limity wydatków i zauważają, że oddzielne klucze API ułatwiają przeglądanie użycia według funkcji, zespołu, produktu lub projektu. Raporty użycia OpenAI obsługują także szczegółową analizę z wykorzystaniem takich pól, jak identyfikator projektu, identyfikator użytkownika, identyfikator klucza API, model, partia i poziom 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.
• Globalny wyłącznik awaryjny: 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. Ogranicz ruch niekrytyczny do 100 procent.
4. Zablokuj tylko klucz, dzierżawcę lub trasę, która powoduje nieprawidłowe działanie, 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.

Śledzenie użycia 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ć użyteczną analizę 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.
• API identyfikator klucza lub identyfikator klucza wirtualnego.
• Identyfikator aplikacji, zespołu, dzierżawy, użytkownika lub przepływu pracy.
• Dostawca, model, trasa i poziom usług.
• Liczba żetonów podpowiedzi i zakoń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 LLM API rotacja nie jest jednorazowym zadaniem związanym z bezpieczeństwem; jest to operacyjny przepływ pracy.

Zalecenie: użyj 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 menedżerze tajnych informacji. Unikaj plików lokalnych, wiadomości na czacie, zgłoszeń i wklejanych zmiennych środowiskowych.
3. Stopniowe wdrażanie konfiguracji. Aktualizowanie jednej usługi, regionu, grupy pracowników lub segmentu dzierżawy na raz.
4. Sprawdź przepływ ruchu. Sprawdź, czy żądania przychodzą pod nowym kluczem oraz czy 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. Maruderzy w inspekcji. Przeszukuj dzienniki, manifesty wdrożeń, tajne magazyny, zmienne CI i błędy czasu wykonania dla 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

Kiedy wycieka klucz, liczy się szybkość. Odpowiedź powinna zostać napisana przed incydentem, a nie improwizowana w atmosferze 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 tajemnice zależne lub sąsiednie systemy również mogą zostać ujawnione.

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.

Prognoza: w miarę jak zespoły będą łączyć coraz więcej agentów, wtyczek, narzędzi do automatyzacji i przepływów pracy dostosowanych do potrzeb klienta z LLM, kluczowe wycieki będą w coraz większym stopniu dotyczyły 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 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 zgodny z OpenAI, API, podczas gdy brama obsługuje routing, analizę użycia, przypisywanie rozliczeń i egzekwowanie zasad.

Zalecenie: rozważ zastosowanie warstwy bramy lub serwera proxy, gdy zajdzie taka potrzeba:

• Jedno miejsce do zarządzania kluczami zespołu u wielu dostawców.
• Ujednolicona sztuczna inteligencja API raportowanie rozliczeń i 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 żądania. 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 – wszystkie mają 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 stacjonarnych i skryptów publicznych.
• Kieruj żądania klientów przez backend lub bramę AI API.
• Do każdego klucza dołącz właściciela, cel, środowisko, dozwolone modele, budżet i metadane przeglądu.
• 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 tokena, szacowany koszt, opóźnienie i kod stanu.
• Utwórz przepływ pracy bez przestojów i przetestuj go przed wystąpieniem sytuacji awaryjnej.
• Napisz element Runbook reagujący na wyciek, zawierający etapy ograniczania, badania i zapobiegania.
• Przejrzyj nieaktywne klucze i unieważnij wszystko bez właściciela lub niedawnego zgodnego z prawem użycia.

Wnioski, które 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 sposób rotacji.

Następnie powtórz. Silne zarządzanie kluczami LLM API nie jest pojedynczą decyzją dotyczącą przechowywania danych tajnych. 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

• produkcja LLM API routing i projekt awaryjny
• wcześniej Model Gate blog notatki
• wprowadzający Model Gate artykuł