Az API-kulcsok kezelése már nem egy kis irányítópult-feladat. Az AI API-kat használó csapatok számára ez a biztonsági, költség- és működési modell részét képezi minden olyan alkalmazás számára, amely felszólításokat küld, modellkimenetet fogad, eszközöket hív meg, vagy pénzt költ mért következtetésekre.
Sok csapat egy szolgáltatói kulccsal kezdi a helyi környezet fájlját. Ez addig működik, amíg ugyanaz a kulcs meg nem jelenik a CI-változókban, notebookokban, IDE-bővítményekben, ügynökökben, kötegelt feladatokban, ügyfél-integrációkban és támogatási szkriptekben. Ezen a ponton a kiszivárgott kulcs nem csak hitelesítési probléma. Felfedheti a figyelmeztetéseket és válaszokat, kiválthat váratlan költségeket, prémium modelleket hívhat meg, eszközöket futtathat alkalmazásjogosultsággal, vagy az incidensekre adott válaszokat találgatásoktól függhet.
Ez az útmutató az API-kulcskezelést életciklusként kezeli: a kulcsok tervezése, kiadása, tárolása, hatóköre, figyelése, elforgatása és visszavonása. Az AI API-hozzáférésre összpontosít, ahol a szokásos API-biztonsági aggályokhoz a modellelérés, a token-alapú költés, a több szolgáltató hitelesítési adatai, az ügyfelek hozzárendelése és az OpenAI-kompatibilis kliensek társulnak.
Ahol az API-kulcsok illeszkednek az API-biztonságba
Az API-kulcs általában a hitelesítő adatok birtoklását bizonyítja. Megválaszolja a kérdést: „van ennek a hívónak érvényes titka?” Ez önmagában nem ad választ minden fontos engedélyezési kérdésre.
A háttérrendszernek továbbra is el kell döntenie, hogy a hívó hozzáfér-e egy adott bérlőhöz, objektumhoz, modellhez, végponthoz, eszközhöz, munkaterülethez, jelentéshez vagy adminisztrációs funkcióhoz. Az OWASP API Security 10 legfontosabb kockázata, mint például a meghibásodott objektumszintű engedélyezés, a meghibásodott hitelesítés, a korlátlan erőforrás-felhasználás és a meghibásodott funkciószintű engedélyezés, emlékeztet arra, hogy az érvényes hitelesítő adatok csak a rendszer egyik rétege.
Az AI API-k esetében ez a különbségtétel azért fontos, mert ugyanaz a kulcs nagyon különböző kockázati profilú műveleteket hajthat végre. Egy belső munkafolyamathoz olcsó szöveges modellt hívni tudó kulcs nem tud automatikusan prémium modelleket hívni, kötegelt feladatokat létrehozni, egy másik bérlő adatait elérni, e-maileket küldő eszközöket meghívni, vagy számlázási beállításokat kezelni.
A tartós API biztonsági modell három szempontot különböztet meg:
- Hitelesítés: igazolja, hogy a kérés érvényes, vagy hiteles. munkamenet.
- Engedélyezés: annak eldöntése, hogy a hitelesített hívó mit tehet az aktuális bérlői, környezeti és üzleti környezetben.
- Irányítás: korlátozza a költést, az arányt, a modellelérést, az adatok hozzáférhetőségét és az adminisztratív felügyeletet, hogy egyetlen hiba is korlátozott sugárzási sugárral járjon.
A vezérlő kulcsok nem lehetnek hasznosak vagy érzékenyek. Használja őket HTTPS-sel, szerveroldali engedélyezési ellenőrzésekkel, auditnaplókkal, legkisebb jogosultságokkal, díjkorlátokkal, kiadási korlátokkal és biztonságos titkos kezeléssel.
Kezdje élő API-kulcskészlettel
Nem kezelheti azokat a kulcsokat, amelyeket nem tud elnevezni. Az első gyakorlati lépés az AI-rendszerek által használt API-kulcsok és hitelesítő adatokhoz hasonló objektumok élő leltározása.
Minden kulcsrekordnak tartalmaznia kell legalább egy kulcsazonosítót, egy nem visszafordítható hash-t vagy ujjlenyomatot, tulajdonost, készítőt, csapatot vagy bérlőt, környezetet, munkaterhelést, hatóköröket, engedélyezett modelleket, engedélyezett végpontokat, ráfordítási szabályzatot, díjszabási szabályzatot, IP-korlátozásokat, ha alkalmazható, expi-t és mp-t metaadatok.
A készletnek többet kell tartalmaznia, mint az éles futásidejű kulcsokat. Tartalmazza a személyes fejlesztői kulcsokat, a szolgáltatási fiók kulcsait, a CI/CD-kulcsokat, a munkaterület-kulcsokat, az ügyfél- vagy bérlői kulcsokat, a viszonteladó által kezelt kulcsokat, a számlázási/jelentési kulcsokat, az adminisztrációs API-hitelesítési adatokat és a felsőbb szintű szolgáltatói hitelesítési adatokat.
A legfontosabb mezők a tulajdonjog, a cél, a hatókör, az utolsó használat és a korlátozási szabályzat. Nélkülük minden jövőbeni biztonsági feladat lassabb lesz: a leállítás, a rotáció, a szivárgásra való reagálás, a költségek vizsgálata és az ügyfélszolgálat.
A kulcsok határainak tudatos tervezése
A legnagyobb API-kulcskezelési hiba az, ha egy kulcsot túl sok határon túllépnek. A megosztott gyártási kulcs kezdetben kényelmes, de tönkreteszi a hozzárendelést, és zavaróvá teszi a visszavonást. Ha kiszivárog, előfordulhat, hogy minden szolgáltatásnál le kell állítania a forgalmat, miközben továbbra sem tudja azonosítani, hogy melyik terhelés okozta a problémát.
A jó kulcshatárok követik az üzlet és a szoftver formáját. A termelés elkülönítése a fejlesztéstől, az emberek a szolgáltatásoktól, az ügyfelek a belső csapatoktól, a bérlők egymástól, a futásidejű hitelesítési adatok az adminisztratív hitelesítő adatoktól, és az átjáró által kiadott ügyfélkulcsok az upstream szolgáltatói kulcsoktól.
Környezeti határok
A fejlesztéshez, az ütemezéshez és a gyártáshoz külön kulcsokat kell használni. A fejlesztési kulcs nem érheti el a termelési adatokat vagy a termelési költségvetést.Az átmeneti kulcsnak csak szigorúan ellenőrzött okai vannak az élő ügyfél-munkaterhelésekhez.
A munkaterhelés határai
Minden szolgáltatásnak, kötegelt feladatnak, ügynökflottának, integrációnak vagy ütemezett feladatnak saját kulcs- vagy szolgáltatásfiókkal kell rendelkeznie. Ez lehetővé teszi az alapvető kérdések megválaszolását: melyik terhelés költötte el a pénzt, melyik szolgáltatásnál kezdődött el a hitelesítés sikertelensége, melyik integráció használt elavult modellt, és melyik kulcsot kell lefagyni egy incidens során.
A bérlő és az ügyfél határai
A több bérlős rendszereknek hozzárendelésre és elkülönítésre van szükségük. Ha ügyféloldali API-kulcsot használnak az értesítések elküldéséhez, a kérést az ügyfélhez, bérlőhöz, alkalmazáshoz és ideális esetben egy álnevű végfelhasználóhoz vagy szereplőhöz kell kötni. Az egyik bérlő számára feltört kulcs nem engedheti meg a hozzáférést egy másik bérlő adataihoz, modellprofiljához, költségvetéséhez vagy naplóihoz.
Szolgáltatói hitelesítési adatok határai
A felfelé irányuló szolgáltatói kulcsok eltérnek az ügyfeleknek vagy belső alkalmazásoknak kiadott kulcsoktól. A szolgáltatói hitelesítési adatoknak szerveroldalinak kell maradniuk, tárolóban vagy titkos kezelőben kell őket tárolni, és soha nem kell elküldeni őket böngészőknek, mobilalkalmazásoknak, asztali klienseknek, nyilvános notebookoknak vagy ügyfél által vezérelt környezeteknek.
Egy átjáró segíthet ebben azáltal, hogy egy ügyféloldali kulcsfelületet tesz elérhetővé, miközben a szolgáltatói hitelesítési adatokat az átjáró mögött tartja. Ez lehetővé teszi a használati elemzések, a visszavonások, a csoportvezérlések és a szabályzatok betartatásának központosítását a szolgáltatók között. Ha egy OpenAI-kompatibilis API köré szabványosítja az ügyfeleket, az átjáró határa különösen fontossá válik, mert sok eszköz egyetlen alap URL-t és vivőjogkivonatot vár el.
Alkalmazza a legkevesebb jogosultságot a modellekre, végpontokra, eszközökre és költésre
A legkisebb hozzáférési jogosultság csak a kulcshoz szükséges hozzáférést jelenti. Az AI-rendszerek esetében a hatókör nem csupán API-végpontok listája. Ezenkívül modelleket, eszközöket, token-költségvetéseket, sebességkorlátokat, bérlőket, adatosztályokat és adminisztrációs funkciókat is tartalmaz.
A gyakorlati AI API kulcsszabályzat a következőket foglalhatja magában:
- Engedélyezett modellcsaládok vagy adott modellazonosítók.
- Engedélyezett végpontok, például csevegés befejezések, beágyazások, kötegelt feladatok, vagy adminisztrációs fájlok létrehozása
. API-k, számlázási API-k és munkaterület-kezelési API-k futásidejű kulcsokhoz.
- Kulcsonkénti sebességkorlátok a percenkénti kérésekhez és a percenkénti tokenekhez.
- Bérlőnkénti, csapatonkénti vagy ügyfélenkénti költési korlátok.
- A prémium modell szabályozza, hogy egy alacsony kockázatú munkafolyamat nem tudja-e hirtelen használni a legdrágább kulcsokat. külső csatlakozók, kódvégrehajtás, visszakereső rendszerek vagy üzleti műveletek.
- IP-engedélyezőlisták stabil szerveroldali munkaterhelésekhez, ahol a hálózati elérési út kiszámítható.
A ráfordítások szabályozása a mért AI API-k API-biztonságának része. Egy kiszivárgott kulcs közvetlen anyagi kárt okozhat még akkor is, ha soha nem fér hozzá érzékeny adatokhoz. A díjkorlátok segítenek, de nem elegendőek. A token mennyisége, az újrapróbálkozások, a kötegelt feladatok, az eszközhívások és a modellválasztás mind hatással vannak a költségekre. A biztonságos megvalósításnak kombinálnia kell a díjszabályozást a kiadási plafonnal, a modellengedélyező listákkal, az anomáliák észlelésével és a vészhelyzeti lefagyás szabályozásával.
A modellköltségeket és a hozzáférési szabályzatokat összehasonlító csapatoknak a biztonságot és a pénzügyet össze kell hangolniuk. A modellárazás nem csak beszerzési kérdés; ez határozza meg, hogy egy kompromittált vagy rosszul konfigurált kulcs mennyit költhet. Tartsa a jóváhagyott modellprofilokat a költségvetéshez kötve, és ellenőrizze őket, amikor a modellkeverék megváltozik, különösen akkor, ha AI-modellárazást használ a munkaterhelések költség és képesség szerinti irányítására.
Tárolja a titkokat, ahol vannak
Az API-kulcsok titkos kezelőkhöz, szerver-oldali konfigurációkhoz, vezérelhető CI-be vagy CD-beállításokhoz tartoznak. Nem tartoznak bele a forráskódba, a böngésző JavaScript-kódjába, a mobilcsomagokba, az asztali alkalmazáscsomagokba, a nyilvános jegyzetfüzetekbe, a képernyőképekbe, a csevegési üzenetekbe, az elemzői adathordozókba, a támogatási jegyekbe vagy a naplókba.
Az ügyféloldali expozíció gyakori hibaüzenet. Ha egy szolgáltatói kulcs be van ágyazva egy böngészőbe vagy mobilalkalmazásba, bárki, aki meg tudja tekinteni az alkalmazást, kibonthatja azt, és kéréseket tehet a számlatulajdonos nevében. A nem ellenőrzött környezetben futó böngészők, mobilalkalmazások, IDE-flották és ügynökök esetében használjon szerveroldali proxyt vagy rövid idejű delegált hitelesítési adatokat szűk hatókörrel. Ne ossza ki a hosszú élettartamú szolgáltatói hitelesítő adatokat olyan ügyfeleknek, amelyeket nem tudja ellenőrizni.
A CI/CD-nek ugyanilyen fegyelemre van szüksége. Tárolja a kulcsokat védett változóként. Korlátozza, hogy ki olvashatja vagy módosíthatja őket. Kerülje a környezeti változók nyomtatását az összeállítási naplókban. Szerkessze vissza az engedélyezési fejléceket a sikertelen kérés kiíratásaiban. Az előzetes telepítéseket és a villás lekérési kérelmeket a védett gyártási folyamatoktól eltérő bizalmi zónákként kezelje.
A naplók és a megfigyelési rendszerek külön figyelmet érdemelnek.Tárolja a kulcsujjlenyomatokat, a kérésazonosítókat, a bérlői azonosítókat, a modellazonosítókat, a válaszállapotot, a tokenszámlálókat, a költségszámlálókat, az IP- vagy ügyfél-metaadatokat, ahol szükséges, és a szabályzati döntéseket. Ne tároljon teljes API-kulcsokat. A nyomkövetések, a fordított proxynaplók, a kivételjelentések, a webhook hasznos terhelések, a támogatási eszközök, az elemző események és a holtbetűs várólisták titkainak visszaállítása.
Vészhelyzet előtti rotáció létrehozása
A forgatás nem egyszerűen egy kulcs törlése és egy másik létrehozása. Ha a telepített szolgáltatások továbbra is a régi kulcstól függenek, a törlés leállást okoz. A megbízható forgatási folyamat átfedést, megfigyelést és egyértelmű visszavonási pontot használ.
Gyakori minta a két aktív résszel rendelkező rotációs csoport. Hozza létre a cserekulcsot, helyezze üzembe minden függő rendszeren, figyelje meg a régi kulcs utolsó használatát, fagyassza le a régi kulcsot, ha a forgalom megmozdult, és törölje azt egy bizalmi ablak után. Legyen egyértelmű a visszaállítási szabályok: mikor engedélyezhető újra a régi kulcs, ki hagyhatja jóvá, és meddig maradhat elérhető?
A kulcsok rövid élettartama csökkenti az elavult hitelesítő adatok kockázatát, de növeli a működési terheket. A hosszú élettartamú kulcsok csökkentik az üzembe helyezési lemorzsolódást, de nagyobb ablakot hoznak létre az elfelejtett hitelesítő adatok és az alkalmazottak kilépési hiányosságai között. A megfelelő politika a munkaterheléstől függ. Előfordulhat, hogy egy nagy értékű termelési szolgáltatási fiók rögzített ütemezés szerint forog automatizálással. Az ideiglenes fejlesztői kulcsnak gyorsan le kell járnia. Előfordulhat, hogy az ügyfél által kezelt integrációhoz hosszabb áttelepítési időtartamra és egyértelmű elavulási üzenetekre van szükség.
Ne forgasson el minden kulcsot ugyanúgy. A kulcsok listázására, létrehozására, törlésére vagy módosítására alkalmas adminisztratív hitelesítő adatok nagyobb kockázatot jelentenek, mint a futásidejű következtetési kulcsok, ezért erősebb vezérléssel, szűkebb hozzáféréssel és agresszívebb figyeléssel kell rendelkezniük. A futásidejű kulcsok nem rendelkezhetnek adminisztratív jogosultsággal, hacsak nincs konkrét, felülvizsgált ok.
A szivárgások és a rendellenes használat észlelése
A szivárgásészlelés akkor működik a legjobban, ha több rendszer erősíti egymást. A forrásvezérlés titkos vizsgálata képes elkapni a lerakatokhoz rendelt kulcsokat. A CI ellenőrzések megakadályozhatják a nyilvánvaló szivárgásokat az egyesítés előtt. Az egyéni minták képesek felismerni a belső kulcsformátumokat. A szolgáltatói irányítópultok szokatlan tevékenységeket mutathatnak be. Az átjáró telemetriája új IP-címeket, új földrajzi területeket, sikertelen hitelesítési sorozatokat, hirtelen költési sebességet vagy váratlan modellek hívásait jeleníti meg.
A hasznos biztonsági irányítópultok közé tartoznak a nyugvó kulcsok, a tulajdonos nélküli kulcsok, a korlátok nélküli kulcsok, a lejárathoz közeledő kulcsok, az új hálózatokból használt kulcsok, a forgalom gyors fogadása, a gyors hibajelenség-növekedéssel rendelkező kulcsok, kulcsok, amelyek megközelítik a költési plafont.
Az észlelésnek ki kell terjednie a naplókra és az aszinkron rendszerekre is. A webhookokhoz, a háttérfeladatokhoz, a várólistákhoz és a késleltetett befejezésekhez kérésazonosítókra és eredeti kulcs-hozzárendelésre van szükség. Ellenkező esetben előfordulhat, hogy egy gyanús visszahívási vagy kötegelt eredményt nem lehet visszakapcsolni a kulcshoz és a bérlőhöz, amely létrehozta.
Ha egy titok megjelenik a Git előzményeiben, nem elég eltávolítani a tárból. Bárki, aki hozzáfért a tárhoz, összeállította a naplókat, tükröket, elágazásokat, csomagtermékeket vagy gyorsítótárazott oldalakat, már másolhatta a kulcsot. A hitelesítő adatot érvényteleníteni kell vagy le kell fagyasztani, majd ki kell cserélni.
Válasz egy feltört API-kulcsra
A jó incidensre adott választerv rövid, átgondolt és konkrét. Az első döntés általában az, hogy befagyasztják vagy visszavonják. A Freeze gyorsan leállítja a forgalmat, miközben megőrzi a rekordot a nyomozáshoz. A visszavonás véglegesen letiltja a kulcsot. Egyes csapatok először a lefagyást használják, ha ellenőrzési folytonosságra és azonnali visszaállítási lehetőségekre van szükségük; mások automatikusan visszavonják a megerősített nyilvános kiszivárogtatások miatt. Mindkét megközelítés automatizálást és egyértelmű jogosultságot igényel.
A gyakorlati válaszfolyamat a következőképpen néz ki:
- A gyanús kulcs lefagyasztása vagy visszavonása a súlyosság és a bizalom alapján.
- Azonosítsa be a tulajdonost, a bérlőt, a munkaterhelést, a hatóköröket, a modellelérést, a költési szabályzatot és a legutóbb használt idővonalat.
- Tekintse át a használatot, a modelleket, a szokatlan IP-címeket, végpontokat, promptokat, modelleket, végpontokat, promptokat költsége.
- Értékelje fel az érintett adatokat, bérlőket, későbbi műveleteket és számlázási hatásokat.
- Kiadjon ki egy cserekulcsot javított hatókörrel és korlátokkal.
- Szüntesse meg a kiváltó okot, például egy titkos titkosságot, nyilvánosságra hozott naplózást, túlzott CI-változót vagy ügyféloldali csomagot.
- Adjon hozzá egy titkosítási, szűkítő-ellenőrző hatókört, naplózási hatókört. vagy költési figyelmeztetéseket.
- Dokumentálja az incidenst, és frissítse a runbookokat.
A csere lépése nem hozhatja újra ugyanazt a kockázatot. Ha egy kulcs kiszivárgott, mert tíz szolgáltatás között megosztották, cserélje ki külön szolgáltatási fiókkulcsokra. Ha kiszivárgott a naplókon keresztül, javítsa ki a naplózást, mielőtt új kulcsot adna ki. Ha túlköltekezett, mert minden modellt meg tud hívni, adjon hozzá modell engedélyezési listákat és költési korlátokat.
Átjáró által kezelt kulcsok és több szolgáltató AI-hozzáférése
A mesterséges intelligencia csapatai gyakran több modellszolgáltatót is használnak.Minden szolgáltatónak saját kulcsmodellje, munkaterület-struktúrája, díjkorlátai, modellnevei, árazása és adminisztrációs API-ja van. Az összes szolgáltatói kulcs közvetlen kezelése minden alkalmazásban megsokszorozza a működési kockázatot.
Az átjáró által kezelt kulcsmodell csökkentheti ezt a bonyolultságot. Az alkalmazások ügyféloldali vagy belső kulccsal hívják meg az átjárót. Az átjáró hitelesíti a hívót, alkalmazza a bérlői házirendet, kényszeríti a modell- és költésvezérlőket, rögzíti a használatot, és a kiszolgálóoldali szolgáltatói hitelesítési adatokat használja. Ez hasznos a többmodelles alkalmazások, belső platformok, ügynökségek és viszonteladói szolgáltatások esetében.
A Model Gate esetében ez az, ahol az átjáró szerepe lényeges: központosított, ügyfélközpontú kulcsok, egységes használati elemzés, csapatvezérlés, költési korlátok, IP-biztonság, Telegram működési integrációk, Partner API automatizálás és visszaélésekre való válaszadás. Az ügyfeleket vagy a későbbi szolgáltatásokat nyújtó vállalkozások számára a Partner API automatizálása a kulcsok létrehozását, a frissítések korlátozását, a lefagyasztást és a viszonteladói munkafolyamatokat konzisztenssé teheti a kézi helyett.
Az átjáró nem von el minden felelősséget az alkalmazáscsapattól. Továbbra is szüksége van a biztonságos tárolásra, a háttér-engedélyezésre, a bérlői elkülönítésre, a végpont-tervezésre, a CI/CD-higiéniára, az azonnali és válaszadási adatszabályzatra, valamint a szolgáltatói oldali korlátozásokra, ahol rendelkezésre állnak. Az átjáró nagy értékű vezérlősíkká válik, ezért erős tárolórendszerre, auditnaplókra, hozzáférés-vezérlésre, rendelkezésre állás tervezésre és adminisztratív szétválasztásra van szüksége.
Gyakori API-kulcskezelési hibák
A leggyakoribb hibák előre jelezhetők. A csapatok közvetlenül az ügyfélalkalmazásokba helyezik el a szolgáltatói kulcsokat. Minden szolgáltatáshoz és ügyfélhez egy gyártási kulcsot használnak. Úgy váltják egymást, hogy először törlik, majd később telepítik. Kulcsokat hoznak létre tulajdonosok, korlátok, hatókör vagy lejárat nélkül. A teljes engedélyezési fejléceket naplózzák. Kizárólag a sebességkorlátokra támaszkodnak a mesterséges intelligencia költségének szabályozására. A futásidejű szolgáltatások rendszergazdai hitelesítő adatait adják meg. Eltávolítanak egy kiszivárgott kulcsot a Gitből anélkül, hogy visszavonnák. Az alkalmazottakat kívülre helyezik, de a személyes kulcsokat, a helyi környezeti fájlokat és a CI-változókat aktívan hagyják.
Egy másik apró hiba, hogy a gyors és válasznaplózást tisztán operatívnak tekintik. A részletes naplók segíthetik a visszaélések kivizsgálását, de személyes adatokat, ügyféltartalmat, titkokat vagy szabályozott információkat is tartalmazhatnak. A metaadatok első naplózása gyakran biztonságosabb: alapértelmezés szerint rögzítheti a kulcs ujjlenyomatait, a modellazonosítókat, a tokenszámokat, a költségeket, az állapotkódokat, a házirend-döntéseket és a kérésazonosítókat, majd szabályozott hozzáférést igényelnek a mélyebb hibakeresési adatokhoz.
Megvalósítási ellenőrzőlista
Egy erős API-kulcskezelő program kezdődhet egy fókuszált ellenőrzőlistával, leltár, kulcstulajdonosok összessége:
Cre>Következtetés
Az AI API-k API-kulcskezelése a személyazonosság, a jogosultság, a költségek és a működési sugárzási sugár ellenőrzéséről szól. A biztonságos kulcs nem csak egy véletlenszerű karakterlánc. Van tulajdonosa, célja, hatálya, környezete, költségvetése, lejárata, rotációs útvonala, ellenőrzési nyomvonala és incidensre adott választerve.
A gyakorlati cél nem az, hogy minden kérés körül bürokráciát teremtsen. Ez a normál munka biztonságosabbá tétele: a fejlesztők építhetnek, a szolgáltatások futhatnak, az ügyfelek biztosíthatók, a biztonsági csapatok pedig megválaszolhatják, mi történt, ha egy kulcs kiszivárog vagy megugrik a költés. Kezdje a leltárral és a határokkal, majd adjon hozzá legkevesebb jogosultságot, biztonságos tárolást, forgatást, figyelést és válaszautomatizálást. A több szolgáltató mesterséges intelligencia-hozzáférése esetén egy átjáró központosíthatja a vezérlés nagy részét, de az alkalmazások engedélyezése és a titkos higiénia továbbra is az alapvető mérnöki felelősség marad.