LLM API kulcskezelés csapatok számára: elkülönítés, rotáció, ráfordítási korlátok és szivárgásra adott válasz

Egy megosztott LLM API-kulcs az első szivárgásig, megmagyarázhatatlan számlaig vagy termeléskimaradásig kényelmes. Az API-kulcskezelés gyakorlati célja nem csupán a hitelesítő adatok titkának megőrzése. A cél a robbanás sugarának korlátozása, a használat attribútumainak meghatározása, a biztonságos forgatás, a rendellenes költések észlelése és a hozzáférés visszavonása anélkül, hogy a nem kapcsolódó alkalmazásokat megzavarná.

Ez az útmutató működési modellt ad a csapatoknak az LLM API-kulcsokhoz a szolgáltatók, átjárók, belső alkalmazások, ügynökségek és az ügyfeleknek szánt termékek között. Elválasztja az ellenőrzött biztonsági tényeket a javasolt megvalósítási lehetőségektől, és elkerüli annak feltételezését, hogy minden szolgáltató ugyanazokat a vezérlőket tegye ki.

A működési modell: minden kulcsnak szüksége van egy határra

Egy hasznos kulcsstratégia egy kérdéssel kezdődik: mi hibásodik meg, ha a kulccsal visszaélnek vagy visszavonják? Ha a válasz „az egész vállalat”, a kulcs túl tág.

Tény: Az OpenAI API-kulcsok biztonsági útmutatása azt javasolja, hogy minden csapattag egyedi API-kulcsot használjon, és azt mondja, hogy a kulcsok megosztása ellentétes a felhasználási feltételekkel, és azt javasolja, hogy az egyes kulcsokhoz rendeljenek engedélyeket, ha ez támogatott. Az OpenAI útmutatása azt is javasolja, hogy ne helyezzen be API-kulcsokat ügyféloldali környezetekben, például böngészőkben vagy mobilalkalmazásokban, mert a nyilvánosságra hozott kulcsokkal visszaélhetnek a tulajdonos nevében.

Javaslat: hozzon létre kulcsokat a működési határok körül, ne a kényelem körül. A közös határok a következők:

• Környezet: gyártás, színpadra állítás, fejlesztés, homokozó.
• Alkalmazás: chatbot háttérrendszer, dokumentumfeldolgozó, kódolási asszisztens, elemzési munkafolyamat.
• Tulajdonos: csapat, szolgáltatási fiók, fejlesztő, ügynökségi ügyfél, bérlő.
• Kockázati szint: nyilvános munkafolyamat, belső automatizálás, kötegelt munka, kísérleti integráció.
• Szolgáltató vagy útvonal: „A” szolgáltató, „B” szolgáltató, jóváhagyott modellcsoport vagy átjáróútvonal.

A növekvő csapat jó alapértelmezése: alkalmazásonként vagy szolgáltatásonként egy gyártási kulcs, környezetenként egy nem gyártási kulcs, valamint külön kulcsok a magas kockázatú automatizáláshoz vagy ügyfélszintű használathoz. Az ügynökségeknek és a viszonteladóknak előnyben kell részesíteniük az ügyfélszintű virtuális kulcsokat az upstream szolgáltatói hitelesítő adatok megosztása helyett.

Soha ne helyezzen el szolgáltatói kulcsokat az elosztott kliensekbe

A böngészők, a mobilalkalmazások, az asztali bővítmények, a nyilvános beépülő modulok és az ügyféloldali szkriptek ellenséges helyek a nyers szolgáltatói hitelesítő adatok számára. Még akkor is, ha elhomályosítja a kulcsot, a megosztott szoftverek ellenőrizhetők, másolhatók vagy lehallgathatók.

Tény: Az OpenAI kifejezetten figyelmeztet, hogy ne helyezzen üzembe API-kulcsokat ügyféloldali környezetekben. A mobilalkalmazásokkal kapcsolatos kutatások arról is beszámoltak, hogy az iOS-alkalmazásokban folyamatosan szivárognak az LLM API hitelesítő adatok, ami ugyanazt a gyakorlati figyelmeztetést támasztja alá: az elosztott kliensekbe beágyazott hitelesítő adatok hajlamosak megszökni.

Javaslat: használjon háttér- vagy átjárómintát:

1. A kliens felhasználói munkamenet, JWT, ügyféltoken vagy rövid élettartamú hitelesítő adatok segítségével hitelesíti az alkalmazást.
2. A háttérrendszer ellenőrzi a felhasználót, a bérlőt, a tervet és a kért műveletet.
3. Az Ön háttérrendszere vagy AI API-átjárója védett szerveroldali hitelesítési adatok használatával hívja a upstream LLM-szolgáltatót.
4. A választ a szabályzat ellenőrzése, a naplózás és a költségelszámolás után visszaküldjük az ügyfélnek.

Ez a kialakítás lehetővé teszi a termékszabályok betartatását, mielőtt a költés megtörténne. Például egy szabad csomagot használó felhasználó kisebb modellekre korlátozható, a fizető bérlő magasabb napi kvótát kaphat, a belső adminisztrátori munkafolyamat pedig külön útvonalat használhat szigorúbb felügyelet mellett.

Hozzon létre egy kulcsleltárt, mielőtt az incidensre reagálnia kellene

A csapatok gyakran felfedezik a kiszivárogtatás során, hogy senki sem tudja, melyik szolgáltatás birtokolja a nyilvánosságra hozott kulcsot. Ez készlethiba.

Tény: Az OWASP API Security Top 10 2023-ban a helytelen készletkezelés az egyik fő API biztonsági kockázat. Az LLM-infrastruktúra esetében a kulcskészlet az API-készlet része: tudnia kell, hogy mely hitelesítő adatok léteznek, mihez férhetnek hozzá, és ki a tulajdonosa.

Javaslat: minden kulcsnak tartalmaznia kell metaadatokat. Legalább pálya:

• A kulcs neve és a belső kulcsazonosító.
• A tulajdonos csapata és a sürgősségi kapcsolattartó.
• Környezet: gyártás, bemutató, fejlesztés, homokozó.
• Cél: alkalmazás, munkafolyamat, bérlő, integráció vagy fejlesztői használat.
• Engedélyezett szolgáltatók, modellek, végpontok vagy útvonalak, ahol támogatottak.
• Létrehozás dátuma, utoljára használt időbélyeg és tervezett felülvizsgálati dátum.
• Költési felső határ vagy kvóta.
• A forgatás állapota és a kapcsolt telepítési konfiguráció.

Használjon olyan elnevezési konvenciót, amely olvasható marad a figyelmeztetésekben. Például:

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platform-lowcost-2026q3
bérlő-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

A pontos formátum kevésbé számít, mint a következetesség. A cél az, hogy a riasztás azt mondja, hogy „a bérlő-acme-prod-standard túllépte a napi küszöbértéket”, és a felelős tulajdonos tudja, mit kell tennie.

A legkisebb jogosultság alkalmazása ott, ahol a platform ezt lehetővé teszi

Nem minden szolgáltató vagy átjáró teszi ki az azonos engedélyeket, de az elv következetes: egy kulcsnak csak azt kell tudnia elvégezni, amire a munkaterhelése szüksége van.

Javaslat: korlátozza a kulcsokat a következő vezérlők közül egy vagy több segítségével, ha támogatott:

• Projekt: a kulcsokat egy projekthez köti, nem pedig egy egész szervezethez.
• Modell: csak jóváhagyott modellek engedélyezése; alapértelmezés szerint blokkolja a drága vagy kísérleti modelleket.
• Végpont: engedélyezi a csevegés befejezését, de letiltja a nem kapcsolódó adminisztrációs végpontokat.
• Szolgáltatói útvonal: engedélyezzen egy átjáróútvonalat ahelyett, hogy közvetlen hozzáférést kapna minden felsőbb szintű szolgáltatóhoz.
• Arány: a percenkénti vagy egyidejű kérések maximális száma.
• Költségkeret: kulcsonkénti, csapatonkénti vagy bérlőnkénti költési korlátok érvényesítése.

Például egy átmeneti kulcshoz általában nem kell hozzáférni a legdrágább éles modellhez. A dokumentum-osztályozó munkásnak valószínűleg nincs szüksége a képgeneráláshoz. Az ügyfél felé néző bérlői kulcs nem használhatja fel egy másik bérlő költségkeretét.

Rétegenkénti költségszabályozás tervezése

Az LLM API biztonsága és a költségszabályozás átfedésben van. A kiszivárgott kulcsot gyakran számlázási rendellenességként észlelik, mielőtt biztonsági eseményként észlelnék.

Tény: Az OpenAI fiókbiztonsági útmutatása ésszerű költési korlátokat javasol, és megjegyzi, hogy a különálló API-kulcsok megkönnyíthetik a használat funkció, csapat, termék vagy projekt szerinti megtekintését. Az OpenAI használati jelentése a részletes elemzést is támogatja olyan mezőkön keresztül, mint a projektazonosító, felhasználói azonosító, API kulcsazonosító, modell, köteg és szolgáltatási szint.

Javaslat: használjon rétegzett korlátokat egy globális korlát helyett:

• Kulcsonkénti korlát: megakadályozza, hogy egyetlen hitelesítő adat lemerítse a teljes költségkeretet.
• Csapatonkénti korlát: láthatóvá és elszámoltathatóvá teszi a részleghasználatot.
• Bérlőnkénti korlát: elkülöníti az ügyfelek használatát SaaS-ben és ügynökségi forgatókönyvekben.
• Napi anomália küszöbértéke: riasztást vált ki, ha a használat eltér a szokásostól.
• Globális vészleállítás: lehetővé teszi a gyors felfüggesztést, ha a visszaélés aktív.

A kemény korlátok hasznosak, de megszakíthatják a törvényes kötegelt feladatokat. A biztonságosabb gyártási minta a következő ellenőrzések sorozata:

1. Figyelmeztetés a várható napi költés 50 százalékánál.
2. 80 százalékos emelés.
3. A nem kritikus forgalmat 100 százalékra szabályozza.
4. Csak a sértő kulcsot, bérlőt vagy útvonalat blokkolja a globális leállítás előtt.

Kiváltás: a szigorú költségvetés csökkenti a számlázási kockázatot, de elérhetőségi kockázatot is okozhat. Munkaterhelés szerinti szintkorlátok: az interaktív éles forgalom, az ügyfelek felé irányuló fizetett forgalom, a háttérmunkák, a kísérletek és a fejlesztői sandboxok nem hibázhatnak egyformán.

A használat nyomon követése kulcs és logikai szereplő szerint

Egy kulcs azonosítja a hitelesítő adatokat. Előfordulhat, hogy nem azonosítja a kérést okozó tényleges felhasználót, bérlőt, szolgáltatást vagy munkafolyamatot. Hasznos mesterséges intelligencia-használati elemzésekhez naplózza a műszaki és az üzleti dimenziókat is.

Javaslat: gyűjtse össze a következő mezőket minden egyes kérelemhez, amennyiben az adatvédelmi és irányelvek ezt lehetővé teszik:

• Kérésazonosító és időbélyegző.
• API-kulcs-azonosító vagy virtuális kulcs-azonosító.
• Alkalmazás-, csapat-, bérlő-, felhasználó- vagy munkafolyamat-azonosító.
• Szolgáltató, modell, útvonal és szolgáltatási szint.
• A felszólítás és a befejezés jogkivonatainak száma vagy ezzel egyenértékű használati egységek.
• Becsült költség.
• Késés, állapotkód, újrapróbálkozások száma és hibaosztály.

Ne változtassa a költségek megfigyelhetőségét szükségtelen adatgyűjtéssé. Alapértelmezés szerint kerülje a teljes értesítések tárolását, ha azok személyes adatokat, ügyféltitkokat vagy szabályozott tartalmat tartalmazhatnak. Sok esetben elegendő a kivonatolt felhasználói azonosítók, bérlői azonosítók, tokenszámok és modellnevek a visszaterhelés és az anomália észleléséhez.

Rotáció állásidő nélkül: biztonságos munkafolyamat

Tény: A NIST kulcskezelési útmutatója a kulcskezelést életciklus-fegyelemként kezeli, beleértve a generálást, tárolást, aktiválást, forgatást, felfüggesztést, visszavonást és megsemmisítést. Az LLM API-kulcsok esetében a rotáció nem egyszeri biztonsági feladat; ez egy operatív munkafolyamat.

Javaslat: használja ezt az állásidő nélküli forgatási eljárást:

1. Hozza létre a cserekulcsot. Egyezzen meg a szükséges engedélyekkel, költségkerettel, útvonallal és metaadatokkal. Még ne vonja vissza a régi kulcsot.
2. Tárolja a titkos kezelőben. Kerülje a helyi fájlokat, csevegési üzeneteket, jegyeket és beillesztett környezeti változókat.
3. A konfiguráció fokozatos üzembe helyezése. Egyszerre frissítsen egy szolgáltatást, régiót, dolgozói csoportot vagy bérlői szegmenst.
4. Ellenőrizze a forgalom mozgását. Győződjön meg arról, hogy a kérések az új kulccsal érkeznek, és hogy a hibaarány és a várakozási idő normális marad.
5. A régi kulcsra írások leállítása. Megakadályozza, hogy az új központi telepítések hivatkozzanak rá.
6. Visszavonja a régi kulcsot. Miután a forgalom megmozdult, tiltsa le, ne hagyja elfelejtett tartalékként.
7. A kóborlók ellenőrzése. Keresési naplók, telepítési jegyzékek, titkos tárolók, CI-változók és futásidejű hibák a régi kulcsazonosítóhoz.

Azoknál az alkalmazásoknál, amelyek még mindig statikus környezeti változókat használnak, a forgatás törékeny lesz. Haladjon a dinamikus titkos betöltés, a központosított konfiguráció vagy az átjáró által kezelt virtuális kulcsok felé. Legalább dokumentálja, hogy melyik központi telepítést kell módosítani a visszavonás előtt.

Szivárgásra adott válasz runbook

Ha egy kulcs kiszivárog, a sebesség számít. A választ az incidens előtt kell megírni, nem pedig számlázási pánikban rögtönözni.

Azonnali elszigetelés

1. Visszavonja vagy függessze fel a hozzáférhető kulcsot.
2. Ha a visszavonás megszakítaná a termelést, először adjon ki cserét, és azonnal váltson át kritikus forgalmat.
3. Letiltsa az útvonalat, a bérlőt vagy a szolgáltatót, ha a visszaélés továbbra is aktív.
4. Őrizze meg a visszaélések azonosításához szükséges naplókat.

Vizsgálat

1. Azonosítsa, hol jelent meg a kulcs: adattár, előtér-csomag, mobilalkalmazás, naplófájl, támogatási jegy, szállítói eszköz vagy csevegés.
2. Keresse meg az utolsó ismert jogos felhasználást.
3. Hasonlítsa össze a használatot a feltételezett expozíció előtt és után.
4. Tekintse át a használt modelleket, kérjen mennyiséget, költséget, földrajzi elhelyezkedést, ha elérhető, és szokatlan állapotkódokat.
5. Ellenőrizze, hogy a függő titkok vagy a szomszédos rendszerek is megjelenhetnek-e.

Helyreállítás és megelőzés

1. Forgassa a függő hitelesítő adatokat, ha ugyanaz a környezet több titkot is kiszivárgott.
2. Adott esetben értesítse a tulajdonos csapatát és az érintett ügyfelek érdekelt feleit.
3. Adjon hozzá titkos vizsgálatot a tárolókhoz és CI-folyamatokhoz.
4. Akadályozza meg az ismétlődést az ügyféloldali hívások háttérrendszer vagy átjáró mögé helyezésével.
5. Dokumentálja az incidens idővonalát, a kiváltó okot, a költséghatást és az ellenőrzési fejlesztéseket.

Előrejelzés: ahogy a csapatok több ügynököt, beépülő modult, automatizálási eszközt és ügyfélspecifikus munkafolyamatot kapcsolnak az LLM-ekhez, a kulcsfontosságú kiszivárgások egyre inkább költséges incidenseknek, másodsorban biztonsági incidenseknek tűnnek. A kulcsonkénti hozzárendeléssel és költségkeret-vezérlőkkel rendelkező csapatok gyorsabban oldják meg ezeket, mint az egyetlen megosztott hitelesítő adatot használó csapatok.

Átjáró által kezelt kulcsok több szolgáltatóval rendelkező csapatok számára

Ha szervezete több LLM-szolgáltatót használ, a közvetlen szolgáltatói kulcsok szétszórt irányítást hozhatnak létre: különböző irányítópultok, eltérő számlázási nézetek, eltérő engedélymodellek és inkonzisztens rotációs folyamatok.

Az átjáró által felügyelt kulcsréteg egyszerűsítheti ezt azáltal, hogy alkalmazásra néző kulcsokat bocsát ki, miközben rejtve tartja az upstream szolgáltatói hitelesítő adatokat. Az alkalmazások OpenAI-kompatibilis API-végpontot hívnak, míg az átjáró kezeli az útválasztást, a használati elemzést, a számlázási hozzárendelést és az irányelvek betartatását.

Javaslat: fontolja meg az átjárót vagy a proxyréteget, amikor szüksége van:

• Egy helyen kezelheti a csapatkulcsokat több szolgáltatónál.
• Egységes AI API számlázás és kulcsonkénti költségjelentés.
• Ügyfélszintű virtuális kulcsok ügynökségek, viszonteladók vagy SaaS-bérlők számára.
• Központi modell engedélyezési listák, útvonalszabályzatok és vészhelyzeti felfüggesztés.
• Használati hozzárendelés bérlő, szolgáltatás, munkafolyamat vagy partnerügyfél szerint.

Trade-off: az átjáró javítja az irányítást, és elrejti az upstream hitelesítő adatokat, de a kérési útvonal részévé válik. Figyelje az éles infrastruktúrához hasonlóan: a várakozási idő, a rendelkezésre állás, a hibaarányok, a sorban állás, az újrapróbálkozási viselkedés és a szolgáltató-specifikus hibák mind számítanak.

Megvalósítási ellenőrzőlista

• Cserélje ki a megosztott szervezeti szintű kulcsokat alkalmazás, környezet, bérlő vagy munkafolyamat szerinti kulcsokra.
• Távolítsa el a nyers szolgáltatói kulcsokat a böngészőkből, mobilalkalmazásokból, asztali bővítményekből és nyilvános szkriptekből.
• A klienskérelmek továbbítása háttérrendszeren vagy AI API-átjárón keresztül.
• Minden kulcshoz csatolja a tulajdonos, a cél, a környezet, az engedélyezett modellek, a költségvetés és a metaadatok áttekintését.
• Alkalmazza a legkisebb jogosultságot: projekt, végpont, modell, útvonal, díjszabás és költségvetési vezérlők, ahol elérhetők.
• Kulcsonkénti, csapatonkénti, bérlőnkénti és globális költési korlátok beállítása.
• Naplókulcs azonosítója, logikai szereplő, modell, tokenhasználat, becsült költség, várakozási idő és állapotkód.
• Hozzon létre egy állásidő nélküli rotációs munkafolyamatot, és tesztelje azt vészhelyzet előtt.
• Írjon szivárgásra adott forgatókönyvet, amely tartalmazza az elszigetelési, vizsgálati és megelőzési lépéseket.
• Tekintse át az inaktív kulcsokat, és vonjon vissza bármit, ha nincs tulajdonosa vagy a közelmúltban jogos használatuk nincs.

Intézhető következtetés

Kezdje a legnagyobb kockázatot jelentő kulccsal: az éles folyamatban használt, több ember által megosztott, túl sok helyre beágyazott, vagy a legnagyobb költésért felelős kulcs. Adjon neki egy tulajdonost, ossza fel határok szerint, adjon hozzá költségvetést, helyezze át egy háttérrendszer vagy átjáró mögé, ha az ügyfelek látják, és dokumentálja, hogyan kell elforgatni.

Ezután ismételje meg. Az erős LLM API kulcskezelés nem egyetlen titkos tárolási döntés. Ez egy életciklus: készlet, elkülönítés, legkevesebb jogosultság, használati hozzárendelés, költségkontroll, rotáció és szivárgásra adott válasz. A megtérülés egyszerű: ha valami elromlik, csak egy alkalmazás, bérlő vagy munkafolyamat kerülhet veszélybe – nem a teljes mesterséges intelligencia-költségvetés.

Kapcsolódó olvasmányok

• u tervezés
• korábbi Model Gate blogjegyzetek
• bevezető Model Gate cikk