Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
✔️ Aplica a: Todos los compartidos de archivos de Azure
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 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 Azure local con Azure File Sync, consulte Introducción a Azure File Sync.
Lee Planificación para un despliegue 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.
Configuras endpoints públicos y privados para Azure Files en el objeto de gestión de primer nivel 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 de otros servicios de almacenamiento de Azure, como contenedores de blobs o colas.
Este video es una guía y una demostración sobre cómo exponer de forma segura las comparticiones de archivos de Azure directamente a los trabajadores de la información y las aplicaciones 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. Azure Active Directory es ahora Microsoft Entra ID. Para obtener más información, vea Nuevo nombre para Azure AD.
Transferencia segura
De forma predeterminada, Azure cuentas de almacenamiento requieren 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, el cifrado en tránsito se controla en el nivel de protocolo:
| Protocol | Nombre de la configuración | Predeterminado (portal de Azure) | Por defecto (PowerShell / CLI / API) |
|---|---|---|---|
| SMB | Exigir cifrado durante el tránsito para SMB | Habilitado | No seleccionada |
| NFS | Exigir cifrado en tránsito para NFS | Habilitado | No seleccionada |
| FileREST | Se requiere transferencia segura | Habilitado | Habilitado |
Cifrado en tránsito para SMB
La configuración Requirir cifrado en tránsito para SMB controla si el cifrado es necesario para el acceso a SMB. En el caso de las nuevas cuentas de almacenamiento creadas mediante el portal de Azure, esta configuración está habilitada de forma predeterminada. Las cuentas de almacenamiento creadas mediante Azure PowerShell, CLI de Azure o la API FileREST establecen este valor como Not seleccionado para garantizar la compatibilidad con versiones anteriores. En el caso de las cuentas de almacenamiento existentes, la opción Transferencia segura necesaria continúa controlando el comportamiento de cifrado de SMB hasta que configure explícitamente la configuración de SMB por protocolo. Cuando se requiere el cifrado SMB en tránsito, todos los recursos compartidos de archivos SMB de esa cuenta de almacenamiento requieren el protocolo SMB 3.x con los algoritmos de cifrado AES-128-CCM, AES-128-GCM o AES-256-GCM. Puede controlar qué algoritmos se permiten a través de la configuración de seguridad de SMB. Al deshabilitar esta configuración, se habilitan los montajes SMB 2.1 y SMB 3.x sin cifrado.
Cifrado en tránsito para NFS
La configuración Requerir Cifrado en Tránsito para NFS controla si se requiere cifrado para el acceso NFS. Los recursos compartidos de archivos NFS de Azure utilizan el paquete de utilidades AZNFS para simplificar los montajes cifrados mediante la instalación y configuración de Stunnel (un contenedor de TLS de código abierto) en el cliente. Consulte Cifrado en tránsito para recursos compartidos de archivos de Azure NFS. En el caso de las nuevas cuentas de almacenamiento creadas mediante el portal de Azure, esta configuración está habilitada de forma predeterminada. Las cuentas de almacenamiento creadas mediante Azure PowerShell, CLI de Azure o la API FileREST establecen este valor como Not seleccionado para garantizar la compatibilidad con versiones anteriores. En el caso de las cuentas de almacenamiento existentes, la opción Transferencia segura necesaria continúa controlando el comportamiento del cifrado NFS hasta que configure explícitamente la configuración NFS por protocolo.
Cifrado en tránsito para FileREST
La opción de Transferencia segura requerida se aplica al tráfico REST/HTTPS. Cuando está habilitado, 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 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 explícitamente la opción Requerir cifrado en tránsito para SMB o Requerir cifrado en tránsito para NFS por protocolo, según corresponda.
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:
- La opción Requerir cifrado en tránsito para SMB debe estar deshabilitada (o, para las cuentas existentes en las que esta configuración no se haya configurado explícitamente, se debe deshabilitar la opción Transferencia segura necesaria ).
- 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. Puedes restringir el acceso a ciertas direcciones IP o rangos de direcciones IP, a redes virtuales específicas, o desactivar por completo el endpoint público.
Cuando restringes el endpoint público a una o más redes, estás usando una capacidad de la red virtual llamada endpoints de servicio. Las solicitudes dirigidas al endpoint de servicio de Azure Files siguen yendo a la dirección IP pública de la cuenta de almacenamiento. Sin embargo, la capa de red realiza una verificación adicional de la solicitud para validar que proviene de una red virtual autorizada. Los protocolos SMB, NFS y FileREST admiten todos los 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 a través del punto de conexión de acceso público mediante el uso de un punto de conexión de servicio.
Acceso a Azure Portal y el firewall de la cuenta de almacenamiento
Al acceder a los recursos compartidos de archivos de Azure a través de Azure Portal, se producen dos solicitudes independientes:
- Solicitud desde el explorador a la interfaz de usuario del Portal de Azure (
https://portal.azure.com). - Una solicitud desde su navegador directamente al punto de conexión del plano de datos de Azure Files (por ejemplo,
https://<storage-account-name>.file.core.windows.net), normalmente utilizando un token de SAS emitido para la experiencia del portal.
El firewall de la cuenta de almacenamiento evalúa solo la solicitud directa al punto de conexión del plano de datos de Azure Files, no la solicitud a portal.azure.com. Por lo tanto, incluso si puede acceder al Azure Portal sin problemas, es posible que reciba un error 403 (Forbidden) al acceder a los datos del recurso compartido de archivos si el firewall no permite la dirección IP de salida pública en la solicitud del navegador al almacenamiento. Esta restricción se aplica solo al tráfico FileREST/HTTPS, no a SMB ni NFS. Para más información, consulte Autorizar acceso a datos de archivos en el portal de Azure.
Nota:
Debido a factores como servidores proxy, VPN, NAT o diferencias en el enrutamiento de red, es posible que la dirección IP que se muestra en un mensaje de error no coincida con la dirección IP de origen real, como se ve en la cuenta de almacenamiento. Para comprobar la dirección IP de origen que llega realmente a la cuenta de almacenamiento, habilite la configuración de diagnóstico de Azure Monitor para la cuenta de almacenamiento y recopile registros de recursos de almacenamiento. A continuación, revise las entradas de solicitud de servicio de archivos pertinentes y compruebe el campo CallerIpAddress para confirmar qué dirección IP alcanzó la cuenta de almacenamiento.
Enrutamiento de red de punto de conexión público
Azure Files admite dos opciones de enrutamiento de red:
- 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 funciona con todas las configuraciones de Azure Files, incluyendo escenarios de unión de dominio de 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.
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 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 individual está asociado a una subred de red virtual específica Azure. 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:
- Conéctese de forma segura a los recursos compartidos de archivos de Azure desde redes locales mediante una conexión VPN o ExpressRoute con emparejamiento privado.
- Proteja los recursos compartidos de archivos de Azure configurando el firewall de la cuenta de almacenamiento para bloquear todas las conexiones en 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 es similar a una red tradicional local. 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 despliegas en un grupo de recursos.
Azure Files admite los siguientes mecanismos para tunelizar el tráfico entre las estaciones de trabajo y los servidores locales y Azure recursos compartidos de archivos SMB/NFS:
VPN de punto a sitio
Azure VPN Gateway soporta conexiones VPN 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 para los teletrabajadores que quieren poder montar su recurso compartido de archivos de Azure desde casa, una cafetería o un hotel mientras están en la carretera. Para usar una conexión VPN punto a sitio con Azure Files, necesitas configurar una conexión VPN punto a sitio para cada cliente que quiera conectarse. Consulta Configurar una VPN punto a sitio en Windows para usar con Azure Files y Configurar una VPN punto a sitio en Linux para usar con Azure Files.
VPN de sitio a sitio
Azure VPN Gateway también soporta conexiones VPN site-to-site, que son conexiones VPN entre Azure y la red de tu organización. Una conexión VPN sitio a sitio te permite configurar una conexión VPN una vez para un servidor o dispositivo VPN alojado en la red de tu organización, en lugar de configurar una conexión para cada dispositivo cliente que necesita acceder a tu archivo compartido en Azure. Consulte Configurar una VPN Site-to-Site para su uso con Azure Files.
ExpressRoute
ExpressRoute te permite crear una ruta definida entre Azure y tu 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 Microsoft recomienda usar endpoints privados para ayudar a extender tu red local a Azure, técnicamente es posible enrutar al endpoint público a través de la conexión VPN. Sin embargo, este método requiere codificar la dirección IP del endpoint público del clúster de almacenamiento de Azure que da servicio a tu cuenta de almacenamiento. Dado que las cuentas de almacenamiento pueden moverse entre clústeres de almacenamiento en cualquier momento y se añaden y eliminan nuevos clústeres con frecuencia, este método requiere codificar regularmente de forma fija todas las posibles direcciones IP de almacenamiento de Azure en tus reglas de enrutamiento.
Configuración de DNS
Cuando creas un punto final privado, Azure también crea o actualiza una zona DNS privada 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, es muy recomendable y resulta explícitamente obligatorio al montar tu recurso compartido de archivos de Azure con una entidad 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 del Gobierno de EE.UU. y la nube de Microsoft Azure operada por 21Vianet; sustituya los sufijos adecuados para su entorno específico.
En tu zona DNS privada, Azure crea un registro A para storageaccount.privatelink.file.core.windows.net y un registro CNAME para el nombre regular 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 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 storageaccount.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 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
Esta configuración refleja que la cuenta de almacenamiento puede exponer tanto el punto final público como uno o más puntos 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. Puedes hacer esto de varias maneras:
- Modifique el archivo hosts de los clientes para que
storageaccount.file.core.windows.netse resuelva en la dirección IP privada del punto de conexión privado deseado. Esto no se recomienda encarecidamente para entornos de producción, ya que deberá 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.neten 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 zona
core.windows.netde los servidores DNS locales a la zona DNS privada Azure. El host DNS privado Azure se puede acceder a través de una dirección IP especial (168.63.129.16) que solo es accesible dentro de las redes virtuales vinculadas a la zona DNS privada de Azure. Para sortear esta limitación, puedes ejecutar servidores DNS adicionales dentro de tu red virtual que reenvíencore.windows.neta la zona DNS privada de Azure. Para simplificar esta configuración, Microsoft proporciona comandos PowerShell que despliegan automáticamente los servidores DNS en tu red virtual de Azure y los configuran según se desee. Para obtener información sobre cómo configurar el reenvío DNS, consulte Configuring DNS with Azure Files.
SMB sobre QUIC
Windows Server 2022 Azure Edition soporta un protocolo de transporte llamado QUIC para el servidor SMB proporcionado por el rol de servidor de archivos. QUIC es un sustituto de TCP construido sobre UDP, ofreciendo numerosas ventajas sobre TCP y aun así proporcionando un mecanismo de transporte fiable. 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. Esta configuración significa efectivamente que SMB sobre QUIC ofrece una "VPN SMB" para compartir archivos a través de internet público. Windows 11 se distribuye con un cliente compatible con SMB a través de QUIC.
Actualmente, Azure Files no soporta SMB sobre QUIC. Sin embargo, puedes acceder a los archivos compartidos de Azure a través de Azure File Sync ejecutándose en Windows Server como en el siguiente diagrama. Esta configuración también te da la opción de que Azure File Sync almacene en caché tanto en las instalaciones como en diferentes centros de datos de Azure para proporcionar cachés locales a una fuerza laboral distribuida. Para saber más sobre esta opció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