Trezorji poverilnic ponudnika za prehode umetne inteligence z več modeli: ločen dostop med izvajanjem, skrbništvom, obračunavanjem in BYOK

navzgor API in poverilnice ponudnika navzgor rešujejo različne težave. Ključ razvijalca, ki ga izda vaš prehod, identificira aplikacijo, ekipo, najemnika, proračun in kontekst pravilnika. Ključ ponudnika navzgor omogoča prehodu porabo denarja in dostop do modelov v računu ponudnika. Če jih obravnavamo kot isto vrsto skrivnosti, ekipe na koncu dobijo en neomejen ključ v skupnem projektu, skrbniške poverilnice v izvajalnih storitvah in nimajo zanesljivega načina za odgovor, kateri najemnik je povzročil katero bremenitev na strani ponudnika.

Praktični vzorec je shramba poverilnic ponudnika: namenska nadzorna ravnina za uvažanje, razvrščanje, shranjevanje, izbiranje, rotacijo in revizijo poverilnic navzgor. Moral bi biti za usmerjevalnikom, knjigo zaračunavanja, mehanizmom pravilnika in delovnim tokom operacij – ne znotraj kode aplikacije, konfiguracijskih datotek modela, zapisov najemnikov ali analitičnih dogodkov.

Težava z bralnikom: poverilnice navzgor postanejo nevidna infrastruktura

Večina uvedb z več modeli se začne s preprostim ciljem: usmerite eno OpenAIzdružljivo zahtevo do najboljšega razpoložljivega ponudnika. Nato se prikaže več računov: en projekt ponudnika za proizvodnjo, drugi za vrednotenje, Anthropic delovni prostor za poslovno enoto, Google projekt v oblaku za Gemini in več ključev, ki jih zagotovijo stranke za pogodbe BYOK.

Tveganje ni le skrivno uhajanje. Gre za izgubo avtorizacijskega konteksta. Veljavni ključ ponudnika je morda tehnično sposoben poklicati končno točko, vendar mora prehod še vedno vedeti, ali je ta ključ dovoljen za tega najemnika, to družino modelov, to politiko hrambe podatkov, ta proračun, to regijo in to pot avtomatizacije.

Dejstvo: platforme ponudnikov razkrivajo različne meje računov in vrste poverilnic. OpenAI dokumenti projektov in storitvenih računov ter privzeta ključna dovoljenja storitvenega računa API za dostop za branje in pisanje za API vire projekta. OpenAI prav tako izpostavi skrbniške API ključne objekte ločeno od običajne uporabe projekta/izvajalnega okolja API. Anthropic dokumentira delovne prostore kot organizacijsko mejo in navaja, da končne točke Admin API zahtevajo ključe Admin API, ki se razlikujejo od standardnih ključev API; Anthropic tudi ugotavlja, da so ključi API vezani na delovni prostor, kjer so ustvarjeni, in jih ni mogoče premikati med delovnimi prostori. Dokumentacija Google Gemini API ključa pravi, da je vsak Gemini API ključ povezan s Google projektom v oblaku in priporoča API omejitve za zmanjšanje škode, če je ključ ogrožen.

Priporočilo: ne ustvarite enega splošnega polja »provider_key« in ga kličite dokončano. Zgradite inventar poverilnic, ki ohranja meje, specifične za ponudnika, hkrati pa prehodu izpostavlja normaliziran model pravilnika.

Določite taksonomijo poverilnic, preden sprejmete ključe

Trezor mora zavrniti dvoumne poverilnice. V času uvoza mora operater ali potek dela za avtomatizacijo razvrstiti poverilnico. Uporabite vsaj te kategorije:

• Poverilnice sklepanja med izvajanjem:, ki jih uporablja prehod za klicanje končnih točk sklepanja modela, kot so klepet, odgovori, vdelave, moderiranje, prepisovanje ali ustvarjanje slik, odvisno od podpore ponudnika.
• Poverilnice za avtomatizacijo skrbnika: uporabljajo se za upravljanje organizacij na strani ponudnika, delovnih prostorov, projektov, uporabnikov, ključev ali upravnih virov. Te nikoli ne smejo biti na poti zahteve med izvajanjem.
• Poverilnice za obračunavanje in poročanje: se uporabljajo za pridobivanje poročil o uporabi, računih, stroških ali organizaciji, kjer ponudniki podpirajo te API-je. Ločite jih od sklepnih ključev, da opravila poročanja ne morejo ustvariti uporabe modela.
• Poverilnice samo za ocenjevanje: uporabljajo se v delovnih tokovih primerjalnega preizkusa, zagotavljanja kakovosti, selitve ali uprizarjanja. Imeti morajo nizke kvote, jasne okoljske oznake in nobene primernosti za nadomestno proizvodnjo.
• Poverilnice stranke BYOK: ključi, ki jih zagotovi stranka, vezani na določenega najemnika, račun ponudnika, pogodbo in politiko podatkov. Ne bi smeli biti združeni v skupno usmerjanje, razen če se stranka izrecno odloči za to.

Ta taksonomija ni samo dokumentacija. Spodbujati bi moral nadzor dostopa, primernost usmerjanja, opozarjanje in delovne tokove rotacije. Če je poverilnica uvožena brez kategorije, lastnika, meje računa ponudnika in dovoljene uporabe, mora ostati onemogočena.

Shranjujte skrivnosti v trezorju, ne v zapisih o izdelkih

Trezor mora biti edina komponenta, ki lahko dešifrira poverilnice navzgor. Drugi sistemi lahko shranjujejo reference, zgoščene vrednosti, statusna polja in metapodatke pravilnika, ne pa tudi same vrednosti poverilnice.

Ne shranjujte zgornjih skrivnosti na teh mestih

• Vrstice profila najemnika.
• Konfiguracijske datoteke za usmerjanje modela.
• Pozivni dnevniki ali razponi sledenja.
• Koristne obremenitve dogodkov Analytics.
• Spremenljivke CI, namenjene razvijalcem.
• Vstopnice za podporo, orodja za klepet ali posnetki zaslona.

Uporabna oblika oboka ima dve ravnini. Skrivno letalo shranjuje šifrirano gradivo poverilnic in strogo nadzoruje operacije dešifriranja. metapodatkovna ravnina shranjuje atribute, ki niso tajni in jih uporabljata usmerjanje in upravljanje. Usmerjevalnik bi običajno potreboval samo ID poverilnice in kratkotrajno iskanje skrivnosti v pomnilniku ob času odpreme, ne pa širokega dostopa do baze podatkov do vsakega ključa ponudnika.

Zaščitite trezor kot infrastrukturo visoke vrednosti: šifriranje ovojnice ali upravljani KMS, stroge identitete storitev, postopki za razbijanje stekla, testiranje varnostnega kopiranja in obnavljanja, pregled dostopa in opozarjanje na nenavaden obseg dešifriranja. Centralni trezor poenostavlja upravljanje, vendar tudi koncentrira tveganje. To je kompromis.

Pripni metapodatke pravilnika vsaki poverilnici

Model metapodatkov mora biti dovolj ekspliciten, da se lahko prehod odloči, ali je poverilnica primerna, preden se dotakne končne točke ponudnika.

Praktični zapis poverilnic vključuje:

• credential_id: notranji nespremenljivi identifikator.
• ponudnik: OpenAI, Anthropic, Gemini, Azure OpenAI ali drug adapter.
• provider_account_boundary: organizacija, projekt, delovni prostor, projekt v oblaku, naročnina ali enakovredno.
• credential_class: čas izvajanja, skrbnik, obračunavanje, vrednotenje ali BYOK.
• okolje: produkcija, uprizarjanje, razvoj, vrednotenje, peskovnik.
• tenant_binding: skupna poverilnica platforme, en najemnik, skupina najemnikov ali najemnik BYOK stranke.
• allowed_model_families: na primer ustvarjanje besedila, vdelave, vizija, slika, zvok ali specifični profili modela.
• allowed_endpoints: normalizirane zmogljivosti prehoda, preslikane na končne točke ponudnika.
• data_policy: dovoljen razred zadrževanja, razred beleženja, zahteva glede stalnega prebivališča in omejitve funkcij.
• budget_scope: stroškovno mesto, stranka preprodajalca, notranji oddelek ali pogodba.
• lastnik: imenovana ekipa ali odgovorna oseba.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: neznano, zdravo, poslabšano, nepooblaščeno, quota_exhausted, onemogočeno.
• emergency_disable: takojšnja blokada usmerjanja, neodvisna od običajnega stanja pravilnika.

Ohranite ta model nevtralen glede ponudnika, vendar ne izbrišite resničnosti ponudnika. Ključ Anthropic, vezan na delovni prostor, in ključ Gemini, povezan s projektom v oblaku Google, nista zamenljiva samo zato, ker lahko oba ustvarita besedilo. Prehod potrebuje to poreklo za revizije, povratne bremenitve in varno samodejni preklop.

Ločen dostop med izvajanjem, skrbništvom in zaračunavanjem

Najpomembnejše pravilo je preprosto: ključ, ki se uporablja za sklepanje med izvajanjem, ne sme upravljati organizacij ponudnikov, delovnih prostorov, uporabnikov, projektov ali upravnih virov.

Promet med izvajanjem je velik in je izpostavljen največji operativni površini. Prehaja skozi usmerjevalnike zahtev, logiko ponovnih poskusov, upravljalnike pretakanja, adapterje modelov in delovne tokove incidentov. Skrbniške poverilnice so redke in imajo velik vpliv. Morali bi živeti za ločeno potjo odobritve s kratkimi TTL-ji, poimenovano človeška odobritev, kjer je primerno, močnim beleženjem in brez primernosti za usmerjanje med izvajanjem.

Tudi poverilnice za obračun si zaslužijo ločitev. Opravilo poročanja, ki usklajuje račune, ne bi smelo generirati zaključkov, ključ za sklepanje med izvajanjem pa ne bi smel biti edini način za pridobivanje poročil o uporabi. Če ponudnik ne ponuja natančnega ločevanja, to nadomestite v prehodu: izolirajte poverilnico, omejite, katera notranja identiteta storitve jo lahko pridobi, in zabeležite vsako uporabo.

Priporočilo: naj bo razred poverilnic trda avtorizacijska meja, ne oznaka. Odpremnik med izvajanjem ne bi smel zahtevati dešifriranja skrbniške poverilnice, tudi če se napaka v konfiguraciji sklicuje na njen ID.

Izdelajte mehanizem pravilnika za izbiro poverilnic

Izbira poverilnice se mora zgoditi po tem, ko prehod overi pristnost nižjega klicatelja in preden se izvaja kakršen koli poskus klica ponudnika. Mehanizem pravilnika bi moral združevati več vhodov:

• ID najemnika in nadaljnji API obseg ključa.
• Zahtevani profil modela ali ID modela, specifičen za ponudnika.
• Zmogljivost končne točke: klepet, vdelave, slike, zvok, paket, datoteke, orodja ali skrbniška avtomatizacija.
• Zahteve glede hrambe podatkov in stalnega prebivališča.
• Proračun, kreditna rezervacija in stroškovno mesto.
• Stanje omejitve hitrosti in pritisk na kvoto.
• Metapodatki poverilnic, zdravje, okolje in vezava najemnika.

Motor mora vrniti enega od treh rezultatov: dovoli z izbrano poverilnico, zavrni z razlogom pravilnika ali zahtevaj odobritev. Zavrnitve morajo biti dovolj natančne, da lahko operativne ekipe odpravijo težavo, ne da bi razvijalcem razkrile tajno gradivo.

Primer odločitve:

{
  "tenant_id": "tenant_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "environment": "production",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "healthy"
  },
  "decision": "allow",
  "credential_id": "cred_8f2...",
  "audit_reason": "tenant BYOK credential matches runtime text profile and data policy"
}

Ne izvajajte nadomestne možnosti kot »poskusite naslednji ključ«. Varnostni pravilnik mora znova zagnati. Poverilnica skupne platforme je lahko veljavna za dostop ponudnika, vendar neveljavna za stranko, ki uporablja samo BYOK. Poverilnica v drugem projektu ima lahko kvoto, vendar lahko krši zahteve glede dodeljevanja stroškov ali hrambe.

Obravnavajte BYOK kot dostop v lasti najemnika, ne kot proste zmogljivosti

BYOK spremeni model zaupanja. Stranka je priskrbela poverilnico, tako da se lahko njen promet zaračuna, upravlja ali izolira znotraj računa njenega ponudnika. Ta poverilnica mora biti vezana na poreklo računa stranke najemnika in ponudnika.

Priporočeni kontrolniki BYOK:

• En zapis trezorja na stranko, ponudnika, mejo računa in okolje.
• Brez usmerjanja med najemniki prek poverilnic BYOK.
• Ne uporablja se kot skupna rezervna zmogljivost, razen če se stranka izrecno odloči za to.
• Stranki vidno zdravstveno stanje, ki ne razkrije neobdelanega ključa.
• Ločen potek dela za rotacijo, ki stranki omogoča dodajanje nadomestnega, preden je stari ključ onemogočen.
• Jasno dodeljevanje v analitiki uporabe in računih: najemnik prehoda, meja računa ponudnika, ID poverilnice, profil modela in ID sledenja zahteve.

Za avtomatizacijo agencij, prodajnih posrednikov in partnerjev API je BYOK lahko bolj zapleten, ker lahko storitev najemnike in poverilnice zagotovi programsko. Še vedno velja isto pravilo: avtomatizacija lahko uvozi in veže poverilnice, vendar ne sme zamegliti lastništva najemnika.

Dodajte preglede stanja pred tiskom brez uhajanja pozivov

Poverilnica lahko ne uspe iz več razlogov: preklican ključ, napačen delovni prostor, manjkajoči dostop do modela, onemogočeno zaračunavanje, izčrpanost kvote, omejitev končne točke, neusklajenost regionalne politike ali izpad ponudnika. Odkritje, da šele potem, ko prispe produkcijska zahteva, povzroči hrupne incidente.

Uporabite preglede stanja, ki potrjujejo zmogljivost brez pošiljanja pozivov strankam. Sintetično preverjanje lahko pokliče minimalno končno točko, navede dovoljene modele, kjer je primerno, ali pošlje neškodljiv fiksni poziv, če je to edina praktična možnost. Naj bodo ti pregledi poceni, tarifno omejeni in označeni kot sintetični promet v telemetriji in zaračunavanju.

Pregledi zdravstvenega stanja bi se morali izvajati:

• Pri uvozu poverilnic.
• Preden omogočite poverilnico za produkcijsko usmerjanje.
• Po spremembah omejitev na strani ponudnika.
• Med preklopom vrtenja.
• Občasno za poverilnice s primernostjo do produkcije.

Kompromis: samodejna preverjanja zgodaj ujamejo potekle ključe ali ključe s premajhnim obsegom, vendar lahko slabo zasnovana preverjanja povzročijo nepotrebne klice ponudnika, hrup pri zaračunavanju ali lažne alarme med izpadi ponudnika. Shranite rezultat zdravja s časovnim žigom, razredom napak ponudnika, preizkušeno končno točko in preizkušeno družino modelov. Ne shranjujte skrivnih vrednosti ali občutljivih pozivov.

Izmenjava z dvema mestoma, ne z eno tvegano zamenjavo

Rotacija poverilnic ne bi smela biti operacija brisanja in molitve. Uporabite model vrtenja z dvema režama:

1. Uvozi nadomestno poverilnico kot neaktivno, s polnimi metapodatki in lastnikom.
2. Zaženite sintetične zdravstvene preglede za predvidene končne točke, družine modelov in mejo računa.
3. Omogoči primernost za senčenje za majhen del varnega sintetičnega prometa ali prometa z nizkim tveganjem, kjer je to primerno.
4. Postopno prestavite produkcijski promet s stare poverilnice na novo.
5. Nadzirajte napake, zakasnitev, kvoto in dodeljevanje stroškov glede na ID poverilnice.
6. Zamrzni nadomestno uporabo stare poverilnice, ko bo nova poverilnica stabilna.
7. Prekličite staro poverilnico pri ponudniku in označite zapis trezorja kot preklican.
8. Preverite, da po preklicu ne pride do dešifriranja ali klicev ponudnika prek stare poverilnice.

Rotirni roki morajo biti vidni v pogledih operacij in opozorilih. Rotacija v sili potrebuje krajšo pot: onemogočite poverilnice, blokirajte usmerjanje, omogočite odobreno zamenjavo in ohranite vse revizijske zapise za pregled incidentov.

Omeji ponudnikove ključe, kjer jih ponudnik podpira

Politika prehoda je potrebna, vendar omejitve na strani ponudnika zmanjšajo radij eksplozije, če je ključ ogrožen ali zlorabljen. Za ključe Gemini in druge platforme v oblaku API uporabite omejitve API/service in ustrezne omejitve aplikacij, kjer so na voljo. Za projekte, delovne prostore in storitvene račune ponudnika se izogibajte širokim organizacijskim privilegijem, ko zadostuje ključ izvajalnega okolja v obsegu projekta.

Priporočilo: vzdržujte kontrolni seznam omejitev na strani ponudnika za vsak razred poverilnic. Kontrolni seznam bi moral biti del odobritve uvoza in rotacije, ne pa ločena varnostna naloga, ki bi jo lahko pod pritiskom preskočili.

Kompromis: omejitve na strani ponudnika dodajajo operativne stroške. Nove končne točke, družine modelov, regije ali funkcije avtomatizacije lahko zahtevajo spremembe pravilnika in omejitev. To je bolje kot po uhajanju odkriti, da lahko en ključ dostopa do vseh delovnih obremenitev v skupnem projektu.

Hranite dnevnik revizije poverilnic samo za dodajanje

Revizijska sled bi morala odkriti, kdo je uvozil poverilnico, kaj je smel narediti, katere odločitve o usmerjanju so jo izbrale, kdaj ni uspelo in kdaj je bila spremenjena ali preklicana.

Zapiši te dogodke:

• Poverilnica ustvarjena ali uvožena.
• Metapodatki spremenjeni, vključno z dovoljenimi končnimi točkami, vezavo najemnika ali politiko podatkov.
• Izveden zdravstveni pregled in zabeležen rezultat.
• Poverilnica, izbrana s pravilnikom usmerjanja za zahtevo.
• Dešifriranje poverilnice zahteva notranja identiteta storitve.
• Klic ponudnika ni uspel zaradi napake pri preverjanju pristnosti, avtorizacije, kvote ali omejitve.
• Rotacija se je začela, promet preusmerjen, stare poverilnice preklicane.
• Onemogočanje v sili je omogočeno ali izbrisano.
• Dostop do skrbniške ali zlomljive poverilnice.

Ne vstavljajte neobdelanih vrednosti poverilnic v revizijske dogodke. Uporabite ID-je poverilnic, meje računa ponudnika, ID-je sledenja zahtevam, identitete igralcev in razloge za odločitev glede pravilnika. Za promet v času izvajanja velikega obsega lahko vzorčite podrobno dešifrirano telemetrijo, vendar morata izbira usmerjanja in dodeljevanje stroškov ostati dovolj popolna za zaračunavanje in odziv na incident.

Kontrolni seznam za implementacijo

• Ustvarite taksonomijo poverilnic in zavrnite nerazvrščene uvoze.
• Prenesite vse skrivnosti ponudnika v namenski šifrirani trezor.
• Shranjujte metapodatke o usmerjanju ločeno od tajnega gradiva.
• Naredite ločene avtorizacijske razrede za čas izvajanja, skrbništvo, obračunavanje, ocenjevanje in BYOK.
• Povežite poverilnice BYOK z izvorom računa najemnika in ponudnika.
• Zahtevaj odobritev mehanizma pravilnika, preden izberete katero koli poverilnico v zgornjem toku.
• Zaženi takojšnje varne zdravstvene preglede pred primernostjo proizvodnje.
• Uporabite rotacijo z dvema mestoma s postopnim premikom prometa in preklicem na strani ponudnika.
• Uporabite omejitve na strani ponudnika, kjer koli so na voljo.
• Vzdrževanje revizijskih dnevnikov samo za dodajanje za uvoz, uporabo, napake, rotacijo in preklic.
• Hrani skrbniške poverilnice za kontrolniki razbitega stekla: kratek TTL, imenovana odobritev, močno beleženje, brez uporabe izvajalnega časa.

Dejanski sklep

Začnite s popisom vseh poverilnic ponudnika navzgor v verigi, ki jih trenutno uporabljajo prehod, skripti, opravila CI, ocenjevalni pasovi in partnerska avtomatizacija. Za vsakega dodelite razred, lastnika, mejo računa ponudnika, vezavo najemnika, dovoljene končne točke, dovoljene družine modelov, rok rotacije in stanje onemogočitve v sili. Vse, česar ne morete razvrstiti, je treba onemogočiti ali dati v karanteno, dokler nima jasnega namena.

Nato uveljavite eno arhitekturno pravilo: nadaljnji razvijalci prejmejo ključe v obsegu prehoda; sam prehod nadzira dostop ponudnika navzgor. Ta ločitev vam omogoča, da ohranite najmanj privilegijev, dodeljevanje najemnikov, natančnost zaračunavanja, usmerjanje podatkovnih pravilnikov in varno avtomatizacijo, tudi ko se ponudniki, projekti, delovni prostori in stranke BYOK množijo.

Sorodno branje

• skupinsko API upravljanje ključev in uhajanje odgovor
• pravilniki usmerjanja, ki upoštevajo hrambo podatkov
• kontrole obračunske knjige in dodeljevanja stroškov