Selección de un modelo de autorización para Azure Storage
Una vez configuradas las opciones de seguridad fundamentales, debe seleccionar un modelo de autorización que controle quién y qué puede acceder a los datos de almacenamiento. Azure Storage proporciona tres enfoques de autorización, cada uno con diferentes características de seguridad y casos de uso adecuados.
Introducción a los modelos de autorización
Azure Storage admite la autorización de clave compartida, firmas de acceso compartido (SAS) y Microsoft Entra ID con control de acceso basado en rol (RBAC). La elección que realice afecta a la posición de seguridad, a la complejidad operativa y a las funcionalidades de auditoría.
| Modelo de autorización | Basado en la identidad | Revocable sin rotación de claves | Registro de auditoría | Recomendación de Microsoft |
|---|---|---|---|---|
| Clave compartida (clave de cuenta) | No | No | Limitado | Eliminar |
| Firma de acceso compartido (SAS) | Parcial | Depende del tipo | Parcial | Uso solo de SAS de delegación de usuarios |
| Microsoft Entra ID + RBAC | Sí | Sí | Completo | Opción preferida |
La autorización de clave compartida usa las claves de acceso de la cuenta de almacenamiento: dos secretos de 512 bits que conceden acceso completo a toda la cuenta. Cualquier aplicación o usuario con una clave de cuenta tiene acceso sin restricciones a todos los blobs, colas, tablas y archivos de la cuenta de almacenamiento. Estas claves aparecen en cadenas de conexión y a menudo se insertan en los archivos de configuración de la aplicación, lo que hace que sean vulnerables a la exposición. Además, revocar el acceso requiere rotar las claves, lo que interrumpe todas las aplicaciones que usan esas claves hasta que se vuelvan a configurar. Microsoft recomienda eliminar completamente la autorización de clave compartida.
Firmas de acceso compartido
Las firmas de acceso compartido proporcionan acceso pormenorizados y limitados al tiempo a recursos de almacenamiento específicos. Azure Storage admite tres tipos de SAS, cada uno con diferentes implicaciones de seguridad.
SaS de servicio tiene como destino un único servicio (Blob, Queue, Table o File) y está firmado con una clave de cuenta de almacenamiento. Especifique el recurso (contenedor o blob), los permisos (lectura, escritura, eliminación) y la hora de expiración. Los tokens de SAS de servicio proporcionan un acceso más limitado que las claves de cuenta completas, pero comparten una debilidad crítica: se firman con la clave de cuenta. Si necesita revocar un token SAS de servicio, deberá rotar la clave de la cuenta, lo que provocará que dejen de funcionar todas las demás aplicaciones que utilicen dicha clave. Sin embargo, al asociar una SAS de servicio a una directiva de acceso almacenada, obtendrá funcionalidad de revocación sin rotación de claves (que se trata en la unidad siguiente).
SAS de cuenta proporciona un acceso más amplio a varios servicios y tipos de recursos, y también se firma con una clave de la cuenta de almacenamiento. Los tokens SAS de cuenta son útiles para operaciones entre servicios, pero plantean el mismo problema de revocación que los tokens SAS de servicio. Dado que están firmados con la clave de la cuenta, no es posible revocarlos sin una rotación de claves, y no existe ningún mecanismo de política de acceso almacenada para las SAS de cuenta.
SAS de delegación de usuario se firma mediante credenciales de Microsoft Entra ID en lugar de la clave de la cuenta de almacenamiento. Este enfoque combina el acceso granular y limitado de tiempo de SAS con las ventajas de seguridad de la autorización basada en identidades. Al crear una SAS de delegación de usuarios, Azure Storage emite una clave de delegación de usuarios válida durante un máximo de siete días. El token de SAS se firma con esta clave de delegación, no con la clave de la cuenta de almacenamiento. Si necesita revocar el acceso, revoque las credenciales de Microsoft Entra ID usadas para crear la clave de delegación y todos los tokens de SAS asociados dejan de funcionar inmediatamente. La SAS de delegación de usuario es el único tipo de SAS que recomienda Microsoft.
Microsoft Entra ID con RBAC
La autorización con Microsoft Entra ID y control de acceso basado en roles es el enfoque preferido para Azure Storage. Este modelo usa identidades (usuarios, grupos, entidades de servicio, identidades administradas) y les asigna roles que definen permisos específicos. A diferencia de la autorización de clave compartida, RBAC proporciona control de acceso por identidad con seguimientos de auditoría completos en Azure Monitor.
Azure Storage proporciona varios roles RBAC integrados para el acceso a datos. El Lector de datos de Storage Blob concede acceso de lectura a contenedores y blobs. Colaborador de datos de Storage Blob otorga acceso de lectura, escritura y eliminación. El propietario de datos de Storage Blob concede control total, incluida la capacidad de establecer permisos. Estos roles solo se aplican a las operaciones del plano de datos (lectura y escritura de blobs), no conceden acceso a las operaciones de administración de cuentas de almacenamiento, como cambiar las opciones de configuración.
Para la canalización de procesamiento de documentos de IA de Contoso, las instancias de Azure Functions que hospedan los agentes de IA deben usar una identidad administrada con el rol Storage Blob Data Reader asignado. Las identidades administradas eliminan la necesidad de almacenar credenciales en la configuración de la aplicación. El tiempo de ejecución de Azure Functions obtiene tokens de Microsoft Entra ID automáticamente y estos tokens se usan para autenticar las solicitudes de almacenamiento.
Implementación del acceso de identidad administrada
Cuando Azure Functions usa una identidad administrada para acceder al almacenamiento, el código de la aplicación usa la biblioteca Azure Identity y la clase DefaultAzureCredential. Este tipo de credencial detecta automáticamente la identidad administrada en el entorno de Azure Functions y obtiene tokens sin ninguna administración explícita de credenciales en el código.
Puede habilitar la identidad administrada en la aplicación de funciones de Azure en el portal, en Identidad>Asignadas por el sistema>Estado: Activada. A continuación, asigne la identidad administrada al rol Storage Blob Data Reader en la cuenta de almacenamiento mediante Access Control (IAM)>Asignación de roles. Una vez que la asignación de roles se propaga (permite hasta 30 minutos), el código de Azure Functions se autentica en el almacenamiento mediante la identidad administrada.
Tip
Azure admite dos tipos de identidad administrada: asignados por el sistema y asignados por el usuario. Una identidad asignada por el sistema está vinculada a un único recurso y se elimina cuando se elimina ese recurso, una buena opción para escenarios de agente único como Contoso. Existe una identidad asignada por el usuario de forma independiente y se puede compartir entre varios recursos de proceso. Considere usar una identidad administrada asignada por el usuario si la arquitectura de IA ejecuta varias instancias de agente o si planea migrar agentes a otro tipo de proceso de ejecución, como Azure Container Apps. Todos los agentes comparten una identidad auditable, lo que simplifica la asignación de roles y facilita la revisión de los registros de auditoría.
Este enfoque elimina completamente las claves de cuenta de almacenamiento de la configuración de la aplicación. Los agentes de IA acceden al almacenamiento mediante tokens basados en identidades que expiran y se actualizan automáticamente. Se aplican todas las directivas de acceso condicional, los registros de auditoría y la administración del ciclo de vida de identidad. Para el equipo de seguridad de Contoso, esta migración de claves de cuenta a identidades administradas resuelve la vulnerabilidad identificada en la auditoría de seguridad.