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

Ključevi nizlaznog API-ja i vjerodajnice uzlaznog pružatelja 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.

Praktični obrazac 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 koda aplikacije, konfiguracijskih datoteka modela, evidencije stanara 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 zahtjev kompatibilan s OpenAI-jem 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 API ključna dopuštenja računa usluge prema zadanim su postavkama pristup za čitanje i pisanje za API resurse projekta. OpenAI također izlaže Admin API ključne objekte odvojeno od uobičajenog korištenja API-ja za projekt/izvođenje. Anthropic dokumentira radne prostore kao organizacijsku granicu i navodi da krajnje točke Admin API-ja zahtijevaju ključeve Admin API-ja različite od standardnih API ključeva; Anthropic također napominje da su API ključevi vezani za radni prostor u kojem su stvoreni i ne mogu se premještati između radnih prostora. Googleova dokumentacija o Gemini API ključu kaže da je svaki Gemini API ključ povezan s Google Cloud projektom i preporučuje ograničenja API-ja kako bi se smanjila šteta 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:

• Vrednosti za zaključivanje tijekom izvođenja: koristi ih 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 izvješća o upotrebi, fakturama, troškovima ili organizaciji tamo 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 procjenu: koriste se u tijeku rada za usporedbu, osiguranje kvalitete, migraciju ili postavljanje. Trebali bi imati niske kvote, jasne oznake okoliša 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 pružatelja, 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 pokretati kontrolu pristupa, podobnost za usmjeravanje, upozoravanje i rotacijske tijekove rada. 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 dekriptirati 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.
• Promptni zapisnici ili rasponi praćenja.
• Korisni teret događaja analitike.
• CI varijable okrenute programerima.
• 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 dešifriranja. Razina 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 usluga, 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.

Praktični zapis vjerodajnica uključuje:

• credential_id: interni nepromjenjivi identifikator.
• pružatelj: 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 zakupac BYOK korisnika.
• 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.
• zdravstveni_status: nepoznato, zdravo, pogoršano, neovlašteno, iscrpljena kvota, onemogućeno.
• emergency_disable: trenutno blokiranje usmjeravanja neovisno o normalnom stanju pravila.

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

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.

Promet u vremenu izvođenja 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. Vjerodajnice administratora 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 identitet unutarnje usluge može je dohvatiti i zabilježite svaku upotrebu.

Preporuka: neka klasa vjerodajnica bude čvrsta granica autorizacije, a ne oznaka. Dispečer vremena izvođenja ne bi trebao biti u mogućnosti zatražiti dešifriranje za vjerodajnicu administratora čak i ako greška u konfiguraciji upućuje na njegov 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 opseg nizvodnog API ključa.
• Traženi profil modela ili ID modela specifičan za pružatelja usluge.
• 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.

Mehanizam bi trebao 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:

{
  "stanar_id": "stanar_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "pravila_podataka": "bez_zapisivanja_prompta",
  "credential_requirements": {
    "klasa": "vrijeme izvođenja",
    "okoliš": "proizvodnja",
    "tenant_binding": "stanar_42",
    "allowed_model_family": "tekst",
    "zdravstveni_status": "zdrav"
  },
  "odluka": "dopusti",
  "credential_id": "cred_8f2...",
  "audit_reason": "vjerodajnica stanara BYOK odgovara tekstualnom profilu vremena izvođenja i politici podataka"
}

Nemojte implementirati zamjenu kao "probajte 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.
• Nema upotrebe kao dijeljeni rezervni 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 agencije, preprodavače i automatizaciju Partner API-ja, 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 zdravlja 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 ispad pružatelja usluga. 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 tarifom i označene kao sintetički promet u telemetriji i naplati.

Provjere zdravlja trebale bi se izvoditi:

• Kod uvoza 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 nedostatke, 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 provjere zdravlja za predviđene krajnje točke, obitelji modela i granice računa.
3. Omogućite podobnost u sjeni za mali dio sigurnog sintetičkog ili niskorizičnog prometa gdje je to prikladno.
4. Proizvodni promet postupno premještajte sa stare vjerodajnice na novu vjerodajnicu.
5. Nadzirite pogreške, kašnjenje, kvotu i dodjelu 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 usluga i označite zapis trezora opozvanim.
8. Provjerite da se nakon opoziva ne pojavljuju dešifriranja ili pozivi pružatelja usluga preko stare vjerodajnice.

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 revizijske zapise za pregled incidenta.

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

Pravila pristupnika su neophodna, ali ograničenja na strani pružatelja usluga smanjuju radijus eksplozije ako je ključ ugrožen ili zloupotrijebljen. Za Gemini i druge API ključeve platforme u oblaku koristite ograničenja API-ja/usluga i prikladna 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 pod pritiskom može preskočiti.

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.
• Promijenjeni su metapodaci, uključujući dopuštene krajnje točke, vezanje stanara ili pravila podataka.
• Provjera ispravnosti izvršena i rezultat zabilježen.
• Vjerodajnica odabrana prema pravilima usmjeravanja za zahtjev.
• Dekriptiranje vjerodajnice zahtijeva interni identitet usluge.
• Poziv pružatelja nije uspio zbog pogreške autentifikacije, autorizacije, kvote ili ograničenja.
• Rotacija je započela, promet pomaknut, stare vjerodajnice opozvane.
• Omogućeno ili izbrisano onemogućavanje u hitnim slučajevima.
• Pristupljeno administratorskoj vjerodajnici 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 trebali bi 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.
• Napravite zasebne autorizacijske klase za vrijeme izvođenja, administratore, naplatu, procjenu i BYOK vjerodajnice.
• Povežite BYOK vjerodajnice s porijeklom računa stanara i pružatelja.
• Zahtijevajte odobrenje mehanizma pravila prije odabira bilo koje uzvodne vjerodajnice.
• Pokreni prompt-safe zdravstvene provjere prije prihvatljivosti proizvodnje.
• 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žavajte zapisnike revizije 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.

Zaključak koji se može poduzeti

Započnite inventariziranjem svih vjerodajnica uzvodnog pružatelja usluga koje trenutno koriste pristupnik, skripte, CI poslovi, evaluacijski pojasevi 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: razvojni programeri koji slijede primaju ključeve s opsegom pristupnika; sam pristupnik kontrolira pristup uzvodnog pružatelja usluga. To vam odvajanje omogućuje očuvanje najmanjih privilegija, dodjeljivanje zakupaca, točnost naplate, usmjeravanje podataka prema politici i sigurnu automatizaciju čak i dok se davatelji, projekti, radni prostori i korisnici BYOK-a množe.

Povezano čitanje

• upravljanje ključem API-ja za tim i odgovor na curenje
• pravila usmjeravanja s obzirom na zadržavanje podataka
• kontrole knjige naplate i pripisivanja troškova