Audita los accesos de WordPress antes de que una cuenta antigua cause un problema nuevo

Una auditoría de acceso a WordPress debe responder a dos preguntas: quién puede modificar el sitio y qué herramientas externas pueden actuar mediante esas cuentas. Una lista de empleados solo responde a la primera. Una credencial antigua de integración puede seguir siendo relevante después de que su creador haya dejado de iniciar sesión.

Empieza con una copia recuperable del sitio y una cuenta de administrador confirmada bajo control del propietario. Después revisa los usuarios identificados, sus capacidades reales y sus contraseñas de aplicación. Esta guía presupone una instalación estándar de WordPress de un solo sitio. Multisite, los productos de membresía y los plugins de roles pueden alterar el modelo: comprueba los permisos de la instalación, no tomes el nombre del rol como prueba.

Parte de una tarea, no del rol más cómodo

La documentación de roles y capacidades de WordPress describe los grupos de permisos predeterminados. Un Colaborador puede escribir y gestionar sus entradas, pero no publicarlas; un Autor puede publicar sus propias entradas; un Editor puede gestionar las de otras personas. Un Administrador tiene facultades más amplias sobre el sitio. La diferencia importa cuando un colaborador externo solo necesita entregar un borrador.

Para cada cuenta, escribe una frase que describa el trabajo actual. «Sube el informe semanal para revisión editorial» es más útil que «marketing». Compara esa tarea con las acciones que permite la cuenta. Cuando los roles estándar no encajen, define la necesidad antes de instalar o cambiar un plugin y prueba las capacidades resultantes, en lugar de confiar en el nombre mostrado.

No compartas una cuenta de administrador para evitar crear otro usuario. Una cuenta individual permite retirar el acceso de una persona sin tener que distribuir deliberadamente una contraseña nueva al resto. Mantén una vía de recuperación controlada por el propietario para que despedir a una agencia o proveedor no elimine también a la única persona capaz de administrar la web.

Prueba el rol con menos privilegios mediante tareas representativas: guardar un borrador, subir los archivos necesarios, editar el contenido previsto e intentar una acción que debería estar prohibida. Un Colaborador estándar no puede subir archivos, por lo que un flujo que requiere imágenes necesita un ajuste deliberado. Resuelve esa necesidad concreta, no todas las solicitudes futuras concediendo administración.

Registra las contraseñas de aplicación como credenciales separadas

La guía de autenticación de la API REST describe contraseñas de aplicación para acceder de forma autenticada a la API mediante HTTPS. Son distintas de la contraseña habitual del usuario. Su utilidad operativa es que cada integración puede tener una credencial propia sin recibir la contraseña cotidiana de la persona.

Registra qué cuenta es propietaria de cada credencial, qué servicio la usa, quién mantiene ese servicio y si la conexión sigue siendo necesaria. Un nombre descriptivo ayuda a identificar el propósito, pero no restringe por sí mismo las peticiones que puede realizar. Ajusta los permisos de la cuenta de servicio al trabajo que ejecuta la integración.

La guía de integración de contraseñas de aplicación explica su gestión y revocación. Utiliza una credencial diferente para cada conexión, de modo que retirar una herramienta no obligue a romper las demás integraciones del usuario. No pegues contraseñas de aplicación en una hoja de auditoría, un correo de soporte o una incidencia pública: registra al responsable y el propósito, no el secreto.

Cuando desconozcas quién responde por una integración, investiga antes de borrarla a ciegas. Identifica la publicación, copia de seguridad o sincronización relacionada y localiza al responsable. Desconocido no significa inocuo, pero tampoco significa sin uso. La auditoría debe convertir la incertidumbre en una decisión explícita de conservar, sustituir o revocar.

Revoca el acceso siguiendo una secuencia controlada

Ante una salida planificada, identifica primero qué debe continuar: publicaciones programadas, propiedad del contenido, gestión de archivos e integraciones. Transfiere la responsabilidad operativa y crea las credenciales sustitutas mediante la cuenta autorizada. Confirma que funcionan antes de retirar una credencial necesaria para un servicio que debe seguir activo.

Si sospechas una intrusión, prioriza la contención y sigue el procedimiento de incidentes en lugar de esperar a un traspaso rutinario. Esta guía es una revisión de accesos, no una garantía de respuesta a incidentes. Conserva los registros pertinentes e involucra al administrador o especialista de seguridad cuando la situación exija más que una limpieza ordinaria de cuentas.

En una limpieza normal, revoca la contraseña de aplicación elegida, confirma que la conexión antigua ya no se autentica y comprueba que las integraciones no relacionadas funcionan. Después reduce o elimina el acceso interactivo de la persona según corresponda. Pulsar un botón no verifica la revocación: las pruebas útiles son la petición denegada prevista y el proceso independiente que sigue operativo.

Antes de eliminar un usuario, revisa cómo afectará a sus contenidos y a su autoría y elige expresamente cualquier reasignación necesaria. No conviertas una limpieza de acceso en un borrado editorial accidental. Los principios de nuestra guía de staging y reversión en WordPress ayudan cuando interviene un plugin de roles u otro cambio de configuración.

Mantén un registro lo bastante pequeño como para actualizarlo

Conserva una entrada por usuario y otra vinculada por integración: propósito, responsable, rol o capacidades, fecha de revisión y decisión. Guarda los secretos en el sistema de gestión de credenciales aprobado por el equipo, no junto al inventario legible. El registro debe ayudar a un sucesor a entender el sitio sin entregarle por defecto todos los secretos.

Define una revisión obligatoria cuando termine un contrato, cambien las funciones de alguien o se retire una herramienta. Una revisión periódica puede detectar omisiones, pero una baja no debe esperar al próximo recordatorio. Incorpora el proceso a la rutina de mantenimiento del sitio y asigna una persona responsable de completarlo.

Al terminar, prueba ambos lados del cambio. El editor que conserva acceso debe poder realizar su trabajo; la cuenta o credencial retirada debe fallar en la acción que ya no tiene autorizada. Documenta la prueba y su resultado sin afirmar que eso demuestra la seguridad de toda la web.

Una auditoría útil termina con menos privilegios sin explicar, no necesariamente con menos cuentas. Las cuentas individuales con un propósito definido pueden ser más fáciles de gestionar que unas pocas cuentas de administrador compartidas. El objetivo es justificar cada permiso activo y demostrar que cada permiso retirado ha desaparecido.