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

Upravljanje ključev API-ja ni več majhna naloga na nadzorni plošči. Za ekipe, ki uporabljajo API-je umetne inteligence, je del varnostnega, stroškovnega in operativnega modela za vsako aplikacijo, ki pošilja pozive, prejema izhod modela, priklič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. Lahko izpostavi pozive in odgovore, sproži nepričakovane bremenitve, pokliče premijske modele, zažene orodja s pooblastilom aplikacije ali naredi odziv na incident odvisen od ugibanja.

Ta vodnik obravnava upravljanje ključev API kot življenjski cikel: kako so ključi zasnovani, izdani, shranjeni, omejeni, nadzorovani, rotirani in preklicani. Osredotoča se na dostop API-ja AI, kjer se običajnim skrbem glede varnosti API-ja pridružijo dostop do modela, poraba na podlagi žetonov, poverilnice več ponudnikov, dodeljevanje strank in odjemalci, združljivi z OpenAI.

Kje ključi API-ja ustrezajo varnosti API-ja

Ključ API-ja običajno dokazuje posedovanje poverilnice. 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 Top 10 varnostnih 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 zaračunavanja.

Trajni varnostni model API-ja ločuje tri pomisleke:

• Preverjanje: dokazovanje, da ima zahteva veljavno poverilnico, žeton ali seja.
• Avtorizacija: 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 omejen radij eksplozije.

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

Začnite s popisom ključev API v živo

Ne morete upravljati ključev, ki jih ne morete poimenovati. Prvi praktični korak je popis v živo vseh ključev API in poverilnicam podobnih objektov, ki jih uporabljajo vaši sistemi AI.

Vsaj vsak zapis ključa mora vključevati 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 za revizijo.

Popis mora zajemati več kot ključe produkcijskega č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 poverilnice API-ja in poverilnice ponudnika navzgor.

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 napaka pri upravljanju ključev API 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 izda prehod, od ključev ponudnika navzgor.

Meje okolja

Razvoj, uprizoritev 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 strank v živo, razen če obstaja strogo nadzorovan razlog.

Meje delovnih obremenitev

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-ja, usmerjen v stranko, mora biti zahteva povezana s stranko, najemnikom, aplikacijo in v idealnem primeru s psevdonimnim končnim uporabnikom ali akterjem. Ogrožen ključ za enega najemnika ne bi smel omogočati dostopa do podatkov, profila modela, proračuna ali dnevnikov drugega najemnika.

Meje poverilnic ponudnika

Ključi ponudnika navzgor se razlikujejo od ključev, ki jih izdate strankam ali notranjim aplikacijam. Poverilnice ponudnika bi morale ostati na strani strežnika, shranjene v trezorju ali tajnem upravitelju in nikoli ne biti poslane 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 poverilnice ponudnika navzgor zadrži za prehodom. To omogoča centralizacijo analitike uporabe, preklica, skupinskih kontrol in uveljavljanja pravilnikov med ponudniki. Če standardizirate odjemalce okoli API-ja, združljivega z OpenAI, postane meja prehoda še posebej pomembna, ker veliko orodij pričakuje en sam osnovni URL in žeton nosilca.

Uporabite najmanjši privilegij za modele, končne točke, orodja in porabite

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

Praktični pravilnik o ključih API-ja AI 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 ustvarjanje slik.
• Nedovoljeni skrbniški API-ji, API-ji za upravljanje ključev, API-ji za zaračunavanje in API-ji za upravljanje delovnega prostora za ključe izvajalnega okolja.
• Omejitve hitrosti na ključ za zahteve na minuto in žetone na minuto.
• Omejitve porabe na najemnika, na ekipo ali na stranko.
• Kontrole modela Premium, tako da potek dela z nizkim tveganjem ne more nenadoma uporabiti najdražjega modela.
• Dovoljenja orodja, na primer, ali lahko ključ kliče zunanji priključki, izvajanje kode, sistemi za pridobivanje ali poslovna dejanja.
• Seznami dovoljenih IP za stabilne delovne obremenitve na strani strežnika, kjer je omrežna pot predvidljiva.

Nadzor porabe je del varnosti API-jev 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 mora 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 določevanja cen modela AI za usmerjanje delovnih obremenitev glede na ceno in zmogljivost.

Shranjujte skrivnosti, kjer jim je mesto

Ključi API-ja spadajo v tajne upravitelje, konfiguracijo na strani strežnika, nadzorovane spremenljivke CI/CD ali prehod, podprt s trezorjem. Ne sodijo v izvorno kodo, JavaScript brskalnika, 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 poverilnic dolgotrajnega 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 avtorizacijske 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.

Dnevniki in sistemi 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 ključev API. Uredite skrivnosti v sledovih, obrnite dnevnike proxyja, poročila o izjemah, obremenitve webhooka, podporna orodja, analitične dogodke in čakalne vrste mrtvih pisem.

Izdelajte rotacijo pred nujnim primerom

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 menjajte 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. Izvajalni ključi ne bi smeli imeti skrbniških pooblastil, razen če obstaja poseben, pregledan razlog.

Odkrivanje puščanj in nenormalne uporabe

Odkrivanje puščanj 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 vedno prejemajo promet, neuspešno preverjanje pristnosti izbruhi 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, nato pa jo zamenjati.

Odziv na ogrožen ključ API-ja

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 pooblastilo.

Praktičen tok odziva izgleda takole:

1. Zamrznite ali prekličite domnevni ključ na podlagi resnosti in zaupanja.
2. Identificirajte lastnika, najemnika, delovno obremenitev, obsege, dostop do modela, pravilnik porabe in zadnjo uporabljeno časovnico.
3. Preglejte uporabo za nenavadne pozive, modele, končne točke, orodja, IP-je, količino žetona in stroške.
4. Ocenite prizadete podatke, najemnike, dejanja na nižji stopnji in vpliv na zaračunavanje.
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, urejanje dnevnika, ožji obseg, krajši potek ali opozorila o porabi.
8. Dokumentirajte incident in posodobite tekoče knjige.

Korak zamenjave ne bi smel ponovno ustvariti enakega tveganja. Č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 več ponudnikov

Skupine 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 preprodajalcev.

Za Model Gate je tukaj pomembna vloga prehoda: centralizirani ključi, obrnjeni k strankam, poenotena analitika uporabe, nadzor skupine, omejitve porabe, varnost IP, operativne integracije Telegrama, avtomatizacija API-ja za partnerje in odziv na zlorabe. Za podjetja, ki zagotavljajo strankam ali nadaljnjim storitvam, lahko Avtomatizacija API-ja za partnerje omogoči skladnost potekov dela ustvarjanja ključev, omejevanja posodobitev, zamrznitev in preprodajalcev namesto ročnega.

Prehod ne odvzame vsake odgovornosti ekipe 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 administrativno ločitev.

Pogoste napake pri upravljanju ključev API

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 avtorizacijske 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 program za upravljanje ključev API se lahko začne z osredotočenim kontrolnim seznamom:

• Ustvarite popis vseh ključev, lastnikov, okolja, najemniki, obsegi, omejitve in časovni žigi zadnje uporabe.
• Ključe ločite glede na okolje, delovno obremenitev, najemnika, stranko in razred poverilnic.
• Premaknite poverilnice ponudnika na strani strežnika in iz njih iz brskalnikov, mobilnih aplikacij, prenosnikov in javnih odjemalcev.
• Uporabite najmanjši privilegij za modele, končne točke, orodja, najemnike, proračune in skrbništvo funkcije.
• Dodajte omejitve porabe, omejitve stopnje, sezname dovoljenih modelov, opozorila o anomalijah in nadzor zamrznitve v sili.
• Shranite skrivnosti v upravitelju skrivnosti, trezorju, zaščiteni shrambi spremenljivk CI ali sistemu poverilnic, ki ga upravlja prehod.
• Uredite skrivnosti iz dnevnikov, sledi, analitike, podpornih orodij, spletnih kavljev in napak poročila.
• Implementirajte rotacijo s prekrivajočimi se ključi, nadzorom zadnje uporabe, zamrznitvijo in končnim izbrisom.
• Integrirajte tajno skeniranje v repozitorije in CI/CD, vključno z vzorci ključev po meri.
• Dokumentirajte vedenje odhoda za osebne ključe, storitvene račune, ključe delovnega prostora in ključe strank.
• Poverilnice sklepanja med izvajanjem hranite ločeno od skrbniškega ponudnika poverilnice.
• Preizkusite odziv na incident, preden resnično uhajanje prisili postopek.

Zaključek

Upravljanje ključev API-ja za API-je AI se nanaša na 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 incidente.

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ši privilegij, 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.