Las aplicaciones inteligentes que usan Azure OpenAI Service a través de servicios nativos de Azure ofrecen una autorización y autenticación de usuario sin problemas. Sin embargo, algunos escenarios son complejos y requieren diferentes diseños de arquitectura. Estos escenarios incluyen topologías con aplicaciones cliente no hospedadas en Azure, usan proveedores de identidades externos e implementan varios clientes que acceden a las mismas instancias de Azure OpenAI. En estos escenarios, la introducción de una puerta de enlace frente a Azure OpenAI puede mejorar significativamente la seguridad mediante la adición de una capa que garantiza la coherencia en la autenticación para las instancias implementadas.
En este artículo se describen escenarios clave que proporcionan autenticación a Azure OpenAI:
Autenticación de aplicaciones cliente con un proveedor de identidades externo
Autenticación de aplicaciones cliente que acceden a varias instancias de Azure OpenAI
Cada escenario describe los desafíos que presentan y las ventajas de incorporar una puerta de enlace.
Importante
Puede seguir las instrucciones siguientes para cualquier implementación de puerta de enlace, incluida Azure API Management. Para ilustrar esta flexibilidad, los diagramas de arquitectura utilizan representaciones genéricas de los componentes en la mayoría de los escenarios.
Autenticación de aplicaciones cliente con un proveedor de identidades externo
Descargue un archivo Visio de esta arquitectura.
Restricciones del escenario
Este escenario tiene las siguientes restricciones:
Las aplicaciones cliente usan un proveedor de identidades habilitado para OpenID Connect (OIDC) externo, como Okta, Auth0 o proveedores de identidades sociales.
Las aplicaciones cliente se autentican en un inquilino de Microsoft Entra diferente del inquilino del plano de datos de Azure OpenAI.
Estas restricciones se pueden aplicar a los ejemplos siguientes:
Las aplicaciones cliente existentes que ya se autentican en un proveedor OIDC externo o Microsoft Entra ID y que se integran con instancias de Azure OpenAI.
Las aplicaciones cliente que deben autenticar de forma coherente a los usuarios de varios proveedores de identidades.
Conexión directa a Azure OpenAI
Si las aplicaciones cliente de estos escenarios se conectan directamente a Azure OpenAI sin usar una puerta de enlace, deben usar la autenticación basada en claves para autenticarse en Azure OpenAI. La autenticación basada en claves presenta problemas de seguridad adicionales. Debe almacenar y rotar claves de forma segura y no puede proporcionar configuraciones de control de acceso basado en roles (RBAC) de clientes diferentes para implementaciones de modelos individuales.
Introducción de una puerta de enlace
Descargue un archivo Visio de esta arquitectura.
Una puerta de enlace resuelve los desafíos de este escenario de las maneras siguientes:
La puerta de enlace usa Open Authorization (OAuth) para autenticar a los usuarios mediante sus proveedores de identidades externos existentes. La puerta de enlace valida los tokens de acceso de usuario autenticado, como un token web JSON (JWT), que genera el proveedor de identidades. A continuación, la puerta de enlace concede autorización a la instancia de Azure OpenAI de reserva.
No es necesario administrar las claves de cliente. Este enfoque elimina los riesgos de seguridad de la autenticación basada en claves.
La puerta de enlace se conecta a Azure OpenAI con una identidad administrada, que mejora la seguridad mediante Azure RBAC con privilegios mínimos.
Recomendaciones para este escenario
Para habilitar el permiso pormenorizado para los consumidores, agregue más ámbitos de OAuth al registro de la aplicación en el proveedor de identidades. Estos ámbitos permiten a las aplicaciones cliente solicitar permiso para realizar operaciones específicas en la puerta de enlace, incluido el acceso a Azure OpenAI.
Configure este escenario para Azure API Management mediante directivas de entrada. Use la directiva
validate-jwtpara aplicar los valores de existencia, validez y atributo de un JWT admitido.
Motivos para evitar una puerta de enlace para este escenario
Si una sola aplicación inteligente accede a Azure OpenAI, es más fácil configurar la autenticación y autorización de usuario dentro de la aplicación en lugar de hacerlo mediante la puerta de enlace. Use este enfoque para asignar el Azure RBAC necesario para autenticar de forma segura la aplicación inteligente con Azure OpenAI.
Autenticación de aplicaciones cliente con certificados
Descargue un archivo Visio de esta arquitectura.
Restricciones del escenario
Este escenario tiene las siguientes restricciones:
Quiere usar certificados para autenticar aplicaciones cliente.
Las aplicaciones cliente no pueden usar o usted no quiere usar Microsoft Entra ID ni ningún proveedor de OIDC para la autenticación.
Los clientes no pueden usar o usted no desea usar la identidad federada para la autenticación.
Estas restricciones se pueden aplicar a los ejemplos siguientes:
Un cliente que se autentica en Azure OpenAI es un equipo o dispositivo y no hay ninguna interacción del usuario.
Su organización requiere el uso de certificados para la autenticación debido a los estándares de seguridad y las normativas de cumplimiento.
Quiere proporcionar varias aplicaciones cliente con opciones para autenticarse en función de su entorno, incluido el uso de certificados de cliente.
Conexión directa a Azure OpenAI
Azure OpenAI no admite de forma nativa la autenticación de certificación de cliente. Para admitir este escenario sin una puerta de enlace, la aplicación inteligente necesita usar la autenticación de certificados para el usuario y una clave de API o una identidad administrada para autenticar las solicitudes en la instancia de Azure OpenAI. Debe implementar la lógica de autenticación de certificados en cada cliente. En este escenario, la autenticación basada en claves presenta riesgos y sobrecarga de administración si se conecta directamente a Azure OpenAI desde clientes.
Introducción de una puerta de enlace
Descargue un archivo Visio de esta arquitectura.
Puede introducir una puerta de enlace en esta arquitectura que descarga de los clientes la validación de la certificación de cliente. La puerta de enlace valida el certificado digital del cliente que presenta la aplicación inteligente y comprueba las listas de emisor, fecha de expiración, huella digital y revocación. La puerta de enlace debe usar una identidad administrada para autenticarse con Azure OpenAI. La puerta de enlace también debe usar Azure Key Vault para almacenar la entidad de certificación raíz (CA). Use este enfoque para centralizar la validación de certificados de cliente, lo que reduce la sobrecarga de mantenimiento.
Una puerta de enlace proporciona varias ventajas en este escenario:
El uso de la identidad administrada de la puerta de enlace frente a las claves de acceso elimina el riesgo de robo de claves y reduce la carga de mantenimiento de las rotación de claves.
Puede centralizar la validación de certificados, que garantiza que usa directivas de seguridad coherentes para evaluar los certificados digitales de cliente para todas las aplicaciones inteligentes.
Puede descargar la validación de certificados en la puerta de enlace, lo que simplifica el código de cliente.
Recomendaciones para este escenario
Compruebe toda la cadena de certificados, incluida la entidad de certificación raíz y los certificados intermedios, al validar los certificados. La comprobación completa garantiza la autenticidad del certificado y evita el acceso no autorizado.
Gire y renueve periódicamente los certificados de cliente para minimizar el riesgo de que el certificado se vea comprometido. Use Key Vault para automatizar este proceso y mantener actualizados los certificados. Configure alertas para las próximas expiraciones de certificados para evitar interrupciones del servicio en la puerta de enlace.
Implemente la seguridad de capa de transporte mutua (mTLS) para asegurarse de que tanto el cliente como el servidor se autentiquen entre sí. Esta estrategia proporciona una capa adicional de seguridad. Para configurar la puerta de enlace para aplicar mTLS, establezca las directivas y restricciones adecuadas.
Use la directiva
validate-client-certificateen API Management para validar los certificados de cliente a los que hace referencia un almacén de claves de Azure. Esta directiva valida el certificado de cliente que presenta la aplicación cliente y comprueba las listas de emisor, expiración, huella digital y revocación.
Motivos para evitar una puerta de enlace para este escenario
En entornos sencillos con pocos clientes, el coste de controlar la seguridad y la administración de certificados en el cliente puede superar la complejidad adicional de introducir una puerta de enlace. Además, las puertas de enlace pueden convertirse en puntos únicos de error, aumentar la latencia debido a capas agregadas y provocar el bloqueo del proveedor si opta por soluciones comerciales en implementaciones personalizadas.
Debe evaluar cuidadosamente sus necesidades específicas, la disponibilidad de los recursos y la importancia de las aplicaciones antes de implementar una puerta de enlace para la autenticación de certificados de cliente.
Autenticación de varias aplicaciones cliente con claves para acceder a una instancia compartida de Azure OpenAI
Descargue un archivo Visio de esta arquitectura.
Restricciones del escenario
Este escenario tiene las siguientes restricciones:
- Varias aplicaciones cliente acceden a una instancia compartida de Azure OpenAI.
- Los clientes no pueden usar o usted no desea usar Microsoft Entra ID para la autenticación.
- Los clientes no pueden usar o usted no desea usar la identidad federada para la autenticación.
- Quiere usar la autenticación basada en claves para las aplicaciones cliente.
Estas restricciones se pueden aplicar a los ejemplos siguientes:
Las aplicaciones cliente se implementan en varios entornos, como Azure, locales u otros proveedores de nube.
Una organización debe proporcionar Azure OpenAI a diferentes equipos y establecer límites de uso y acceso únicos para cada uno de ellos.
Conexión directa a Azure OpenAI
Azure OpenAI admite la autenticación basada en claves mediante claves compartidas. Azure OpenAI expone una clave principal y una clave secundaria. El propósito de la clave secundaria es admitir la rotación de claves. No proporciona aislamiento de identidad de cliente. Al autenticar varios clientes directamente en Azure OpenAI en este escenario, cada cliente comparte la misma clave. Esta implementación tiene los desafíos siguientes:
No se pueden revocar los permisos de clientes específicos porque todos los clientes comparten la misma clave.
No puede conceder a distintos clientes derechos de acceso diferentes a diferentes modelos en la misma implementación de la instancia de Azure OpenAI.
No se puede diferenciar un cliente de otro desde una perspectiva de registro.
Introducción de una puerta de enlace
Descargue un archivo Visio de esta arquitectura.
Puede introducir una puerta de enlace en esta arquitectura que emite una clave dedicada para cada aplicación cliente. API Management usa el concepto de suscripciones para proporcionar claves de cliente dedicadas. La puerta de enlace debe usar una identidad administrada para autenticarse con Azure OpenAI.
Una puerta de enlace proporciona varias ventajas en este escenario:
Puede revocar el acceso a una sola aplicación cliente sin que afecte a otros clientes.
No es necesario actualizar todas las configuraciones de clave del cliente antes de rotar las claves, por lo que la rotación de claves es más fácil. Puede rotar las claves dedicadas se para cada cliente después de actualizar la configuración del cliente.
Puede identificar cada cliente de forma única desde una perspectiva de registro.
La puerta de enlace aplica límites de velocidad y cuotas para cada cliente de forma independiente.
Recomendaciones para este escenario
Mejore la supervisión de métricas relacionadas con las solicitudes de API. Cuando se usa una identidad administrada de una puerta de enlace, la trazabilidad de la aplicación de usuario y cliente en los registros de Azure OpenAI no mejora. La puerta de enlace debe proporcionar el registro asociado a la solicitud, como los identificadores de cliente y usuario que solicitan.
Asegúrese de que la puerta de enlace tome decisiones de enrutamiento basadas en la identidad del cliente para las implementaciones de modelos adecuadas al enrutar varias solicitudes de aplicación cliente a través de una puerta de enlace a una instancia compartida de Azure OpenAI. Para obtener más información, consulte Uso de una puerta de enlace frente a varias implementaciones de Azure OpenAI.
Autenticación de aplicaciones cliente que acceden a varias instancias de Azure OpenAI
Descargue un archivo Visio de esta arquitectura.
Restricciones del escenario
Este escenario tiene las siguientes restricciones:
- Las aplicaciones cliente se conectan a varias instancias de Azure OpenAI en una o varias regiones.
- Los clientes no pueden usar o no quiere usar microsoft Entra ID ni ningún proveedor de OIDC para la autenticación.
- Quiere usar la autenticación basada en claves para las aplicaciones cliente.
Estas restricciones se pueden aplicar a los ejemplos siguientes:
Las aplicaciones cliente deben distribuir sus cargas de trabajo geográficamente para reducir la latencia y mejorar el rendimiento.
Las aplicaciones cliente intentan optimizar sus cuotas de tokens por minuto mediante la implementación de instancias en varias regiones.
Una organización requiere funcionalidades de conmutación por error y recuperación ante desastres sin problemas para garantizar el funcionamiento continuo. Por lo tanto, administran una estrategia de implementación dual, como una estrategia que consta de una implementación de rendimiento aprovisionada y una implementación de pago por uso.
Las aplicaciones cliente deben usar funcionalidades de modelo específicas que solo están disponibles en determinadas regiones de Azure.
Conexión directa a varias instancias de Azure OpenAI
Cuando las aplicaciones cliente se conectan directamente a varias instancias de Azure OpenAI, cada cliente debe almacenar la clave de cada instancia. Junto con las consideraciones de seguridad del uso de claves, hay una mayor carga de administración con respecto a las claves rotativas.
Introducción de una puerta de enlace
Descargue un archivo Visio de esta arquitectura.
Al usar una puerta de enlace para controlar las aplicaciones cliente que acceden a varias implementaciones de Azure OpenAI tiene las mismas ventajas que una puerta de enlace que controla varias aplicaciones cliente mediante claves para acceder a una instancia compartida de Azure OpenAI. También simplifica el proceso de autenticación porque usa una única identidad administrada definida por el usuario para autenticar las solicitudes de la puerta de enlace a varias instancias de Azure OpenAI. Implemente este enfoque para reducir la sobrecarga operativa general y minimizar los riesgos de una configuración incorrecta del cliente al trabajar con varias instancias.
Un ejemplo de cómo se usa una puerta de enlace en Azure para descargar la identidad a un intermediario es el recurso de Azure AI Services. En esa implementación, se autentica en la puerta de enlace y la puerta de enlace controla la autenticación en los distintos servicios de Azure AI, como Custom Vision o Speech. Aunque esa implementación es similar, no aborda este escenario.
Recomendaciones para este escenario
Implemente técnicas de equilibrio de carga para distribuir las solicitudes de API en varias instancias de Azure OpenAI para controlar el tráfico elevado y garantizar una alta disponibilidad. Para obtener más información, consulte Uso de una puerta de enlace frene a varias implementaciones o instancias de Azure OpenAI.
Correlacione el uso de tokens para cada inquilino en la puerta de enlace al implementar escenarios multiinquilino con varias instancias de Azure OpenAI. Este enfoque garantiza que realice un seguimiento del uso total de tokens, independientemente de la instancia de Azure OpenAI de back-end a la que se reenvíe la solicitud.
Recomendaciones generales
Al integrar Azure OpenAI a través de una puerta de enlace, hay varias recomendaciones transversales que se deben tener en cuenta que se aplican en todos los escenarios.
Use Azure API Management en lugar de crear su propia solución para una orquestación de API eficaz, una integración perfecta con otros servicios de Azure y ahorros de costos al reducir los esfuerzos de desarrollo y mantenimiento. API Management garantiza una administración de API segura al admitir la autenticación y la autorización directamente. Se integra con proveedores de identidades, como Microsoft Entra ID, que habilita OAuth 2.0 y ofrece autorización basada en directivas. Además, API Management usa identidades administradas para un acceso seguro y bajo mantenimiento a Azure OpenAI.
Combine escenarios para una solución de puerta de enlace completa
En las aplicaciones del mundo real, los casos de uso pueden abarcar varios escenarios de este artículo. Por ejemplo, puede tener aplicaciones cliente que se autentiquen con un proveedor de identidades externo y necesiten acceso a varias instancias de Azure OpenAI.
Descargue un archivo Visio de esta arquitectura.
Para crear una puerta de enlace que admita sus requisitos específicos, combine las recomendaciones de estos escenarios para un enfoque completo.
Aplicación de directivas de puerta de enlace
Antes de que una puerta de enlace envíe solicitudes a las instancias de Azure OpenAI, asegúrese de aplicar directivas de autenticación y autorización de entrada. Para garantizar que la puerta de enlace solo reenvía solicitudes autenticadas y autorizadas, use tokens de acceso de usuario de un proveedor de identidades o por validación de certificados para implementar este enfoque.
Para permitir un control pormenorizado, implemente más ámbitos de autorización con roles y permisos para las aplicaciones cliente de la puerta de enlace. Use estos ámbitos para permitir operaciones específicas en función de las necesidades de la aplicación cliente. Este enfoque mejora la seguridad y la capacidad de administración.
Para la validación de tokens de acceso, asegúrese de validar todas las notificaciones registradas clave como iss, aud, exp y nbf además de cualquier notificación específica de carga de trabajo pertinente, como pertenencias a grupos o roles de aplicación.
Uso de las identidades administradas de Azure
Para simplificar la autenticación en todos los escenarios de aplicaciones cliente, use identidades administradas de Azure para centralizar la administración de la autenticación. Este enfoque reduce la complejidad y los riesgos asociados a la administración de varias claves de API o credenciales en aplicaciones cliente.
Como las identidades administradas admiten inherentemente Azure RBAC, garantizan que la puerta de enlace solo tenga el nivel más bajo de permiso necesario para acceder a las instancias de Azure OpenAI. Para reducir el riesgo de acceso no autorizado y simplificar el cumplimiento de las directivas de seguridad, combine identidades administradas con otros métodos que deshabilitan la autenticación alternativa.
Implementación de una observabilidad completa
Al implementar una puerta de enlace con una identidad administrada, se reduce la rastreabilidad, ya que una identidad administrada representa la puerta de enlace, no el usuario final o la aplicación que realizó la solicitud. Por tanto, es esencial mejorar la observabilidad en las métricas relacionadas con las solicitudes de API. Para mantener la visibilidad sobre los patrones de acceso y el uso, las puertas de enlace deben proporcionar más metadatos de seguimiento, como los identificadores de cliente y de usuario que que realizan las solicitudes.
El registro centralizado de todas las solicitudes que pasan por la puerta de enlace ayudan a mantener una pista de auditoría. Una pista de auditoría centralizada es especialmente importante para la solución de problemas, el cumplimiento y para detectar intentos de acceso no autorizados.
Almacenamiento en caché de direcciones de forma segura
Si la puerta de enlace de API es responsable de las finalizaciones de almacenamiento en caché u otros resultados de inferencia, asegúrese de que la identidad del solicitante se considera en la lógica de caché. No devuelva resultados almacenados en caché para identidades que no estén autorizadas para recibir esos datos.
Implementaciones de puerta de enlace
Azure no proporciona una solución o arquitectura de referencia completa para compilar la puerta de enlace en este artículo, por lo que debe compilar y operar la puerta de enlace. Azure API Management se puede usar para crear una solución basada en PaaS mediante directivas integradas y personalizadas. Azure también proporciona ejemplos de implementaciones compatibles con la comunidad que cubren los casos de uso de este artículo. Consulte estos ejemplos al compilar su propia solución de puerta de enlace. Para obtener más información, consulte el vídeo Learn Live: Azure OpenAI application identity and security (Información en directo : identidad y seguridad de la aplicación de Azure OpenAI).
Colaboradores
Los siguientes colaboradores escribieron originalmente este artículo.
Creadores de entidad de seguridad:
- Lizet Pena De Sola | Ingeniero sénior de clientes, FastTrack for Azure
- Bappaditya Banerjee | Ingeniero de clientes sénior, FastTrack for Azure
- James Croft | Ingeniero de clientes, ISV y Centro de excelencia nativo digital
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- RBAC para Azure OpenAI
- Uso de identidades administradas en API Management
- Directivas de Azure API Management
- Autenticación y autorización para las API en API Management
- Protección de una API en API Management mediante OAuth 2.0 y Microsoft Entra ID
- Protección de servicios back-end con la autenticación de certificados de cliente en API Management