LLM API atslēgu pārvaldība komandām: izolācija, rotācija, tēriņu ierobežojumi un noplūdes reakcija

Viena koplietota LLM API atslēga ir ērta līdz pirmajai noplūdei, neizskaidrojamam rēķinam vai ražošanas pārtraukumam. API atslēgu pārvaldības praktiskais mērķis ir ne tikai saglabāt akreditācijas datu noslēpumu. Tas ir paredzēts, lai ierobežotu sprādziena rādiusu, piešķirtu lietojumu, droši rotētu, atklātu neparastus izdevumus un atsauktu piekļuvi, nepārtraucot nesaistītas lietojumprogrammas.

Šajā rokasgrāmatā ir sniegts komandām darbības modelis LLM API atslēgām starp pakalpojumu sniedzējiem, vārtejām, iekšējām lietojumprogrammām, aģentūrām un klientiem paredzētiem produktiem. Tas atdala pārbaudītus drošības faktus no ieteicamajām ieviešanas izvēlēm un ļauj izvairīties no pieņemšanas, ka katrs pakalpojumu sniedzējs pakļauj vienas un tās pašas vadīklas.

Darbības modelis: katrai atslēgai ir nepieciešama robeža

Noderīga atslēgas stratēģija sākas ar vienu jautājumu: kas neizdosies, ja šī atslēga tiek ļaunprātīgi izmantota vai atsaukta? Ja atbilde ir “viss uzņēmums”, atslēga ir pārāk plaša.

Fakts: OpenAI API atslēgas drošības norādījumos ir ieteikts katram komandas dalībniekam izmantot unikālu API atslēgu, teikts, ka atslēgu kopīgošana ir pretrunā tās lietošanas noteikumiem, un ir ieteikts piešķirt atļaujas atsevišķām atslēgām, ja tās tiek atbalstītas. OpenAI norādījumi arī iesaka neizvietot API atslēgas klienta puses vidēs, piemēram, pārlūkprogrammās vai mobilajās lietotnēs, jo atklātās atslēgas var tikt ļaunprātīgi izmantotas, lai veiktu pieprasījumus īpašnieka vārdā.

Ieteikums: izveidojiet atslēgas ap darbības robežām, nevis ērtībām. Kopējās robežas ietver:

• Vide: ražošana, iestudēšana, izstrāde, smilškaste.
• Lietojumprogramma: tērzēšanas robota aizmugursistēma, dokumentu procesors, kodēšanas palīgs, analīzes darbplūsma.
• Īpašnieks: komanda, pakalpojuma konts, izstrādātājs, aģentūras klients, nomnieks.
• Riska līmenis: publiski pieejama darbplūsma, iekšējā automatizācija, pakešu darbs, eksperimentāla integrācija.
• Pakalpojumu sniedzējs vai maršruts: iepriekšējais pakalpojumu sniedzējs A, nodrošinātājs B, apstiprināta modeļu grupa vai vārtejas maršruts.

Labs noklusējuma risinājums augošai komandai ir: viena ražošanas atslēga katrai lietojumprogrammai vai pakalpojumam, viena ar ražošanu nesaistīta atslēga katrai videi un atsevišķas atslēgas augsta riska automatizācijai vai lietojumam klienta līmenī. Aģentūrām un tālākpārdevējiem ir jādod priekšroka klientu līmeņa virtuālajām atslēgām, nevis koplietošanas pakalpojumu sniedzēja akreditācijas datiem.

Nekad neievietojiet nodrošinātāja atslēgas izplatītajos klientos

Pārlūkprogrammas, mobilās lietotnes, darbvirsmas paplašinājumi, publiskie spraudņi un klienta puses skripti ir naidīgas vietas neapstrādātiem pakalpojumu sniedzēja akreditācijas datiem. Pat tad, ja aptumšojat atslēgu, izplatīto programmatūru var pārbaudīt, kopēt vai pārtvert.

Fakts: OpenAI skaidri brīdina neizvietot API atslēgas klienta puses vidēs. Pētījumos par mobilajām lietojumprogrammām ir ziņots arī par pastāvīgu LLM API akreditācijas datu noplūdi iOS lietotnēs, kas atbalsta to pašu praktisko brīdinājumu: izplatītajos klientos iegultie akreditācijas dati mēdz izkļūt.

Ieteikums: izmantojiet aizmugursistēmas vai vārtejas modeli:

1. Klients autentificējas jūsu lietojumprogrammā, izmantojot lietotāja sesiju, JWT, klienta pilnvaru vai īslaicīgu akreditācijas datus.
2. Jūsu aizmugursistēma apstiprina lietotāju, nomnieku, plānu un pieprasīto darbību.
3. Jūsu aizmugursistēma vai AI API vārteja izsauc augšējo LLM nodrošinātāju, izmantojot aizsargātus servera puses akreditācijas datus.
4. Atbilde tiek atgriezta klientam pēc politikas pārbaudēm, reģistrēšanas un izmaksu uzskaites.

Šis dizains ļauj ieviest produktu noteikumus pirms tēriņu parādīšanās. Piemēram, brīvā plāna lietotājs var izmantot mazākus modeļus, apmaksāts nomnieks var saņemt lielākas dienas kvotas, un iekšējā administratora darbplūsma var izmantot atsevišķu maršrutu ar stingrāku uzraudzību.

Izveidojiet galveno inventāru, pirms jums ir nepieciešama reakcija uz incidentu

Komandas bieži noplūdes laikā atklāj, ka neviens nezina, kuram pakalpojumam pieder atklātā atslēga. Tā ir krājumu kļūme.

Fakts: OWASP API drošības populārākais 10 2023. gads ietver nepareizu krājumu pārvaldību kā galveno API drošības risku. LLM infrastruktūrai galvenie krājumi ir daļa no API krājumiem: jums ir jāzina, kuri akreditācijas dati pastāv, kam tie var piekļūt un kam tie pieder.

Ieteikums: katrai atslēgai ir jābūt metadatiem. Vismaz ierakstiet:

• Atslēgas nosaukums un iekšējās atslēgas ID.
• Īpašnieku komanda un ārkārtas kontaktpersona.
• Vide: ražošana, iestudēšana, izstrāde, smilškaste.
• Mērķis: lietojumprogramma, darbplūsma, nomnieks, integrācija vai izstrādātāja izmantošana.
• Atļautie pakalpojumu sniedzēji, modeļi, galapunkti vai maršruti, ja tiek atbalstīti.
• Izveidošanas datums, pēdējoreiz izmantotais laikspiedols un plānotais pārskatīšanas datums.
• Tēriņu griesti vai kvota.
• Rotācijas statuss un saistītā izvietošanas konfigurācija.

Izmantojiet nosaukumu piešķiršanas principu, kas joprojām ir lasāms brīdinājumos. Piemēram:

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platform-lowcost-2026q3
rentant-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

Precīzs formāts ir svarīgāks par konsekvenci. Mērķis ir nodrošināt, lai brīdinājums varētu teikt: “īrnieka-acme-prod-standard pārsniedzis dienas slieksni”, un atbildīgais īpašnieks zinātu, kā rīkoties.

Pielietojiet vismazākās privilēģijas tur, kur to atļauj platforma

Ne katrs pakalpojumu sniedzējs vai vārteja piedāvā identiskas atļauju vadīklas, taču princips ir konsekvents: atslēgai ir jāspēj veikt tikai to, kas nepieciešams tās darba slodzei.

Ieteikums: ierobežojiet taustiņus, izmantojot vienu vai vairākas no tālāk norādītajām vadīklām, ja tās tiek atbalstītas.

• Projekts: saistiet atslēgas projektam, nevis visai organizācijai.
• Modelis: atļaut tikai apstiprinātus modeļus; bloķēt dārgus vai eksperimentālus modeļus pēc noklusējuma.
• Galapunkts: atļaut tērzēšanas pabeigšanu, bet aizliegt nesaistītus administratīvos galapunktus.
• Pakalpojumu sniedzēja maršruts: atļaujiet vārtejas maršrutu, nevis tiešu piekļuvi katram pakalpojuma sniedzējam.
• Likums: ierobežojiet pieprasījumu skaitu minūtē vai vienlaicīgus pieprasījumus.
• Budžets: ieviesiet tēriņu ierobežojumus katrai atslēgai, komandai vai nomniekam.

Piemēram, iestudējuma atslēgai parasti nav nepieciešama piekļuve visdārgākajam ražošanas modelim. Dokumentu klasifikācijas darbiniekam, iespējams, nav nepieciešama piekļuve attēlu ģenerēšanai. Klientam paredzēta īrnieka atslēga nedrīkst izmantot cita nomnieka budžetu.

Izstrādājiet tēriņu vadīklas slāņos

LLM API drošība un izmaksu kontrole pārklājas. Atslēgas noplūde bieži tiek noteikta kā norēķinu anomālija, pirms tā tiek noteikta kā drošības notikums.

Fakts: OpenAI konta drošības norādījumos ir ieteikti saprātīgi tēriņu ierobežojumi un ir norādīts, ka atsevišķas API atslēgas var atvieglot lietojuma apskati pēc funkcijas, komandas, produkta vai projekta. OpenAI lietojuma pārskati atbalsta arī detalizētu analīzi, izmantojot tādus laukus kā projekta ID, lietotāja ID, API atslēgas ID, modelis, pakete un pakalpojumu līmenis.

Ieteikums: izmantojiet slāņveida ierobežojumus, nevis vienu globālu ierobežojumu:

• Atslēgas ierobežojums: neļauj vienam akreditācijas datiem iztērēt visu budžetu.
• Ierobežojums vienai komandai: nodrošina, ka departamenta lietojums ir redzams un atbildīgs.
• Ierobežojums vienam nomniekam: izolē klientu lietojumu SaaS un aģentūru scenārijos.
• Ikdienas anomāliju slieksnis: aktivizē brīdinājumus, ja lietojums atšķiras no parastajiem modeļiem.
• Globāla avārijas apturēšana: ļauj ātri apturēt darbību, ja ir aktīva ļaunprātīga izmantošana.

Cietie ierobežojumi ir noderīgi, taču tie var pārtraukt likumīgus pakešu darbus. Drošāks ražošanas modelis ir šādu vadīklu secība:

1. Brīdinājums par 50 procentiem no paredzētajiem ikdienas izdevumiem.
2. Palieliniet par 80 procentiem.
3. 100 procentiem samaziniet nekritisko trafiku.
4. Pirms globālās izslēgšanas bloķējiet tikai aizskarošo atslēgu, nomnieku vai maršrutu.

Kompozīcija: stingri budžeti samazina norēķinu risku, taču var radīt pieejamības risku. Līmeņu ierobežojumi pēc darba slodzes: interaktīva ražošanas datplūsma, klientiem paredzēta maksas datplūsma, fona darbi, eksperimenti un izstrādātāju smilškastes nedrīkst neizdoties vienādi.

Izsekot lietojumam pēc atslēgas un loģiskā dalībnieka

Atslēga identificē akreditācijas datus. Tas var neidentificēt faktisko lietotāju, nomnieku, līdzekli vai darbplūsmu, kas izraisīja pieprasījumu. Lai iegūtu noderīgu AI lietojuma analīzi, reģistrējiet gan tehniskos, gan biznesa rādītājus.

Ieteikums: apkopojiet tālāk norādītos laukus katram pieprasījumam, ja to atļauj konfidencialitāte un politika.

• Pieprasīt ID un laikspiedolu.
• API atslēgas ID vai virtuālās atslēgas ID.
• Lietojumprogrammas, komandas, nomnieka, lietotāja vai darbplūsmas identifikators.
• Pakalpojumu sniedzējs, modelis, maršruts un pakalpojumu līmenis.
• Uzvednes un pabeigšanas pilnvaru skaits vai līdzvērtīgas lietošanas vienības.
• Paredzamās izmaksas.
• Latentums, statusa kods, atkārtojumu skaits un kļūdu klase.

Nepārvērtiet izmaksu novērojamību par nevajadzīgu datu apkopošanu. Izvairieties no visu uzvedņu glabāšanas pēc noklusējuma, ja tās var saturēt personas datus, klientu noslēpumus vai regulētu saturu. Daudzos gadījumos atmaksas un anomāliju noteikšanai pietiek ar jauktiem lietotāju ID, nomnieku ID, pilnvaru skaitu un modeļu nosaukumiem.

Rotācija bez dīkstāves: droša darbplūsma

Fakts: NIST atslēgu pārvaldības vadlīnijās atslēgas pārvaldība tiek uzskatīta par dzīves cikla disciplīnu, tostarp ģenerēšanu, uzglabāšanu, aktivizēšanu, rotāciju, apturēšanu, atsaukšanu un iznīcināšanu. LLM API atslēgām rotācija nav vienreizējs drošības darbs; tā ir operatīva darbplūsma.

Ieteikums: izmantojiet šo bezdīkstāves rotācijas procesu:

1. Izveidojiet nomaiņas atslēgu. Saskaņojiet nepieciešamās atļaujas, budžetu, maršrutu un metadatus. Vēl neatsauciet veco atslēgu.
2. Saglabājiet to slepenajā pārvaldniekā. Izvairieties no vietējiem failiem, tērzēšanas ziņojumiem, biļetēm un ielīmētiem vides mainīgajiem.
3. Izvietot konfigurāciju pakāpeniski. Vienlaicīgi atjauniniet vienu pakalpojumu, reģionu, darbinieku grupu vai nomnieka segmentu.
4. Pārbaudiet satiksmes kustību. Apstipriniet, ka pieprasījumi tiek saņemti ar jauno atslēgu un ka kļūdu līmenis un latentums paliek normāli.
5. Iesaldēt rakstīšanu uz veco atslēgu. Pārtrauciet to atsaukšanu jaunajos izvietojumos.
6. Atsauciet veco atslēgu. Kad satiksme ir pārvietota, atspējojiet to, nevis atstājiet to kā aizmirstu atslēgu.
7. Pārbaudīt kļūdīties. Meklējiet vecās atslēgas ID žurnālos, izvietošanas manifestos, slepenajos krātuvēs, CI mainīgajos un izpildlaika kļūdas.

Lietojumprogrammām, kurās joprojām tiek izmantoti statiski vides mainīgie, rotācija būs trausla. Pārejiet uz dinamisku slepeno ielādi, centralizētu konfigurāciju vai vārtejas pārvaldītām virtuālajām atslēgām. Pirms atsaukšanas dokumentējiet vismaz, kura izvietošana ir jāmaina.

Noplūdes atbildes rokasgrāmata

Kad atslēga noplūst, ātrums ir svarīgs. Atbilde jāraksta pirms incidenta, nevis jāimprovizē rēķinu panikā.

Tūlītēja ierobežošana

1. Atsauciet vai apturiet atklāto atslēgu.
2. Ja atsaukšana pārtrauktu ražošanu, vispirms izdodiet nomaiņu un nekavējoties pārslēdziet kritisko trafiku.
3. Ja ļaunprātīga izmantošana joprojām ir aktīva, bloķējiet maršrutu, nomnieku vai pakalpojumu sniedzēju.
4. Saglabājiet žurnālus, kas nepieciešami, lai identificētu ļaunprātīgu izmantošanu.

Izmeklēšana

1. Nosakiet, kur tika parādīta atslēga: krātuve, priekšgala komplekts, mobilā lietotne, žurnālfails, atbalsta biļete, piegādātāja rīks vai tērzēšana.
2. Atrodiet pēdējo zināmo likumīgo lietojumu.
3. Salīdziniet lietojumu pirms un pēc iespējamās iedarbības.
4. Pārskatiet izmantotos modeļus, pieprasiet apjomu, izmaksas, ģeogrāfisko atrašanās vietu, ja iespējams, un neparastus statusa kodus.
5. Pārbaudiet, vai var tikt atklāti arī atkarīgi noslēpumi vai blakus esošās sistēmas.

Atveseļošanās un profilakse

1. Pagrieziet atkarīgos akreditācijas datus, ja viena un tā pati vide ir nopludinājusi vairāk nekā vienu noslēpumu.
2. Attiecīgā gadījumā paziņojiet īpašnieku komandai un ietekmētajām klientu ieinteresētajām personām.
3. Pievienojiet krātuvēm un CI konveijeriem slepeno skenēšanu.
4. Novērsiet atkārtošanos, pārvietojot klienta puses zvanus aiz aizmugursistēmas vai vārtejas.
5. Dokumentējiet incidenta laika grafiku, galveno cēloni, izmaksu ietekmi un kontroles uzlabojumus.

Paredzēšana: tā kā komandas savieno vairāk aģentu, spraudņu, automatizācijas rīku un klientam specifiskas darbplūsmas ar LLM, galvenās noplūdes arvien vairāk izskatīsies kā izmaksu incidenti, pirmkārt, un drošības incidenti. Komandas ar katras atslēgas attiecinājumu un budžeta vadīklām tos atrisinās ātrāk nekā komandas, kas izmanto vienu koplietotu akreditācijas datus.

Vārtejas pārvaldītas atslēgas vairāku pakalpojumu sniedzēju komandām

Ja jūsu organizācija izmanto vairākus LLM pakalpojumu sniedzējus, tiešās nodrošinātāja atslēgas var radīt izkliedētu pārvaldību: dažādus informācijas paneļus, dažādus norēķinu skatus, dažādus atļauju modeļus un nekonsekventus rotācijas procesus.

Vārtejas pārvaldīts atslēgas slānis var to vienkāršot, izdodot lietojumprogrammai vērstas atslēgas, vienlaikus paslēpjot augšējo pakalpojumu sniedzēja akreditācijas datus. Lietojumprogrammas izsauc ar OpenAI saderīgu API galapunktu, savukārt vārteja apstrādā maršrutēšanu, lietojuma analīzi, norēķinu attiecinājumu un politikas ieviešanu.

Ieteikums: apsveriet vārtejas vai starpniekservera slāni, kad nepieciešams:

• Viena vieta, kur pārvaldīt komandas atslēgas no vairākiem pakalpojumu sniedzējiem.
• Vienotie AI API norēķini un tēriņu pārskati par katru atslēgu.
• Klienta līmeņa virtuālās atslēgas aģentūrām, tālākpārdevējiem vai SaaS nomniekiem.
• Centrālie modeļu atļauju saraksti, maršruta politikas un ārkārtas apturēšana.
• Lietošanas attiecinājums pēc nomnieka, līdzekļa, darbplūsmas vai partnera klienta.

Kompozīcija: vārteja uzlabo pārvaldību un slēpj iepriekšējās akreditācijas datus, taču tā kļūst par daļu no pieprasījuma ceļa. Pārraugiet to tāpat kā ražošanas infrastruktūru: svarīgs ir latentums, pieejamība, kļūdu līmenis, rindas, atkārtota mēģinājuma darbība un pakalpojumu sniedzēja kļūmes.

Ieviešanas kontrolsaraksts

• Aizstāt visas organizācijas koplietojamās atslēgas ar atslēgām, kuru darbības joma ir atkarīga no lietotnes, vides, nomnieka vai darbplūsmas.
• Noņemiet neapstrādātas nodrošinātāja atslēgas no pārlūkprogrammām, mobilajām lietotnēm, darbvirsmas paplašinājumiem un publiskiem skriptiem.
• Novirziet klientu pieprasījumus, izmantojot aizmugursistēmu vai AI API vārteju.
• Katrai atslēgai pievienojiet īpašnieku, mērķi, vidi, atļautos modeļus, budžetu un pārskatiet metadatus.
• Piemērot vismazākās privilēģijas: projekta, galapunkta, modeļa, maršruta, tarifa un budžeta vadīklas, kur pieejamas.
• Iestatiet katras atslēgas, katras komandas, nomnieka un globālos tēriņu ierobežojumus.
• Žurnāla atslēgas ID, loģiskais dalībnieks, modelis, marķiera lietojums, aptuvenās izmaksas, latentums un statusa kods.
• Izveidojiet bezdīkstāves rotācijas darbplūsmu un pārbaudiet to pirms ārkārtas situācijas.
• Uzrakstiet noplūžu reaģēšanas rokasgrāmatu ar ierobežošanas, izmeklēšanas un novēršanas darbībām.
• Pārskatiet neaktīvās atslēgas un atsauciet visu, kas nav īpašnieka vai nesen likumīgi izmantots.

Lietojams secinājums

Sāciet ar visaugstākā riska atslēgu: to, kas tiek izmantota ražošanā, kuru koplieto vairākas personas, kas ir iegulta pārāk daudzās vietās vai ir atbildīga par vislielākajiem tēriņiem. Piešķiriet tam īpašnieku, sadaliet to pēc robežām, pievienojiet budžetu, pārvietojiet to aiz aizmugursistēmas vai vārtejas, ja klienti to var redzēt, un dokumentējiet, kā to pagriezt.

Pēc tam atkārtojiet. Spēcīga LLM API atslēgu pārvaldība nav viens lēmums par slepenu glabāšanu. Tas ir dzīves cikls: krājumi, izolācija, vismazākās privilēģijas, lietojuma attiecinājums, izmaksu kontrole, rotācija un reakcija uz noplūdi. Izmaksa ir vienkārša: ja kaut kas noiet greizi, riskam vajadzētu būt tikai vienai lietojumprogrammai, nomniekam vai darbplūsmai — nevis visam AI budžetam.

Saistīta informācija

• iepriekšējās Model Gate emuāra piezīmes
• ievadraksts Model Gate