Hardening de Microsoft 365: checklist de seguridad para empresas

Por Kike Gandia · Co-Fundador y CEO, OSCP

La configuración por defecto de Microsoft 365 prioriza la facilidad de uso. Este checklist, alineado con el CIS Microsoft 365 Benchmark, recorre los ajustes que más reducen tu superficie de ataque, ordenados por impacto. Empieza por la identidad: Entra ID es donde un atacante busca primero.

Protege y limita los administradores globales

Reduce el número de administradores globales al mínimo imprescindible y protégelos con MFA resistente al phishing. Usa Privileged Identity Management (PIM) para conceder los roles privilegiados solo cuando se necesitan (just-in-time) y mantén cuentas de administración separadas de las de uso diario.

Impón MFA resistente al phishing y acceso condicional

Activa MFA para todos los usuarios y, en las cuentas críticas, exige métodos resistentes al phishing (FIDO2, passkeys, Windows Hello). Define políticas de acceso condicional que bloqueen la autenticación heredada (legacy auth), restrinjan por dispositivo y ubicación y cubran a todos los usuarios sin huecos.

Controla el consentimiento de apps OAuth

Desactiva el consentimiento de usuario para apps no verificadas y exige aprobación del administrador para los permisos sensibles. Revisa las app registrations y los service principals existentes y sus permisos: el consentimiento ilícito es uno de los vectores más usados contra Microsoft 365.

Asegura Exchange, SharePoint y los registros

En Exchange Online, desactiva el reenvío automático externo y revisa los permisos de buzón. En SharePoint y OneDrive, restringe la compartición externa y los enlaces anónimos. Activa el Unified Audit Log, configura alertas y, si tienes Defender y Purview, aplica DLP y retención.

Bloquea la autenticación heredada y comprueba que no queda nadie usándola

Bloquear la autenticación heredada es una sola política de acceso condicional, pero es también el paso que más operativa rompe si se activa a ciegas: suele haber una impresora multifunción que envía por SMTP, un escáner, una aplicación antigua o un buzón compartido que dependen de ella.

El orden que funciona es al revés de lo que parece. Primero, filtra los registros de inicio de sesión por clientes de autenticación heredada —Exchange ActiveSync, IMAP, POP, SMTP AUTH y la categoría de otros clientes— y anota qué cuentas y qué aplicaciones aparecen. Segundo, migra cada caso a autenticación moderna o, si no es posible a corto plazo, crea una exclusión explícita, acotada y con fecha de caducidad. Solo entonces pasa la política de modo solo informe a activa. Una exclusión sin dueño ni fecha es la forma habitual de que la autenticación heredada siga viva años después de "haberla bloqueado".

Despliega cada política en modo solo informe antes de activarla

Las políticas de acceso condicional admiten un modo solo informe que registra lo que habría ocurrido sin bloquear a nadie. Es la diferencia entre descubrir el impacto en los registros y descubrirlo en el teléfono, con media empresa sin poder entrar.

Hay una condición que no se puede saltar: las cuentas de emergencia deben quedar excluidas de forma explícita de todas y cada una de las políticas de acceso condicional, y su uso debe disparar una alerta. Una política mal escrita que no contemple esa exclusión puede dejarte fuera de tu propio tenant, y la recuperación en ese punto pasa por el soporte de Microsoft, que no es donde quieres estar.

Verifica que cada ajuste está realmente puesto

Un checklist no vale de nada si nadie comprueba el resultado. Estas son las comprobaciones que cierran cada punto.

Ajuste	Dónde se comprueba	Señal de que algo va mal
MFA para todos los usuarios	Informe de métodos de autenticación en Entra	Usuarios sin ningún método registrado, o solo con SMS
Bloqueo de la autenticación heredada	Registros de inicio de sesión filtrando por cliente heredado	Inicios correctos por IMAP, POP o SMTP AUTH
Acceso condicional sin huecos	Herramienta What If y exclusiones de cada política	Grupos de exclusión sin propietario ni fecha de caducidad
Consentimiento de aplicaciones	Ajustes de consentimiento de usuario en Entra	Consentimiento de usuario permitido para permisos sensibles
Reenvío externo	Política antispam de salida en Defender	Buzones con reenvío externo activo
Compartición externa	Ajustes de SharePoint y OneDrive	Enlaces anónimos permitidos, o sin fecha de caducidad
Registro de auditoría	Búsqueda en el registro unificado	La búsqueda no devuelve eventos del periodo esperado

FAQ

¿Es suficiente con el Secure Score y el CIS Benchmark?

Son una excelente base de configuración, pero no sustituyen a una auditoría ofensiva: revisan ajustes uno a uno, pero no encadenan vectores ni reproducen lo que haría un atacante real (consentimiento ilícito, AiTM, robo de tokens).

¿Qué es lo primero que debería endurecer?

La identidad: MFA resistente al phishing, acceso condicional sin huecos (incluido el bloqueo de la autenticación heredada) y la protección de los administradores globales con PIM. Es donde un atacante busca primero.

¿En qué orden aplico todo esto sin romper la operativa?

Identidad primero, siempre en modo solo informe: MFA, acceso condicional y bloqueo de autenticación heredada, con una ventana de observación antes de activar. Después el consentimiento de aplicaciones, que casi nunca molesta a nadie. Y al final Exchange y la compartición externa, que son los que más fricción generan con el trabajo diario y conviene comunicar antes.

¿Cuánto se tarda en endurecer un tenant?

La configuración en sí es rápida. Lo que marca el calendario es el trabajo previo: inventariar qué sigue usando autenticación heredada, migrar esos casos, identificar las cuentas que no pueden llevar MFA convencional y acordar la política de compartición externa con quienes trabajan con clientes. Ese inventario es el que define el plazo real, no el número de ajustes.

¿Qué hago con las cuentas que no pueden tener MFA?

No excluirlas sin más. Las opciones razonables son quitarles el inicio de sesión interactivo y dar el acceso por delegación a personas concretas, sustituirlas por una entidad de servicio con permisos acotados, o —si no queda otra— acotar la exclusión por IP de origen y ponerle fecha de caducidad con un responsable asignado.

¿Las cuentas de emergencia también entran en las políticas?

Justo al contrario: deben excluirse explícitamente de todas las políticas de acceso condicional, precisamente para que un fallo de configuración o del proveedor de MFA no os deje sin administración. A cambio, cualquier uso de esas cuentas tiene que generar una alerta inmediata, porque en condiciones normales no deberían iniciar sesión nunca.