Métodos de autenticación admitidos por Azure OpenAI

Completado

Azure OpenAI admite varios métodos de autenticación para garantizar el acceso seguro y controlado a sus recursos. Los métodos principales son:

• Claves de API: Azure OpenAI también admite la autenticación basada en claves de API. Las claves de API se generan en Azure Portal y se pueden usar para autenticar solicitudes en el servicio Azure OpenAI. Este método de autenticación no se recomienda desde una perspectiva de seguridad y solo debe usarse como último recurso. Si debe usar este método de autenticación, es importante controlar las claves de API de forma segura y rotarlas periódicamente para reducir el riesgo de acceso no autorizado.
• Microsoft Entra ID: Este método aprovecha las sólidas funcionalidades de administración de identidades y acceso de Microsoft Entra. Los usuarios y las aplicaciones se autentican mediante identidades de Microsoft Entra, que pueden ser cuentas de usuario tradicionales o identidades administradas. Este método garantiza que solo los usuarios autenticados y autorizados puedan acceder a los recursos de Azure OpenAI.
• Identidades administradas de Entra: Las identidades administradas para recursos de Azure proporcionan una identidad administrada automáticamente en Microsoft Entra a fin de que las aplicaciones se usen al conectarse a recursos que admiten la autenticación de Microsoft Entra. Estas identidades se pueden asignar por el sistema, lo que significa que están vinculadas a un recurso específico de Azure o asignados por el usuario, lo que permite compartir una única identidad entre varios recursos. Las identidades administradas simplifican la administración de credenciales y mejoran la seguridad mediante la eliminación de la necesidad de credenciales codificadas de forma rígida en el código de aplicación.

¿Por qué las identidades administradas son más seguras que las claves de API?

Las identidades administradas de Microsoft Azure ofrecen una alternativa más segura a las claves de API por varias razones:

1. Las identidades administradas eliminan la necesidad de que los desarrolladores controle las credenciales directamente, lo que reduce el riesgo de exposición accidental o uso incorrecto.
2. Al usar claves de API, los desarrolladores deben insertar estas claves dentro de sus archivos de configuración o código de aplicación.

Las claves de API se pueden exponer involuntariamente a través de repositorios de código fuente, registros u otros medios. Esta exposición puede provocar un acceso no autorizado y posibles infracciones de seguridad. Por el contrario, las identidades administradas proporcionan una identidad administrada automáticamente para que las aplicaciones se usen al conectarse a recursos que admiten la autenticación de Microsoft Entra (anteriormente Azure AD). Esto significa que las credenciales no se almacenan en el código de la aplicación, lo que reduce el riesgo de fugas y acceso no autorizado.

Además, las identidades administradas simplifican el proceso de autenticación al permitir que los servicios de Azure se autentiquen en otros servicios de Azure de forma segura sin necesidad de credenciales explícitas. Esto se logra mediante el uso de tokens emitidos por Microsoft Entra, que se administran y rotan automáticamente, lo que garantiza que las credenciales siempre están actualizadas y reducen el riesgo de robo de credenciales. Las claves de API, por otro lado, son estáticas y requieren rotación manual, lo que puede ser propenso a errores y a menudo descuidado, lo que conduce a posibles vulnerabilidades. Mediante el uso de identidades administradas, los desarrolladores pueden aprovechar las características de seguridad integradas de Azure, como el control de acceso basado en roles (RBAC), para conceder permisos precisos a los recursos y mejorar aún más la seguridad.

Microsoft recomienda usar identidad administrada a través de claves de API al autenticarse en Azure OpenAI o en cualquier otro servicio de Azure que admita identidad administrada.

Diferencias entre el uso de claves de API e identidades administradas en Azure OpenAI

Vamos a evaluar el impacto de un identificador de cliente filtrado frente a una clave de API filtrada.

Una clave de API funciona de forma similar a una contraseña normal. Si está en peligro, cualquier persona con la clave puede acceder al recurso. Para Azure OpenAI, esto significa un uso sin restricciones de modelos de IA como GPT-4. Si la red es accesible públicamente, el impacto en la seguridad podría ser aún mayor.

Por el contrario, si se filtra el identificador de cliente, los riesgos son mínimos. Esto se debe a que el identificador de cliente por sí solo no puede establecer una conexión a Azure OpenAI. Para usar una identidad administrada, el servicio debe funcionar en Azure e incluso si Azure OpenAI es público, no se puede conectar desde un entorno local ni a través de una red mediante una aplicación.

En resumen, en comparación con las ramificaciones de una clave de API filtrada, aprovechar un identificador de cliente filtrado implica varios pasos, lo que dificulta la explotación de actores malintencionados.

Por estos motivos, las identidades administradas ofrecen un método más seguro para administrar las operaciones en comparación con las claves de API. Se recomienda en los términos más seguros posibles que use identidad administrada a través de claves de API al autenticarse en Azure OpenAI o en cualquier otro servicio de Azure que admita identidad administrada.

Identidades asignadas por el sistema frente a las asignadas por el usuario

Al compilar una aplicación de Azure OpenAI, comprender la distinción entre identidades asignadas por el sistema y asignadas por el usuario es fundamental para una seguridad y administración óptima de recursos.

• Azure crea y administra identidades asignadas por el sistema para un recurso específico. Cuando se elimina un recurso, también se elimina su identidad asignada por el sistema asociada, lo que garantiza que el ciclo de vida de la identidad esté estrechamente unido al recurso al que pertenece. Este tipo de identidad es ideal para escenarios en los que una sola identidad solo necesita usarse, lo que proporciona simplicidad y reduce la sobrecarga administrativa, ya que Azure administra las credenciales de la identidad.
• Las identidades asignadas por el usuario se crean independientemente de cualquier recurso específico y se pueden compartir entre varios recursos. Esto hace que sean muy versátiles para las aplicaciones que requieren una identidad coherente en distintos recursos, lo que facilita la administración de permisos y controles de acceso. Las identidades asignadas por el usuario se conservan incluso después de que se eliminen los recursos que los usan, lo que permite una mayor flexibilidad en la reimplementación y reutilización de identidades.

Elegir entre identidades asignadas por el sistema y asignadas por el usuario depende de las necesidades específicas de la aplicación. En el caso de las aplicaciones de un solo recurso en las que la simplicidad y la administración mínima son prioridades, las identidades asignadas por el sistema suelen ser la mejor opción. Por el contrario, para las aplicaciones que requieren una identidad compartida en varios recursos, las identidades asignadas por el usuario ofrecen mayor flexibilidad y reutilización.