LLM API võtmehaldus meeskondade jaoks: isoleerimine, rotatsioon, kululimiidid ja lekkereageerimine

Üks jagatud LLM API võti on mugav kuni esimese lekke, seletamatu arve või tootmiskatkestuseni. API Võtmehalduse praktiline eesmärk ei ole ainult mandaadi saladuse hoidmine. Selle eesmärk on piirata plahvatuse raadiust, omistada kasutust, ohutult pöörata, tuvastada ebatavalisi kulutusi ja tühistada juurdepääs, ilma et sellega seotud rakendusi purustataks.

See juhend annab meeskondadele LLM API võtmete töömudeli pakkujate, lüüside, sisemiste rakenduste, agentuuride ja klientidele suunatud toodete vahel. See eraldab kontrollitud turvafaktid soovitatavatest rakendusvalikutest ja väldib eeldamist, et iga pakkuja kasutab samu juhtelemente.

Kasutusmudel: iga võti vajab piiri

Kasulik võtmestrateegia algab ühest küsimusest: mis peaks ebaõnnestuma, kui seda võtit kuritarvitatakse või tühistatakse? Kui vastus on „kogu ettevõte”, on võti liiga lai.

Fakt: OpenAI klahvi API ohutusjuhistes soovitatakse igal meeskonnaliikmel kasutada kordumatut API võtit, öeldakse, et võtmete jagamine on vastuolus selle kasutustingimustega ja soovitab määrata üksikutele võtmetele load, kui seda toetatakse. Samuti soovitatakse OpenAI-i juhistes mitte juurutada võtmeid API kliendipoolsetes keskkondades, näiteks brauserites või mobiilirakendustes, kuna avalikustatud võtmeid saab omaniku nimel taotluste esitamiseks kuritarvitada.

Soovitus: loo võtmed tööpiiride, mitte mugavuse ümber. Ühised piirid on järgmised:

• Keskkond: tootmine, lavastus, arendus, liivakast.
• Rakendus: vestlusroti taustaprogramm, dokumendiprotsessor, kodeerimisassistent, analüüsi töövoog.
• Omanik: meeskond, teenusekonto, arendaja, agentuuri klient, rentnik.
• Riskitase: avalik töövoog, sisemine automatiseerimine, paketttöö, eksperimentaalne integreerimine.
• Pakkuja või marsruut: ülesvoolu pakkuja A, pakkuja B, kinnitatud mudelirühm või lüüsi marsruut.

Kasvava meeskonna hea vaikeseade on: üks tootmisvõti rakenduse või teenuse kohta, üks mittetootmisvõti keskkonna kohta ja eraldi võtmed kõrge riskiga automatiseerimiseks või klienditasemel kasutamiseks. Agentuurid ja edasimüüjad peaksid eelistama klienditasemel virtuaalseid võtmeid, mitte jagama ülesvoolu pakkuja mandaate.

Ärge kunagi pange teenusepakkuja võtmeid hajutatud klientidele

Brauserid, mobiilirakendused, töölaualaiendid, avalikud pistikprogrammid ja kliendipoolsed skriptid on vaenulikud kohad pakkuja töötlemata mandaatide jaoks. Isegi kui võti hägustab, saab levitatud tarkvara kontrollida, kopeerida või pealtkuulada.

Fakt: OpenAI hoiatab selgesõnaliselt mitte juurutada API võtmeid kliendipoolsetes keskkondades. Mobiilirakenduste uurimine on samuti teatanud püsivast LLM API mandaatide lekkimisest iOS-i rakendustes, mis toetab sama praktilist hoiatust: hajutatud klientidele manustatud mandaadid kipuvad põgenema.

Soovitus: kasutage tausta- või lüüsimustrit:

1. Klient autentib teie rakenduse kasutajaseanssi, JWT-d, kliendiluba või lühiajalist mandaati kasutades.
2. Teie taustaprogramm kinnitab kasutaja, rentniku, plaani ja nõutud toimingu.
3. Teie tausta- või tehisintellekti API lüüs helistab kaitstud serveripoolseid mandaate kasutades ülesvoolu LLM-i pakkujale.
4. Vastus tagastatakse kliendile pärast eeskirjade kontrollimist, logimist ja kuluarvestust.

See kujundus võimaldab teil tootereegleid jõustada enne kulutamist. Näiteks võib vabaplaaniga kasutaja piirduda väiksemate mudelitega, tasuline üürnik võib saada suuremaid päevakvoote ja sisemine administraatori töövoog saab kasutada eraldi marsruuti rangema jälgimisega.

Koostage võtmevaru enne, kui vajate juhtumile reageerimist

Meeskonnad avastavad sageli lekke ajal, et keegi ei tea, millisele teenusele paljastatud võti kuulub. See on laoseisu rike.

Fakt: OWASP API Turvalisuse Top 10 2023 sisaldab ebaõiget varude haldamist kui peamist API turvariski. LLM-i infrastruktuuri puhul on võtmevarud osa API reklaamikohtadest: peate teadma, millised mandaadid on olemas, millele neil on juurdepääs ja kellele need kuuluvad.

Soovitus: igal võtmel peaksid olema metaandmed. Vähemalt lugu:

• Võtme nimi ja sisemine võtme ID.
• Omanikutiim ja hädaabikontakt.
• Keskkond: tootmine, lavastus, arendus, liivakast.
• Eesmärk: rakendus, töövoog, rentnik, integreerimine või arendaja kasutamine.
• Lubatud pakkujad, mudelid, lõpp-punktid või marsruudid, kus neid toetatakse.
• Loomise kuupäev, viimati kasutatud ajatempel ja kavandatud ülevaatuse kuupäev.
• Kulutuste ülemmäär või kvoot.
• Pööramise olek ja lingitud juurutamise konfiguratsioon.

Kasutage nimetamisviisi, mis jääb hoiatustes loetavaks. Näiteks:

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

Täpne vorming on vähem oluline kui järjepidevus. Eesmärk on, et hoiatus saaks öelda, et „üürnik-acme-prod-standard ületas oma päevase läve“ ja vastutav omanik teaks, mida teha.

Rakenda vähimat õigust seal, kus platvorm seda võimaldab

Mitte kõik pakkujad või lüüsid ei paku identseid lubade juhtelemente, kuid põhimõte on järjepidev: võti peaks suutma teha ainult seda, mida selle töökoormus vajab.

Soovitus: piirake võtmeid ühe või mitme järgmise juhtelemendiga, kui seda toetatakse:

• Projekt: siduge võtmed projektiga, mitte terve organisatsiooniga.
• Mudel: luba ainult heakskiidetud mudeleid; vaikimisi blokeerige kallid või eksperimentaalsed mudelid.
• Lõpp-punkt: lubage vestluse lõpetamist, kuid keelake mitteseotud administratiivsed lõpp-punktid.
• Pakkuja marsruut: lubage lüüsi marsruut, mitte otsejuurdepääs igale ülesvoolu pakkujale.
• Määr: taotluste piirmäär minutis või samaaegsed taotlused.
• Eelarve: jõustage kulupiirangud võtme-, meeskonna- või üürniku kohta.

Näiteks ei vaja etapivõti tavaliselt juurdepääsu kõige kallimale tootmismudelile. Tõenäoliselt ei vaja dokumentide klassifitseerimise töötaja juurdepääsu kujutiste genereerimisele. Kliendile suunatud üürniku võti ei tohiks kasutada teise üürniku eelarvet.

Kujundage kulukontrollid kihtidena

LLM API turvalisus ja kulude kontroll kattuvad. Lekkinud võti tuvastatakse sageli arveldusanomaaliana enne, kui see tuvastatakse turvasündmusena.

Fakt: OpenAI konto turvajuhised soovitavad mõistlikke kululimiite ja märgivad, et eraldi API võtmed võivad muuta funktsiooni, meeskonna, toote või projekti järgi kasutamise lihtsamaks. OpenAI kasutusaruandlus toetab ka üksikasjalikku analüüsi selliste väljade kaudu nagu projekti ID, kasutaja ID, API võtme ID, mudel, partii ja teenuse tase.

Soovitus: kasutage ühe üldise ülempiiri asemel kihilisi piiranguid:

• Võtmepiirang: takistab ühel mandaadil kogu eelarvet kulutamast.
• Tiimide piirang: hoiab osakonna kasutuse nähtavana ja vastutustundlikuna.
• Üürniku piirang: isoleerib klientide kasutuse SaaS-i ja agentuuri stsenaariumides.
• Igapäevane anomaalia lävi: käivitab hoiatused, kui kasutus erineb tavapärastest mustritest.
• Ülemaailmne hädaseiskamine: võimaldab kiiret peatamist, kui kuritarvitamine on aktiivne.

Kõrvad piirangud on kasulikud, kuid võivad katkestada seaduslikud pakktööd. Ohutum tootmismuster koosneb järgmistest juhtelementidest:

1. Hoiatus 50 protsendi kohta eeldatavast päevasest kulust.
2. Eskaleeruge 80 protsendiga.
3. Lähendage mittekriitilist liiklust 100 protsenti.
4. Enne globaalse sulgemise kasutamist blokeerige ainult rikkuv võti, rentnik või marsruut.

Trade-off: ranged eelarved vähendavad arveldusriski, kuid võivad tekitada saadavuse riski. Tasemepiirangud töökoormuse järgi: interaktiivne tootmisliiklus, klientidele suunatud tasuline liiklus, taustatööd, katsed ja arendaja liivakastid ei tohiks kõik ühtmoodi ebaõnnestuda.

Jälgige kasutamist võtme ja loogilise osaleja järgi

Võti identifitseerib mandaadi. See ei pruugi tuvastada tegelikku kasutajat, rentnikku, funktsiooni või töövoogu, mis päringu põhjustas. Kasuliku tehisintellekti kasutamise analüüsi saamiseks logige nii tehnilised kui ka ärimõõtmed.

Soovitus: koguge iga päringu jaoks järgmised väljad, kui privaatsus ja eeskirjad seda võimaldavad:

• Taotluse ID ja ajatempel.
• API võtme ID või virtuaalse võtme ID.
• Rakenduse, meeskonna, rentniku, kasutaja või töövoo identifikaator.
• Pakkuja, mudel, marsruut ja teenusetasand.
• Viip- ja lõpetamislubade arv või samaväärsed kasutusühikud.
• Hinnanguline kulu.
• Laitentsus, olekukood, korduskatsete arv ja veaklass.

Ärge muutke kulude jälgitavust tarbetuks andmete kogumiseks. Vältige vaikimisi täielike viipade salvestamist, kui need võivad sisaldada isikuandmeid, kliendisaladusi või reguleeritud sisu. Paljudel juhtudel piisab tagasimaksete ja kõrvalekallete tuvastamiseks räsistatud kasutaja-ID-dest, rentnike ID-dest, lubade arvust ja mudelinimedest.

Pööramine ilma seisakuta: ohutu töövoog

Fakt: NIST-i võtmehalduse juhistes käsitletakse võtmehaldust elutsükli distsipliinina, mis hõlmab genereerimist, salvestamist, aktiveerimist, pööramist, peatamist, tühistamist ja hävitamist. LLM API võtmete puhul ei ole pööramine ühekordne turvatöö; see on operatiivne töövoog.

Soovitus: kasutage seda ilma seisakuta rotatsiooniprotsessi:

1. Looge asendusvõti. Sobitage nõutavad load, eelarve, marsruut ja metaandmed. Ärge tühistage veel vana võtit.
2. Salvestage see salahaldurisse. Vältige kohalikke faile, vestlussõnumeid, pileteid ja kleebitud keskkonnamuutujaid.
3. Juutage konfiguratsioon järk-järgult. Värskendage korraga ühte teenust, piirkonda, töötajate rühma või rentniku segmenti.
4. Kinnitage liiklust. Veenduge, et taotlused saabuvad uue võtmega ning et veamäär ja latentsus jäävad normaalseks.
5. Külmutage vanale võtmele kirjutamine. Peatage uute juurutuste puhul sellele viitamine.
6. Tühista vana võti. Kui liiklus on kolinud, keelake see selle asemel, et jätta see unustatud varuvariandiks.
7. Audit stragglers. Otsingulogid, juurutusmanifestid, salajased salvestused, CI muutujad ja käitusaja vead vana võtme ID jaoks.

Rakenduste puhul, mis kasutavad endiselt staatilisi keskkonnamuutujaid, on pööramine habras. Liikuge dünaamilise salajase laadimise, tsentraliseeritud konfiguratsiooni või lüüsi hallatavate virtuaalsete võtmete poole. Dokumenteerige vähemalt, millist juurutust tuleb enne tühistamist muuta.

Lekkevastuse käsiraamat

Kui võti lekib, on kiirus oluline. Vastus tuleks kirjutada enne vahejuhtumit, mitte arvelduspaanikas improviseeritud.

Kohe ohjeldamine

1. Tühista või peata paljastatud võti.
2. Kui tühistamine katkestaks tootmise, väljastage esmalt asendus ja vahetage kohe kriitilise tähtsusega liiklus.
3. Kui kuritarvitamine on endiselt aktiivne, blokeerige marsruut, rentnik või pakkuja.
4. Säilitage väärkasutuse tuvastamiseks vajalikud logid.

Uurimine

1. Tuvastage, kus võti ilmus: hoidla, kasutajaliidese komplekt, mobiilirakendus, logifail, tugipilet, teenusepakkuja tööriist või vestlus.
2. Leidke viimane teadaolev seaduslik kasutus.
3. Võrdle kasutust enne ja pärast kahtlustatavat kokkupuudet.
4. Vaadake üle kasutatud mudelid, küsige mahtu, maksumust, geograafiat, kui see on saadaval, ja ebatavalisi olekukoode.
5. Kontrollige, kas sõltuvad saladused või külgnevad süsteemid võivad samuti paljastada.

Taastumine ja ennetamine

1. Pöörake sõltuvaid mandaate, kui sama keskkond võib olla lekkinud rohkem kui ühe saladuse.
2. Teavitage vajadusel omanikutiimi ja mõjutatud klientide sidusrühmi.
3. Lisage hoidlatesse ja CI torujuhtmetesse salajane skannimine.
4. Vältida kordumist, liigutades kliendipoolsed kõned taustaprogrammi või lüüsi taha.
5. Dokumenteerige juhtumite ajaskaala, algpõhjus, mõju kuludele ja juhtimistäiustused.

Prognoos: kuna meeskonnad ühendavad LLM-idega rohkem agente, pistikprogramme, automatiseerimistööriistu ja kliendispetsiifilisi töövooge, näevad võtmelekked üha enam esmalt välja kulujuhtumitena ja teiseks turvaintsidentidena. Võtmepõhise omistamise ja eelarve juhtelementidega meeskonnad lahendavad need kiiremini kui üht jagatud mandaati kasutavad meeskonnad.

Lüüsi kaudu hallatavad võtmed mitme teenusepakkuja meeskondadele

Kui teie organisatsioon kasutab mitut LLM-i pakkujat, võivad otsepakkuja võtmed luua hajutatud juhtimist: erinevad armatuurlauad, erinevad arveldusvaated, erinevad lubade mudelid ja ebajärjekindlad rotatsiooniprotsessid.

Lüüsi hallatav võtmekiht võib seda lihtsustada, väljastades rakendusele suunatud võtmed, hoides samal ajal ülesvoolu pakkuja mandaadid peidetuna. Rakendused kutsuvad OpenAIühilduva API lõpp-punkti, samas kui lüüs tegeleb marsruutimise, kasutusanalüütika, arvelduse omistamise ja eeskirjade jõustamisega.

Soovitus: kaaluge lüüsi või puhverserveri kihti, kui vajate:

• Üks koht mitme teenusepakkuja meeskonnavõtmete haldamiseks.
• Unified AI API arveldus ja võtmepõhine kuluaruanne.
• Klienditasemel virtuaalsed võtmed agentuuridele, edasimüüjatele või SaaS-i rentnikele.
• Keskmudeli lubatud loendid, marsruudireeglid ja hädaolukorra peatamine.
• Kasutuse omistamine rentniku, funktsiooni, töövoo või partnerkliendi järgi.

Trade-off: lüüs parandab juhtimist ja peidab ülesvoolu mandaadid, kuid sellest saab osa päringu teest. Jälgige seda nagu tootmistaristut: olulised on latentsusaeg, saadavus, veamäär, järjekorda seadmine, korduskatsete käitumine ja teenusepakkujapõhised tõrked.

Rakendamise kontroll-loend

• Asendage kogu organisatsiooni hõlmavad jagatud võtmed võtmetega, mille ulatus on rakenduse, keskkonna, rentniku või töövoo järgi.
• Eemaldage brauseritest, mobiilirakendustest, töölaualaienditest ja avalikest skriptidest pakkuja töötlemata võtmed.
• Marsruuteerige kliendi taotlused taustaprogrammi või AI API lüüsi kaudu.
• Lisage igale võtmele omanik, eesmärk, keskkond, lubatud mudelid, eelarve ja vaadake üle metaandmed.
• Rakendage minimaalseid õigusi: projekti, lõpp-punkti, mudeli, marsruudi, määra ja eelarve juhtelemendid, kui need on saadaval.
• Määrake võtme-, meeskonna-, rentniku- ja globaalsed kululimiidid.
• Logivõtme ID, loogiline toimija, mudel, märgikasutus, hinnanguline kulu, latentsusaeg ja olekukood.
• Looge seisakuta rotatsiooni töövoog ja testige seda enne hädaolukorda.
• Kirjutage lekkereaktsiooni käsiraamat koos ohjeldamise, uurimise ja ennetamise sammudega.
• Vaadake passiivsed võtmed üle ja tühistage kõik, mida pole omaniku või hiljuti seaduslikult kasutatud.

Tehtitav järeldus

Alustage kõrgeima riskiga võtmega: see, mida kasutatakse tootmises, mida jagavad mitu inimest, mis on manustatud liiga paljudesse kohtadesse või vastutab suurimate kulutuste eest. Andke sellele omanik, jagage see piiride kaupa, lisage eelarve, teisaldage see taustaprogrammi või lüüsi taha, kui kliendid seda näevad, ja dokumenteerige, kuidas seda pöörata.

Seejärel korrake. Tugev LLM API võtmehaldus ei ole üksainus salajase säilitamise otsus. See on elutsükkel: inventar, isolatsioon, vähimad privileegid, kasutuse omistamine, kulude juhtimine, rotatsioon ja lekkereaktsioon. Tasumine on lihtne: kui midagi läheb valesti, peaks ohus olema ainult üks rakendus, rentnik või töövoog, mitte kogu tehisintellekti eelarve.

Seotud lugemine

• Tootmise LLM API marsruutimine ja varukujundus
• earli Model Gate märkmed
• sissejuhatus Model Gate artikkel