Selección y configuración de un método adecuado para el acceso a las colas de Azure

Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos en cola. Con Microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad, que puede ser un usuario o una entidad de servicio de aplicación. Microsoft Entra ID autentica la entidad de seguridad para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Queue service.

La autorización con Microsoft Entra ID proporciona más seguridad y facilidad de uso que la autorización con clave compartida. Microsoft recomienda usar la autorización de Microsoft Entra con las aplicaciones de cola siempre que sea posible para garantizar el acceso con los privilegios mínimos necesarios. En el caso de las aplicaciones que se ejecutan en Azure, use identidades administradas para eliminar la necesidad de almacenar credenciales en el código.

La autorización con microsoft Entra ID está disponible para todas las cuentas de almacenamiento de uso general en todas las regiones públicas y nubes nacionales. Solo las cuentas de almacenamiento creadas con el modelo de implementación de Azure Resource Manager admiten la autorización de Microsoft Entra.

Información general de Microsoft Entra ID para colas

Cuando una entidad de seguridad (un usuario, un grupo o una aplicación) intenta acceder a un recurso de cola, la solicitud debe estar autorizada. Con Microsoft Entra ID, el acceso a un recurso es un proceso de dos pasos:

• Autenticación: la identidad del principal de seguridad se autentica y se devuelve un token de OAuth 2.0. El paso de autenticación exige que una aplicación solicite un token de acceso de OAuth 2.0 en tiempo de ejecución. Si una aplicación se ejecuta desde una entidad de Azure como una máquina virtual de Azure, un conjunto de escalado de máquinas virtuales o una aplicación de Azure Functions, puede usar una identidad administrada para acceder a los datos de la cola. El uso de identidades administradas es el enfoque recomendado , ya que elimina la necesidad de administrar las credenciales.
• Autorización: el token se pasa como parte de una solicitud al servicio Queue y lo usa el servicio para autorizar el acceso al recurso especificado. El paso de la autorización exige que se asignen uno o varios roles Rol RBAC de Azure a la entidad de seguridad que realiza la solicitud.

Uso de una cuenta de Microsoft Entra con el portal, PowerShell o la CLI de Azure

Para más información sobre cómo acceder a los datos en el Azure Portal con una cuenta de Microsoft Entra, vea Acceso a datos desde el Azure Portal. Para aprender a invocar comandos de Azure PowerShell o la CLI de Azure con una cuenta de Microsoft Entra, vea Acceso a datos desde PowerShell o la CLI de Azure.

Uso de Microsoft Entra ID para autorizar el acceso en el código de la aplicación

Para autorizar el acceso a Azure Storage con Microsoft Entra ID, puede usar una de las siguientes bibliotecas cliente para adquirir un token de OAuth 2.0:

• La biblioteca cliente de Azure Identity se recomienda para la mayoría de los escenarios de desarrollo.
• La Biblioteca de autenticación de Microsoft (MSAL) puede ser adecuada para determinados escenarios avanzados.

Biblioteca cliente de Azure Identity

La biblioteca cliente de Azure Identity simplifica el proceso de obtener un token de acceso de OAuth 2.0 para la autorización con Microsoft Entra ID a través del SDK de Azure. Las versiones más recientes de las bibliotecas cliente de Azure Storage para .NET, Java, Python, JavaScript y Go se integran con las bibliotecas de Azure Identity para dichos lenguajes para proporcionar un medio sencillo y seguro de obtener un token de acceso para la autorización de las solicitudes de Azure Storage.

Una ventaja de la biblioteca cliente de Azure Identity es que permite usar el mismo código para adquirir el token de acceso tanto si la aplicación se ejecuta en el entorno de desarrollo como en Azure. La biblioteca cliente de Azure Identity devuelve un token de acceso para una entidad de seguridad. Cuando el código se ejecuta en Azure, la entidad de seguridad puede ser una identidad administrada para recursos de Azure, una entidad de servicio, un usuario o un grupo. En el entorno de desarrollo, la biblioteca cliente proporciona un token de acceso para un usuario o una entidad de servicio con fines de prueba.

El token de acceso devuelto por la biblioteca cliente de Azure Identity se encapsula en una credencial de token. A continuación, puede usar la credencial de token para obtener un objeto de cliente de servicio que se usará para realizar operaciones autorizadas en Azure Storage. Una manera sencilla de obtener el token de acceso y la credencial de token es usar la clase DefaultAzureCredential proporcionada por la biblioteca cliente de Identidad de Azure. DefaultAzureCredential intenta obtener la credencial del token probando secuencialmente varios tipos de credenciales diferentes. DefaultAzureCredential funciona tanto en el entorno de desarrollo como en Azure.

En la tabla siguiente se señala información adicional para autorizar el acceso a los datos en varios escenarios:

Biblioteca de autenticación de Microsoft (MSAL)

Aunque Microsoft recomienda usar la biblioteca cliente de Azure Identity siempre que sea posible, podría ser adecuado usar la biblioteca MSAL en determinados escenarios avanzados.

Cuando se usa MSAL para adquirir un token de OAuth para el acceso a Azure Storage, debe proporcionar un recurso de Microsoft Entra ID. Un identificador de recurso de Microsoft Entra indica el público con el que se puede usar un token emitido para proporcionar acceso a un recurso de Azure. En el caso de Azure Storage, el identificador de recurso puede ser específico de una sola cuenta de almacenamiento o puede aplicarse a cualquiera de ellas.

Cuando se proporciona un identificador de recurso específico de una sola cuenta de almacenamiento y servicio, el identificador de recurso se usa para adquirir un token para autorizar solicitudes a la cuenta y el servicio especificados. En la tabla siguiente se muestra el valor que se usará para el identificador de recurso, en función de la nube con la que esté trabajando. Reemplace <account-name> por el nombre de la cuenta de almacenamiento.

También puede proporcionar un id. de recurso que se aplique a cualquier cuenta de almacenamiento, como se muestra en la tabla siguiente. Este id. de recurso es el mismo para todas las nubes públicas y soberanas y se usa para adquirir un token para autorizar las solicitudes a cualquier cuenta de almacenamiento.

Asignación de roles de Azure para derechos de acceso

Microsoft Entra autoriza los derechos de acceso a los recursos protegidos mediante el RBAC de Azure. Azure Storage define un conjunto de roles RBAC integrados que abarcan conjuntos comunes de permisos usados para acceder a los datos de cola. También puede definir roles personalizados para el acceso a los datos de cola.

Una entidad de seguridad de Microsoft Entra puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada para recursos de Azure. Los roles RBAC que se asignan a una entidad de seguridad determinan los permisos que tiene esa entidad de seguridad.

En algunos casos, es posible que tenga que habilitar el acceso específico a los recursos de cola o simplificar los permisos cuando tiene un gran número de asignaciones de roles para un recurso de almacenamiento. Puede usar el control de acceso basado en atributos de Azure (Azure ABAC) para configurar las condiciones de asignación de roles. Puede usar condiciones con un rol personalizado o seleccionar roles integrados. Para más información sobre cómo configurar condiciones para los recursos de almacenamiento de Azure con ABAC, consulte Autorización del acceso a colas mediante condiciones de asignación de roles de Azure.

Al crear una cuenta de Azure Storage, no se le asignan automáticamente permisos para acceder a los datos a través de Microsoft Entra ID. Debe asignarse explícitamente un rol de Azure para acceder a Queue Storage. Puede asignarlo al nivel de su suscripción, grupo de recursos, cuenta de almacenamiento o cola.

Ámbito de recursos

Antes de asignar un rol de Azure RBAC a una entidad de seguridad, determine el ámbito de acceso que debería tener la entidad de seguridad. Otorgue siempre el alcance más restringido posible necesario para que el principal de seguridad realice sus tareas. Esto sigue el principio de privilegios mínimos y minimiza los riesgos de seguridad. Los roles de Azure RBAC definidos en un ámbito más amplio los heredan los recursos que están debajo de ellos.

Puede limitar el acceso a los recursos de cola de Azure en los siguientes niveles, empezando por el ámbito más estrecho (más restrictivo):

• Una cola individual. En este ámbito, una asignación de roles se aplica a los mensajes de la cola y a las propiedades y metadatos de la cola.
• La cuenta de almacenamiento. En este ámbito, una asignación de roles se aplica a todas las colas y sus mensajes.
• El grupo de recursos. En este ámbito, se aplica una asignación de roles a todas las colas de todas las cuentas de almacenamiento del grupo de recursos.
• La suscripción. En este ámbito, se aplica una asignación de roles a todas las colas de todas las cuentas de almacenamiento de todos los grupos de recursos de la suscripción.
• Un grupo de administración. En este ámbito, se aplica una asignación de roles a todas las colas de todas las cuentas de almacenamiento de todos los grupos de recursos de todas las suscripciones del grupo de administración.

Roles integrados de Azure para colas

Azure RBAC proporciona varios roles integrados para autorizar el acceso a los datos de cola mediante microsoft Entra ID y OAuth. Entre los roles que proporcionan permisos a los recursos de datos en Azure Storage están, por ejemplo, los siguientes:

• Colaborador de datos de la cola de Storage: concede permisos de lectura, escritura y eliminación a las colas de Azure. Use este rol para aplicaciones o usuarios que necesitan acceso total a los mensajes de cola.
• Lector de datos de cola de almacenamiento: concede permisos de solo lectura a las colas de Azure. Use este rol para aplicaciones o usuarios que solo necesiten ver los mensajes de cola sin derechos de modificación.
• Procesador de mensajes de datos de la cola de Storage: concede permisos de inspección, recuperación y eliminación a los mensajes de las colas de Azure Storage. Use este rol para las aplicaciones de trabajadores que procesan y eliminan mensajes de las colas.
• Emisor de mensajes de datos de la cola de Storage: concede permisos de adición a los mensajes de las colas de Azure Storage. Use este rol para las aplicaciones que solo necesitan poner en cola mensajes sin leerlos ni eliminarlos.

Solo los roles definidos explícitamente para el acceso a datos permiten a una entidad de seguridad acceder a los datos de colas. Los roles integrados, como Propietario, Colaborador y Colaborador de cuenta de almacenamiento, permiten que una entidad de seguridad administre una cuenta de almacenamiento, pero no proporcionan acceso a los datos de cola dentro de esa cuenta a través de Microsoft Entra ID. Sin embargo, si un rol incluye Microsoft.Storage/storageAccounts/listKeys/action, un usuario al que se asigna ese rol puede acceder a los datos de la cuenta de almacenamiento a través de la autorización de clave compartida con las claves de acceso de la cuenta.

Las asignaciones de roles de Azure pueden tardar hasta 30 minutos en propagarse.

Acceso a datos con una cuenta de Microsoft Entra

El acceso a los datos de cola a través de Azure Portal, PowerShell o la CLI de Azure se puede autorizar mediante la cuenta de Microsoft Entra del usuario o mediante las claves de acceso de la cuenta (autorización de clave compartida).

• Evitar la autorización de clave compartida: no se recomienda la autorización con clave compartida, ya que proporciona acceso completo a la cuenta de almacenamiento y no admite características de seguridad avanzadas, como el acceso condicional. Para una seguridad óptima, deshabilite la autorización mediante clave compartida para la cuenta de almacenamiento, como se describe en Impedir la autorización de clave compartida para una cuenta de Azure Storage.
• Limitar el uso de claves de acceso: el uso de claves de acceso y cadenas de conexión debe limitarse a la prueba inicial de aplicaciones de concepto o prototipos de desarrollo que no tienen acceso a datos confidenciales o de producción. En el caso de las cargas de trabajo de producción, use siempre las clases de autenticación basadas en tokens disponibles en el SDK de Azure.
• Preferir Microsoft Entra ID: Microsoft recomienda que los clientes usen Microsoft Entra ID para el método de autorización más seguro. Cuando se requiera delegación, use una SAS de delegación de usuarios para Blob Storage protegida con credenciales de Microsoft Entra.

Acceso a datos desde Azure Portal

Azure Portal puede usar la cuenta de Microsoft Entra o las claves de acceso de cuenta para acceder a datos de cola en una cuenta de Azure Storage. El esquema de autorización que use Azure Portal depende de los roles de Azure que tenga asignados.

Al intentar acceder a los datos de la cola, el portal de Azure primero comprueba si se le ha asignado un rol de Azure con Microsoft.Storage/storageAccounts/listkeys/action. Si se le ha asignado un rol con esta acción, Azure Portal usa la clave de cuenta para acceder a los datos de cola a través de la autorización de clave compartida. Si no tiene un rol asignado con esta acción, Azure Portal intenta acceder a los datos mediante la cuenta de Microsoft Entra.

Para acceder a los datos de cola desde Azure Portal mediante su cuenta de Microsoft Entra, necesita permisos para acceder a los datos de la cola y también necesita permisos para navegar por los recursos de la cuenta de almacenamiento en Azure Portal. Los roles integrados proporcionados por Azure Storage conceden acceso a los recursos de cola, pero no conceden permisos a los recursos de la cuenta de almacenamiento. Por este motivo, el acceso al portal también requiere la asignación de un rol de Azure Resource Manager, como el rol Lector, con ámbito limitado al nivel de la cuenta de almacenamiento o superior. El rol Lector concede los permisos más restringidos, pero otro rol de Azure Resource Manager que concede acceso a los recursos de administración de cuentas de almacenamiento también es aceptable.

Acceso a datos desde PowerShell o la CLI de Azure

La CLI de Azure y PowerShell admiten el inicio de sesión con credenciales de Microsoft Entra. Después de iniciar sesión, la sesión se ejecuta con esas credenciales. Para obtener más información, vea uno de los siguientes artículos:

• Distintas formas de autorizar el acceso para poner datos en cola con la CLI de Azure
• Ejecución de comandos de PowerShell con credenciales de Microsoft Entra para acceder a los datos de la cola

Procedimientos recomendados para autorizar el acceso a colas

Al implementar la autorización de Identificador de Entra de Microsoft para Azure Queue Storage, siga estos procedimientos recomendados de seguridad:

• Uso de identidades administradas: para las aplicaciones que se ejecutan en Azure (VM, App Service, Azure Functions, Container Instances, AKS), use siempre identidades administradas en lugar de entidades de servicio con credenciales almacenadas. Esto elimina la sobrecarga de administración de credenciales y mejora la seguridad.
• Implementar privilegios mínimos: asigne el rol más restrictivo que cumpla los requisitos:
  • Uso de Lector de datos de colas de almacenamiento para aplicaciones que solo necesitan ver los mensajes
  • Use el Emisor de mensajes de datos de la cola de Storage para aplicaciones que solo ponen en cola mensajes
  • Use el Procesador de mensajes de datos de la cola de Storage para aplicaciones de trabajo que procesan y quitan mensajes
  • Use el Colaborador de datos de la cola de Storage solo cuando se requiere acceso completo
• Delimite el ámbito de las asignaciones de forma correcta: aplique asignaciones de roles en el nivel de cola siempre que sea posible en lugar de en el nivel de cuenta de almacenamiento o suscripción. Esto limita el acceso solo a las colas específicas que necesitan los usuarios o las aplicaciones.
• Deshabilitar la autorización de clave compartida: una vez que haya migrado a la autenticación de Id. de Microsoft Entra, considere la posibilidad de deshabilitar la autorización de clave compartida en el nivel de cuenta de almacenamiento para evitar el acceso no autorizado a través de claves de cuenta.
• Uso de roles personalizados para el control específico: si los roles integrados no cumplen sus requisitos específicos, cree roles RBAC de Azure personalizados solo con los permisos necesarios.
• Supervisión de patrones de acceso: habilite el registro de diagnóstico y revise periódicamente los registros de Azure Monitor para realizar un seguimiento del acceso a la cola e identificar cualquier actividad sospechosa o no autorizada.
• Aplicar directivas de acceso condicional: use directivas de acceso condicional de Microsoft Entra para aplicar requisitos de seguridad adicionales, como la autenticación multifactor, el cumplimiento de dispositivos o las restricciones basadas en ubicaciones.
• Implementar lógica de reintento: las aplicaciones basadas en cola deben implementar la lógica de reintento adecuada con retroceso exponencial para controlar correctamente los errores transitorios de autenticación o autorización.
• Revisiones de acceso periódicas: audite periódicamente las asignaciones de roles para asegurarse de que los usuarios y las aplicaciones siguen necesitando sus permisos asignados y quitar el acceso innecesario.
• Entornos independientes: use diferentes cuentas de almacenamiento y asignaciones de roles para entornos de desarrollo, pruebas y producción para minimizar el riesgo de exposición o modificación accidentales de datos.