Voltes de credencials de proveïdors per a passarel·les d'AI multimodel: temps d'execució, administració, facturació i accés BYOK separats

Les claus de l'API descendent i les credencials del proveïdor amunt resolen diferents problemes. Una clau de desenvolupador emesa per la vostra passarel·la identifica l'aplicació, l'equip, l'arrendatari, el pressupost i el context de la política. Una clau de proveïdor aigües amunt permet a la passarel·la gastar diners i accedir a models en un compte de proveïdor. Tractar-los com el mateix tipus de secret és com els equips acaben amb una clau sense restriccions en un projecte compartit, credencials d'administrador en serveis en temps d'execució i cap manera fiable de respondre quin inquilí ha causat quin càrrec del proveïdor.

El patró pràctic és una caixa de credencials del proveïdor: un pla de control dedicat per importar, classificar, emmagatzemar, seleccionar, girar i auditar les credencials amunt. S'ha de situar darrere de l'encaminador, el llibre de facturació, el motor de polítiques i el flux de treball d'operacions, no dins del codi d'aplicació, fitxers de configuració del model, registres d'inquilí o esdeveniments d'anàlisi.

El problema del lector: les credencials amunt esdevenen una infraestructura invisible

La majoria de desplegaments multimodel comencen amb un objectiu senzill: dirigir una sol·licitud compatible amb OpenAI al millor proveïdor disponible. A continuació, apareixen més comptes: un projecte de proveïdor per a la producció, un altre per a l'avaluació, un espai de treball antròpic per a una unitat de negoci, un projecte de Google Cloud per a Gemini i diverses claus subministrades pel client per als contractes BYOK.

El risc no és només una fuga secreta. És la pèrdua del context d'autorització. Una clau de proveïdor vàlida pot ser tècnicament capaç de trucar a un punt final, però la passarel·la encara necessita saber si aquesta clau està permesa per a aquest inquilí, aquesta família de models, aquesta política de retenció de dades, aquest pressupost, aquesta regió i aquesta ruta d'automatització.

Fet: les plataformes de proveïdors exposen diferents límits de compte i tipus de credencials. L'OpenAI documenta els projectes i els comptes de servei, i els permisos de clau de l'API del compte de servei per defecte per a l'accés de lectura i escriptura als recursos de l'API del projecte. L'OpenAI també exposa els objectes clau de l'API d'administració per separat de l'ús normal de l'API del projecte/del temps d'execució. Anthropic documenta els espais de treball com a límit organitzatiu i afirma que els punts finals de l'API d'administració requereixen claus de l'API d'administració diferents de les claus de l'API estàndard; Anthropic també assenyala que les claus de l'API estan lligades a l'espai de treball on es creen i no es poden moure entre espais de treball. La documentació de la clau de l'API Gemini de Google diu que totes les claus de l'API Gemini estan associades a un projecte de Google Cloud i recomana restriccions de l'API per reduir els danys si una clau està compromesa.

Recomanació: no creeu un camp genèric "provedor_clau" i ho digueu fet. Creeu un inventari de credencials que preservi els límits específics del proveïdor alhora que exposa un model de política normalitzat a la passarel·la.

Definiu una taxonomia de credencials abans d'acceptar claus

Una caixa forta hauria de rebutjar credencials ambigües. En el moment de la importació, l'operador o el flux de treball d'automatització ha de classificar la credencial. Com a mínim, utilitzeu aquestes categories:

• Credencials d'inferència en temps d'execució: que s'utilitza la passarel·la per trucar a punts d'extrem d'inferència del model, com ara xat, respostes, incrustacions, moderació, transcripció o generació d'imatges, en funció de l'assistència del proveïdor.
• Credencials d'automatització de l'administrador: s'utilitzen per gestionar organitzacions del proveïdor, espais de treball, projectes, usuaris, claus o recursos administratius. Aquests mai haurien d'estar al camí de sol·licitud de temps d'execució.
• Credencials de facturació i d'informes: s'utilitzen per recuperar l'ús, les factures, els costos o els informes d'organització quan els proveïdors admeten aquestes API. Manteniu-los separats de les claus d'inferència perquè les tasques d'informes no generin ús del model.
• Credencials només per a l'avaluació: s'utilitzen pels fluxos de treball de referència, control de qualitat, migració o escenificació. Haurien de tenir quotes baixes, etiquetes d'entorn clares i no elegibles per a la producció alternativa.
• Credencials BYOK del client: claus subministrades pel client vinculades a un inquilí, compte de proveïdor, contracte i política de dades concrets. No s'han d'agrupar en l'encaminament compartit tret que el client s'hi posi explícitament.

Aquesta taxonomia no és només documentació. Hauria d'impulsar el control d'accés, l'elegibilitat de l'encaminament, les alertes i els fluxos de treball de rotació. Si s'importa una credencial sense una categoria, propietari, límit de compte de proveïdor i ús permès, hauria de romandre desactivada.

Emmagatzema els secrets en una caixa de seguretat, no en els registres del producte

La volta ha de ser l'únic component que pot desxifrar les credencials amunt. Altres sistemes poden emmagatzemar referències, hash, camps d'estat i metadades de polítiques, però no el valor de la credencial en si.

No emmagatzemeu secrets aigües amunt en aquests llocs

• Files de perfil d'inquilí.
• Fitxers de configuració d'encaminament del model.
• Registres sol·licitats o traça spans.
• Càrregues útils d'esdeveniments d'Analytics.
• Variables CI orientades al desenvolupador.
• Entrades de suport, eines de xat o captures de pantalla.

Un disseny de volta utilitzable té dos plans. El avió secret emmagatzema material de credencials xifrat i controla estrictament les operacions de desxifrat. El pla de metadades emmagatzema atributs no secrets utilitzats per l'encaminament i el govern. Normalment, l'encaminador només hauria de necessitar un identificador de credencial i una recuperació de secrets a la memòria de curta durada en el moment de l'enviament, no un accés ampli a la base de dades a totes les claus del proveïdor.

Protegiu la caixa forta com a infraestructura d'alt valor: xifratge de sobre o KMS gestionat, identitats de servei estrictes, procediments de trencament de vidre, proves de còpia de seguretat i restauració, revisió d'accés i alertes sobre volum de desxifrat inusual. Una volta central simplifica la governança, però també concentra el risc. Aquesta és la compensació.

Adjunteu metadades de política a cada credencial

El model de metadades ha de ser prou explícit perquè la passarel·la pugui decidir si una credencial és apte abans que toqui un punt final del proveïdor.

Un registre de credencials pràctics inclou:

• credential_id: identificador intern immutable.
• proveïdor: OpenAI, Anthropic, Gemini, Azure OpenAI o un altre adaptador.
• provider_account_boundary: organització, projecte, espai de treball, projecte al núvol, subscripció o equivalent.
• credential_class: temps d'execució, administració, facturació, avaluació o BYOK.
• entorn: producció, posada en escena, desenvolupament, avaluació, sandbox.
• tenant_binding: credencial de plataforma compartida, inquilí únic, grup d'inquilins o inquilí BYOK del client.
• allowed_model_families: per exemple, generació de text, incrustacions, visió, imatge, àudio o perfils de model específics.
• allowed_endpoints: capacitats de passarel·la normalitzades assignades als punts finals del proveïdor.
• data_policy: classe de retenció permesa, classe de registre, requisit de residència i restriccions de funcions.
• budget_scope: centre de costos, client distribuïdor, departament intern o contracte.
• propietari: equip nomenat o persona responsable.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: desconegut, saludable, degradat, no autoritzat, quota_exhausted, desactivat.
• emergency_disable: bloc d'encaminament immediat independent de l'estat normal de la política.

Mantingueu aquest model neutral pel que fa al proveïdor, però no esborreu la realitat del proveïdor. Una clau vinculada a un espai de treball antròpic i una clau Gemini lligada a un projecte de Google Cloud no són intercanviables només perquè totes dues poden generar text. La passarel·la necessita aquesta procedència per a auditories, devolució de càrrec i migració segura per error.

Separa el temps d'execució, l'administració i l'accés a la facturació

La regla més important és senzilla: una clau utilitzada per a la inferència en temps d'execució no hauria de gestionar organitzacions de proveïdors, espais de treball, usuaris, projectes o recursos administratius.

El trànsit en temps d'execució és de gran volum i està exposat a la superfície operativa més gran. Passa per encaminadors de sol·licitud, lògica de reintent, controladors de transmissió, adaptadors de models i fluxos de treball d'incidències. Les credencials d'administrador són de baixa freqüència i d'alt impacte. Haurien de viure darrere d'una ruta d'aprovació independent amb TTL curts, anomenada aprovació humana si escau, registres forts i sense elegibilitat per a l'encaminament en temps d'execució.

Les credencials de facturació també mereixen una separació. Un treball d'informes que concilii les factures no hauria de poder generar finalitzacions, i una clau d'inferència en temps d'execució no hauria de ser l'única manera de recuperar informes d'ús. Quan un proveïdor no ofereix una separació detallada, compenseu a la passarel·la: aïlleu la credencial, limiteu quina identitat de servei interna la pot recuperar i registreu cada ús.

Recomanació: feu que la classe de credencials sigui un límit d'autorització, no una etiqueta. Un despatxador en temps d'execució no hauria de poder sol·licitar el desxifrat d'una credencial d'administrador encara que un error de configuració faci referència al seu identificador.

Crea un motor de polítiques de selecció de credencials

La selecció de credencials s'ha de fer després que la passarel·la autentiqui la persona que truca aigües avall i abans que s'intenti cap trucada al proveïdor. El motor de polítiques hauria d'unir diverses entrades:

• Identificador de llogater i àmbit de la clau de l'API posterior.
• Perfil de model sol·licitat o identificador de model específic del proveïdor.
• Capacitat del punt final: xat, incrustacions, imatge, àudio, lots, fitxers, eines o automatització de l'administració.
• Requisits de retenció de dades i residència.
• Pressupost, reserva de crèdit i centre de costos.
• Estat de límit de tarifa i pressió de quota.
• Metadades de credencials, salut, entorn i vinculació d'inquilí.

El motor hauria de tornar un dels tres resultats: permetre amb una credencial seleccionada, denegar amb un motiu de política o requerir aprovació. Les denegacions han de ser prou precises perquè els equips d'operacions solucionin el problema sense revelar material secret als desenvolupadors.

Exemple de decisió:

{
  "tenant_id": "tenant_42",
  "requested_profile": "prod-text ràpid",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "temps d'execució",
    "environment": "producció",
    "tenant_binding": "arrendatari_42",
    "allowed_model_family": "text",
    "health_status": "saludable"
  },
  "decision": "permetre",
  "credential_id": "cred_8f2...",
  "audit_reason": "La credencial de l'arrendatari BYOK coincideix amb el perfil de text en temps d'execució i la política de dades"
}

No implementeu la alternativa com a "prova la següent clau". La política de reserva ha de tornar a executar. Una credencial de plataforma compartida pot ser vàlida per a l'accés del proveïdor, però no vàlida per a un client només BYOK. Una credencial d'un altre projecte pot tenir quota, però pot infringir els requisits d'atribució de costos o de retenció.

Gestiona BYOK com a accés de propietat de l'inquilí, no com a capacitat excedent

BYOK canvia el model de confiança. El client ha proporcionat la credencial perquè el seu trànsit es pugui carregar, governar o aïllar dins del seu compte de proveïdor. Aquesta credencial ha d'estar vinculada a la procedència del compte de l'arrendatari del client i del proveïdor.

Controls BYOK recomanats:

• Un registre de volta per client, proveïdor, límit del compte i entorn.
• No hi ha encaminament entre inquilins mitjançant les credencials BYOK.
• No s'utilitza com a capacitat alternativa compartida tret que el client s'activi explícitament.
• Estat de salut visible per al client que no revela la clau en brut.
• Flux de treball de rotació independent que permet al client afegir un reemplaçament abans que es desactivi la clau antiga.
• Atribució clara a l'anàlisi d'ús i a les factures: l'arrendatari de la passarel·la, el límit del compte del proveïdor, l'identificador de credencials, el perfil del model i l'identificador de traça de la sol·licitud.

Per a les agències, els distribuïdors i l'automatització de l'API per a partners, BYOK pot ser més complex perquè un servei pot subministrar inquilins i credencials mitjançant programació. La mateixa regla encara s'aplica: l'automatització pot importar i lligar credencials, però no hauria de difuminar la propietat de l'inquilí.

Afegiu comprovacions prèvies de l'estat del vol sense filtracions de sol·licituds

Una credencial pot fallar per molts motius: clau revocada, espai de treball incorrecte, falta d'accés al model, facturació desactivada, exhauriment de quotes, restricció de punts finals, discrepància de polítiques regionals o interrupció del proveïdor. Descobrir que només després d'arribar una sol·licitud de producció crea incidents sorollosos.

Utilitzeu comprovacions de salut que validin la capacitat sense enviar sol·licituds del client. Una comprovació sintètica pot trucar a un punt final mínim, enumerar els models permesos si escau o enviar un missatge fix inofensiu si aquesta és l'única opció pràctica. Mantingueu aquests xecs econòmics, amb tarifes limitats i etiquetats com a trànsit sintètic en telemetria i facturació.

Les comprovacions de salut s'han d'executar:

• A la importació de credencials.
• Abans d'activar una credencial per a l'encaminament de producció.
• Després dels canvis de restricció del proveïdor.
• Durant el tall de rotació.
• Periòdicament per a credencials amb elegibilitat de producció.

Compartiment: els xecs automatitzats detecten les claus caducades o amb un abast insuficient, però els xecs mal dissenyats poden generar trucades innecessàries al proveïdor, sorolls de facturació o falses alarmes durant les interrupcions del proveïdor. Emmagatzemeu el resultat de salut amb marca de temps, classe d'error del proveïdor, punt final provat i família de models provada. No deseu valors secrets ni indicacions sensibles.

Gira amb dues ranures, sense cap substitució arriscada

La rotació de credencials no hauria de ser una operació d'eliminació i resa. Utilitzeu un model de rotació de dues ranures:

1. Importa la credencial de substitució com a inactiva, amb metadades completes i propietari.
2. Executeu comprovacions d'estat sintètiques per als punts finals, les famílies de models i el límit del compte previstos.
3. Activeu l'elegibilitat a l'ombra per a una petita porció de trànsit sintètic segur o de baix risc si escau.
4. Canvia el trànsit de producció gradualment de la credencial antiga a la nova.
5. Superviseu els errors, la latència, la quota i l'atribució de costos per identificador de credencial.
6. Congela el retorn a la credencial antiga un cop la credencial nova sigui estable.
7. Revoca la credencial antiga del proveïdor i marca el registre de la caixa forta com a revocat.
8. Verifiqueu que no hi hagi cap desxifrat ni trucades al proveïdor mitjançant la credencial antiga després de la revocació.

Els terminis de rotació haurien de ser visibles a les visualitzacions d'operacions i a les alertes. La rotació d'emergència necessita un camí més curt: desactiveu la credencial, bloquegeu l'encaminament, activeu la substitució aprovada i conserveu tots els registres d'auditoria per a la revisió d'incidències.

Restringeix les claus del proveïdor quan el proveïdor ho admet

La política de passarel·la és necessària, però les restriccions del proveïdor redueixen el radi d'explosió si una clau està compromesa o s'utilitza malament. Per a les claus d'API Gemini i altres de plataforma núvol, utilitzeu restriccions d'API/servei i restriccions d'aplicació adequades quan estiguin disponibles. Per als projectes de proveïdors, espais de treball i comptes de servei, eviteu privilegis organitzatius amplis quan n'hi ha prou amb una clau d'execució de l'àmbit del projecte.

Recomanació: mantingueu una llista de verificació de restriccions del proveïdor per a cada classe de credencials. La llista de verificació hauria de formar part de l'aprovació d'importació i de l'aprovació de la rotació, no una tasca de seguretat independent que es pugui ometre sota pressió.

Compartiment: les restriccions del proveïdor afegeixen una sobrecàrrega operativa. Els nous punts finals, famílies de models, regions o funcions d'automatització poden requerir canvis de política i restriccions. Això és preferible que descobrir després d'una filtració que una clau podria accedir a totes les càrregues de treball d'un projecte compartit.

Conserveu un registre d'auditoria de credencials només per a afegir

Una pista d'auditoria hauria de respondre qui va importar una credencial, què se li permetia fer, quines decisions d'encaminament la van seleccionar, quan va fallar i quan es va rotar o revocar.

Registreu aquests esdeveniments:

• Credencial creada o importada.
• S'han canviat les metadades, inclosos els punts finals permesos, l'enllaç d'inquilí o la política de dades.
• S'ha executat la revisió de l'estat i s'ha registrat el resultat.
• Credential seleccionada per la política d'encaminament per a una sol·licitud.
• Desxifrat de credencials sol·licitat per una identitat de servei interna.
• La trucada del proveïdor ha fallat a causa d'un error d'autenticació, autorització, quota o restricció.
• S'ha iniciat la rotació, s'ha canviat el trànsit, s'ha revocat la credencial antiga.
• Desactivació d'emergència activada o esborrada.
• S'ha accedit a la credencial d'administrador o de trencament de vidre.

No introduïu valors de credencials en brut als esdeveniments d'auditoria. Utilitzeu identificadors de credencials, límits del compte del proveïdor, identificadors de traça de sol·licitud, identitats d'actor i motius de decisió de polítiques. Per al trànsit d'execució de gran volum, podeu provar la telemetria de desxifrat detallada, però la selecció d'encaminament i l'atribució de costos haurien de romandre prou completes per a la facturació i la resposta a incidents.

Llista de verificació d'implementació

• Creeu una taxonomia de credencials i rebutgeu les importacions no classificades.
• Mou tots els secrets del proveïdor a una caixa de seguretat encriptada dedicada.
• Emmagatzema les metadades d'encaminament per separat del material secret.
• Feu que les credencials d'execució, d'administració, de facturació, d'avaluació i de BYOK siguin classes d'autorització separades.
• Enllaceu les credencials de BYOK a la procedència del compte de l'inquilí i del proveïdor.
• Requereix l'aprovació del motor de polítiques abans de seleccionar qualsevol credencial amunt.
• Executa comprovacions de salut ràpides i segures abans de la producció.
• Utilitzeu la rotació de dues ranures amb un canvi de trànsit gradual i la revocació del proveïdor.
• Aplica restriccions del proveïdor sempre que estigui disponible.
• Manteniu els registres d'auditoria només d'annex per a la importació, l'ús, els errors, la rotació i la revocació.
• Mantingueu les credencials d'administrador darrere dels controls de trencament de vidre: TTL curt, aprovació amb nom, registre fort, sense ús en temps d'execució.

Conclusió accionable

Comenceu fent un inventari de totes les credencials de proveïdor aigües amunt que utilitzen actualment la passarel·la, els scripts, les feines de CI, els arnes d'avaluació i l'automatització dels socis. Per a cadascun, assigneu una classe, un propietari, un límit del compte del proveïdor, l'enllaç d'inquilí, els punts finals permesos, les famílies de models permeses, el termini de rotació i l'estat d'inhabilitació d'emergència. Qualsevol cosa que no pugueu classificar s'hauria de desactivar o posar en quarantena fins que tingui un propòsit clar.

A continuació, apliqueu una regla arquitectònica: els desenvolupadors aigües avall reben claus d'abast de passarel·la; la passarel·la sola controla l'accés del proveïdor aigües amunt. Aquesta separació us permet preservar el mínim privilegi, l'atribució de l'arrendatari, la precisió de la facturació, l'encaminament de la política de dades i l'automatització segura, fins i tot quan es multipliquen els proveïdors, els projectes, els espais de treball i els clients de BYOK.

Lectura relacionada

• gestió de claus de l'API i resposta a les fuites d'equip
• polítiques d'encaminament de data-retention-aware
• FAQ

  Preguntes freqüents

  Les credencials del proveïdor s'han d'emmagatzemar als registres dels inquilins?

  No. Emmagatzemeu el material de credencials xifrat en una caixa de seguretat dedicada. Els registres d'inquilí poden fer referència a un identificador de credencial i metadades de política, però no han de contenir secrets de proveïdors amunt.

  Es pot utilitzar una clau de proveïdor tant per a la inferència en temps d'execució com per a l'automatització de l'administració?

  Eviteu-ho. Les claus d'execució estan exposades a camins de sol·licituds de gran volum, mentre que les claus d'administració poden canviar els recursos de l'organització, l'espai de treball o el projecte. Separeu-los amb diferents classes de credencials, identitats de servei, aprovacions i pistes d'auditoria.

  Com s'han de gestionar les credencials de BYOK en una passarel·la multi-inquilí?

  Enllaceu cada credencial de BYOK amb l'arrendatari del client, el límit del compte del proveïdor, l'entorn i l'ús permès. No utilitzeu les claus subministrades pel client com a capacitat de reserva compartida tret que el client s'hi active explícitament.

  Quina és la manera més segura de girar les claus del proveïdor aigües amunt?

  Utilitzeu un procés de dues ranures: importeu el reemplaçament com a inactiu, executeu comprovacions de salut, canvieu gradualment el trànsit, superviseu els errors i l'atribució de costos, revoqueu la credencial antiga del proveïdor i comproveu que encara no l'utilitzi cap trànsit.