Consideraciones de redes para Azure Files

Puede acceder a los recursos compartidos de archivos de Azure mediante el punto de conexión público accesible desde Internet, mediante uno o varios puntos de conexión privados en las redes o almacenando en caché el recurso compartido de archivos de Azure en el entorno local con Azure File Sync (solo recursos compartidos de archivos SMB). Este artículo se centra en cómo configurar Azure Files para el acceso directo mediante 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 en el entorno local con Azure File Sync, consulte ¿Qué es 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 mediante el puerto 445, que muchas organizaciones y proveedores de servicios de Internet (ISP) bloquean para el tráfico saliente (Internet). Esta práctica procede de las instrucciones de seguridad heredadas sobre las versiones en desuso y no seguras para Internet del protocolo SMB. Aunque SMB 3.x es un protocolo seguro para Internet, es posible que no se puedan cambiar las directivas de la organización o del ISP. Por lo tanto, el montaje de un recurso compartido de archivos SMB a menudo requiere una configuración de redes adicional para su uso 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 de 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 de 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 de 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 recurso compartido de archivos	SMB	NFS
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Transferencia segura

De manera predeterminada, las cuentas de almacenamiento de Azure requieren transferencia segura, independientemente de si se accede a los datos mediante el punto de conexión público o privado. Para Azure Files, se aplica la configuración requerir transferencia segura 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 configuración requerir transferencia segura para permitir el tráfico sin cifrar. En el portal Azure, es posible que también vea esta configuración etiquetada como requerir transferencia segura para las operaciones de la API REST.

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

• Cuando se habilita la configuración requerir transferencia segura 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 los algoritmos de cifrado AES-128-CCM, AES-128-GCM o AES-256-GCM, según la negociación de cifrado disponible y requerido entre el cliente SMB y Azure Files. Puede alternar qué algoritmos de cifrado SMB se permiten mediante la configuración de seguridad de SMB. Al deshabilitar la configuración requerir transferencia segura, se permiten los montajes SMB 2.1 y SMB 3.x sin cifrado.

• Los recursos compartidos de archivos NFS no admiten un mecanismo de cifrado, por lo que para poder usar el protocolo NFS para acceder a un recurso compartido de archivos de Azure, debe deshabilitar la configuración requerir transferencia segura para la cuenta de almacenamiento.

• Cuando se requiere transferencia segura, el protocolo FileREST solo se puede usar con HTTPS. Actualmente, FileREST solo se admite en recursos compartidos de archivos SMB.

Nota:

La comunicación entre un cliente y una cuenta de almacenamiento Azure se cifra utilizando la seguridad de la capa de transporte (TLS). Azure Files se basa en una implementación de Windows de SSL que no está basada en OpenSSL y, por tanto, no está expuesta a vulnerabilidades relacionadas con OpenSSL.

Punto de conexión público

El punto de conexión público de los recursos compartidos de archivos de Azure 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 uno 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 dentro o fuera de la región de Azure. Si se desea usar SMB 2.1 o SMB 3.x sin cifrado, se deben cumplir dos condiciones:

  1. La configuración requerir transferencia segura de la cuenta de almacenamiento debe estar deshabilitada.
  2. La solicitud se debe originar desde dentro de la región de Azure. Como se mencionó anteriormente, se permiten las solicitudes SMB cifradas 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 del punto de conexión público para obtener información adicional sobre los puntos de conexión de servicio.

• FileREST es accesible mediante el 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 de 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 por completo el punto de conexión público.

Al restringir el tráfico del punto de conexión público a una o varias redes virtuales, se usa una funcionalidad de la red virtual llamada puntos de conexión de servicio. Las solicitudes dirigidas al punto de conexión de servicio de Azure Files aún van a la dirección IP pública de la cuenta de almacenamiento; sin embargo, la capa de redes realiza una comprobación adicional de la solicitud para validar que proceda de una red virtual autorizada. Los protocolos SMB, NFS y FileREST admiten puntos de conexión de servicio. Sin embargo, a diferencia de SMB y FileREST, 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 los firewalls y las redes virtuales de Azure Storage.

Enrutamiento de red del 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 ofrece la opción de tener uno o más puntos de conexión privados. Un punto de conexión privado es un punto de conexión que solo es accesible dentro de una red virtual de Azure. Cuando se crea un punto de conexión privado para la cuenta de almacenamiento, esta obtiene una dirección IP privada del espacio de direcciones de la red virtual, de forma muy parecida a cómo un servidor de archivos local o un dispositivo NAS reciben 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, crear 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 almacenamiento de Azure 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 los servidores y las estaciones de trabajo locales y los recursos compartidos de archivos de SMB y NFS de Azure:

• 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 de conexión distintos:
  • Las conexiones de puerta de enlace de VPN de punto a sitio, 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 el de los teletrabajadores que quieren poder montar su recurso compartido de archivos de Azure desde su casa, una cafetería o un hotel cuando están de viaje. Para usar una conexión VPN de punto a sitio con Azure Files, debe configurar una conexión VPN de punto a sitio para cada cliente que quiera conectarse. Consulte Configurar una VPN punto a sitio (P2S) en Windows para su uso con Azure Files y Configurar una VPN punto a sitio (P2S) en Linux para su uso con Azure Files.
  • Las VPN de sitio a sitio, que son conexiones VPN entre Azure y la red de su organización. Una conexión VPN de sitio a sitio le permite configurar una conexión VPN una vez para un servidor o dispositivo VPN hospedado en la red de su organización, en lugar de configurar una conexión para cada dispositivo cliente que necesite acceder al recurso compartido de archivos de Azure. 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. Como ExpressRoute proporciona una ruta de acceso dedicada entre el centro de recursos local y Azure, ExpressRoute puede resultar ú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 extender la red local a Azure, técnicamente es posible enrutar al punto de conexión público mediante la conexión VPN. Sin embargo, esto requiere codificar de forma rígida la dirección IP del punto de conexión público del clúster de almacenamiento de Azure que atiende la cuenta de almacenamiento. Dado que las cuentas de almacenamiento se pueden mover entre clústeres de almacenamiento en cualquier momento y se agregan clústeres nuevos y se quitan con frecuencia, esto requiere codificar de forma rígida y con regularidad todas las posibles direcciones IP de almacenamiento de Azure en las reglas de enrutamiento.

Configuración de DNS

Cuando se crea un punto de conexión privado, de forma predeterminada también se crea una zona DNS privada (o se actualiza una existente) correspondiente al subdominio privatelink. En sentido estricto, 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 Azure Sovereign, como la nube Azure US Government y la nube Microsoft Azure operado por 21Vianet; basta con sustituir los sufijos adecuados para su entorno.

En la zona DNS privada, se va a crea un registro D 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 cuando mediante una llamada al cmdlet Resolve-DnsName 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 el entorno local, verá que el mismo nombre de cuenta de almacenamiento se resuelve en la dirección IP pública de la cuenta de almacenamiento en su lugar. 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 el punto de conexión público y 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. Este método no se recomienda en entornos de producción, ya que estos cambios se deberán realizar en todos los clientes que quieran montar los recursos compartidos de archivos de Azure y los cambios en la cuenta de almacenamiento o en el punto de conexión privado no se administrarán automáticamente.
• Cree un registro D para storageaccount.file.core.windows.net en los servidores DNS locales. Este método tiene la ventaja de que los clientes de su entorno local podrán resolver automáticamente la cuenta de almacenamiento sin necesidad de configurar cada cliente. Sin embargo, esta solución es igual de frágil que modificar el archivo hosts, ya que no se reflejan los cambios. Aunque esta solución es frágil, puede ser la mejor opción para algunos entornos.
• Reenvíe la zona core.windows.net de 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 reenviarán core.windows.net a la zona DNS privada de Azure. Para simplificar esta configuración, se han proporcionado cmdlets de PowerShell que implementarán automáticamente los 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 a través de QUIC

Windows Server 2022 Azure Edition admite un nuevo protocolo de transporte llamado QUIC para el servidor SMB proporcionado por el rol Servidor de archivos. QUIC es una sustitución de TCP que se basa en UDP, lo que proporciona numerosas ventajas sobre TCP, a la vez que proporciona un mecanismo de transporte confiable. Una de las principales ventajas para el protocolo SMB es que, en lugar de usar el puerto 445, todo el transporte se lleva a cabo mediante el puerto 443, que está generalmente abierto para admitir HTTPS. Esto significa de forma efectiva que SMB mediante QUIC ofrece una "VPN de SMB" para el uso compartido de archivos mediante la red pública de Internet. Windows 11 se suministra con un cliente compatible con SMB mediante QUIC.

En este momento, Azure Files no admite directamente SMB mediante QUIC. Sin embargo, puede obtener acceso a recursos compartidos de archivos de Azure a través de Azure File Sync que se ejecutan en Windows Server, como se muestra en el diagrama siguiente. Esto también le ofrece la opción de tener memorias caché de Azure File Sync tanto locales 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