Acceso de proveedores sin perder el control: RDP con trazabilidad end-to-end

Hace unas semanas, un amigo con una startup de IA me escribió en medio de un incendio: varios proveedores necesitaban entrar por RDP a sus…

Hace unas semanas, un amigo con una startup de IA me escribió en medio de un incendio: varios proveedores necesitaban entrar por RDP a sus instancias EC2 y no había ni aprobación previa ni rastro de lo que hacían. En 2025, en plena ola de ataques a la cadena de suministro, eso es jugar a la ruleta. En este post (sin revelar detalles sensibles) te cuento el patrón que implementamos: acceso Just-in-Time (JIT), aprobación obligatoria y sesiones RDP grabadas y auditadas end-to-end en AWS.

Situación actual

El cliente opera varias instancias EC2 a las que distintos proveedores deben conectarse por RDP para mantenimiento y soporte. Idealmente, las tareas se ejecutarían desde infraestructura controlada por el cliente; sin embargo, en la práctica hay casos en los que las instancias residen o se gestionan desde infraestructura/cuentas del propio proveedor, lo que obliga a habilitar acceso directo. El problema: el acceso existe, pero la visibilidad y el control sobre lo que ocurre dentro de la sesión son limitados.

Problemas detectados

• Sin evidencia forense (sin grabación ni logs correlacionables).
• Acceso a terceros permanentemente habilitado (sin expiración ni ventanas de tiempo).
• Sesiones sin supervisión ni aprobación previa.
• Credenciales compartidas o usuarios genéricos.

Solución JIT + RDP auditado

Objetivo: acceso de proveedores solo cuando toca, aprobado, temporizado y con evidencia end-to-end.

Flujo de acceso

1. Solicitud: el proveedor pide acceso.
2. Aprobación JIT: se autoriza por una ventana corta.
3. Conexión segura: entra por Fleet Manager (GUI Connect), sin abrir 3389 público.
4. Trazabilidad total: sesión grabada en S3/KMS + logs de Windows y CloudTrail.
5. Cierre automático: al vencer el tiempo, se revocan permisos y etiquetas.

La solución JIT + RDP auditado reduce drásticamente el riesgo porque elimina el acceso permanente y solo lo habilita cuando realmente se necesita, con aprobación previa y expiración automática. Al usar Fleet Manager (GUI Connect) evitas abrir el 3389 a Internet, cerrando un vector común de ataque y garantizando que cada sesión esté atada a una identidad individual con MFA. La grabación de la sesión en S3/KMS y los logs de Windows y CloudTrail te dan trazabilidad end-to-end y evidencia forense lista para auditorías. En operación, ordena la gestión de proveedores mediante etiquetas y permisos por instancia, y evita accesos residuales al revocar automáticamente al cierre, lo que reduce la superficie de ataque, incrementa el control, simplifica el cumplimiento y asegura trazabilidad total sobre quién hizo qué y cuándo.

Es preferible que todas las instancias estén gestionadas por AWS Systems Manager (SSM) (luego haré un post explicándolo a fondo). Con SSM operativo y Fleet Manager funcionando, el siguiente paso es preparar el almacenamiento de evidencia: crear un bucket de S3 dedicado para las grabaciones de RDP, de modo que cada vez que un proveedor se conecte, se grabe la pantalla de la instancia.

Con (JIT) Node Access en AWS, el proveedor solicita acceso, tú lo apruebas y se habilita una ventana temporal; al terminar, el permiso se revoca solo. La conexión pasa por Systems Manager, así que no necesitas exponer 3389/22. Todo queda auditado en CloudTrail y, si usas Fleet Manager para RDP, puedes grabar la sesión en S3 cifrada con KMS, lo que garantiza mayor control, reduce riesgos operativos y aporta evidencia clara de quién hizo qué y cuándo.

AWS IAM Identity Center (antes AWS SSO) es la forma más limpia de dar acceso a proveedores sin crear usuarios IAM locales: creas o sincronizas el usuario, habilitas MFA, defines un permission set de privilegios mínimos y asignas al usuario a la cuenta correspondiente. Con eso, las políticas del permission set aplican automáticamente y solo permiten RDP donde corresponda.

Para que nadie quede “activo” todo el tiempo, puedes:

• A) Asignar el permission set solo cuando el proveedor va a trabajar (y retirarlo al cierre).
• B) Dejar el permission set fijo y controlar el acceso únicamente con JIT (aprobación y expiración).

Implementé la opción A + JIT por preferencia del cliente, pero ambas funcionan y se pueden combinar.

Con la política JIT manual lista, podemos avanzar. (Conviene aclarar que JIT también puede configurarse en modo autoaprobado; en este caso, elegimos aprobaciones manuales para maximizar el control y la separación de funciones). Así garantizamos que cada acceso tenga justificación, una ventana temporal definida y trazabilidad completa.

Este post se centra en el patrón de solución, no en cada clic de la consola. Más adelante publicaré una guía paso a paso con la implementación detallada (roles, policies, bucket/KMS, reglas de EventBridge, etc.) y variantes para escenarios de menor riesgo donde el auto-approve tenga sentido, por ejemplo, en dev o en ventanas de mantenimiento recurrentes.

Una vez todo configurado, al proveedor le aparecerá una ventana para solicitar acceso a la instancia EC2, ya sea por terminal o mediante RDP. La aprobación dependerá de nosotros, quienes decidiremos si otorgarlo o rechazarlo, garantizando así un mayor control y trazabilidad en el proceso.

Del lado del cliente, una vez que el proveedor solicita el acceso, se genera automáticamente una notificación. Esta alerta puede configurarse para llegar por correo electrónico, aunque también es posible habilitar otros canales más interactivos, como aplicaciones de mensajería.

Una vez que el proveedor obtiene acceso, la mayoría de los registros que puedan resultar de interés quedarán almacenados de forma automática. Este comportamiento puede ajustarse desde el apartado de configuración del JIT, lo que brinda mayor flexibilidad en la gestión. Además, para incrementar la visibilidad y asegurar una trazabilidad completa, hemos habilitado la grabación de sesiones. Dichas grabaciones se envían de manera centralizada a un bucket de Amazon S3, donde permanecen disponibles para auditorías, revisiones de seguridad y cumplimiento normativo, garantizando así un control más robusto de la actividad.

Conclusión

La implementación de un esquema Just-in-Time (JIT) con RDP auditado representa un cambio fundamental en la manera de gestionar accesos de terceros a instancias EC2. Pasamos de un modelo inseguro con accesos permanentes, credenciales compartidas y nula trazabilidad a un enfoque controlado, temporal y completamente auditable.

Al habilitar aprobaciones manuales, grabación de sesiones en Amazon S3 cifrado con KMS, y trazabilidad end-to-end a través de Windows Logs y CloudTrail, logramos un ecosistema donde cada acceso está justificado, limitado en el tiempo y respaldado por evidencia forense lista para auditoría.

Este método reduce drásticamente la superficie de ataque, acelera el cumplimiento y ordena la gobernanza de proveedores. Con la presión sobre la cadena de suministro, el acceso temporal, revisado y registrado ya no es opcional: es imprescindible para la ciberresiliencia.