Správa kľúčov LLM API pre tímy: izolácia, rotácia, limity výdavkov a odozva na úniky

Jeden zdieľaný kľúč LLM API je vhodný až do prvého úniku, nevysvetleného účtu alebo výpadku výroby. Praktickým cieľom správy kľúčov API nie je len uchovanie tajných poverení. Ide o obmedzenie polomeru výbuchu, používanie atribútov, bezpečné otáčanie, detekciu abnormálnych výdavkov a zrušenie prístupu bez prerušenia nesúvisiacich aplikácií.

Táto príručka poskytuje tímom operačný model pre kľúče API LLM naprieč poskytovateľmi, bránami, internými aplikáciami, agentúrami a produktmi pre zákazníkov. Oddeľuje overené bezpečnostné fakty od odporúčaných možností implementácie a vyhýba sa predpokladu, že každý poskytovateľ poskytuje rovnaké ovládacie prvky.

Prevádzkový model: každý kľúč potrebuje hranicu

Užitočná kľúčová stratégia začína jednou otázkou: čo by malo zlyhať, ak je tento kľúč zneužitý alebo zrušený? Ak je odpoveď „celá spoločnosť“, kľúč je príliš široký.

Fakt: Bezpečnostné pokyny pre kľúče API OpenAI odporúčajú, aby každý člen tímu používal jedinečný kľúč API, hovorí, že zdieľanie kľúčov je v rozpore s jeho Zmluvnými podmienkami, a odporúča prideľovať povolenia jednotlivým kľúčom, ak sú podporované. Pokyny OpenAI tiež neodporúčajú nasadzovať kľúče API v prostrediach na strane klienta, ako sú prehliadače alebo mobilné aplikácie, pretože odhalené kľúče môžu byť zneužité na odosielanie žiadostí v mene vlastníka.

Odporúčanie: vytvorte kľúče okolo prevádzkových hraníc, nie okolo pohodlia. Bežné hranice zahŕňajú:

• Prostredie: výroba, inscenácia, vývoj, pieskovisko.
• Aplikácia: backend chatbota, procesor dokumentov, asistent kódovania, analytický pracovný postup.
• Vlastník: tím, servisný účet, vývojár, klient agentúry, nájomník.
• Úroveň rizika: verejne prístupný pracovný postup, interná automatizácia, dávková úloha, experimentálna integrácia.
• Poskytovateľ alebo trasa: upstream poskytovateľ A, poskytovateľ B, schválená modelová skupina alebo trasa brány.

Dobrým predvoleným nastavením pre rastúci tím je: jeden produkčný kľúč na aplikáciu alebo službu, jeden neprodukčný kľúč na prostredie a samostatné kľúče pre vysokorizikovú automatizáciu alebo použitie na úrovni zákazníka. Agentúry a predajcovia by mali uprednostňovať virtuálne kľúče na úrovni zákazníka pred zdieľaním poverení poskytovateľa.

Nikdy nevkladajte kľúče poskytovateľa do distribuovaných klientov

Prehliadače, mobilné aplikácie, rozšírenia pre počítače, verejné doplnky a skripty na strane zákazníka predstavujú nepriateľské miesta pre nespracované poverenia poskytovateľa. Aj keď kľúč zahmlievate, distribuovaný softvér možno skontrolovať, skopírovať alebo zachytiť.

Fakt: OpenAI výslovne varuje pred nasadením kľúčov API v prostrediach na strane klienta. Výskum mobilných aplikácií tiež hlásil pretrvávajúci únik poverení LLM API v aplikáciách pre iOS, čo podporuje rovnaké praktické varovanie: poverenia vložené do distribuovaných klientov majú tendenciu unikať.

Odporúčanie: použite vzor backendu alebo brány:

1. Klient sa autentifikuje vo vašej aplikácii pomocou používateľskej relácie, JWT, zákazníckeho tokenu alebo krátkodobých poverení.
2. Váš backend overí používateľa, nájomníka, plán a požadovanú operáciu.
3. Váš backend alebo brána AI API volá poskytovateľa LLM upstream pomocou chránených poverení na strane servera.
4. Odpoveď sa vráti klientovi po kontrole pravidiel, protokolovaní a účtovaní nákladov.

Tento dizajn vám umožňuje presadzovať pravidlá produktu skôr, ako dôjde k míňaniu. Používateľ s bezplatným plánom môže byť napríklad obmedzený na menšie modely, platený nájomca môže získať vyššie denné kvóty a interný pracovný postup správcu môže používať samostatnú trasu s prísnejším monitorovaním.

Vytvorte si kľúčový inventár skôr, ako budete potrebovať reakciu na incident

Tímy počas úniku často zistia, že nikto nevie, ktorá služba vlastní odhalený kľúč. Ide o zlyhanie zásob.

Fakt: OWASP API Top 10 Security 2023 zahŕňa nesprávne riadenie zásob ako hlavné bezpečnostné riziko API. V prípade infraštruktúry LLM je kľúčový inventár súčasťou inventára API: musíte vedieť, ktoré poverenia existujú, k čomu majú prístup a kto ich vlastní.

Odporúčanie: každý kľúč by mal mať metadáta. Minimálne sledujte:

• Názov kľúča a interné ID kľúča.
• Tím vlastníka a núdzový kontakt.
• Prostredie: produkcia, inscenácia, vývoj, pieskovisko.
• Účel: použitie aplikácie, pracovného postupu, nájomníka, integrácie alebo vývojára.
• Povolení poskytovatelia, modely, koncové body alebo trasy, ak sú podporované.
• Dátum vytvorenia, časová pečiatka posledného použitia a plánovaný dátum kontroly.
• Strop alebo kvóta výdavkov.
• Stav rotácie a konfigurácia prepojeného nasadenia.

Použite konvenciu pomenovania, ktorá zostane čitateľná vo výstrahách. Napríklad:

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

Na presnom formáte záleží menej ako na konzistencii. Cieľom je, aby výstraha mohla povedať „štandard nájomníka-acme-prod prekročil svoj denný prah“ a zodpovedný vlastník vedel, čo má robiť.

Použiť najmenšie privilégiá tam, kde to platforma umožňuje

Nie každý poskytovateľ alebo brána poskytuje rovnaké ovládacie prvky povolení, ale princíp je konzistentný: kľúč by mal byť schopný vykonávať len to, čo jeho pracovné zaťaženie potrebuje.

Odporúčanie: obmedziť klávesy jedným alebo viacerými z nasledujúcich ovládacích prvkov, ak sú podporované:

• Projekt: viaže kľúče na projekt a nie na celú organizáciu.
• Model: povoliť iba schválené modely; predvolene blokovať drahé alebo experimentálne modely.
• Koncový bod: povoliť dokončenie rozhovoru, ale zakázať nesúvisiace koncové body správy.
• Trasa poskytovateľa: povoľte smerovanie cez bránu namiesto priameho prístupu ku každému upstream poskytovateľovi.
• Sadzba: obmedzenie počtu žiadostí za minútu alebo súbežných žiadostí.
• Rozpočet: presadzujte limity výdavkov na kľúč, tím alebo nájomcu.

Napríklad produkčný kľúč zvyčajne nepotrebuje prístup k najdrahšiemu produkčnému modelu. Pracovník na klasifikáciu dokumentov pravdepodobne nepotrebuje prístup ku generovaniu obrázkov. Kľúč nájomníka orientovaný na zákazníka by nemal byť schopný spotrebovať rozpočet iného nájomníka.

Navrhnite ovládacie prvky výdavkov vo vrstvách

Zabezpečenie rozhrania LLM API a kontrola nákladov sa prekrývajú. Uniknutý kľúč je často zistený ako anomália fakturácie skôr, ako je zistený ako bezpečnostná udalosť.

Fakt: Bezpečnostné pokyny pre účet OpenAI odporúčajú primerané limity výdavkov a poznamenávajú, že samostatné kľúče API môžu uľahčiť zobrazenie používania podľa funkcie, tímu, produktu alebo projektu. Prehľady používania OpenAI tiež podporujú podrobnú analýzu prostredníctvom polí, ako je ID projektu, ID používateľa, ID kľúča API, model, dávka a úroveň služieb.

Odporúčanie: namiesto jedného globálneho limitu použite viacvrstvové limity:

• Limit na kľúč: bráni jednému povereniu odčerpať celý rozpočet.
• Limit na tím: udržiava využitie oddelenia viditeľné a zodpovedné.
• Limit na nájomníka: izoluje používanie zákazníkov v rámci SaaS a scenárov agentúr.
• Denný prah anomálií: spúšťa upozornenia, keď sa používanie odchyľuje od bežných vzorov.
• Globálne núdzové zastavenie: umožňuje rýchle pozastavenie, keď je aktívne zneužívanie.

Tvrdé limity sú užitočné, ale môžu prerušiť legitímne dávkové úlohy. Bezpečnejší spôsob výroby je postupnosť kontrol:

1. Upozornenie na 50 percent očakávaných denných výdavkov.
2. Eskalujte o 80 percent.
3. Znížte nekritickú návštevnosť na 100 percent.
4. Pred použitím globálneho vypnutia zablokujte iba problematický kľúč, nájomníka alebo trasu.

Výmena: prísne rozpočty znižujú riziko fakturácie, ale môžu vytvárať riziko dostupnosti. Obmedzenia úrovní podľa pracovného zaťaženia: interaktívna produkčná návštevnosť, platená návštevnosť zo strany zákazníkov, úlohy na pozadí, experimenty a izolované priestory pre vývojárov by nemali zlyhať rovnako.

Sledovanie používania podľa kľúča a logického aktéra

Kľúč identifikuje poverenia. Nemusí identifikovať skutočného používateľa, nájomníka, funkciu alebo pracovný postup, ktorý spôsobil požiadavku. Ak chcete získať užitočnú analýzu používania AI, zapíšte si technické aj obchodné dimenzie.

Odporúčanie: zhromaždite nasledujúce polia pre každú žiadosť tam, kde to povoľuje ochrana osobných údajov a pravidlá:

• ID žiadosti a časovú pečiatku.
• ID kľúča API alebo ID virtuálneho kľúča.
• Identifikátor aplikácie, tímu, nájomníka, používateľa alebo pracovného postupu.
• Poskytovateľ, model, trasa a úroveň služieb.
• Počet tokenov výzvy a dokončenia alebo ekvivalentné jednotky použitia.
• Odhadované náklady.
• Latencia, stavový kód, počet opakovaní a trieda chýb.

Nepremieňajte pozorovateľnosť nákladov na zbytočné zhromažďovanie údajov. Predvolene neukladajte úplné výzvy, ak môžu obsahovať osobné údaje, tajomstvá zákazníkov alebo regulovaný obsah. V mnohých prípadoch na kompenzáciu a detekciu anomálií stačia hašované ID používateľov, ID nájomníkov, počty tokenov a názvy modelov.

Otáčanie bez prestojov: bezpečný pracovný postup

Fakt: Usmernenia pre správu kľúčov NIST považujú správu kľúčov za disciplínu životného cyklu vrátane generovania, ukladania, aktivácie, rotácie, pozastavenia, zrušenia a zničenia. Pre kľúče LLM API nie je rotácia jednorazovou bezpečnostnou úlohou; ide o prevádzkový pracovný postup.

Odporúčanie: použite tento proces rotácie bez prestojov:

1. Vytvorte náhradný kľúč. Priraďte požadované povolenia, rozpočet, trasu a metadáta. Starý kľúč zatiaľ neodvolávajte.
2. Uložte ho v správcovi tajomstiev. Vyhnite sa miestnym súborom, četovým správam, lístkom a prilepeným premenným prostredia.
3. Konfiguráciu nasadzujte postupne. Aktualizujte vždy jednu službu, región, skupinu pracovníkov alebo segment nájomníkov.
4. Overte pohyb návštevnosti. Potvrďte, že požiadavky prichádzajú pod novým kľúčom a že chybovosť a latencia zostávajú normálne.
5. Zmraziť zápisy na starý kľúč. Zabrániť novým nasadeniam, aby naň odkazovali.
6. Odvolajte starý kľúč. Po presunutí ho radšej deaktivujte, než aby ste ho nechali ako zabudnutý záložný kľúč.
7. Audit nevoľníkov. Vyhľadávajte v denníkoch, manifestoch nasadenia, tajných skladoch, premenných CI a chybách spustenia pre staré ID kľúča.

V prípade aplikácií, ktoré stále používajú statické premenné prostredia, bude rotácia krehká. Prejdite k dynamickému načítaniu tajných údajov, centralizovanej konfigurácii alebo virtuálnym kľúčom spravovaným bránou. Minimálne zdokumentujte, ktoré nasadenie sa musí pred zrušením zmeniť.

Runbook odozvy na únik

Keď kľúč unikne, na rýchlosti záleží. Odpoveď by mala byť napísaná pred incidentom, nie improvizovaná v panike z účtovania.

Okamžité obmedzenie

1. Odvolajte alebo pozastavte odhalený kľúč.
2. Ak by zrušenie prerušilo produkciu, najskôr vydajte náhradu a okamžite prepnite kritickú prevádzku.
3. Ak je zneužívanie stále aktívne, zablokujte trasu, nájomníka alebo poskytovateľa.
4. Uchovajte protokoly potrebné na identifikáciu zneužitia.

Vyšetrovanie

1. Identifikujte, kde sa kľúč objavil: úložisko, balík frontendu, mobilná aplikácia, súbor denníka, lístok podpory, nástroj dodávateľa alebo čet.
2. Nájdite posledné známe legitímne použitie.
3. Porovnajte použitie pred a po podozrivej expozícii.
4. Skontrolujte použité modely, objem žiadostí, cenu, geografickú polohu, ak je k dispozícii, a neobvyklé stavové kódy.
5. Skontrolujte, či môžu byť odhalené aj závislé tajomstvá alebo susedné systémy.

Obnova a prevencia

1. Otočte závislé poverenia, ak z toho istého prostredia mohlo uniknúť viac ako jedno tajomstvo.
2. V prípade potreby upovedomte tím vlastníkov a dotknuté zainteresované strany zákazníkov.
3. Pridajte tajné skenovanie do úložísk a kanálov CI.
4. Zabráňte opakovaniu presunutím hovorov na strane klienta za backend alebo bránu.
5. Zdokumentujte časovú os incidentu, hlavnú príčinu, vplyv na náklady a vylepšenia kontroly.

Predpoveď: keďže tímy pripájajú viac agentov, doplnkov, automatizačných nástrojov a pracovných postupov špecifických pre zákazníka k LLM, kľúčové úniky budú v prvom rade vyzerať ako cenové incidenty a ako druhé bezpečnostné incidenty. Tímy s pripisovaním podľa kľúča a kontrolami rozpočtu ich vyriešia rýchlejšie ako tímy používajúce jedno zdieľané poverenie.

Kľúče spravované bránou pre tímy s viacerými poskytovateľmi

Ak vaša organizácia využíva viacerých poskytovateľov LLM, priame kľúče poskytovateľov môžu vytvoriť rozptýlené riadenie: rôzne informačné panely, rôzne zobrazenia fakturácie, rôzne modely povolení a nekonzistentné procesy rotácie.

Vrstva kľúčov spravovaných bránou to môže zjednodušiť vydávaním kľúčov pre aplikácie, pričom prihlasovacie údaje poskytovateľa sú skryté. Aplikácie volajú koncový bod API kompatibilný s OpenAI, zatiaľ čo brána sa stará o smerovanie, analýzu používania, pripisovanie fakturácie a presadzovanie pravidiel.

Odporúčanie: zvážte vrstvu brány alebo proxy, keď potrebujete:

• Jedno miesto na správu tímových kľúčov u viacerých poskytovateľov.
• Zjednotená fakturácia AI API a prehľady výdavkov podľa kľúča.
• Virtuálne kľúče na úrovni zákazníka pre agentúry, predajcov alebo nájomníkov SaaS.
• Zoznamy povolení centrálneho modelu, pravidlá trás a núdzové pozastavenie.
• Použitie priradenia podľa nájomníka, funkcie, pracovného postupu alebo partnerského zákazníka.

Trade-off: brána zlepšuje riadenie a skryje prihlasovacie údaje, ale stáva sa súčasťou cesty žiadosti. Monitorujte to ako produkčnú infraštruktúru: záleží na latencii, dostupnosti, chybovosti, radení, opakovaní pokusov a zlyhaniach špecifických pre poskytovateľa.

Kontrolný zoznam implementácie

• Nahraďte zdieľané kľúče pre celú organizáciu kľúčmi s rozsahom podľa aplikácie, prostredia, nájomníka alebo pracovného postupu.
• Odstráňte nespracované kľúče poskytovateľa z prehliadačov, mobilných aplikácií, rozšírení pre počítače a verejných skriptov.
• Smerujte požiadavky klientov cez backend alebo bránu AI API.
• Ku každému kľúču pripojte vlastníka, účel, prostredie, povolené modely, rozpočet a metadáta kontroly.
• Použite minimálne privilégiá: projekt, koncový bod, model, trasa, sadzba a ovládacie prvky rozpočtu, ak sú k dispozícii.
• Nastavte limity výdavkov na kľúč, tím, nájomníka a globálne výdavky.
• ID kľúča denníka, logický aktér, model, využitie tokenu, odhadované náklady, latencia a stavový kód.
• Vytvorte pracovný postup rotácie bez prestojov a otestujte ho pred núdzovým prípadom.
• Napíšte príručku odozvy na úniky s krokmi na obmedzenie, vyšetrovanie a prevenciu.
• Skontrolujte neaktívne kľúče a odvolajte čokoľvek bez vlastníka alebo nedávneho legitímneho použitia.

Uplatniteľný záver

Začnite s kľúčom s najvyšším rizikom: kľúčom používaným vo výrobe, zdieľaným viacerými ľuďmi, vloženým na príliš veľa miestach alebo zodpovedným za najväčšie výdavky. Dajte mu vlastníka, rozdeľte ho podľa hraníc, pridajte rozpočet, presuňte ho za backend alebo bránu, ak ho klienti uvidia, a zdokumentujte, ako ho otočiť.

Potom to zopakujte. Silná správa kľúčov LLM API nie je jediným rozhodnutím o tajnom ukladaní. Je to životný cyklus: inventár, izolácia, najmenšie privilégium, pripisovanie použitia, kontrola nákladov, rotácia a reakcia na únik. Odmena je jednoduchá: keď sa niečo pokazí, mala by byť ohrozená iba jedna aplikácia, nájomca alebo pracovný postup – nie celý rozpočet na AI.

Súvisiace čítanie

• >. href="https://model-gate.com/en/blog/article-2-2/">staršie poznámky k blogu Model Gate
• úvodný článok Model Gate