Autorización del acceso a blobs mediante Microsoft Entra ID
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 rol 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 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 blobs siempre que sea posible para garantizar el acceso con privilegios mínimos necesarios.
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.
Blob Storage también admite la creación de firmas de acceso compartido (SAS) firmadas con credenciales de Microsoft Entra. Para más información, consulte Concesión de acceso limitado a datos con firmas de acceso compartido.
Introducción a Microsoft Entra ID para blobs
Cuando una entidad de seguridad (un usuario, un grupo o una aplicación) intenta acceder a un recurso de blob, la solicitud debe autorizarse, a menos que sea un blob disponible para acceso anónimo. Con Microsoft Entra ID, el acceso a un recurso es un proceso de dos pasos:
En primer lugar, se autentica la identidad de la entidad de seguridad 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 blobs.
Después, el token se pasa como parte de una solicitud a Blob service y el servicio lo usa 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. Para más información, vea Asignación de roles de Azure para derechos de acceso.
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 Azure Identity. 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. Para más información, consulte Más información sobre MSAL.
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.
| Nube | Id. de recurso |
|---|---|
| Azure Global | https://<account-name>.blob.core.windows.net |
| Azure Government | https://<account-name>.blob.core.usgovcloudapi.net |
| Azure China 21Vianet | https://<account-name>.blob.core.chinacloudapi.cn |
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.
| Nube | Id. de recurso |
|---|---|
| Azure Global Azure Government Azure China 21Vianet |
https://storage.azure.com/ |
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 utilizados para acceder a los datos de blob. También puede definir roles personalizados para el acceso a datos de blobs. Para más información sobre la asignación de roles de Azure para acceder a blobs, consulte Asignación de un rol de Azure para acceder 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 recursos de Azure. Los roles RBAC que se asignan a una entidad de seguridad determinan los permisos que la entidad de seguridad tiene para el recurso especificado. Para más información sobre la asignación de roles de Azure para acceder a blobs, consulte Asignación de un rol de Azure para acceder a datos de blobs.
En algunos casos, puede que necesite habilitar el acceso específico a los recursos de blob 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 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 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 blob, consulte Acciones y atributos para las condiciones de asignación de roles de Azure en Azure Storage (versión preliminar).
Nota:
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. Tiene que asignarse a sí mismo de forma explícita un rol de Azure para acceder a Blob Storage. Puede asignarlo al nivel de su suscripción, grupo de recursos, cuenta de almacenamiento o un contenedor.
Á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. Los procedimientos recomendados dictan que siempre es mejor conceder únicamente el ámbito más restringido posible. 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 blobs de Azure en los niveles siguientes, empezando por el ámbito más reducido:
- Un contenedor individual. En este ámbito, una asignación de rol 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, se aplica una asignación de roles a todos los contenedores de todas las cuentas de almacenamiento del grupo de recursos.
- Suscripción. En este ámbito, se aplica una asignación de roles 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, se aplica una asignación de roles 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.
Para obtener más información sobre el ámbito de las asignaciones de roles de RBAC de Azure, consulte Información sobre el ámbito de RBAC de Azure.
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. Entre los roles que proporcionan permisos a los recursos de datos en Azure Storage están, por ejemplo, los siguientes:
- Propietario de datos de Storage Blob: se usa para establecer la propiedad y administrar el control de acceso POSIX en Azure Data Lake Storage Gen2. Para más información, consulte Control de acceso en Azure Data Lake Storage Gen2.
- Colaborador de datos de Storage Blob: se usa para conceder permisos de lectura, escritura y eliminación a los recursos de almacenamiento de blobs.
- Lector de datos de Storage Blob: se usa para conceder permisos de solo lectura a los recursos de almacenamiento de blobs.
- Delegador de Blob Storage: obtiene una clave de delegación de usuarios que se usa para crear una firma de acceso compartido que se firma con credenciales de Microsoft Entra para un contenedor o un blob.
Para obtener información sobre cómo asignar un rol integrado de Azure a una entidad de seguridad, vea Asignación de un rol de Azure para acceder a datos de blobs. Para obtener información sobre cómo enumerar los roles RBAC de Azure y sus permisos, consulte Enumeración de las definiciones de roles de Azure.
Para más información acerca de cómo se definen los roles integrados para Azure Storage, consulte Descripción de definiciones de roles. Para más información acerca de la creación de 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 de blob dentro de esa cuenta a través de Microsoft Entra ID. Sin embargo, si un rol incluye Microsoft.Storage/storageAccounts/listKeys/action, el usuario al que se haya asignado ese rol podrá acceder a los datos de la cuenta de almacenamiento mediante la autorización de clave compartida con las claves de acceso de la cuenta. Para obtener más información, vea Elección de la forma de autorizar el acceso a los datos de blob 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 RBAC de Azure. Además, para obtener información sobre los diferentes tipos de roles que proporcionan permisos en Azure, consulte Roles de Azure, roles de Microsoft Entra y roles de administrador de suscripciones clásicas.
Importante
Las asignaciones de roles de Azure pueden tardar hasta 30 minutos en propagarse.
Permisos de acceso para operaciones de datos
Para obtener información sobre los permisos necesarios para llamar a operaciones concretas de Blob service, consulte Permisos para llamar a operaciones de datos.
Acceso a 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).
Precaución
No se recomienda la autorización con clave compartida, ya que puede ser menos segura. Para obtener 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.
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. De lo contrario, siempre se deben preferir las clases de autenticación basadas en tokens disponibles en el SDK de Azure al autenticarse en los recursos de Azure.
Microsoft recomienda que los clientes usen Microsoft Entra ID o una firma de acceso compartido (SAS) para autorizar el acceso a los datos de Azure Storage. 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 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.
Si intenta acceder a datos de blobs, Azure Portal primero comprueba si tiene 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 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 blob 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 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 conceda acceso a los recursos de administración de la cuenta de almacenamiento también es aceptable. Para obtener más información sobre cómo asignar permisos a los usuarios para el acceso a los datos de Azure Portal con una cuenta de Microsoft Entra, consulte Asignar 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 obtener más información sobre acceso a los datos en el portal, consulte Elección de la forma de autorizar el acceso a los 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. Para obtener más información, vea uno de los siguientes artículos:
- Distintas formas de autorizar el acceso a datos en blobs con la CLI de Azure
- Ejecución de comandos de PowerShell con credenciales de Microsoft Entra para acceder a los datos de blob
Compatibilidad de características
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). Si ha habilitado cualquiera de estas funcionalidades, consulte Compatibilidad con características de Blob Storage en cuentas de Azure Storage para evaluar la compatibilidad con esta característica.
La autorización de operaciones de datos de blob con Microsoft Entra ID solo se admite para las versiones de la API REST 2017-11-09 y versiones posteriores. Para obtener más información, vea Versiones de los servicios de Azure Storage.