Offboarding seguro en Google Workspace: checklist al dar de baja empleados

Por Kike Gandia · Co-Fundador y CEO, OSCP

Las cuentas de ex-empleados mal gestionadas son una superficie de ataque silenciosa: accesos que siguen activos, datos que se pierden y tokens que nunca se revocan. Este checklist cubre el offboarding seguro de un empleado en Google Workspace, paso a paso.

Suspende la cuenta de inmediato

El primer paso al dar de baja a un empleado es suspender la cuenta, no eliminarla. La suspensión corta el acceso al instante mientras conserva los datos y permite transferirlos de forma ordenada. Eliminar la cuenta directamente puede provocar la pérdida de información valiosa.

Revoca sesiones, tokens OAuth y contraseñas de aplicación

Suspender la cuenta no siempre invalida todo el acceso: los tokens OAuth de apps de terceros y las contraseñas de aplicación pueden seguir activos. Revoca explícitamente las sesiones, los tokens y las contraseñas de aplicación para asegurarte de que no queda ningún acceso abierto.

Transfiere la propiedad de los datos

Antes de eliminar la cuenta, transfiere la propiedad del correo, los archivos de Drive y los eventos de calendario a un responsable o a una unidad compartida. La herramienta de transferencia de datos de Google facilita este paso y evita perder información de negocio.

Revisa reglas, delegaciones y dispositivos

Elimina las reglas de reenvío y los filtros, retira las delegaciones de buzón y desvincula o borra remotamente los dispositivos asociados a la cuenta. Por último, aplica la política de retención (con Vault si procede) y libera la licencia.

Antes de tocar nada: decide si hay que conservar evidencia

Si la salida es conflictiva, hay una reclamación abierta o existe sospecha de que el empleado se ha llevado información, el primer paso no es suspender: es congelar el estado. Una retención en Vault sobre el correo y los archivos, aplicada antes de transferir nada, conserva el contenido tal y como está. En cuanto transfieres la propiedad de Drive o borras la cuenta, pierdes información que después no se puede reconstruir.

En ese mismo momento conviene exportar la actividad relevante de la cuenta —inicios de sesión, descargas masivas de Drive, compartición externa reciente— porque los registros de auditoría tienen un plazo de retención propio que no depende de que la cuenta exista. Si la salida es rutinaria, este paso se salta y se va directo a la suspensión.

Cierra el bucle fuera de Google Workspace

La cuenta de Workspace suele ser también la identidad con la que el empleado entraba en media docena de herramientas SaaS por SSO. Suspenderla impide nuevos inicios de sesión federados, pero no cierra por sí sola las sesiones ya abiertas en esas aplicaciones ni los tokens de API que hubiera generado en ellas, y no afecta en absoluto a las que tienen usuario y contraseña propios.

Por eso el offboarding termina fuera de la consola: revisar las aplicaciones federadas una a una, retirar al usuario de los repositorios de código y de la VPN, borrar o retirar sus dispositivos del MDM, cambiar las credenciales compartidas que conociera en el gestor de contraseñas, quitarlo de las unidades compartidas y comprobar si dejó permisos IAM o cuentas de servicio creadas en Google Cloud.

Verifica el orden: qué se rompe si te saltas un paso

La secuencia importa más de lo que parece, porque varios pasos se destruyen entre sí si se hacen en el orden equivocado.

Paso	Si lo haces demasiado pronto	Si lo olvidas
Retención en Vault	Nada, es el primero	Pierdes la evidencia en cuanto transfieres o borras
Suspender la cuenta	Nada, cuanto antes mejor	El acceso sigue abierto
Revocar tokens OAuth y contraseñas de aplicación	Nada	Las apps de terceros siguen leyendo correo y archivos
Transferir Drive, correo y calendario	Si lo haces sin suspender, el usuario sigue modificando	Los datos se pierden al borrar la cuenta
Eliminar reglas, filtros y delegaciones	Nada	El correo se sigue reenviando fuera de la empresa
Retirar el acceso en apps federadas y MDM	Nada	Quedan sesiones vivas fuera de Workspace
Borrar o archivar la cuenta	Antes de transferir, pierdes los datos	Pagas licencia y mantienes viva una identidad

FAQ

¿Debo borrar la cuenta inmediatamente?

No. Lo recomendable es suspenderla primero, transferir los datos y, solo después, borrarla o archivarla según tu política de retención. Borrarla de golpe puede provocar la pérdida de información y de evidencias.

Si la cuenta estaba comprometida, ¿basta con suspenderla?

Suspenderla corta el inicio de sesión, pero debes revisar también los tokens OAuth, las reglas de reenvío y las delegaciones, porque pueden mantener el acceso del atacante de forma independiente a la contraseña.

¿Cuánto tiempo hay que conservar la cuenta suspendida?

El plazo lo marcan vuestra política de retención y las obligaciones legales aplicables, no un criterio técnico. Lo que sí es criterio técnico es el mínimo: no se borra hasta que la transferencia de datos está verificada y no queda ninguna retención de Vault activa sobre esa cuenta. Borrar antes de comprobar la transferencia es el error más caro de este proceso.

¿Puedo reasignar la licencia inmediatamente?

Suspender la cuenta no libera la licencia por sí solo. Algunas ediciones ofrecen licencias de usuario archivado, que conservan los datos con Vault a un coste menor que una licencia completa. Conviene comprobar qué ofrece vuestra edición antes de asumir que el ahorro llega automáticamente al suspender.

¿Qué hacemos si el empleado se fue hace meses y nadie hizo nada de esto?

Es el hallazgo más habitual en una auditoría de Workspace. La forma de abordarlo es inventariar primero: cuentas activas sin actividad reciente, cuentas suspendidas que nunca se cerraron y archivos cuyo propietario ya no está. Sobre ese inventario se revisan tokens, reglas de reenvío y delegaciones antes de transferir la propiedad, y solo después se borran las cuentas.

¿Basta con hacerlo a mano en la consola o conviene automatizarlo?

Con poca rotación, la consola es suficiente si el checklist está escrito y alguien lo firma. A partir de cierto volumen deja de ser realista: la vía razonable es apoyarse en el Admin SDK para que la suspensión, la revocación de tokens y la transferencia se ejecuten siempre igual y queden registradas, en lugar de depender de que la persona de turno se acuerde de los siete pasos.