Seifuri de acreditări ale furnizorului pentru gateway-uri AI cu mai multe modele: timp de execuție separat, acces administrativ, facturare și acces BYOK

Cheile API în aval și acreditările furnizorului în amonte rezolvă diferite probleme. O cheie de dezvoltator emisă de gateway-ul dvs. identifică aplicația, echipa, chiriașul, bugetul și contextul politicii. O cheie de furnizor în amonte permite gateway-ului să cheltuiască bani și să acceseze modele într-un cont de furnizor. Tratarea acestora ca pe același tip de secret este modul în care echipele ajung cu o cheie nerestricționată într-un proiect partajat, acreditări de administrator în serviciile de execuție și nicio modalitate fiabilă de a răspunde ce chiriaș a cauzat ce debit pentru furnizor.

Modelul practic este un seif pentru acreditările furnizorului: un plan de control dedicat pentru importarea, clasificarea, stocarea, selectarea, rotirea și auditarea acreditărilor în amonte. Ar trebui să se afle în spatele routerului, registrului de facturare, motorului de politici și fluxului de lucru operațional, nu în interiorul codului aplicației, fișierelor de configurare a modelului, înregistrărilor chiriașilor sau evenimentelor de analiză.

Problema cititorului: acreditările din amonte devin infrastructură invizibilă

Majoritatea implementărilor cu mai multe modele încep cu un obiectiv simplu: direcționați o solicitare compatibilă cu OpenAI către cel mai bun furnizor disponibil. Apoi apar mai multe conturi: un proiect de furnizor pentru producție, altul pentru evaluare, un spațiu de lucru antropic pentru o unitate de afaceri, un proiect Google Cloud pentru Gemini și mai multe chei furnizate de clienți pentru contractele BYOK.

Riscul nu este doar o scurgere secretă. Este pierderea contextului de autorizare. O cheie de furnizor validă poate fi capabilă din punct de vedere tehnic să apeleze un punct final, dar gateway-ul trebuie să știe dacă acea cheie este permisă pentru acest chiriaș, această familie de modele, această politică de păstrare a datelor, acest buget, această regiune și această cale de automatizare.

Realitate: platformele furnizorilor expun diferite limite ale conturilor și tipuri de acreditări. OpenAI documentează proiectele și conturile de serviciu, iar permisiunile cheii API ale conturilor de serviciu sunt implicite pentru acces de citire și scriere pentru resursele API ale proiectului. OpenAI expune, de asemenea, obiectele cheie API Admin separat de utilizarea obișnuită a API-ului de proiect/execuție. Anthropic documentează spațiile de lucru ca o limită organizațională și afirmă că punctele finale API Admin necesită chei API Admin distincte de cheile API standard; Anthropic observă, de asemenea, că cheile API sunt legate de spațiul de lucru în care sunt create și nu pot fi mutate între spațiile de lucru. Documentația Google Gemini API spune că fiecare cheie Gemini API este asociată cu un proiect Google Cloud și recomandă restricții API pentru a reduce daunele în cazul în care o cheie este compromisă.

Recomandare: nu creați un câmp generic „provider_key” și numiți gata. Creați un inventar de acreditări care păstrează limitele specifice furnizorului în timp ce expune un model de politică normalizat la gateway.

Definiți o taxonomie de acreditări înainte de a accepta cheile

Un seif ar trebui să respingă acreditările ambigue. La momentul importului, operatorul sau fluxul de lucru de automatizare trebuie să clasifice acreditările. Utilizați cel puțin aceste categorii:

• Acreditări de inferență de execuție: utilizate de către gateway pentru a apela punctele finale de inferență ale modelului, cum ar fi chat, răspunsuri, încorporare, moderare, transcriere sau generare de imagini, în funcție de asistența furnizorului.
• Acreditări de automatizare de administrator: utilizate pentru a gestiona organizațiile, spațiile de lucru, proiectele, utilizatorii, cheile sau resursele administrative ale furnizorului. Acestea nu ar trebui să fie niciodată pe calea cererii de rulare.
• Acreditări de facturare și raportare: utilizate pentru a prelua rapoarte de utilizare, facturi, costuri sau organizații în care furnizorii acceptă acele API-uri. Păstrați-le separate de cheile de inferență, astfel încât joburile de raportare să nu poată genera utilizarea modelului.
• Acreditări numai pentru evaluare: utilizate de fluxurile de lucru de referință, QA, migrare sau punere în pas. Ar trebui să aibă cote scăzute, etichete de mediu clare și nicio eligibilitate pentru producție de rezervă.
• Acreditări BYOK client: chei furnizate de client legate de un anumit chiriaș, cont de furnizor, contract și politică de date. Acestea nu ar trebui să fie grupate în rutarea partajată decât dacă clientul acceptă în mod explicit.

Această taxonomie nu este doar documentație. Ar trebui să conducă controlul accesului, eligibilitatea rutei, alertele și fluxurile de lucru de rotație. Dacă o acreditare este importată fără o categorie, un proprietar, o limită a contului de furnizor și o utilizare permisă, ar trebui să rămână dezactivată.

Pastrați secretele într-un seif, nu în înregistrările produselor

Seiful ar trebui să fie singura componentă care poate decripta acreditările din amonte. Alte sisteme pot stoca referințe, hashuri, câmpuri de stare și metadate de politică, dar nu și valoarea acreditării în sine.

Nu stocați secrete din amonte în aceste locuri

• Rânduri de profil de chiriaș.
• Fișiere de configurare a rutare a modelului.
• Prompt jurnalele sau urmărirea intervalelor.
• Încărcături utile pentru evenimentele de analiză.
• Variabile CI orientate spre dezvoltator.
• Bilete de asistență, instrumente de chat sau capturi de ecran.

Un design de seif utilizabil are două planuri. Planul secret stochează material de acreditări criptat și controlează în mod strict operațiunile de decriptare. Planul de metadate stochează atribute non-secrete utilizate de rutare și guvernare. De obicei, routerul ar trebui să aibă nevoie doar de un ID de autentificare și de o recuperare secretă în memorie de scurtă durată la momentul expedierii, nu de acces larg la baza de date la fiecare cheie de furnizor.

Protejați seiful ca infrastructură de mare valoare: criptare plic sau KMS gestionat, identități stricte de serviciu, proceduri de spargere a sticlei, testare de backup și restaurare, revizuire a accesului și alerte privind volumul de decriptare neobișnuit. Un seif central simplifică guvernarea, dar concentrează și riscul. Acesta este compromisul.

Atașați metadatele politicii la fiecare acreditări

Modelul de metadate ar trebui să fie suficient de explicit încât gateway-ul să poată decide dacă o acreditare este eligibilă înainte de a atinge punctul final al furnizorului.

O înregistrare practică de acreditare include:

• credential_id: identificator intern imuabil.
• furnizor: OpenAI, Anthropic, Gemini, Azure OpenAI sau alt adaptor.
• provider_account_boundary: organizație, proiect, spațiu de lucru, proiect cloud, abonament sau echivalent.
• credential_class: runtime, admin, facturare, evaluare sau BYOK.
• mediu: producție, punere în scenă, dezvoltare, evaluare, sandbox.
• tenant_binding: date de conectare a platformei partajate, chiriaș unic, grup de chiriași sau chiriaș BYOK al clientului.
• allowed_model_families: de exemplu, generarea de text, încorporarea, viziunea, imaginea, audio sau anumite profiluri de model.
• allowed_endpoints: capabilități de gateway normalizate mapate la punctele finale ale furnizorului.
• data_policy: permise clasa de reținere, clasa de înregistrare, cerința de rezidență și restricții pentru caracteristici.
• budget_scope: centru de cost, client revânzător, departament intern sau contract.
• proprietar: echipa numită sau persoană responsabilă.
• created_at, expires_at, rotation_due_at, last_used_at.
• starea_sănătății: necunoscut, sănătos, degradat, neautorizat, cota_epuizată, dezactivat.
• emergency_disable: bloc de rutare imediat, independent de starea normală a politicii.

Păstrați acest model neutru față de furnizor, dar nu ștergeți realitățile furnizorului. O cheie legată de spațiul de lucru antropic și o cheie Gemini legată de un proiect Google Cloud nu sunt interschimbabile doar pentru că ambele pot genera text. Gateway-ul are nevoie de această proveniență pentru audituri, rambursare și failover în siguranță.

Acces separat la durata de execuție, la administrare și la facturare

Cea mai importantă regulă este simplă: o cheie utilizată pentru inferența de rulare nu ar trebui să gestioneze organizațiile furnizorilor, spațiile de lucru, utilizatorii, proiectele sau resursele administrative.

Traficul de rulare are un volum mare și este expus la cea mai mare suprafață operațională. Trece prin routere de solicitare, logica de reîncercare, handlere de streaming, adaptoare de model și fluxuri de lucru incidente. Acreditările de administrator au frecvență scăzută și impact ridicat. Aceștia ar trebui să trăiască în spatele unei căi de aprobare separată, cu TTL-uri scurte, denumite aprobare umană, acolo unde este cazul, înregistrare puternică în jurnal și fără eligibilitate pentru rutarea timpului de execuție.

Acreditările de facturare merită, de asemenea, separate. O lucrare de raportare care reconciliază facturile nu ar trebui să poată genera completări, iar o cheie de inferență de rulare nu ar trebui să fie singura modalitate de a prelua rapoartele de utilizare. Când un furnizor nu oferă o separare fină, compensați în gateway: izolați acreditările, limitați identitatea de serviciu internă care o poate prelua și înregistrați fiecare utilizare.

Recomandare: faceți din clasa de acreditări o limită de autorizare strictă, nu o etichetă. Un dispecer de rulare ar trebui să nu poată solicita decriptarea unei acreditări de administrator, chiar dacă o greșeală de configurare face referire la ID-ul acestuia.

Creați un motor de politică de selecție a acreditărilor

Selectarea acreditării ar trebui să aibă loc după ce gateway-ul autentifică apelantul din aval și înainte de a încerca orice apel către furnizor. Motorul de politici ar trebui să se alăture mai multor intrări:

• ID de chiriaș și domeniul de aplicare a cheii API din aval.
• Profilul de model solicitat sau ID-ul modelului specific furnizorului.
• Capacitatea punctului final: chat, încorporare, imagine, audio, lot, fișiere, instrumente sau automatizare administrativă.
• Cerințe privind păstrarea datelor și rezidența.
• Buget, rezervare de credit și centru de cost.
• Starea limită a ratei și presiunea cotei.
• Metadatele de acreditări, sănătatea, mediul și legarea chiriașilor.

Motorul ar trebui să returneze unul dintre cele trei rezultate: permiteți cu o acreditare selectată, respingeți cu un motiv de politică sau solicitați aprobarea. Refuzurile ar trebui să fie suficient de precise pentru ca echipele de operațiuni să rezolve problema fără a dezvălui dezvoltatorilor materiale secrete.

Exemplu de decizie:

{
  "tenant_id": "tenant_42",
  "requested_profile": "rapid-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  „credential_requirements”: {
    "class": "runtime",
    „mediu”: „producție”,
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "sănătos"
  },
  "decizie": "permite",
  "credential_id": "cred_8f2...",
  „audit_reason”: „Acreditările BYOK ale locatarului se potrivesc cu profilul textului de rulare și cu politica de date”
}

Nu implementați alternativa ca „încercați următoarea cheie”. Politica de rezervă trebuie să ruleze din nou. O acreditare a platformei partajate poate fi validă pentru accesul furnizorului, dar invalidă pentru un client exclusiv BYOK. O acreditare dintr-un alt proiect poate avea cotă, dar poate încălca cerințele de atribuire a costurilor sau de păstrare.

Tratați BYOK ca acces deținut de chiriaș, nu ca capacitate de rezervă

BYOK modifică modelul de încredere. Clientul a furnizat acreditările, astfel încât traficul său să poată fi taxat, guvernat de sau izolat în contul său de furnizor. Acreditarea ar trebui să fie legată de proveniența contului clientului chiriașului și furnizorului.

Comenzi BYOK recomandate:

• O înregistrare seif pentru fiecare client, furnizor, limită de cont și mediu.
• Fără rutare între chiriași prin acreditările BYOK.
• Nu se utilizează ca capacitate de rezervă partajată, cu excepția cazului în care clientul acceptă în mod explicit.
• Starea de sănătate vizibilă de client care nu dezvăluie cheia brută.
• Flux de lucru de rotație separat care permite clientului să adauge un înlocuitor înainte ca vechea cheie să fie dezactivată.
• Atribuire clară în analiza utilizării și în facturi: chiriașul gateway-ului, limita contului furnizorului, ID-ul acreditării, profilul modelului și ID-ul urmăririi cererii.

Pentru agenții, revânzători și automatizarea API pentru parteneri, BYOK poate fi mai complex, deoarece un serviciu poate furniza chiriași și acreditări în mod programatic. Aceeași regulă se aplică în continuare: automatizarea poate importa și lega acreditările, dar nu ar trebui să estompeze calitatea de proprietar al chiriașilor.

Adăugați verificări de stare preflight fără scurgeri de solicitări

O acreditare poate eșua din mai multe motive: cheie revocată, spațiu de lucru greșit, lipsă de acces la model, facturare dezactivată, epuizare a cotei, restricție la punctul final, nepotrivire a politicii regionale sau întrerupere a furnizorului. Descoperirea faptului că numai după ce sosește o solicitare de producție creează incidente zgomotoase.

Utilizați verificări de sănătate care validează capacitatea fără a trimite solicitări clienților. O verificare sintetică poate apela un punct final minim, poate enumera modelele permise acolo unde este cazul sau poate trimite o solicitare fixă ​​inofensivă dacă aceasta este singura opțiune practică. Păstrați aceste cecuri ieftine, cu tarif limitat și etichetate drept trafic sintetic în telemetrie și facturare.

Verificările de sănătate ar trebui să ruleze:

• La importul acreditărilor.
• Înainte de a activa o autentificare pentru rutarea producției.
• După modificările restricțiilor de la furnizor.
• În timpul întreruperii rotației.
• Periodic pentru acreditări cu eligibilitate pentru producție.

Compartiment: verificările automate observă devreme cheile expirate sau sublimitate, dar verificările prost concepute pot crea apeluri inutile la furnizor, zgomot de facturare sau alarme false în timpul întreruperii furnizorului. Stocați rezultatul de sănătate cu marca temporală, clasa de eroare a furnizorului, punctul final testat și familia de modele testată. Nu stocați valori secrete sau solicitări sensibile.

Rotiți cu două sloturi, nu o înlocuire riscantă

Rotația acreditărilor nu ar trebui să fie o operațiune de ștergere și rugăciune. Utilizați un model de rotație cu două fante:

1. Importați acreditările de înlocuire ca inactive, cu metadate complete și proprietar.
2. Executați verificări sintetice de stare pentru punctele finale, familiile de modele și limita contului vizate.
3. Activați eligibilitatea umbră pentru o mică parte de trafic sintetic sigur sau cu risc scăzut, acolo unde este cazul.
4. Schimbați treptat traficul de producție de la autentificarea veche la autentificarea nouă.
5. Monitorizați erorile, latența, cota și atribuirea costurilor în funcție de codul de autentificare.
6. Înghețați alternativă la vechea autentificare odată ce noua autentificare este stabilă.
7. Revocați vechiul document de conectare la furnizor și marcați înregistrarea seifului ca revocată.
8. Verificați că nu au loc decriptări sau apeluri de la furnizor prin intermediul vechii acreditări după revocare.

Termenele limită de rotație ar trebui să fie vizibile în vizualizările operațiunilor și în alerte. Rotația de urgență necesită o cale mai scurtă: dezactivați acreditările, blocați rutarea, activați înlocuirea aprobată și păstrați toate înregistrările de audit pentru examinarea incidentelor.

Restricționați cheile furnizorului acolo unde furnizorul le acceptă

Politica de gateway este necesară, dar restricțiile la nivelul furnizorului reduc raza de explozie dacă o cheie este compromisă sau utilizată greșit. Pentru Gemini și alte chei API pentru platforma cloud, utilizați restricții API/servicii și restricții adecvate pentru aplicații, acolo unde sunt disponibile. Pentru proiectele furnizorilor, spațiile de lucru și conturile de servicii, evitați privilegiile organizaționale largi atunci când este suficientă o cheie de rulare pentru proiect.

Recomandare: mențineți o listă de verificare a restricțiilor la nivelul furnizorului pentru fiecare clasă de acreditări. Lista de verificare ar trebui să facă parte din aprobarea de import și din aprobarea rotației, nu o sarcină separată de securitate care poate fi omisă sub presiune.

Compartiment: restricțiile la nivelul furnizorului adaugă cheltuieli operaționale. Noile puncte finale, familii de modele, regiuni sau funcții de automatizare pot necesita modificări ale politicii și restricțiilor. Acest lucru este de preferat decât a descoperi după o scurgere că o singură cheie ar putea accesa fiecare sarcină de lucru dintr-un proiect partajat.

Păstrați un jurnal de audit al acreditărilor numai pentru atașare

O pistă de audit ar trebui să răspundă cine a importat o acreditare, ce i s-a permis să facă, ce decizii de rutare a selectat-o, când a eșuat și când a fost rotită sau revocată.

Înregistrați aceste evenimente:

• Acreditare creată sau importată.
• Metadatele modificate, inclusiv punctele finale permise, legarea locatarului sau politica privind datele.
• Verificarea stării de sănătate a fost executată și rezultatul a fost înregistrat.
• Acreditare selectată de politica de rutare pentru o solicitare.
• Decriptarea acreditării solicitată de o identitate de serviciu internă.
• Apelul furnizorului a eșuat din cauza unei erori de autentificare, autorizare, cotă sau restricție.
• Rotirea a început, traficul s-a deplasat, vechile acreditări au fost revocate.
• Dezactivarea de urgență a fost activată sau anulată.
• Autentificare de administrator sau break-glass accesată.

Nu introduceți valori brute de acreditări în evenimentele de audit. Utilizați ID-uri de acreditări, limitele contului de furnizor, ID-uri de urmărire a solicitării, identitățile actorilor și motivele deciziei de politică. Pentru traficul de rulare cu volum mare, puteți eșantiona telemetria decriptată detaliată, dar selecția rutei și atribuirea costurilor ar trebui să rămână suficient de complete pentru facturare și răspuns la incident.

Lista de verificare a implementării

• Creați o taxonomie de acreditări și respingeți importurile neclasificate.
• Mutați toate secretele furnizorului într-un seif criptat dedicat.
• Stochează metadatele de rutare separat de materialul secret.
• Faceți din timpul de execuție, administrare, facturare, evaluare și acreditările BYOK clase de autorizare separate.
• Leagă datele de conectare BYOK la proveniența contului chiriașului și furnizorului.
• Solicitați aprobarea motorului de politici înainte de a selecta orice autentificare în amonte.
• Efectuați verificări rapide și sigure înainte de eligibilitatea pentru producție.
• Utilizați rotația în două sloturi cu schimbarea treptată a traficului și revocarea din partea furnizorului.
• Aplicați restricții la nivelul furnizorului oriunde sunt disponibile.
• Păstrați jurnalele de audit numai pentru atașare pentru import, utilizare, eșecuri, rotație și revocare.
• Păstrați acreditările de administrator în spatele comenzilor sparte de sticlă: TTL scurt, aprobare denumită, înregistrare puternică, fără utilizare în timpul rulării.

Concluzie acționabilă

Începeți prin a inventaria fiecare autentificare a furnizorului din amonte utilizată în prezent de gateway, scripturi, joburi CI, sisteme de evaluare și automatizarea partenerilor. Pentru fiecare dintre ele, atribuiți o clasă, un proprietar, o limită a contului de furnizor, o legare a chiriașilor, punctele finale permise, familiile de modele permise, termenul limită de rotație și starea de dezactivare de urgență. Tot ceea ce nu puteți clasifica ar trebui să fie dezactivat sau pus în carantină până când are un scop clar.

Apoi, aplicați o singură regulă arhitecturală: dezvoltatorii din aval primesc chei pentru gateway; Numai gateway-ul controlează accesul furnizorului din amonte. Această separare vă permite să păstrați cel mai mic privilegiu, atribuirea chiriașului, acuratețea facturării, rutarea politicii de date și automatizarea sigură, chiar și pe măsură ce furnizorii, proiectele, spațiile de lucru și clienții BYOK se înmulțesc.

Lectură similară

• gestionarea cheilor API pentru echipă și răspunsul la scurgeri
• politici de rutare data-retention-aware
• FAQ

  Întrebări frecvente

  Ar trebui să fie stocate acreditările furnizorului în evidențele chiriașilor?

  Nu. Stocați materialul de acreditări criptat într-un seif dedicat. Înregistrările chiriașilor pot face referire la un ID de acreditări și metadate de politică, dar nu ar trebui să conțină secrete ale furnizorului din amonte.

  Poate fi folosită o cheie de furnizor atât pentru inferența de rulare, cât și pentru automatizarea administrației?

  Evita-l. Cheile de execuție sunt expuse la căi de solicitare cu volum mare, în timp ce cheile de administrare pot schimba organizația, spațiul de lucru sau resursele proiectului. Separați-le cu diferite clase de acreditări, identități de serviciu, aprobări și piste de audit.

  Cum ar trebui să fie gestionate acreditările BYOK într-un gateway cu mai mulți locatari?

  Legați fiecare autentificare BYOK la chiriașul clientului, limita contului furnizorului, mediul și utilizarea permisă. Nu utilizați cheile furnizate de client ca capacitate de rezervă partajată decât dacă clientul acceptă în mod explicit.

  Care este cel mai sigur mod de a roti cheile furnizorului din amonte?

  Utilizați un proces cu două intervale: importați înlocuitorul ca inactiv, executați verificări de sănătate, schimbați treptat traficul, monitorizați erorile și atribuirea costurilor, revocați vechiul acreditiv al furnizorului și verificați că niciun trafic nu îl folosește în continuare.