AWS Transfer Family: Terraform con Okta y Entra ID

AWS Transfer Family ahora tiene ejemplos oficiales de Terraform para integrar Okta y Microsoft Entra ID como proveedores de identidad personalizados. El módulo aws-ia/transfer-family en Terraform Registry incorpora desde abril de 2026 templates listos para deployar SFTP con autenticación federada, usando Lambda como intermediario entre Transfer Family y el IdP.

Qué es AWS Transfer Family y por qué el SSO importa

AWS Transfer Family es el servicio managed de Amazon para transferencia de archivos via SFTP, FTPS y FTP, sin necesidad de mantener servidores propios. Lo usás cuando tenés socios, proveedores o sistemas legacy que necesitan intercambiar archivos de forma segura y ya conocen los protocolos estándar de transferencia.

El problema histórico era la gestión de credenciales. Transfer Family siempre soportó autenticación nativa (usuarios en el propio servicio) o contra directorios de AWS. Pero si tu empresa ya usa Okta o Entra ID para todo el resto, tener usuarios separados para SFTP es una pesadilla operativa: reseteos de contraseña por duplicado, offboarding que se olvida, auditorías que no cierran.

Acá entra el Custom Identity Provider (IdP), que existe desde hace tiempo. Lo nuevo de abril de 2026 es que AWS publicó ejemplos Terraform oficiales para que no tengas que armar toda la arquitectura desde cero.

La arquitectura: Lambda como intermediario de identidad

El flujo es el siguiente: el cliente SFTP se conecta a Transfer Family con usuario y contraseña. Transfer Family, en vez de validar las credenciales internamente, invoca una función Lambda con esos datos. La Lambda los lleva al IdP configurado (Okta o Entra ID), recibe la respuesta, y si todo está bien devuelve a Transfer Family los permisos del usuario (bucket S3, prefijos accesibles, rol IAM).

Eso sí, la Lambda no es solo un proxy tonto. Tiene que manejar el mapping de atributos del IdP a los permisos de Transfer Family, el manejo de errores, y opcionalmente el logging detallado. AWS proporciona una función de referencia en el toolkit, pero vas a tener que adaptarla a tu estructura de grupos y permisos.

Los componentes concretos que deployás: un aws_transfer_server, una aws_lambda_function con acceso a Secrets Manager para las credenciales del IdP, y una tabla DynamoDB opcional para cachear atributos de usuario (útil para reducir latencia en autenticaciones frecuentes). El audit logging de Transfer Family registra cada intento de autenticación en CloudWatch. Esto se conecta con lo que analizamos en estrategia SEO en múltiples regiones.

Integración con Okta: soporte de MFA incluido

Okta es el caso más completo de los dos. Según la documentación oficial del blog de AWS Storage, el Custom IdP con Okta soporta autenticación por contraseña y MFA basado en TOTP (el código de 6 dígitos que genera una app de autenticación).

El mecanismo de MFA en SFTP tiene una particularidad que no todo el mundo nota: el protocolo SFTP no tiene un campo nativo para el segundo factor. La implementación de AWS resuelve esto concatenando la contraseña y el código TOTP en el campo de password, separados por un carácter configurable. Ponele, si tu contraseña es MiPass123 y el TOTP es 847291, mandás MiPass123847291. La Lambda hace el split y valida cada parte por separado.

¿Funciona en la práctica? Sí, pero tenés que entrenar a los usuarios o configurar scripts que armen el string correctamente. No es exactamente ergonómico (si es que eso cuenta como experiencia de usuario pulida), pero es funcional para casos enterprise donde los accesos son automatizados de todas formas.

Okta también permite recuperar atributos del usuario (grupos, departamento, custom attributes) que podés mapear a permisos S3 específicos, lo cual es muy útil para implementar multi-tenancy en SFTP.

Integración con Microsoft Entra ID: OAuth 2.0 pero sin MFA

Entra ID (antes Azure Active Directory) tiene una integración diferente. Según el blog de AWS sobre autenticación con Azure AD, el flujo usa password-based auth y OAuth 2.0 para validar credenciales contra el tenant de Microsoft 365.

La limitación importante: MFA no está soportado de forma nativa en este setup. Si tu tenant de Entra ID tiene MFA obligatorio para todos los usuarios (que es lo recomendable), necesitás crear políticas de acceso condicional que excluyan las autenticaciones de Transfer Family, o usar service accounts específicas para SFTP.

Esto no es menor. Para una empresa con postura de seguridad seria, eximir cuentas de MFA es un tradeoff que hay que documentar y justificar. No es imposible, pero tampoco es algo que hagas sin pensarlo. Para más detalles técnicos, mirá confiabilidad de servicios en nube.

¿Cuándo tiene sentido usar Entra ID a pesar de esto? Cuando tu empresa ya tiene todo en Microsoft 365, los grupos y permisos ya están modelados ahí, y el equipo de IT prefiere gestionar todo desde el mismo lugar. El ahorro operativo puede justificar la limitación de MFA si compensás con otros controles (IP allowlisting, logging agresivo, service accounts con permisos mínimos).

Cómo deployar con el módulo Terraform

El módulo aws-ia/transfer-family en Terraform Registry tiene los ejemplos en el directorio /examples, separados por IdP. La estructura básica para Okta se ve así:

Primero configurás el servidor con Lambda como IdP:

• identity_provider_type = "AWS_LAMBDA" en aws_transfer_server
• ARN de la Lambda en function_arn
• Permisos IAM para que Transfer Family pueda invocar la Lambda (lambda:InvokeFunction)
• La Lambda necesita permisos para leer secrets de Secrets Manager (donde guardás el client_id y client_secret de Okta/Entra ID)

Un detalle que los ejemplos del repositorio de aws-samples/toolkit-for-aws-transfer-family manejan bien: la rotación de credenciales del IdP. Las credenciales de la aplicación en Okta o Entra ID se guardan en Secrets Manager, y la Lambda las lee cada vez (con caching local por tiempo configurable). Así podés rotar sin redesployar.

Lo que tenés que aportar vos: el mapping de atributos específico de tu organización. Los ejemplos traen un mapping genérico que asume una estructura de grupos específica; lo más probable es que tengas que adaptarlo.

Comparativa: Okta vs Microsoft Entra ID en Transfer Family

Beneficios concretos para operaciones y compliance

Centralizar la identidad para SFTP tiene un impacto directo en tres áreas que suelen aparecer en auditorías:

Primero, el offboarding. Cuando un empleado o contratista se va, deshabilitar la cuenta en Okta o Entra ID corta el acceso a Transfer Family automáticamente. Sin cuentas SFTP locales que se queden activas por olvido. Ya lo cubrimos antes en automatización de flujos con Docker.

Segundo, el audit trail. Transfer Family registra cada conexión y transferencia en CloudWatch, y esos logs incluyen el username del IdP. Cruzar esos logs con los de Okta/Entra ID te da visibilidad completa de quién accedió a qué y cuándo, algo que los frameworks de compliance (SOC 2, ISO 27001) requieren explícitamente.

Tercero, la escala. Si tenés 50 socios o partners con acceso SFTP, gestionar eso con usuarios locales es un trabajo manual constante. Con el Custom IdP, podés usar grupos del directorio para asignar permisos de forma masiva.

Para empresas con infraestructura en AWS que necesiten un proveedor de hosting web o dominios en la región, donweb.com tiene opciones de cloud y servidores con soporte en español que pueden complementar esta arquitectura.

Errores comunes al implementar Custom IdP en Transfer Family

Error 1: No manejar el timeout de Lambda correctamente. Transfer Family tiene un timeout de 10 segundos para la invocación de Lambda. Si tu IdP tarda más (raro, pero pasa en redes con alta latencia o cuando Okta tiene degradación), la autenticación falla con un error genérico que no indica la causa real. Configurá alarmas en CloudWatch para latencia de Lambda y manejá el timeout explícitamente en el código.

Error 2: Olvidar el IP allowlisting del endpoint de Transfer Family. Tenés un IdP que valida identidades, pero si no restringís desde qué IPs se pueden conectar al servidor SFTP, cualquiera puede intentar autenticarse. Transfer Family soporta security groups y VPC endpoints. Usalo.

Error 3: Mapping de permisos demasiado permisivo en los ejemplos. Los ejemplos del toolkit de AWS usan un mapping de bucket S3 genérico para simplificar la demostración. Si copiás eso a producción sin adaptar, terminás con usuarios que tienen acceso a más prefijos de los que deberían. Revisá el mapping de atributos antes de poner en producción. Más contexto en automatización de procesos de transferencia.

Error 4: No testear la concatenación de MFA con diferentes clients SFTP. Si usás Okta con MFA, el comportamiento varía según el cliente SFTP. FileZilla, WinSCP, y scripts de Python con Paramiko manejan el campo de contraseña diferente. Testeá con todos los clientes que van a usar tus usuarios antes de hacer el rollout.

Preguntas Frecuentes

¿Cómo configuro Okta como proveedor de identidad en AWS Transfer Family?

Creás una aplicación de tipo “API Services” en Okta y obtenés el client_id y client_secret. Guardás esas credenciales en AWS Secrets Manager. Deployás una Lambda que, al recibir las credenciales del usuario de Transfer Family, las valida contra la API de Okta y devuelve los permisos S3 correspondientes. Configurás identity_provider_type = "AWS_LAMBDA" en el servidor Transfer Family apuntando al ARN de esa Lambda. El ejemplo completo está en el repositorio aws-samples.

¿AWS Transfer Family soporta Microsoft Entra ID como IdP?

Sí, desde el anuncio de abril de 2026 hay ejemplos Terraform oficiales para Entra ID. La arquitectura es la misma que con Okta: Lambda como intermediario que valida contra Microsoft Graph API. La limitación es que MFA no está soportado de forma nativa en el flujo SFTP con Entra ID, por lo que necesitás políticas de acceso condicional en tu tenant para manejar esto.

¿Necesito usar Lambda para integrar Okta con Transfer Family?

Sí, la arquitectura de Custom IdP en Transfer Family requiere Lambda como intermediario. No hay forma de conectar Transfer Family directamente a Okta o Entra ID sin una función Lambda. La Lambda recibe las credenciales del intento de autenticación, las valida contra el IdP, y devuelve los permisos. AWS también ofrece una arquitectura alternativa con API Gateway, pero Lambda directa es la recomendada para este caso.

¿Puedo usar MFA con Okta en AWS Transfer SFTP?

Sí, pero con una adaptación: el cliente SFTP tiene que concatenar la contraseña y el código TOTP en el campo de password (por ejemplo contraseña123456789 donde los últimos 6 dígitos son el TOTP). La Lambda hace el split y valida cada parte contra Okta por separado. Funciona bien para accesos automatizados; para usuarios humanos requiere configurar el cliente SFTP correctamente o usar un wrapper script.

¿Cuál es el módulo Terraform para deployar Transfer Family con autenticación federada?

El módulo oficial es aws-ia/transfer-family disponible en Terraform Registry. Los ejemplos específicos para Okta y Entra ID están en el directorio /examples del módulo. Para versiones más detalladas y el código de la Lambda de referencia, el repositorio aws-samples/toolkit-for-aws-transfer-family en GitHub tiene todo el toolkit con documentación de cada componente.

Conclusión

Los ejemplos Terraform para Okta y Entra ID en Transfer Family eliminan la excusa más común para no implementar SSO en SFTP: “es mucho trabajo armarlo desde cero”. Con el módulo aws-ia y los ejemplos del toolkit de AWS, tenés una base funcional que podés adaptar en horas en vez de días.

Si tu empresa ya tiene Okta y querés el setup más completo (con MFA), ese es el camino. Si estás en un entorno Microsoft 365, Entra ID tiene sentido a pesar de la limitación de MFA, que podés compensar con controles compensatorios. Lo que ya no tiene justificación es seguir gestionando usuarios SFTP de forma local cuando el directorio corporativo ya existe y está mantenido.

El próximo paso concreto: clonar el repositorio, revisar el ejemplo que aplica a tu IdP, y adaptar el mapping de atributos a tu estructura de grupos antes de poner cualquier cosa en producción.

Fuentes

• AWS – Anuncio oficial: Transfer Family Terraform module con Okta y Entra ID (abril 2026)
• AWS Blog Storage – Deploy Okta como Custom Identity Provider en Transfer Family
• AWS Blog Storage – Autenticación con Azure Active Directory/Entra ID y Lambda
• GitHub – aws-samples/toolkit-for-aws-transfer-family (ejemplos completos)
• Terraform Registry – Módulo aws-ia/transfer-family