Úschova pověření poskytovatele pro vícemodelové brány umělé inteligence: Samostatný běhový, administrátorský, fakturační a BYOK přístup

Klíče k odběru API a přihlašovací údaje poskytovatele upstream řeší různé problémy. Klíč vývojáře vydaný vaší bránou identifikuje aplikaci, tým, tenanta, rozpočet a kontext zásad. Upstreamový klíč poskytovatele umožňuje bráně utrácet peníze a přistupovat k modelům na účtu poskytovatele. Zacházení s nimi jako se stejným druhem tajemství je způsob, jak týmy skončí s jedním neomezeným klíčem ve sdíleném projektu, pověřeními správce v runtime službách a neexistuje spolehlivý způsob, jak odpovědět, který tenant způsobil který poplatek na straně poskytovatele.

Praktickým vzorem je úschovna pověření poskytovatele: vyhrazená řídicí rovina pro import, klasifikaci, ukládání, výběr, otáčení a auditování přihlašovacích údajů proti proudu. Měl by být umístěn za směrovačem, účetní knihou, modulem zásad a pracovním postupem operací – nikoli v kódu aplikace, konfiguračních souborech modelu, záznamech tenantů nebo analytických událostech.

Problém čtenáře: přihlašovací údaje se stávají neviditelnou infrastrukturou

Většina implementací pro více modelů začíná jednoduchým cílem: přesměrovat jeden OpenAI-kompatibilní požadavek k nejlepšímu dostupnému poskytovateli. Poté se objeví další účty: jeden projekt poskytovatele pro produkci, další pro hodnocení, pracovní prostor Anthropic pro obchodní jednotku, cloudový projekt Google pro Gemini a několik klíčů dodaných zákazníkem pro smlouvy BYOK.

Riziko není jen tajný únik. Je to ztráta kontextu autorizace. Platný klíč poskytovatele může být technicky schopen volat koncový bod, ale brána stále potřebuje vědět, zda je tento klíč povolen pro tohoto tenanta, tuto modelovou rodinu, tyto zásady uchovávání dat, tento rozpočet, tuto oblast a tuto cestu automatizace.

Fakt: platformy poskytovatelů odhalují různé hranice účtů a typy pověření. OpenAI dokumenty k projektům a servisním účtům a klíčová oprávnění servisního účtu API jsou výchozím nastavením pro přístup ke čtení a zápisu ke zdrojům projektu API. OpenAI také odhaluje klíčové objekty správce API odděleně od běžného použití projektu/runtime API. Anthropic dokumentuje pracovní prostory jako organizační hranici a uvádí, že koncové body správce API vyžadují klíče správce API odlišné od standardních klíčů API; Anthropic také poznamenává, že klíče API jsou svázány s pracovním prostorem, kde byly vytvořeny, a nelze je mezi pracovními prostory přesouvat. Dokumentace klíče Google Gemini API říká, že každý klíč Gemini API je spojen s cloudovým projektem Google a doporučuje omezení API, aby se snížilo poškození, pokud je klíč kompromitován.

Doporučení:nevytvářejte jedno obecné pole „provider_key“ a neříkejte mu hotovo. Vytvořte inventář pověření, který zachová hranice specifické pro poskytovatele a zároveň zpřístupní bráně model normalizovaných zásad.

Před přijetím klíčů definujte taxonomii pověření

Sejf by měl odmítnout nejednoznačné přihlašovací údaje. Při importu musí operátor nebo pracovní postup automatizace klasifikovat pověření. Použijte minimálně tyto kategorie:

• Runtime inference credentials: používané bránou k volání koncových bodů odvození modelu, jako je chat, odpovědi, vkládání, moderování, přepis nebo generování obrázků, v závislosti na podpoře poskytovatele.
• Přihlašovací údaje pro automatizaci správce: slouží ke správě organizací, pracovních prostorů, projektů, uživatelů, klíčů nebo zdrojů správy na straně poskytovatele. Ty by nikdy neměly být na cestě požadavku za běhu.
• Ověřovací údaje pro fakturaci a vytváření přehledů: slouží k získávání údajů o využití, fakturách, nákladech nebo přehledech organizace, pokud poskytovatelé tato rozhraní API podporují. Udržujte je odděleně od odvozených klíčů, aby úlohy sestav nemohly generovat využití modelu.
• Pověření pouze pro hodnocení: používané při srovnávání, kontrole kvality, migraci nebo pracovních postupech. Měly by mít nízké kvóty, jasné ekologické štítky a neměly by být způsobilé pro záložní výrobu.
• Přihlašovací údaje zákazníka BYOK: Klíče dodané zákazníkem vázané na konkrétního tenanta, účet poskytovatele, smlouvu a zásady týkající se dat. Neměly by být sdruženy do sdíleného směrování, pokud se zákazník výslovně nepřihlásí.

Tato taxonomie není jen dokumentace. Mělo by řídit řízení přístupu, způsobilost směrování, upozorňování a pracovní postupy rotace. Pokud jsou přihlašovací údaje importovány bez kategorie, vlastníka, hranice účtu poskytovatele a povoleného použití, měly by zůstat deaktivované.

Uchovávejte tajemství v trezoru, nikoli v záznamech produktu

Sejf by měl být jedinou součástí, která dokáže dešifrovat přihlašovací údaje. Jiné systémy mohou ukládat reference, hash, stavová pole a metadata zásad, ale nikoli samotnou hodnotu pověření.

Na těchto místech neukládejte tajná tajemství

• Řádky profilu nájemce.
• Soubory konfigurace směrování modelu.
• Protokoly výzvy nebo rozsahy trasování.
• Data událostí Analytics.
• Proměnné CI orientované na vývojáře.
• Podpora lístků, chatovacích nástrojů nebo snímků obrazovky.

Použitelný návrh trezoru má dvě roviny. tajné letadlo uchovává šifrovaný materiál pověření a přísně kontroluje operace dešifrování. rovina metadat ukládá netajné atributy používané směrováním a správou. Směrovač by měl obvykle potřebovat pouze ID pověření a krátkodobé načtení tajemství v paměti v době odeslání, nikoli široký přístup k databázi ke každému klíči poskytovatele.

Chraňte trezor jako infrastrukturu vysoké hodnoty: šifrování obálek nebo spravované KMS, přísné identity služeb, postupy pro rozbití skla, testování zálohování a obnovy, kontrola přístupu a upozornění na neobvyklý dešifrovaný svazek. Centrální trezor zjednodušuje správu, ale také koncentruje riziko. To je kompromis.

Připojit metadata zásad ke každému pověření

Model metadat by měl být dostatečně explicitní, aby brána mohla rozhodnout, zda je pověření způsobilé, než se dotkne koncového bodu poskytovatele.

Praktický záznam pověření obsahuje:

• credential_id: interní neměnný identifikátor.
• poskytovatel: OpenAI, Anthropic, Gemini, Azure OpenAI nebo jiný adaptér.
• provider_account_boundary: organizace, projekt, pracovní prostor, cloudový projekt, předplatné nebo ekvivalent.
• credential_class: runtime, správce, fakturace, hodnocení nebo BYOK.
• prostředí: produkce, inscenace, vývoj, hodnocení, izolovaný prostor.
• tenant_binding: pověření sdílené platformy, jeden tenant, skupina tenantů nebo tenant zákazníka BYOK.
• allowed_model_families: například generování textu, vkládání, vidění, obrázek, zvuk nebo profily konkrétních modelů.
• allowed_endpoints: normalizované možnosti brány mapované na koncové body poskytovatele.
• data_policy: povolená třída uchování, třída protokolování, požadavek na bydliště a omezení funkcí.
• budget_scope: nákladové středisko, zákazník distributora, interní oddělení nebo smlouva.
• owner: jmenovaný tým nebo odpovědná osoba.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: neznámý, zdravý, degradovaný, neautorizovaný, quota_exhausted, zakázán.
• emergency_disable: blok okamžitého směrování nezávislý na běžném stavu zásad.

Uchovejte tento model jako poskytovatele neutrální, ale nemažte realitu poskytovatele. Klíč vázaný na pracovní prostor Anthropic a klíč Gemini vázaný na cloudový projekt Google nejsou zaměnitelné jen proto, že oba mohou generovat text. Brána potřebuje tento původ pro audity, zpětné zúčtování a bezpečné převzetí služeb při selhání.

Samostatný přístup pro běh, správce a fakturaci

Nejdůležitější pravidlo je jednoduché: klíč používaný k odvozování za běhu by neměl spravovat organizace poskytovatelů, pracovní prostory, uživatele, projekty ani administrativní zdroje.

Provoz za běhu je velký a je vystaven největšímu provoznímu povrchu. Prochází směrovači požadavků, logikou opakování, obslužnými rutinami streamování, modelovými adaptéry a pracovními postupy incidentů. Pověření správce mají nízkou frekvenci a velký dopad. Měli by žít za samostatnou schvalovací cestou s krátkými TTL, případně pojmenovanými lidským schválením, silným protokolováním a bez způsobilosti pro běhové směrování.

Oddělení si zaslouží také fakturační údaje. Úloha sestav, která odsouhlasuje faktury, by neměla být schopna generovat dokončení a klíč pro odvození za běhu by neměl být jediným způsobem, jak získat sestavy využití. Když poskytovatel nenabízí jemné oddělení, kompenzujte to v bráně: izolujte přihlašovací údaje, omezte, která identita interní služby je může získat, a zaznamenejte každé použití.

Doporučení: udělejte z třídy pověření pevnou autorizační hranici, nikoli štítek. Runtime dispečer by neměl být schopen požádat o dešifrování pověření správce, i když chyba konfigurace odkazuje na jeho ID.

Vytvořte modul zásad pro výběr pověření

Výběr pověření by měl proběhnout poté, co brána ověří následného volajícího a před pokusem o volání poskytovatele. Modul zásad by měl spojit několik vstupů:

• ID nájemce a downstream API klíčový rozsah.
• Požadovaný profil modelu nebo ID modelu specifického pro poskytovatele.
• Možnost koncového bodu: chat, vkládání, obrázek, zvuk, dávka, soubory, nástroje nebo automatizace správy.
• Požadavky na uchovávání údajů a trvalé bydliště.
• Rozpočet, rezervace kreditu a nákladové středisko.
• Stav omezení sazby a tlak kvóty.
• Metadata pověření, stav, prostředí a vazba tenanta.

Systém by měl vrátit jeden ze tří výsledků: povolit s vybraným pověřením, odmítnout s důvodem zásad nebo vyžadovat schválení. Odmítnutí by měla být dostatečně přesná, aby operační týmy mohly problém vyřešit, aniž by vývojářům odhalily tajný materiál.

Příklad rozhodnutí:

{
  "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í jako „zkuste další klíč“. Záložní zásady musí znovu spustit. Pověření sdílené platformy může být platné pro přístup poskytovatele, ale neplatné pro zákazníka pouze BYOK. Pověření v jiném projektu může mít kvótu, ale může porušovat požadavky na přiřazení nákladů nebo zachování.

Nakládat s BYOK jako s přístupem vlastněným nájemcem, nikoli s volnou kapacitou

BYOK mění model důvěryhodnosti. Zákazník poskytl přihlašovací údaje, aby jeho provoz mohl být účtován, řízen nebo izolován v rámci jeho účtu poskytovatele. Tyto přihlašovací údaje by měly být vázány na původ účtu nájemce a poskytovatele.

Doporučené ovládací prvky BYOK:

• Jeden záznam v trezoru na zákazníka, poskytovatele, hranici účtu a prostředí.
• Žádné směrování mezi klienty prostřednictvím přihlašovacích údajů BYOK.
• Nepoužívá se jako sdílená záložní kapacita, pokud se zákazník výslovně nepřihlásí.
• Zdravotní stav viditelný pro zákazníka, který neodhaluje nezpracovaný klíč.
• Samostatný pracovní postup střídání, který umožňuje zákazníkovi přidat náhradní před deaktivací starého klíče.
• Jasné přiřazení ve statistikách využití a fakturách: tenant brány, hranice účtu poskytovatele, ID pověření, profil modelu a ID trasování požadavku.

Pro agentury, distributory a automatizaci partnerů API může být BYOK složitější, protože služba může poskytovat nájemce a přihlašovací údaje programově. Stále platí stejné pravidlo: automatizace může importovat a svázat přihlašovací údaje, ale neměla by rozmazávat vlastnictví tenanta.

Přidat kontroly stavu před výstupem bez úniku výzev

Přihlašovací údaje mohou selhat z mnoha důvodů: zrušený klíč, nesprávný pracovní prostor, chybějící přístup k modelu, zakázaná fakturace, vyčerpání kvóty, omezení koncového bodu, nesoulad regionálních zásad nebo výpadek poskytovatele. Zjištění, že až poté, co dorazí produkční požadavek, vytváří hlučné incidenty.

Používejte kontroly stavu, které ověřují schopnosti bez zasílání výzev zákazníkům. Syntetická kontrola může zavolat minimální koncový bod, uvést povolené modely tam, kde je to vhodné, nebo poslat neškodnou pevnou výzvu, pokud je to jediná praktická možnost. Udržujte tyto šeky levné, omezené a označené jako syntetický provoz v telemetrii a fakturaci.

Zdravotní kontroly by měly probíhat:

• Při importu pověření.
• Před povolením pověření pro produkční směrování.
• Po změnách omezení na straně poskytovatele.
• Během přerušování otáčení.
• Pravidelně pro pověření s produkční způsobilostí.

Trade-off: automatizované kontroly zachytí klíče s prošlou platností nebo s nedostatečným rozsahem, ale špatně navržené kontroly mohou způsobit zbytečná volání poskytovatele, hluk z fakturace nebo falešné poplachy během výpadků poskytovatele. Uložte výsledek stavu s časovým razítkem, třídou chyb poskytovatele, testovaným koncovým bodem a testovanou rodinou modelů. Neukládejte tajné hodnoty ani citlivé výzvy.

Otočte se dvěma sloty, ne jednou riskantní výměnou

Otočení pověření by nemělo být operací vymazání a přehrání. Použijte dvouslotový rotační model:

1. Importovat náhradní pověření jako neaktivní, s úplnými metadaty a vlastníkem.
2. Spusťte syntetické kontroly stavu pro zamýšlené koncové body, rodiny modelů a hranice účtu.
3. Povolte stínovou způsobilost pro malý úsek bezpečného syntetického nebo nízkorizikového provozu tam, kde je to vhodné.
4. Postupně přesouvejte produkční provoz ze starých pověření na nové.
5. Sledování chyb, latence, kvóty a atribuce nákladů podle ID pověření.
6. Zmrazte návrat ke starým přihlašovacím údajům, jakmile budou nové přihlašovací údaje stabilní.
7. Zrušte staré přihlašovací údaje u poskytovatele a označte záznam trezoru jako odvolaný.
8. Ověřte, že po odvolání nedochází k dešifrování nebo volání poskytovatele přes staré přihlašovací údaje.

Termíny střídání by měly být viditelné v provozních zobrazeních a upozorněních. Nouzové střídání vyžaduje kratší cestu: deaktivujte přihlašovací údaje, zablokujte směrování, povolte schválenou náhradu a uchujte všechny záznamy auditu pro kontrolu incidentu.

Omezit klíče poskytovatele tam, kde to poskytovatel podporuje

Zásady brány jsou nezbytné, ale omezení na straně poskytovatele omezují dosah, pokud je klíč kompromitován nebo zneužit. Pro klíče Gemini a další cloudové platformy API použijte omezení API/service a vhodná omezení aplikací, pokud jsou k dispozici. U projektů poskytovatelů, pracovních prostorů a servisních účtů se vyhněte širokým organizačním oprávněním, pokud stačí runtime klíč v rozsahu projektu.

Doporučení: udržovat kontrolní seznam omezení na straně poskytovatele pro každou třídu pověření. Kontrolní seznam by měl být součástí schvalování importu a schvalování rotace, nikoli samostatným úkolem zabezpečení, který lze pod tlakem přeskočit.

Trade-off: Omezení na straně poskytovatele zvyšují provozní režii. Nové koncové body, rodiny modelů, oblasti nebo funkce automatizace mohou vyžadovat změny zásad a omezení. To je lepší než zjištění po úniku, že jeden klíč by mohl přistupovat ke každé pracovní zátěži ve sdíleném projektu.

Uchovávejte si protokol auditu pověření pouze pro připojení

Audit trail by měl odpovědět na to, kdo importoval pověření, co mu bylo povoleno, která rozhodnutí o směrování jej vybrala, kdy selhala a kdy byla otočena nebo zrušena.

Zaznamenat tyto události:

• Pověření vytvořeno nebo importováno.
• Metadata se změnila, včetně povolených koncových bodů, vazby tenanta nebo zásad dat.
• Zdravotní kontrola provedena a výsledek zaznamenán.
• Pověření vybrané podle zásad směrování pro požadavek.
• Dešifrování pověření požadované interní identitou služby.
• Volání poskytovatele selhalo kvůli chybě ověření, autorizace, kvóty nebo omezení.
• Otáčení zahájeno, provoz posunut, staré pověření zrušeno.
• Nouzová deaktivace povolena nebo zrušena.
• Přístup k přihlašovacím údajům správce nebo rozbitého skla.

Do událostí auditu nevkládejte nezpracované hodnoty pověření. Použijte ID pověření, hranice účtů poskytovatele, ID trasování požadavků, identity aktérů a důvody rozhodnutí o politice. Pro vysokoobjemový provoz za běhu si můžete vyzkoušet podrobnou dešifrovací telemetrii, ale výběr směrování a přiřazení nákladů by měly zůstat dostatečně kompletní pro fakturaci a reakci na incidenty.

Kontrolní seznam implementace

• Vytvořte taxonomii pověření a odmítněte neklasifikované importy.
• Přesuňte všechna tajemství poskytovatele do vyhrazeného šifrovaného trezoru.
• Ukládejte směrovací metadata odděleně od tajného materiálu.
• Udělejte z pověření runtime, správce, fakturace, hodnocení a BYOK samostatné třídy autorizace.
• Svažte přihlašovací údaje BYOK k původu účtu nájemce a poskytovatele.
• Před výběrem jakýchkoli přihlašovacích údajů pro upstream vyžadovat schválení nástrojem zásad.
• Před způsobilostí k produkci spusťte bezpečné kontroly stavu.
• Používejte střídání dvou slotů s postupným přesunem provozu a zrušením na straně poskytovatele.
• Uplatněte omezení na straně poskytovatele, kdykoli je to možné.
• Udržujte protokoly auditu pouze pro připojení pro import, použití, selhání, rotaci a odvolání.
• Uchovávejte přihlašovací údaje správce pod ovládacími prvky pro rozbití: krátké TTL, pojmenované schválení, silné protokolování, žádné použití za běhu.

Akční závěr

Začněte inventarizací všech přihlašovacích údajů upstream poskytovatele, které aktuálně používá brána, skripty, úlohy CI, vyhodnocovací svazky a automatizace partnerů. Pro každou z nich přiřaďte třídu, vlastníka, hranici účtu poskytovatele, vazbu tenanta, povolené koncové body, povolené rodiny modelů, termín rotace a stav nouzového vypnutí. Cokoli, co nemůžete klasifikovat, by mělo být deaktivováno nebo umístěno do karantény, dokud to nebude mít jasný účel.

Pak vynucujte jedno architektonické pravidlo: následní vývojáři obdrží klíče s rozsahem brány; samotná brána řídí přístup poskytovatele proti proudu. Toto oddělení vám umožní zachovat minimální oprávnění, přiřazování tenantů, přesnost fakturace, směrování zásad dat a bezpečnou automatizaci, i když se poskytovatelé, projekty, pracovní prostory a zákazníci BYOK množí.

Související čtení

• týmová orientace API správa klíčů a úniky response
• zásady směrování s ohledem na uchovávání dat
• fakturační kniha a ovládací prvky připisování nákladů