Los 10 errores de seguridad más comunes en Microsoft 365

Los errores que encontramos en la mayoría de tenants

Tras auditar cientos de tenants de Microsoft 365, estos son los 10 errores de configuración de seguridad más frecuentes. La mayoría son fáciles de corregir pero difíciles de detectar sin una herramienta de auditoría automática.

1. Global Admins sin MFA

El error más crítico y sorprendentemente común. Las cuentas de Global Admin tienen control total sobre el tenant — si una de estas cuentas se compromete, el atacante tiene acceso a todo: email, archivos, configuraciones, datos de usuarios. Tener un Global Admin sin MFA es como dejar la puerta del datacenter abierta.

Solución: MFA obligatorio para todos los roles de admin con un método fuerte (FIDO2 o Microsoft Authenticator, nunca SMS). Reducir el número de Global Admins permanentes a un máximo de 2-4 y usar PIM (Privileged Identity Management) para activaciones Just-In-Time.

2. Demasiados Global Admins permanentes

Microsoft recomienda un máximo de 2-4 Global Admins permanentes. Sin embargo, es habitual encontrar 5, 10 o incluso más. Cada Global Admin permanente es una superficie de ataque adicional.

Solución: Activar Azure AD PIM. Los administradores solicitan la activación del rol cuando lo necesitan (Just-In-Time) y el rol se desactiva automáticamente tras un período definido.

3. Protocolos legacy sin bloquear

POP3, IMAP4, SMTP autenticado y ActiveSync son protocolos que no soportan autenticación moderna ni MFA. Un atacante con credenciales robadas puede usarlos para acceder al buzón de correo sin necesidad de pasar por MFA.

Solución: Crear una política de Conditional Access que bloquee todos los protocolos de autenticación legacy. Verificar que no haya aplicaciones legítimas que dependan de estos protocolos antes de bloquear.

4. Conditional Access en report-only

Las políticas de Conditional Access en modo report-only no bloquean nada — solo generan logs. Es un modo útil durante la fase de pruebas, pero muchas organizaciones olvidan pasarlas a enforcement.

Solución: Revisar todas las políticas en report-only y cambiarlas a enforcement una vez verificado que no afectan a usuarios legítimos.

5. DMARC con p=none

Un registro DMARC con p=none no protege contra el spoofing de email — solo monitoriza. Los emails falsos se siguen entregando al destinatario. Es el equivalente a tener una alarma de seguridad que suena pero no llama a nadie.

Solución: Avanzar progresivamente de p=none a p=quarantine y finalmente a p=reject. Analizar los informes DMARC (rua) durante cada fase para asegurar que el email legítimo no se ve afectado.

6. Aplicaciones OAuth con permisos excesivos

Los usuarios pueden consentir aplicaciones de terceros que solicitan permisos amplios como Mail.ReadWrite o Files.ReadWrite.All. Un atacante puede crear una aplicación maliciosa, hacer phishing para obtener el consentimiento y acceder a datos corporativos sin necesidad de credenciales.

Solución: Restringir el consentimiento de usuarios a aplicaciones verificadas y con permisos de bajo riesgo. Requerir aprobación de administrador para permisos sensibles. Revisar periódicamente las aplicaciones con consentimientos activos.

7. Sin SPF o SPF con demasiados lookups

Organizaciones sin registro SPF, con registros SPF rotos (más de 10 DNS lookups) o con ~all (soft fail) en vez de -all (hard fail). Cualquiera de estas situaciones debilita la protección contra spoofing de email.

Solución: Configurar SPF correctamente, usar mecanismos de aplanamiento (SPF flattening) si tienes muchos includes, y cambiar a -all en producción.

8. Usuarios guest inactivos con acceso a recursos

Los usuarios invitados (guests B2B) que nunca aceptaron la invitación o que llevan más de 90 días inactivos siguen teniendo acceso potencial a recursos compartidos. Son cuentas zombi que amplían la superficie de ataque.

Solución: Implementar revisiones periódicas de acceso guest. Eliminar invitaciones no aceptadas tras 30 días. Revocar acceso a guests inactivos más de 90 días.

9. Secure Score bajo sin seguimiento

Muchas organizaciones ignoran el Microsoft Secure Score o lo revisan una vez y no hacen seguimiento. El Secure Score es la propia evaluación de Microsoft sobre la postura de seguridad del tenant y ofrece recomendaciones priorizadas por impacto.

Solución: Revisar el Secure Score mensualmente. Implementar las recomendaciones de mayor impacto primero. Usar una herramienta como 365toControl para complementar el Secure Score con análisis adicionales que Microsoft no cubre.

10. Sin alertas de seguridad configuradas

El tenant puede estar siendo atacado ahora mismo y nadie lo sabe. Sin alertas configuradas para eventos de seguridad (sign-ins sospechosos, cambios en roles de admin, nuevas apps OAuth, reglas de reenvío de email), los incidentes pasan desapercibidos durante días o semanas.

Solución: Configurar alertas de seguridad en Microsoft 365 Defender para eventos críticos. El plan IT Manager de 365toControl incluye monitorización continua con refrescos diarios y alertas por email cuando se detectan cambios en la postura de seguridad.

Audita tu tenant ahora

Estos 10 errores son solo una muestra de los más de 68 checks que ejecuta 365toControl. Puedes lanzar una auditoría gratuita de tu tenant en menos de 2 minutos para descubrir qué problemas de seguridad tienes y cómo corregirlos.