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

Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con Microsoft Entra ID, puede usar el control de acceso basado en roles de Azure (Azure RBAC) para conceder permisos a una entidad de seguridad, que puede ser un usuario, un grupo 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 Blob service.

La autorización con credenciales de Microsoft Entra ID está disponible para todas las cuentas de propósito general y de Blob Storage 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.

Para una seguridad óptima, Microsoft recomienda usar Microsoft Entra ID con identidades administradas para autorizar solicitudes contra datos de blobs, colas y tablas, siempre que sea posible. La autorización con Microsoft Entra ID e identidades administradas proporciona mayor seguridad y facilidad de uso a través de la autorización de clave compartida. Para más información sobre las identidades administradas, consulte ¿Qué son las identidades administradas para los recursos de Azure? Para obtener un ejemplo de cómo habilitar y usar una identidad administrada para una aplicación .NET, consulte Autenticación de aplicaciones hospedadas en Azure en recursos de Azure con .NET.

En el caso de los recursos hospedados fuera de Azure, como las aplicaciones locales, puede usar identidades administradas a través de Azure Arc. Por ejemplo, las aplicaciones que se ejecutan en servidores habilitados para Azure Arc pueden usar identidades administradas para conectarse a los servicios de Azure. Para más información, consulte Autenticación en recursos de Azure con servidores habilitados para Azure Arc.

En escenarios en los que se usan firmas de acceso compartido (SAS), Microsoft recomienda usar una SAS de delegación de usuarios. Una SAS de delegación de usuarios está protegida con credenciales de Microsoft Entra en lugar de la clave de cuenta. Para obtener información sobre las firmas de acceso compartido, consulte Concesión de acceso limitado a los datos con firmas de acceso compartido. Para obtener un ejemplo de cómo crear y usar una SAS de delegación de usuarios con .NET, consulte Creación de una SAS de delegación de usuarios para un blob con .NET.

Introducción a Microsoft Entra ID para blobs

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

• Autenticación: la identidad del principal de seguridad es autenticada 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 el runtime. 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 datos de blobs.

• Autorización: el token se pasa como parte de una solicitud al servicio Blob y lo usa el servicio para autorizar el acceso al recurso especificado en función de los permisos concedidos a la entidad de seguridad.

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

Para obtener información sobre cómo acceder a los datos en Azure Portal con una cuenta de Microsoft Entra, consulte Acceso a datos desde Azure Portal. Para obtener información sobre cómo llamar a comandos de Azure PowerShell o la CLI de Azure con una cuenta de Microsoft Entra, consulte 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:

• Se recomienda la biblioteca cliente de Azure Identity 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 Identidad de Azure simplifica el proceso de obtención de un token de acceso de OAuth 2.0 para la autorización con el identificador de Microsoft Entra 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 cada uno de esos lenguajes para proporcionar un medio sencillo y seguro para adquirir 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 los recursos de Azure, una entidad de servicio o un usuario o 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. Después, puede usar la credencial del 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, la biblioteca MSAL puede ser adecuada para usarla en determinados escenarios avanzados. Para obtener más información, consulte Más información sobre MSAL.

Al usar MSAL para adquirir un token de OAuth para acceder a Azure Storage, debe proporcionar un id. de recurso de Microsoft Entra. El id. de recurso de Microsoft Entra indica la audiencia para la que se puede usar un token emitido para proporcionar acceso a un recurso de Azure. En el caso de Azure Storage, el id. de recurso puede ser específico de una sola cuenta de almacenamiento o puede aplicarse a cualquiera de ellas.

Cuando se proporciona un id. de recurso específico de una sola cuenta de almacenamiento y servicio, el id. de recurso se usa para adquirir un token para autorizar solicitudes solo para la cuenta y el servicio especificados. En la tabla siguiente se enumeran ejemplos de valores que se usarán para el identificador de recurso, en función de la nube con la que trabaja. 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 la 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 blobs. También puede definir roles personalizados para el acceso a los datos de blobs. Para más información sobre cómo asignar roles de Azure para el acceso a blobs, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

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 los recursos de Azure. Los roles de RBAC asignados a una entidad de seguridad determinan los permisos que tiene la entidad de seguridad para el recurso especificado. Para más información sobre cómo asignar roles de Azure para el acceso a blobs, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

En algunos casos, es posible que tenga que habilitar el acceso específico a los recursos de blobs o simplificar los permisos cuando tenga 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 condiciones en las asignaciones 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 Azure Storage con ABAC, consulte Autorización del acceso a blobs mediante condiciones de asignación de roles de Azure (versión preliminar). Para más información sobre las condiciones admitidas para las operaciones de datos de blobs, consulte Acciones y atributos para las condiciones de asignación de roles de Azure en Azure Storage (versión preliminar).

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 Blob Storage. Puede asignarlo en el nivel de su suscripción, grupo de recursos, cuenta de almacenamiento o contenedor.

Ámbito de recursos

Antes de asignar un rol RBAC de Azure a una entidad de seguridad, determine el ámbito de acceso que debe tener la entidad de seguridad. Conceda siempre el ámbito más estrecho posible necesario para que el principal de seguridad pueda realizar 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 definir el ámbito del acceso a los recursos de blobs de Azure en los siguientes niveles, empezando por el ámbito más estrecho (más restrictivo):

• Un contenedor individual. En este ámbito, una asignación de roles se aplica a todos los blobs del contenedor y a las propiedades y metadatos del contenedor.
• La cuenta de almacenamiento. En este ámbito, una asignación de roles se aplica a todos los contenedores y sus blobs.
• el grupo de recursos. En este ámbito, una asignación de roles se aplica a todos los contenedores de todas las cuentas de almacenamiento del grupo de recursos.
• La suscripción. En este ámbito, una asignación de roles se aplica a todos los contenedores de todas las cuentas de almacenamiento de todos los grupos de recursos de la suscripción.
• Un grupo de administración. En este ámbito, una asignación de roles se aplica a todos los contenedores 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 blobs

Azure RBAC proporciona varios roles integrados para autorizar el acceso a los datos de blobs mediante Microsoft Entra ID y OAuth. Algunos ejemplos de roles que proporcionan permisos para los recursos de datos en Azure Storage incluyen:

• Propietario de datos de Storage Blob: proporciona acceso completo a los contenedores y datos de blobs, incluida la capacidad de establecer la propiedad y administrar el control de acceso POSIX para Azure Data Lake Storage Gen2. Use este rol cuando los usuarios necesiten un control completo sobre los recursos de blobs. Para más información, consulte Control de acceso en Azure Data Lake Storage Gen2.
• Colaborador de datos de Storage Blob: concede permisos de lectura, escritura y eliminación a los recursos de Blob Storage. Este es el rol adecuado para los usuarios que necesitan modificar los datos de blobs, pero no requieren la propiedad ni las funcionalidades de administración de ACL.
• Lector de datos de Storage Blob: concede permisos de solo lectura a los recursos de Blob Storage. Use este rol para usuarios o aplicaciones que solo necesiten ver o descargar datos de blobs sin derechos de modificación.
• Delegador de blobs de Storage: permite obtener una clave de delegación de usuarios para crear una firma de acceso compartido firmada con las credenciales de Microsoft Entra. Este rol es útil para escenarios en los que es necesario delegar el acceso limitado a los recursos de blobs sin compartir claves de cuenta.

Para obtener información sobre cómo asignar un rol integrado de Azure a una entidad de seguridad, consulte Asignación de un rol de Azure para el acceso a datos de blobs. Para obtener información sobre cómo enumerar los roles RBAC de Azure y sus permisos, consulte Enumeración de definiciones de roles de Azure.

Para más información sobre cómo se definen los roles integrados para Azure Storage, consulte Descripción de las definiciones de roles. Para obtener información sobre cómo crear roles personalizados de Azure, consulte Roles personalizados de Azure.

Solo los roles definidos explícitamente para el acceso a datos permiten a una entidad de seguridad acceder a los datos de blobs. Los roles integrados, como propietario, colaborador y colaborador de la cuenta de almacenamiento, permiten que una entidad de seguridad administre una cuenta de almacenamiento, pero no proporcionan acceso a los datos del blob 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. Para más información, consulte Elección de cómo autorizar el acceso a datos de blobs en Azure Portal.

Para obtener información detallada sobre los roles integrados de Azure para Azure Storage para los servicios de datos y el servicio de administración, consulte la sección Almacenamiento en Roles integrados de Azure para Azure RBAC. Además, para obtener información sobre los distintos tipos de roles que proporcionan permisos en Azure, consulte Roles de Azure, roles de Microsoft Entra y roles de administrador de suscripciones clásicas.

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

Permisos de acceso para operaciones de datos

Para más información sobre los permisos necesarios para llamar a operaciones específicas de Blob Service, consulte Permisos para llamar a operaciones de datos.

Acceder a los datos con una cuenta de Microsoft Entra

El acceso a los datos de blob 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).

Recomendaciones de seguridad:

• 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 o la autenticación multifactor. 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 requiere delegación directa de acceso de usuario, use una SAS de delegación de usuarios protegida con credenciales de Microsoft Entra en lugar de una SAS de cuenta. Para obtener más información, consulte Autorización de operaciones para el acceso a datos.

Acceso a datos desde Azure Portal

Azure Portal puede usar su cuenta de Microsoft Entra o las claves de acceso de la cuenta para acceder a los datos de blob 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 blobs, Azure Portal comprueba primero si se le ha asignado un rol de Azure con Microsoft.Storage/storageAccounts/listkeys/action. Si tiene un rol asignado con esta acción, Azure Portal usa la clave de cuenta para acceder a los datos de blobs mediante la autorización de clave compartida. Si no se le ha asignado un rol con esta acción, Azure Portal intenta acceder a los datos mediante su cuenta de Microsoft Entra.

Para acceder a los datos de blobs desde Azure Portal mediante su cuenta de Microsoft Entra, necesita permisos para acceder a los datos del blob y también necesita permisos para navegar por los recursos de la cuenta de almacenamiento en Azure Portal. Los roles integrados que proporciona Azure Storage conceden acceso a recursos de blobs, 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 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. Para más información sobre cómo asignar permisos a los usuarios para el acceso a datos en Azure Portal con una cuenta de Microsoft Entra, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

Azure Portal indica qué esquema de autorización se está usando al examinar un contenedor. Para más información sobre el acceso a datos en el portal, consulte Elección de cómo autorizar el acceso a datos de blobs en Azure Portal.

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.

Soporte de funcionalidades

La compatibilidad con esta característica puede verse afectada al habilitar Data Lake Storage Gen2, el protocolo Network File System (NFS) 3.0 o el Protocolo de transferencia de archivos SSH (SFTP).

Procedimientos recomendados para autorizar el acceso a blobs

Al implementar la autorización de Microsoft Entra ID para Blob Storage, siga estas prácticas recomendadas de seguridad:

• Uso de identidades administradas: para las aplicaciones que se ejecutan en Azure (VM, App Service, Functions, AKS), use siempre identidades administradas en lugar de entidades de servicio con credenciales almacenadas.
• Implementar privilegios mínimos: asigne el rol más restrictivo que cumpla los requisitos. Use el Lector de datos de blobs de Storage para escenarios de solo lectura en lugar de más roles permisivos.
• Delimite el ámbito de las asignaciones de forma correcta: aplique asignaciones de roles en el nivel de contenedor siempre que sea posible en lugar de en el nivel de cuenta de almacenamiento o suscripción.
• Aprovechamiento de Azure ABAC: use las condiciones de control de acceso basado en atributos (ABAC) para el control de acceso específico cuando necesite restringir el acceso en función de los atributos de recursos, como el nombre del contenedor, la ruta de acceso del blob o las etiquetas.
• Deshabilitar la autorización de clave compartida: una vez que haya migrado a la autenticación de Id. de Microsoft Entra, deshabilite 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.
• Utilice SAS de delegación de usuario: cuando necesite proporcionar acceso temporal, prefiera SAS de delegación de usuario en lugar de SAS de cuenta o SAS de servicio, ya que están protegidas con credenciales de Microsoft Entra.
• Supervisión del acceso: habilite el registro de diagnóstico y revise los registros de Azure Monitor con regularidad para realizar un seguimiento de quién accede a los datos del blob e identificar cualquier actividad sospechosa.
• Aplicar 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 los controles de acceso basados en ubicación.