Windows Server: FTP y SFTP, CAL y RDS explicados con buenas prácticas de concurrencia

¿Vas a publicar archivos para decenas de equipos internos y dudas entre FTP, FTPS o SFTP en Windows Server? Aquí tienes una guía práctica de licenciamiento (CAL y RDS), concurrencia y configuración óptima para que funcione estable y seguro en entornos corporativos.

Índice

Escenario y preguntas clave

Servidor de transferencias en una red privada tipo 192.168.0.x con alrededor de sesenta dispositivos.
Dudas sobre licencias: cuántas CAL hacen falta, si se requieren RDS CAL y si existe límite de conexiones por licenciamiento.
Inquietud por el periodo de gracia de RDS y su impacto en el servicio de archivos.
Si estar en la misma red cambia las reglas de acceso y licenciamiento.

Resumen ejecutivo

Pregunta	Respuesta breve
¿Hace falta RDS CAL para FTP, FTPS o SFTP?	No, a menos que los usuarios entren por escritorio remoto para operar dentro del servidor.
¿Las CAL limitan conexiones de transferencia?	No. La concurrencia depende de recursos y parámetros del servicio, no del licenciamiento.
¿Qué implica el periodo de gracia de RDS?	Solo afecta a escritorio remoto. No bloquea ni condiciona FTP, FTPS o SFTP.
¿La red local cambia algo?	No. Las reglas de licenciamiento aplican igual, estés en red interna o con acceso externo.
¿Se necesitan CAL de Windows Server?	En entornos corporativos, normalmente sí por usuario o por dispositivo, independiente de RDS.

Diferencia entre las licencias del sistema y las de escritorio remoto

En Windows Server conviven dos tipos de licencias lógicas que suelen confundirse:

CAL de Windows Server: permiten el acceso a servicios del servidor como compartición de archivos, impresoras, servicios web o el propio servicio de transferencia de archivos. Se licencian por usuario o por dispositivo. Que uses FTP, FTPS o SFTP no te exime de este requisito en entornos empresariales.
RDS CAL: necesarias cuando los usuarios abren sesiones interactivas mediante escritorio remoto para utilizar el servidor como estación de trabajo o para ejecutar aplicaciones publicadas. No son necesarias si los clientes solo envían y reciben archivos por un servicio en segundo plano.

Conclusión práctica: si el flujo de trabajo consiste en que cada equipo cliente se conecta al puerto del servicio (FTPS o SFTP) y transfiere archivos sin iniciar una sesión de escritorio, no compres RDS CAL. Si algún usuario debe iniciar sesión interactiva para administrar tareas dentro del servidor, entonces sí necesitas RDS CAL para esos usuarios o dispositivos.

Concurrencia y límites reales

Las licencias no imponen un techo de sesiones concurrentes de transferencia. La capacidad real de atender muchas conexiones a la vez depende de:

Procesador: número de hilos concurrentes, cifrado y compresión.
Memoria: buffers de red, caché de disco y procesos simultáneos.
Almacenamiento: latencia de lectura y escritura, colas de disco, rendimiento sostenido.
Red: ancho de banda disponible, latencia interna, calidad de los switches.
Parámetros del servicio: límites configurados en IIS para FTPS o en OpenSSH para SFTP.

Ejemplo de dimensionamiento con sesenta equipos

Supón que cada dispositivo sube archivos de cien megabytes y que en los picos se conectan veinte a la vez. Si quieres que esas subidas finalicen en torno a dos minutos, cada sesión necesitaría unos ocho megabits sostenidos. Con veinte sesiones, el servidor y la red deben sostener cerca de ciento sesenta megabits netos de transferencia, más overhead de TCP, TLS o SSH. Si además el almacenamiento es un volumen con cifrado en reposo y antivirus en tiempo real, la E y S de disco debe poder entregar al menos veinte a treinta megabytes por segundo sostenidos sin colas largas. Ajusta estos números a tu realidad: tamaño de archivo, número de sesiones pico y ventana temporal objetivo.

Periodo de gracia de escritorio remoto

Cuando se instala el rol de servicios de escritorio remoto, el host de sesiones permite conexiones por un tiempo de cortesía hasta que configuremos el servidor de licencias y apliquemos las licencias correspondientes. Al expirar, se restringe el acceso por escritorio remoto. Esto no afecta a los servicios de transferencia que funcionan como un demonio o servicio del sistema, por lo que FTPS y SFTP continuarán operando si no dependen de sesiones interactivas.

Impacto de estar en la red local

El hecho de que todos los equipos estén en la misma subred privada no altera el criterio de licenciamiento: las CAL de Windows Server aplican igualmente. Lo que sí cambia es la topología y la seguridad: al estar en red interna puedes prescindir de publicar puertos hacia internet, pero aun así conviene mantener prácticas de defensa en profundidad y cifrar el tránsito.

Recomendaciones de arquitectura y seguridad

Elección del protocolo

Opción	Resumen	Puertos	Autenticación	Notas
FTPS	Extensión segura de FTP con cifrado mediante tls en el servicio de internet de microsoft	Control en veintiuno y datos pasivos en un rango configurable	Usuario y contraseña del directorio local o dominio, certificados para el servidor	Ideal si ya usas el gestor de internet de microsoft y precise de compatibilidad con clientes legados
SFTP	Protocolo de archivos sobre ssh mediante el servidor de openssh para Windows	Puerto veintidós	Clave pública o usuario y contraseña, con preferencia por claves	Más simple en red y cortafuegos, menor superficie de exposición y buen control de claves
FTP sin cifrar	Transferencia en claro	Control y datos sin protección	Usuario y contraseña visibles si no se usa túnel	No recomendado en ningún entorno, ni siquiera interno

Topologías sugeridas

Solo red interna: servidor unido a dominio con roles mínimos y servicio de transferencia. Cortafuegos interno permitiendo únicamente los puertos necesarios.
Segmentación: si existe una zona de servidores, coloca el servicio en esa vlan y regula el acceso desde las subredes de usuario mediante reglas explícitas.
Publicación controlada: si en el futuro expones el servicio, utiliza un proxy o puerta de enlace, cifra extremo a extremo y aplica inspección de capa de aplicación donde sea posible.

Identidades y permisos

Crea cuentas de servicio dedicadas para el demonio de transferencia y cuentas de aplicación para los clientes robóticos.
Para casos humanos, usa grupos del directorio para autorizar acceso a sitios y carpetas, con mínimos privilegios.
Evita utilizar la cuenta de administración local o de dominio para autenticación de transferencia.
Aplica listas de control de acceso de ntfs estrictas y herencia limitada. Aísla carpetas por equipo o por organización.

Cifrado y protocolos

En FTPS fuerza tls moderno y desactiva versiones y suites de cifrado obsoletas.
En SFTP prioriza autenticación por clave pública, deshabilita inicio de sesión con contraseña si es viable y establece rotación periódica de claves.
Evita el modo activo en ftp y define un rango pasivo fijo para simplificar cortafuegos y trazabilidad.

Guía de implementación mínima

Configuración base de sftp con el servidor de openssh

Instala la característica del servidor: PowerShell Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Start-Service sshd Set-Service -Name sshd -StartupType Automatic Regla de cortafuegos New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server' -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
Configura el archivo de parámetros, normalmente en la ruta del programa del servidor en Windows: # Fragmento orientativo para apoyar concurrencia y seguridad Requiere validar con tus clientes y carga real PubkeyAuthentication yes PasswordAuthentication yes Considera deshabilitar contraseñas cuando todos usen claves PasswordAuthentication no Control de sesiones y arranques simultáneos Ajusta estos valores tras pruebas de carga MaxSessions 50 MaxStartups 60:30:200 Mantener con comandos internos para transferencia y limitar el acceso interactivo donde aplique Match Group sftpusers ForceCommand internal-sftp
Distribuye claves públicas en las carpetas de usuario del directorio autorizado y valida el inicio de sesión no interactivo si solo se permitirá transferencia.
Crea estructura de carpetas con permisos dedicados en la unidad de datos y separa cuotas por equipo o proyecto.

Configuración base de ftps con el servicio de internet de microsoft

Instala el rol de servidor web y la extensión de transferencia: PowerShell Install-WindowsFeature Web-Server Install-WindowsFeature Web-FTP-Server Install-WindowsFeature Web-Common-Http
Crea un sitio de transferencia, asigna una ruta física y un certificado del equipo. En el administrador del servicio, en la sección de seguridad de transferencia, selecciona que el cifrado sea obligatorio y vincula el certificado adecuado.
Define un rango pasivo fijo y refléjalo en el cortafuegos del servidor y en cualquier equipo intermedio: PowerShell Ejemplo de rango netsh advfirewall firewall add rule name="FTPS PASV" dir=in action=allow protocol=TCP localport=50000-51000
En límites del sitio, ajusta el máximo de conexiones concurrentes acorde a tus pruebas y establece tiempos de espera razonables de canal de control y datos.
Habilita aislamiento por usuario o por directorio virtual para separar espacios de trabajo sin fuga de información entre clientes.

Parámetros del servicio para sostener la concurrencia

En el servidor de openssh, ajusta inicio de sesiones y valores de arranque, además de los tiempos de inactividad.
En el servicio de internet para transferencia, revisa los límites de sitio, tiempos de espera y el modo de aislamiento, así como registros extendidos.
Evita inspecciones profundas en dispositivos de seguridad que rompan el canal cifrado salvo que estén en modo puente transparente y soporten tls moderno o ssh sin intermediación.

Pruebas, monitoreo y operación

Pruebas de carga

Antes de abrir a todos los clientes, realiza pruebas escalonadas con un generador de carga que simule sesiones de subida y bajada. Observa en el monitor de rendimiento contadores del procesador, memoria, red y disco. Es preferible encontrar cuellos de botella en un entorno de ensayo que en producción.

Métricas esenciales

Porcentaje de tiempo del procesador y colas por núcleo.
Longitud de cola de disco, tiempos de respuesta y transferencias por segundo.
Tráfico total por interfaz de red y paquetes con errores.
Latencia p95 y tasa de fallos por autenticación.

Registros y auditoría

En sftp, consulta el registro de aplicaciones y servicios del sistema para eventos del servidor de openssh.
En ftps, habilita registros extendidos y rota archivos por tamaño o fecha. Ubicación por defecto en la carpeta de archivos de registro del servicio de internet.
Centraliza los registros en una solución de análisis para correlacionar intentos, errores y picos de carga.

Checklist de licenciamiento y cumplimiento

Verifica que cada usuario o dispositivo que accede al servicio del servidor cuenta con la licencia adecuada del sistema por usuario o por dispositivo, según tu modalidad elegida.
Confirma que no se requieren licencias de escritorio remoto si nadie abrirá sesiones interactivas para realizar las transferencias.
Si vas a utilizar escritorio remoto para tareas administrativas recurrentes por parte de varios operadores, incorpora licencias de escritorio remoto y configura el servidor de licencias correspondiente.
Si el acceso incluye entidades externas no empleadas por tu organización, evalúa modelos alternativos de licenciamiento empresarial antes de lanzar el servicio.

Escenarios típicos y qué licencias encajan

Escenario	Licencia de servidor	Licencia de escritorio remoto	Comentario
Equipos internos que suben y bajan archivos con cliente de transferencia	Necesaria por usuario o por dispositivo	No necesaria	Servicio en segundo plano sin sesión interactiva
Operadores que administran el servidor por escritorio remoto	Necesaria	Necesaria	Se abren sesiones interactivas para gestionar o ejecutar procesos
Terminales robóticos o sensores sin usuarios humanos	Generalmente necesaria por dispositivo	No necesaria	Valora licencias por dispositivo si son equipos dedicados

Errores frecuentes y cómo evitarlos

Confundir licencias de sistema con licencias de escritorio remoto y comprar las segundas sin necesitarlas.
No fijar un rango pasivo en ftps y terminar con puertos aleatorios bloqueados por cortafuegos.
Permitir contraseñas débiles o sin rotación y no activar la autenticación por claves en sftp.
No aislar carpetas por cliente y provocar accesos no autorizados por herencia de permisos.
Ignorar el impacto del antivirus en el volumen de datos y no aplicar exclusiones donde proceda.

Guía rápida de endurecimiento

Actualiza el sistema y aplica reinicios planificados.
Minimiza roles y características instaladas, solo lo imprescindible para la transferencia.
Usa claves para sftp y tls obligatorio para ftps, con certificados firmados por una entidad de confianza interna.
Segmenta la red, limita los puertos y aplica listas de control en el cortafuegos del sistema y de la red.
Rota credenciales y claves con una política clara y registrada.
Monitorea y alerta sobre fallos de autenticación, patrones anómalos y caídas de rendimiento.

Respuestas directas a las preguntas clave

Cuántas licencias del sistema: en entornos empresariales, necesitas una por usuario o por dispositivo que accede al servicio. Con un parque fijo de sesenta equipos que realizan la transferencia, la modalidad por dispositivo suele ser la más directa. Si muchos usuarios comparten pocos equipos, por usuario puede ser preferible.
Necesitas licencias de escritorio remoto: no, mientras el acceso sea exclusivamente por transferencia de archivos. Sí, si los usuarios iniciarán sesión interactiva por escritorio remoto para trabajar dentro del servidor.
Límites de sesiones por licenciamiento: no existen límites de concurrencia por las licencias del sistema ni por las de escritorio remoto cuando no usas sesiones interactivas. Los límites prácticos dependen de recursos y configuración del servicio.
Periodo de gracia de escritorio remoto: solo tiene efecto cuando ese rol está habilitado. Su expiración restringe el acceso por escritorio remoto, no las transferencias por ftps o sftp.
Estar en la misma red: no altera la exigencia de licencias ni la naturaleza del servicio. Simplifica la red, pero no cambia la regla.

Plan de acción recomendado

Decide protocolo. Para sencillez de red y seguridad, prioriza sftp. Si ya operas con el servicio web del sistema y tienes procesos dependientes de ftp clásico, usa ftps.
Documenta el modelo de licenciamiento elegido y el inventario de usuarios o dispositivos afectados.
Prepara el servidor con almacenamiento rápido, verificación de antivirus y exclusiones donde proceda para carpetas de transferencia.
Configura el servicio elegido siguiendo las secciones anteriores y fija límites de sesiones, tiempos de espera e aislamiento.
Ejecuta pruebas con carga representativa y corrige cuellos de botella detectados.
Activa monitoreo y registros centralizados, con retención acorde a tu normativa.

Conclusión

Para un servicio de transferencia de archivos en Windows Server con decenas de clientes internos, el punto crítico no es la compra de licencias de escritorio remoto sino la planificación del servicio, el licenciamiento del sistema por usuario o por dispositivo y el ajuste fino de recursos y parámetros. Define el protocolo seguro, configura correctamente el cortafuegos, aísla espacios de trabajo y monitoriza. Así tendrás sesiones concurrentes estables sin sorpresas de licenciamiento ni bloqueos por periodos de gracia de escritorio remoto.