Cuando termina la relación con una agencia web, un desarrollador freelance o un proveedor tecnológico, eliminar su usuario de WordPress suele ser solo una parte del trabajo. El proveedor puede conservar acceso al dominio, al hosting, a copias de seguridad, al correo transaccional, a repositorios de código o a integraciones que permiten modificar la web o consultar datos operativos.
El problema concreto es retirar esos accesos sin dejar inoperativa una tienda, los formularios, los avisos de pedidos o las renovaciones del dominio. La solución no consiste en revocar todo de golpe: requiere identificar dependencias, asegurar primero el control interno y aplicar un cierre documentado y verificable.
El alcance real de los accesos de un proveedor web
Una web corporativa o un e-commerce depende normalmente de varios servicios conectados. Además del administrador del CMS, pueden existir cuentas en el registrador del dominio, la gestión DNS, el hosting o la nube, una CDN, un firewall de aplicaciones, plataformas de pago, herramientas de email, CRM, analítica, monitorización y sistemas de copia. Cada servicio puede tener usuarios, tokens, claves o mecanismos de recuperación propios.
El primer riesgo de un cierre apresurado es la interrupción: desactivar una cuenta que renueva una credencial de API puede detener el envío de pedidos al ERP; retirar un correo de recuperación puede impedir recuperar una cuenta crítica. El segundo es mantener accesos residuales sin saberlo. OWASP recomienda aplicar mínimo privilegio, revisar permisos periódicamente y denegar el acceso cuando no exista una autorización explícita. [2]
Prepare un inventario antes de revocar ningún acceso
Antes de cambiar contraseñas o eliminar usuarios, reúna un inventario de activos y accesos. Para cada activo, anote el servicio, la URL o identificador, el propietario interno, los administradores, el proveedor con acceso, el uso operativo, el método de recuperación y la fecha prevista de retirada. Este registro permite decidir el orden de los cambios y reduce la dependencia de información dispersa en correos o conversaciones.
Incluya como mínimo el dominio y DNS; hosting, nube, CDN y WAF; WordPress y la tienda; pagos; correo saliente y formularios; CRM y automatizaciones; copias, alertas y monitorización; repositorios; claves SSH; tokens de API; aplicaciones OAuth y webhooks. También conviene registrar sesiones activas y cuentas de servicio, porque no siempre se eliminan al borrar un usuario del CMS.
- Asigne un responsable interno y un suplente para cada activo crítico.
- Distinga entre cuentas de personas, cuentas compartidas, cuentas de servicio y credenciales de integración.
- Marque qué servicios afectan a ventas, atención al cliente, campañas, copias o renovación del dominio.
Asegure propiedad, recuperación y MFA dentro de la empresa
La empresa debe ser propietaria administrativa de sus activos críticos, aunque delegue su operación. Antes de retirar al proveedor, compruebe que al menos dos personas autorizadas de la organización pueden administrar o recuperar las cuentas más sensibles mediante vías separadas. NIST indica mantener las cuentas activas como identidades únicas y registrar los autenticadores asociados; disponer de más de un medio de autenticación reduce la dependencia de un único proceso de recuperación. [1]
Revise los correos y teléfonos de recuperación, las claves de respaldo y los factores de autenticación multifactor. CISA recomienda habilitar MFA donde sea posible, empezando por cuentas administrativas y accesos que manejan información sensible. Si debe sustituirse un factor MFA, hágalo con un procedimiento validado: OWASP advierte que este cambio es una acción de riesgo y recomienda pedir una nueva autenticación con un factor ya registrado y notificarlo por un canal independiente. [3] [4]
Ejecute la retirada por fases y con pruebas operativas
Una secuencia prudente es crear primero cuentas nominales internas, validar que funcionan y después reducir los permisos del proveedor hasta retirarlos. Sustituya las cuentas compartidas por cuentas personales con el rol mínimo necesario. Para credenciales técnicas, planifique una rotación: genere una nueva clave o token, actualice la integración autorizada, compruebe su funcionamiento y solo entonces invalide el elemento anterior.
Ejemplo hipotético: una tienda en WordPress envía pedidos a un ERP mediante una API configurada por su agencia. En lugar de borrar inmediatamente al proveedor, el equipo identifica la credencial usada, crea una nueva bajo control empresarial, actualiza la configuración en un entorno o ventana de cambio acordada y verifica que un pedido de prueba autorizado llega al destino correcto. Tras ello, revoca el token antiguo y el acceso administrativo de la agencia.
- Compruebe el acceso al dominio antes de modificar DNS o hosting.
- Verifique formularios, pagos, pedidos, correos transaccionales y restauración de copias tras cada cambio relevante.
- Cierre sesiones activas cuando el servicio lo permita y retire claves SSH, tokens, OAuth, webhooks y permisos en repositorios.
Documente el cierre y revise los accesos restantes
Registre cada acción de cierre con el activo afectado, la cuenta o credencial retirada, la persona responsable, la fecha, la sustitución aplicada y la prueba realizada. Este registro no sustituye una auditoría completa, pero facilita responder a incidencias y saber qué sigue pendiente. Guarde también instrucciones operativas actualizadas, sin incluir secretos en documentos accesibles de forma indiscriminada.
Tras el cambio, programe una revisión autorizada de cuentas, permisos y registros disponibles para confirmar que no quedan accesos innecesarios. CISA recomienda retirar cuentas que ya no se necesitan, revisar de forma periódica si las cuentas continúan siendo necesarias y aplicar mínimo privilegio. Si el inventario revela configuraciones desconocidas o dependencias críticas, una auditoría de protección web con alcance acordado puede ayudar a priorizar correcciones defensivas sin afectar la operación. [5]
Preguntas frecuentes
¿Basta con eliminar a la agencia como administradora de WordPress?
No necesariamente. Esa acción no revoca por sí sola accesos al hosting, dominio, DNS, copias, repositorios, correo transaccional, cuentas de servicio, tokens de API, aplicaciones OAuth o sesiones activas. Revise cada activo incluido en el inventario antes de dar el cierre por terminado.
¿Debo cambiar todas las contraseñas al finalizar la relación?
Priorice las cuentas críticas y las que hayan sido compartidas o gestionadas por el proveedor. Además de las contraseñas, revise métodos de recuperación, MFA, claves SSH, tokens y permisos de integraciones. El cambio debe hacerse por fases para evitar romper servicios que dependan de una credencial anterior.
¿Qué hago si no sé quién controla el dominio o una integración?
No retire accesos a ciegas. Identifique el registrador, los datos de titularidad, las cuentas de recuperación y los responsables actuales. Para una integración, determine qué sistema la usa, con qué credencial opera y cómo se valida su funcionamiento. Si hay incertidumbre técnica relevante, delimite una revisión autorizada antes de aplicar cambios.