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 downstream 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 tými 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 žiadnym spoľahlivým spôsobom, 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 importovanie, 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 požiadavku kompatibilnú s OpenAI k najlepšiemu dostupnému poskytovateľovi. Potom sa objavia ďalšie účty: jeden projekt poskytovateľa na produkciu, druhý na hodnotenie, antropický pracovný priestor pre obchodnú jednotku, projekt Google Cloud pre Gemini a niekoľko kľúčov dodaných zákazníkom pre zmluvy BYOK.

Riziko nie je len tajný únik. Je to strata 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 oprávnenia kľúča API servisného účtu predvolene umožňujú prístup na čítanie a zápis pre zdroje API projektu. OpenAI tiež odhaľuje kľúčové objekty Admin API oddelene od bežného používania projektového/behového API. Pracovné priestory antropických dokumentov ako organizačná hranica a uvádza, že koncové body Admin API vyžadujú kľúče Admin API odlišné od štandardných kľúčov API; Antropic tiež poznamenáva, že kľúče API sú viazané na pracovný priestor, kde sú vytvorené, a nemožno ich presúvať medzi pracovnými priestormi. Dokumentácia kľúča Gemini API od Googlu hovorí, že každý kľúč Gemini API je spojený s projektom Google Cloud a odporúča obmedzenia API, aby sa znížilo poškodenie v prípade ohrozenia 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í normalizovaný model politiky.

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:

• Poverenia na odvodenie za spustenia: 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 na automatizáciu 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 vytváranie prehľadov: používajú sa na získanie údajov o používaní, faktúrach, nákladoch alebo prehľadoch organizácie, ak poskytovatelia podporujú tieto rozhrania API. Udržujte ich oddelene od inferenčných kľúčov, aby úlohy vytvárania prehľadov nemohli generovať využitie modelu.
• Poverenia len na hodnotenie: používajú sa 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 BYOK zákazníka: kľúče dodané zákazníkom viazané na konkrétneho nájomníka, účet poskytovateľa, zmluvu a politiku ú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 produktu

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

Na týchto miestach neuchovávajte tajné informácie proti prúdu

• Riadky profilu nájomcu.
• Konfiguračné súbory smerovania modelov.
• Protokoly výzvy alebo rozsahy sledovania.
• Užitočné zaťaženia udalostí služby Analytics.
• Premenné CI orientované na vývojárov.
• Podpora lístkov, nástrojov na četovanie 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á neutajované 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 vysokohodnotnú infraštruktúru: š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ý zväzok. 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, ako sa dotkne koncového bodu poskytovateľa.

Praktický záznam poverení obsahuje:

• id poverenia: 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.
• trieda_poverení: runtime, admin, fakturácia, hodnotenie alebo BYOK.
• prostredie: výroba, inscenácia, vývoj, hodnotenie, karanténa.
• tenant_binding: poverenia zdieľanej platformy, jeden nájomník, skupina nájomníkov alebo nájomník BYOK zákazníka.
• 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í.
• rozsah_rozpočtu: nákladové stredisko, zákazník predajcu, interné oddelenie alebo zmluva.
• vlastník: menovaný tím alebo zodpovedná osoba.
• vytvorené_at, expires_at, rotation_due_at, last_used_at.
• health_status: neznámy, zdravý, degradovaný, nepovolený, kvóta_vyčerpaná, 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ľúč viazaný na antropický pracovný priestor a kľúč Gemini zviazaný s projektom Google Cloud 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 behu, správcovi a fakturácii

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

Premávka počas prevádzky je veľká 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í. Ak 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.

Vytvorte nástroj politiky výberu poverení

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

• ID nájomníka a rozsah kľúča downstream 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 pobyt.
• Rozpočet, rezervácia kreditu a nákladové stredisko.
• Stav limitu rýchlosti a tlak kvóty.
• Metadáta poverení, zdravie, prostredie a viazanie 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 operačné tímy vyriešili problém bez odhalenia tajného materiálu vývojárom.

Príklad rozhodnutia:

{
  "tenant_id": "tenant_42",
  "requested_profile": "výroba rýchleho textu",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "životné prostredie": "výroba",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "zdravý"
  },
  "rozhodnutie": "povoliť",
  "credential_id": "cred_8f2...",
  "audit_reason": "poverenia nájomníka BYOK sa zhodujú s textovým profilom a zásadami údajov pri spustení"
}

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ádzajte 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 zákazníka 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ý neodhaľuje základný kľúč.
• Samostatný pracovný postup rotácie, ktorý umožňuje zákazníkovi pridať náhradu skôr, ako bude starý kľúč zakázaný.
• 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 rozhrania Partner 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 nemalo by to rozmazávať vlastníctvo nájomníka.

Pridajte 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 kontroly stavu, ktoré overia schopnosť 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é, s obmedzenou sadzbou a označené ako syntetická prevádzka v telemetrii a fakturácii.

Zdravotné kontroly by sa mali spustiť:

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

Výmena: automatizované kontroly zachytia kľúče s vypršanou platnosťou alebo nedostatočným rozsahom, no zle navrhnuté kontroly môžu spôsobiť zbytočné volania poskytovateľa, hluk z fakturácie 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.

Otočte 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ých poverení na nové.
5. Monitorujte chyby, latenciu, kvótu a priradenie nákladov podľa ID poverenia.
6. Zmrazte návrat na staré poverenia, keď budú nové poverenia stabilné.
7. Odvolajte staré poverenia u poskytovateľa a označte záznam v trezore ako odvolaný.
8. Skontrolujte, či sa po odvolaní nevykonajú žiadne dešifrovanie alebo volania poskytovateľa prostredníctvom starých poverení.

Termíny striedania by mali byť viditeľné v zobrazeniach operácií a upozorneniach. Núdzová rotácia 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

Zásady brány sú nevyhnutné, ale obmedzenia na strane poskytovateľa zmenšujú dosah, ak je kľúč ohrozený alebo zneužitý. Pre Gemini a ďalšie kľúče API cloudovej platformy použite obmedzenia API/služieb 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ď postačuje runtime kľúč v rozsahu projektu.

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

Výmena: 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í. To je vhodnejšie ako zistenie po úniku, že jeden kľúč by mohol pristupovať ku každému pracovnému zaťaženiu v zdieľanom projekte.

Uchovávajte si denník auditu poverení, ktorý obsahuje iba pridanie

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

Zaznamenajte tieto udalosti:

• Vytvorené alebo importované poverenia.
• Metadáta sa zmenili, vrátane povolených koncových bodov, viazania nájomníka alebo pravidiel údajov.
• Vykonaná zdravotná kontrola a zaznamenaný výsledok.
• Poverenie vybraté podľa pravidiel smerovania pre požiadavku.
• Dešifrovanie poverení požadované internou identitou služby.
• Volanie poskytovateľa zlyhalo v dôsledku chyby overenia, autorizácie, kvóty alebo obmedzenia.
• Otáčanie sa začalo, návštevnosť sa presunula, staré poverenia boli odvolané.
• Núdzové vypnutie je 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 môžete otestovať podrobnú dešifrovaciu telemetriu, ale výber smerovania a priradenie nákladov by mali zostať dostatočne úplné na fakturáciu a reakciu na incidenty.

Kontrolný zoznam implementácie

• Vytvorte taxonómiu poverení a odmietnite neklasifikované importy.
• Presuňte všetky tajné informácie poskytovateľa do vyhradeného šifrovaného trezoru.
• Uchovávajte 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 používateľov si vyžiadajte schválenie nástrojom politiky.
• 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 odvolaním na strane poskytovateľa.
• Aplikujte obmedzenia na strane poskytovateľa všade tam, kde je to možné.
• Udržiavajte protokoly auditu, ktoré sa len pripájajú, pre import, použitie, zlyhania, rotáciu a zrušenie.
• Uchovávajte poverenia správcu pod ovládacími prvkami rozbitia: krátke TTL, pomenované schválenie, silné protokolovanie, žiadne použitie pri spustení.

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. Všetko, čo nemôžete klasifikovať, by malo byť zakázané alebo umiestnené 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ť najmenšie privilégiá, priradenie nájomníkov, presnosť fakturácie, smerovanie na základe ú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á správa kľúčov API a reakcia na únik
• zásady smerovania s ohľadom na uchovávanie údajov
• ledger-1. a ovládacie prvky pripisovania nákladov