Upravljanje ključev API za API-je AI: varnost, rotacija, omejitve porabe in odziv na incidente

API upravljanje ključev ni več majhna naloga na nadzorni plošči. Za ekipe, ki uporabljajo API-je umetne inteligence, je to del varnostnega, stroškovnega in operativnega modela za vsako aplikacijo, ki pošilja pozive, prejema izhod modela, kliče orodja ali porabi denar za merjeno sklepanje.

Številne ekipe začnejo z enim ključem ponudnika v datoteki lokalnega okolja. To deluje, dokler se isti ključ ne pojavi v spremenljivkah CI, zvezkih, razširitvah IDE, posrednikih, paketnih opravilih, integracijah strank in podpornih skriptih. Na tej točki razkriti ključ ni samo težava pri preverjanju pristnosti. Izpostavi lahko pozive in odgovore, sproži nepričakovane stroške, pokliče premijske modele, zažene orodja s pooblastilom aplikacije ali naredi odziv na incident odvisen od ugibanja.

Ta vodnik obravnava API upravljanje ključev kot življenjski cikel: kako so ključi zasnovani, izdani, shranjeni, obsegajo, spremljajo, rotirajo in prekličejo. Osredotoča se na dostop z umetno inteligenco API, kjer se običajnim API varnostnim pomislekom pridružijo dostop do modela, poraba na podlagi žetonov, poverilnice več ponudnikov, dodeljevanje strank in odjemalci, združljivi z OpenAI.

Kjer API ključi ustrezajo API varnosti

Ključ API običajno dokazuje posedovanje poverilnica. Odgovarja na vprašanje, "ali ima ta klicatelj veljavno skrivnost?" Samo po sebi ne odgovori na vsa pomembna avtorizacijska vprašanja.

Zaledje se mora še vedno odločiti, ali lahko klicatelj dostopa do določenega najemnika, predmeta, modela, končne točke, orodja, delovnega prostora, poročila ali skrbniške funkcije. OWASP API Varnost Top 10 tveganj, kot so pokvarjeno pooblastilo na ravni objekta, pokvarjeno preverjanje pristnosti, neomejena poraba virov in pokvarjeno pooblastilo na funkcionalni ravni, so opomniki, da je veljavna poverilnica le ena plast sistema.

Za API-je AI je to razlikovanje pomembno, ker lahko isti ključ izvaja dejanja z zelo različnimi profili tveganja. Ključ, ki lahko pokliče nizkocenovni besedilni model za en notranji potek dela, ne bi smel samodejno klicati premium modelov, ustvarjati paketnih opravil, dostopati do podatkov drugega najemnika, klicati orodij, ki pošiljajo e-pošto, ali upravljati nastavitve obračunavanja.

Trajen API varnostni model loči tri pomisleke:

• Preverjanje pristnosti: dokazovanje zahteva ima veljavno poverilnico, žeton ali sejo.
• Authorization: odločanje o tem, kaj lahko ta preverjeni klicatelj počne v trenutnem najemniku, okolju in poslovnem kontekstu.
• Upravljanje: omejevanje porabe, stopnje, dostopa do modela, izpostavljenosti podatkov in skrbniškega nadzora, tako da ima ena napaka omejeno eksplozijo polmer.

API ključi so uporabni, vendar ne bi smeli biti edini nadzor, ki ščiti občutljive vire ali vire visoke vrednosti. Uporabite jih z HTTPS, avtorizacijskimi preverjanji na strani strežnika, revizijskimi dnevniki, najmanjšimi pravicami, omejitvami hitrosti, omejitvami porabe in varno tajno obravnavo.

Začnite z živim API popisom ključev

Ne morete upravljati ključev, ki jih ne morete poimenovati. Prvi praktični korak je popis v živo vsakega API ključa in predmeta, podobnega poverilnici, ki ga uporabljajo vaši sistemi AI.

Vsaj vsak zapis ključa mora vsebovati ID ključa, nepovratno zgoščeno vrednost ali prstni odtis, lastnika, ustvarjalca, ekipo ali najemnika, okolje, delovno obremenitev, obsege, dovoljene modele, dovoljene končne točke, politiko porabe, politiko stopnje, omejitve IP, kjer je to primerno, stanje, čas ustvarjanja, potek, zadnji uporabljeni časovni žig, rotacijska skupina in metapodatki o reviziji.

Inventar mora zajemati več kot produkcijske ključe časa izvajanja.Vključite osebne ključe razvijalca, ključe storitvenih računov, ključe CI/CD, ključe delovnega prostora, ključe strank ali najemnikov, ključe, ki jih upravlja preprodajalec, ključe za obračun/poročanje, skrbniške API poverilnice in poverilnice zgornjega ponudnika.

Najpomembnejša polja so lastništvo, namen, obseg, zadnja uporaba in pravilnik o omejitvah. Brez njih postane vsaka prihodnja varnostna naloga počasnejša: odstranitev, rotacija, odziv na uhajanje, preiskava stroškov in podpora strankam.

Načrtno načrtujte meje ključev

Največja API napaka pri upravljanju ključev je uporaba enega ključa čez preveč meja. Skupni produkcijski ključ je sprva prikladen, vendar uniči pripisovanje in naredi preklic moteč. Če pušča, boste morda morali ustaviti promet za vsako storitev, medtem ko še vedno ne morete ugotoviti, katera delovna obremenitev je povzročila težavo.

Dobre ključne meje sledijo obliki podjetja in programske opreme. Ločite proizvodnjo od razvoja, ljudi od storitev, stranke od notranjih skupin, najemnike med seboj, poverilnice za čas izvajanja od skrbniških poverilnic in ključe strank, ki jih je izdal prehod, od ključev ponudnika navzgor.

Meje okolja

Razvoj, uprizarjanje in produkcija morajo uporabljati ločene ključe. Razvojni ključ ne sme doseči proizvodnih podatkov ali proizvodnih proračunov. Uprizoritveni ključ ne bi smel imeti dostopa do delovnih obremenitev stranke v živo, razen če obstaja strogo nadzorovan razlog.

Meje delovne obremenitve

Vsaka storitev, paketno opravilo, flota agentov, integracija ali načrtovano opravilo mora imeti svoj ključ ali račun storitve. To vam omogoča odgovor na osnovna vprašanja: katera delovna obremenitev je porabila denar, katera storitev je začela neuspešno preverjati pristnost, katera integracija je uporabila zastarel model in kateri ključ je treba med incidentom zamrzniti.

Meje najemnikov in strank

Sistemi z več najemniki potrebujejo dodelitev in izolacijo. Če se za oddajo pozivov uporablja ključ API, usmerjen k stranki, mora biti zahteva povezana s stranko, najemnikom, aplikacijo in v idealnem primeru psevdonimnim končnim uporabnikom ali akterjem. Ogrožen ključ za enega najemnika ne bi smel dovoliti dostopa do podatkov, profila modela, proračuna ali dnevnikov drugega najemnika.

Meje poverilnic ponudnika

Ključi ponudnika navzgor v verigi se razlikujejo od ključev, ki jih izdate strankam ali notranjim aplikacijam. Poverilnice ponudnika morajo ostati na strani strežnika, shranjene v trezorju ali skrivnem upravitelju in jih nikoli ne pošiljati v brskalnike, mobilne aplikacije, namizne odjemalce, javne prenosnike ali okolja, ki jih nadzirajo stranke.

Tu lahko pomaga prehod, tako da izpostavi eno ključno površino, obrnjeno k stranki, medtem ko za prehodom ohrani poverilnice ponudnika navzgor. To omogoča centralizacijo analitike uporabe, preklica, skupinskih kontrol in uveljavljanja pravilnikov med ponudniki. Če standardizirate odjemalce okoli OpenAI-združljivega API, postane meja prehoda še posebej pomembna, ker veliko orodij pričakuje en sam osnovni URL in žeton nosilca.

Uporabi najmanjši privilegij za modele, končne točke, orodja in porabi

Najmanjši privilegij pomeni, da mora ključ imeti samo dostop, potreben za delovna obremenitev. Za sisteme AI obseg ni le seznam API končnih točk.Vključuje tudi modele, orodja, proračune žetonov, omejitve stopenj, najemnike, podatkovne razrede in skrbniške funkcije.

Praktični pravilnik o ključih AI API lahko vključuje:

• Dovoljene družine modelov ali specifične ID-je modelov.
• Dovoljene končne točke, kot so zaključki klepetov, vdelave, paketna opravila ali slike generacija.
• Nedovoljeni skrbniški API-ji, API-ji za upravljanje ključev, API-ji za obračunavanje in API-ji za upravljanje delovnega prostora za ključe izvajalnega časa.
• Omejitve hitrosti na ključ za zahteve na minuto in žetone na minuto.
• Poraba na najemnika, na ekipo ali na stranko omejitve.
• Model Premium nadzoruje, tako da potek dela z nizkim tveganjem ne more nenadoma uporabiti najdražjega modela.
• Dovoljenja orodja, na primer, ali lahko ključ kliče zunanje povezovalnike, izvajanje kode, sisteme za iskanje ali poslovna dejanja.
• Seznami dovoljenih IP za stabilne delovne obremenitve na strani strežnika, kjer je omrežna pot predvidljivo.

Nadzor porabe je del API varnosti za merjene API-je AI. Ključ, ki je ušel, lahko povzroči neposredno finančno škodo, tudi če nikoli ne dostopa do občutljivih podatkov. Omejitve hitrosti pomagajo, vendar niso dovolj. Količina žetonov, ponovni poskusi, paketna opravila, klici orodij in izbira modela vplivajo na stroške. Varna izvedba bi morala združevati nadzor stopnje z zgornjimi mejami porabe, dovoljenimi seznami modelov, zaznavanjem nepravilnosti in nadzorom zamrznitve v sili.

Ekipe, ki primerjajo stroške modela in politike dostopa, bi morale ohranjati varnost in finance usklajene. Modeliranje cen ni le vprašanje javnega naročanja; določa, koliko lahko porabi ogrožen ali napačno konfiguriran ključ. Odobrene profile modelov imejte vezane na proračune in jih pregledujte, ko se vaša mešanica modelov spremeni, še posebej pri uporabi cen modelov AI za usmerjanje delovnih obremenitev glede na stroške in zmogljivosti.

Shranjujte skrivnosti, kamor spadajo

API ključi sodijo v upravitelje skrivnosti, konfiguracijo na strani strežnika, nadzorovane spremenljivke CI/CD ali prehod, podprt s trezorjem. Ne sodijo v izvorno kodo, brskalnik JavaScript, mobilne pakete, pakete namiznih aplikacij, javne beležnice, posnetke zaslona, ​​sporočila klepeta, koristne podatke analitike, zahteve za podporo ali dnevnike.

Izpostavljenost na strani odjemalca je pogost način napake. Če je ključ ponudnika vdelan v brskalnik ali mobilno aplikacijo, ga lahko vsakdo, ki lahko pregleda aplikacijo, izvleče in poda zahteve v imenu imetnika računa. Za brskalnike, mobilne aplikacije, skupine IDE in agente, ki se izvajajo v nenadzorovanih okoljih, uporabite proxy na strani strežnika ali kratkotrajne delegirane poverilnice z ozkim obsegom. Ne razdeljujte dolgotrajnih poverilnic ponudnika strankam, ki jih ne morete nadzorovati.

CI/CD potrebuje enako disciplino. Shranite ključe kot zaščitene spremenljivke. Omejite, kdo jih lahko bere ali spreminja. Izogibajte se tiskanju spremenljivk okolja v dnevnikih gradnje. Uredi Authorization glave v izpisih neuspelih zahtev. Razmestitve predogleda in razcepljene zahteve za vlečenje obravnavajte kot različna območja zaupanja od zaščitenih proizvodnih cevovodov.

Sistemi dnevnikov in opazovanja si zaslužijo posebno pozornost. Shranjujte prstne odtise ključev, ID-je zahtev, ID-je najemnikov, ID-je modelov, status odziva, števce žetonov, števce stroškov, IP ali metapodatke odjemalcev, kjer je to primerno, ter odločitve pravilnikov. Ne shranjujte polnih API ključev. Uredite skrivnosti v sledovih, obrnite dnevnike strežnika proxy, poročila o izjemah, obremenitve webhooka, podporna orodja, analitične dogodke in čakalne vrste mrtvih pisem.

Rotacija gradnje pred izrednimi razmerami

Rotacija ni preprosto brisanje enega ključa in ustvarjanje drugega. Če so nameščene storitve še vedno odvisne od starega ključa, izbris povzroči izpade. Zanesljiv postopek rotacije uporablja prekrivanje, opazovanje in jasno točko umika.

Pogost vzorec je rotacijska skupina z dvema aktivnima mestoma.Ustvarite nadomestni ključ, ga namestite v vsak odvisen sistem, opazujte zadnjo uporabo starega ključa, zamrznite stari ključ, ko se promet premakne, in ga izbrišite po oknu zaupanja. Pravila za povrnitev naj bodo jasna: kdaj je mogoče stari ključ znova omogočiti, kdo lahko to odobri in kako dolgo lahko ostane na voljo?

Kratka življenjska doba ključa zmanjša tveganje zastarelih poverilnic, vendar poveča operativno breme. Dolgotrajni ključi zmanjšajo osip pri uvajanju, vendar ustvarijo večje okno za pozabljene poverilnice in vrzeli pri odhodu zaposlenih. Pravilna politika je odvisna od delovne obremenitve. Račun proizvodne storitve visoke vrednosti se lahko vrti po fiksnem urniku z avtomatizacijo. Začasni ključ razvijalca bi moral hitro poteči. Integracija, ki jo upravlja stranka, bo morda potrebovala daljše obdobje selitve in jasno sporočilo o opustitvi.

Ne izmenjujte vseh ključev na enak način. Skrbniške poverilnice, ki lahko navajajo, ustvarjajo, brišejo ali spreminjajo ključe, so bolj tvegane kot ključi za sklepanje med izvajanjem in bi morale imeti močnejše kontrole, ožji dostop in bolj agresivno spremljanje. Ključi izvajalnega okolja ne smejo imeti skrbniških pooblastil, razen če obstaja poseben, pregledan razlog.

Odkrivanje uhajanj in nenormalne uporabe

Odkrivanje uhajanj deluje najbolje, ko se več sistemov krepi. Skrivno skeniranje nadzora vira lahko ujame ključe, dodeljene repozitorijem. Preverjanja CI lahko blokirajo očitna puščanja pred združitvijo. Vzorci po meri lahko zaznajo notranje formate ključev. Nadzorne plošče ponudnika lahko razkrijejo nenavadno dejavnost. Telemetrija prehoda lahko prikaže nove naslove IP, nove geografske lokacije, neuspele izbruhe avtentikacije, nenadno hitrost porabe ali klice nepričakovanih modelov.

Uporabne varnostne nadzorne plošče vključujejo mirujoče ključe, ključe brez lastnikov, ključe brez omejitev, ključe, ki se bližajo izteku, ključe, uporabljene iz novih omrežij, ključe s hitro rastjo žetonov, zamrznjene ključe, ki še prejemajo promet, neuspele izbruhi avtentikacije in ključi strank, ki se približujejo zgornjim mejam porabe.

Zaznavanje mora zajemati tudi dnevnike in asinhrone sisteme. Webhooki, opravila v ozadju, čakalne vrste in zakasnjena dokončanja potrebujejo ID-je zahtev in dodelitev izvirnega ključa. V nasprotnem primeru sumljivega povratnega klica ali paketnega rezultata morda ne bo mogoče povezati s ključem in najemnikom, ki ga je ustvaril.

Ko se v zgodovini Git pojavi skrivnost, ni dovolj, da jo odstranite iz repozitorija. Vsi, ki so dostopali do skladišča, gradili dnevnike, zrcala, razcepe, pakirali artefakte ali predpomnjene strani, so morda že kopirali ključ. Poverilnico je treba razveljaviti ali zamrzniti in nato zamenjati.

Odziv na ogrožen API ključ

Dober načrt odziva na incident je kratek, vajen in natančen. Prva odločitev je običajno, ali zamrzniti ali preklicati. Zamrznitev hitro ustavi promet, hkrati pa ohrani zapis za preiskavo. Preklic trajno onemogoči ključ. Nekatere ekipe najprej uporabijo zamrznitev, ko potrebujejo kontinuiteto revizije in možnosti takojšnjega povrnitve; drugi se samodejno prekličejo zaradi potrjenih javnih razkritij. Vsak pristop potrebuje avtomatizacijo in jasno avtoriteto.

Praktičen potek odziva izgleda takole:

1. Zamrznite ali prekličite domnevni ključ glede na resnost in zaupanje.
2. Določite lastnika, najemnika, delovno obremenitev, obsege, dostop do modela, pravilnik o porabi in zadnjo uporabo časovnica.
3. Preglejte uporabo nenavadnih pozivov, modelov, končnih točk, orodij, IP-jev, količine žetonov in stroškov.
4. Ocenite prizadete podatke, najemnike, nadaljnja dejanja in vpliv zaračunavanja.
5. Izdajte nadomestni ključ s popravljenim obsegom in omejitvami.
6. Odstranite glavni vzrok, kot je odobrena skrivnost, izpostavljeni dnevnik, preširoka spremenljivka CI ali sveženj na strani odjemalca.
7. Dodajte nadzor za preprečevanje, kot je tajno skeniranje, redigiranje dnevnika, ožji obsegi, krajši potek ali opozorila o porabi.
8. Dokumentirajte incident in posodobite runbooks.

Nadomestni korak ne bi smel ponovno ustvarite isto tveganje.Če je ključ ušel, ker je bil v skupni rabi v desetih storitvah, ga zamenjajte z ločenimi ključi storitvenega računa. Če je pricurljalo skozi dnevnike, popravite beleženje, preden izdate nov ključ. Če je porabil preveč, ker bi lahko poklical vsak model, dodajte dovoljene sezname modelov in omejite porabo.

Ključi, ki jih upravljajo prehodi, in dostop do umetne inteligence z več ponudniki

Ekipe umetne inteligence pogosto uporabljajo več ponudnikov modelov. Vsak ponudnik ima svoj model ključa, strukturo delovnega prostora, omejitve stopnje, imena modelov, cene in administrativne API-je. Upravljanje vsakega ključa ponudnika neposredno v vsaki aplikaciji pomnoži operativno tveganje.

Model ključa, ki ga upravlja prehod, lahko zmanjša to zapletenost. Aplikacije pokličejo prehod s stranskim ali notranjim ključem. Prehod preveri pristnost klicatelja, uporabi politiko najemnika, uveljavi nadzor modela in porabe, beleži uporabo in uporablja poverilnice ponudnika navzgor na strani strežnika. To je uporabno za aplikacije z več modeli, interne platforme, agencije in storitve prodajnih posrednikov.

Za Model Gate je tukaj pomembna vloga prehoda: centralizirani ključi za stranke, poenotena analitika uporabe, nadzor skupine, omejitve porabe, varnost IP, Telegram operativne integracije, avtomatizacija partnerja API in odziv na zlorabe. Za podjetja, ki strankam ali nadaljnjim storitvam zagotavljajo storitve, lahko Partner API avtomatizacija poskrbi za skladnost potekov dela ustvarjanja ključev, omejevanja posodobitev, zamrznitve in preprodajalcev namesto ročnega.

Prehod ne odstrani vseh odgovornosti skupine za aplikacije. Še vedno potrebujete varno shranjevanje, avtorizacijo zaledja, izolacijo najemnika, zasnovo končne točke, higieno CI/CD, pravilnik o podatkih o pozivih in odzivih ter omejitve na strani ponudnika, kjer so na voljo. Prehod postane nadzorna ravnina visoke vrednosti, zato potrebuje močno obokanje, revizijske dnevnike, nadzor dostopa, načrtovanje razpoložljivosti in upravno ločevanje.

Pogoste API napake pri upravljanju ključev

Najpogostejše napake so predvidljive. Ekipe dajo ključe ponudnika neposredno v odjemalske aplikacije. Za vsako storitev in stranko uporabljajo en proizvodni ključ. Menjajo se tako, da se najprej izbrišejo in kasneje razmestijo. Ustvarijo ključe brez lastnikov, omejitev, obsegov ali poteka. Beležijo polne Authorization glave. Za nadzor stroškov umetne inteligence se zanašajo samo na omejitve cen. Storitvam med izvajanjem dajejo skrbniške poverilnice. Iz Gita odstranijo razkriti ključ, ne da bi ga preklicali. Zaposlene izklopijo, osebne ključe, datoteke lokalnega okolja in spremenljivke CI pa pustijo aktivne.

Druga subtilna napaka je obravnavanje beleženja pozivov in odzivov kot zgolj operativnega. Podrobni dnevniki lahko pomagajo pri preiskavi zlorabe, vendar lahko vsebujejo tudi osebne podatke, vsebino strank, skrivnosti ali zakonsko predpisane informacije.Beleženje najprej metapodatkov je pogosto varnejše: privzeto zajemite prstne odtise ključev, ID-je modelov, število žetonov, stroške, statusne kode, odločitve pravilnikov in ID-je zahtev, nato pa zahtevajte nadzorovan dostop za globlje podatke o odpravljanju napak.

Kontrolni seznam za implementacijo

Močan API program za upravljanje ključev se lahko začne z osredotočenim kontrolnim seznamom:

• Ustvari popis vseh ključev, lastnikov, okolij, najemnikov, obsegov, omejitev in časovnih žigov zadnje uporabe.
• Ločite ključe glede na okolje, delovno obremenitev, najemnika, stranko in razred poverilnic.
• Premaknite poverilnice ponudnika na strani strežnika in iz brskalnikov, mobilnih aplikacij, prenosnikov in javnih odjemalcev.
• Uporabi najmanj privilegij za modele, končne točke, orodja, najemnike, proračune in skrbniške funkcije.
• Dodajte omejitve porabe, omejitve stopenj, sezname dovoljenih modelov, opozorila o nepravilnostih in kontrole zamrznitve v sili.
• Shranite skrivnosti v upravitelju skrivnosti, trezorju, zaščiteni shrambi spremenljivk CI ali poverilnici, ki jo upravlja prehod sistem.
• Popravite skrivnosti iz dnevnikov, sledi, analitike, podpornih orodij, webhookov in poročil o napakah.
• Izvedite rotacijo s prekrivajočimi se ključi, spremljanje zadnje uporabe, zamrznitev in končno brisanje.
• Integrirajte tajno skeniranje v repozitorije in CI/CD, vključno s ključem po meri vzorcev.
• Dokumentirajte vedenje izstopa za osebne ključe, storitvene račune, ključe delovnega prostora in ključe strank.
• Poverilnice sklepanja med izvajanjem naj bodo ločene od poverilnic skrbniškega ponudnika.
• Preizkusite odziv na incident, preden resnično uhajanje povzroči proces.

Zaključek

API pri upravljanju ključev za API-je umetne inteligence gre za nadzor nad identiteto, pooblastilom, stroški in radijem delovanja. Varni ključ ni le naključen niz. Ima lastnika, namen, obseg, okolje, proračun, potek, pot kroženja, revizijsko sled in načrt odzivanja na incident.

Praktični cilj ni ustvariti birokracije okoli vsake zahteve. Namen je narediti normalno delo varnejše: razvijalci lahko gradijo, storitve se lahko izvajajo, strankam je mogoče omogočiti in varnostne ekipe lahko odgovorijo, kaj se je zgodilo, ko ključ uhaja ali poraba skokovito naraste. Začnite z inventarjem in mejami, nato dodajte najmanjše pravice, varno shranjevanje, rotacijo, spremljanje in avtomatizacijo odzivanja. Za dostop z umetno inteligenco več ponudnikov lahko prehod centralizira velik del tega nadzora, vendar avtorizacija aplikacij in tajna higiena še vedno ostajata glavni inženirski odgovornosti.