La sincronización de archivos por SMB se ha convertido en una pieza crÃtica para cualquier organización que comparta datos entre servidores Windows, Linux, NAS, Azure, AWS o soluciones hÃbridas. Cuando empiezas a manejar varios teras, decenas de usuarios concurrentes y requisitos de cumplimiento, ya no vale con «compartir una carpeta» y listo: entran en juego el rendimiento, los permisos NTFS y de recurso compartido, la seguridad del protocolo y hasta cómo migras esos datos sin dejar a medio negocio parado.
En este artÃculo vas a encontrar una guÃa completa sobre cómo funciona SMB, qué papel juega Samba en entornos mixtos, cómo reforzar la seguridad (cifrado, firmas, versiones del protocolo), qué buenas prácticas seguir con permisos y ACL en Windows, Azure Files, Azure NetApp Files o FSLogix, y cómo mantener un rendimiento decente incluso cuando mueves o sincronizas volúmenes enormes entre servidores o hacia la nube.
Qué es SMB y por qué sigue siendo clave para compartir archivos
El protocolo Server Message Block (SMB) es el «idioma» de compartición de archivos, impresoras y ciertos servicios de red que usan de forma nativa los sistemas Windows. A través de SMB, un cliente puede acceder a carpetas compartidas, abrir y editar archivos, ver impresoras o consultar determinados recursos como si estuvieran en su propio equipo, aunque en realidad se encuentren en un servidor remoto.
SMB ha ido evolucionando con los años. Cada salto ha traÃdo mejoras de rendimiento, más seguridad (cifrado integrado, firmas modernas, integridad de autenticación previa) y más funcionalidades pensadas para entornos de alta disponibilidad o virtualización como Hyper-V o SQL Server sobre servidores de archivos.
La gracia de usar SMB es que permite integrar redes mixtas (Windows, macOS, Linux, dispositivos de almacenamiento, nubes públicas) sin obligar a los usuarios a cambiar su forma de trabajar: siguen utilizando el Explorador de archivos, mapean unidades de red y guardan sus documentos como siempre.
Capa de seguridad en SMB: cifrado, firmas y versiones del protocolo
La seguridad en SMB ya no es un «extra» opcional. Si compartes ficheros con datos sensibles y la red no es totalmente de confianza, necesitas cifrado y protección frente a ataques de interceptación (man-in-the-middle). Windows Server y Windows 10/11 han incorporado mejoras de seguridad importantes en las últimas versiones del protocolo SMB.
El cifrado SMB proporciona protección extremo a extremo de los datos que viajan entre cliente y servidor. A diferencia de soluciones como IPsec o hardware WAN especÃfico, el cifrado SMB se configura directamente sobre el protocolo. Se puede aplicar:
- A nivel de recurso compartido (solo algunas carpetas).
- A nivel de servidor (todo el servidor de archivos).
- En el propio mapeo de unidad desde el cliente.
Los escenarios tÃpicos donde tiene sentido activarlo incluyen datos de usuarios o aplicaciones crÃticas que atraviesan redes no controladas (WAN de proveedores, redes de terceros, entornos hÃbridos) o cuando usas SMB para ofrecer almacenamiento altamente disponible a servicios como SQL Server o Hyper-V.
A partir de Windows Server 2022 y Windows 11, SMB 3.1.1 negocia de forma automática conjuntos criptográficos modernos como AES-256-GCM y AES-256-CCM, aunque sigue existiendo compatibilidad con AES-128-GCM y AES-128-CCM. De forma predeterminada se suele usar AES-128-GCM porque ofrece un equilibrio muy bueno entre rendimiento y seguridad.
Además, SMB Direct (SMB sobre RDMA), presente en entornos de alto rendimiento, ahora puede cifrar el tráfico sin renunciar al acceso directo a memoria. Se reduce asà el impacto de rendimiento respecto a TCP clásico cuando se activa el cifrado.
Requisitos y métodos para habilitar el cifrado SMB
Antes de lanzarte a activar el cifrado en todos los recursos compartidos, conviene comprobar algunos requisitos previos básicos. Para evitar sorpresas con clientes antiguos o aplicaciones raras. Son estos:
Lo primero: Contar con una versión de Windows o Windows Server compatible con SMB 3.0 o superior. Y que dicho protocolo esté habilitado tanto en el lado cliente como en el servidor. Además, necesitarás privilegios de administrador (o equivalentes) en ambos extremos para poder modificar la configuración.
El cifrado puede habilitarse por interfaz gráfica con Windows Admin Center, mediante PowerShell o forzando requisitos en el cliente a través de la llamada «protección UNC», que permite exigir cifrado incluso si el servidor no lo tiene configurado de forma predeterminada.
Cuando activas el cifrado en un servidor o un recurso compartido, por defecto solo los clientes SMB 3.0, 3.02 y 3.1.1 pueden conectarse. Es una medida deliberada para asegurar que todos los clientes que accedan a ese recurso lo hagan con cifrado. Los clientes más antiguos o sin soporte de SMB 3.x serán rechazados a menos que relajes la configuración.
Si en tu entorno conviven sistemas antiguos que no soportan SMB 3.x, puedes desactivar el rechazo de acceso sin cifrar con PowerShell usando la propiedad RejectUnencryptedAccess del servidor SMB. Esto supone bajar el listón de seguridad, por lo que conviene limitarlo.
Cómo activar el cifrado SMB: Admin Center, PowerShell y protección UNC
En muchos casos, la forma más cómoda de gestionar un servidor de archivos moderno es Windows Admin Center. Desde su interfaz web puedes activar el cifrado tanto a nivel de servidor como para recursos compartidos especÃficos sin complicarte con comandos.
Para un recurso compartido concreto, basta con seleccionar el nombre del share en la pestaña de recursos compartidos de archivos y marcar la opción de habilitar cifrado SMB. Si quieres obligar a que todo el servidor use cifrado, puedes ir a la configuración del servidor de archivos y establecer que el cifrado SMB 3 sea obligatorio para todos los clientes, rechazando cualquier conexión que no lo soporte.
Si prefieres la lÃnea de comandos, PowerShell ofrece cmdlets claros como Set-SmbShare, Set-SmbServerConfiguration o New-SmbShare para crear y configurar recursos con cifrado activado desde el primer momento, asà como comandos para mapear unidades exigiendo privacidad (-RequirePrivacy) tanto desde PowerShell como desde CMD con NET USE ... /REQUIREPRIVACY.
La protección UNC añade otra capa. Permite que, aunque el servidor no requiera cifrado por defecto, el cliente puede estar configurado para aceptar únicamente conexiones cifradas hacia determinadas rutas UNC. Esto es especialmente útil para proteger contra ataques de interceptación en redes poco confiables, forzando la privacidad en los clientes corporativos.
Al implantar cifrado, debes considerar la presencia de aceleradores WAN o dispositivos intermedios en la red que dependan de ver el contenido en claro. El cifrado SMB puede interferir con su funcionamiento y generar incidencias de acceso o rendimiento.
Integridad de autenticación previa y firma moderna en SMB 3.x
Para reforzar aún más la seguridad contra ataques de degradación del protocolo o manipulación de la negociación, SMB 3.1.1 incorpora la llamada integridad de autenticación previa. Esta función calcula hashes criptográficos de los mensajes de negociación y configuración de sesión. Después usa ese resultado en la derivación de claves de sesión y de firma.
Gracias a este mecanismo, cliente y servidor pueden detectar si alguien está manipulando la conexión para forzar, por ejemplo, un descenso a SMB 2.x sin cifrado. Si se detecta una inconsistencia en esos hashes, la sesión se cierra de forma inmediata.
En paralelo al cifrado, SMB evoluciona también en la parte de firma de mensajes. SMB 2.0 usaba HMAC-SHA256, mientras que SMB 3.0/3.02 ya introdujeron AES-CMAC, más optimizado para CPUs modernas que soportan instrucciones AES. Con Windows Server 2022 y Windows 11, SMB 3.1.1 añade AES-128-GMAC como algoritmo de firma, que ofrece mejor rendimiento en muchos escenarios.
La ventaja práctica es que ahora puedes separar firma y cifrado. Si en algún caso necesitas solo firma (integridad) sin cifrado, SMB lo permite con algoritmos modernos. Esto te da flexibilidad para cumplir requisitos de auditorÃa y rendimiento al mismo tiempo.
Para sacar el máximo partido a estas funciones y evitar que un atacante fuerce el uso de SMB 1.0, es buena idea deshabilitar SMBv1 por completo en servidores y clientes modernos, algo que Microsoft ya hace de forma predeterminada en versiones recientes de Windows y Windows Server.
Por qué debes desactivar SMB 1.0 cuanto antes
SMB 1.0 es un protocolo antiguo, poco eficiente y con vulnerabilidades graves conocidas que han sido explotadas por ransomware y otros tipos de malware en los últimos años. Por eso, a partir de ciertas versiones de Windows 10 y Windows Server, ya no se instala por defecto.
Si en tu entorno todavÃa queda algún servidor o equipo con SMB 1.0 habilitado, el primer paso sensato es planificar su eliminación. La recomendación actual es deshabilitarlo tanto en servidores como en clientes. Se recomienda mantener únicamente SMB 2.x y 3.x. Esto reduce de forma drástica la superficie de ataque y evita que una conexión legÃtima acabe degradada a una versión sin cifrado o con seguridad deficiente.
En entornos Windows puedes gestionar SMB 1.0 desde caracterÃsticas opcionales del sistema, PowerShell o herramientas de administración remota. Conviene documentar bien qué servicios podÃan depender de él. Para que nadie se lleve una sorpresa después.
En algunos escenarios muy especÃficos (por ejemplo, centros de activación antiguos) puede que no tengas más remedio que mantener SMB 1.0 en un segmento de red aislado y altamente controlado. Hablamos de excepciones muy puntuales y con compensaciones de seguridad importantes.
Sincronización y migraciones de grandes volúmenes SMB sin cortar el servicio
Uno de los retos más molestos en la vida real es migrar o sincronizar grandes directorios SMB (hablamos de 10 TB o más) de un servidor a otro o hacia otra plataforma, sin dejar a la empresa varios dÃas sin poder escribir en los recursos compartidos.
La aproximación clásica suele ser esta:
- Deshabilitar la escritura en el share antiguo.
- Usar una herramienta como robocopy para copiar todo el contenido manteniendo permisos NTFS.
- Configurar los nuevos shares en el servidor destino.
- Actualizar las asignaciones de unidad.
- Pedir a los usuarios que reinicien sus equipos.
Esto funciona, pero tiene el problema de que durante la copia larga nadie puede guardar cambios en el origen.
En volúmenes gigantes y discos no muy rápidos, la copia inicial puede tardar más de un fin de semana, lo que impacta directamente en el negocio. Si dejas el share en uso mientras copias, corres el riesgo de perder cambios, borrados o movimientos de archivos realizados durante la ventana en la que se hace la migración.
En estos casos, la estrategia pasa por combinar múltiples pasadas con robocopy (primero copia masiva, luego solo cambios) y planificar una ventana de corte final muy corta durante la cual se deshabilita la escritura. Luego se hace una sincronización incremental con /MIR o similar y se redirige el acceso al nuevo servidor. Para los VHDX y otros ficheros enormes, puede ser necesario planificar ventanas especÃficas. O incluso replicaciones a nivel de almacenamiento si la cabina lo permite.
Otra alternativa es migrar por trozos, moviendo carpetas grandes por fases y comunicando bien a los usuarios los cambios de rutas. Lo malo es que esto suele complicar la experiencia de uso.
Permisos y ACL en SMB para FSLogix, Azure Files y Azure NetApp Files
En entornos modernos de virtualización de escritorios o aplicaciones, como los que usan FSLogix, los perfiles de usuario se almacenan en contenedores VHD(X) sobre recursos SMB. Estos recursos pueden vivir en servidores de archivos tradicionales, en Azure Files, en Azure NetApp Files o incluso sobre pasarelas como AWS Storage Gateway.
FSLogix utiliza rutas UNC (VHDLocations o CCDLocations) para ubicar los contenedores de perfil y de Office. La seguridad de esos datos depende de dos capas:
- Los permisos NTFS (ACL de Windows) en el recurso compartido.
- Los permisos de nivel de recurso compartido asignados a identidades de Entra ID en Azure Files.
En Azure Files es muy recomendable configurar un permiso de recurso compartido predeterminado del tipo «colaborador de recursos compartidos SMB de datos de archivos de almacenamiento» aplicado a todas las identidades autenticadas. Imprescindible para que puedan leer y escribir. Para administrar ACL detalladas, se otorga a ciertos usuarios o grupos un rol de colaborador con privilegios elevados sobre el share.
La práctica recomendada para estos escenarios es usar lo que se denomina acceso basado en el usuario. Cada usuario debe ser dueño de su propia carpeta de perfil o fichero VHD(X). Por su parte, los administradores de dominio y grupos de soporte tienen control total para labores de mantenimiento.
Para configurar esto, se establecen ACL tÃpicas donde el grupo de administradores del dominio tiene control total sobre toda la estructura, CREATOR OWNER tiene permisos de modificación sobre subcarpetas y archivos, y el grupo de usuarios de dominio tiene permisos de modificación solo sobre la carpeta raÃz para que se puedan crear sus directorios.
Aplicar ACL de Windows: icacls, Explorador y SIDDirSDDL en FSLogix
En Windows puedes usar la herramienta de lÃnea de comandos icacls para aplicar de forma masiva permisos NTFS recomendados sobre un recurso compartido, incluyendo la carpeta raÃz y todos sus subdirectorios y archivos, algo muy útil cuando preparas shares para FSLogix, perfiles móviles o repositorios multiusuario.
Con icacls puedes, por ejemplo, deshabilitar la herencia en la raÃz del recurso compartido, otorgar permisos especiales a CREATOR OWNER, a los administradores del dominio y a los usuarios de dominio, y asegurar que cada nueva carpeta creada herede esa estructura de permisos correctamente.
Si prefieres entorno gráfico, el propio Explorador de archivos de Windows te permite editar permisos avanzados: desactivar herencia, añadir entidades de seguridad (como CREATOR OWNER, grupos de dominio, etc.), definir a qué se aplican (solo esta carpeta, subcarpetas y archivos, etc.) y marcar niveles de permiso como Modificar o Control total.
FSLogix, además, ofrece una opción interesante llamada SIDDirSDDL. Esta configuración acepta una cadena SDDL que define las ACL que se aplicarán automáticamente al directorio del usuario en el momento de su creación. Para generar esa cadena, se suele crear una carpeta de prueba. En ella se ajustan los permisos a la estructura deseada, se extrae la SDDL con PowerShell (Get-Acl | Select Sddl), y luego se adapta la parte del propietario y de CREATOR OWNER para que usen el SID del usuario dinámicamente.
Una vez configurado SIDDirSDDL en las polÃticas de FSLogix, cada vez que un usuario inicia sesión por primera vez, su directorio se creará con los permisos exactos definidos en esa SDDL. Nos ahorramos asà tener que corregir ACL a posteriori o ejecutar scripts adicionales.
SMB en la nube y pasarelas de archivo: Azure, AWS y almacenamiento hÃbrido
Además del clásico servidor de archivos on-premises, muchas organizaciones usan hoy servicios de almacenamiento SMB en la nube como Azure Files, Azure NetApp Files o soluciones hÃbridas que exponen SMB en el borde y almacenan datos en S3 u otros backends, como AWS Storage Gateway en modo file gateway.
En Azure Files, el flujo habitual es este:
- Crear un recurso compartido de archivos SMB.
- Vincularlo a un origen de identidad (Active Directory tradicional, Azure AD Domain Services, etc.).
- Asignar permisos de share a usuarios o grupos de Entra ID.
- Configurar las ACL NTFS desde un equipo unido al dominio.
En Azure NetApp Files los pasos son estos:
- Crear una cuenta de NetApp.
- Definir sitios y diseño de AD DS.
- Crear grupos de capacidad y volúmenes SMB especÃficos.
- Trabajar exclusivamente con permisos Windows como si se tratara de un servidor de archivos clásico, pero respaldado por almacenamiento de alto rendimiento en la nube.
Con AWS, la consola de Storage Gateway permite crear recursos compartidos de archivo SMB apoyados en buckets S3, definiendo la puerta de enlace, el bucket o punto de acceso, clase de almacenamiento, rol de IAM y opciones como el uso o no de PrivateLink, tipos de cifrado o detección de tipos MIME.
En estos entornos hÃbridos, las ACL de SMB y NTFS siguen siendo el mecanismo fundamental para controlar quién ve qué archivos y con qué nivel de permisos, aunque por debajo se estén usando buckets de objetos o volúmenes en la nube. Resulta especialmente importante coordinar la seguridad de SMB con la de los roles de IAM o equivalentes para evitar incoherencias.
Combinando todas estas piezas es posible construir una infraestructura de sincronización de archivos robusta, segura y con un rendimiento razonable. Incluso cuando trabajas con volúmenes enormes y entornos hÃbridos complejos.
