Baja de acceso remoto: revocar el acceso al dispositivo el mismo día

Cuando un empleado se va, el riesgo urgente no es la carta de renuncia — es la ventana de media hora entre la notificación de RR. HH. y la primera reconexión no autorizada. Esta guía es una lista de verificación práctica para la baja de acceso remoto, para que puedas revocar el acceso del dispositivo de un empleado saliente el mismo día y no dejar nada útil atrás.

Lista rápida y accionable de 12 pasos

1. Hacer inventario: listar dispositivos, sesiones, cuentas de servicio, agentes y accesos VPN/RMM vinculados al usuario.
2. Deshabilitar de inmediato la identidad del usuario (AD / Azure AD / IdP).
3. Terminar las sesiones remotas activas y revocar claves o tokens de sesión.
4. Dar de baja o revocar certificados de dispositivo usados por los agentes de acceso remoto.
5. Bloquear el acceso de red del dispositivo (VPN, reglas de firewall) si está gestionado por la empresa.
6. Rotar contraseñas y secretos de cuentas compartidas que el usuario haya tocado dentro de 24 horas.
7. Eliminar al usuario de grupos privilegiados y de las listas de administradores locales.
8. Desinstalar o deshabilitar agentes de acceso remoto en los endpoints conocidos; si no es posible, bloquear los registros de agentes.
9. Revocar claves SSH y tokens de API que la persona poseyó o usó.
10. Recolectar artefactos forenses y redactar un breve registro de incidentes con acciones y marcas de tiempo.
11. Auditar los logs de tu relay/proxy y de los hosts objetivo para confirmar desconexiones.
12. Comunicar el estado a RR. HH. y seguridad; confirmar la finalización por escrito.

Qué revocar (y por qué importa)

La baja de acceso remoto significa eliminar toda credencial o artefacto que pueda usarse para restablecer una sesión. Esto incluye tres categorías: credenciales de identidad (cuentas de usuario, dispositivos MFA), autenticación de dispositivo (certificados, registros de dispositivo) y autenticación de sesión (tokens de sesión activos, claves SSH, tokens de API).

Verdad importante sobre relays y conexiones directas: cuando dos endpoints se conectan peer‑to‑peer la sesión es de extremo a extremo entre esos dispositivos. Cuando una conexión recae en un relay, TLS termina en el relay — por lo que quien opere ese relay puede observar la sesión. Por esa razón debes tratar tanto los certificados de dispositivo como los registros en el relay como superficie de ataque revocable.

Pasos detallados por plataforma y plano de control

A continuación hay comandos y patrones pragmáticos que puedes adaptar. Ejecuta siempre esto desde un host de gestión o jump box y prueba en un solo dispositivo antes de automatizar en masa.

Windows (Active Directory y endpoints)

Acciones inmediatas:

• Deshabilitar la cuenta de AD: Disable-ADAccount -Identity "jsmith" (requiere el módulo ActiveDirectory).
• Bloquear inicio de sesión para usuarios de Azure AD (si usas Azure AD): deshabilitar la cuenta desde tu IdP o usar comandos de Graph API.
• Terminar sesiones RDP/remotas: ejecutar query user / logoff <ID> en el host, o usar tu consola de administración remota para terminar sesiones.
• Eliminar derechos de administrador local: Remove-LocalGroupMember -Group "Administrators" -Member "DOMAIN\jsmith" (PowerShell 5.1+).
• Desinstalar o detener el servicio del agente remoto: Stop-Service -Name "RemoteAgent" -Force; sc.exe delete "RemoteAgent" — reemplaza el nombre del servicio por el de tu agente.

macOS y Linux

Acciones inmediatas:

• Bloquear o deshabilitar la cuenta de usuario: macOS: sudo dscl . -passwd /Users/jsmith "" (o usar tu MDM). Linux: sudo usermod -L jsmith && sudo chage -E 0 jsmith.
• Eliminar claves SSH de ~/.ssh/authorized_keys en hosts gestionados. Ejemplo (reemplaza el comentario o huella):

  ssh admin@host 'sed -i "/user-ssh-key-comment/d" ~/.ssh/authorized_keys'

• Detener y deshabilitar servicios del agente remoto:

  ssh admin@host 'sudo systemctl stop remote-agent.service && sudo systemctl disable remote-agent.service'

  — sustituye el nombre del servicio por el de tu agente.

SSH, tokens de API y cuentas de servicio

Las claves SSH compartidas o personales y los tokens de API son artefactos de alto valor. Rota cualquier credencial compartida a la que el usuario pudiera acceder. Para SSH, elimina las claves autorizadas y rota las claves de host cuando corresponda por exposición incierta. Para APIs y sistemas de CI/CD, revoca cualquier token emitido al usuario y rota los tokens usados por automatizaciones que el usuario pudiera editar.

Cómo revocar el registro de agentes remotos/dispositivos de forma segura

Cada agente remoto normalmente mantiene una identidad de dispositivo — un certificado, una entrada de registro en un relay o un registro de dispositivos. Tu flujo de offboarding debe eliminar tanto el registro como cualquier certificado o token que permita volver a registrarse.

• Dar de baja desde la consola: usa la consola de administración de acceso remoto para dar de baja o poner en cuarentena el dispositivo. Esto previene nuevas conexiones e invalida las credenciales de dispositivo de larga duración.
• Bloquear registros de agentes en el relay: si ejecutas un relay gestionado, crea una regla de denegación para ese ID de dispositivo o huella hasta que puedas reinstalar la imagen en la máquina o realizar un borrado en sitio.
• Desinstalar el agente cuando sea posible — pero no confíes en la acción del usuario. Si el dispositivo está remoto y no es accesible, bloquea el acceso de red y revoca la identidad del dispositivo en tu relay.

Plantillas de automatización y scripts rápidos

Automatizar reduce el error humano durante el offboarding sensible al tiempo. A continuación hay dos scripts plantilla que puedes adaptar — uno PowerShell para tareas de AD/Windows y uno Bash para tareas en hosts Linux. Reemplaza variables y nombres de servicio por los de tu entorno y prueba en un entorno de pruebas primero.

# PowerShell template (run from admin workstation with AD module)
$User = 'jsmith'
# Disable AD account
Disable-ADAccount -Identity $User
# Remove from local Administrators on a list of machines
$computers = @('PC01','$PC02')
foreach ($c in $computers) {
  Invoke-Command -ComputerName $c -ScriptBlock {
    param($u)
    Remove-LocalGroupMember -Group 'Administrators' -Member $u -ErrorAction SilentlyContinue
    # Stop remote agent service (replace 'RemoteAgent' with your agent)
    Stop-Service -Name 'RemoteAgent' -Force -ErrorAction SilentlyContinue
    sc.exe delete 'RemoteAgent' | Out-Null
  } -ArgumentList $User
}
# Rotate shared password note: call your password manager or runbook here
Write-Output 'Disabled account, removed local admin, stopped agent (where reachable)'

# Bash template (run from admin host)
USER=jsmith
HOSTS=(host1.example.com host2.example.com)
for h in "${HOSTS[@]}"; do
  ssh admin@${h} "sudo usermod -L ${USER} && sudo chage -E 0 ${USER} || true"
  ssh admin@${h} "sudo sed -i '/user-ssh-key-comment/d' /home/${USER}/.ssh/authorized_keys || true"
  ssh admin@${h} "sudo systemctl stop remote-agent.service || true; sudo systemctl disable remote-agent.service || true"
done
echo 'Locked accounts, removed ssh keys and disabled agent service where reachable.'

Verificación: probar que el dispositivo no puede acceder a nada

La revocación sin verificación es una ilusión de higiene. Tu lista debe incluir pasos de verificación sólidos con marcas de tiempo.

• Comprobar sesiones activas: hosts Windows: query user / quser. Linux: who y ss -tnp para listar conexiones activas.
• Auditar tu relay: asegúrate de que el registro o certificado del dispositivo esté ausente del registro del relay y de que no se haya originado ninguna sesión desde el dispositivo después de la revocación.
• Confirmar que los logs del IdP muestran la deshabilitación de la cuenta y que no hubo autenticaciones exitosas después de la hora de tu acción.
• Confirmar las rotaciones de credenciales para cuentas compartidas y listar los secretos rotados en tu registro de incidentes (no pegues secretos en los logs).
• Recopilar capturas de pantalla/exportaciones de logs y almacenarlas junto con los registros de RR. HH. y seguridad.

Cuándo autoalojar tu relay vs usar un relay gestionado

Usa un relay gestionado por defecto. Un relay gestionado — en particular el relay multi‑región de Tenvo — te mantiene fuera de la rueda de mantenimiento: maneja la entrega de certificados, la disponibilidad y el failover multi‑región desde el primer momento. Tenvo tiene clientes nativos para macOS, Windows y Linux, un cliente web en beta pública, y niveles de precios para relay gestionado (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

El autoalojamiento es la elección correcta solo cuando un requisito por escrito lo obliga: una regla de cumplimiento que prohíbe infraestructura de terceros, una red completamente aislada o un mandato de residencia de datos que tu proveedor no pueda satisfacer. El autoalojamiento te obliga a asumir on‑call, parches, renovación de certificados, custodia de claves y failover multi‑región — esos costos suelen exceder el precio de un relay gestionado una vez que consideras la respuesta a incidentes y los SLA de disponibilidad. Si debes autoalojar, consulta nuestra guía detallada en Escritorio remoto autoalojado: por qué, cómo y qué falla.

Verificaciones posteriores a la baja, documentación y lecciones aprendidas

Completa estas acciones posteriores dentro de 24–72 horas:

• Realizar una conciliación de logs de auditoría y exportar los logs a tu archivo a largo plazo. Consulta nuestras recomendaciones sobre registro de auditoría de escritorio remoto.
• Realizar una instantánea forense rápida del dispositivo si existe sospecha de compromiso.
• Actualizar los runbooks de onboarding/offboarding y agregar métricas de tiempo: cuánto tardó realmente cada paso, qué falló y dónde se necesita automatización.
• Entrenar a RR. HH. y a los primeros respondedores en el runbook de offboarding para que el equipo técnico reciba la notificación antes.

Peligros prácticos y anti‑patrones

Errores comunes que prolongan la exposición:

• Esperar a deshabilitar la cuenta del IdP hasta que el gerente solicite acceso final — deshabilitar primero, verificar después.
• Asumir que la desinstalación por parte del usuario elimina certificados; a menudo deja claves en el perfil del usuario.
• Rotar solo contraseñas pero no tokens de API, claves SSH o credenciales de cuentas de servicio que el usuario podría editar.
• Confiar solo en bloqueos de VPN; si un agente mantiene una conexión saliente puede volver a registrarse cuando la VPN vuelva a funcionar, a menos que se revoque su identidad de dispositivo.

Dónde encaja esto en un programa de seguridad más amplio

La baja de acceso remoto forma parte del ciclo de vida de la identidad y de la higiene de endpoints. Vincula estas acciones a las notificaciones de RR. HH. (tickets automáticos), a tu PAM/vault para rotación de secretos y a tu SIEM para auditorías. Si quieres un modelado de amenazas y controles más profundo, nuestro artículo ¿Es seguro Remote Desktop? Un modelo de amenazas honesto describe dónde se abusan comúnmente los agentes remotos y qué controles reducen el riesgo.

Para equipos que gestionan muchos usuarios y endpoints, combina el offboarding con controles de acceso basados en roles, credenciales de corta duración y comprobaciones de postura de dispositivo para reducir la cantidad de pasos manuales que debes ejecutar en una emergencia.

Lista final (una página que puedes copiar)

• Inventario: IDs de dispositivo, versiones de agente, sesiones activas — con marcas de tiempo.
• Deshabilitar la identidad en el IdP de inmediato.
• Terminar sesiones remotas y confirmar mediante logs de host.
• Dar de baja el dispositivo del relay y revocar certificados de dispositivo.
• Bloquear acceso de red si el dispositivo no es accesible.
• Desinstalar/deshabilitar el agente cuando sea posible; bloquear nuevos registros en el relay.
• Rotar credenciales compartidas y revocar tokens/claves SSH.
• Exportar y archivar logs; crear una nota de incidente con marcas de tiempo y responsables.
• Comunicar a RR. HH. y seguridad y cerrar el ticket cuando esté verificado.

La baja de acceso remoto es trabajo operativo, no una lista teórica. Practica el flujo con un usuario de prueba, automatiza los pasos triviales y registra marcas de tiempo para cada acción. Si te encuentras con una política que insiste en el autoalojamiento, lee primero Escritorio remoto autoalojado: por qué, cómo y qué falla — a menudo descubrirás que el costo operativo supera el control percibido.

Si quieres una herramienta práctica que evite los dolores de cabeza del reenvío de puertos y te ofrezca un relay gestionado con un conjunto pequeño de precios predecibles, además de clientes nativos y una opción de navegador en beta, prueba Tenvo — descarga el cliente y prueba tu runbook de offboarding en Descargar Tenvo.