La auditoría y políticas de contraseñas no consisten solo en exigir claves complejas: permiten detectar cuentas expuestas, reutilizadas, compartidas o sin uso y transformarlas en controles medibles. Facilitan la revisión de WordPress, Microsoft 365, Active Directory y SaaS, la aplicación de criterios NIST, MFA y mínimo privilegio, la asignación de responsables, la conservación de evidencias y la medición de la corrección de riesgos.
Resumen del proceso para revisar y corregir accesos
Una revisión eficaz sigue un orden: primero se localizan las cuentas y sus responsables; después se cierran los riesgos urgentes y, por último, se establecen reglas comprobables cada mes.
- Inventaría sistemas y cuentas: anota WordPress, hosting, correo, DNS, copias de seguridad, Microsoft 365, Active Directory y cada SaaS que pueda afectar al negocio.
- Clasifica el riesgo: marca cuentas de administrador, sin MFA, compartidas, inactivas, predeterminadas o vinculadas a personas que ya no trabajan contigo.
- Corrige lo crítico: revoca accesos sin dueño, cambia credenciales expuestas y activa MFA en correo, hosting y cuentas privilegiadas.
- Aprueba una política: define longitud, gestor, MFA, excepciones, responsables, plazos y pruebas que guardar.
- Mide y repite: revisa cada mes los accesos privilegiados y cada trimestre el inventario completo.
Una cuenta de correo corporativo sin MFA suele ser más crítica que un usuario WordPress básico: con el correo se pueden restablecer contraseñas de casi todos los demás servicios.
Paso 1: inventarie cuentas, roles y credenciales expuestas
Una auditoría debe incluir toda cuenta capaz de publicar, recuperar contraseñas, modificar DNS o leer datos personales.
Sistemas que deben entrar en el inventario
Crea una hoja con sistema, URL, propietario, tipo de cuenta, rol, fecha del último acceso, MFA y fecha de revisión. Incluye WordPress, panel de hosting, SFTP o SSH, base de datos, DNS, CDN, cuentas de copias de seguridad, correo, Microsoft 365 y herramientas como facturación, CRM o envío de newsletters.
Marca como crítico un administrador sin autenticación multifactor, una clave vista en una filtración, una cuenta compartida o un acceso de un ex empleado. También requieren prioridad una contraseña predeterminada, una cuenta sin propietario o una credencial que permite entrar al correo o al DNS.
Checklist de revisión de cuentas
- Contraseñas filtradas: comprueba alertas del proveedor de identidad o un servicio de detección de brechas sin enviar claves en texto plano.
- Claves reutilizadas: pregunta y valida el uso de gestor, sin pedir a nadie que revele su contraseña.
- Credenciales predeterminadas: revisa routers, hosting, plugins, cuentas de base de datos y software recién instalado.
- Cuentas compartidas: sustituye “admin”, “marketing” o “soporte” por cuentas individuales.
- Cuentas inactivas: revisa accesos sin uso durante entre 60 y 90 días, según la función.
- Privilegios excesivos: comprueba si un administrador necesita realmente administrar usuarios, DNS o plugins.
Las cuentas huérfanas no siempre pertenecen a un ex empleado visible. También pueden ser buzones creados para proyectos, usuarios de proveedores, cuentas técnicas de integración, identidades usadas por scripts o credenciales de aplicaciones cuyo responsable ya no trabaja en la empresa. Para localizarlas, compara el inventario de accesos con las bajas comunicadas por recursos humanos, revisa el último inicio de sesión, identifica al propietario de cada aplicación y analiza los logs de acceso.
Si una cuenta técnica sigue siendo necesaria, asígnale un dueño de negocio y otro técnico, limita sus permisos y fija una revisión periódica; si no, desactívala y revoca sus sesiones, tokens y claves asociadas.
En WordPress, la auditoría de contraseñas debe complementarse con una revisión de vulnerabilidades y de las vías que permiten obtener o reutilizar credenciales. Comprueba que el núcleo, los temas y los plugins estén actualizados y elimina los componentes desactivados que ya no se usan, porque también pueden contener fallos conocidos. Revisa los usuarios con rol de administrador, las contraseñas de aplicación, las claves SFTP, las cuentas de hosting y los registros de actividad para detectar cambios no autorizados.
Si XML-RPC, el acceso REST o la página de inicio de sesión reciben intentos anómalos, aplica rate limiting, MFA y restricciones adecuadas sin impedir los procesos legítimos de integración.
Paso 2: cierre riesgos con MFA y mínimo privilegio
Corrige primero las cuentas con alto privilegio y alta exposición, sin bloquear la actividad del equipo.
Orden de corrección según el riesgo
Prioriza administradores de correo, Microsoft 365, hosting, DNS y WordPress sin MFA. Después, elimina cuentas de antiguos empleados, proveedores sin fecha de fin, accesos compartidos y credenciales de aplicaciones sin propietario.
| Hallazgo | Plazo aconsejado | Medida de cierre |
|---|
| Administrador sin MFA | Menos de 24 horas | Activar MFA y validar recuperación |
| Cuenta de ex empleado | Menos de 24 horas | Bloquear, revocar sesiones y reasignar recursos |
| Contraseña antigua sin alerta | Entre 7 y 30 días | Validar unicidad y guardar en gestor |
| Usuario inactivo básico | Entre 30 y 90 días | Confirmar necesidad o desactivar |
MFA, SSO y protección frente a fuerza bruta
Frenar fuerza bruta sin castigar usuarios
La protección contra fuerza bruta limita intentos repetidos de adivinar una clave. Usa rate limiting, una reducción gradual de los intentos permitidos, CAPTCHA adaptativo y alertas antes de aplicar bloqueos rígidos tras dos o tres fallos.
El SSO reduce el número de contraseñas que cada persona debe gestionar al permitir que Microsoft 365, Active Directory o un proveedor de identidad central autentiquen el acceso a las herramientas SaaS compatibles. Su valor principal es operativo: al dar de baja a una persona en el directorio, se puede revocar su acceso a varios servicios de forma coordinada, aplicar MFA desde un único punto y conservar registros de autenticación homogéneos.
No obstante, deben revisarse las cuentas locales que quedan fuera del SSO, las cuentas de administrador de emergencia o break-glass y las integraciones de servicio. Estas identidades necesitan dueño, mínimo privilegio, una credencial única y pruebas periódicas de recuperación.
Paso 3: convierta los hallazgos en una política NIST
Una política útil fija reglas que el personal, los proveedores y el responsable técnico pueden seguir y demostrar.
Reglas que conviene aprobar por escrito
Define una longitud mínima de entre 14 y 16 caracteres cuando el sistema lo permita, con frases de paso o claves generadas por un gestor. No obligues a símbolos concretos si eso empuja a patrones repetidos; una frase larga y única suele resistir mejor que una clave corta llena de signos.
Plantilla editable de política interna
Copia este modelo en tu documento interno y completa los campos entre corchetes:
Política de credenciales de [Empresa]
Alcance: WordPress, hosting, correo, Microsoft 365, Active Directory, SaaS, DNS y accesos de proveedores.
Responsable de aprobación: [Dirección]. Responsable técnico: [Nombre o proveedor].
Reglas: cuentas individuales, claves únicas de al menos [14/16] caracteres, uso obligatorio de gestor, MFA en cuentas privilegiadas y revisión de permisos.
Cambios de clave: solo por exposición, incidente, cambio de rol, baja o requisito documentado.
Excepciones: requieren motivo, control compensatorio, fecha de caducidad y aprobación de [Responsable].
Evidencias: inventario, logs de acceso, revisiones, altas, bajas y cierres de hallazgos.
Incumplimiento: retirada temporal de acceso y revisión por [Responsable].
Revisión de la política: cada [12] meses o tras un incidente relevante.
Flujo visual de revisión y evidencia
1. Inventario
Cuenta, dueño y rol
→
2. Riesgo
MFA, actividad y exposición
→
3. Corrección
Revocar o reforzar
→
4. Evidencia
Fecha, dueño y prueba
Errores que impiden controlar las credenciales
Una política falla cuando se queda en una regla de complejidad y no asigna quién revisa cuentas, aprueba excepciones y cierra riesgos. Instalar un plugin de seguridad puede ayudar a limitar ataques, pero no sabe si “[email protected]” pertenece a un proveedor que dejó de trabajar contigo.
Cambiar claves cada pocos meses sin señal
Forzar un cambio cada 30, 60 o 90 días suele crear patrones previsibles. Es como pedir cambiar el candado de una taquilla con tanta frecuencia que todos acaban dejando una nota para recordar el código.
Compartir cuentas de administrador
Una cuenta compartida impide atribuir una acción concreta en los logs de acceso. Crea usuarios individuales, da el rol mínimo y fija una fecha de retirada para agencias, desarrolladores o soporte externo.
Ignorar evidencias y cuentas externas
Guarda pruebas de alta, baja, activación de MFA, revisión de roles y cierre de hallazgos. El RGPD y la LOPDGDD exigen tratar estos registros con acceso limitado y un plazo de conservación justificado, porque pueden contener datos personales.
No apliques esta guía por tu cuenta si hay un incidente activo, señales de acceso comprometido, obligaciones regulatorias concretas o una infraestructura compleja con directorio corporativo. En esos casos hace falta respuesta a incidentes y una revisión especializada. Para una web personal sin usuarios, datos sensibles ni paneles compartidos, no es una prioridad formal, aunque conviene mantener claves únicas y MFA.
Preguntas y respuestas
¿Qué es una auditoría de contraseñas?
Es una revisión de cuentas, permisos, MFA, actividad y exposición de credenciales en todos los sistemas relevantes. Debe identificar al menos claves filtradas, accesos compartidos, cuentas inactivas y privilegios excesivos.
¿Cada cuánto se deben cambiar las contraseñas?
Deben cambiarse ante filtración, sospecha de phishing, cambio de rol, baja o incidente. La caducidad cada entre 30 y 90 días no es recomendable por defecto si no existe una obligación concreta.
¿Qué longitud debe tener una contraseña segura?
Una frase de paso o clave generada de entre 14 y 20 caracteres ofrece una base práctica para la mayoría de cuentas corporativas. Debe ser única y guardarse en un gestor, nunca reutilizarse entre correo, WordPress y SaaS.
¿WordPress guarda mis contraseñas en texto plano?
No, WordPress guarda hashes, no la contraseña legible, y usa salts para reforzar ese proceso. Aun así, una clave reutilizada puede estar expuesta por una brecha en otro servicio.
¿Es obligatorio usar MFA en WordPress?
No siempre es una obligación legal directa, pero debe exigirse para administradores y para cualquier cuenta con acceso a datos o ajustes críticos. Para hosting, correo, DNS y Microsoft 365, MFA es una medida prioritaria.
¿Puedo compartir una cuenta de administrador?
No conviene compartirla porque elimina trazabilidad y complica la revocación. Crea una cuenta individual con el permiso mínimo y una fecha de revisión o fin de acceso.
¿Qué indicadores demuestran que la política funciona?
Mide cobertura de MFA, porcentaje de cuentas privilegiadas revisadas, credenciales expuestas corregidas y tiempo medio de cierre. Un objetivo razonable es revisar el 100% de administradores cada mes y cerrar riesgos críticos en menos de 24 horas.
¿Qué plugins ayudan a aplicar estas reglas en WordPress?
Un plugin de MFA y otro de registro de actividad pueden reforzar WordPress si están actualizados y configurados. No sustituyen el inventario, las cuentas individuales ni la revisión de hosting, correo y proveedores.
Mantenga una revisión mensual con dueños y pruebas
La forma más fiable de proteger accesos es unir revisión mensual de administradores, MFA obligatorio y cierre documentado de cada hallazgo. Una política de contraseñas deja de ser un PDF olvidado cuando cada sistema tiene propietario, cada excepción caduca y cada baja se puede demostrar.
La seguridad WordPress no depende de una clave perfecta. Depende de saber quién entra, por qué puede entrar y cuándo debe dejar de hacerlo.
