Consideraciones sobre redes de Azure Files

Puede acceder a los recursos compartidos de archivos de Azure a través del punto de conexión accesible de Internet público, a través de uno o varios puntos de conexión privados en las redes o almacenando en caché el recurso compartido de archivos de Azure local con Azure File Sync (solo recursos compartidos de archivos SMB). En este artículo se centra en cómo configurar Azure Files para el acceso directo a través de puntos de conexión públicos o privados. Para obtener información sobre cómo almacenar en caché el recurso compartido de archivos de Azure local con Azure File Sync, consulte Introducción a Azure File Sync.

Se recomienda leer Planeamiento de una implementación de Azure Files antes de leer esta guía.

El acceso directo a un recurso compartido de archivos de Azure a menudo requiere un pensamiento adicional con respecto a las redes:

• Los recursos compartidos de archivos SMB se comunican a través del puerto 445, que muchas organizaciones y proveedores de servicios de Internet bloquean para el tráfico de salida a Internet. Esta práctica se origina en instrucciones de seguridad heredadas sobre versiones obsoletas y no seguras para Internet del protocolo SMB. Aunque SMB 3.x es un protocolo seguro para Internet, es posible que las directivas organizativas o ISP no sean posibles cambiar. Por lo tanto, el montaje de un recurso compartido de archivos SMB suele requerir una configuración de red adicional para usarla fuera de Azure.

• 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.

La configuración de puntos de conexión públicos y privados para Azure Files se realiza en el objeto de administración de nivel superior para Azure Files, la cuenta de almacenamiento de Azure. Una cuenta de almacenamiento es una construcción de administración que representa un grupo compartido de almacenamiento en el que puede implementar varios recursos compartidos de archivos de Azure, así como los recursos de almacenamiento para otros servicios de almacenamiento de Azure, como contenedores de blobs o colas.

Este vídeo es una guía y demostración sobre cómo exponer de forma segura recursos compartidos de archivos de Azure directamente para las aplicaciones y trabajadores de la información en cinco sencillos pasos. En las secciones siguientes se proporcionan vínculos y contexto adicional a la documentación a la que se hace referencia en el vídeo. Tenga en cuenta que Azure Active Directory es ahora Microsoft Entra ID. Para obtener más información, consulte Nuevo nombre para Azure AD.

Se aplica a

Tipo de compartición de archivos	Pequeñas y Medianas Empresas (PYME)	NFS
Compartición de archivos estándar (GPv2), LRS/ZRS
Comparticiones de archivos estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Transferencia segura

De forma predeterminada, las cuentas de Almacenamiento de Azure requieren una transferencia segura, independientemente de si se accede a los datos a través del punto de conexión público o privado. Para Azure Files, se aplica la opción Transferencia segura necesaria para todo el acceso de protocolo a los datos almacenados en recursos compartidos de archivos de Azure, incluidos SMB, NFS y FileREST. Puede deshabilitar la opción Transferencia segura necesaria para permitir el tráfico sin cifrar.

Los protocolos SMB, NFS y FileREST tienen un comportamiento ligeramente diferente con respecto a la configuración necesaria de transferencia segura :

• Cuando se habilita la transferencia segura necesaria en una cuenta de almacenamiento, todos los recursos compartidos de archivos SMB de esa cuenta de almacenamiento requerirán el protocolo SMB 3.x con AES-128-CCM, AES-128-GCM o algoritmos de cifrado AES-256-GCM, según la negociación de cifrado disponible/necesaria entre el cliente SMB y Azure Files. Puede alternar qué algoritmos de cifrado SMB se permiten a través de la configuración de seguridad de SMB. Al deshabilitar la opción Transferencia segura necesaria , se habilitan los montajes SMB 2.1 y SMB 3.x sin cifrado.

• Los recursos compartidos de archivos de Azure NFS usan el paquete de utilidad AZNFS para simplificar los montajes cifrados mediante la instalación y configuración de Stunnel (un contenedor TLS de código abierto) en el cliente. Consulte Cifrado en tránsito para recursos compartidos de archivos de Azure NFS.

• Cuando se requiere transferencia segura, el protocolo FileREST solo se puede usar con HTTPS.

Nota:

La comunicación entre un cliente y una cuenta de almacenamiento de Azure se cifra mediante la seguridad de la capa de transporte (TLS). Azure Files se basa en una implementación de Windows de SSL que no se basa en OpenSSL y, por lo tanto, no se expone a vulnerabilidades relacionadas con OpenSSL. Los usuarios que prefieren mantener la flexibilidad entre las conexiones TLS y no TLS en la misma cuenta de almacenamiento deben deshabilitar la transferencia segura necesaria.

Punto de conexión público

El punto de conexión público para los recursos compartidos de archivos de Azure dentro de una cuenta de almacenamiento es un punto de conexión expuesto a Internet. El punto de conexión público es el punto de conexión predeterminado para una cuenta de almacenamiento; sin embargo, se puede deshabilitar si lo desea.

Los protocolos SMB, NFS y FileREST pueden usar el punto de conexión público. Sin embargo, cada una tiene reglas ligeramente diferentes para el acceso:

• Los recursos compartidos de archivos SMB son accesibles desde cualquier lugar del mundo mediante el punto de conexión público de la cuenta de almacenamiento con SMB 3.x con cifrado. Esto significa que las solicitudes autenticadas, como las solicitudes autorizadas por la identidad de inicio de sesión de un usuario, se pueden originar de forma segura desde dentro o fuera de la región de Azure. Si se desea SMB 2.1 o SMB 3.x sin cifrado, se deben cumplir dos condiciones:

  1. La configuración de transferencia segura necesaria de la cuenta de almacenamiento debe estar deshabilitada.
  2. La solicitud debe originarse desde dentro de la región de Azure. Como se mencionó anteriormente, las solicitudes SMB cifradas se permiten desde cualquier lugar, dentro o fuera de la región de Azure.

• Los recursos compartidos de archivos NFS son accesibles desde el punto de conexión público de la cuenta de almacenamiento si y solo si el punto de conexión público de la cuenta de almacenamiento está restringido a redes virtuales específicas mediante puntos de conexión de servicio. Consulte configuración de firewall de punto de conexión público para obtener información adicional sobre los puntos de conexión de servicio.

• FileREST es accesible a través del punto de conexión público. Si se requiere transferencia segura, solo se aceptan solicitudes HTTPS. Si la transferencia segura está deshabilitada, el punto de conexión público acepta las solicitudes HTTP independientemente del origen.

Configuración del firewall del punto de conexión público

El firewall de la cuenta de almacenamiento restringe el acceso al punto de conexión público de una cuenta de almacenamiento. Con el firewall de la cuenta de almacenamiento, puede restringir el acceso a determinadas direcciones IP o intervalos de direcciones IP, a redes virtuales específicas o deshabilitar el punto de conexión público por completo.

Al restringir el tráfico del punto de conexión público a una o varias redes virtuales, usa una funcionalidad de la red virtual denominada puntos de conexión de servicio. Las solicitudes dirigidas al punto de conexión de servicio de Azure Files todavía van a la dirección IP pública de la cuenta de almacenamiento; sin embargo, la capa de red está realizando una comprobación adicional de la solicitud para validar que procede de una red virtual autorizada. Los protocolos SMB, NFS y FileREST admiten todos los puntos de conexión de servicio. A diferencia de SMB y FileREST, sin embargo, solo se puede acceder a los recursos compartidos de archivos NFS con el punto de conexión público mediante el uso de un punto de conexión de servicio.

Para más información sobre cómo configurar el firewall de la cuenta de almacenamiento, consulte Configuración de firewalls y redes virtuales de Azure Storage.

Enrutamiento de red de punto de conexión público

Azure Files admite varias opciones de enrutamiento de red. La opción predeterminada, el enrutamiento de Microsoft, funciona con todas las configuraciones de Azure Files. La opción de enrutamiento de Internet no admite escenarios de unión a un dominio de AD ni Azure File Sync.

Puntos de conexión privados

Además del punto de conexión público predeterminado para una cuenta de almacenamiento, Azure Files proporciona la opción de tener uno o varios puntos de conexión privados. Un punto de conexión privado es un punto de conexión al que solo se puede acceder dentro de una red virtual de Azure. Al crear un punto de conexión privado para la cuenta de almacenamiento, la cuenta de almacenamiento obtiene una dirección IP privada desde el espacio de direcciones de la red virtual, al igual que la forma en que un servidor de archivos local o un dispositivo NAS recibe una dirección IP dentro del espacio de direcciones dedicado de la red local.

Un punto de conexión privado está asociado a una subred de red virtual de Azure específica. Una cuenta de almacenamiento puede tener puntos de conexión privados en más de una red virtual.

El uso de puntos de conexión privados con Azure Files le permite:

• Conectarse de forma segura a los recursos compartidos de archivos de Azure desde redes locales mediante una conexión VPN o ExpressRoute con emparejamiento privado.
• Proteger los recursos compartidos de archivos mediante la configuración del firewall de la cuenta de almacenamiento para bloquear todas las conexiones el punto de conexión público. De forma predeterminada, la creación de un punto de conexión privado no bloquea las conexiones al punto de conexión público.
• Aumentar la seguridad de la red virtual, al permitirle bloquear la filtración de datos desde la red virtual (y los límites de emparejamiento).

Para crear un punto de conexión privado, consulte Configuración de puntos de conexión privados para Azure Files.

Tunelización del tráfico a través de una red privada virtual o de ExpressRoute

Para usar puntos de conexión privados para acceder a recursos compartidos de archivos SMB o NFS desde el entorno local, debe establecer un túnel de red entre la red local y Azure. Una red virtual, o VNet, es similar a una red local tradicional. Al igual que una cuenta de Azure Storage o una máquina virtual de Azure, una red virtual es un recurso de Azure que se implementa en un grupo de recursos.

Azure Files admite los siguientes mecanismos para tunelizar el tráfico entre las estaciones de trabajo locales y los servidores y los recursos compartidos de archivos SMB/NFS de Azure:

• Azure VPN Gateway: una puerta de enlace de VPN es un tipo específico de puerta de enlace de red virtual que se usa para enviar tráfico cifrado entre una red virtual de Azure y una ubicación alternativa (por ejemplo, en un entorno local) a través de Internet. Una instancia de Azure VPN Gateway es un recurso de Azure que se puede implementar en un grupo de recursos junto con una cuenta de almacenamiento u otros recursos de Azure. Las puertas de enlace de VPN exponen dos tipos diferentes de conexiones:
  • Conexiones de VPN Gateway de punto a sitio (P2S), que son conexiones VPN entre Azure y un cliente individual. Esta solución es principalmente útil para los dispositivos que no forman parte de la red local de la organización. Un caso de uso común es para los teletrabajadores que desean poder montar su recurso compartido de archivos de Azure desde casa, una cafetería o un hotel mientras están de viaje. Para usar una conexión VPN P2S con Azure Files, deberá configurar una conexión VPN P2S para cada cliente que quiera conectarse. Consulte Configuración de una VPN de punto a sitio (P2S) en Windows para su uso con Azure Files y Configuración de una VPN de punto a sitio (P2S) en Linux para su uso con Azure Files.
  • VPN de sitio a sitio (S2S), que son conexiones VPN entre Azure y la red de la organización. Una conexión VPN S2S permite configurar una conexión VPN una vez para un servidor VPN o dispositivo hospedado en la red de la organización, en lugar de configurar una conexión para cada dispositivo cliente que necesite acceder al recurso compartido de archivos de Azure. Consulte Configuración de una VPN de sitio a sitio (S2S) para su uso con Azure Files.
• ExpressRoute, que permite crear una ruta definida entre Azure y la red local que no atraviesa Internet. Dado que ExpressRoute proporciona una ruta de acceso dedicada entre el centro de datos local y Azure, ExpressRoute puede ser útil cuando se tiene en cuenta el rendimiento de la red. ExpressRoute también es una buena opción cuando la directiva o los requisitos normativos de la organización requieren una ruta de acceso determinista a los recursos en la nube.

Nota:

Aunque se recomienda usar puntos de conexión privados para ayudar a ampliar la red local a Azure, técnicamente es posible enrutar al punto de conexión público a través de la conexión VPN. Sin embargo, esto requiere codificar de forma rígida la dirección IP del punto de conexión público para el clúster de Almacenamiento de Azure que atiende la cuenta de almacenamiento. Dado que las cuentas de almacenamiento pueden moverse entre clústeres de almacenamiento en cualquier momento y los clústeres nuevos se agregan y quitan con frecuencia, esto requiere codificar periódicamente de forma rígida todas las posibles direcciones IP de Almacenamiento de Azure en las reglas de enrutamiento.

Configuración de DNS

Al crear un punto de conexión privado, de forma predeterminada también creamos una zona DNS privada (o actualiza una existente) correspondiente al privatelink subdominio. En términos estrictos, no es necesario crear una zona DNS privada para usar un punto de conexión privado para la cuenta de almacenamiento. Sin embargo, se recomienda en general y se requiere de forma explícita al montar el recurso compartido de archivos de Azure con una entidad de seguridad de usuario de Active Directory o al acceder a él desde la API de FileREST.

Nota:

En este artículo se usa el sufijo DNS de la cuenta de almacenamiento para las regiones públicas de Azure core.windows.net. Este comentario también se aplica a las nubes soberanas de Azure, como la nube de Azure Gobierno de EE.UU. y Microsoft Azure, operada por la nube de 21Vianet; simplemente sustituya los sufijos adecuados para su entorno.

En la zona DNS privada, creamos un registro A para storageaccount.privatelink.file.core.windows.net y un registro CNAME para el nombre normal de la cuenta de almacenamiento, que sigue el patrón storageaccount.file.core.windows.net. Dado que la zona DNS privada de Azure está conectada a la red virtual que contiene el punto de conexión privado, puede observar la configuración de DNS llamando al Resolve-DnsName cmdlet desde PowerShell en una máquina virtual de Azure (como alternativa nslookup en Windows y Linux):

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

En este ejemplo, la cuenta de almacenamiento storageaccount.file.core.windows.net se resuelve en la dirección IP privada del punto de conexión privado, que resulta ser 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

Si ejecuta el mismo comando desde las instalaciones locales, verá que el mismo nombre de cuenta de almacenamiento se traduce en cambio en la dirección IP pública de la cuenta de almacenamiento. Por ejemplo, storageaccount.file.core.windows.net es un registro CNAME para storageaccount.privatelink.file.core.windows.net, que a su vez es un registro CNAME para el clúster de almacenamiento de Azure que hospeda la cuenta de almacenamiento:

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

Esto refleja el hecho de que la cuenta de almacenamiento puede exponer tanto el punto de conexión público como uno o varios puntos de conexión privados. Para asegurarse de que el nombre de la cuenta de almacenamiento se resuelve en la dirección IP privada del punto de conexión privado, debe cambiar la configuración en los servidores DNS locales. Esto puede realizarse de varias maneras:

• Modifique el archivo hosts de los clientes para que storageaccount.file.core.windows.net se resuelva en la dirección IP privada del punto de conexión privado deseado. Esto no se recomienda en entornos de producción, ya que tendrá que realizar estos cambios en cada cliente que quiera montar los recursos compartidos de archivos de Azure y los cambios en la cuenta de almacenamiento o el punto de conexión privado no se controlarán automáticamente.
• Crear un registro A para storageaccount.file.core.windows.net en los servidores DNS locales. Esto tiene la ventaja de que los clientes del entorno local podrán resolver automáticamente la cuenta de almacenamiento sin necesidad de configurar cada cliente. Sin embargo, esta solución es igualmente frágil a la modificación del archivo hosts porque los cambios no se reflejan. Aunque esta solución es frágil, puede ser la mejor opción para algunos entornos.
• Reenvíe la core.windows.net zona desde los servidores DNS locales a la zona DNS privada de Azure. Se puede acceder al host DNS privado de Azure a través de una dirección IP especial (168.63.129.16) que solo es accesible dentro de las redes virtuales que están vinculadas a la zona DNS privada de Azure. Para solucionar esta limitación, puede ejecutar servidores DNS adicionales dentro de la red virtual que se reenviarán core.windows.net a la zona DNS privada de Azure. Para simplificar esta configuración, hemos proporcionado cmdlets de PowerShell que implementarán automáticamente servidores DNS en la red virtual de Azure y los configurarán según sea necesario. Para aprender a configurar el reenvío de DNS, consulte Configuración de DNS con Azure Files.

SMB sobre QUIC

Windows Server 2022 Azure Edition admite un nuevo protocolo de transporte denominado QUIC para el servidor SMB proporcionado por el rol servidor de archivos. QUIC es un reemplazo de TCP que se basa en UDP, lo que proporciona numerosas ventajas sobre TCP mientras sigue proporcionando un mecanismo de transporte confiable. Una ventaja clave para el protocolo SMB es que, en lugar de usar el puerto 445, todo el transporte se realiza a través del puerto 443, que es ampliamente abierto para admitir HTTPS. Esto significa eficazmente que SMB a través de QUIC ofrece una "VPN SMB" para el uso compartido de archivos a través de la red pública de Internet. Windows 11 se incluye con un cliente compatible con SMB a través de QUIC.

En este momento, Azure Files no admite directamente SMB a través de QUIC. Sin embargo, puede obtener acceso a recursos compartidos de archivos de Azure a través de Azure File Sync que se ejecuta en Windows Server, como se muestra en el diagrama siguiente. Esto también le ofrece la opción de tener cachés de Azure File Sync tanto en el entorno local como en diferentes centros de datos de Azure para proporcionar cachés locales para un personal distribuido. Para más información sobre esta opción, consulte Implementación de Azure File Sync y SMB a través de QUIC.

Consulte también

• Introducción a Azure Files
• Planeamiento de una implementación de Azure Files