LLM API Key Management za ekipe: izolacija, rotacija, omejitve porabe in odziv na uhajanje

En skupni ključ LLM API je priročen do prvega uhajanja, nepojasnjenega računa ali izpada proizvodnje. Praktični cilj API upravljanja ključev ni le ohranjanje skrivnosti poverilnice. Namenjen je omejitvi radija eksplozije, uporabi atributov, varnemu vrtenju, zaznavanju nenormalne porabe in preklicu dostopa brez zloma nepovezanih aplikacij.

Ta vodnik daje ekipam operativni model za LLM API ključe med ponudniki, prehodi, notranjimi aplikacijami, agencijami in izdelki, namenjenimi strankam. Ločuje preverjena varnostna dejstva od priporočenih izbir implementacije in se izogiba predpostavki, da vsak ponudnik izpostavlja enake kontrole.

Operacijski model: vsak ključ potrebuje mejo

Uporabna ključna strategija se začne z enim vprašanjem: kaj bi moralo odpovedati, če je ta ključ zlorabljen ali preklican? Če je odgovor »celotno podjetje«, je ključ preširok.

Dejstvo: OpenAI API varnostna navodila za ključe priporočajo, da vsak član skupine uporablja edinstven ključ API, pravi, da je deljenje ključev v nasprotju s pogoji uporabe, in priporoča dodeljevanje dovoljenj posameznim ključem, kjer je to podprto. Smernice OpenAI prav tako odsvetujejo uvajanje ključev API v okolja na strani odjemalca, kot so brskalniki ali mobilne aplikacije, ker je mogoče izpostavljene ključe zlorabiti za pošiljanje zahtev v imenu lastnika.

Priporočilo: ustvarite ključe okoli meja delovanja, ne glede na priročnost. Pogoste meje vključujejo:

• Okolje: produkcija, uprizarjanje, razvoj, peskovnik.
• Aplikacija: zaledje klepetalnega robota, procesor dokumentov, pomočnik za kodiranje, potek dela analitike.
• Lastnik: ekipa, storitveni račun, razvijalec, stranka agencije, najemnik.
• Raven tveganja: javni potek dela, notranja avtomatizacija, paketno opravilo, eksperimentalna integracija.
• Ponudnik ali pot: zgornji ponudnik A, ponudnik B, odobrena skupina modelov ali prehodna pot.

Dobra privzeta vrednost za rastočo ekipo je: en produkcijski ključ na aplikacijo ali storitev, en neprodukcijski ključ na okolje in ločeni ključi za visoko tvegano avtomatizacijo ali uporabo na ravni stranke. Agencije in preprodajalci bi morali raje imeti navidezne ključe na ravni stranke, kot pa deliti poverilnice zgornjega ponudnika.

Ključev ponudnika nikoli ne postavljajte v porazdeljene odjemalce

Brskalniki, mobilne aplikacije, namizne razširitve, javni vtičniki in skripti na strani strank so sovražna mesta za neobdelane poverilnice ponudnika. Tudi če zakrijete ključ, je mogoče distribuirano programsko opremo pregledati, kopirati ali prestreči.

Dejstvo: OpenAI izrecno opozarja, da se ključev API ne namešča v okoljih na strani odjemalca. Raziskave o mobilnih aplikacijah so poročale tudi o vztrajnem uhajanju poverilnic LLM API v aplikacijah za iOS, kar podpira isto praktično opozorilo: poverilnice, vdelane v porazdeljene odjemalce, ponavadi pobegnejo.

Priporočilo: uporabite vzorec zaledja ali prehoda:

1. Odjemalec preveri pristnost vaše aplikacije z uporabo uporabniške seje, JWT, žetona stranke ali kratkotrajne poverilnice.
2. Vaše zaledje potrdi uporabnika, najemnika, načrt in zahtevano operacijo.
3. Vaš zaledni ali prehod AI API pokliče navzgornjega ponudnika LLM z uporabo zaščitenih poverilnic na strani strežnika.
4. Odgovor se vrne stranki po preverjanju pravilnika, beleženju in obračunu stroškov.

Ta zasnova vam omogoča uveljavitev pravil izdelkov, preden pride do porabe. Na primer, uporabnik brezplačnega načrta je lahko omejen na manjše modele, plačani najemnik lahko prejme višje dnevne kvote, notranji skrbniški potek dela pa lahko uporablja ločeno pot s strožjim nadzorom.

Izdelajte ključni inventar, preden potrebujete odziv na incident

Ekipe med uhajanjem pogosto odkrijejo, da nihče ne ve, katera storitev je lastnik izpostavljenega ključa. To je napaka inventarja.

Dejstvo: OWASP API Varnost Top 10 2023 vključuje neustrezno upravljanje inventarja kot glavno API varnostno tveganje. Za infrastrukturo LLM je ključni inventar del API inventarja: vedeti morate, katere poverilnice obstajajo, do česa lahko dostopajo in kdo je njihov lastnik.

Priporočilo: vsak ključ mora imeti metapodatke. Vsaj skladba:

• Ime ključa in interni ID ključa.
• Ekipa lastnika in kontakt za nujne primere.
• Okolje: produkcija, uprizarjanje, razvoj, peskovnik.
• Namen: aplikacija, potek dela, najemnik, integracija ali uporaba razvijalca.
• Dovoljeni ponudniki, modeli, končne točke ali poti, kjer so podprti.
• Ustvarjen datum, zadnji uporabljeni časovni žig in načrtovani datum pregleda.
• Zgornja meja porabe ali kvota.
• Stanje menjave in konfiguracija povezane uvedbe.

Uporabite dogovor o poimenovanju, ki ostane berljiv v opozorilih. Na primer:

prod-supportbot-teamcx-gpt4class-2026q3
stg-docprocessor-platform-lowcost-2026q3
tenant-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

Natančna oblika je manj pomembna kot doslednost. Cilj je, da lahko v opozorilu piše, da je tenant-acme-prod-standard presegel svoj dnevni prag, odgovorni lastnik pa ve, kaj mora storiti.

Uporabi najmanjši privilegij, kjer platforma to omogoča

Vsak ponudnik ali prehod ne razkrije enakih kontrol dovoljenj, vendar je načelo dosledno: ključ mora biti sposoben narediti le tisto, kar potrebuje njegova delovna obremenitev.

Priporočilo: omejite ključe z enim ali več naslednjimi kontrolniki, kjer je podprto:

• Projekt: povežite ključe s projektom in ne s celotno organizacijo.
• Model: dovoli samo odobrene modele; privzeto blokirajte drage ali poskusne modele.
• Končna točka: dovoli zaključke klepeta, vendar zavrne nepovezane administrativne končne točke.
• Ponudnikova pot: dovoli prehodno pot namesto neposrednega dostopa do vsakega zgornjega ponudnika.
• Rate: omejitev zahtev na minuto ali sočasnih zahtev.
• Proračun: uveljavite omejitve porabe na ključ, ekipo ali najemnika.

Na primer, uprizoritveni ključ običajno ne potrebuje dostopa do najdražjega proizvodnega modela. Klasifikator dokumentov verjetno ne potrebuje dostopa do generiranja slik. Ključ najemnika, usmerjen k stranki, ne bi smel porabiti proračuna drugega najemnika.

Oblikujte nadzor porabe v plasteh

LLM API varnost in nadzor stroškov se prekrivata. Ključ, ki je ušel, je pogosto zaznan kot anomalija pri zaračunavanju, preden je zaznan kot varnostni dogodek.

Dejstvo: OpenAI varnostna navodila za račun priporočajo razumne omejitve porabe in ugotavljajo, da lahko ločeni API ključi olajšajo uporabo glede na funkcijo, ekipo, izdelek ali projekt. Poročanje o uporabi OpenAI podpira tudi podrobno analizo prek polj, kot so ID projekta, ID uporabnika, ID ključa API, model, serija in raven storitve.

Priporočilo: uporabite večplastne omejitve namesto ene globalne omejitve:

• Omejitev na ključ: preprečuje, da bi ena poverilnica porabila celoten proračun.
• Omejitev na ekipo: omogoča, da je uporaba oddelka vidna in odgovorna.
• Omejitev na najemnika: izolira uporabo strank v scenarijih SaaS in agencijah.
• Dnevni prag anomalije: sproži opozorila, ko uporaba odstopa od običajnih vzorcev.
• Globalna zaustavitev v sili: omogoča hitro prekinitev, ko je aktivna zloraba.

Trde omejitve so uporabne, vendar lahko prekinejo zakonita paketna opravila. Varnejši proizvodni vzorec je zaporedje kontrol:

1. Opozorilo pri 50 odstotkih pričakovane dnevne porabe.
2. Eskalirajte pri 80 odstotkih.
3. Zadušite nekritični promet pri 100 odstotkih.
4. Pred uporabo globalne zaustavitve blokirajte samo ključ, najemnika ali pot, ki moti.

Kompromis: strogi proračuni zmanjšajo tveganje zaračunavanja, vendar lahko povzročijo tveganje razpoložljivosti. Omejitve ravni glede na delovno obremenitev: interaktivni produkcijski promet, plačan promet, namenjen strankam, opravila v ozadju, poskusi in peskovniki za razvijalce ne bi smeli vsi odpovedati na enak način.

Sledenje uporabi po ključu in logičnem akterju

Ključ identificira poverilnico. Morda ne identificira dejanskega uporabnika, najemnika, funkcije ali poteka dela, ki je povzročil zahtevo. Za uporabno analitiko uporabe umetne inteligence zabeležite tehnične in poslovne razsežnosti.

Priporočilo: zberite naslednja polja za vsako zahtevo, kjer to dovoljujeta zasebnost in politika:

• ID zahteve in časovni žig.
• API ID ključa ali ID navideznega ključa.
• Identifikator aplikacije, ekipe, najemnika, uporabnika ali poteka dela.
• Ponudnik, model, pot in raven storitve.
• Število žetonov za poziv in dokončanje ali enakovredne enote uporabe.
• Ocenjeni stroški.
• Zakasnitev, statusna koda, število ponovnih poskusov in razred napake.

Ne spreminjajte opazovanja stroškov v nepotrebno zbiranje podatkov. Izogibajte se privzetemu shranjevanju celotnih pozivov, če morda vsebujejo osebne podatke, skrivnosti strank ali zakonsko predpisano vsebino. V mnogih primerih so zgoščeni ID-ji uporabnikov, ID-ji najemnikov, število žetonov in imena modelov dovolj za povratno bremenitev in odkrivanje nepravilnosti.

Rotacija brez izpadov: varen potek dela

Dejstvo: Navodila NIST za upravljanje ključev obravnavajo upravljanje ključev kot disciplino življenjskega cikla, vključno z ustvarjanjem, shranjevanjem, aktivacijo, rotacijo, začasno prekinitvijo, preklicem in uničenjem. Za ključe LLM API rotacija ni enkraten varnostni opravek; to je operativni potek dela.

Priporočilo: uporabite ta postopek rotacije brez izpadov:

1. Ustvarite nadomestni ključ. Ujemite zahtevana dovoljenja, proračun, pot in metapodatke. Ne prekličite še starega ključa.
2. Shranite ga v skrivnem upravitelju. Izogibajte se lokalnim datotekam, sporočilom klepeta, vstopnicam in prilepljenim spremenljivkam okolja.
3. Postopno uvedite konfiguracijo. Posodobite eno storitev, regijo, skupino delavcev ali segment najemnika naenkrat.
4. Preverite gibanje prometa. Potrdite, da zahteve prihajajo pod novim ključem in da stopnje napak in zakasnitve ostajajo normalne.
5. Zamrzni pisanje v stari ključ. Prepreči, da bi se nove uvedbe sklicevale nanj.
6. Prekličite stari ključ. Ko se promet premakne, ga raje onemogočite, kot da ga pustite kot pozabljeno rezervo.
7. Zamude pri reviziji. Išči dnevnike, manifeste uvajanja, skrivne shrambe, spremenljivke CI in napake med izvajanjem za stari ID ključa.

Za aplikacije, ki še vedno uporabljajo statične spremenljivke okolja, bo rotacija občutljiva. Pomaknite se proti dinamičnemu skrivnemu nalaganju, centralizirani konfiguraciji ali virtualnim ključem, ki jih upravlja prehod. Vsaj dokumentirajte, katera uvedba se mora spremeniti pred preklicem.

Runbook za odziv na uhajanje

Ko ključ pušča, je hitrost pomembna. Odgovor bi moral biti napisan pred incidentom, ne pa improviziran v paniki zaračunavanja.

Takojšnje zadrževanje

1. Prekliči ali začasno ustavi izpostavljeni ključ.
2. Če bi preklic prekinil proizvodnjo, najprej izdajte zamenjavo in takoj preklopite kritični promet.
3. Blokiraj pot, najemnika ali ponudnika, če je zloraba še vedno aktivna.
4. Ohranitev dnevnikov, potrebnih za prepoznavanje zlorabe.

Preiskava

1. Ugotovite, kje se je ključ pojavil: repozitorij, čelni paket, mobilna aplikacija, dnevniška datoteka, podporna vozovnica, orodje prodajalca ali klepet.
2. Poiščite zadnjo znano zakonito uporabo.
3. Primerjajte uporabo pred in po domnevni izpostavljenosti.
4. Preglejte uporabljene modele, zahtevajte količino, ceno, geografsko lokacijo, če je na voljo, in nenavadne statusne kode.
5. Preverite, ali so morda izpostavljene tudi odvisne skrivnosti ali sosednji sistemi.

Okrevanje in preprečevanje

1. Zamenjava odvisnih poverilnic, če je isto okolje morda razkrilo več kot eno skrivnost.
2. Obvestite ekipo lastnikov in prizadete zainteresirane strani strank, kadar je to primerno.
3. Dodaj tajno skeniranje v repozitorije in cevovode CI.
4. Preprečite ponovitev tako, da klice na strani odjemalca premaknete za zaledje ali prehod.
5. Dokumentirajte časovnico incidenta, glavni vzrok, vpliv na stroške in izboljšave nadzora.

Predvidevanje: ko ekipe povezujejo več agentov, vtičnikov, orodij za avtomatizacijo in delovnih tokov, specifičnih za stranke, z LLM-ji, bo uhajanje ključev vse bolj videti kot najprej stroškovni incident in nato varnostni incident. Ekipe z dodeljevanjem po ključu in nadzorom proračuna jih bodo rešile hitreje kot ekipe, ki uporabljajo eno skupno poverilnico.

Ključi, ki jih upravlja prehod za skupine z več ponudniki

Če vaša organizacija uporablja več ponudnikov LLM, lahko neposredni ključi ponudnika ustvarijo razpršeno upravljanje: različne nadzorne plošče, različne poglede obračunavanja, različne modele dovoljenj in nedosledne postopke rotacije.

Sloj ključev, ki ga upravlja prehod, lahko to poenostavi tako, da izda ključe, usmerjene v aplikacijo, medtem ko poverilnice ponudnika navzgor ostanejo skrite. Aplikacije kličejo OpenAI-združljivo API končno točko, medtem ko prehod obravnava usmerjanje, analitiko uporabe, dodeljevanje zaračunavanja in uveljavljanje pravilnika.

Priporočilo: razmislite o prehodu ali posredniškem sloju, ko potrebujete:

• Eno mesto za upravljanje skupinskih ključev pri več ponudnikih.
• Enotno AI API obračunavanje in poročanje o porabi po ključu.
• Virtualni ključi na ravni stranke za agencije, preprodajalce ali najemnike SaaS.
• Osrednji dovoljeni seznami modelov, pravilniki o poti in začasna prekinitev.
• Dodeljevanje uporabe glede na najemnika, funkcijo, potek dela ali partnersko stranko.

Kompromis: prehod izboljša upravljanje in skrije poverilnice navzgor, vendar postane del poti zahteve. Spremljajte ga kot produkcijsko infrastrukturo: pomembni so zakasnitev, razpoložljivost, stopnje napak, čakalne vrste, vedenje pri ponovnem poskusu in napake, specifične za ponudnika.

Kontrolni seznam za implementacijo

• Zamenjajte skupne ključe za celotno organizacijo s ključi, ki obsegajo aplikacijo, okolje, najemnika ali potek dela.
• Odstranite neobdelane ključe ponudnika iz brskalnikov, mobilnih aplikacij, namiznih razširitev in javnih skriptov.
• Usmeri zahteve odjemalcev prek zaledja ali API prehoda AI.
• Vsakemu ključu pripnite metapodatke o lastniku, namenu, okolju, dovoljenih modelih, proračunu in pregledu.
• Uporabi najmanjši privilegij: projekt, končna točka, model, pot, stopnja in nadzor proračuna, kjer so na voljo.
• Nastavite omejitve glede na ključ, ekipo, najemnika in globalne porabe.
• ID ključa dnevnika, logični akter, model, uporaba žetona, ocenjeni stroški, zakasnitev in koda stanja.
• Ustvarite delovni tok rotacije brez izpadov in ga preizkusite pred nujnim primerom.
• Napišite priročnik za odzivanje na uhajanje s koraki za zadrževanje, preiskavo in preprečevanje.
• Preglejte neaktivne ključe in prekličite vse brez lastnika ali nedavne zakonite uporabe.

Dejanski sklep

Začnite s ključem z največjim tveganjem: tistim, ki se uporablja v proizvodnji, si ga deli več ljudi, je vdelan na preveč mestih ali je odgovoren za največjo porabo. Dodelite mu lastnika, razdelite ga po mejah, dodajte proračun, premaknite ga za zaledje ali prehod, če ga stranke lahko vidijo, in dokumentirajte, kako ga rotirati.

Potem ponovite. Močno upravljanje ključev LLM API ni ena sama odločitev glede shranjevanja skrivnosti. Gre za življenjski cikel: popis, izolacija, najmanjši privilegij, dodeljevanje uporabe, nadzor stroškov, rotacija in odziv na uhajanje. Izplačilo je preprosto: ko gre kaj narobe, bi morala biti ogrožena samo ena aplikacija, najemnik ali potek dela – ne celoten proračun za umetno inteligenco.

Sorodno branje

• proizvodnja LLM API usmerjanje in nadomestno oblikovanje
• prejšnji Model Gate blog opombe
• uvodni Model Gate članek