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

En ključ API LLM v skupni rabi je primeren do prvega uhajanja, nepojasnjenega računa ali izpada proizvodnje. Praktični cilj upravljanja ključev API-ja ni le ohranjanje skrivnosti poverilnice. Namenjen je omejitvi radija eksplozije, uporabi atributov, varnemu rotiranju, odkrivanju nenormalne porabe in preklicu dostopa brez zloma nepovezanih aplikacij.

Ta vodnik daje ekipam operativni model za ključe API-ja LLM 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: Varnostna navodila za ključ API OpenAI priporočajo, da vsak član skupine uporablja edinstven ključ API, pravijo, da je deljenje ključev v nasprotju s pogoji uporabe, in priporočajo dodeljevanje dovoljenj posameznim ključem, kjer je to podprto. Smernice OpenAI prav tako odsvetujejo uvajanje ključev API v okoljih na strani odjemalca, kot so brskalniki ali mobilne aplikacije, ker se izpostavljeni ključi lahko zlorabljajo za pošiljanje zahtev v imenu lastnika.

Priporočilo: ustvarite ključe okoli operativnih meja, ne okoli priročnosti. Pogoste meje vključujejo:

• Okolje: produkcija, uprizoritev, razvoj, peskovnik.
• Aplikacija: zaledje chatbota, 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.

Dober privzetek 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 skupno rabo poverilnic ponudnika navzgor.

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, naj se ključi API ne uporabljajo 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še zaledje ali prehod API-ja AI 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, da uveljavite pravila izdelka, preden pride do porabe. Na primer, uporabnik brezplačnega načrta je lahko omejen na manjše modele, plačan 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 ima v lasti razkriti ključ. To je napaka inventarja.

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

Priporočilo: vsak ključ mora imeti metapodatke. Sledite vsaj:

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

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

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platforma-lowcost-2026q3
najemnik-acme-prod-standard-2026q3
dev-jlee-peskovnik-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" in odgovorni lastnik 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č bi moral biti sposoben narediti le tisto, kar zahteva njegova delovna obremenitev.

Priporočilo: omejite tipke z enim ali več naslednjimi kontrolniki, kjer so podprti:

• Projekt: povežite ključe s projektom in ne s celotno organizacijo.
• Model: dovoli samo odobrene modele; privzeto blokira drage ali poskusne modele.
• Končna točka: dovoli zaključke klepeta, vendar zavrni nepovezane skrbniške končne točke.
• Pot ponudnika: dovolite prehodno pot namesto neposrednega dostopa do vseh ponudnikov navzgor.
• 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 strankam, ne bi smel porabiti proračuna drugega najemnika.

Načrtujte nadzor porabe v plasteh

Varnost API LLM 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: Varnostna navodila za račun OpenAI priporočajo razumne omejitve porabe in ugotavljajo, da lahko ločeni ključi API olajšajo uporabo glede na funkcijo, skupino, izdelek ali projekt. Poročanje o uporabi OpenAI podpira tudi podrobno analizo prek polj, kot so ID projekta, ID uporabnika, ID ključa API-ja, model, serija in raven storitve.

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

• Omejitev na ključ: preprečuje, da bi ena poverilnica porabila celoten proračun.
• Omejitev na ekipo: ohranja vidno in odgovorno uporabo oddelka.
• Omejitev na najemnika: izolira uporabo strank v scenarijih SaaS in agencijah.
• Prag dnevne anomalije: sproži opozorila, ko uporaba odstopa od običajnih vzorcev.
• Globalna zaustavitev v sili: omogoča hitro zaustavitev, 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 na 80 odstotkov.
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.

Sledite 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.
• ID ključa API ali ID navideznega ključa.
• Identifikator aplikacije, ekipe, najemnika, uporabnika ali delovnega toka.
• 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 za upravljanje ključev NIST obravnavajo upravljanje ključev kot disciplino življenjskega cikla, vključno z ustvarjanjem, shranjevanjem, aktivacijo, rotacijo, prekinitvijo, preklicem in uničenjem. Za ključe API LLM rotacija ni enkraten varnostni opravek; to je operativni tok dela.

Priporočilo: uporabite ta postopek rotacije brez izpadov:

1. Ustvarite nadomestni ključ. Ujemite zahtevana dovoljenja, proračun, pot in metapodatke. Starega ključa še ne prekličite.
2. Shranite ga v tajnem upravitelju. Izogibajte se lokalnim datotekam, sporočilom klepeta, vstopnicam in prilepljenim spremenljivkam okolja.
3. Postopoma 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. Zamrznitev piše 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. Zamudeni pri reviziji. Preiščite 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 je treba napisati pred incidentom, ne pa improvizirati v paniki zaračunavanja.

Takojšnja omejitev

1. Prekličite ali začasno ustavite izpostavljeni ključ.
2. Če bi preklic prekinil proizvodnjo, najprej izdajte zamenjavo in takoj preklopite kritični promet.
3. Blokirajte pot, najemnika ali ponudnika, če je zloraba še vedno aktivna.
4. Ohranite dnevnike, potrebne za odkrivanje zlorabe.

Preiskava

1. Ugotovite, kje se je ključ pojavil: repozitorij, čelni paket, mobilna aplikacija, dnevniška datoteka, vstopnica za podporo, 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 neobičajne 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 lastniško ekipo in prizadete deležnike strank, kadar je to primerno.
3. Dodajte skrivno 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 potekov dela, specifičnih za stranke, z LLM-ji, bo uhajanje ključev vedno bolj najprej izgledalo kot stroškovni incidenti in nato varnostni incidenti. 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 končno točko API, združljivo z OpenAI, 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.
• Poenoteno obračunavanje API-ja AI in poročanje o porabi na ključ.
• Virtualni ključi na ravni stranke za agencije, preprodajalce ali najemnike SaaS.
• Osrednji dovoljeni seznami modelov, pravilniki o poti in začasna ustavitev.
• 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 deljene 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.
• Usmerjanje zahtev odjemalcev prek zaledja ali prehoda AI API.
• 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 porabe na ključ, ekipo, najemnika in globalno porabo.
• ID ključa dnevnika, logični akter, model, uporaba žetona, ocenjeni stroški, zakasnitev in statusna koda.
• Ustvarite potek dela 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. Določite mu lastnika, razdelite ga po mejah, dodajte proračun, ga premaknite 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 o shranjevanju 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 le ena aplikacija, najemnik ali delovni tok – ne celoten proračun za umetno inteligenco.

Sorodno branje

• produkcijsko usmerjanje in nadomestni API LLM API oblikovanje
• prejšnje opombe spletnega dnevnika Model Gate
• uvodni članek Model Gate