Jak zaprojektować konta usług LLM dla obciążeń produkcyjnych

Zadania produkcyjne LLM nie powinny być uwierzytelniane jako osoby. Zadanie CI, usługa zaplecza, agent uruchamiający, procesor wsadowy lub brama skierowana do partnera wymagają własnej tożsamości innej niż ludzka z jasnym właścicielem, wąskim zakresem, budżetem, ścieżką audytu i ścieżką zamknięcia. Bez tego modelu jeden klucz, który wyciekł, może reprezentować zbyt wiele systemów, odejście od pracy nie powoduje usunięcia dostępu, a raporty użytkowania nie są w stanie wyjaśnić, jakie obciążenie spowodowało koszty lub ryzyko.

Ten przewodnik przedstawia zespołom inżynieryjnym i platformom praktyczny projekt zarządzania kontami usług LLM w interfejsach API dostawców i bramach wewnętrznych. Oddziela zweryfikowane fakty dotyczące dostawców od zaleceń dotyczących wdrożenia i przedstawia prognozy, w których obszarach model operacyjny prawdopodobnie będzie ewoluował.

Co to jest konto usługi LLM?

Fakt: Konta usług to tożsamości inne niż ludzkie, używane przez aplikacje i obciążenia, a nie przez indywidualnych użytkowników. Projekty OpenAI API obsługują konta usług o zakresie projektu i klucze API. Anthropic opisuje konta usług jako nazwane tożsamości inne niż ludzkie w organizacji. Google Cloud IAM opisuje konta usług jako użytkowników aplikacji i obciążeń innych niż ludzie.

W przypadku systemów LLM konto usługi powinno reprezentować granicę obciążenia: jedną usługę backendu, jedną rodzinę przepływów pracy CI, jedno środowisko wykonawcze agenta, jeden potok wsadowy lub jeden poziom integracji partnera API. Nie powinien reprezentować osoby, całej firmy ani każdej aplikacji w środowisku.

Przydatny zapis konta usługi odpowiada na pięć pytań:

• Która aplikacja lub przepływ pracy jest właścicielem tej tożsamości?
• W jakim środowisku można to uruchomić?
• Który zespół jest odpowiedzialny za koszty, dostęp i incydenty?
• Jakie modele, punkty końcowe, narzędzia, zasady dotyczące danych i regiony są dozwolone?
• W jaki sposób dane uwierzytelniające są zmieniane, unieważniane lub zastępowane przez federację?

Kiedy utworzyć konto usługi

Utwórz konto usługi, jeśli rozmówcą jest oprogramowanie operacyjne, a nie człowiek. Typowe przykłady obejmują zadania CI/CD, które uruchamiają oceny, usługi produkcyjne API, pracowników przetwarzających dokumenty, drugich pilotów obsługi klienta, autonomiczne kolejki agentów, zaplanowane zadania wzbogacania i wewnętrzne platformy programistyczne, które pośredniczą w dostępie LLM dla wielu zespołów.

Nie twórz nowego konta usługi dla każdego programisty, każdego lokalnego eksperymentu ani każdego monitu. Eksploracja człowieka kryje się za tożsamością użytkownika i krótkotrwałymi referencjami programistycznymi. Atrybucję na poziomie podpowiedzi i na poziomie funkcji można przechwycić jako metadane żądania w ramach tożsamości obciążenia.

Prosta zasada decyzyjna działa dobrze:

• Jeśli rozmówca może działać bez nadzoru, użyj konta usługi.
• Jeśli obiekt wywołujący obsługuje ruch produkcyjny, użyj konta usługi odpowiadającego obciążeniu i środowisku.
• Jeśli osoba dzwoniąca działa w imieniu klienta lub partnera, oddziel tożsamość obciążenia od tożsamości delegowanej dzierżawy.
• Jeśli rozmówcą jest człowiek korzystający z konsoli lub notebooka, nie ukrywaj tego za kontem usługi produkcyjnej.

Zacznij od spisu tożsamości

Migrację należy rozpocząć od inwentarza, a nie od rotacji kluczy. Zespoły często odkrywają, że jeden klucz dostawcy jest używany przez usługi produkcyjne, zadania przemieszczania, skrypty lokalne, potoki ewaluacyjne i porzucone integracje. Obrót tego klucza najpierw stwarza ryzyko bez poprawy własności.

Zbuduj asortyment, korzystając z następujących kategorii:

• Klucze API dostawcy należącego do człowieka.
• Konta usługi Workload.
• Tożsamości CI/CD.
• Klucze wewnętrzne wydawane przez bramę.
• Klucze przekazane przez partnera lub klienta.
• Awaryjne dane uwierzytelniające dotyczące stłuczenia szyby.
• Nieznane klucze, które nadal powodują użycie.

Dla każdego poświadczenia, dostawcy rekordów, projektu lub obszaru roboczego, właściciela klucza, aplikacji korzystającej, środowiska wdrożenia, tajnej lokalizacji, dozwolonych modeli, właściciela wydatku, sygnatury czasowej ostatnio widzianej i ryzyka unieważnienia. Ten spis staje się źródłem prawdy dla LLM API zarządzania kluczami, ale konta usług powinny być modelowane jako pierwszorzędne tożsamości obciążenia, a nie tylko kolejna kluczowa etykieta.

Użyj jednego konta usługi na granicę obciążenia

Głównym wyborem projektowym jest szczegółowość. Zbyt mało kont usług tworzy wspólny promień wybuchu. Zbyt wiele powoduje hałas operacyjny. Właściwa jednostka to najmniejsza granica obciążenia, która ma odrębnych właścicieli, uprawnienia, profil kosztów lub potrzeby w zakresie reagowania na incydenty.

Używaj oddzielnych kont usług dla:

• Środowiska produkcyjne i nieprodukcyjne.
• Różne aplikacje należące do różnych zespołów.
• Usługi skierowane do klienta a zadania wewnętrzne.
• Interaktywne ścieżki żądań a asynchroniczne procesory wsadowe.
• Środowiska wykonawcze agentów, które mogą wywoływać narzędzia lub uruchamiać pętle.
• Partner API powierzchnie udostępniające delegowany dostęp.

Praktyczny wzór nazewnictwa to:

llm-sa-{app}-{env}-{team}-{purpose}

Przykłady:

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

Nie koduj tajemnic, nazw klientów, nazwisk ani tymczasowych numerów biletów w nazwie konta. Zamiast tego umieść modyfikowalne szczegóły w tagach lub metadanych.

Mapuj konta dostawców na model tożsamości bramy

Fakt: Możliwości dostawców są różne. OpenAI obsługuje konta usług w ramach API projektów, a konta usług projektu są unikalne dla projektu, w którym zostały utworzone. Anthropic obszary robocze mogą zawierać członków, konta usług, API klucze i limity zasobów. Anthropic Federacja tożsamości zadań roboczych umożliwia obciążeniom korzystanie z podpisanych tokenów tożsamości Anthropic zamiast statycznych poświadczeń, przy czym po skonfigurowaniu limity atrybucji i szybkości są powiązane z obszarem roboczym.

Zalecenie: Zachowaj model konta usługi na poziomie bramy, nawet jeśli istnieją konta usług natywne dla dostawcy. Tożsamością bramy powinien być stabilny obiekt wewnętrzny, z którym powiązane są zasady, raporty, budżety i dowody kontroli. Dane uwierzytelniające dostawcy są następnie odwzorowane pod nimi ze szczegółami implementacji.

Na przykład:

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

To mapowanie ma znaczenie w wielomodelowej bramie AI API, ponieważ dostawcy wyższego szczebla udostępniają różne struktury kont, pola rozliczeniowe, uprawnienia modeli i opcje federacji. Pojedyncza wewnętrzna warstwa tożsamości pozwala zespołom egzekwować jedną umowę zasad, zachowując jednocześnie kontekst specyficzny dla dostawcy na potrzeby rozwiązywania problemów.

Wąski zakres uprawnień

Zakres konta usługi powinien uwzględniać potrzeby obciążenia, a nie to, na co pozwala klucz dostawcy. Zdefiniuj co najmniej zakres w ramach tych wymiarów:

• Granica dostawcy: których dostawców, projekty dostawców lub obszary robocze mogą być używane.
• Granica modelu: dozwolone rodziny modeli, wersje, modele podglądowe i modele zastępcze.
• Granica punktu końcowego: czat, odpowiedzi, osadzanie, wsad, pliki, dostrajanie, asystenci, narzędzia lub interfejsy API administratora.
• Granica środowiska: programowanie, etapowanie, produkcja, piaskownica lub partner.
• Granica danych: zasady przechowywania, region, klasa danych wrażliwych i dozwolone funkcje stanowe.
• Granica budżetu: alerty programowe, limity twarde, limity minutowe i limity miesięczne.
• Granica sieci: akceptowane sieci źródłowe, tożsamości obciążeń lub platformy wdrożeniowe.

Uprawnienia administracyjne API prawie nigdy nie powinny być dostępne dla kont usług wykonawczych. Oddziel automatyzację udostępniania od obciążeń wnioskowania. Usługa zaplecza wysyłająca monity nie powinna także mieć możliwości tworzenia nowych kluczy dostawców, zmiany budżetów ani udzielania dostępu modelom.

Jeśli jest to praktyczne, preferuj federację zamiast kluczy statycznych

Fakt: Anthropic dokumentuje federację tożsamości obciążeń jako sposób, w jaki obciążenia mogą używać podpisanych tokenów tożsamości, a nie statycznych Anthropic poświadczeń. Google Cloud ostrzega, że ​​klucze konta usługi zarządzane przez użytkownika stanowią ryzyko dla bezpieczeństwa, jeśli nie są zarządzane ostrożnie, i zaleca bezpieczniejsze alternatywy, jeśli to możliwe. OWASP zaleca scentralizowane przechowywanie sekretów, kontrolowanie żądań i wykorzystania tajnych danych, rotację, unieważnianie i wygaśnięcie, jeśli to możliwe.

Zalecenie: Preferuj federację tożsamości obciążenia pracą lub krótkotrwałą wymianę tokenów w przypadku usług hostowanych w chmurze i systemów CI/CD, w przypadku których dostępna jest obsługa dostawców. Używaj kluczy statycznych API tylko wtedy, gdy federacja jest niedostępna, nie jest obsługiwana przez potrzebną ścieżkę dostawcy lub jest operacyjnie nieuzasadniona w przypadku obciążenia o niskim ryzyku.

Przebieg federacji zwykle wygląda następująco:

1. Obciążenie działa w ramach chmury, CI lub dostawcy tożsamości.
2. Zadanie uzyskuje podpisany token tożsamości od nadrzędnego dostawcy tożsamości.
3. Dostawca LLM lub brama wewnętrzna weryfikuje wystawcę, odbiorców, temat i oświadczenia.
4. Brama mapuje token na wewnętrzne konto usługi.
5. Brama wystawia krótkotrwałą sesję lub bezpośrednio autoryzuje żądanie LLM.

Weryfikuj więcej niż wydawca. Sprawdź odbiorców, temat, repozytorium lub ścieżkę obciążenia, środowisko, gałąź lub oświadczenia dotyczące wdrożenia, jeśli są dostępne, oraz czas życia tokenu. Federacja przenosi ryzyko ze statycznego wycieku danych tajnych na konfigurację dostawcy tożsamości. Słabe oświadczenia, szerokie zasady zaufania lub liberalne środowiska CI mogą nadal zapewniać niezamierzony dostęp.

Wymagaj metadanych przypisania przy każdym żądaniu

Konta usług identyfikują obciążenie pracą, ale nie powinny być jedynym polem atrybucji. Żądania produkcyjne LLM wymagają wystarczającej ilości metadanych, aby szybko odpowiedzieć na pytania operacyjne.

Wymagaj tych pól na bramie:

• service_account_id
• app
• environment
• owner_team
• deployment_id lub wersja wydania
• request_purpose, np. czat, wyodrębnianie, klasyfikacja, ewaluacja lub agent_tool_use
• tenant_id lub identyfikator klienta, jeśli ma to zastosowanie
• workflow_id lub identyfikator zadania dla pracy asynchronicznej

Te pola obsługują LLM API atrybucję kosztów, reakcję na incydenty, decyzje dotyczące limitów stawek i uzgadnianie faktur od dostawcy. Zapobiegają także typowemu trybowi awarii, w którym każde żądanie ze wspólnego klucza jest oznaczone jedynie jako „backend”.

Dołącz budżety i alerty do tożsamości zadań

Konta usług często działają bez nadzoru. To sprawia, że ​​kontrola kosztów jest ważniejsza, a nie mniej. Użytkownik może zauważyć niekontrolowaną sesję czatu. Zaplanowany agent lub ponawianie zadania wsadowego może przepalić budżet z dnia na dzień.

Ustaw budżety na wielu poziomach:

• Budżet projektu dostawcy lub obszaru roboczego, jeśli jest obsługiwany.
• Miesięczny budżet na poziomie bramy na konto usługi.
• Wykrywanie anomalii w krótkim czasie w przypadku nagłych skoków.
• Maksymalny szacowany koszt na żądanie lub na zadanie.
• Oddzielne limity dla obciążeń produkcyjnych, przejściowych, CI i ewaluacyjnych.

Użyj różnych działań dla różnych progów. Przy 50 procentach powiadom zespół właściciela. Przy 80 procentach wymagaj potwierdzenia. Przy 100 procentach możesz albo blokować żądania niekrytyczne, przechodzić na tańsze, zatwierdzone modele, albo wymagać jawnego zastąpienia. Prawidłowe zachowanie zależy od tego, czy obciążenie jest skierowane do klienta, wewnętrzne, wsadowe czy krytyczne dla bezpieczeństwa.

Zaprojektuj przepływ pracy w cyklu życia

Konto usługi bez kontroli cyklu życia staje się kolejnym niezarządzanym sekretem. Zdefiniuj przepływ pracy przed powszechnym przyjęciem.

Prośba

Osoba żądająca musi podać nazwę aplikacji, środowisko, zespół właścicieli, cel biznesowy, oczekiwane miesięczne wydatki, klasyfikację danych, wymagania dotyczące modelu, wymagania dotyczące punktu końcowego oraz informację, czy możliwa jest federacja.

Zatwierdzenie

Zgoda powinna pochodzić od zespołu właścicieli i platformy lub zasad bezpieczeństwa. Zadania wysokobudżetowe, wymagające danych wrażliwych, wymagające współpracy z partnerami lub wymagające użycia narzędzi powinny wymagać dokładniejszej kontroli niż zadania związane z wewnętrznym podsumowaniem o niskim ryzyku.

Udostępnianie

Utwórz wewnętrzne konto usługi, powiązanie dostawcy, budżet, zasady modelu, ujście audytu oraz zaufanie tajne lub federacyjne. Tam, gdzie to możliwe, zapewnianie usług poprzez automatyzację, a nie ręczną pracę na konsoli.

Tajna dostawa

Jeśli wymagany jest klucz statyczny, dostarcz go tylko do scentralizowanego menedżera tajnych kluczy lub platformy wdrożeniowej. Nie wysyłaj kluczy za pośrednictwem czatu, zgłoszeń, plików lokalnych ani stron dokumentacji.

Recenzja

Przeglądaj konta usług w ustalonym rytmie. Potwierdź zespół właścicieli, ostatnie użycie, uprawnienia, budżet, dostęp do modelu, zasady dotyczące danych i to, czy klucze statyczne można zastąpić federacją.

Wyłącz i usuń

Wyłącz nieużywane konta usług przed usunięciem. Spowoduje to utworzenie okna odzyskiwania w przypadku pominięcia zależności obciążenia. Po okresie kwarantanny usuń konto i unieważnij wszystkie powiązania i sekrety dostawców.

Rejestracja zdarzeń potrzebnych audytorom i osobom odpowiadającym

Dzienniki audytu powinny obejmować zarówno aktywność na płaszczyźnie kontroli, jak i na płaszczyźnie danych. Rejestruj co najmniej:

• Tworzenie, aktualizacja, wyłączanie i usuwanie konta usługi.
• Tworzenie, odczytywanie, rotacja i unieważnianie danych uwierzytelniających.
• Tworzenie zaufania federacji i zmiany zasad roszczeń.
• Zmiany uprawnień, dostępu do modelu, dostępu do punktu końcowego i zasad dotyczących danych.
• Każde żądanie LLM zawierające konto usługi, najemcę, model, dostawcę, użycie tokena, szacunkowy koszt, stan i cel żądania.
• Zdarzenia związane z progami budżetu, blokady stałych limitów i ręczne nadpisania.
• Wywołania administracyjne API mające wpływ na projekty dostawców, obszary robocze, konta usług lub klucze.

Wyślij te zdarzenia do niezmiennego lub odpornego na manipulacje strumienia audytu. Trzymaj dane telemetryczne żądań o wysokiej kardynalności oddzielnie od dowodów kontroli o długim okresie przechowywania, jeśli pomaga to kontrolować koszty przechowywania, ale zachowaj klucze łączenia potrzebne do dochodzeń.

Plan migracji z kluczy współdzielonych

Zastępowanie kluczy współdzielonych można przeprowadzać stopniowo. Unikaj migracji typu „big-bang”, chyba że klucz został już naruszony.

1. Zidentyfikuj najbardziej obciążone klucze współdzielone. Uszereguj według wydatków, ruchu, dostępu do modelu i nieznanego właściciela.
2. Grupuj rozmówców w granicach obciążenia. Korzystaj z dzienników, repozytoriów źródłowych, zmiennych wdrożeniowych, agentów użytkownika i danych źródłowych sieci.
3. Utwórz konta usług o określonym zakresie. Zacznij od zadań produkcyjnych, które mają jasno określonych właścicieli i charakteryzują się wysokimi wydatkami lub wysokim ryzykiem.
4. Przejdź przez bramę. Zachowaj tymczasowo stary klucz dostawcy za bramą, jeśli bezpośrednia migracja dostawcy trwałaby dłużej.
5. Atrybucja podwójna. Porównaj ruch, koszty, błędy, opóźnienia i rozliczenia z dostawcą przed całkowitym ograniczeniem.
6. Zmieniaj dzwoniących. Aktualizuj wpisy tajne wdrożenia, zmienne CI i konfigurację aplikacji po jednym zadaniu na raz.
7. Unieważnij klucz współdzielony. Najpierw poddaj kwarantannie, jeśli promień wybuchu jest niejasny, a następnie unieważnij po upływie okna obserwacyjnego.

Celem nie jest jedynie obrócenie klucza. Celem jest zastąpienie niejednoznacznego dostępu tożsamością, zasadami, budżetem i dowodami należącymi do obciążenia.

Kompromisy w sposób wyraźny

Więcej kont usług poprawia kontrolę, ale zwiększa administrację. Konwencje nazewnictwa, metadane własności, zadania czyszczenia i przepływy pracy recenzowania zapewniają użyteczność modelu.

Federacja zmniejsza ryzyko związane z tajemnicą statyczną, ale zwiększa zależność od dostawcy tożsamości. Wymiana tokenów może zakończyć się niepowodzeniem ze względu na zmiany wystawcy, zmianę roszczeń, przesunięcie zegara lub zmiany konfiguracji CI. Zaprojektuj jasne tryby awarii i alerty.

Natywne kontrole dostawcy są cenne, ale niespójne. Niektórzy dostawcy w różny sposób przedstawiają projekty, obszary robocze, konta usług, budżety lub federację. Warstwa tożsamości na poziomie bramy zapewnia spójne zasady i raporty, ale musi zachować kontekst nadrzędny na potrzeby dochodzeń w sprawie limitów, rozliczeń i pomocy technicznej.

Krótkotrwałe poświadczenia zwiększają bezpieczeństwo, ale zwiększają złożoność środowiska wykonawczego. Ostrożnie przechowuj tokeny w pamięci podręcznej, przestrzegaj daty wygaśnięcia i unikaj uzależniania każdego żądania LLM od powolnego wywołania płaszczyzny kontrolnej.

Scentralizowane egzekwowanie poprawia zarządzanie, ale zwiększa odpowiedzialność platformy. Jeśli brama posiada zasady, budżety i atrybucję, musi być łatwo obserwowalna i dojrzała operacyjnie.

Lista kontrolna wdrożenia

• Utwórz spis kluczy ludzkich, tożsamości obciążeń, tożsamości CI, kluczy partnerów i danych uwierzytelniających typu break-glass.
• Określ konwencję nazewnictwa obejmującą aplikację, środowisko, zespół właścicieli i cel.
• Użyj jednego konta usługi na granicę obciążenia produkcyjnego.
• Powiąż każdą tożsamość z wąskimi projektami dostawców lub obszarami roboczymi.
• Ogranicz rodziny modeli, punkty końcowe, regiony, zasady dotyczące danych i budżety.
• Preferuj federację lub krótkotrwałą wymianę tokenów, jeśli jest obsługiwana.
• Przechowuj klucze statyczne tylko w scentralizowanym zarządzaniu sekretami.
• Wymagaj metadanych przypisania przy każdym żądaniu.
• Ustaw budżety kont usług i alerty o anomaliach.
• Logowanie poświadczeń, uprawnień, żądań, budżetu i zdarzeń cofnięcia.
• Wyłącz nieużywane konta przed ich usunięciem.
• Przeprowadź migrację kluczy współdzielonych według obciążenia, a następnie unieważnij stare dane uwierzytelniające.

Wniosek

Zarządzanie kontem usługi LLM to model operacyjny dostępu do produkcyjnej sztucznej inteligencji. Traktuj każdego nienadzorowanego wywołującego jako tożsamość obciążenia z właścicielem, celem, granicą uprawnień, budżetem i cyklem życia. Korzystaj z kont usług natywnych dostawcy tam, gdzie są pomocne, preferuj federację tam, gdzie jest to praktyczne, i normalizuj tożsamość na bramie, aby można było spójnie zarządzać OpenAI, Anthropic, Gemini i systemami wewnętrznymi.

Prognoza: platformy LLM będą w dalszym ciągu odchodzić od ogólnych kluczy statycznych w stronę modeli kont usług i tożsamości obciążeń. Zespoły, które ustanowią teraz odpowiedzialność za czyste obciążenie pracą, będą miały łatwiejszą ścieżkę do federacji dostawców, gotowości do audytu, zarządzania partnerem API i niezawodnej kontroli kosztów później.

Powiązane lektury

• API kluczowe zarządzanie zespołami