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

Downstream API klíče a upstream poskytovatele pověření ř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 nasazení pro více modelů začíná jednoduchým cílem: směrovat jeden požadavek kompatibilní s OpenAI k nejlepšímu dostupnému poskytovateli. Poté se objeví další účty: jeden projekt poskytovatele pro produkci, druhý pro hodnocení, antropický pracovní prostor pro obchodní jednotku, projekt Google Cloud pro Gemini a několik klíčů dodaných zákazníkem pro smlouvy BYOK.

Rizikem není pouze 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 skupinu, tuto zásadu 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 dokumentuje projekty a účty služeb a oprávnění klíče API servisního účtu ve výchozím nastavení pro přístup ke čtení a zápisu pro zdroje API projektu. OpenAI také zpřístupňuje klíčové objekty Admin API odděleně od běžného použití projektového/runtime API. Anthropic dokumentuje pracovní prostory jako organizační hranici a uvádí, že koncové body Admin API vyžadují klíče Admin 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 jsou vytvořeny, a nelze je přesouvat mezi pracovními prostory. Dokumentace klíče Gemini API od Googlu uvádí, že každý klíč Gemini API je spojen s projektem Google Cloud a doporučuje omezení API, aby se snížilo poškození v případě kompromitace klíče.

Doporučení: nevytvářejte jedno obecné pole „provider_key“ a neříkejte mu hotové. 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:

• Přihlašovací údaje za běhu: 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.
• Pověřovací údaje pro automatizaci správce: slouží ke správě organizací, pracovních prostorů, projektů, uživatelů, klíčů nebo prostředků 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 přehledy: 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ěřovací údaje pouze pro hodnocení: používají se 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.
• Pověření BYOK zákazníka: 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 dokumentací. Mělo by řídit řízení přístupu, způsobilost směrování, upozorňování a pracovní postupy rotace. Pokud je pověření importováno bez kategorie, vlastníka, hranice účtu poskytovatele a povoleného použití, mělo by zůstat deaktivováno.

Ukládejte 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é informace proti proudu

• Řádky profilu nájemce.
• Konfigurační soubory 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á rovina 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í tajného klíče v paměti v době odeslání, nikoli široký přístup k databázi ke každému klíči poskytovatele.

Chraňte úschovnu jako infrastrukturu s vysokou hodnotou: š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řipojte 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:

• id pověření: 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, admin, billing, evaluation, or BYOK.
• prostředí: produkce, inscenace, vývoj, hodnocení, sandbox.
• 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í.
• rozsah rozpočtu: nákladové středisko, zákazník distributora, interní oddělení nebo smlouva.
• vlastník: jmenovaný tým nebo odpovědná osoba.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: neznámý, zdravý, degradovaný, neautorizovaný, kvóta_vyčerpaná, zakázáno.
• emergency_disable: okamžité blokování směrování nezávislé na běžném stavu zásad.

Ponechte tento model jako poskytovatele neutrální, ale nemažte realitu poskytovatele. Klíč vázaný na antropický pracovní prostor a klíč Gemini vázaný na projekt Google Cloud 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ý pro 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 oddělenou 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íč odvozování 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 tenant a rozsah klíčů downstream API.
• Požadovaný profil modelu nebo ID modelu specifického pro poskytovatele.
• Schopnost 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, kreditní rezervace a nákladové středisko.
• Stav limitu sazby a tlak kvóty.
• Metadata pověření, stav, prostředí a vazba tenanta.

Stroj 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",
  "požadavky_pověření": {
    "class": "runtime",
    "životní prostředí": "výroba",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "zdravý"
  },
  "rozhodnutí": "povolit",
  "credential_id": "cred_8f2...",
  "audit_reason": "Pověření BYOK nájemce odpovídá runtime textovému profilu a zásadám dat"
}

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

S BYOK zacházet jako s přístupem vlastněným nájemcem, nikoli s volnou kapacitou

BYOK změ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 zákazníka a poskytovatele.

Doporučené ovládací prvky BYOK:

• Jeden záznam úložiště 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 rotace, který zákazníkovi umožňuje 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, prodejce 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řidejte kontroly stavu před výstupem bez úniků 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 odesí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 kontroly levné, omezené a označené jako syntetický provoz v telemetrii a fakturaci.

Měly by se spustit zdravotní kontroly:

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

Výměna: automatické kontroly zachytí klíče s prošlou platností nebo s nedostatečným rozsahem dříve, 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, nikoli 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. Importujte náhradní přihlašovací údaje 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. V případě potřeby povolte stínovou způsobilost pro malý úsek bezpečného syntetického nebo nízkorizikového provozu.
4. Postupně převádějte produkční provoz ze starých přihlašovacích údajů na nové.
5. Sledujte chyby, latenci, kvótu a atribuci 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 prostřednictvím starých přihlašovacích údajů.

Termíny střídání by měly být viditelné v provozních zobrazeních a výstrahá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 Gemini a další klíče API cloudové platformy použijte omezení API/služby a vhodná omezení aplikací, pokud jsou k dispozici. U projektů poskytovatelů, pracovních prostorů a účtů služeb se vyhněte širokým organizačním oprávněním, pokud stačí runtime klíč v rozsahu projektu.

Doporučení: udržujte 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 bezpečnostním úkolem, který lze pod tlakem přeskočit.

Výměna: 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ídat tomu, kdo importoval pověření, co mu bylo povoleno, která rozhodnutí o směrování ho vybrala, kdy selhala a kdy byla otočena nebo zrušena.

Zaznamenejte tyto události:

• Přihlašovací údaje byly vytvořeny nebo importovány.
• Metadata se změnila, včetně povolených koncových bodů, vazby tenanta nebo zásad dat.
• Provedena zdravotní kontrola a zaznamenán výsledek.
• Pověření vybrané podle zásad směrování pro požadavek.
• Dešifrování pověření požadované identitou interní služby.
• Volání poskytovatele selhalo kvůli chybě ověření, autorizace, kvóty nebo omezení.
• Otáčení zahájeno, provoz se přesunul, 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 můžete ochutnat 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ádat 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 oprávnění.
• Svažte přihlašovací údaje BYOK k původu účtu nájemce a poskytovatele.
• Vyžadovat schválení nástrojem zásad před výběrem jakýchkoli přihlašovacích údajů proti proudu.
• Před způsobilostí k produkci spusťte bezodkladně bezpečné kontroly stavu.
• Používejte rotaci dvou slotů s postupným přesunem provozu a zrušením na straně poskytovatele.
• Pokud je to možné, použijte omezení na straně poskytovatele.
• 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 zakázá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 v rozsahu brány; samotná brána řídí přístup poskytovatele proti proudu. Toto oddělení vám umožní zachovat nejmenší oprávnění, atribuci 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í informace

• týmem orientovaná správa klíčů API a reakce na únik
• zásady směrování s ohledem na uchovávání dat
• ledger-1. a ovládací prvky atribuce nákladů