Szolgáltatói hitelesítő adattárolók többmodell AI-átjárókhoz: külön futásidejű, rendszergazdai, számlázási és BYOK-hozzáférés

A lefelé irányuló API-kulcsok és az upstream szolgáltatói hitelesítő adatok különböző problémákat oldanak meg. Az átjáró által kiadott fejlesztői kulcs azonosítja az alkalmazást, a csapatot, a bérlőt, a költségvetést és a házirend-környezetet. Az upstream szolgáltatói kulcs lehetővé teszi az átjáró számára, hogy pénzt költsön, és hozzáférjen a modellekhez a szolgáltatói fiókban. Ha ezeket ugyanolyan titokként kezeljük, a csapatok végül egyetlen korlátlan kulccsal rendelkeznek egy megosztott projektben, adminisztrátori hitelesítő adatokkal a futásidejű szolgáltatásokban, és nincs megbízható módja annak, hogy megválaszolják, melyik bérlő melyik szolgáltatói oldali díjat okozta.

A gyakorlati minta egy szolgáltatói hitelesítő adattár: egy dedikált vezérlősík az upstream hitelesítő adatok importálására, osztályozására, tárolására, kiválasztására, elforgatására és auditálására. Ennek az útválasztó, a számlázási főkönyv, a házirend-motor és a műveleti munkafolyamat mögött kell lennie – nem az alkalmazáskódban, a modell konfigurációs fájljaiban, a bérlői rekordokban vagy az elemzési eseményekben.

Az olvasói probléma: az upstream hitelesítő adatok láthatatlan infrastruktúrává válnak

A legtöbb többmodelles üzembe helyezés egy egyszerű céllal kezdődik: irányítson egy OpenAI-kompatibilis kérést a legjobb elérhető szolgáltatóhoz. Ezután további fiókok jelennek meg: egy szolgáltatói projekt a termeléshez, egy másik az értékeléshez, egy Anthropic munkaterület egy üzleti egység számára, egy Google Cloud projekt a Gemini számára, és több, az ügyfelek által biztosított kulcs a BYOK-szerződésekhez.

A kockázat nem pusztán titkos kiszivárgás. Ez az engedélyezési kontextus elvesztése. Egy érvényes szolgáltatói kulcs technikailag fel tud hívni egy végpontot, de az átjárónak továbbra is tudnia kell, hogy ez a kulcs engedélyezett-e ehhez a bérlőhöz, ehhez a modellcsaládhoz, ehhez az adatmegőrzési szabályzathoz, ehhez a költségvetéshez, ehhez a régióhoz és ehhez az automatizálási útvonalhoz.

Tény: a szolgáltatói platformok különböző fiókhatárokat és hitelesítő adatok típusokat tesznek elérhetővé. Az OpenAI dokumentálja a projekteket és a szolgáltatásfiókokat, valamint a szolgáltatásfiók API-kulcsengedélyei alapértelmezés szerint olvasási és írási hozzáférést biztosítanak a projekt API-erőforrásaihoz. Az OpenAI az Admin API kulcsobjektumokat a szokásos projekt/futási API használattól elkülönítve teszi közzé. Az Anthropic a munkaterületeket szervezeti határként dokumentálja, és kijelenti, hogy az Admin API-végpontokhoz a szabványos API-kulcsoktól eltérő rendszergazdai API-kulcsokra van szükség; Az Anthropic azt is megjegyzi, hogy az API-kulcsok ahhoz a munkaterülethez vannak kötve, ahol létrejöttek, és nem mozgathatók át a munkaterületek között. A Google Gemini API-kulcsdokumentációja szerint minden Gemini API-kulcs egy Google Cloud-projekthez van társítva, és API-korlátozásokat javasol, hogy csökkentsék a sérüléseket, ha egy kulcsot feltörnek.

Javaslat: ne hozzon létre egyetlen általános „provider_key” mezőt, és ne nevezze késznek. Hozzon létre egy hitelesítési adatkészletet, amely megőrzi a szolgáltató-specifikus határokat, miközben egy normalizált házirend-modellt tesz az átjáró elé.

Határozzon meg egy hitelesítő adatok taxonómiáját a kulcsok elfogadása előtt

A trezornak vissza kell utasítania a kétértelmű hitelesítő adatokat. Az importáláskor az üzemeltetőnek vagy az automatizálási munkafolyamatnak be kell osztályoznia a hitelesítő adatokat. Legalább ezeket a kategóriákat használja:

• Futásidejű következtetés hitelesítő adatai: az átjáró modellkövetkeztetési végpontok, például csevegés, válaszok, beágyazás, moderálás, átírás vagy képgenerálás hívására használja, a szolgáltatói támogatástól függően.
• Rendszergazdai automatizálási hitelesítési adatok: szolgáltatói oldali szervezetek, munkaterületek, projektek, felhasználók, kulcsok vagy adminisztratív erőforrások kezelésére szolgál. Ezek soha nem lehetnek a futásidejű kérési útvonalon.
• Számlázási és jelentési hitelesítő adatok: használati, számlák, költségek vagy szervezeti jelentések lekérésére szolgál, ahol a szolgáltatók támogatják ezeket az API-kat. Tartsa őket elkülönítve a következtetési kulcsoktól, hogy a jelentéskészítési feladatok ne generáljanak modellhasználatot.
• Csak értékeléshez szükséges hitelesítési adatok: az összehasonlítás, a minőségbiztosítás, az áttelepítés vagy az átmeneti munkafolyamatok használják. Alacsony kvótákkal, egyértelmű környezeti címkékkel kell rendelkezniük, és nem kell visszaállítani a termelést.
• Ügyfél BYOK hitelesítő adatai: az ügyfél által biztosított kulcsok egy adott bérlőhöz, szolgáltatói fiókhoz, szerződéshez és adatszabályzathoz kötve. Ezeket nem szabad összevonni megosztott útválasztásban, kivéve, ha az ügyfél kifejezetten engedélyezi.

Ez a taxonómia nem csupán dokumentáció. Ennek vezérelnie kell a hozzáférés-vezérlést, az útválasztási jogosultságot, a riasztást és a rotációs munkafolyamatokat. Ha egy hitelesítési adatot kategória, tulajdonos, szolgáltatói fiókhatár és engedélyezett használat nélkül importál, akkor le van tiltva.

Tárolja a titkokat egy trezorban, ne a terméknyilvántartásban

A trezor legyen az egyetlen olyan összetevő, amely képes visszafejteni a felfelé irányuló hitelesítő adatokat. Más rendszerek tárolhatnak hivatkozásokat, kivonatokat, állapotmezőket és házirend-metaadatokat, de magát a hitelesítő adatot nem.

Ne tároljon felfelé irányuló titkokat ezeken a helyeken

• Bérlői profil sorai.
• Modell útválasztási konfigurációs fájlok.
• Rendszernaplók vagy nyomkövetési szakaszok.
• Analytics esemény hasznos terhelései.
• Fejlesztői CI-változók.
• Jegyek, csevegőeszközök vagy képernyőképek támogatása.

Egy használható boltozattervnek két síkja van. A titkos sík titkosított hitelesítő adatokat tárol, és szigorúan ellenőrzi a visszafejtési műveleteket. A metaadatsík az útválasztás és az irányítás által használt, nem titkos attribútumokat tárolja. Az útválasztónak általában csak egy hitelesítő adatazonosítóra és egy rövid ideig tartó, a memóriában lévő titkos lekérésre van szüksége a feladáskor, nem pedig széles körű adatbázis-hozzáférésre minden szolgáltatói kulcshoz.

Védje meg a trezort, mint nagy értékű infrastruktúrát: borítéktitkosítás vagy felügyelt KMS, szigorú szolgáltatási identitás, üvegtörési eljárások, biztonsági mentés és visszaállítás tesztelése, hozzáférés ellenőrzése és riasztás szokatlan visszafejtési mennyiség esetén. A központi trezor leegyszerűsíti az irányítást, de koncentrálja a kockázatokat is. Ez a kompromisszum.

Minden hitelesítő adathoz csatolja a szabályzat metaadatait

A metaadat-modellnek elég egyértelműnek kell lennie ahhoz, hogy az átjáró eldönthesse, hogy egy hitelesítő adat jogosult-e, mielőtt hozzáérne egy szolgáltatói végponthoz.

A gyakorlati hitelesítő nyilvántartás a következőket tartalmazza:

• credential_id: belső megváltoztathatatlan azonosító.
• szolgáltató: OpenAI, Anthropic, Gemini, Azure OpenAI vagy más adapter.
• provider_account_boundary: szervezet, projekt, munkaterület, felhőprojekt, előfizetés vagy ezzel egyenértékű.
• credential_class: futásidejű, adminisztrációs, számlázási, értékelési vagy BYOK.
• környezet: gyártás, színpadra állítás, fejlesztés, értékelés, homokozó.
• tenant_binding: megosztott platform hitelesítő adatai, egyetlen bérlő, bérlői csoport vagy ügyfél BYOK-bérlő.
• allowed_model_families: például szöveggenerálás, beágyazás, látás, kép, hang vagy konkrét modellprofilok.
• allowed_endpoints: normalizált átjáró-képességek a szolgáltatói végpontokhoz leképezve.
• data_policy: engedélyezett megőrzési osztály, naplózási osztály, lakóhely-követelmény és szolgáltatáskorlátozások.
• budget_scope: költséghely, viszonteladói ügyfél, belső részleg vagy szerződés.
• tulajdonos: megnevezett csapat vagy felelős személy.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: ismeretlen, egészséges, leromlott, nem engedélyezett, quota_exhausted, letiltott.
• emergency_disable: azonnali útválasztási blokk, független a normál házirend-állapottól.

Tartsa ezt a modellt szolgáltatósemlegesen, de ne törölje a szolgáltatói valóságot. Egy antropikus munkaterülethez kötött kulcs és egy Google Cloud-projekthez kötött Gemini-kulcs nem cserélhető fel, csak mert mindkettő képes szöveget generálni. Az átjárónak szüksége van erre a származásra az ellenőrzésekhez, a visszaterheléshez és a biztonságos feladatátvételhez.

Külön futásidejű, rendszergazdai és számlázási hozzáférés

A legfontosabb szabály egyszerű: a futásidejű következtetésekhez használt kulcs nem kezelheti a szolgáltató szervezeteket, munkaterületeket, felhasználókat, projekteket vagy adminisztratív erőforrásokat.

A futásidejű forgalom nagy volumenű, és a legnagyobb működési felületnek van kitéve. Áthalad a kérés-útválasztókon, az újrapróbálkozási logikán, az adatfolyam-kezelőkön, a modelladaptereken és az incidens munkafolyamatokon. Az adminisztrátori hitelesítő adatok alacsony gyakoriságúak és nagy hatásúak. Külön jóváhagyási útvonal mögött kell élniük, rövid TTL-ekkel, adott esetben emberi jóváhagyással, erős naplózással és futásidejű útválasztási jogosultság nélkül.

A számlázási hitelesítő adatok is különválasztást érdemelnek. A számlákat egyeztető jelentéskészítési feladat nem képes befejezéseket generálni, és a futásidejű következtetési kulcs nem lehet az egyetlen módja a használati jelentések lekérésének. Ha egy szolgáltató nem kínál finomszemcsés szétválasztást, kompenzáljon az átjáróban: izolálja a hitelesítő adatokat, korlátozza, hogy melyik belső szolgáltatási identitás kérheti le, és minden használatot naplózzon.

Javaslat: tegye a hitelesítő adatosztályt szigorú engedélyezési határré, ne pedig címkévé. A futásidejű diszpécser nem kérheti a rendszergazdai hitelesítő adatok visszafejtését, még akkor sem, ha egy konfigurációs hiba hivatkozik az azonosítójára.

Hitelesítőadat-kiválasztó házirend-motor létrehozása

A hitelesítő adatok kiválasztásának azután kell megtörténnie, hogy az átjáró hitelesíti a későbbi hívót, és mielőtt bármilyen szolgáltatói hívást kísérel meg. A házirend-motornak több bemenethez kell csatlakoznia:

• Bérlőazonosító és a későbbi API-kulcs hatóköre.
• A kért modellprofil vagy szolgáltató-specifikus modellazonosító.
• Végpont-képesség: csevegés, beágyazás, kép, hang, köteg, fájlok, eszközök vagy adminisztrátori automatizálás.
• Adatmegőrzési és tartózkodási követelmények.
• Költségkeret, hitelfoglalás és költséghely.
• Drátakorlát állapota és kvótanyomás.
• Hitelesítési adatok metaadatai, állapota, környezete és bérlői kötés.

A motornak a három eredmény egyikét kell visszaadnia: engedélyezi a kiválasztott hitelesítési adatokkal, elutasítja házirend okával vagy jóváhagyást kér. Az elutasításoknak elég pontosaknak kell lenniük ahhoz, hogy az operatív csapatok megoldhassák a problémát anélkül, hogy titkos anyagokat fednének fel a fejlesztőknek.

Példadöntés:

{
  "bérlő_azonosítója": "bérlő_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "futási idő",
    "environment": "termelés",
    "bérlő_binding": "bérlő_42",
    "allowed_model_family": "szöveg",
    "health_status": "egészséges"
  },
  "decision": "engedélyezés",
  "credential_id": "cred_8f2...",
  "audit_reason": "A bérlő BYOK hitelesítő adatai megfelelnek a futásidejű szöveges profilnak és az adatszabályzatnak"
}

Ne alkalmazza a tartalékot „próbálja meg a következő kulcsot”. A tartalékszabályzatot újra kell futtatni. A megosztott platform hitelesítő adatai érvényesek a szolgáltatói hozzáféréshez, de érvénytelenek a csak BYOK-t használó ügyfelek számára. Előfordulhat, hogy egy másik projektben lévő hitelesítő adat kvótával rendelkezik, de sértheti a költséghozzárendelési vagy -megőrzési követelményeket.

A BYOK-ot bérlői hozzáférésként kezelje, nem szabad kapacitásként

A BYOK megváltoztatja a bizalmi modellt. Az ügyfél megadta a hitelesítési adatokat, így a forgalmát a szolgáltatói fiókjára terhelhetik, szabályozhatják vagy elkülöníthetik a szolgáltatói fiókjából. Ezt a hitelesítő adatot az ügyfél bérlőjéhez és a szolgáltató fiókjához kell kötni.

Ajánlott BYOK-vezérlők:

• Egy tárolórekord ügyfelenként, szolgáltatónként, fiókhatáronként és környezetenként.
• Nincs bérlői átirányítás a BYOK hitelesítő adatain keresztül.
• Nem használható megosztott tartalék kapacitásként, hacsak az ügyfél kifejezetten nem engedélyezi.
• Az ügyfél által látható állapot, amely nem fedi fel a nyers kulcsot.
• Külön rotációs munkafolyamat, amely lehetővé teszi az ügyfél számára, hogy cserét adjon hozzá, mielőtt a régi kulcsot letiltják.
• Egyértelmű hozzárendelés a használati elemzésben és a számlákban: átjáró bérlő, szolgáltatói fiók határa, hitelesítő adatok azonosítója, modellprofil és kérés nyomkövetési azonosítója.

Az ügynökségek, a viszonteladók és a Partner API automatizálása számára a BYOK bonyolultabb lehet, mivel egy szolgáltatás programozottan biztosíthatja a bérlőket és a hitelesítési adatokat. Ugyanez a szabály továbbra is érvényes: az automatizálás importálhat és köthet hitelesítő adatokat, de nem homályosíthatja el a bérlő tulajdonjogát.

Futtatás előtti állapotellenőrzések hozzáadása kiszivárogtatás nélkül

A hitelesítési adatok számos okból meghibásodhatnak: visszavont kulcs, rossz munkaterület, hiányzó modellelérés, letiltott számlázás, kvóta kimerülés, végpont korlátozás, regionális irányelvek eltérése vagy szolgáltatói leállás. Ennek felfedezése csak a gyártási kérés megérkezése után zajos eseményeket eredményez.

Használjon állapotellenőrzéseket, amelyek az ügyfelek értesítése nélkül ellenőrzik a képességet. A szintetikus ellenőrzés egy minimális végpontot hívhat meg, adott esetben listázhatja az engedélyezett modelleket, vagy ártalmatlan rögzített promptot küldhet, ha ez az egyetlen praktikus lehetőség. Tartsa ezeket a csekkeket olcsón, árkorlátozottan, és szintetikus forgalomként címkézze fel a telemetria és a számlázás területén.

Az állapotfelmérésnek le kell futnia:

• A hitelesítési adatok importálásakor.
• Mielőtt engedélyezne egy hitelesítő adatot az éles útválasztáshoz.
• A szolgáltató oldali korlátozások módosítása után.
• A forgás átkapcsolása közben.
• Időszakonként a gyártási jogosultsággal rendelkező hitelesítő adatokért.

Kiváltás: az automatikus ellenőrzések korán elkapják a lejárt vagy nem megfelelő hatókörű kulcsokat, de a rosszul megtervezett ellenőrzések szükségtelen szolgáltatói hívásokat, számlázási zajt vagy téves riasztásokat okozhatnak a szolgáltatói leállások során. Tárolja az állapoteredményt időbélyeggel, szolgáltatói hibaosztályokkal, tesztelt végponttal és tesztelt modellcsaláddal. Ne tároljon titkos értékeket vagy érzékeny promptokat.

Két foglalattal foroghat, nem pedig egy kockázatos cserével

A hitelesítő adatok elforgatása nem lehet törlés és imádkozás művelet. Használjon kéthelyes forgatási modellt:

1. Csere hitelesítő adat importálása inaktívként, teljes metaadatokkal és tulajdonossal.
2. Futtasson szintetikus állapotellenőrzéseket a tervezett végpontokhoz, modellcsaládokhoz és fiókhatárokhoz.
3. Engedélyezze az árnyékjogosultságot a biztonságos szintetikus vagy alacsony kockázatú forgalom egy kis szeletéhez, ahol lehetséges.
4. Fokozatosan állítsa át az éles forgalmat a régi hitelesítő adatokról az új hitelesítő adatokra.
5. Kövesse nyomon a hibákat, a várakozási időt, a kvótát és a költséghozzárendelést a hitelesítési adatok azonosítója alapján.
6. A régi hitelesítési adatok visszaállítása, ha az új hitelesítési adat stabil.
7. Visszavonja a régi hitelesítési adatokat a szolgáltatónál, és jelölje meg a trezorrekordot visszavontként.
8. Győződjön meg arról, hogy visszavonás után nem történik-e visszafejtés vagy szolgáltatói hívás a régi hitelesítő adatokkal.

A rotációs határidőknek láthatónak kell lenniük a műveleti nézetekben és a riasztásokban. A vészhelyzeti rotációnak rövidebb útra van szüksége: tiltsa le a hitelesítési adatokat, blokkolja az útválasztást, engedélyezze a jóváhagyott cserét, és őrizze meg az összes ellenőrzési rekordot az incidensek felülvizsgálatához.

A szolgáltatói kulcsok korlátozása ott, ahol a szolgáltató támogatja

Az átjáróházirend szükséges, de a szolgáltató oldali korlátozások csökkentik a kitörési sugarat, ha egy kulcsot feltörnek vagy visszaélnek vele. A Gemini és más felhőplatform API-kulcsok esetén használjon API/szolgáltatás korlátozásokat és megfelelő alkalmazáskorlátozásokat, ahol elérhető. A szolgáltatói projektek, munkaterületek és szolgáltatásfiókok esetében kerülje a széles körű szervezeti jogosultságokat, ha elegendő egy projektre kiterjedő futásidejű kulcs.

Javaslat: minden hitelesítési osztályhoz tartson fenn egy szolgáltatói korlátozási ellenőrzőlistát. Az ellenőrzőlista az import-jóváhagyás és a rotációs jóváhagyás részét kell, hogy képezze, és ne egy különálló biztonsági feladat, amely nyomás alatt kihagyható.

Kiváltás: a szolgáltatói oldali korlátozások működési többletköltséget jelentenek. Az új végpontok, modellcsaládok, régiók vagy automatizálási szolgáltatások házirend- és korlátozásmódosítást igényelhetnek. Ez jobb, mint egy szivárgás után felfedezni, hogy egy kulcs egy megosztott projektben minden munkaterheléshez hozzáférhet.

Vezessen egy csak hozzáfűzést tartalmazó hitelesítési naplót

Az ellenőrzési nyomvonalnak meg kell válaszolnia, hogy ki importált egy hitelesítő adatot, mit tehetett, mely útválasztási döntések választották ki, mikor nem sikerült, és mikor forgatták el vagy vonták vissza.

Naplózza ezeket az eseményeket:

• A hitelesítési adatok létrehozva vagy importálva.
• Módosultak a metaadatok, beleértve az engedélyezett végpontokat, a bérlői összerendelést vagy az adatszabályzatot.
• Az állapotfelmérés végrehajtása és az eredmény rögzítése.
• A kéréshez az útválasztási szabályzat által kiválasztott hitelesítési adat.
• A hitelesítő adatok visszafejtése belső szolgáltatási identitás által kért.
• A szolgáltató hívása hitelesítési, engedélyezési, kvóta- vagy korlátozási hiba miatt meghiúsult.
• A forgatás megkezdődött, a forgalom eltolódott, a régi hitelesítő adatok visszavonva.
• Vészletiltás engedélyezve vagy törölve.
• Adminisztrátor vagy üvegtörő hitelesítő adatok elérve.

Ne adjon meg nyers hitelesítő adatokat az ellenőrzési eseményekben. Használja a hitelesítő adatok azonosítóit, a szolgáltatói fiókok határait, a kérés nyomkövetési azonosítóit, a szereplők identitását és az irányelvekkel kapcsolatos döntés okait. Nagy volumenű futásidejű forgalom esetén részletes visszafejtési telemetria mintát vehet igénybe, de az útvonalválasztás és a költség-hozzárendelés kellően teljes marad a számlázáshoz és az incidensekre való reagáláshoz.

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

• Hozzon létre egy hitelesítő adatok taxonómiáját, és utasítsa el a nem besorolt importokat.
• Helyezze át az összes szolgáltatói titkot egy dedikált titkosított tárolóba.
• Az útválasztási metaadatokat a titkos anyagoktól elkülönítve tárolja.
• Tegye külön engedélyezési osztályokat a futásidejű, adminisztrátori, számlázási, kiértékelési és BYOK hitelesítési adatokhoz.
• A BYOK hitelesítő adatait kösse a bérlői és szolgáltatói fiók származásához.
• Kérje meg a házirend-motor jóváhagyását, mielőtt bármilyen korábbi hitelesítő adatot kiválasztana.
• Futtasson azonnali, biztonságos állapotellenőrzést a gyártási jogosultság előtt.
• Használjon kéthelyes rotációt a forgalom fokozatos eltolásával és a szolgáltató oldali visszavonásával.
• Alkalmazzon szolgáltatói korlátozásokat, ahol elérhető.
• Csak hozzáfűzhető ellenőrzési naplók fenntartása az importálás, a használat, a hibák, a forgatás és a visszavonás során.
• Az adminisztrátori hitelesítési adatokat tartsa az üvegtörő vezérlők mögött: rövid TTL, névvel ellátott jóváhagyás, erős naplózás, futásidejű használat nélkül.

Intézhető következtetés

Kezdje azzal, hogy leltározza meg az átjáró által jelenleg használt összes upstream szolgáltatói hitelesítő adatot, szkripteket, CI-feladatokat, kiértékelési kábeleket és partnerautomatizálást. Mindegyikhez rendeljen hozzá egy osztályt, tulajdonost, szolgáltatói fiókhatárt, bérlői kötést, engedélyezett végpontokat, engedélyezett modellcsaládokat, rotációs határidőt és vészletiltás állapotát. Mindent, amit nem tud besorolni, le kell tiltani vagy karanténba kell helyezni, amíg nincs egyértelmű célja.

Ezután kényszerítsen ki egy architekturális szabályt: a későbbi fejlesztők átjáró-hatókörű kulcsokat kapnak; az átjáró egyedül vezérli a upstream szolgáltatói hozzáférést. Ezzel a szétválasztással megőrizheti a legkevesebb jogosultságot, a bérlői hozzárendelést, a számlázás pontosságát, az adatpolitikai útválasztást és a biztonságos automatizálást, még akkor is, ha a szolgáltatók, a projektek, a munkaterületek és a BYOK-ügyfelek szaporodnak.

Kapcsolódó olvasmányok

• csapatközi API-kulcskezelés és szivárgásra adott válasz
• adatmegőrzésre alkalmas útválasztási irányelvek
• főkönyvi és költség-hozzárendelési vezérlők