Identidad y Access Control

Completado

En esta unidad aprenderá a autenticar a los usuarios y a proporcionar acceso a los recursos compartidos de archivos de Azure. Azure Files admite la autenticación basada en identidades para los clientes que acceden a recursos compartidos de archivos a través de SMB. Además, los usuarios de SMB también pueden autenticarse mediante una clave de cuenta de almacenamiento. Los recursos compartidos de archivos NFS se basan en la autenticación de nivel de red y, por tanto, solo son accesibles mediante redes restringidas. El uso de un recurso compartido de archivos NFS siempre requiere algún nivel de configuración de redes. Durante el acceso a recursos compartidos de archivos a través de API de REST, se usan firmas de acceso compartido y claves de cuenta de almacenamiento para operaciones de administración de datos específicas.

  • Autenticación basada en identidad: los clientes pueden usar el acceso basado en identidad a través del protocolo de autenticación Kerberos. Los servicios de Active Directory almacenan información de cuenta de usuario, como nombres de usuario, contraseñas, información de contacto, etc. Azure Files se integra con servicios de directorio comunes para comprobar los detalles de la cuenta de usuario y habilitar la autenticación correcta. Para SMB, la autenticación basada en identidades es la opción más segura y recomendada.

  • Clave de cuenta de almacenamiento: un usuario con la clave de cuenta de almacenamiento puede acceder a los recursos compartidos de archivos de Azure con permisos de superusuario a través de SMB y REST. Lo ideal es que solo los administradores de superusuarios usen claves de cuenta de almacenamiento, puesto que omiten todas las restricciones de acceso. En el caso de los recursos compartidos de archivos que usan los clientes empresariales, las claves de cuenta de almacenamiento no son mecanismos escalables ni seguros para el acceso a toda la organización y, por tanto, no se recomiendan. El procedimiento recomendado de seguridad es evitar el uso compartido de las claves de cuenta de almacenamiento y usar la autenticación basada en identidades.

  • Firma de acceso compartido: los clientes que acceden a través de REST pueden usar una firma de acceso compartido (SAS) para autenticarse con Azure Files. Las firmas de acceso compartido se usan en escenarios específicos en los que los proveedores de software independientes desarrollan aplicaciones de API de REST y usan Azure Files como solución de almacenamiento. También se usan cuando los asociados internos necesitan acceso a través de REST para las operaciones de administración de datos. Una firma de acceso compartido es un URI que concede derechos de acceso restringido a recursos de Azure Storage. Puede usar una firma de acceso compartido para conceder a los clientes acceso a determinados recursos de cuenta de almacenamiento sin tener que concederles acceso a la clave de la cuenta de almacenamiento.

Habilitación basada en identidad

Azure Files admite la autenticación basada en identidades para recursos compartidos de archivos SMB mediante el protocolo Kerberos. Cuando una identidad asociada con un usuario o una aplicación que se ejecuta en un cliente intenta acceder a los datos de recursos compartidos de archivos de Azure, la solicitud se envía al servicio de dominio para autenticar la identidad. Si la autenticación es correcta, devuelve un token de Kerberos. El cliente envía una solicitud que incluye el token de Kerberos, y los recursos compartidos de archivos de Azure usan ese token para autorizar la solicitud. Los recursos compartidos de archivos de Azure solo reciben el token de Kerberos, no las credenciales de acceso.

Azure Files admite los siguientes métodos de autenticación para recursos compartidos de archivos SMB:

  • Active Directory Domain Services (AD DS) locales: Al habilitar la autenticación de AD DS para un recurso compartido de archivos de Azure, los usuarios pueden autenticarse con sus credenciales de AD DS local. El AD DS local debe sincronizarse con Microsoft Entra ID mediante la sincronización de Microsoft Entra Connect. Solo se puede autenticar y autorizar a los usuarios híbridos que existen en el AD DS local y en Microsoft Entra ID para el acceso a recursos compartidos de archivos de Azure. El cliente debe configurar sus controladores de dominio y unir a un dominio sus máquinas virtuales (VMs). Los controladores de dominio se pueden hospedar de forma local o en máquinas virtuales, pero los clientes deben tener una línea de visión de los controladores de dominio, ya sea en una red local o en la misma red virtual.

  • Microsoft Entra Domain Services: En el caso de la autenticación de Microsoft Entra DS, los clientes deben habilitar Domain Services y unir a un dominio las máquinas virtuales desde las que tienen pensado obtener acceso a los datos de los archivos. Las máquinas virtuales unidas al dominio deben residir en la misma red virtual que Domain Services. No obstante, no es necesario que los clientes creen la identidad en Domain Services para representar la cuenta de almacenamiento. El proceso de habilitación crea la identidad en segundo plano. Además, todos los usuarios que existen en Microsoft Entra ID se pueden autenticar y autorizar. El usuario puede ser híbrido o estar solo en la nube. La plataforma administra la sincronización de Microsoft Entra ID con Domain Services sin necesidad de ninguna configuración de usuario.

  • Microsoft Entra Kerberos para identidades de usuario híbrido: Azure Files admite la autenticación Kerberos de Microsoft Entra (anteriormente Kerberos de Azure AD) para identidades de usuario híbrido, que son identidades de AD locales que se sincronizan con la nube. Esta configuración usa Microsoft Entra ID para emitir vales de Kerberos para acceder al recurso compartido de archivos a través de SMB. Esto significa que los usuarios finales pueden acceder a los recursos compartidos de archivos de Azure a través de Internet sin necesidad de una línea de visión a los controladores de dominio desde máquinas virtuales unidas a dominios de Microsoft Entra híbrido y Microsoft Entra. Además, con esta funcionalidad, los clientes de Azure Virtual Desktop pueden crear un recurso compartido de archivos de Azure para almacenar contenedores de perfiles de usuario a los que puedan acceder las identidades de usuario híbridas.

  • Autenticación de AD para clientes Linux: La autenticación para clientes Linux se admite a través de AD DS o Microsoft Entra Domain Services.

Casos de uso comunes para la autenticación basada en identidades

Estos son algunos escenarios comunes para usar la autenticación basada en identidades:

  • Migración desde servidores de archivos locales a Azure Files: para muchos clientes, reemplazar servidores de archivos locales es un caso de uso común de transformación de TI. El uso de AD DS local para habilitar una migración sin problemas a archivos de Azure no solo proporciona una buena experiencia de usuario, sino que también permite a los usuarios acceder al recurso compartido de archivos y a los datos con sus credenciales actuales mediante la unión a un dominio de sus máquinas.

  • Traslado de aplicaciones empresariales a la nube: a medida que los clientes trasladan sus aplicaciones nativas locales a la nube, la autenticación basada en identidades con Azure Files elimina la necesidad de cambiar los mecanismos de autenticación para admitir aplicaciones en la nube.

  • Copia de seguridad y recuperación ante desastres: Azure Files puede actuar como sistema de almacenamiento de copia de seguridad para servidores de archivos locales. Mediante la configuración de la autenticación adecuada, puede aplicar controles de acceso durante escenarios de recuperación ante desastres.