Gestionarea cheilor API nu mai este o sarcină mică din tabloul de bord. Pentru echipele care folosesc API-uri AI, aceasta face parte din modelul de securitate, cost și operațiuni pentru fiecare aplicație care trimite solicitări, primește rezultate ale modelului, invocă instrumente sau cheltuiește bani pentru inferența măsurată.
Multe echipe încep cu o cheie de furnizor într-un fișier de mediu local. Aceasta funcționează până când aceeași cheie apare în variabile CI, notebook-uri, extensii IDE, agenți, joburi în lot, integrări cu clienții și scripturi de asistență. În acel moment, o cheie scursă nu este doar o problemă de autentificare. Poate expune solicitări și răspunsuri, poate declanșa taxe neașteptate, poate apela modele premium, poate rula instrumente cu autorizarea aplicației sau poate face ca răspunsul la incident să depindă de presupuneri.
Acest ghid tratează gestionarea cheilor API ca pe un ciclu de viață: cum sunt proiectate, emise, stocate, definite, monitorizate, rotite și revocate cheile. Se concentrează pe accesul API AI, unde preocupările obișnuite de securitate API sunt adăugate de accesul la model, cheltuielile bazate pe token, acreditările cu mai mulți furnizori, atribuirea clienților și clienții compatibili cu OpenAI.
Acolo unde cheile API se încadrează în securitatea API
O cheie API dovedește de obicei deținerea unei acreditări. Răspunde la întrebarea „Acest apelant are un secret valid?” Nu răspunde, în sine, la fiecare întrebare de autorizare care contează.
Un backend mai trebuie să decidă dacă apelantul poate accesa un anumit chiriaș, obiect, model, punct final, instrument, spațiu de lucru, raport sau funcție administrativă. Securitatea API-ului OWASP Cele mai importante 10 riscuri, cum ar fi autorizarea la nivel de obiect defect, autentificarea întreruptă, consumul nerestricționat de resurse și autorizarea la nivel de funcție întreruptă sunt mementouri că o acreditare validă este doar un strat al sistemului.
Pentru API-urile AI, această distincție contează, deoarece aceeași cheie ar putea fi capabilă să efectueze acțiuni cu profiluri de risc foarte diferite. O cheie care poate apela un model text cu cost redus pentru un flux de lucru intern nu ar trebui să poată apela automat modele premium, să creeze joburi în loturi, să acceseze datele altui chiriaș, să invoce instrumente care trimit e-mailuri sau să gestioneze setările de facturare.
Un model de securitate API durabil separă trei preocupări:
- Autentificare:, să dovedească o solicitare validă sau o acreditare. sesiune.
- Autorizare: decide ce poate face acel apelant autentificat în actualul chiriaș, mediul și contextul de afaceri.
- Guvernare: limitarea cheltuielilor, ratei, accesului la model, expunerea la date și controlul administrativ, astfel încât o greșeală să aibă o rază de explozie limitată.
Resurse API nu ar trebui să fie utile, dar nu ar trebui să protejeze cheile API. Folosiți-le cu HTTPS, verificări de autorizare la nivelul serverului, jurnalele de audit, privilegiul minim, limitele ratelor, limitele de cheltuieli și gestionarea securizată a secretelor.
Începeți cu un inventar de chei API live
Nu puteți gestiona cheile pe care nu le puteți numi. Primul pas practic este un inventar în timp real al fiecărei chei API și al obiectelor asemănătoare acreditărilor utilizate de sistemele dvs. AI.
Cel puțin, fiecare înregistrare a cheii trebuie să includă un ID de cheie, un hash nereversibil sau amprentă digitală, proprietar, creator, echipă sau chiriaș, mediu, volum de lucru, domenii, modele permise, puncte finale permise, politică de cheltuire, politică de rate, timp de expirare, IP, restricții, ultima dată când este cazul, grup de rotație și metadate de audit.
Inventarul ar trebui să acopere mai mult decât cheile de rulare de producție. Includeți chei personale de dezvoltator, chei de cont de serviciu, chei CI/CD, chei de spațiu de lucru, chei pentru client sau chiriaș, chei gestionate de distribuitor, chei de facturare/raportare, acreditări administrative API și acreditări ale furnizorului din amonte.
Cele mai importante câmpuri sunt proprietatea, scopul, domeniul de aplicare, ultima utilizare și politica de limită. Fără ele, fiecare sarcină viitoare de securitate devine mai lentă: offboarding, rotație, răspuns la scurgeri, investigarea costurilor și asistență pentru clienți.
Concepeți în mod deliberat limitele cheilor
Cea mai mare greșeală de gestionare a cheilor API este utilizarea unei chei peste prea multe granițe. O cheie de producție partajată este convenabilă la început, dar distruge atribuirea și face ca revocarea să deranjeze. Dacă se scurge, este posibil să trebuiască să opriți traficul pentru fiecare serviciu, fără a putea identifica încărcătura de lucru care a cauzat problema.
Graniile cheie bune urmează forma afacerii și a software-ului. Separați producția de dezvoltare, oamenii de servicii, clienții din echipele interne, chiriașii unul de celălalt, acreditările de execuție de acreditările administrative și cheile pentru clienți emise de gateway de cheile furnizorilor din amonte.
Delimitarea mediului
Dezvoltarea, punerea în scenă și producția ar trebui să utilizeze chei separate. O cheie de dezvoltare nu ar trebui să ajungă la datele de producție sau la bugetele de producție.O cheie de pregătire nu ar trebui să aibă acces la sarcinile de lucru ale clienților în direct decât dacă există un motiv strâns controlat.
Delimitări ale sarcinii de lucru
Fiecare serviciu, sarcină lot, flotă de agenți, integrare sau sarcină programată ar trebui să aibă propria cheie sau cont de serviciu. Acest lucru vă permite să răspundeți la întrebările de bază: ce sarcină de lucru a cheltuit banii, ce serviciu a început să eșueze autentificarea, ce integrare a folosit un model depreciat și ce cheie ar trebui să fie înghețată în timpul unui incident.
Delimitarea chiriașilor și clienților
Sistemele cu mai mulți chiriași au nevoie de atribuire și izolare. Dacă se folosește o cheie API orientată către client pentru a trimite solicitări, cererea ar trebui să fie legată de client, chiriaș, aplicație și, în mod ideal, un utilizator final sau un actor pseudonim. O cheie compromisă pentru un chiriaș nu ar trebui să permită accesul la datele, profilul modelului, bugetul sau jurnalele altui chiriaș.
Marginile acreditărilor furnizorului
Cheile furnizorului din amonte sunt diferite de cheile pe care le emiteți clienților sau aplicațiilor interne. Acreditările furnizorului ar trebui să rămână pe partea serverului, stocate într-un seif sau într-un manager secret și să nu fie niciodată trimise către browsere, aplicații mobile, clienți desktop, notebook-uri publice sau medii controlate de client.
Un gateway poate ajuta aici expunând o suprafață cheie orientată către client, păstrând în același timp acreditările furnizorului în spatele gateway-ului. Acest lucru face posibilă centralizarea analizei utilizării, revocarea, controalele echipei și aplicarea politicilor între furnizori. Dacă standardizați clienții în jurul unui API compatibil OpenAI, limita gateway-ului devine deosebit de importantă, deoarece multe instrumente se așteaptă la o singură adresă URL de bază și un simbol purtător.
Aplicați cel mai mic privilegiu modelelor, punctelor finale, instrumentelor și cheltuiți
Cel mai mic privilegiu pentru a funcționa înseamnă că o cheie trebuie să aibă acces. Pentru sistemele AI, domeniul de aplicare nu este doar o listă de puncte finale API. Include, de asemenea, modele, instrumente, bugete de simboluri, limite de tarife, chiriași, clase de date și funcții administrative.
O politică practică a cheilor API AI poate include:
- Familii de modele permise sau ID-uri de model specifice.
- Punctele finale permise, cum ar fi completările de chat, încorporarea, lucrările de generare a loturilor, sau >
- Limite de rate pe cheie pentru solicitări pe minut și jetoane pe minut.
- Limite de cheltuieli pe chiriaș, pe echipă sau pe client.
- Modelul premium controlează, astfel încât un model cu risc scăzut nu poate utiliza brusc fluxul de lucru.
- permisiuni, cum ar fi dacă o cheie poate apela conectori externi, execuție de cod, sisteme de recuperare sau acțiuni de afaceri.
- Liste permise IP pentru încărcături de lucru stabile pe server, unde calea rețelei este previzibilă.
Controlul cheltuielilor face parte din securitatea API pentru API-urile AI măsurate. O cheie scursă poate crea daune financiare directe, chiar dacă nu accesează niciodată date sensibile. Limitele ratelor ajută, dar nu sunt suficiente. Volumul de simboluri, reîncercările, lucrările în lot, apelurile de instrumente și selecția modelului afectează toate costurile. O implementare sigură ar trebui să combine controalele ratelor cu plafoanele de cheltuieli, listele de modele permise, detectarea anomaliilor și controalele de înghețare în caz de urgență.
Echipele care compară costurile modelului și politicile de acces ar trebui să mențină securitatea și finanțarea aliniate. Prețul model nu este doar o problemă de achiziție; determină ce poate cheltui o cheie compromisă sau configurată greșit. Păstrați profilurile de model aprobate legate de bugete și revizuiți-le atunci când amestecul dvs. de modele se modifică, în special atunci când utilizați prețurile modelului AI pentru a direcționa sarcinile de lucru în funcție de cost și capacitate.
Stocați secretele acolo unde le aparțin
Cheile API aparțin managerilor de secrete, configurațiilor server-side, variabilelor controlate sau gateway-back-ul/CD. Acestea nu aparțin codului sursă, JavaScript al browserului, pachetele mobile, pachetele de aplicații desktop, blocnotesurile publice, capturile de ecran, mesajele de chat, încărcăturile utile de analiză, biletele de asistență sau jurnalele.
Expunerea la nivelul clientului este un mod obișnuit de eșec. Dacă o cheie de furnizor este încorporată într-un browser sau într-o aplicație mobilă, oricine poate inspecta aplicația o poate extrage și face solicitări în numele titularului contului. Pentru browsere, aplicații mobile, flote IDE și agenți care rulează în medii necontrolate, utilizați proxy-ul pe server sau acreditări delegate de scurtă durată, cu un domeniu de aplicare restrâns. Nu distribuiți acreditări ale furnizorilor de lungă durată clienților pe care nu îi puteți controla.
CI/CD necesită aceeași disciplină. Stocați cheile ca variabile protejate. Limitați cine le poate citi sau modifica. Evitați tipărirea variabilelor de mediu în jurnalele de compilare. Redactați anteturile de autorizare în depozitele de cereri eșuate. Tratează implementările de previzualizare și solicitările de extragere forked ca zone de încredere diferite din conductele de producție protejate.
Jurnalele și sistemele de observabilitate merită o atenție specială.Stocați amprentele cheilor, ID-urile solicitărilor, ID-urile chiriașilor, ID-urile modelului, starea răspunsului, contoarele de simboluri, contoarele de costuri, metadatele IP sau ale clienților, acolo unde este cazul, și deciziile de politică. Nu stocați cheile API complete. Redactați secretele în urme, jurnalele proxy inverse, rapoarte de excepție, încărcături utile webhook, instrumente de asistență, evenimente de analiză și cozi de mesaje moarte.
Creați rotație înainte de urgență
Rotația nu înseamnă doar ștergerea unei chei și crearea alta. Dacă serviciile implementate depind în continuare de vechea cheie, ștergerea cauzează timpi de nefuncționare. Un proces de rotație fiabil utilizează suprapunerea, observarea și un punct de retragere clar.
Un model comun este un grup de rotație cu două intervale active. Creați cheia de înlocuire, implementați-o în fiecare sistem dependent, observați ultima utilizare a cheii vechi, înghețați cheia veche când traficul s-a mutat și ștergeți-o după o fereastră de încredere. Păstrați regulile de rollback explicite: când poate fi reactivată vechea cheie, cine o poate aprobă și cât timp poate rămâne disponibilă?
Duratele scurte de viață ale cheilor reduc riscul de acreditări învechite, dar cresc sarcina operațională. Cheile cu durată lungă de viață reduc rata de desfășurare, dar creează o fereastră mai mare pentru acreditările uitate și lacunele de la angajați. Politica corectă depinde de volumul de muncă. Un cont de serviciu de producție de mare valoare se poate roti după un program fix cu automatizare. O cheie temporară de dezvoltator ar trebui să expire rapid. O integrare gestionată de client poate avea nevoie de o fereastră de migrare mai lungă și de mesaje clare de depreciere.
Nu rotiți fiecare tastă în același mod. Acreditările administrative care pot enumera, crea, șterge sau modifica chei prezintă un risc mai mare decât cheile de inferență de rulare și ar trebui să aibă controale mai puternice, acces mai restrâns și monitorizare mai agresivă. Cheile de rulare nu ar trebui să aibă autoritate administrativă decât dacă există un motiv specific, revizuit.
Detectarea scurgerilor și a utilizării anormale
Detectarea scurgerilor funcționează cel mai bine atunci când mai multe sisteme se consolidează reciproc. Scanarea secretă prin controlul sursei poate captura cheile trimise în depozite. Verificările CI pot bloca scurgeri evidente înainte de îmbinare. Modelele personalizate pot detecta formatele de chei interne. Tablourile de bord ale furnizorilor pot dezvălui activități neobișnuite. Telemetria gateway-ului poate afișa IP-uri noi, zone geografice noi, explozii de autentificare eșuate, viteza bruscă de cheltuire sau apeluri către modele neașteptate.
Tablourile de bord de securitate utile includ chei latente, chei fără proprietari, chei fără limite, chei care se apropie de expirare, chei utilizate din rețele noi, chei cu chei cu chei eșuate, creșterea rapidă a tokenului de chei, autentificarea eșuată și încărcarea traficului înghețat. cheile clienților care se apropie de plafoanele de cheltuieli.
Detecția ar trebui să acopere și jurnalele și sistemele asincrone. Webhook-urile, joburile de fundal, cozile și completările întârziate necesită ID-uri de solicitare și atribuirea cheii originale. În caz contrar, un rezultat suspect de apel invers sau lot poate fi imposibil de legat de cheia și de chiriașul care l-a creat.
Când apare un secret în istoricul Git, eliminarea acestuia din depozit nu este suficientă. Oricine a accesat depozitul, a construit jurnalele, oglinzile, furculițele, artefactele pachetului sau paginile stocate în cache ar putea să fi copiat deja cheia. Acreditările trebuie să fie invalidate sau înghețate, apoi înlocuite.
Răspunsul la o cheie API compromisă
Un plan bun de răspuns la incident este scurt, repetat și specific. Prima decizie este de obicei dacă să înghețe sau să revoce. Freeze oprește rapid traficul, păstrând în același timp înregistrarea pentru investigare. Revocarea dezactivează definitiv cheia. Unele echipe folosesc mai întâi înghețarea atunci când au nevoie de continuitate a auditului și de opțiuni de retragere imediată; alții revocă automat pentru scurgeri publice confirmate. Oricare dintre abordări necesită automatizare și autoritate clară.
Un flux de răspuns practic arată astfel:
- Înghețați sau revocați cheia suspectată pe baza severității și a încrederii.
- Identificați proprietarul, locatarul, volumul de lucru, domeniile, accesul la model, politica de cheltuieli și cronologia ultimului utilizat.
- Examinați, instrumente, instrumente, modele, puncte finale neutilizate. volumul de simboluri și costul.
- Evaluați datele afectate, chiriașii, acțiunile din aval și impactul facturării.
- Emiteți o cheie de înlocuire cu domeniul și limitele corectate.
- Eliminați cauza principală, cum ar fi un secret confirmat, un jurnal expus, o variabilă CI excesivă sau un pachet de control pe partea clientului, cum ar fi un secret de prevenire, un jurnal de prevenție, un jurnal roșu de scanare, un jurnal de prevenire, un jurnal roșu.
- domenii, alerte de expirare mai scurtă sau cheltuieli.
- Documentați incidentul și actualizați runbook-urile.
Pasul de înlocuire nu ar trebui să recreeze același risc. Dacă o cheie a scurs, deoarece a fost partajată în zece servicii, înlocuiți-o cu chei separate pentru cont de serviciu. Dacă s-a scurs prin jurnalele, remediați înregistrarea înainte de a emite o nouă cheie. Dacă a cheltuit în exces pentru că ar putea apela fiecare model, adăugați liste de modele permise și limite de cheltuieli.
Cheile gestionate de gateway și acces AI cu mai mulți furnizori
Echipele AI folosesc adesea mai mulți furnizori de modele.Fiecare furnizor are propriul său model de cheie, structură de spațiu de lucru, limite de rate, nume de modele, prețuri și API-uri administrative. Gestionarea fiecărei chei de furnizor direct în fiecare aplicație multiplică riscul operațional.
Un model de cheie gestionat de gateway poate reduce această complexitate. Aplicațiile apelează gateway-ul cu o cheie internă sau orientată către client. Gateway-ul autentifică apelantul, aplică politica locatarului, aplică controalele modelului și al cheltuielilor, înregistrează utilizarea și folosește acreditările furnizorului din amonte pe partea serverului. Acest lucru este util pentru aplicații cu mai multe modele, platforme interne, agenții și servicii de reseller.
Pentru Model Gate, aici este relevant rolul gateway-ului: chei centralizate orientate către clienți, analize unificate de utilizare, controale ale echipelor, limite de cheltuieli, securitate IP, integrări operaționale Telegram, automatizare API pentru parteneri și răspuns la abuz. Pentru companiile care furnizează clienți sau servicii în aval, Automatizarea API-ului Partener poate face ca crearea cheilor, să limiteze actualizările, înghețarea și fluxurile de lucru ale revânzătorului să fie coerente în loc de manuale.
O gateway nu înlătură orice responsabilitate din partea echipei aplicației. Aveți în continuare nevoie de stocare securizată, autorizare backend, izolarea chiriașilor, proiectarea punctelor finale, igiena CI/CD, politică de date prompte și de răspuns și restricții la nivelul furnizorului, acolo unde sunt disponibile. Poarta de acces devine un plan de control de mare valoare, așa că are nevoie de seifuri puternice, jurnale de audit, controale de acces, planificare a disponibilității și separare administrativă.
Greșeli obișnuite de gestionare a cheilor API
Cele mai frecvente greșeli sunt previzibile. Echipele pun cheile furnizorului direct în aplicațiile client. Ei folosesc o cheie de producție pentru fiecare serviciu și client. Acestea se rotesc prin ștergerea întâi și implementarea mai târziu. Ei creează chei fără proprietari, limite, domenii sau expirare. Ele înregistrează anteturile complete de autorizare. Ei se bazează numai pe limitele ratelor pentru controlul costurilor AI. Ele oferă acreditări de administrator pentru serviciile de rulare. Ei elimină o cheie scursă din Git fără a o revoca. Ei ies de la bordul angajaților, dar lasă active cheile personale, fișierele de mediu local și variabilele CI.
O altă greșeală subtilă este tratarea jurnalului prompt și răspuns ca pur operațional. Jurnalele detaliate pot ajuta la investigarea abuzurilor, dar pot conține și date personale, conținut client, secrete sau informații reglementate. Înregistrarea prima dată a metadatelor este adesea mai sigură: capturați amprentele cheilor, ID-urile modelului, numărul de simboluri, costurile, codurile de stare, deciziile de politică și ID-urile de solicitare în mod implicit, apoi necesită acces controlat pentru date de depanare mai profunde.
Lista de verificare a implementării
Un program puternic de gestionare a cheilor API poate începe cu o listă de verificare concentrată, inventariere și inventariere a tuturor cheilor:
medii, chiriași, domenii, limite și marcaje temporale pentru ultima utilizare.
Concluzie
Gestionarea cheilor API pentru API-urile AI se referă la controlul identității, autorității, costurilor și razei operaționale a exploziei. O cheie securizată nu este doar un șir aleatoriu. Are proprietar, scop, domeniu de aplicare, mediu, buget, expirare, cale de rotație, pistă de audit și plan de răspuns la incident.
Obiectivul practic nu este de a crea birocrație în jurul fiecărei solicitări. Este de a face munca normală mai sigură: dezvoltatorii pot construi, serviciile pot rula, clienții pot fi furnizați, iar echipele de securitate pot răspunde la ceea ce s-a întâmplat atunci când o cheie se scurge sau cheltuiește crește. Începeți cu inventarul și limitele, apoi adăugați cel mai mic privilegiu, stocare securizată, rotație, monitorizare și automatizare a răspunsului. Pentru accesul AI cu mai mulți furnizori, un gateway poate centraliza o mare parte din acest control, dar autorizarea aplicației și igiena secretă rămân în continuare responsabilități de bază de inginerie.