Gestió de claus de l'API LLM per a equips: aïllament, rotació, límits de despesa i resposta a fuites

Una clau d'API LLM compartida és convenient fins a la primera filtració, factura inexplicable o interrupció de la producció. L'objectiu pràctic de la gestió de claus de l'API no és només mantenir un secret de credencials. Es tracta de limitar el radi de l'explosió, atribuir l'ús, girar amb seguretat, detectar despeses anormals i revocar l'accés sense trencar aplicacions no relacionades.

Aquesta guia ofereix als equips un model operatiu per a les claus de l'API LLM per a proveïdors, passarel·les, aplicacions internes, agències i productes orientats al client. Separa els fets de seguretat verificats de les opcions d'implementació recomanades i evita suposar que tots els proveïdors exposaran els mateixos controls.

El model de funcionament: cada clau necessita un límit

Una estratègia de clau útil comença amb una pregunta: què hauria de fallar si s'abusa d'aquesta clau o es revoca? Si la resposta és "tota l'empresa", la clau és massa àmplia.

Fet: la guia de seguretat de les claus de l'API d'OpenAI recomana que cada membre de l'equip utilitzi una clau d'API única, diu que compartir claus va en contra de les seves Condicions d'ús i recomana assignar permisos a claus individuals quan sigui compatible. Les directrius d'OpenAI també aconsellen no desplegar claus API en entorns del costat del client, com ara navegadors o aplicacions mòbils, perquè es pot abusar de les claus exposades per fer sol·licituds en nom del propietari.

Recomanació: creeu claus al voltant dels límits operatius, no de la comoditat. Els límits comuns inclouen:

• Entorn: producció, posada en escena, desenvolupament, sandbox.
• Aplicació: backend de chatbot, processador de documents, assistent de codificació, flux de treball d'anàlisi.
• Propietari: equip, compte de servei, desenvolupador, client d'agència, llogater.
• Nivell de risc: flux de treball públic, automatització interna, treball per lots, integració experimental.
• Proveïdor o ruta: proveïdor amunt A, proveïdor B, grup de models aprovat o ruta de passarel·la.

Un bon valor predeterminat per a un equip en creixement és: una clau de producció per aplicació o servei, una clau de no producció per entorn i claus separades per a l'automatització d'alt risc o l'ús a nivell de client. Les agències i els distribuïdors haurien de preferir les claus virtuals a nivell de client en lloc de compartir les credencials del proveïdor amunt.

No poseu mai les claus del proveïdor als clients distribuïts

Els navegadors, les aplicacions per a mòbils, les extensions d'escriptori, els connectors públics i els scripts del client són llocs hostils per a les credencials de proveïdor en brut. Encara que enfosquiu la clau, el programari distribuït es pot inspeccionar, copiar o interceptar.

Fet: l'OpenAI adverteix explícitament de no desplegar claus API en entorns del costat del client. La investigació sobre aplicacions mòbils també ha informat de fuites persistents de credencials de l'API de LLM a les aplicacions d'iOS, donant suport al mateix advertiment pràctic: les credencials incrustades als clients distribuïts solen escapar.

Recomanació: utilitzeu un patró de backend o passarel·la:

1. El client s'autentica a la vostra aplicació mitjançant una sessió d'usuari, un JWT, un testimoni de client o una credencial de curta durada.
2. El vostre backend valida l'usuari, l'arrendatari, el pla i l'operació sol·licitada.
3. El vostre backend o la vostra passarel·la de l'API AI truca al proveïdor de LLM amunt mitjançant credencials protegides del costat del servidor.
4. La resposta es retorna al client després de les comprovacions de la política, el registre i la comptabilitat de costos.

Aquest disseny us permet fer complir les regles del producte abans que es produeixi la despesa. Per exemple, un usuari de pla gratuït es pot limitar a models més petits, un inquilí de pagament pot rebre quotes diàries més elevades i un flux de treball d'administració intern pot utilitzar una ruta independent amb un control més estricte.

Creeu un inventari de claus abans de necessitar una resposta a un incident

Sovint, els equips descobreixen durant una filtració que ningú sap quin servei és el propietari de la clau exposada. Això és un error d'inventari.

Fet: OWASP API Security Top 10 2023 inclou una gestió inadequada de l'inventari com un risc important de seguretat de l'API. Per a la infraestructura de LLM, l'inventari de claus forma part de l'inventari de l'API: heu de saber quines credencials existeixen, a què hi poden accedir i qui són el propietari.

Recomanació: cada clau hauria de tenir metadades. Com a mínim, seguiu:

• Nom de la clau i ID de clau interna.
• Equip del propietari i contacte d'emergència.
• Entorn: producció, posada en escena, desenvolupament, sandbox.
• Propòsit: aplicació, flux de treball, llogater, integració o ús del desenvolupador.
• Proveïdors, models, punts finals o rutes permesos quan s'admeten.
• Data de creació, marca de temps del darrer ús i data de revisió planificada.
• Gasta sostre o quota.
• Estat de rotació i configuració de desplegament enllaçat.

Utilitzeu una convenció de nomenclatura que es pugui llegir a les alertes. Per exemple:

prod-supportbot-teamcx-gpt4class-2026q3stg-docprocessor-platform-lowcost-2026q3
tenant-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

El format exacte importa menys que la coherència. L'objectiu és que una alerta pugui dir "l'estàndard de l'inquilí-acme-prod-ha superat el seu llindar diari" i el propietari responsable sàpiga què ha de fer.

Aplica el mínim privilegi on la plataforma ho permet

No tots els proveïdors o passarel·les exposaran controls de permisos idèntics, però el principi és coherent: una clau només hauria de poder fer el que necessita la seva càrrega de treball.

Recomanació: restringeix les claus amb un o més dels controls següents quan s'admet:

• Projecte: enllaça les claus d'un projecte en lloc d'una organització sencera.
• Model: només permeten models aprovats; bloqueja models cars o experimentals per defecte.
• Punt final: permet completar el xat però denegar els punts finals administratius no relacionats.
• Ruta del proveïdor: permet una ruta de passarel·la en comptes d'accés directe a tots els proveïdors aigües amunt.
• Taxa: limiteu les sol·licituds per minut o les sol·licituds simultànies.
• Pressupost: apliqueu límits de despesa per clau, per equip o per inquilí.

Per exemple, una clau de posada en escena normalment no necessita accés al model de producció més car. Un treballador de classificació de documents probablement no necessita accés a la generació d'imatges. Una clau d'inquilí orientada al client no hauria de poder consumir el pressupost d'un altre inquilí.

Dissenyeu controls de despesa en capes

La seguretat de l'API de LLM i el control de costos es superposen. Sovint, una clau filtrada es detecta com una anomalia de facturació abans que es detecti com un esdeveniment de seguretat.

Fet: les instruccions de seguretat del compte d'OpenAI recomana límits de despesa raonables i assenyala que les claus d'API separades poden facilitar la visualització de l'ús per funció, equip, producte o projecte. Els informes d'ús d'OpenAI també admeten anàlisis detallades mitjançant camps com ara l'identificador del projecte, l'identificador d'usuari, l'identificador de clau de l'API, el model, el lot i el nivell de servei.

Recomanació: utilitzeu límits en capes en lloc d'un límit global:

• Límit per clau: impedeix que una credencial esgoti tot el pressupost.
• Límit per equip: fa que l'ús del departament sigui visible i responsable.
• Límit per inquilí: aïlla l'ús del client en escenaris de SaaS i d'agència.
• Llindar d'anomalia diari: activa alertes quan l'ús es desvia dels patrons normals.
• Parada d'emergència global: permet una suspensió ràpida quan l'ús abusiu està actiu.

Els límits durs són útils, però poden interrompre treballs per lots legítims. Un patró de producció més segur és una seqüència de controls:

1. Alerta del 50% de la despesa diària prevista.
2. Ampliar al 80 per cent.
3. Acelera el trànsit no crític al 100%.
4. Bloqueja només la clau, l'arrendatari o la ruta ofensiva abans d'utilitzar un tancament global.

Compartiment: els pressupostos estrictes redueixen el risc de facturació, però poden generar un risc de disponibilitat. Límits de nivell per càrrega de treball: el trànsit de producció interactiu, el trànsit de pagament orientat al client, els treballs en segon pla, els experiments i els espais de proves de desenvolupadors no haurien de fallar tots de la mateixa manera.

Fes un seguiment de l'ús per clau i actor lògic

Una clau identifica la credencial. És possible que no identifiqui l'usuari, l'arrendatari, la funció o el flux de treball real que va provocar la sol·licitud. Per obtenir analítiques útils de l'ús de la IA, registreu les dimensions tècniques i empresarials.

Recomanació: recopila els camps següents per a cada sol·licitud on la privadesa i la política ho permeten:

• Identificador de sol·licitud i marca de temps.
• Identificador de clau de l'API o ID de clau virtual.
• Identificador d'aplicació, equip, inquilí, usuari o flux de treball.
• Proveïdor, model, ruta i nivell de servei.
• Recomptes de fitxes de sol·licitud i finalització o unitats d'ús equivalents.
• Cost estimat.
• Latència, codi d'estat, recompte de reintents i classe d'error.

No transformeu l'observabilitat dels costos en una recollida de dades innecessària. Eviteu emmagatzemar les sol·licituds completes de manera predeterminada si poden contenir dades personals, secrets de clients o contingut regulat. En molts casos, els identificadors d'usuari, els identificadors d'inquilí, els recomptes de testimonis i els noms de models amb funció resum són suficients per a la detecció d'anomalies i de devolució de càrrec.

Rotació sense temps d'inactivitat: un flux de treball segur

Fet: la guia de gestió de claus del NIST tracta la gestió de claus com una disciplina del cicle de vida, que inclou la generació, l'emmagatzematge, l'activació, la rotació, la suspensió, la revocació i la destrucció. Per a les claus de l'API LLM, la rotació no és una tasca de seguretat única; és un flux de treball operatiu.

Recomanació: utilitzeu aquest procés de rotació sense temps d'inactivitat:

1. Creeu la clau de substitució. Coincideix amb els permisos, el pressupost, la ruta i les metadades necessaris. No revoquis la clau antiga encara.
2. Deseu-lo al gestor de secrets. Eviteu fitxers locals, missatges de xat, entrades i variables d'entorn enganxades.
3. Implementeu la configuració de manera gradual. Actualitzeu un servei, una regió, un grup de treballadors o un segment d'inquilí alhora.
4. Verifiqueu el moviment del trànsit. Confirmeu que les sol·licituds arribin amb la clau nova i que les taxes d'error i la latència segueixen sent normals.
5. Congela les escriptures a la clau antiga. Impedeix que els nous desplegaments hi facin referència.
6. Revoca la clau antiga. Quan el trànsit s'hagi mogut, desactiveu-la en lloc de deixar-la com a alternativa oblidada.
7. Auditoris que no estan disponibles. Cerqueu registres, manifestos de desplegament, magatzems secrets, variables CI i errors de temps d'execució per a l'identificador de clau antiga.

Per a les aplicacions que encara utilitzen variables d'entorn estàtiques, la rotació serà fràgil. Passeu cap a la càrrega secreta dinàmica, la configuració centralitzada o les claus virtuals gestionades per passarel·la. Com a mínim, documenteu quin desplegament ha de canviar abans de la revocació.

Llibre d'execució de resposta a filtracions

Quan una clau es filtra, la velocitat importa. La resposta s'ha d'escriure abans de l'incident, no improvisada en un pànic de facturació.

Contenció immediata

1. Revocar o suspendre la clau exposada.
2. Si la revocació podria interrompre la producció, emeteu primer un substitut i canvieu el trànsit crític immediatament.
3. Bloqueja la ruta, l'arrendatari o el proveïdor si l'abús encara està actiu.
4. Conserva els registres necessaris per identificar un mal ús.

Investigació

1. Identifiqueu on va aparèixer la clau: dipòsit, paquet d'interfície, aplicació mòbil, fitxer de registre, bitllet d'assistència, eina de proveïdor o xat.
2. Cerca l'últim ús legítim conegut.
3. Compara l'ús abans i després de la sospita d'exposició.
4. Reviseu els models utilitzats, volum de sol·licitud, cost, geografia si està disponible i codis d'estat inusuals.
5. Comproveu si també es poden exposar secrets dependents o sistemes adjacents.

Recuperació i prevenció

1. Gira les credencials dependents si el mateix entorn pot haver filtrat més d'un secret.
2. Notifiqui l'equip del propietari i les parts interessades dels clients afectats quan escaigui.
3. Afegiu l'exploració secreta als repositoris i canalitzacions CI.
4. Evita la repetició movent les trucades del client darrere d'un backend o passarel·la.
5. Documenteu la cronologia de l'incident, la causa arrel, l'impacte dels costos i les millores de control.

Predicció: a mesura que els equips connectin més agents, connectors, eines d'automatització i fluxos de treball específics del client als LLM, les filtracions clau s'assemblaran cada cop més a incidents de costos primer i incidents de seguretat, en segon lloc. Els equips amb atribució per clau i controls pressupostaris els resoldran més ràpidament que els equips que utilitzen una credencial compartida.

Claus gestionades per passarel·la per a equips de diversos proveïdors

Si la vostra organització utilitza diversos proveïdors de LLM, les claus de proveïdor directe poden crear una governança dispersa: taulers diferents, vistes de facturació diferents, models de permisos diferents i processos de rotació inconsistents.

Una capa de claus gestionada per passarel·la pot simplificar-ho emetent claus orientades a l'aplicació i mantenint amagades les credencials del proveïdor amunt. Les aplicacions criden a un punt final d'API compatible amb OpenAI, mentre que la passarel·la gestiona l'encaminament, l'anàlisi d'ús, l'atribució de facturació i l'aplicació de polítiques.

Recomanació: considereu una passarel·la o una capa de servidor intermediari quan necessiteu:

• Un lloc per gestionar les claus d'equip de diversos proveïdors.
• Facturació unificada de l'API d'IA i informes de despesa per clau.
• Claus virtuals a nivell de client per a agències, distribuïdors o llogaters de SaaS.
• Llistes permeses de models centrals, polítiques de rutes i suspensió d'emergència.
• Atribució de l'ús per inquilí, funció, flux de treball o client associat.

Compartiment: una passarel·la millora el govern i amaga les credencials amunt, però passa a formar part del camí de la sol·licitud. Superviseu-lo com la infraestructura de producció: la latència, la disponibilitat, les taxes d'error, les cues, el comportament dels reintents i els errors específics del proveïdor són importants.

Llista de verificació d'implementació

• Substituïu les claus compartides de tota l'organització per les claus de l'aplicació, l'entorn, l'arrendatari o el flux de treball.
• Elimineu les claus de proveïdor en brut dels navegadors, aplicacions mòbils, extensions d'escriptori i scripts públics.
• Encamina les sol·licituds dels clients mitjançant un backend o una passarel·la de l'API d'IA.
• Adjunteu el propietari, el propòsit, l'entorn, els models permesos, el pressupost i les metadades de revisió a cada clau.
• Aplica el mínim privilegi: controls de projecte, punt final, model, ruta, tarifa i pressupost quan estiguin disponibles.
• Definiu límits de despesa per clau, per equip, per inquilí i globals.
• Identificador de clau de registre, actor lògic, model, ús del testimoni, cost estimat, latència i codi d'estat.
• Creeu un flux de treball de rotació sense temps d'inactivitat i proveu-lo abans d'una emergència.
• Escriu un runbook de resposta a fuites amb passos de contenció, investigació i prevenció.
• Reviseu les claus inactives i revoqueu qualsevol cosa sense un propietari o un ús legítim recent.

Conclusió accionable

Comenceu amb la clau de més risc: la que s'utilitza a la producció, compartida per diverses persones, incrustada en massa llocs o responsable de la despesa més gran. Doneu-li un propietari, dividiu-lo per límits, afegiu un pressupost, moveu-lo darrere d'un backend o passarel·la si els clients el poden veure i documenteu com es pot girar.

A continuació, repeteix. La gestió de claus de l'API LLM sòlida no és una decisió única d'emmagatzematge secret. És un cicle de vida: inventari, aïllament, privilegis mínims, atribució d'ús, control de costos, rotació i resposta a les fuites. El resultat és senzill: quan alguna cosa va malament, només una aplicació, un inquilí o un flux de treball hauria de correr risc, no tot el pressupost d'IA.

Lectura relacionada

• production routing LLM disseny
• Notes anteriors del bloc de Model Gate
• article introductori de Model Gate