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

Ključi vmesnika API za nadaljnji tok in poverilnice ponudnika navzgor po toku 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, dobijo ekipe 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. Nahajati se mora za usmerjevalnikom, knjigo obračunavanja, mehanizmom pravilnika in potekom dela – 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 zahtevo, združljivo z OpenAI, do najboljšega razpoložljivega ponudnika. Nato se prikaže več računov: projekt enega ponudnika za proizvodnjo, drugi za vrednotenje, delovni prostor Anthropic za poslovno enoto, projekt Google Cloud za Gemini in več ključev, ki jih zagotovijo stranke, za pogodbe BYOK.

Tveganje ni le uhajanje skrivnosti. 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 dokumentira projekte in storitvene račune ter ključna dovoljenja API-ja za storitvene račune privzeto omogočajo dostop za branje in pisanje za vire API-ja projekta. OpenAI prav tako izpostavi ključne objekte Admin API ločeno od običajne uporabe API-ja za projekt/izvajanje. Anthropic dokumentira delovne prostore kot organizacijsko mejo in navaja, da končne točke skrbniškega API-ja zahtevajo ključe skrbniškega API-ja, ki se razlikujejo od standardnih ključev API-ja; Anthropic tudi ugotavlja, da so ključi API-ja vezani na delovni prostor, kjer so ustvarjeni, in jih ni mogoče premikati med delovnimi prostori. Googlova dokumentacija o ključu Gemini API pravi, da je vsak ključ Gemini API povezan s projektom Google Cloud in priporoča omejitve API-ja 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 popis 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: uporablja jih 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: uporabljajo se 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 jih primerjalno preverjanje, zagotavljanje kakovosti, selitev ali uprizarjanje potekov dela. Imeti morajo nizke kvote, jasne okoljske oznake in nobene primernosti za rezervno 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 izdelkov

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.

Na teh mestih ne shranjujte zgornjih skrivnosti

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

Uporaben dizajn trezorja 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 le ID poverilnice in kratkotrajno iskanje skrivnosti v pomnilniku ob času pošiljanja, 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 razbitja 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.

Priložite 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, uprizoritev, 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 hrambe, razred beleženja, zahteva glede stalnega prebivališča in omejitve funkcij.
• budget_scope: stroškovno mesto, stranka prodajalca, notranji oddelek ali pogodba.
• lastnik: imenovana ekipa ali odgovorna oseba.
• created_at, expires_at, rotation_due_at, last_used_at.
• zdravstveno_stanje: neznano, zdravo, poslabšano, nepooblaščeno, kvota_izčrpana, onemogočeno.
• emergency_disable: takojšnja blokada usmerjanja neodvisno od običajnega stanja pravilnika.

Ta model naj bo nevtralen glede ponudnika, vendar ne izbrišite resničnosti ponudnika. Ključ Anthropic, vezan na delovni prostor, in ključ Gemini, vezan na projekt Google Cloud, 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 usmerjanja 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 in ne oznaka. Odpremnik med izvajanjem ne bi smel zahtevati dešifriranja za skrbniško poverilnico, 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 klicatelja navzdol in preden se poskusi klicati ponudnik. Mehanizem pravilnika bi moral združevati več vhodov:

• ID najemnika in obseg ključa API-ja na nižji stopnji.
• 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": "najemnik_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_belging",
  "credential_requirements": {
    "razred": "izvajalni čas",
    "okolje": "proizvodnja",
    "tenant_binding": "najemnik_42",
    "allowed_model_family": "besedilo",
    "health_status": "zdravo"
  },
  "odločitev": "dovoli",
  "credential_id": "cred_8f2...",
  "audit_reason": "poverilnica BYOK najemnika se ujema s profilom besedila med izvajanjem in politiko podatkov"
}

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 spreminja 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 najemnika stranke 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 agencije, preprodajalce in avtomatizacijo API-jev za partnerje je BYOK lahko bolj zapleten, ker lahko storitev programsko zagotovi najemnike in poverilnice. Š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 obračunavanje, izčrpanost kvote, omejitev končne točke, neusklajenost regionalne politike ali izpad ponudnika. Odkritje tega šele potem, ko prispe produkcijska zahteva, povzroča 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.

Zdravstveni pregledi bi morali potekati:

• 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.

Rotirajte z dvema režama, ne z eno tvegano zamenjavo

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

1. Uvozite nadomestno poverilnico kot neaktivno, s polnimi metapodatki in lastnikom.
2. Izvedite sintetične preglede zdravja za predvidene končne točke, družine modelov in mejo računa.
3. Omogočite primernost za senčenje za majhen del varnega sintetičnega prometa ali prometa z nizkim tveganjem, kjer je to primerno.
4. Produkcijski promet postopoma preusmerite s stare poverilnice na novo.
5. Spremljajte 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 ni prišlo do dešifriranja ali klicev ponudnika prek stare poverilnice.

Rotirni roki bi morali 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 Gemini in druge ključe API platforme v oblaku uporabite omejitve API/storitev 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 odobritve rotacije, ne pa ločena varnostna naloga, ki jo lahko pod pritiskom preskočite.

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.

Zabeležite 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.

V revizijske dogodke ne postavljajte neobdelanih vrednosti poverilnic. 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 poverilnic za čas izvajanja, skrbništvo, obračunavanje, ocenjevanje in BYOK.
• Povežite poverilnice BYOK z izvorom računa najemnika in ponudnika.
• Zahtevajte odobritev mehanizma pravilnika, preden izberete katero koli poverilnico v zgornjem toku.
• Zaženite 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.
• Skrbniške poverilnice naj bodo 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, 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 klasificirati, je treba onemogočiti ali postaviti 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, čeprav se ponudniki, projekti, delovni prostori in stranke BYOK množijo.

Sorodno branje

• upravljanje ključev API-ja, usmerjeno v ekipo, in odziv na uhajanje
• pravilniki usmerjanja, ki upoštevajo hrambo podatkov
• kontrole obračunske knjige in pripisovanja stroškov