Trezory poverení poskytovateľa pre brány umelej inteligencie s viacerými modelmi: samostatný prístup k behu, správcovi, fakturácii a BYOK

Kľúče na odber API a poverenia poskytovateľa upstream riešia rôzne problémy. Kľúč vývojára vydaný vašou bránou identifikuje aplikáciu, tím, nájomníka, rozpočet a kontext politiky. Upstreamový kľúč poskytovateľa umožňuje bráne míňať peniaze a pristupovať k modelom na účte poskytovateľa. Zaobchádzanie s nimi ako s rovnakým druhom tajomstva je spôsob, akým tímy skončia s jedným neobmedzeným kľúčom v zdieľanom projekte, povereniami správcu v prevádzkových službách a neexistuje žiadny spoľahlivý spôsob, ako odpovedať, ktorý nájomca spôsobil ktorý poplatok na strane poskytovateľa.

Praktickým vzorom je trezor poverení poskytovateľa: vyhradená riadiaca rovina na import, klasifikáciu, ukladanie, výber, rotáciu a auditovanie prihlasovacích údajov. Mal by byť umiestnený za smerovačom, účtovnou knihou, nástrojom politiky a pracovným tokom operácií – nie v kóde aplikácie, konfiguračných súboroch modelu, záznamoch nájomníkov alebo analytických udalostiach.

Problém čitateľa: prihlasovacie údaje sa stanú neviditeľnou infraštruktúrou

Väčšina nasadení viacerých modelov začína jednoduchým cieľom: nasmerovať jednu OpenAI-kompatibilnú požiadavku k najlepšiemu dostupnému poskytovateľovi. Potom sa objavia ďalšie účty: jeden projekt poskytovateľa na produkciu, ďalší na hodnotenie, pracovný priestor Anthropic pre obchodnú jednotku, cloudový projekt Google pre Gemini a niekoľko kľúčov dodaných zákazníkom pre zmluvy BYOK.

Riziko nie je len tajný únik. Ide o stratu autorizačného kontextu. Platný kľúč poskytovateľa môže byť technicky schopný volať koncový bod, ale brána stále potrebuje vedieť, či je tento kľúč povolený pre tohto nájomníka, túto modelovú skupinu, túto politiku uchovávania údajov, tento rozpočet, tento región a túto cestu automatizácie.

Fakt: platformy poskytovateľov odhaľujú rôzne hranice účtov a typy poverení. OpenAI dokumentuje projekty a účty služieb a kľúčové povolenia účtu služby API predvolene umožňujú prístup na čítanie a zápis pre zdroje projektu API. OpenAI tiež odhaľuje kľúčové objekty správcu API oddelene od bežného používania projektu/runtime API. Anthropic dokumentuje pracovné priestory ako organizačnú hranicu a uvádza, že koncové body správcu API vyžadujú kľúče správcu API odlišné od štandardných kľúčov API; Anthropic tiež poznamenáva, že klávesy API sú prepojené s pracovným priestorom, kde sú vytvorené, a nemožno ich presúvať medzi pracovnými priestormi. Dokumentácia kľúča Google Gemini API hovorí, že každý kľúč Gemini API je spojený s cloudovým projektom Google a odporúča obmedzenia API na zníženie poškodenia v prípade narušenia kľúča.

Odporúčanie: nevytvárajte jedno všeobecné pole „provider_key“ a neoznačujte ho za hotové. Vytvorte inventár poverení, ktorý zachová hranice špecifické pre poskytovateľa a zároveň bráne vystaví model normalizovaných pravidiel.

Pred prijatím kľúčov definujte taxonómiu poverení

Sejf by mal odmietnuť nejednoznačné poverenia. V čase importu musí operátor alebo pracovný postup automatizácie klasifikovať poverenie. Použite minimálne tieto kategórie:

• Runtime inference credentials:používané bránou na volanie koncových bodov odvodenia modelu, ako sú čet, odpovede, vkladanie, moderovanie, prepis alebo generovanie obrázkov, v závislosti od podpory poskytovateľa.
• Poverenia automatizácie správcu: používajú sa na správu organizácií, pracovných priestorov, projektov, používateľov, kľúčov alebo zdrojov správy na strane poskytovateľa. Tieto by sa nikdy nemali nachádzať na ceste požiadavky spustenia.
• Poverenia pre fakturáciu a prehľady: používajú sa na získavanie údajov o používaní, faktúrach, nákladoch alebo prehľadoch organizácie, ak poskytovatelia podporujú tieto rozhrania API. Uchovávajte ich oddelene od vyvodzovacích kľúčov, aby úlohy vytvárania prehľadov nemohli generovať využitie modelu.
• Poverenia len na hodnotenie: používané pri porovnávaní, kontrole kvality, migrácii alebo pracovných postupoch. Mali by mať nízke kvóty, jasné environmentálne označenia a nemali by mať nárok na núdzovú výrobu.
• Poverenia zákazníka BYOK: kľúče dodané zákazníkom viazané na konkrétneho nájomníka, účet poskytovateľa, zmluvu a pravidlá týkajúce sa údajov. Nemali by byť združené do zdieľaného smerovania, pokiaľ sa zákazník výslovne neprihlási.

Táto taxonómia nie je len dokumentáciou. Mala by riadiť riadenie prístupu, vhodnosť smerovania, upozorňovanie a pracovné postupy rotácie. Ak sa poverenia importujú bez kategórie, vlastníka, hraníc účtu poskytovateľa a povoleného použitia, mali by zostať zakázané.

Uchovávajte tajomstvá v trezore, nie v záznamoch o produkte

Vault by mal byť jediným komponentom, ktorý dokáže dešifrovať prihlasovacie údaje. Iné systémy môžu uchovávať referencie, hodnoty hash, stavové polia a metadáta pravidiel, ale nie samotnú hodnotu poverenia.

Na týchto miestach neukladajte tajomstvá upstream

• Riadky profilu nájomcu.
• Súbory konfigurácie smerovania modelu.
• Prompt logs or trace spans.
• Úžitkové zaťaženia udalostí služby Analytics.
• Premenné CI orientované na vývojárov.
• Podpora lístkov, četových nástrojov alebo snímok obrazovky.

Použiteľný dizajn trezoru má dve roviny. Tajná rovina uchováva šifrovaný materiál poverení a prísne kontroluje operácie dešifrovania. rovina metadát ukladá neutajené atribúty používané pri smerovaní a riadení. Smerovač by mal zvyčajne potrebovať iba ID poverenia a krátkodobé obnovenie tajomstva v pamäti v čase odoslania, nie široký prístup k databáze ku každému kľúču poskytovateľa.

Chráňte trezor ako infraštruktúru vysokej hodnoty: šifrovanie obálok alebo spravované KMS, prísne identity služieb, procedúry rozbitia skla, testovanie zálohovania a obnovy, kontrola prístupu a upozornenia na nezvyčajný dešifrovaný objem. Centrálny trezor zjednodušuje riadenie, no zároveň koncentruje riziko. To je kompromis.

Ku každému povereniu pripojte metadáta pravidiel

Model metadát by mal byť dostatočne explicitný, aby brána mohla rozhodnúť, či je poverenie vhodné skôr, než sa dotkne koncového bodu poskytovateľa.

Praktický záznam poverení obsahuje:

• credential_id: interný nemenný identifikátor.
• poskytovateľ: OpenAI, Anthropic, Gemini, Azure OpenAI alebo iný adaptér.
• provider_account_boundary: organizácia, projekt, pracovný priestor, cloudový projekt, predplatné alebo ekvivalent.
• credential_class: runtime, správca, fakturácia, hodnotenie alebo BYOK.
• environment: produkcia, inscenácia, vývoj, hodnotenie, karanténa.
• tenant_binding: poverenia zdieľanej platformy, jedného nájomníka, skupiny nájomníkov alebo nájomníka zákazníka BYOK.
• allowed_model_families: napríklad generovanie textu, vkladanie, vízia, obrázok, zvuk alebo profily konkrétnych modelov.
• allowed_endpoints: normalizované možnosti brány mapované na koncové body poskytovateľa.
• data_policy: povolená trieda uchovávania, trieda protokolovania, požiadavka na pobyt a obmedzenia funkcií.
• budget_scope: nákladové stredisko, zákazník predajcu, interné oddelenie alebo zmluva.
• owner: pomenovaný tím alebo zodpovedná osoba.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: neznámy, zdravý, degradovaný, neoprávnený, quota_exhausted, zakázané.
• emergency_disable: okamžité blokovanie smerovania nezávislé od bežného stavu politiky.

Ponechajte tento model ako poskytovateľa neutrálny, ale nevymažte realitu poskytovateľa. Kľúč Anthropic viazaný na pracovný priestor a kľúč Gemini zviazaný s cloudovým projektom Google nie sú zameniteľné len preto, že oba dokážu generovať text. Brána potrebuje tento pôvod pre audity, kompenzáciu a bezpečné prepnutie pri zlyhaní.

Samostatný prístup k runtime, správcovi a fakturácii

Najdôležitejšie pravidlo je jednoduché: kľúč používaný na vyvodzovanie runtime by nemal spravovať organizácie poskytovateľov, pracovné priestory, používateľov, projekty ani administratívne zdroje.

Premávka počas spustenia je vysoká a je vystavená najväčšej prevádzkovej ploche. Prechádza cez smerovače požiadaviek, logiku opakovania, obslužné programy streamovania, modelové adaptéry a pracovné postupy incidentov. Poverenia správcu sú nízkofrekvenčné a majú veľký vplyv. Mali by žiť za oddelenou cestou schvaľovania s krátkymi TTL, v prípade potreby pomenovanými ľudským schválením, silným protokolovaním a bez nároku na smerovanie v režime runtime.

Oddelenie si zaslúžia aj fakturačné údaje. Úloha výkazov, ktorá zosúlaďuje faktúry, by nemala byť schopná generovať dokončenia a inferenčný kľúč za behu by nemal byť jediným spôsobom, ako získať správy o používaní. Keď poskytovateľ neponúka jemné oddelenie, kompenzujte to v bráne: izolujte poverenie, obmedzte, ktorá identita internej služby ho môže získať, a zaznamenajte každé použitie.

Odporúčanie: urobte z triedy poverení pevnú hranicu autorizácie, nie označenie. Runtime dispečer by nemal byť schopný požiadať o dešifrovanie poverenia správcu, aj keď chyba konfigurácie odkazuje na jeho ID.

Vytvoriť nástroj pravidiel výberu poverení

Výber poverení by mal prebehnúť po tom, čo brána overí volajúceho zo siete a pred pokusom o volanie poskytovateľa. Nástroj pravidiel by mal spojiť niekoľko vstupov:

• Identifikátor nájomníka a nadväzujúci kľúčový rozsah API.
• Požadovaný profil modelu alebo ID modelu špecifického pre poskytovateľa.
• Možnosť koncového bodu: čet, vkladanie, obrázok, zvuk, dávka, súbory, nástroje alebo automatizácia správcu.
• Požiadavky na uchovávanie údajov a trvalý pobyt.
• Rozpočet, rezervácia kreditu a nákladové stredisko.
• Stav hraničnej sadzby a tlak kvóty.
• Metadáta poverení, stav, prostredie a väzba nájomníka.

Stroj by mal vrátiť jeden z troch výsledkov: povoliť s vybratým poverením, zamietnuť s dôvodom na porušenie pravidiel alebo vyžadovať schválenie. Odmietnutia by mali byť dostatočne presné, aby prevádzkové tímy mohli problém vyriešiť bez toho, aby vývojárom prezradili tajný materiál.

Príklad rozhodnutia:

{
  "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"
}

Neimplementujte záložnú možnosť ako „skúste ďalší kľúč“. Záložná politika musí znova spustiť. Poverenie zdieľanej platformy môže byť platné pre prístup poskytovateľa, ale neplatné pre zákazníka, ktorý má iba BYOK. Poverenie v inom projekte môže mať kvótu, ale môže porušovať požiadavky na pripisovanie nákladov alebo uchovávanie.

S BYOK zaobchádzať ako s prístupom vo vlastníctve nájomcu, nie s voľnou kapacitou

BYOK mení model dôvery. Zákazník poskytol poverenia, aby jeho prevádzka mohla byť účtovaná, riadená alebo izolovaná v rámci účtu poskytovateľa. Tieto poverenia by mali byť viazané na pôvod účtu nájomcu a poskytovateľa.

Odporúčané ovládacie prvky BYOK:

• Jeden záznam v trezore na zákazníka, poskytovateľa, hranicu účtu a prostredie.
• Žiadne smerovanie medzi nájomníkmi prostredníctvom poverení BYOK.
• Nepoužíva sa ako zdieľaná záložná kapacita, pokiaľ sa zákazník výslovne neprihlási.
• Zdravotný stav viditeľný pre zákazníka, ktorý neprezrádza nespracovaný kľúč.
• Samostatný pracovný postup rotácie, ktorý umožňuje zákazníkovi pridať náhradný kľúč ešte pred zakázaním starého kľúča.
• Jasné priradenie v analýze používania a faktúrach: nájomník brány, hranica účtu poskytovateľa, ID poverenia, profil modelu a ID sledovania žiadosti.

Pre agentúry, predajcov a automatizáciu partnerov API môže byť BYOK zložitejší, pretože služba môže poskytovať nájomcom a poverenia programovo. Stále platí rovnaké pravidlo: automatizácia môže importovať a viazať poverenia, ale nemala by zamazať vlastníctvo nájomníka.

Pridať kontroly stavu pred výstupom bez úniku výziev

Poverenie môže zlyhať z mnohých dôvodov: odvolaný kľúč, nesprávny pracovný priestor, chýbajúci prístup k modelu, zakázaná fakturácia, vyčerpanie kvóty, obmedzenie koncového bodu, nesúlad s regionálnou politikou alebo výpadok poskytovateľa. Zistenie, že až potom, čo príde produkčná požiadavka, vytvára hlučné incidenty.

Používajte zdravotné kontroly, ktoré overia schopnosti bez odosielania výziev zákazníkom. Syntetická kontrola môže vyvolať minimálny koncový bod, uviesť zoznam povolených modelov, ak je to vhodné, alebo poslať neškodnú fixnú výzvu, ak je to jediná praktická možnosť. Udržujte tieto šeky lacné, obmedzené sadzbou a označené ako syntetická prevádzka v telemetrii a fakturácii.

Zdravotné kontroly by mali prebiehať:

• Pri importe poverení.
• Pred povolením poverenia pre produkčné smerovanie.
• Po zmenách obmedzení na strane poskytovateľa.
• Počas prerušenia otáčania.
• Pravidelne pre poverenia s oprávnenosťou produkcie.

Trade-off: automatické kontroly zachytia kľúče, ktorým vypršala platnosť alebo nedostatočný rozsah, ale zle navrhnuté kontroly môžu spôsobiť zbytočné volania poskytovateľa, hluk z účtovania alebo falošné poplachy počas výpadkov poskytovateľa. Uložte výsledok stavu s časovou pečiatkou, triedou chýb poskytovateľa, testovaným koncovým bodom a testovanou rodinou modelov. Neuchovávajte tajné hodnoty ani citlivé výzvy.

Otáčanie pomocou dvoch slotov, nie jednej riskantnej výmeny

Otočenie poverení by nemalo byť operáciou vymazania a vymazania. Použite model rotácie s dvoma slotmi:

1. Importovať náhradné poverenia ako neaktívne, s úplnými metadátami a vlastníkom.
2. Spustite syntetické kontroly stavu pre zamýšľané koncové body, skupiny modelov a hranice účtu.
3. Ak je to vhodné, povoľte tieňovú spôsobilosť pre malý kúsok bezpečnej syntetickej alebo nízkorizikovej návštevnosti.
4. Postupne presúvajte produkčnú prevádzku zo starého poverenia na nové.
5. Sledovanie chýb, latencie, kvóty a priradenia nákladov podľa ID poverenia.
6. Zmrazte návrat k starému povereniu, keď bude nové poverenie stabilné.
7. Zrušte staré poverenie u poskytovateľa a označte záznam trezoru za odvolaný.
8. Overte, že po odvolaní sa cez staré poverenia nevyskytujú žiadne dešifrovanie ani volania poskytovateľa.

Termíny striedania by mali byť viditeľné v prevádzkových zobrazeniach a upozorneniach. Núdzové striedanie si vyžaduje kratšiu cestu: deaktivujte poverenia, zablokujte smerovanie, povoľte schválenú výmenu a uložte všetky záznamy auditu na kontrolu incidentu.

Obmedzenie kľúčov poskytovateľa tam, kde to poskytovateľ podporuje

Pravidlá týkajúce sa brány sú nevyhnutné, ale obmedzenia na strane poskytovateľa zmenšujú dosah, ak je kľúč kompromitovaný alebo zneužitý. V prípade kľúčov Gemini a iných cloudových platforiem API použite obmedzenia API/service a vhodné obmedzenia aplikácií, ak sú k dispozícii. V prípade projektov poskytovateľov, pracovných priestorov a servisných účtov sa vyhnite širokým organizačným privilégiám, keď stačí kľúč runtime v rozsahu projektu.

Odporúčanie: udržiavať kontrolný zoznam obmedzení na strane poskytovateľa pre každú triedu poverení. Kontrolný zoznam by mal byť súčasťou schvaľovania importu a schvaľovania rotácie, nie samostatnou bezpečnostnou úlohou, ktorú možno pod tlakom preskočiť.

Trade-off: Obmedzenia na strane poskytovateľa zvyšujú prevádzkovú réžiu. Nové koncové body, rodiny modelov, oblasti alebo automatizačné funkcie môžu vyžadovať zmeny pravidiel a obmedzení. Je to vhodnejšie ako po úniku zistiť, že jeden kľúč môže pristupovať ku každému pracovnému zaťaženiu v zdieľanom projekte.

Uchovávajte si denník auditu poverení, ktorý len pripájate

Audítorský záznam by mal zodpovedať, kto importoval poverenie, čo mu bolo povolené, ktoré rozhodnutia o smerovaní ho vybrali, kedy zlyhalo a kedy bolo otočené alebo odvolané.

Zapíšte tieto udalosti:

• Vytvorené alebo importované poverenia.
• Metadáta sa zmenili, vrátane povolených koncových bodov, viazania nájomníkov alebo údajových pravidiel.
• Vykonaná zdravotná kontrola a zaznamenaný výsledok.
• Poverenie vybrané podľa pravidiel smerovania pre žiadosť.
• Dešifrovanie poverení požadované internou identitou služby.
• Volanie poskytovateľa zlyhalo pre chybu overenia, autorizácie, kvóty alebo obmedzenia.
• Rotácia bola spustená, premávka sa presunula, staré poverenia boli odvolané.
• Núdzové vypnutie povolené alebo vymazané.
• Prístup k povereniu správcu alebo rozbitého skla.

Do udalostí auditu nevkladajte nespracované hodnoty poverení. Použite ID poverení, hranice účtov poskytovateľa, ID sledovania žiadostí, identity aktérov a dôvody rozhodnutia o politike. Pre vysokoobjemovú prevádzkovú prevádzku si môžete vyskúšať podrobnú dešifrovaciu telemetriu, ale výber smerovania a priradenie nákladov by mali zostať dostatočne dokončené na fakturáciu a reakciu na incidenty.

Kontrolný zoznam implementácie

• Vytvorte taxonómiu poverení a odmietnite neklasifikované importy.
• Presuňte všetky tajomstvá poskytovateľa do vyhradeného šifrovaného trezoru.
• Ukladajte smerovacie metadáta oddelene od tajného materiálu.
• Urobte z poverení runtime, správcu, fakturácie, hodnotenia a BYOK samostatné triedy autorizácie.
• Zviažte poverenia BYOK s pôvodom účtu nájomcu a poskytovateľa.
• Pred výberom akýchkoľvek poverení pre odosielateľov si vyžiadajte schválenie nástrojom pravidiel.
• Spustite rýchle a bezpečné zdravotné kontroly pred oprávnenosťou výroby.
• Použite striedanie dvoch slotov s postupným presunom návštevnosti a zrušením na strane poskytovateľa.
• Aplikujte obmedzenia na strane poskytovateľa všade tam, kde je to možné.
• Udržiavajte protokoly auditu iba na pridanie pre import, použitie, zlyhania, rotáciu a zrušenie.
• Správcovské poverenia majte pod ovládacími prvkami rozbitia: krátke TTL, pomenované schválenie, silné protokolovanie, bez použitia runtime.

Uplatniteľný záver

Začnite inventarizáciou všetkých poverení poskytovateľa upstream, ktoré momentálne používa brána, skripty, úlohy CI, hodnotiace zväzky a automatizácia partnerov. Ku každému priraďte triedu, vlastníka, hranicu účtu poskytovateľa, väzbu nájomníka, povolené koncové body, povolené rodiny modelov, termín rotácie a stav núdzového vypnutia. Čokoľvek, čo nemôžete klasifikovať, by ste mali deaktivovať alebo umiestniť do karantény, kým to nebude mať jasný účel.

Potom presadzujte jedno architektonické pravidlo: následní vývojári dostanú kľúče v rozsahu brány; samotná brána riadi prístup poskytovateľa proti prúdu. Toto oddelenie vám umožní zachovať si najmenšie privilégiá, priradenie nájomníkov, presnosť fakturácie, smerovanie podľa pravidiel údajov a bezpečnú automatizáciu, aj keď sa poskytovatelia, projekty, pracovné priestory a zákazníci BYOK množia.

Súvisiace čítanie

• tímová orientácia API správa kľúčov a úniky response
• pravidlá smerovania s ohľadom na uchovávanie údajov
• účtovacia kniha a ovládacie prvky pripisovania nákladov