Consideraciones de red de Azure Files

✔️ Aplica a: Todos los compartidos de archivos de Azure

Los recursos compartidos de archivos de Azure tienen endpoints públicos y pueden tener uno o más endpoints privados. Las rutas de red disponibles para los clientes dependen del protocolo y de las reglas de red. Este artículo cubre tanto los recursos compartidos de archivos clásicos (Microsoft.Storage) como los recursos compartidos de archivos creados con Microsoft.FileShares. Azure File Sync ofrece una opción de caché para los recursos compartidos de archivos SMB clásicos. Para obtener más información, consulte Introducción a Azure File Sync.

Para consideraciones más amplias sobre el despliegue, véase Planificar un despliegue de Azure Files. Para los pasos de configuración, consulta Configurar puntos finales de red para los recursos compartidos de archivos de Azure.

Dos diferencias en los protocolos afectan al diseño de la red:

• SMB utiliza el puerto TCP 445, que algunas organizaciones y proveedores de servicios de internet bloquean para el tráfico saliente. La conectividad privada a través de VPN o ExpressRoute ofrece una ruta alternativa.

• NFS utiliza autenticación basada en red. Los clientes se conectan a través de puntos finales privados o puntos de conexión de servicio desde subredes de red virtual permitidas.

Los archivos compartidos clásicos soportan SMB y NFS. Microsoft.FileShares actualmente admite NFS. Ambos proveedores de recursos soportan endpoints públicos y privados. Para diferencias en la propiedad y gestión de recursos, véase Conceptos de administración de Azure Files.

Cifrado en tránsito

El cifrado en tránsito protege la confidencialidad e integridad de los datos entre clientes y Azure Files, incluyendo la protección contra interceptaciones o modificaciones por parte de un atacante man-in-the-middle. Esta protección se aplica tanto a los puntos finales públicos como privados. El cifrado y las reglas de acceso a la red tienen propósitos separados: el cifrado protege la conexión, mientras que las reglas de red determinan qué clientes pueden acceder al servicio.

Cifrado en tránsito para SMB

SMB 3.x protege los datos mediante cifrado del canal SMB. Azure Files es compatible con AES-128-CCM con SMB 3.0, y AES-128-GCM y AES-256-GCM con SMB 3.1.1. El algoritmo de cifrado depende de las capacidades del cliente y de los algoritmos permitidos por el servicio. SMB 2.1 no soporta cifrado de canales.

Restringir los algoritmos permitidos puede afectar la compatibilidad del cliente. Por ejemplo, los clientes de Windows antiguos no soportan AES-256-GCM. El cifrado de canales protege los datos de archivos en la conexión; El cifrado de tickets Kerberos protege los tickets de autenticación. Estos son controles separados. Para soporte para clientes y configuración, consulte la configuración de seguridad de SMB.

Cifrado en tránsito para NFS

Los recursos compartidos de archivos NFS con cualquiera de los proveedores de recursos admiten el cifrado mediante túneles TLS. El helper de montaje AZNFS utiliza stunnel para transportar tráfico NFS a través de una conexión cifrada entre el cliente y Azure Files. AZNFS es compatible con TLS 1.2 y TLS 1.3 y valida el certificado del servidor. Las aplicaciones continúan utilizando el protocolo NFS sin implementar TLS por sí mismas.

TLS protege los datos en tránsito, pero no añade autenticación basada en el usuario a NFS. Las reglas de acceso a la red y los permisos de archivo siguen gobernando el acceso. Para obtener instrucciones sobre el montaje cifrado, consulta Cifrar datos en tránsito para recursos compartidos NFS.

Cifrado en tránsito para FileREST

FileREST protege los datos en tránsito a través de HTTPS. Azure Files es compatible con TLS 1.2 y TLS 1.3 para conexiones HTTPS. Exigir HTTPS rechaza las solicitudes HTTP no cifradas; un requisito mínimo de versión TLS controla qué versiones TLS pueden usar los clientes.

El acceso a datos FileREST está disponible para recursos compartidos de archivos clásicos. Microsoft.FileShares actualmente no admite el acceso a datos mediante FileREST.

Guías de configuración de cifrado

Los requisitos y valores predeterminados de cifrado dependen del proveedor de recursos y del protocolo. Las siguientes guías describen cómo verlas y cambiarlas:

• Microsoft.FileShares: Requisitos de cifrado al crear un recurso compartido de archivos y actualizar las propiedades del recurso compartido de archivos con PowerShell o CLI de Azure.
• Compartidos de archivos clásicos: cifrado SMB, cifrado NFS y requisitos HTTPS para FileREST.

Punto de conexión público

Un endpoint público tiene una dirección IP pública. Una dirección pública no implica acceso sin restricciones: los requisitos del protocolo, las reglas de red y la autorización determinan si una solicitud está permitida.

Los protocolos tienen reglas diferentes para el acceso a endpoints públicos. SMB y FileREST se aplican a los recursos compartidos de archivos clásicos. El NFS se aplica a ambos proveedores de recursos:

• SMB: Las conexiones SMB 3.x cifradas pueden originarse dentro o fuera de Azure, sujetas a las reglas de red y autorizaciones. Las conexiones SMB sin cifrar están limitadas a clientes en la misma región de Azure y requieren una configuración que permita el acceso sin cifrar.

• NFS: Los clientes solo pueden acceder al endpoint público a través de un endpoint de servicio desde una subred permitida. NFS no admite acceso directo desde clientes de internet.

• FileREST: Los clientes acceden a los datos de archivos mediante solicitudes REST. HTTPS protege estas solicitudes en tránsito. Las reglas de red y la autorización se aplican independientemente de si se requiere HTTPS.

Acceso de red entrante

Las reglas de red controlan el acceso entrante al endpoint público. Ambos proveedores de recursos admiten el acceso desde subredes virtuales seleccionadas. El acceso clásico SMB y FileREST también puede usar reglas de dirección IP. El acceso NFS requiere endpoints de servicio y subredes permitidas.

Un endpoint de servicio transporta tráfico desde una subred de red virtual a Azure Files a través de la backbone de Azure. El tráfico sigue usando la dirección IP del endpoint público. La capa de red identifica la subred de origen para que el servicio pueda comprobarla con las redes permitidas.

Desactivar el acceso a la red pública también impide el acceso del cliente a través de los endpoints de servicio. El acceso a puntos finales privados es independiente de esta configuración. Para los recursos compartidos de archivos clásicos, las excepciones de servicio confiable existentes pueden permanecer en vigor.

Para los pasos de configuración de ambos proveedores de recursos, véase Restringir el acceso a endpoints públicos.

Restringir el acceso saliente con directivas de punto de conexión de servicio

Las reglas de red para un archivo compartido controlan el acceso entrante. No restringen los destinos de salida de los clientes. Por ejemplo, un cliente que puede leer un recurso compartido podría copiar datos a otro recurso en el que tenga permiso para escribir.

Para los recursos compartidos de archivos clásicos, opcionalmente puedes usar una política de endpoint de servicio para limitar a qué cuentas de almacenamiento los clientes de una subred pueden acceder a través de endpoints de servicio. La política se aplica a todos los clientes de esa subred. Las normas de red y los requisitos de autorización del destino siguen aplicándose.

Las políticas de endpoint de servicio funcionan junto con otros controles de red:

• Las rutas de los endpoints de servicio sobrescriben rutas definidas por el usuario (UDRs) para los prefijos de dirección de servicio correspondientes. El tráfico que pasa por un endpoint de servicio no pasa por Azure Firewall ni por un dispositivo virtual de red (NVA), por lo que estos dispositivos no pueden inspeccionarlo ni registrarlo. Para obtener más información, consulte puntos de conexión de servicio de red virtual.
• Las reglas de los grupos de seguridad de red (NSG) pueden usar etiquetas de servicio, como Storage.WestUS, para restringir el tráfico saliente a una región. Las etiquetas de servicio no pueden restringir el tráfico a una cuenta de almacenamiento específica.

La lista de permisos de la política puede contener cuentas individuales de almacenamiento, grupos de recursos o suscripciones. La política bloquea que los clientes en la subred asociada accedan a otras cuentas de almacenamiento a través de los endpoints de servicio. No restringe otras rutas salientes desde la subred.

Las políticas de endpoint de servicio no se aplican al tráfico de endpoint privado.

Para configurar una política de endpoint de servicio, consulte Restringir el acceso saliente a cuentas de almacenamiento específicas.

Acceso a Azure Portal

Abrir un recurso en el portal de Azure y acceder a sus datos de archivos son operaciones separadas. Para los recursos compartidos de archivos clásicos, explorar los datos envía solicitudes FileREST desde el navegador al endpoint del servicio de archivos. Esas solicitudes están sujetas a las normas de red de la cuenta de almacenamiento. El mero acceso al portal no concede acceso de red a los datos de los archivos.

Microsoft.FileShares actualmente no admite el acceso a datos mediante FileREST. Para los requisitos clásicos de navegación de archivos compartidos y resolución de problemas, consulte Autorizar acceso a datos de archivos en el portal de Azure.

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

La preferencia de enrutamiento solo está disponible para recursos compartidos de archivos HDD clásicos que utilizan el modelo de facturación de pago por uso en cuentas de almacenamiento StorageV2. No es compatible con recursos compartidos de archivos aprovisionados en FileStoragecuentas de almacenamiento ni con Microsoft.FileShares.

Para estas cuentas de pago por uso, la preferencia de enrutamiento determina cómo llega el tráfico de internet al punto final público:

• Enrutamiento de Microsoft (por defecto): El tráfico entre el cliente y la cuenta de almacenamiento viaja por la red troncal global de Microsoft durante el mayor tiempo posible antes de salir a internet. Esta opción soporta escenarios de unión de dominio Active Directory (AD) y Azure File Sync.
• Enrutamiento de Internet: El tráfico se enruta por internet público lo antes posible. Esta opción no admite escenarios de unión de dominios de Active Directory (AD) ni Azure File Sync.

Para los pasos de configuración, consulte Configurar preferencia de enrutamiento de red.

Puntos de conexión privados

Un punto final privado proporciona una dirección IP privada en tu red virtual para acceder a un recurso compartido de archivos.

Cada punto final privado está asociado a una subred de red virtual. Múltiples puntos de conexión privados pueden proporcionar acceso al mismo recurso compartido de archivos desde diferentes redes virtuales.

Los clientes pueden acceder a un punto final privado desde su red virtual, redes virtuales emparejadas o redes locales conectadas.

Los endpoints privados y públicos pueden coexistir. Crear un punto final privado no desactiva el acceso público ni restringe otras rutas salientes de los clientes.

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

Conectividad privada desde entornos locales

VPN y ExpressRoute proporcionan conectividad entre clientes locales y puntos finales privados en una red virtual de Azure. Este enfoque se aplica tanto a SMB como a NFS.

Las opciones de conexión varían en alcance y transporte:

VPN de punto a sitio

Una VPN punto a sitio conecta a un cliente individual a una red virtual de Azure. Admite usuarios y dispositivos remotos que no estén conectados a través de la red del sitio de una organización. Para protocolos compatibles y guías de configuración, consulta Acerca de la VPN punto a sitio.

VPN de sitio a sitio

Una VPN sitio a sitio conecta la red de una organización a una red virtual de Azure a través de una pasarela VPN. Los clientes en la red conectada comparten esa conexión. Para guías de arquitectura y configuración, véase VPN Site-to-site.

ExpressRoute

El peering privado ExpressRoute conecta una red local a redes virtuales de Azure sin atravesar la red pública. Proporciona una opción de conectividad privada para cargas de trabajo con requisitos de rendimiento de red u organizativos. El cifrado a nivel de aplicación sigue siendo una consideración aparte. Para opciones de conectividad y guías de configuración, consulte la visión general de ExpressRoute.

Resolución DNS

El DNS determina si el nombre de host de un archivo compartido se resuelve a una dirección IP pública o privada. Los clientes usan el mismo nombre de host para cualquiera de las rutas. Dentro de una red que utiliza DNS privado para el recurso compartido, el nombre se resuelve a la dirección IP del endpoint privado. Los clientes que usan DNS público lo resuelven en el endpoint público en su lugar.

Los recursos compartidos de archivos clásicos utilizan el nombre de host del servicio de archivos de la cuenta de almacenamiento. Microsoft.FileShares asigna un nombre de host generado a cada recurso compartido de archivos. Ese nombre generado es independiente del nombre de recurso del recurso compartido de archivos.

En Azure public cloud, ambos proveedores de recursos utilizan la zona privatelink.file.core.windows.netDNS privada. Los clientes locales necesitan acceso a los registros DNS privados así como una ruta de red al punto final privado. Una conexión VPN o ExpressRoute por sí sola no proporciona resolución DNS privada. El reenvío DNS o Azure DNS Private Resolver pueden proporcionar esa resolución.

Para configuración y verificación, véase:

• Crea un punto final privado con integración DNS y verifica la conectividad para ambos proveedores de recursos.
• Integración DNS de Azure con endpoint privado, para diseños DNS on-premises.
• Configura el reenvío DNS para compartición de archivos clásica, para ejemplos específicos de Azure Files.

SMB sobre QUIC

SMB sobre QUIC transporta tráfico SMB por el puerto UDP 443, proporcionando una alternativa cuando el puerto TCP 445 no está disponible. Un servidor de archivos compatible con Windows Server proporciona el punto final QUIC, y los clientes necesitan soporte SMB sobre QUIC.

Actualmente, Azure Files no soporta SMB directamente sobre QUIC. Puedes acceder a una caché de Windows Server de un recurso compartido de archivos SMB clásico a través de Azure File Sync, como se muestra en el siguiente diagrama. Esta opción no se aplica ni a NFS ni a Microsoft.FileShares. Puedes desplegar cachés de Azure File Sync en las instalaciones o en centros de datos de Azure. Para obtener más información, consulta la documentación de Windows Server. Para detalles específicos de red de Azure File Sync, consulta SMB sobre QUIC.

Consulte también

• Información general sobre Azure Files
• Plan para una implementación de Azure Files