Správa kľúčov API už nie je malá úloha na informačnom paneli. Pre tímy používajúce AI API je súčasťou bezpečnostného, ​​nákladového a operačného modelu pre každú aplikáciu, ktorá odosiela výzvy, prijíma výstup modelu, vyvoláva nástroje alebo míňa peniaze na merané odvodenie.

Mnoho tímov začína s jedným kľúčom poskytovateľa v súbore lokálneho prostredia. Funguje to dovtedy, kým sa rovnaký kľúč neobjaví v premenných CI, notebookoch, rozšíreniach IDE, agentoch, dávkových úlohách, zákazníckych integráciách a podporných skriptoch. V tomto bode nie je uniknutý kľúč len problémom s autentifikáciou. Môže odhaľovať výzvy a odpovede, spúšťať neočakávané poplatky, volať prémiové modely, spúšťať nástroje s aplikačným oprávnením alebo zabezpečiť, aby reakcia na incidenty závisela od dohadov.

Táto príručka považuje správu kľúčov API za životný cyklus: ako sa kľúče navrhujú, vydávajú, ukladajú, upravujú, monitorujú, otáčajú a odvolávajú. Zameriava sa na prístup k AI API, kde sa k bežným obavám o zabezpečenie rozhrania API pripája modelový prístup, výdavky založené na tokenoch, poverenia viacerých poskytovateľov, atribúcia zákazníkov a klienti kompatibilní s OpenAI.

Kde sa kľúče API hodia k zabezpečeniu API

Kľúč API zvyčajne dokazuje vlastníctvo poverenia. Odpovedá na otázku: „Má tento volajúci platné tajomstvo? Sám o sebe neodpovedá na každú autorizačnú otázku, na ktorej záleží.

Backend musí stále rozhodnúť, či má volajúci prístup ku konkrétnemu nájomníkovi, objektu, modelu, koncovému bodu, nástroju, pracovnému priestoru, zostave alebo administratívnej funkcii. OWASP API Security Top 10 rizík, ako je napríklad nefunkčná autorizácia na úrovni objektu, nefunkčná autentifikácia, neobmedzená spotreba zdrojov a nefunkčná autorizácia na úrovni funkcií, pripomínajú, že platné poverenia sú len jednou vrstvou systému.

V prípade AI API je toto rozlíšenie dôležité, pretože rovnaký kľúč môže vykonávať akcie s veľmi odlišnými profilmi rizík. Kľúč, ktorý dokáže volať lacný textový model pre jeden interný pracovný tok, by nemal byť schopný automaticky volať prémiové modely, vytvárať dávkové úlohy, pristupovať k údajom iného nájomcu, vyvolávať nástroje na odosielanie e-mailov alebo spravovať nastavenia fakturácie.

Trvalý model zabezpečenia rozhrania API oddeľuje tri problémy:

  • Autentifikácia: preukázanie, že požiadavka má platný token alebo c. relácia.
  • Autorizácia: rozhodovanie o tom, čo môže overený volajúci robiť v aktuálnom nájomníkovi, prostredí a obchodnom kontexte.
  • Správa: obmedzenie výdavkov, sadzby, prístup k modelu, vystavenie údajom a administratívna kontrola, takže jedna chyba má obmedzený dosah.

Kľúče s vysokou úrovňou ochrany by nemali byť užitočné alebo citlivé na ovládanie. Používajte ich s protokolom HTTPS, kontrolami autorizácie na strane servera, protokolmi auditu, najmenšími privilégiami, limitmi sadzieb, limitmi výdavkov a bezpečným spracovaním tajných informácií.

Začnite so živým inventárom kľúčov API

Nemôžete spravovať kľúče, ktoré nemôžete pomenovať. Prvým praktickým krokom je živý inventár každého kľúča API a objektu podobného povereniu, ktorý používajú vaše systémy AI.

Každý záznam kľúča by mal obsahovať minimálne ID kľúča, nereverzibilný hash alebo odtlačok prsta, vlastníka, tvorcu, tím alebo nájomníka, prostredie, pracovné zaťaženie, rozsahy, povolené modely, povolené koncové body, zásady výdavkov, pravidlá sadzieb, obmedzenia skupiny IP, kde je to možné, stav amplitúdy, čas posledného vytvorenia, čas vytvorenia, čas posledného vytvorenia, metadáta.

Inventár by mal pokrývať viac ako len produkčné kľúče. Zahrňte osobné kľúče vývojára, kľúče servisných účtov, kľúče CI/CD, kľúče pracovného priestoru, kľúče zákazníkov alebo nájomníkov, kľúče spravované predajcom, kľúče fakturácie/prehľadov, poverenia správcu API a poverenia poskytovateľa upstream.

Najdôležitejšie polia sú vlastníctvo, účel, rozsah, posledné použitie a politika limitov. Bez nich sa každá budúca bezpečnostná úloha spomalí: offboarding, rotácia, reakcia na úniky, vyšetrovanie nákladov a zákaznícka podpora.

Zámerne navrhujte hranice kľúča

Najväčšou chybou pri správe kľúčov API je použitie jedného kľúča cez príliš veľa hraníc. Zdieľaný produkčný kľúč je na začiatku pohodlný, ale ničí priradenie a spôsobuje, že zrušenie je rušivé. Ak dôjde k úniku, možno budete musieť zastaviť prevádzku pre každú službu, pričom stále nebudete vedieť identifikovať, ktoré pracovné zaťaženie spôsobilo problém.

Dobré kľúčové hranice zodpovedajú tvaru podnikania a softvéru. Oddeľte produkciu od vývoja, ľudí od služieb, zákazníkov z interných tímov, nájomníkov od seba navzájom, runtime poverenia od správcovských poverení a zákaznícke kľúče vydané bránou od kľúčov upstream poskytovateľa.

Hranice prostredia

Vývoj, príprava a produkcia by mali používať samostatné kľúče. Vývojový kľúč by nemal dosahovať výrobné údaje ani výrobné rozpočty.Postupový kľúč by nemal mať prístup k aktuálnym pracovným zaťaženiam zákazníkov, pokiaľ na to neexistuje prísne kontrolovaný dôvod.

Hranice pracovného zaťaženia

Každá služba, dávková úloha, flotila agentov, integrácia alebo naplánovaná úloha by mala mať svoj vlastný kľúč alebo účet služby. To vám umožní odpovedať na základné otázky: na aké pracovné zaťaženie sa minuli peniaze, pri ktorej službe začala zlyhávať autentifikácia, pri ktorej integrácii sa použil zastaraný model a ktorý kľúč by mal byť zmrazený počas incidentu.

Hranice nájomníkov a zákazníkov

Systémy viacerých nájomníkov potrebujú priradenie a izoláciu. Ak sa na odosielanie výziev používa kľúč API orientovaný na zákazníka, požiadavka by mala byť spojená so zákazníkom, nájomcom, aplikáciou a ideálne pseudonymným koncovým používateľom alebo aktérom. Kompromitovaný kľúč pre jedného nájomníka by nemal umožňovať prístup k údajom, profilu modelu, rozpočtu alebo denníkom iného nájomníka.

Hranice poverení poskytovateľa

Kľúče poskytovateľa upstream sa líšia od kľúčov, ktoré vydávate zákazníkom alebo interným aplikáciám. Poverenia poskytovateľa by mali zostať na strane servera, uložené v trezore alebo tajnom správcovi a nikdy by sa nemali odosielať do prehliadačov, mobilných aplikácií, desktopových klientov, verejných notebookov alebo prostredí ovládaných zákazníkmi.

Brána tu môže pomôcť odhalením jedného kľúčového povrchu pre zákazníka, pričom poverenia poskytovateľa upstream ponechá za bránou. To umožňuje centralizovať analýzu používania, zrušenie, tímové kontroly a presadzovanie pravidiel medzi poskytovateľmi. Ak štandardizujete klientov na základe rozhrania API kompatibilného s OpenAI, hranica brány sa stáva obzvlášť dôležitou, pretože mnohé nástroje očakávajú jedinú základnú adresu URL a nosný token.

Použiť najmenšie privilégiá na modely, koncové body, nástroje a výdavky

Najnižšie privilégium znamená, že kľúč by mal mať iba prístup potrebný pre jeho pracovné zaťaženie. Pre systémy AI rozsah nie je len zoznam koncových bodov API. Zahŕňa aj modely, nástroje, rozpočty tokenov, limity sadzieb, nájomníkov, dátové triedy a administratívne funkcie.

Praktická politika kľúčov rozhrania AI API môže zahŕňať:

  • Povolené rodiny modelov alebo špecifické ID modelov.
  • Povolené koncové body, ako sú dokončenia četov, vkladanie, dávkové úlohy alebo generovanie obrázkov, API, API pre správu účtov, API pre správu kľúčov a APIis. a rozhrania API na správu pracovného priestoru pre runtime kľúče.
  • Limity rýchlosti na kľúč pre požiadavky za minútu a tokeny za minútu.
  • Limity výdavkov na nájomcu, tím alebo zákazníka.
  • Prémiový model ovláda, takže pracovný tok hovorov s nízkym rizikom nemôže zrazu použiť najdrahší externý model.
  • Či už môžu byť systémy získavania kľúčov, alebo spúšťanie kódu, oprávnenia na získavanie kľúčov, môže to byť aj spustenie kľúčov. akcie.
  • Zoznamy povolených adries IP pre stabilné pracovné zaťaženia na strane servera, kde je sieťová cesta predvídateľná.

Kontrola výdavkov je súčasťou zabezpečenia API pre merané rozhrania API AI. Uniknutý kľúč môže spôsobiť priame finančné škody, aj keď sa nikdy nedostane k citlivým údajom. Sadzobné limity pomáhajú, ale nestačia. Objem tokenov, opakované pokusy, dávkové úlohy, volania nástrojov a výber modelu ovplyvňujú náklady. Bezpečná implementácia by mala kombinovať kontroly sadzieb so stropmi výdavkov, zoznamami povolených modelov, detekciou anomálií a kontrolami núdzového zmrazenia.

Tímy porovnávajúce modelové náklady a politiky prístupu by mali udržiavať bezpečnosť a financie zosúladené. Modelové oceňovanie nie je len otázkou obstarávania; určuje, koľko môže ohrozený alebo nesprávne nakonfigurovaný kľúč minúť. Schválené profily modelov majte naviazané na rozpočty a kontrolujte ich, keď sa zmení váš modelový mix, najmä ak používate cenenie modelu AI na smerovanie pracovného zaťaženia podľa nákladov a schopností.

Uchovávajte tajomstvá tam, kam patria

Kľúče API patria do tajných manažérov, konfigurácie na strane servera, kontrolovaných premenných CI/CD alebo vault-back. Nepatria do zdrojového kódu, JavaScriptu prehliadača, mobilných balíkov, balíčkov aplikácií pre stolné počítače, verejných poznámkových blokov, snímok obrazovky, četových správ, analytických údajov, lístkov podpory ani denníkov.

Odhalenie na strane klienta je bežným režimom zlyhania. Ak je kľúč poskytovateľa vložený do prehliadača alebo mobilnej aplikácie, ktokoľvek, kto môže aplikáciu skontrolovať, ho môže extrahovať a podávať žiadosti v mene majiteľa účtu. Pre prehliadače, mobilné aplikácie, flotily IDE a agentov spustených v nekontrolovaných prostrediach použite server proxy alebo krátkodobé delegované poverenia s úzkym rozsahom. Nedistribuujte dlhotrvajúce poverenia poskytovateľa klientom, ktorých nemôžete ovládať.

CI/CD si vyžadujú rovnakú disciplínu. Uložte kľúče ako chránené premenné. Obmedzte, kto ich môže čítať alebo meniť. Vyhnite sa tlači premenných prostredia v denníkoch zostavy. Upraviť hlavičky autorizácie vo výpisoch neúspešných žiadostí. S nasadeniami ukážky a rozvetvenými požiadavkami na stiahnutie zaobchádzajte ako s rôznymi zónami dôveryhodnosti z chránených produkčných kanálov.

Protokoly a systémy pozorovateľnosti si zaslúžia osobitnú pozornosť.Uchovávajte kľúčové odtlačky prstov, ID žiadostí, ID nájomníkov, ID modelov, stav odpovedí, počítadlá tokenov, počítadlá nákladov, IP alebo metadáta klienta, ak je to vhodné, a rozhodnutia o politike. Neuchovávajte úplné kľúče API. Upravte tajomstvá v trasovaní, reverzných protokoloch proxy, hláseniach o výnimkách, užitočných zaťaženiach webhooku, podporných nástrojoch, analytických udalostiach a frontoch nedoručených správ.

Vybudujte rotáciu pred núdzovým stavom

Otáčanie nie je len vymazanie jedného kľúča a vytvorenie ďalšieho. Ak nasadené služby stále závisia od starého kľúča, odstránenie spôsobí výpadok. Spoľahlivý proces rotácie využíva prekrytie, pozorovanie a jasný bod odchodu.

Bežným vzorom je skupina rotácie s dvoma aktívnymi slotmi. Vytvorte náhradný kľúč, nasaďte ho do každého závislého systému, sledujte posledné použitie starého kľúča, zmrazte starý kľúč, keď sa prevádzka presunie, a po uplynutí okna spoľahlivosti ho vymažte. Udržujte pravidlá vrátenia explicitné: kedy môže byť starý kľúč znova povolený, kto to môže schváliť a ako dlho môže zostať dostupný?

Krátke životnosti kľúča znižujú riziko zastaraných poverení, no zvyšujú prevádzkovú záťaž. Kľúče s dlhou životnosťou obmedzujú výpadky pri nasadzovaní, ale vytvárajú väčšie okno pre zabudnuté prihlasovacie údaje a medzery pri odchode zamestnancov. Správna politika závisí od pracovného zaťaženia. Účet produkčných služieb s vysokou hodnotou sa môže s automatizáciou otáčať podľa pevného plánu. Platnosť dočasného vývojárskeho kľúča by mala rýchlo vypršať. Zákazníkom spravovaná integrácia môže vyžadovať dlhšie obdobie migrácie a jasné správy o ukončení podpory.

Nerotujte všetky kľúče rovnakým spôsobom. Administratívne poverenia, ktoré môžu uvádzať, vytvárať, odstraňovať alebo upravovať kľúče, predstavujú vyššie riziko ako inferenčné kľúče za behu a mali by mať silnejšie ovládacie prvky, užší prístup a agresívnejšie monitorovanie. Runtime kľúče by nemali mať administratívnu autoritu, pokiaľ neexistuje konkrétny, preverený dôvod.

Zisťovanie únikov a abnormálneho používania

Detekcia únikov funguje najlepšie, keď sa viaceré systémy navzájom posilňujú. Tajné skenovanie ovládania zdroja môže zachytiť kľúče odovzdané do úložísk. Kontroly CI môžu pred zlúčením zablokovať zjavné netesnosti. Vlastné vzory dokážu zistiť interné formáty kľúčov. Panely poskytovateľa môžu odhaliť nezvyčajnú aktivitu. Telemetria brány môže zobraziť nové adresy IP, nové geografické oblasti, výpadky overenia, náhlu rýchlosť míňania alebo volania na neočakávané modely.

Užitočné panely zabezpečenia zahŕňajú nečinné kľúče, kľúče bez vlastníkov, kľúče bez obmedzení, kľúče, ktorých platnosť sa blíži ku koncu platnosti, kľúče používané z nových sietí, kľúče s rýchlym rastom tokenov, zamrznuté kľúče, ktoré stále prijímajú prenos, výpadky overovania a krytiep by sa mali blížiť aj stropy a protokoly zákazníkovD. asynchrónne systémy. Webhooky, úlohy na pozadí, fronty a oneskorené dokončenia vyžadujú ID žiadostí a pôvodné priradenie kľúča. V opačnom prípade môže byť podozrivé spätné volanie alebo výsledok dávky nemožné spojiť s kľúčom a nájomníkom, ktorý ho vytvoril.

Keď sa tajomstvo objaví v histórii Git, jeho odstránenie z úložiska nestačí. Každý, kto pristupoval k úložisku, protokolom zostavovania, zrkadlám, forkom, artefaktom balíčkov alebo stránkam uloženým vo vyrovnávacej pamäti, už mohol skopírovať kľúč. Poverenie musí byť zrušené alebo zmrazené a potom nahradené.

Reakcia na napadnutý kľúč API

Dobrý plán reakcie na incidenty je krátky, nacvičený a špecifický. Prvým rozhodnutím je zvyčajne to, či zmraziť alebo odvolať. Zmrazenie rýchlo zastaví premávku a zároveň uchová záznam pre vyšetrovanie. Zrušenie natrvalo deaktivuje kľúč. Niektoré tímy používajú zmrazenie ako prvé, keď potrebujú kontinuitu auditu a možnosti okamžitého návratu; ostatné sa automaticky odvolávajú pre potvrdené verejné úniky. Každý z týchto prístupov si vyžaduje automatizáciu a jasnú autoritu.

Praktický tok odozvy vyzerá takto:

  1. Zmrazte alebo odvolajte podozrivý kľúč na základe závažnosti a spoľahlivosti.
  2. Identifikujte vlastníka, nájomcu, pracovné zaťaženie, rozsahy, prístup k modelu, politiku výdavkov a naposledy použitú časovú os.
  3. Skontrolujte použitie pre nezvyčajné výzvy, objemy, nástroje, IP adresy. náklady.
  4. Posúďte ovplyvnené údaje, nájomníkov, následné akcie a vplyv fakturácie.
  5. Vydajte náhradný kľúč s opraveným rozsahom a limitmi.
  6. Odstráňte hlavnú príčinu, ako je potvrdené tajomstvo, odhalený denník, premenná CI alebo balík na strane klienta.
  7. Pridajte ovládací prvok prevencie, napríklad kratšiu kontrolu výdavkov, skenovanie tajných výdavkov, protokol vypršania platnosti. výstrahy.
  8. Zdokumentujte incident a aktualizujte runbooky.

Krok výmeny by nemal spôsobiť rovnaké riziko. Ak kľúč unikol, pretože bol zdieľaný medzi desiatimi službami, nahraďte ho samostatnými kľúčmi účtu služby. Ak unikol cez protokoly, opravte protokolovanie pred vydaním nového kľúča. Ak prečerpala, pretože by mohla vyvolať každý model, pridajte zoznamy povolených modelov a limity výdavkov.

Kľúče spravované bránou a prístup umelej inteligencie od viacerých poskytovateľov

Tímy umelej inteligencie často využívajú niekoľkých poskytovateľov modelov.Každý poskytovateľ má svoj vlastný kľúčový model, štruktúru pracovného priestoru, limity sadzieb, názvy modelov, ceny a administratívne rozhrania API. Spravovanie každého kľúča poskytovateľa priamo v každej aplikácii znásobuje prevádzkové riziko.

Model kľúčov spravovaných bránou môže túto zložitosť znížiť. Aplikácie volajú bránu pomocou zákazníckeho alebo interného kľúča. Brána overuje volajúceho, aplikuje politiku nájomníka, presadzuje riadenie modelu a výdavkov, zaznamenáva používanie a používa poverenia poskytovateľa na strane servera. Je to užitočné pre aplikácie s viacerými modelmi, interné platformy, agentúry a služby predajcov.

Pre Model Gate je to miesto, kde je rola brány relevantná: centralizované kľúče pre zákazníkov, zjednotené analýzy používania, tímové kontroly, limity výdavkov, zabezpečenie IP, prevádzkové integrácie telegramov, automatizácia rozhrania API partnera a odozva na zneužitie. Pre firmy, ktoré poskytujú zákazníkom alebo nadväzujúce služby, môže Automatizácia rozhrania Partner API zabezpečiť konzistentnosť vytvárania kľúčov, obmedzovania aktualizácií, zmrazovania a pracovných postupov predajcov namiesto manuálnych.

Brána nezbavuje aplikačný tím všetku zodpovednosť. Stále potrebujete bezpečné úložisko, autorizáciu backendu, izoláciu nájomníkov, návrh koncového bodu, hygienu CI/CD, zásady rýchlej reakcie a údajov a obmedzenia na strane poskytovateľa, ak sú k dispozícii. Brána sa stáva vysokohodnotnou riadiacou rovinou, takže potrebuje silné úložisko, protokoly auditu, riadenie prístupu, plánovanie dostupnosti a administratívne oddelenie.

Bežné chyby v správe kľúčov API

Najčastejšie chyby sú predvídateľné. Tímy vkladajú kľúče poskytovateľa priamo do klientskych aplikácií. Pre každú službu a zákazníka používajú jeden výrobný kľúč. Otáčajú sa tak, že sa najskôr vymažú a neskôr nasadia. Vytvárajú kľúče bez vlastníkov, obmedzení, rozsahov alebo vypršania platnosti. Zapisujú úplné autorizačné hlavičky. Pri kontrole nákladov na AI sa spoliehajú len na limity sadzieb. Poskytujú poverenia správcu runtime služieb. Odstránia uniknutý kľúč z Gitu bez toho, aby ho odvolali. Odchádzajú od zamestnancov, ale nechávajú aktívne osobné kľúče, súbory miestneho prostredia a premenné CI.

Ďalšou jemnou chybou je považovať protokolovanie promptných a odpovedí za čisto prevádzkové. Podrobné protokoly môžu pomôcť pri vyšetrovaní zneužitia, ale môžu obsahovať aj osobné údaje, obsah zákazníka, tajomstvá alebo regulované informácie. Protokolovanie najskôr pomocou metaúdajov je často bezpečnejšie: v predvolenom nastavení zachytávajte kľúčové odtlačky prstov, ID modelov, počty tokenov, náklady, stavové kódy, rozhodnutia o politikách a ID žiadostí, potom si vyžiadajte riadený prístup pre hlbšie údaje na ladenie.

Kontrolný zoznam implementácie

Silný program na správu kľúčov API môže začať cieleným kontrolným zoznamom:

  • Všetky kľúče, limity, vlastníci, prostredie a inventár časové pečiatky posledného použitia.
  • Oddeľte kľúče podľa prostredia, pracovného zaťaženia, nájomníka, zákazníka a triedy poverení.
  • Presuňte poverenia poskytovateľa na stranu servera a mimo prehliadačov, mobilných aplikácií, notebookov a verejných klientov.
  • Povoľte používanie najmenších privilégií pre modely, koncové body, nástroje, nájomníkov, rozpočty a funkcie správy, pridanie limitov a limitov, upozornenia na limity, upozornenia.
  • Uchovávajte tajné informácie v správcovi tajomstiev, trezore, chránenom úložisku premenných CI alebo v systéme poverení spravovanom bránou.
  • Upravte tajomstvá z protokolov, stôp, analýzy, podporných nástrojov, webhookov a hlásení o chybách.
  • Implementujte rotáciu s prekrývajúcimi sa kľúčmi, konečné monitorovanie posledného použitia, vkladanie tajných kľúčov do posledného použitia a skenovanie tajných údajov pri poslednom použití. a CI/CD, vrátane vlastných vzorov kľúčov.
  • Správanie pri vypínaní dokumentov pre osobné kľúče, účty služieb, kľúče pracovného priestoru a zákaznícke kľúče.
  • Poverenia na odvodenie za behu uchovávajte oddelene od poverení administratívneho poskytovateľa.
  • Otestujte odozvu na incident predtým, ako si proces vynúti skutočný únik.

Záver, správa kľúčov API, AI, náklady API sú tu. rádius výbuchu. Zabezpečený kľúč nie je len náhodný reťazec. Má vlastníka, účel, rozsah, prostredie, rozpočet, expiráciu, rotačnú cestu, audit trail a plán reakcie na incidenty.

Praktickým cieľom nie je vytvoriť byrokraciu okolo každej požiadavky. Ide o to, aby bola normálna práca bezpečnejšia: vývojári môžu stavať, služby môžu bežať, zákazníci môžu byť poskytovaní a bezpečnostné tímy môžu odpovedať na to, čo sa stalo, keď kľúč unikne alebo sa zvýšia výdavky. Začnite s inventárom a hranicami, potom pridajte najmenšie privilégiá, bezpečné úložisko, rotáciu, monitorovanie a automatizáciu odozvy. V prípade prístupu umelej inteligencie od viacerých poskytovateľov môže brána centralizovať veľkú časť tejto kontroly, ale autorizácia aplikácií a tajná hygiena stále zostávajú kľúčovými inžinierskymi povinnosťami.