Bóvedas de credenciales de proveedores para puertas de enlace de IA multimodelo: tiempo de ejecución, administración, facturación y acceso BYOK separados

Las claves API descendentes y las credenciales del proveedor ascendente resuelven diferentes problemas. Una clave de desarrollador emitida por su puerta de enlace identifica la aplicación, el equipo, el inquilino, el presupuesto y el contexto de la política. Una clave de proveedor ascendente permite que la puerta de enlace gaste dinero y acceda a modelos en una cuenta de proveedor. Tratarlos como el mismo tipo de secreto es la forma en que los equipos terminan con una clave sin restricciones en un proyecto compartido, credenciales de administrador en servicios de tiempo de ejecución y sin una forma confiable de responder qué inquilino causó qué cargo del proveedor.

El patrón práctico es una bóveda de credenciales de proveedor: un plano de control dedicado para importar, clasificar, almacenar, seleccionar, rotar y auditar credenciales ascendentes. Debe ubicarse detrás del enrutador, el libro de facturación, el motor de políticas y el flujo de trabajo de operaciones, no dentro del código de la aplicación, los archivos de configuración del modelo, los registros de inquilinos o los eventos de análisis.

El problema del lector: las credenciales ascendentes se convierten en una infraestructura invisible

La mayoría de las implementaciones multimodelo comienzan con un objetivo simple: dirigir una solicitud compatible con OpenAI al mejor proveedor disponible. Luego aparecen más cuentas: un proyecto de proveedor para producción, otro para evaluación, un espacio de trabajo de Anthropic para una unidad de negocio, un proyecto de Google Cloud para Gemini y varias claves proporcionadas por los clientes para contratos BYOK.

El riesgo no es simplemente la filtración de secretos. Es la pérdida del contexto de autorización. Una clave de proveedor válida puede ser técnicamente capaz de llamar a un punto final, pero la puerta de enlace aún necesita saber si esa clave está permitida para este inquilino, esta familia de modelos, esta política de retención de datos, este presupuesto, esta región y esta ruta de automatización.

Hecho: las plataformas de proveedores exponen diferentes límites de cuentas y tipos de credenciales. OpenAI documenta proyectos y cuentas de servicio, y los permisos de clave API de la cuenta de servicio tienen acceso predeterminado de lectura y escritura para los recursos API del proyecto. OpenAI también expone los objetos clave de la API de administración por separado del uso normal de la API en tiempo de ejecución/proyecto. Anthropic documenta los espacios de trabajo como un límite organizacional y establece que los puntos finales de la API de administración requieren claves de API de administración distintas de las claves de API estándar; Anthropic también señala que las claves API están vinculadas al espacio de trabajo donde se crean y no se pueden mover entre espacios de trabajo. La documentación de la clave API Gemini de Google dice que cada clave API Gemini está asociada con un proyecto de Google Cloud y recomienda restricciones de API para reducir el daño si una clave se ve comprometida.

Recomendación: no cree un campo genérico "provider_key" y dé por terminado. Cree un inventario de credenciales que preserve los límites específicos del proveedor y al mismo tiempo exponga un modelo de política normalizado a la puerta de enlace.

Defina una taxonomía de credenciales antes de aceptar claves

Una bóveda debe rechazar credenciales ambiguas. En el momento de la importación, el operador o el flujo de trabajo de automatización debe clasificar la credencial. Como mínimo, utilice estas categorías:

• Credenciales de inferencia en tiempo de ejecución: utilizadas por la puerta de enlace para llamar a los puntos finales de inferencia del modelo, como chat, respuestas, incrustaciones, moderación, transcripción o generación de imágenes, según el soporte del proveedor.
• Credenciales de automatización de administración: se utilizan para administrar organizaciones, espacios de trabajo, proyectos, usuarios, claves o recursos administrativos del lado del proveedor. Estos nunca deberían estar en la ruta de solicitud del tiempo de ejecución.
• Credenciales de facturación e informes: se utilizan para recuperar el uso, las facturas, los costos o los informes de la organización cuando los proveedores admiten esas API. Manténgalos separados de las claves de inferencia para que los trabajos de informes no puedan generar el uso del modelo.
• Credenciales solo de evaluación: utilizadas en flujos de trabajo de evaluación comparativa, control de calidad, migración o preparación. Deben tener cuotas bajas, etiquetas medioambientales claras y ninguna elegibilidad alternativa de producción.
• Credenciales BYOK del cliente: claves proporcionadas por el cliente vinculadas a un inquilino, cuenta de proveedor, contrato y política de datos específicos. No deben agruparse en rutas compartidas a menos que el cliente lo acepte explícitamente.

Esta taxonomía no es sólo documentación. Debería impulsar el control de acceso, la elegibilidad de enrutamiento, las alertas y los flujos de trabajo de rotación. Si se importa una credencial sin categoría, propietario, límite de cuenta de proveedor y uso permitido, debe permanecer deshabilitada.

Almacenar secretos en una bóveda, no en registros de productos

La bóveda debe ser el único componente que pueda descifrar las credenciales ascendentes. Otros sistemas pueden almacenar referencias, hashes, campos de estado y metadatos de políticas, pero no el valor de la credencial en sí.

No almacene secretos ascendentes en estos lugares

• Filas del perfil del inquilino.
• Archivos de configuración de enrutamiento del modelo.
• Registros de avisos o intervalos de seguimiento.
• Cargas útiles de eventos de Analytics.
• Variables de CI orientadas al desarrollador.
• Tickets de soporte, herramientas de chat o capturas de pantalla.

Un diseño de bóveda utilizable tiene dos planos. El avión secreto almacena material de credenciales cifrado y controla estrictamente las operaciones de descifrado. El plano de metadatos almacena atributos no secretos utilizados por el enrutamiento y la gobernanza. Por lo general, el enrutador solo debería necesitar una identificación de credencial y una recuperación secreta en memoria de corta duración en el momento del envío, no un acceso amplio a la base de datos para cada clave de proveedor.

Proteja la bóveda como infraestructura de alto valor: cifrado de sobres o KMS administrado, identidades de servicio estrictas, procedimientos de seguridad, pruebas de copia de seguridad y restauración, revisión de acceso y alertas sobre volúmenes de descifrado inusuales. Una bóveda central simplifica la gobernanza, pero también concentra el riesgo. Ésa es la compensación.

Adjuntar metadatos de políticas a cada credencial

El modelo de metadatos debe ser lo suficientemente explícito como para que la puerta de enlace pueda decidir si una credencial es elegible antes de que llegue al punto final de un proveedor.

Un registro de credenciales práctico incluye:

• credential_id: identificador interno inmutable.
• proveedor: OpenAI, Anthropic, Gemini, Azure OpenAI u otro adaptador.
• provider_account_boundary: organización, proyecto, espacio de trabajo, proyecto en la nube, suscripción o equivalente.
• credential_class: tiempo de ejecución, administración, facturación, evaluación o BYOK.
• entorno: producción, puesta en escena, desarrollo, evaluación, sandbox.
• tenant_binding: credencial de plataforma compartida, inquilino único, grupo de inquilinos o inquilino BYOK del cliente.
• allowed_model_families: por ejemplo, generación de texto, incrustaciones, visión, imagen, audio o perfiles de modelo específicos.
• allowed_endpoints: capacidades de puerta de enlace normalizadas asignadas a los puntos finales del proveedor.
• data_policy: clase de retención permitida, clase de registro, requisito de residencia y restricciones de funciones.
• presupuesto_alcance: centro de costos, cliente revendedor, departamento interno o contrato.
• propietario: equipo designado o persona responsable.
• creado_en, expira_en, rotación_debido_en, último_usado_en.
• estado_de_salud: desconocido, saludable, degradado, no autorizado, cuota_agotada, deshabilitado.
• emergency_disable: bloqueo de enrutamiento inmediato independiente del estado normal de la política.

Mantenga este modelo neutral respecto a los proveedores, pero no borre las realidades de los proveedores. Una clave vinculada a un espacio de trabajo Anthropic y una clave Gemini vinculada a un proyecto de Google Cloud no son intercambiables solo porque ambas pueden generar texto. La puerta de enlace necesita esa procedencia para auditorías, contracargos y conmutación por error segura.

Acceso independiente al tiempo de ejecución, al administrador y a la facturación

La regla más importante es simple: una clave utilizada para la inferencia en tiempo de ejecución no debe administrar organizaciones de proveedores, espacios de trabajo, usuarios, proyectos o recursos administrativos.

El tráfico en tiempo de ejecución es de gran volumen y está expuesto a la mayor superficie operativa. Pasa a través de enrutadores de solicitudes, lógica de reintento, controladores de transmisión, adaptadores de modelos y flujos de trabajo de incidentes. Las credenciales de administrador son de baja frecuencia y de alto impacto. Deben vivir detrás de una ruta de aprobación separada con TTL cortos, aprobación humana denominada cuando corresponda, registros sólidos y sin elegibilidad de enrutamiento en tiempo de ejecución.

Las credenciales de facturación también merecen separación. Un trabajo de informes que concilia facturas no debería poder generar finalizaciones, y una clave de inferencia en tiempo de ejecución no debería ser la única forma de recuperar informes de uso. Cuando un proveedor no ofrece una separación detallada, compense en la puerta de enlace: aísle la credencial, limite qué identidad de servicio interno puede recuperarla y registre cada uso.

Recomendación: haga que la clase de credencial sea un límite de autorización estricto, no una etiqueta. Un distribuidor de tiempo de ejecución no debería poder solicitar el descifrado de una credencial de administrador incluso si un error de configuración hace referencia a su ID.

Crear un motor de políticas de selección de credenciales

La selección de credenciales debe realizarse después de que la puerta de enlace autentique a la persona que llama y antes de que se intente realizar cualquier llamada al proveedor. El motor de políticas debe unir varias entradas:

• ID del inquilino y alcance de la clave API descendente.
• Perfil de modelo solicitado o ID de modelo específico del proveedor.
• Capacidad de punto final: chat, incrustaciones, imágenes, audio, lotes, archivos, herramientas o automatización administrativa.
• Requisitos de residencia y retención de datos.
• Presupuesto, reserva de crédito y centro de costes.
• Estado límite de tasas y presión de cuotas.
• Metadatos de credenciales, estado, entorno y vinculación de inquilinos.

El motor debería devolver uno de tres resultados: permitir con una credencial seleccionada, denegar con un motivo de política o requerir aprobación. Las denegaciones deben ser lo suficientemente precisas para que los equipos de operaciones solucionen el problema sin revelar material secreto a los desarrolladores.

Ejemplo de decisión:

{
  "tenant_id": "inquilino_42",
  "requested_profile": "producción-de-texto-rápida",
  "punto final": "chat.completions",
  "data_policy": "no_prompt_logging",
  "requisitos_credenciales": {
    "clase": "tiempo de ejecución",
    "medio ambiente": "producción",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "texto",
    "health_status": "saludable"
  },
  "decisión": "permitir",
  "credential_id": "cred_8f2...",
  "audit_reason": "la credencial BYOK del inquilino coincide con el perfil de texto del tiempo de ejecución y la política de datos"
}

No implemente la opción alternativa como "pruebe con la siguiente clave". El respaldo debe volver a ejecutar la política. Una credencial de plataforma compartida puede ser válida para el acceso del proveedor, pero no válida para un cliente que solo utiliza BYOK. Una credencial de otro proyecto puede tener cuota, pero puede infringir los requisitos de retención o atribución de costos.

Manejar BYOK como acceso propiedad del inquilino, no como capacidad adicional

BYOK cambia el modelo de confianza. El cliente proporcionó la credencial para que su tráfico pueda cargarse, regirse o aislarse dentro de su cuenta de proveedor. Esa credencial debe estar vinculada al inquilino del cliente y al origen de la cuenta del proveedor.

Controles BYOK recomendados:

• Un registro de bóveda por cliente, proveedor, límite de cuenta y entorno.
• No hay enrutamiento entre inquilinos a través de credenciales BYOK.
• No se puede utilizar como capacidad de reserva compartida a menos que el cliente lo acepte explícitamente.
• Estado de salud visible para el cliente que no revela la clave sin formato.
• Flujo de trabajo de rotación independiente que permite al cliente agregar un reemplazo antes de que se desactive la clave anterior.
• Atribución clara en análisis de uso y facturas: inquilino de puerta de enlace, límite de cuenta de proveedor, ID de credencial, perfil de modelo e ID de seguimiento de solicitud.

Para agencias, revendedores y automatización de API de socios, BYOK puede ser más complejo porque un servicio puede proporcionar inquilinos y credenciales mediante programación. Se sigue aplicando la misma regla: la automatización puede importar y vincular credenciales, pero no debería desdibujar la propiedad del inquilino.

Añadir comprobaciones de estado previas al vuelo sin mensajes de fuga

Una credencial puede fallar por muchos motivos: clave revocada, espacio de trabajo incorrecto, falta de acceso al modelo, facturación deshabilitada, agotamiento de cuota, restricción de terminales, discrepancia en la política regional o interrupción del proveedor. Descubrir eso sólo después de que llega una solicitud de producción genera incidentes ruidosos.

Utilice controles de estado que validen la capacidad sin enviar mensajes al cliente. Una verificación sintética podría llamar a un punto final mínimo, enumerar los modelos permitidos cuando corresponda o enviar un mensaje fijo inofensivo si esa es la única opción práctica. Mantenga estas comprobaciones económicas, con tarifas limitadas y etiquetadas como tráfico sintético en telemetría y facturación.

Se deben ejecutar controles de estado:

• En la importación de credenciales.
• Antes de habilitar una credencial para enrutamiento de producción.
• Después de cambios en las restricciones del lado del proveedor.
• Durante el corte de rotación.
• Periódicamente para credenciales con elegibilidad de producción.

Compensación: las comprobaciones automáticas detectan tempranamente las claves vencidas o cuyo alcance no es suficiente, pero las comprobaciones mal diseñadas pueden generar llamadas innecesarias al proveedor, ruido en la facturación o falsas alarmas durante las interrupciones del proveedor. Almacene el resultado de salud con marca de tiempo, clase de error del proveedor, punto final probado y familia de modelos probados. No almacene valores secretos ni mensajes confidenciales.

Rotar con dos ranuras, no con un reemplazo arriesgado

La rotación de credenciales no debe ser una operación de eliminación y oración. Utilice un modelo de rotación de dos ranuras:

1. Importar credencial de reemplazo como inactiva, con metadatos completos y propietario.
2. Ejecute comprobaciones de estado sintéticas para los puntos finales previstos, las familias de modelos y los límites de la cuenta.
3. Habilite la elegibilidad oculta para una pequeña porción de tráfico sintético seguro o de bajo riesgo cuando corresponda.
4. Cambie el tráfico de producción gradualmente de la credencial antigua a la nueva.
5. Supervise los errores, la latencia, la cuota y la atribución de costes por ID de credencial.
6. Congelar el respaldo a la credencial anterior una vez que la nueva credencial sea estable.
7. Revocar la credencial anterior en el proveedor y marcar el registro de la bóveda como revocado.
8. Verifique que no se produzcan descifrados ni llamadas al proveedor a través de la credencial anterior después de la revocación.

Las fechas límite de rotación deben ser visibles en las vistas de operaciones y en las alertas. La rotación de emergencia necesita un camino más corto: deshabilitar la credencial, bloquear el enrutamiento, habilitar el reemplazo aprobado y conservar todos los registros de auditoría para la revisión de incidentes.

Restringir las claves del proveedor cuando el proveedor las admita

La política de puerta de enlace es necesaria, pero las restricciones del lado del proveedor reducen el radio de explosión si una clave se ve comprometida o se utiliza incorrectamente. Para Gemini y otras claves API de plataforma en la nube, utilice restricciones de API/servicio y restricciones de aplicaciones adecuadas cuando estén disponibles. Para proyectos de proveedores, espacios de trabajo y cuentas de servicio, evite privilegios organizativos amplios cuando una clave de tiempo de ejecución con ámbito de proyecto sea suficiente.

Recomendación: mantenga una lista de verificación de restricciones del lado del proveedor para cada clase de credencial. La lista de verificación debe ser parte de la aprobación de la importación y la aprobación de la rotación, no una tarea de seguridad separada que pueda omitirse bajo presión.

Compensación: las restricciones del lado del proveedor añaden gastos operativos. Los nuevos puntos finales, familias de modelos, regiones o funciones de automatización pueden requerir cambios de políticas y restricciones. Esto es preferible a descubrir después de una filtración que una clave podría acceder a todas las cargas de trabajo de un proyecto compartido.

Mantenga un registro de auditoría de credenciales de solo anexar

Un seguimiento de auditoría debe responder quién importó una credencial, qué se le permitió hacer, qué decisiones de enrutamiento la seleccionaron, cuándo falló y cuándo se rotó o revocó.

Registra estos eventos:

• Credencial creada o importada.
• Los metadatos cambiaron, incluidos los puntos finales permitidos, el enlace de inquilinos o la política de datos.
• Comprobación de estado ejecutada y resultado registrado.
• Credencial seleccionada por la política de enrutamiento para una solicitud.
• Descifrado de credenciales solicitado por una identidad de servicio interno.
• La llamada al proveedor falló debido a un error de autenticación, autorización, cuota o restricción.
• Se inició la rotación, se desvió el tráfico, se revocó la credencial anterior.
• Desactivación de emergencia habilitada o borrada.
• Se accedió a la credencial de administrador o de emergencia.

No incluya valores de credenciales sin procesar en eventos de auditoría. Utilice ID de credenciales, límites de cuentas de proveedores, ID de seguimiento de solicitudes, identidades de actores y motivos de decisión de políticas. Para tráfico de tiempo de ejecución de gran volumen, puede probar la telemetría de descifrado detallada, pero la selección de enrutamiento y la atribución de costos deben permanecer lo suficientemente completas para la facturación y la respuesta a incidentes.

Lista de verificación de implementación

• Cree una taxonomía de credenciales y rechace importaciones no clasificadas.
• Mueva todos los secretos del proveedor a una bóveda cifrada dedicada.
• Almacenar los metadatos de enrutamiento por separado del material secreto.
• Haga que las credenciales de tiempo de ejecución, administración, facturación, evaluación y BYOK sean clases de autorización separadas.
• Vincular las credenciales BYOK a la procedencia de la cuenta del inquilino y del proveedor.
• Requerir la aprobación del motor de políticas antes de seleccionar cualquier credencial ascendente.
• Realice controles de salud rápidos y seguros antes de la elegibilidad de producción.
• Utilice la rotación de dos espacios con cambio de tráfico gradual y revocación por parte del proveedor.
• Aplicar restricciones del lado del proveedor siempre que estén disponibles.
• Mantenga registros de auditoría de solo anexos para importación, uso, fallas, rotación y revocación.
• Mantenga las credenciales de administrador detrás de controles de seguridad: TTL corto, aprobación con nombre, registro seguro, sin uso de tiempo de ejecución.

Conclusión procesable

Comience por hacer un inventario de todas las credenciales de proveedores ascendentes utilizadas actualmente por la puerta de enlace, los scripts, los trabajos de CI, los arneses de evaluación y la automatización de socios. Para cada uno, asigne una clase, propietario, límite de cuenta de proveedor, vinculación de inquilino, puntos finales permitidos, familias de modelos permitidas, fecha límite de rotación y estado de desactivación de emergencia. Todo lo que no puedas clasificar debe desactivarse o ponerse en cuarentena hasta que tenga un propósito claro.

Luego, aplique una regla arquitectónica: los desarrolladores posteriores reciben claves con alcance de puerta de enlace; la puerta de enlace por sí sola controla el acceso del proveedor ascendente. Esa separación le permite preservar los privilegios mínimos, la atribución de inquilinos, la precisión de la facturación, el enrutamiento de políticas de datos y la automatización segura incluso cuando se multiplican los proveedores, proyectos, espacios de trabajo y clientes BYOK.

Lectura relacionada

• Administración de claves API orientada al equipo y respuesta a fugas
• políticas de enrutamiento con reconocimiento de retención de datos
• libro mayor de facturación y controles de atribución de costes