Trezori vjerodajnica davatelja za AI pristupnike s više modela: odvojeno vrijeme izvođenja, administratorski, naplatni i BYOK pristup

Dolazni API ključevi i vjerodajnice pružatelja uzlaznih usluga rješavaju različite probleme. Ključ razvojnog programera koji izdaje vaš pristupnik identificira aplikaciju, tim, zakupca, proračun i kontekst pravila. Uzlazni ključ pružatelja omogućuje pristupniku da troši novac i pristupa modelima na računu pružatelja. Tretirajući ih kao istu vrstu tajne je način na koji timovi završavaju s jednim neograničenim ključem u zajedničkom projektu, administratorskim vjerodajnicama u uslugama izvođenja i bez pouzdanog načina da se odgovori koji je stanar uzrokovao koju naplatu na strani pružatelja usluga.

Praktični uzorak je trezor vjerodajnica pružatelja: namjenska kontrolna ravnina za uvoz, klasificiranje, pohranjivanje, odabir, rotiranje i reviziju uzvodnih vjerodajnica. Trebao bi se nalaziti iza usmjerivača, knjige naplate, mehanizma pravila i tijeka rada—ne unutar aplikacijskog koda, konfiguracijskih datoteka modela, zapisa zakupaca ili analitičkih događaja.

Problem čitača: uzvodne vjerodajnice postaju nevidljiva infrastruktura

Većina implementacija više modela počinje s jednostavnim ciljem: usmjerite jedan OpenAI-kompatibilan zahtjev najboljem dostupnom pružatelju usluga. Zatim se pojavljuje više računa: jedan projekt pružatelja za proizvodnju, drugi za evaluaciju, Anthropic radni prostor za poslovnu jedinicu, Google Cloud projekt za Gemini i nekoliko ključeva koje su dostavili korisnici za BYOK ugovore.

Rizik nije samo tajno curenje. To je gubitak konteksta autorizacije. Valjani ključ pružatelja možda tehnički može pozvati krajnju točku, ali pristupnik i dalje mora znati je li taj ključ dopušten za ovog zakupca, ovu obitelj modela, ovu politiku zadržavanja podataka, ovaj proračun, ovu regiju i ovaj put automatizacije.

Činjenica: platforme pružatelja usluga izlažu različite granice računa i vrste vjerodajnica. OpenAI dokumentira projekte i račune usluga, a račun usluge API zadane su dozvole ključa za pristup čitanju i pisanju za API resurse projekta. OpenAI također izlaže Admin API ključne objekte odvojeno od uobičajenog korištenja API projekta/vremena izvođenja. Anthropic dokumentira radne prostore kao organizacijsku granicu i navodi da krajnje točke Admin API zahtijevaju ključeve Admin API različite od standardnih ključeva API; Anthropic također napominje da su ključevi API vezani za radni prostor u kojem su stvoreni i ne mogu se premještati između radnih prostora. Dokumentacija ključa Google Gemini API kaže da je svaki ključ Gemini API povezan s Google Cloud projektom i preporučuje API ograničenja za smanjenje štete ako je ključ ugrožen.

Preporuka: nemojte izraditi jedno generičko polje “provider_key” i zvati ga gotovim. Izgradite inventar vjerodajnica koji čuva granice specifične za davatelja usluga dok izlaže normalizirani model pravila pristupniku.

Definirajte taksonomiju vjerodajnica prije prihvaćanja ključeva

Trezor bi trebao odbiti dvosmislene vjerodajnice. U trenutku uvoza, operater ili tijek rada automatizacije mora klasificirati vjerodajnicu. Koristite najmanje ove kategorije:

• Vrednice za zaključivanje vremena izvođenja: koje koristi pristupnik za pozivanje krajnjih točaka zaključivanja modela kao što su chat, odgovori, ugrađivanja, moderiranje, transkripcija ili generiranje slika, ovisno o podršci pružatelja usluga.
• Administratorske vjerodajnice za automatizaciju: koriste se za upravljanje organizacijama, radnim prostorima, projektima, korisnicima, ključevima ili administrativnim resursima na strani pružatelja usluga. Oni nikada ne bi smjeli biti na stazi zahtjeva za vrijeme izvođenja.
• Akreditivi za naplatu i izvješćivanje: koriste se za dohvaćanje korištenja, faktura, troškova ili izvješća organizacije gdje pružatelji usluga podržavaju te API-je. Držite ih odvojeno od ključeva zaključivanja tako da poslovi izvješćivanja ne mogu generirati korištenje modela.
• Vrednice samo za evaluaciju: koriste se u tijeku rada za usporedbu, osiguranje kvalitete, migraciju ili postavljanje. Trebali bi imati niske kvote, jasne oznake okruženja i ne ispunjavati uvjete za rezervnu proizvodnju.
• Korisničke BYOK vjerodajnice: ključevi koje je dostavio korisnik vezani su za određenog zakupca, račun davatelja, ugovor i politiku podataka. Ne bi se trebali objedinjavati u zajedničko usmjeravanje osim ako korisnik to izričito ne odabere.

Ova taksonomija nije samo dokumentacija. Trebao bi upravljati kontrolom pristupa, podobnošću usmjeravanja, upozoravanjem i rotacijom radnih procesa. Ako se vjerodajnica uveze bez kategorije, vlasnika, granice računa davatelja i dopuštene upotrebe, trebala bi ostati onemogućena.

Pohranjujte tajne u trezor, a ne u evidenciju proizvoda

Trezor bi trebao biti jedina komponenta koja može dešifrirati uzvodne vjerodajnice. Drugi sustavi mogu pohranjivati reference, hashove, statusna polja i metapodatke pravila, ali ne i samu vrijednost vjerodajnice.

Nemojte pohranjivati uzvodne tajne na ovim mjestima

• Reci profila stanara.
• Konfiguracijske datoteke za usmjeravanje modela.
• Zapisnici upita ili rasponi praćenja.
• Korisni teret događaja analitike.
• CI varijable okrenute razvojnom programeru.
• Ulaznice za podršku, alati za chat ili snimke zaslona.

Korisni dizajn trezora ima dvije ravnine. Tajni avion pohranjuje kriptirani vjerodajnički materijal i strogo kontrolira operacije dekriptiranja. Ravan metapodataka pohranjuje netajne atribute koje koristi usmjeravanje i upravljanje. Usmjerivač bi obično trebao samo ID vjerodajnice i kratkotrajno dohvaćanje tajne u memoriji u vrijeme otpreme, a ne pristup širokoj bazi podataka svakom ključu pružatelja usluga.

Zaštitite trezor kao visokovrijednu infrastrukturu: enkripcija omotnice ili upravljani KMS, strogi identiteti usluge, postupci razbijanja stakla, testiranje sigurnosne kopije i vraćanja, pregled pristupa i upozorenje o neuobičajenom volumenu dekriptiranja. Središnji trezor pojednostavljuje upravljanje, ali također koncentrira rizik. To je kompromis.

Priloži metapodatke pravila svakoj vjerodajnici

Model metapodataka trebao bi biti dovoljno eksplicitan da pristupnik može odlučiti je li vjerodajnica prihvatljiva prije nego što dodirne krajnju točku pružatelja usluga.

Praktični zapis vjerodajnica uključuje:

• credential_id: interni nepromjenjivi identifikator.
• provider: OpenAI, Anthropic, Gemini, Azure OpenAI ili neki drugi adapter.
• provider_account_boundary: organizacija, projekt, radni prostor, projekt u oblaku, pretplata ili ekvivalent.
• credential_class: vrijeme izvođenja, administrator, naplata, procjena ili BYOK.
• okruženje: produkcija, postavljanje, razvoj, evaluacija, sandbox.
• tenant_binding: dijeljena vjerodajnica platforme, jedan zakupac, grupa zakupaca ili korisnik BYOK zakupac.
• allowed_model_families: na primjer, generiranje teksta, ugrađivanja, vizije, slike, zvuka ili specifični profili modela.
• allowed_endpoints: normalizirane mogućnosti pristupnika mapirane na krajnje točke pružatelja usluga.
• data_policy: dopuštena klasa zadržavanja, klasa zapisivanja, zahtjev prebivališta i ograničenja značajki.
• budget_scope: mjesto troška, kupac preprodavača, interni odjel ili ugovor.
• vlasnik: imenovani tim ili odgovorna osoba.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: nepoznato, ispravno, degradirano, neovlašteno, quota_exhausted, onemogućeno.
• emergency_disable: neposredni blok usmjeravanja neovisno o normalnom stanju pravila.

Držite ovaj model neutralnim prema pružatelju, ali nemojte brisati stvarnost pružatelja. Ključ Anthropic vezan za radni prostor i ključ Gemini povezan s projektom u oblaku Google nisu međusobno zamjenjivi samo zato što oba mogu generirati tekst. Pristupniku je to porijeklo potrebno za revizije, storniranje i sigurno prebacivanje.

Odvojeni pristup vremenu izvođenja, administratoru i naplati

Najvažnije pravilo je jednostavno: ključ koji se koristi za zaključivanje vremena izvođenja ne bi trebao upravljati organizacijama pružatelja usluga, radnim prostorima, korisnicima, projektima ili administrativnim resursima.

Runtime promet je velik i izložen najvećoj radnoj površini. Prolazi kroz usmjerivače zahtjeva, logiku ponovnog pokušaja, rukovatelje strujanjem, adaptere modela i tijekove rada incidenta. Administratorske vjerodajnice su niske učestalosti i velikog utjecaja. Oni bi trebali živjeti iza zasebnog puta odobrenja s kratkim TTL-ovima, imenovanim ljudskim odobrenjem gdje je to prikladno, jakim zapisivanjem i bez podobnosti za usmjeravanje tijekom izvođenja.

Akreditivi za naplatu također zaslužuju odvajanje. Posao izvješćivanja koji usklađuje fakture ne bi trebao moći generirati dovršetke, a ključ za zaključivanje vremena izvođenja ne bi trebao biti jedini način za dohvaćanje izvješća o korištenju. Kada pružatelj usluga ne nudi precizno odvajanje, nadoknadite to u pristupniku: izolirajte vjerodajnicu, ograničite koji interni identitet usluge je može dohvatiti i zabilježite svaku upotrebu.

Preporuka: neka klasa vjerodajnica bude granica autorizacije, a ne oznaka. Runtime dispecher ne bi trebao biti u mogućnosti zatražiti dešifriranje za administratorsku vjerodajnicu čak i ako greška u konfiguraciji upućuje na njen ID.

Izradite mehanizam pravila za odabir vjerodajnica

Odabir vjerodajnice trebao bi se dogoditi nakon što pristupnik provjeri autentičnost nizvodnog pozivatelja i prije pokušaja bilo kakvog poziva davatelja usluga. Motor za pravila trebao bi spojiti nekoliko ulaza:

• ID stanara i nizvodni API opseg ključa.
• Traženi profil modela ili ID modela specifičan za pružatelja usluga.
• Mogućnosti krajnje točke: chat, ugradnje, slike, zvuk, serija, datoteke, alati ili automatizacija administratora.
• Zahtjevi za zadržavanje podataka i boravak.
• Proračun, kreditna rezervacija i mjesto troška.
• Stanje ograničenja brzine i pritisak na kvotu.
• Metapodaci vjerodajnica, zdravlje, okoliš i vezanje stanara.

Mašina bi trebala vratiti jedan od tri rezultata: dopustiti s odabranom vjerodajnicom, odbiti s razlogom pravila ili zahtijevati odobrenje. Odbijanja bi trebala biti dovoljno precizna da operativni timovi riješe problem bez otkrivanja tajnog materijala programerima.

Primjer odluke:

{
  "tenant_id": "tenant_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "environment": "production",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "healthy"
  },
  "decision": "allow",
  "credential_id": "cred_8f2...",
  "audit_reason": "tenant BYOK credential matches runtime text profile and data policy"
}

Nemojte implementirati zamjenu kao "pokušajte sljedeći ključ." Zamjena mora ponovno pokrenuti pravilo. Vjerodajnica dijeljene platforme može biti valjana za pristup davatelja usluga, ali nevažeća za korisnika koji koristi samo BYOK. Vjerodajnica u drugom projektu može imati kvotu, ali može kršiti zahtjeve za dodjelu troškova ili zadržavanje.

Upravljajte BYOK-om kao pristupom u vlasništvu stanara, a ne slobodnim kapacitetom

BYOK mijenja model povjerenja. Korisnik je dostavio vjerodajnicu kako bi se njegov promet mogao naplaćivati, upravljati ili izolirati unutar računa njegovog pružatelja usluga. Ta vjerodajnica trebala bi biti povezana s porijeklom računa kupca zakupca i pružatelja usluga.

Preporučene BYOK kontrole:

• Jedan zapis trezora po klijentu, pružatelju usluga, granici računa i okruženju.
• Nema usmjeravanja preko BYOK vjerodajnica.
• Ne koristi se kao zajednički zamjenski kapacitet osim ako korisnik to izričito ne odabere.
• Korisniku vidljivo zdravstveno stanje koje ne otkriva neobrađeni ključ.
• Odvojeni radni tijek rotacije koji korisniku omogućuje dodavanje zamjene prije nego što se stari ključ onemogući.
• Jasna atribucija u analizi upotrebe i fakturama: stanar pristupnika, granica računa davatelja, ID vjerodajnice, profil modela i ID praćenja zahtjeva.

Za automatizaciju agencija, prodavača i partnera API, BYOK može biti složeniji jer usluga može programski osigurati zakupce i vjerodajnice. I dalje vrijedi isto pravilo: automatizacija može uvesti i vezati vjerodajnice, ali ne bi trebala zamagliti vlasništvo stanara.

Dodajte provjere stanja prije leta bez curenja upita

Akreditiv može biti neuspješan iz mnogo razloga: opozvan ključ, pogrešan radni prostor, nedostajući pristup modelu, onemogućena naplata, iscrpljenost kvote, ograničenje krajnje točke, neusklađenost regionalnih pravila ili prekid rada pružatelja. Otkrivanje toga tek nakon što stigne zahtjev za proizvodnju stvara bučne incidente.

Koristite provjere ispravnosti koje provjeravaju sposobnost bez slanja korisničkih upita. Sintetička provjera može pozvati minimalnu krajnju točku, navesti dopuštene modele gdje je to prikladno ili poslati bezopasni fiksni upit ako je to jedina praktična opcija. Neka ove provjere budu jeftine, ograničene stopom i označene kao sintetički promet u telemetriji i naplati.

Provjere zdravlja trebale bi se izvoditi:

• Pri uvozu vjerodajnica.
• Prije omogućavanja vjerodajnice za proizvodno usmjeravanje.
• Nakon promjena ograničenja na strani pružatelja usluge.
• Tijekom prekida rotacije.
• Povremeno za vjerodajnice s podobnošću za proizvodnju.

Kompromis: automatizirane provjere rano hvataju ključeve koji su istekli ili su pod dometom, ali loše dizajnirane provjere mogu stvoriti nepotrebne pozive pružatelja usluga, buku pri naplati ili lažne alarme tijekom prekida pružatelja usluga. Pohranite rezultat ispravnosti s vremenskom oznakom, klasom pogreške davatelja, testiranom krajnjom točkom i testiranom obitelji modela. Nemojte pohranjivati ​​tajne vrijednosti ili osjetljive upite.

Rotirajte s dva utora, a ne jednom riskantnom zamjenom

Rotacija vjerodajnica ne bi trebala biti brisanje i molitva. Koristite model rotacije s dva utora:

1. Uvezi zamjensku vjerodajnicu kao neaktivnu, s punim metapodacima i vlasnikom.
2. Pokrenite sintetičke zdravstvene provjere za predviđene krajnje točke, obitelji modela i granicu računa.
3. Omogućite podobnost u sjeni za mali dio sigurnog sintetičkog ili niskorizičnog prometa gdje je to prikladno.
4. Postupno prebacite proizvodni promet sa stare vjerodajnice na novu vjerodajnicu.
5. Praćenje pogrešaka, latencije, kvote i dodjele troškova prema ID-u vjerodajnice.
6. Zamrzni vraćanje na staru vjerodajnicu nakon što nova vjerodajnica postane stabilna.
7. Opozovite staru vjerodajnicu kod davatelja i označite zapis trezora opozvanim.
8. Provjerite da nema dešifriranja ili poziva davatelja preko stare vjerodajnice nakon opoziva.

Rokovi rotacije trebali bi biti vidljivi u prikazima operacija i upozorenjima. Za rotaciju u hitnim slučajevima potreban je kraći put: onemogućite vjerodajnice, blokirajte usmjeravanje, omogućite odobrenu zamjenu i sačuvajte sve zapise revizije za pregled incidenta.

Ograniči ključeve pružatelja tamo gdje pružatelj to podržava

Pravila pristupnika su neophodna, ali ograničenja na strani pružatelja smanjuju radijus eksplozije ako je ključ ugrožen ili zloupotrijebljen. Za ključeve Gemini i druge API platforme u oblaku koristite API/uslužna ograničenja i odgovarajuća ograničenja aplikacija gdje su dostupna. Za projekte pružatelja usluga, radne prostore i račune usluga izbjegavajte široke organizacijske privilegije kada je dovoljan runtime ključ s opsegom projekta.

Preporuka: održavajte kontrolni popis ograničenja na strani pružatelja za svaku klasu vjerodajnica. Kontrolni popis trebao bi biti dio odobrenja uvoza i rotacije, a ne zasebni sigurnosni zadatak koji se može preskočiti pod pritiskom.

Kompromis: ograničenja na strani pružatelja dodaju operativne troškove. Nove krajnje točke, obitelji modela, regije ili značajke automatizacije mogu zahtijevati promjene pravila i ograničenja. To je bolje nego nakon curenja otkriti da jedan ključ može pristupiti svakom radnom opterećenju u zajedničkom projektu.

Vodite zapisnik revizije vjerodajnica samo za dodavanje

Revizijski trag trebao bi odgovoriti tko je uvezao vjerodajnicu, što mu je dopušteno učiniti, koje su odluke o usmjeravanju odabrale, kada nije uspjelo i kada je rotirano ili opozvano.

Zabilježite ove događaje:

• Izrađena ili uvezena vjerodajnica.
• Metapodaci su promijenjeni, uključujući dopuštene krajnje točke, vezanje stanara ili pravila podataka.
• Provjera zdravlja izvršena i rezultat zabilježen.
• Vjerodajnica odabrana prema pravilima usmjeravanja za zahtjev.
• Dešifriranje vjerodajnice zahtijeva interni identitet usluge.
• Poziv pružatelja nije uspio zbog pogreške autentifikacije, autorizacije, kvote ili ograničenja.
• Rotacija započeta, promet pomaknut, stara vjerodajnica opozvana.
• Omogućeno ili izbrisano onemogućavanje u hitnim slučajevima.
• Pristup administratoru ili vjerodajnici za razbijanje stakla.

Ne stavljajte neobrađene vrijednosti vjerodajnica u revizijske događaje. Koristite ID-ove vjerodajnica, granice računa davatelja, ID-ove zahtjeva za praćenje, identitete aktera i razloge odluke o politici. Za veliki promet u vremenu izvođenja, možete uzorkovati detaljnu dekriptiranu telemetriju, ali odabir usmjeravanja i dodjela troškova trebaju ostati dovoljno potpuni za naplatu i odgovor na incident.

Popis za provjeru implementacije

• Stvorite taksonomiju vjerodajnica i odbacite neklasificirani uvoz.
• Premjestite sve tajne pružatelja usluga u namjenski šifrirani trezor.
• Pohranjujte metapodatke o usmjeravanju odvojeno od tajnog materijala.
• Učinite vjerodajnice za vrijeme izvođenja, administraciju, naplatu, procjenu i BYOK zasebnim klasama autorizacije.
• Povežite BYOK vjerodajnice s porijeklom računa zakupca i davatelja.
• Zahtijevajte odobrenje mehanizma pravila prije odabira bilo koje upstream vjerodajnice.
• Pokreni prompt-safe zdravstvene provjere prije ispunjavanja uvjeta za proizvodnju.
• Koristite rotaciju u dva mjesta s postupnim prebacivanjem prometa i opozivom na strani pružatelja usluga.
• Primijenite ograničenja na strani pružatelja usluga gdje god su dostupna.
• Održavanje revizijskih zapisa samo za dodavanje za uvoz, upotrebu, kvarove, rotaciju i opoziv.
• Zadržite administratorske vjerodajnice iza kontrola razbijenog stakla: kratki TTL, imenovano odobrenje, snažno bilježenje, bez upotrebe vremena izvođenja.

Poduzimajući zaključak

Započnite popisom svih vjerodajnica uzlaznog pružatelja usluga koje trenutačno koriste pristupnik, skripte, CI poslovi, pojasevi za procjenu i partnerska automatizacija. Za svaki od njih dodijelite klasu, vlasnika, granicu računa davatelja, vezanje stanara, dopuštene krajnje točke, dopuštene obitelji modela, rok rotacije i status onemogućavanja u hitnim slučajevima. Sve što ne možete klasificirati treba onemogućiti ili staviti u karantenu dok ne dobije jasnu svrhu.

Zatim primijenite jedno arhitektonsko pravilo: daljnji programeri primaju ključeve s opsegom pristupnika; sam pristupnik kontrolira pristup uzvodnog pružatelja usluga. To vam odvajanje omogućuje očuvanje najmanjih privilegija, dodjelu zakupaca, točnost naplate, usmjeravanje podataka prema politici i sigurnu automatizaciju čak i dok se davatelji, projekti, radni prostori i korisnici BYOK-a umnožavaju.

Povezano čitanje

• timski API upravljanje ključevima i curenje odgovor
• pravila usmjeravanja koja su svjesna zadržavanja podataka
• kontrole knjige naplate i dodjele troškova