Uzvodna provjera autentičnosti bez ključa za pristupnike AI API: obrazac federacije identiteta radnog opterećenja

Radnici proizvodnog pristupnika ne bi trebali nositi dugotrajne uzvodne API ključeve kada pružatelj može sam autentificirati radno opterećenje. Sigurniji je obrazac razmijeniti postojeći identitet u oblaku, Kubernetes, CI ili SPIFFE za kratkotrajnu vjerodajnicu pružatelja usluga, ispravno spremiti tu vjerodajnicu u predmemoriju i ograničiti je na najmanju korisnu granicu autorizacije.

Teži dio nije razmjena tokena. Obrađuje neujednačenu podršku pružatelja usluga, istodobna osvježavanja, mapiranje identiteta, iznimke kontrolne ravnine, prekide rada i migraciju bez stvaranja skrivene zamjene na široko privilegirani dijeljeni ključ.

Počnite s mogućnostima provjere autentičnosti, a ne globalnom postavkom bez ključa

Činjenica: Podrška za autentifikaciju razlikuje se ovisno o pružatelju usluge i operaciji. OpenAI i Anthropic podržavaju federaciju identiteta radnog opterećenja za API radna opterećenja. Azure OpenAI podržava Microsoft Entra ID i upravljane identitete. Google Cloud podržava priložene račune usluga, zadane vjerodajnice aplikacije i Federaciju identiteta radnog opterećenja za vanjska radna opterećenja. Međutim, zaključivanje vremena izvođenja i administrativni API-ji ne prihvaćaju nužno iste vrste vjerodajnica.

Na primjer, OpenAI tokeni identiteta radnog opterećenja trenutno ne mogu pozvati Admin API krajnje točke. Gateway stoga ne može sigurno predstavljati autentifikaciju kao jedno polje na razini pružatelja usluga kao što je auth_mode: federated.

Preporuka: Izgradite matricu mogućnosti prema računu davatelja, obitelji krajnjih točaka, okruženju i radnoj klasi:

Pohranite ovu matricu kao verzioniranu konfiguraciju. Pristup ruti trebao bi odbiti operaciju kada njezin konfigurirani identitet ne može zadovoljiti potrebnu sposobnost provjere autentičnosti. Ovo spada u AI API kontrolnu razinu za razvojne timove, a ne u nedokumentirane varijable okoline na pojedinačnim radnicima.

Postavite posrednika vjerodajnica između usmjerivača i adaptera pružatelja usluga

Adapteri pružatelja usluga ne bi trebali samostalno dohvaćati vjerodajnice metapodataka, konstruirati tvrdnje ili upravljati osvježavanjem tokena. Predstavite brokera vjerodajnica s jednim uskim sučeljem:

Credential acquire(CredentialRequest request)

CredentialRequest {
  provider_account_id
  workload_identity_id
  operation_class
  target_service_account
  audience
  scopes
}

Credential {
  value
  expires_at
  authorization_context
  provenance
}

Vrijednost vjerodajnice je osjetljiva i mora ostati u memoriji ili odobrenoj efemernoj predmemoriji. Kontekst autorizacije bilježi projekt pružatelja, račun usluge, opsege, uloge ili ograničenja implementacije predstavljena tokenom. Podrijetlo identificira kako je stečeno, kao što je oidc_exchange, managed_identity, adc ili break_glass.

Ovaj ugovor održava neutralnost davatelja usmjeravanja uz očuvanje detalja potrebnih za autorizacijske provjere i telemetriju. Također sprječava višemodelni API pristupnik za timove da svaki token nositelja tretira kao zamjenjiv.

Upotreba adaptera za akviziciju specifičnih za pružatelja usluga

Svaki adapter za akviziciju treba izvoditi samo korake koje zahtijeva njegov pružatelj:

• Nabavite vanjsku tvrdnju iz lokalnog izvora identiteta, kao što je Kubernetes projiciran token servisnog računa, usluga metapodataka u oblaku ili SPIFFE radno opterećenje API.
• Zatražite točnu publiku koju očekuje pružatelj ili konfigurirano pravilo federacije.
• Razmijenite tvrdnju kada pružatelj zahtijeva token razmjena.
• Vrati rezultirajuće vjerodajnice i vrijeme isteka autoritativnog.
• Klasificiraj greške kao pogreške lokalnog identiteta, razmjene, autorizacije, konfiguracije ili dostupnosti pružatelja usluga.

Vertex AI OpenAI-kompatibilna krajnja točka koristan je primjer odvajanja: aplikacija može dobiti Google pristupni token putem zadanih vjerodajnica aplikacije i dostaviti taj token kao OpenAI klijentovu vjerodajnicu. Adapter protokola ostaje OpenAI-kompatibilan, dok dobivanje vjerodajnica ostaje Google-specifično.

Omogućite autorizaciju predmemorije tokena

Činjenica: Federativne vjerodajnice kratko traju. OpenAI tokeni za pristup identitetu radnog opterećenja traju najviše jedan sat, ne mogu nadživjeti vanjski token subjekta ili potvrđeni certifikat i izdaju se bez tokena za osvježavanje. Radno opterećenje mora ponoviti razmjenu prije isteka.

Ključ predmemorije mora uključivati svaku dimenziju koja može promijeniti rezultirajuće ovlaštenje:

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

Izostavljanje ciljnog računa, publike ili opsega može dovesti do toga da radnik ponovno upotrijebi važeći token u pogrešnom kontekstu autorizacije. To je opasnije od promašaja predmemorije.

Osvježi prije isteka koristeći sigurnosnu marginu i nasumično podrhtavanje. Jedno praktično pravilo je:

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

Točna margina trebala bi uzeti u obzir izobličenje sata, latenciju razmjene, vrijeme ponovnog pokušaja i najduži očekivani zahtjev. Nemojte osvježavati samo na fiksnom mjeraču vremena odvojenom od expires_at.

Spriječite oluje razmjene s jednokratnim osvježavanjem

Kada mnogo zahtjeva naiđe na isti token pred istekom, samo jedno izvršenje treba izvršiti razmjenu. Ostali pozivatelji trebali bi nastaviti koristiti postojeću vjerodajnicu dok je unutar dopuštenog prozora ili kratko pričekati rezultat zajedničkog osvježavanja.

Koristite jednokratno zaključavanje po ključu predmemorije. U implementaciji s više procesa ili više čvorova, odlučite može li svaki radnik održavati vlastitu predmemoriju ili mora li se koordinacija osvježavanja distribuirati. Lokalna predmemorija je jednostavnija, ali povećava volumen razmjene. Distribuirana predmemorija smanjuje razmjene, ali proširuje granicu osjetljivih tokena i zahtijeva šifrirani prijenos, strogu kontrolu pristupa i pažljivo izbacivanje.

Preporuka: Preferirajte predmemorije u procesu osim ako ograničenja pružatelja ili veličina flote ne pokazuju potrebu za uslugom dijeljenog tokena. Prvo koordinirajte osvježavanja unutar svakog procesa, a zatim izmjerite volumen razmjene.

Povezivanje identiteta s točnim zahtjevima za radnim opterećenjem

Federacija premješta povjerenje s pohranjenog ključa na tvrdnje o identitetu. Permisivno mapiranje stoga može biti jednako opasno kao i procurila dijeljena vjerodajnica.

Potvrdite izdavatelja i namjeravanu publiku, a zatim povežite mapiranje s nepromjenjivim ili strogo kontroliranim zahtjevima. Za Kubernetes uključite imenski prostor i račun usluge umjesto da vjerujete bilo kakvom radnom opterećenju u klasteru. Za CI ograničite repozitorij, tijek rada, okruženje i zaštićenu granu ili kontekst postavljanja. Za identitete u oblaku mapirajte određenog principala radnog opterećenja umjesto cijelog zakupca ili organizacije.

Stvorite odvojene upstream servisne račune ili upravljane identitete za proizvodnju, prikazivanje, pozadinske poslove i administrativnu automatizaciju. Ograničite svaki identitet na modele, projekte, radne prostore, implementacije i API operacije koje su mu potrebne.

Činjenica: OpenAI može ograničiti preslikavanja identiteta radnog opterećenja s dopuštenjima API. Anthropic suradnici su razmijenili vjerodajnice s računom usluge i upozoravaju da je federacija sigurna onoliko koliko je sigurna konfiguracija uzlaznog identiteta. Upravljani identiteti i IAM u oblaku na sličan način ovise o točno definiranim dodjelama uloga.

Odvojite vjerodajnice za vrijeme izvođenja od administrativnih vjerodajnica

Radnik za zaključivanje nikada ne bi trebao naslijediti token organizacijskog administratora samo zato što ga neki zadatak kontrolne razine još uvijek treba. Podijelite sustav na dvije sigurnosne granice:

• Ravan vremena izvođenja: Obrađuje zahtjeve modela i prima samo udružene ili upravljane vjerodajnice s opsegom zaključivanja.
• Upravljačka razina: Obavlja administraciju projekta, radnog prostora, naplate ili računa usluge kroz izolirane poslove s zasebno pohranjenim vjerodajnicama i jačim odobrenjem kontrole.

Administrativne vjerodajnice ne bi smjele imati put do varijabli okruženja za vrijeme izvođenja, specifikacija podova, skupova za otklanjanje pogrešaka ili predmemorija tokena. Zabilježite njihovu upotrebu u istom sustavu revizije samo za dodavanje koji se koristi za promjene konfiguracije.

Greška zatvorena bez improviziranog oporavka

Preporuka: Nemojte automatski zamijeniti neuspjelu federacijsku razmjenu zajedničkim statičkim ključem. Automatsko vraćanje može zaobići opozvano mapiranje, sakriti netočnu publiku ili vratiti pristup koji je administrator identiteta namjerno uklonio.

Vrati klasificiranu pogrešku uzlazne provjere autentičnosti, zaustaviti slanje na pogođeni račun davatelja i dopustiti uobičajenoj politici usmjeravanja da odabere drugog davatelja samo kada je ta alternativa dopuštena za stanara i radno opterećenje. Zamjenski model i zamjenska vjerodajnica različite su odluke.

Ključ za razbijanje stakla još uvijek može biti opravdan za teške prekide davatelja identiteta. Neka bude onemogućen ili nedostupan u normalnom radu. Aktivacija bi trebala zahtijevati ovjereno odobrenje, imati fiksni istek, ograničiti pogođeni račun pružatelja usluga i operacije te upozoriti na svaki zahtjev upućen s njim. Njegovo porijeklo mora se pojaviti u telemetriji zahtjeva.

Migracija jednog po jednog skupa usmjeravanja

1. Vrijeme izvođenja inventara i administrativne vjerodajnice. Odredite koji procesi mogu čitati svaki od njih.
2. Stvorite namjenski identitet radnog opterećenja i račun usluge pružatelja uskog opsega.
3. Konfigurirajte točna mapiranja izdavača, publike, subjekta i dopuštenja.
4. Dodajte provjeru prije leta koja stječe token i poziva dopuštenu krajnju točku s malim utjecajem.
5. Canary a mali skup usmjeravanja koji koristi samo federaciju. Ne ostavljajte uključen automatski povratni ključ tijekom testa.
6. Usporedite neuspjele provjere autentičnosti, latenciju razmjene, starost tokena i rezultate autorizacije pružatelja usluga s postojećim putem.
7. Postupno povećavajte promet i promatrajte barem jedan potpuni ciklus osvježavanja tokena.
8. Uklonite stari ključ iz pristupa za vrijeme izvođenja, a zatim ga opozovite nakon definiranog opažanja razdoblje.

Ponovite ovaj postupak prema računu davatelja i okruženju. Globalno presjecanje otežava razlikovanje pogreške mapiranja identiteta od ponašanja tokena specifičnog za pružatelja usluga.

Instrumentirajte i testirajte načine kvara

Bilježi kašnjenje razmjene tokena, pokušaje osvježavanja, neuspjele osvježavanja, starost vjerodajnice, izdavatelja, mapiranog principala, račun pružatelja, radnu klasu i kategoriju pogreške provjere autentičnosti. Nikada nemojte bilježiti pristupne tokene, vanjske tvrdnje, klijentske tajne ili potpuna autorizacijska zaglavlja.

Prije nego što udruživanje postane jedini proizvodni put, testirajte:

• Odstupanje sata između radnika, pružatelja identiteta i usluga tokena pružatelja.
• Nedostupnost krajnje točke identiteta poslužitelja metapodataka ili radnog opterećenja.
• Istekle tvrdnje i netočna publika.
• Uklanjanje uloga i pravilo federacije onemogućavanje.
• Prigušivanje razmjene tokena i privremene pogreške pružatelja.
• Istodobno osvježavanje pod vršnim prometom.
• Rotacija ključa za potpisivanje dok stari tokeni ostaju važeći.

Za rotaciju izdavača OIDC-a, objavite stare i nove ključeve za potpisivanje s dovoljnim preklapanjem za predmemorije verifikatora i izdane tokene. OpenAI dokumentira predmemoriju od 600 sekundi za otkrivanje i udaljene JWKS podatke, s JWKS osvježavanjem kada token upućuje na nepoznati ID ključa. Nemojte pretpostavljati da se svaki verifikator ponaša identično; test rotacije sa živim kanarincima.

Usvojite autentifikaciju vremena izvođenja bez ključa kao ograničenu migraciju

Cilj nije tvrditi da gateway ne sadrži tajne. Radi se o uklanjanju dugotrajnih ključeva pružatelja usluga iz radnog vremena velikog volumena i ograničavanju neizbježnih administrativnih vjerodajnica na manju granicu kontrolne razine.

Počnite s matricom mogućnosti, brokerskim vjerodajnicama kroz jedno sučelje, predmemorirajte prema autorizacijskom kontekstu, koristite točna mapiranja identiteta i neuspješno zatvaranje zbog pogreške razmjene. Dovršite migraciju samo nakon promatranja uspješnih testova osvježavanja, opoziva, ispada i rotacije ključeva potpisivanja. To proizvodi put izvođenja bez ključa čija se dostupnost i ponašanje autorizacije razumiju, a ne pretpostavljaju.

Povezana literatura

• provjera vjerodajnica pružatelja prije usmjeravanja proizvodnog prometa