Cómo auditar administradores y permisos en una cartera WordPress

Respuesta corta: para auditar administradores y permisos en una cartera WordPress no basta con contar usuarios con el rol «Administrador». Hay que comprobar, sitio por sitio, quién conserva acceso, para qué lo necesita, qué credenciales de aplicación siguen activas y si el nivel de privilegio coincide con una responsabilidad vigente. El resultado útil es una lista de decisiones con propietario y fecha: mantener, reducir, suspender o eliminar.

Este proceso está pensado para agencias, freelancers y equipos de mantenimiento que gestionan varios WordPress. No demuestra que una cuenta sea legítima ni sustituye una investigación forense; reduce accesos innecesarios y deja evidencia para detectar excepciones.

El problema no es tener varios administradores, sino no poder justificarlos

WordPress separa roles y capacidades: un rol agrupa permisos, mientras que las capacidades determinan qué puede hacer realmente un usuario. La documentación oficial de WordPress pone un ejemplo relevante: un Administrador dispone de manage_options, una capacidad que un Editor no tiene. Por eso dos cuentas activas no representan el mismo riesgo si una solo publica contenido y la otra puede cambiar opciones, instalar extensiones o gestionar usuarios.

OWASP recomienda aplicar mínimo privilegio y revisar periódicamente los permisos para detectar privilege creep: accesos que se acumulan cuando cambian proyectos, equipos o responsabilidades. Esa recomendación es la evidencia general. La frecuencia, el formato y los umbrales concretos que proponemos a continuación son criterio editorial para operar una cartera WordPress.

Qué debe cubrir el inventario de acceso

Una exportación de usuarios por sí sola se queda corta. Para cada sitio, la agencia necesita relacionar identidad, privilegio, motivo y vigencia.

Campo	Pregunta que resuelve	Señal de revisión
Sitio y entorno	¿Dónde existe el acceso?	Cuenta administrativa en producción sin necesidad equivalente en staging.
Usuario e identidad real	¿A qué persona o servicio pertenece?	Alias compartido, correo genérico o propietario desconocido.
Rol y capacidades relevantes	¿Qué puede hacer de verdad?	El rol nominal parece limitado, pero un plugin añadió capacidades elevadas.
Responsable y motivo	¿Quién aprueba que siga activo?	No existe cliente, empleado o proveedor que lo justifique.
Último uso observado	¿Hay actividad reciente y explicable?	Uso inesperado o ausencia prolongada sin política de retención.
Credenciales asociadas	¿Hay contraseñas de aplicación o integraciones?	Credencial revocable sin aplicación, propietario o fecha reconocible.
Decisión y vencimiento	¿Qué ocurrirá y cuándo se revisará?	Excepción permanente sin fecha ni propietario.

WordPress permite crear contraseñas de aplicación revocables y específicas por integración. No comparten necesariamente el ciclo de vida de la contraseña principal, así que deben formar parte de la revisión. Una cuenta humana aparentemente correcta puede conservar además credenciales programáticas que nadie recuerda.

Un flujo de auditoría en seis pasos

1. Define el denominador antes de buscar anomalías

Empieza por la lista completa de sitios dentro del servicio, incluidos entornos que sigan accesibles. Si se revisan 38 webs de una cartera de 42, el resultado no es «sin problemas»: es 38 revisadas y 4 con cobertura desconocida. Esta distinción evita que una web olvidada parezca una web segura.

2. Extrae usuarios, roles y credenciales por sitio

Recoge usuarios activos, roles asignados y, cuando el proceso lo permita, capacidades relevantes añadidas por plugins o código propio. Incluye cuentas de agencia, cliente, hosting, proveedores externos, automatizaciones e integraciones. La pantalla Usuarios de WordPress permite buscar, cambiar y eliminar usuarios; para una cartera grande hará falta consolidar esa información fuera de cada panel.

3. Une la cuenta con una identidad y una necesidad actuales

No deduzcas el propietario por el nombre de usuario. Confirma persona, empresa o sistema, y registra quién autoriza el acceso. Pregunta qué tarea requiere privilegios elevados. «Siempre ha estado ahí» no es una justificación operativa.

4. Clasifica la decisión, no solo el hallazgo

Decisión	Cuándo encaja	Verificación mínima
Mantener	Identidad, tarea y nivel de acceso están vigentes.	Responsable y fecha de próxima revisión registrados.
Reducir	La persona necesita entrar, pero no administrar el sitio.	La tarea habitual sigue funcionando con el rol menor.
Suspender	Hay duda razonable o una ausencia temporal.	Acceso bloqueado de forma reversible y propietario contactado.
Eliminar	La relación terminó o la cuenta carece de justificación.	Contenido reasignado cuando corresponda y acceso revocado.
Investigar	Uso, identidad o cambios recientes no cuadran.	Evidencia preservada antes de modificar o borrar la cuenta.

Criterio editorial: ante una cuenta dudosa no siempre conviene borrarla de inmediato. Si puede estar vinculada a un incidente, primero conserva los datos necesarios para analizar actividad, alcance y cambios. La reversibilidad y la evidencia pesan más que la rapidez cosmética.

5. Ejecuta cambios por lotes pequeños

Reduce o revoca accesos en grupos controlados, empezando por cuentas claramente caducadas y privilegios innecesarios. Comprueba después que publicación, soporte, integraciones y mantenimiento siguen funcionando. Un cambio masivo sin validación puede convertir una mejora de seguridad en una interrupción operativa.

6. Cierra con evidencia y riesgo residual

La auditoría termina cuando cada excepción tiene propietario, motivo y vencimiento; los cambios están verificados; y los sitios no revisados quedan visibles. «Lista exportada» no es un cierre. Una salida defendible muestra cobertura, decisiones y dudas pendientes.

Cómo priorizar cuando aparecen demasiadas cuentas

Revisar primero por antigüedad puede dejar para el final las cuentas más peligrosas. Una secuencia más útil combina privilegio, exposición y contexto:

1. Cuentas administrativas sin propietario o con direcciones genéricas que nadie reconoce.
2. Accesos de proveedores y empleados que ya no participan en el servicio.
3. Cuentas compartidas, porque impiden atribuir acciones a una identidad concreta.
4. Administradores con actividad inesperada o coincidente con cambios sensibles.
5. Contraseñas de aplicación e integraciones sin nombre, responsable o uso vigente.
6. Privilegios excesivos pero legítimos, que pueden reducirse con una prueba controlada.

La inactividad es una señal, no una sentencia. Una cuenta de emergencia puede usarse poco y seguir siendo necesaria; una cuenta comprometida puede mostrar actividad reciente. La decisión necesita contexto.

Qué automatizar y qué no delegar a una regla

Es razonable automatizar el inventario, la comparación entre revisiones y la detección de cambios: cuentas nuevas, roles elevados, sitios que no respondieron y excepciones vencidas. También conviene centralizar alertas y responsables para no depender de revisar cada panel por separado.

La aprobación final de un acceso sigue necesitando contexto humano: relación contractual, tarea real, criticidad del sitio y consecuencias de retirar permisos. Una herramienta puede mostrar que una cuenta existe; no puede demostrar por sí sola que todavía debe existir.

Si la cartera ya genera señales dispersas, Vulnity ayuda a centralizar la supervisión de seguridad WordPress y la respuesta operativa. En este flujo, su valor está en reducir puntos ciegos y relacionar cambios o alertas con una cartera, no en decidir automáticamente quién merece permisos.

Checklist de cierre

• La lista de sitios revisados coincide con el alcance contratado.
• Cada administrador tiene identidad, propietario y motivo vigentes.
• Las capacidades elevadas y roles personalizados están contemplados.
• Las contraseñas de aplicación e integraciones tienen responsable.
• Las bajas se ejecutaron sin perder contenido ni evidencia necesaria.
• Los privilegios reducidos se probaron con tareas reales.
• Las excepciones incluyen aprobación y fecha de vencimiento.
• Los sitios sin datos aparecen como cobertura desconocida, no como correctos.
• La siguiente revisión tiene fecha y responsable.

Limitaciones que deben quedar por escrito

Esta auditoría describe el estado observado, no prueba que una cuenta nunca se haya compartido o comprometido. Los roles personalizados pueden ocultar capacidades que el nombre del rol no revela. La última actividad puede ser incompleta si el sitio no conserva registros suficientes. Revocar una cuenta tampoco elimina sesiones, tokens o accesos externos si no se revisan de forma específica.

Vulnity no detecta CVEs ni identifica plugins, temas o versiones de WordPress vulnerables. Tampoco sustituye un proveedor de identidad, un gestor de secretos, un WAF, un escáner de malware, las copias de seguridad o la investigación forense.

Fuentes y criterio editorial

• Evidencia primaria: WordPress documenta la separación entre roles y capacidades, la gestión de usuarios y las contraseñas de aplicación revocables.
• Evidencia primaria: la Authorization Cheat Sheet de OWASP recomienda mínimo privilegio y revisiones periódicas para detectar acumulación de permisos.
• Evidencia primaria: NIST SP 800-53 Rev. 5, actualización 1 incluye controles de gestión de cuentas y mínimo privilegio.
• Propuesta editorial: el flujo inventario → identidad → necesidad → decisión → cambio → evidencia, las prioridades y la tabla de cierre son un modelo operativo adaptable; no son umbrales obligatorios de WordPress, OWASP o NIST.

Continuar el flujo

La revisión de permisos encaja con tres controles ya documentados: gobernar el acceso remoto de administradores, vigilar accesos sospechosos entre sitios y cerrar alertas con evidencia.

Si gestionas varios WordPress, prueba Vulnity para centralizar señales y reducir puntos ciegos operativos. La herramienta debe apoyar la revisión; la agencia conserva la decisión sobre acceso y riesgo.