Seguridad de roles de usuario en WordPress: limpie admins

La mayoría de los sitios WordPress tienen más administradores de los que necesitan. Cualquiera de esas cuentas puede instalar un plugin, y instalar un plugin equivale a ejecutar código en su servidor. La seguridad de los roles de usuario en WordPress se resume en un principio, el del mínimo privilegio: cada persona tiene su propia cuenta, con el rol más bajo que le permita hacer su trabajo.

Seguridad de roles de usuario en WordPress: empiece contando administradores

Cuente primero cuántos administradores hay. En el escritorio, vaya a Usuarios > Todos los usuarios y pulse el filtro «Administrador» sobre el listado. Anote el número y los nombres.

Con WP-CLI obtiene la misma lista, con la fecha de registro incluida:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

En una red multisitio, compruebe además quién tiene control sobre toda la red:

wp super-admin list

Para cada cuenta, hágase una pregunta sencilla: ¿sabe decir qué persona real hay detrás y sigue necesitando control total? Si la respuesta no está clara, la cuenta pasa a su lista de revisión. La documentación de los comandos de usuario de WP-CLI recoge todas las opciones que se usan en este artículo.

Los cinco roles por defecto y a quién asignar cada uno

El núcleo de WordPress incluye cinco roles, más el de Superadministrador en multisitio. La página oficial Roles and Capabilities detalla todas las capacidades. En resumen:

Los plugins añaden sus propios roles y capacidades. WooCommerce, por ejemplo, incorpora «Gestor de la tienda» y «Cliente», y un gestor de la tienda puede ver pedidos llenos de datos personales de clientes. Los plugins de SEO, LMS y membresías suelen hacer algo parecido. Revise el filtro de roles de la pantalla Usuarios, busque cualquier rol que no reconozca y consulte en la documentación del plugin qué puede hacer.

Mi recomendación: el trabajo diario con contenidos se hace con una cuenta de Editor. La cuenta de administrador se reserva para actualizaciones y mantenimiento. En un sitio individual, los editores pueden seguir publicando HTML sin filtrar, así que esto no es una barrera de seguridad frente a personas de las que no se fía. Lo que sí consigue es que un acceso de marketing robado mediante phishing ya no pueda instalar plugins.

Cuentas que eliminar o reducir: personal anterior, agencias, accesos compartidos

Casi todos los sitios de pequeñas empresas acumulan los mismos tipos de cuenta:

• Antiguos empleados cuya cuenta nunca se eliminó al marcharse.
• La agencia anterior, que sigue figurando como administradora años después de acabar el contrato.
• Un autónomo de un proyecto puntual, como un rediseño o la migración de una tienda.
• Un acceso compartido «oficina» o «info» que usan varias personas.
• El usuario «admin» de la instalación original.

Los accesos compartidos son los más difíciles de justificar. Si cinco personas usan una cuenta, no hay forma de saber quién cambió un ajuste o exportó datos de clientes. Y tampoco puede cortar el acceso a una sola persona sin cambiar la contraseña de todas. Cada persona debe tener su propia cuenta nominal.

Las agencias deben trabajar igual. Cada miembro del equipo, una cuenta con nombre, y todas se eliminan el día en que termina el contrato. Si una agencia tiene acceso de administrador a un sitio con datos personales, normalmente actúa como encargada del tratamiento conforme al art. 28 del RGPD. Su acceso debe quedar reflejado en la documentación que conserve junto al contrato de encargo. Sobre la parte de evidencias, véase qué conservar en un informe de auditoría de seguridad.

El nombre de usuario «admin» no se puede cambiar desde el escritorio: WordPress muestra «Los nombres de usuario no se pueden cambiar» en la pantalla de perfil. Cree en su lugar un nuevo administrador con un nombre personal:

wp user create jane.doe jane@example.com --role=administrator

Inicie sesión con el nuevo usuario, elimine después la cuenta «admin» antigua y reasigne su contenido, como se explica en el apartado siguiente.

Eliminar con seguridad: reasigne el contenido y conserve un administrador operativo

wp user delete 7 --reassign=2

Para reducir el rol en lugar de eliminar la cuenta, por ejemplo con un empleado que sigue escribiendo artículos:

wp user set-role mark.writer editor

Reducir el rol suele ser un primer paso más prudente. Si en dos semanas nadie se queja, elimine la cuenta.

Contraseñas de aplicación: los accesos que sobreviven a un cambio de contraseña

Las contraseñas de aplicación forman parte del núcleo desde WordPress 5.6. Permiten que aplicaciones e integraciones, como una app móvil, una herramienta de informes o un servicio de automatización, se autentiquen en la API REST. El problema es que siguen funcionando aunque se cambie la contraseña principal del usuario. Si restablece la contraseña de una agencia anterior pero deja su contraseña de aplicación, esa agencia conserva el acceso.

Revíselas para cada administrador: vaya a Usuarios > Todos los usuarios, edite el usuario y desplácese hasta Contraseñas de aplicación. Con WP-CLI:

wp user application-password list jane.doe

La lista muestra cuándo se creó cada contraseña y cuándo se usó por última vez. Revoque todo lo que no pueda asociar a una integración actual:

wp user application-password delete jane.doe <uuid>

Ponga a cada nueva contraseña de aplicación el nombre de la integración que la usa, por ejemplo «Zapier – exportación de pedidos», para que la siguiente revisión sea rápida. Si nadie en el sitio usa esta función, muchos plugins de seguridad y algunos hostings permiten desactivarla por completo.

Administradores ocultos tras un ataque: cómo detectarlos

Los atacantes que consiguen entrar a veces crean su propio administrador y lo ocultan con código que filtra la consulta de usuarios. Entonces la cuenta no aparece en Usuarios y puede que tampoco en wp user list, porque WP-CLI carga los mismos plugins. Una consulta directa a la base de datos se salta ese código:

wp db query "SELECT u.ID, u.user_login, u.user_email, u.user_registered FROM wp_users u JOIN wp_usermeta m ON m.user_id = u.ID WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%'"

El prefijo wp_ es solo el valor por defecto. Ejecute antes wp db prefix y sustituya wp_ en los dos nombres de tabla y en la clave meta. Si su prefijo es xy7_, la clave es xy7_capabilities. En multisitio, cada sitio tiene su propia clave, como wp_2_capabilities.

Compare el resultado con el número que muestra el escritorio. Después busque fechas de user_registered recientes y dominios de correo que no correspondan a nadie con quien trabaje. Un administrador oculto o sin explicación es señal de compromiso, no una tarea de limpieza. No lo elimine sin más. Siga los pasos de señales de que su sitio WordPress ha sido hackeado.

El análisis de indicadores de compromiso del plugin de secaudit.eu busca administradores ocultos como parte de su auditoría.

Revisión trimestral de accesos como evidencia para NIS2 y RGPD

Una revisión lleva unos 15 minutos. Hágala cada trimestre y también cada vez que alguien se marche o cambie un contrato con una agencia:

• Exporte la lista de administradores (y de Superadministradores en multisitio).
• Confirme la persona y el rol de cada cuenta. Reduzca o elimine el resto.
• Compruebe los roles añadidos por plugins, como Gestor de la tienda.
• Liste y depure las contraseñas de aplicación de cada administrador.
• Confirme que todos los administradores usan autenticación en dos pasos.
• Confirme que el editor de archivos del escritorio está desactivado.
• Anote la fecha, quién hizo la revisión y qué cambió.

Ese último registro es lo que convierte un hábito en evidencia. El art. 21, apartado 2, letra i), de la Directiva NIS2 incluye la seguridad de los recursos humanos, la política de control de acceso y la gestión de activos entre las medidas mínimas (Directiva (UE) 2022/2555). Las obligaciones concretas proceden de la transposición de cada país, así que consulte la norma nacional de transposición de NIS2 que le corresponda. En el RGPD, el control de acceso forma parte de las «medidas técnicas y organizativas apropiadas» del art. 32, y el art. 5, apartado 2, exige poder demostrarlo (Reglamento (UE) 2016/679).

Una limitación que conviene tener presente: el núcleo de WordPress no registra cuándo inició sesión un usuario por última vez. Para detectar cuentas inactivas necesita un plugin de registro de actividad o los registros de acceso del servidor. De lo contrario, tendrá que preguntar directamente a las personas.

El plugin Security Audit & Compliance de secaudit.eu ayuda con la parte recurrente. Señala administradores ocultos, contraseñas débiles o por defecto y carencias de refuerzo como un editor de archivos activado, relaciona los hallazgos con el art. 32 del RGPD y el art. 21 de NIS2, y exporta un informe que puede archivar junto a sus notas de revisión.

Preguntas frecuentes

¿Basta con cambiar el nombre de usuario «admin» para frenar ataques?

No. Elimina una suposición fácil, pero los nombres de usuario suelen poder averiguarse de otras formas. Contraseñas robustas y únicas y la autenticación en dos pasos hacen mucho más.

¿Puede una agencia compartir un único acceso de administrador entre su equipo?

No. Cada persona necesita una cuenta con su nombre, para saber quién hizo qué y poder retirar el acceso de una persona sin afectar a las demás.

¿Qué pasa con los pedidos de WooCommerce o las entradas si elimino un usuario?

Las entradas y páginas se borran si no las reasigna. Cada plugin guarda sus propios datos a su manera, así que consulte su documentación antes de eliminar cuentas de clientes o de personal de la tienda. Si tiene dudas, reduzca primero el rol de la cuenta.

Este artículo es información general y no constituye asesoramiento jurídico.