Microsoft 365 suele estar en el centro de la operación: correo, Teams, SharePoint, OneDrive, calendarios, identidad, aplicaciones conectadas y cuentas administrativas.

Por eso no basta con “tener MFA” o confiar en que la configuración predeterminada será suficiente para siempre. Un tenant mal endurecido puede facilitar phishing, robo de sesión, acceso no autorizado a documentos, abuso de aplicaciones OAuth o cambios administrativos que nadie detecta a tiempo.

Endurecer Microsoft 365 no significa apagar todo ni volver imposible el trabajo diario. Significa reducir rutas comunes de ataque, mejorar visibilidad y dejar claras las excepciones.

Este checklist está pensado para empresas que usan Microsoft 365 y quieren una ruta práctica para mejorar seguridad sin perder control operativo.

Primero: define el alcance

Antes de cambiar políticas, identifica qué estás protegiendo.

Revisa:

  • cuántos usuarios activos hay;
  • cuántas cuentas administrativas existen;
  • qué licencias y capacidades de seguridad tienes;
  • qué dominios están verificados;
  • qué aplicaciones externas tienen permisos;
  • qué usuarios externos o invitados tienen acceso;
  • qué buzones compartidos existen;
  • qué dispositivos se conectan;
  • qué datos viven en SharePoint, OneDrive y Teams;
  • qué logs puedes consultar y retener.

Sin ese mapa inicial, el endurecimiento se vuelve una lista de cambios sueltos. Con inventario, puedes decidir qué proteger primero y qué excepciones tienen sentido.

1. Protege administradores antes que todo lo demás

Las cuentas administrativas deben tener controles más fuertes que una cuenta normal.

Prioridades:

  • separar cuenta administrativa y cuenta de correo diaria;
  • exigir MFA resistente al phishing donde sea posible;
  • reducir roles permanentes;
  • revisar Global Administrator, Privileged Role Administrator, Exchange Administrator y SharePoint Administrator;
  • evitar cuentas compartidas;
  • documentar cuentas de emergencia;
  • monitorear cambios en roles, métodos MFA y políticas.

Una cuenta administrativa comprometida puede cambiar reglas de correo, crear aplicaciones, modificar acceso a datos, desactivar controles o crear persistencia. Por eso el primer objetivo no es proteger “a todos igual”, sino proteger mejor a quien puede causar más impacto.

Si todavía hay administradores usando SMS o aprobaciones push sin contexto, conviene priorizar la ruta hacia MFA resistente al phishing en Microsoft 365.

2. Bloquea autenticación heredada

La autenticación heredada permite protocolos y clientes que no soportan controles modernos como MFA. Eso la vuelve atractiva para password spray, credential stuffing y automatización de intentos.

Microsoft recomienda bloquear protocolos heredados con Conditional Access cuando se cuenta con las licencias adecuadas. Para entornos sin Conditional Access, Security Defaults también ayuda a bloquear autenticación heredada y exigir controles básicos.

Antes de bloquear, revisa logs de inicio de sesión para detectar clientes antiguos o sistemas que todavía dependan de esos protocolos. Después:

  1. identifica usuarios y aplicaciones que usan autenticación heredada;
  2. valida si el uso sigue siendo necesario;
  3. migra clientes antiguos a autenticación moderna;
  4. deja excepciones solo cuando tengan dueño y fecha de revisión;
  5. activa bloqueo en modo report-only cuando aplique;
  6. pasa a bloqueo efectivo cuando el impacto esté claro.

No conviene conservar autenticación heredada como excepción permanente. Si algo crítico la necesita, ese sistema también debe entrar a un plan de reemplazo o mitigación.

3. Usa acceso condicional con criterio

Conditional Access no debe convertirse en una colección de reglas difíciles de entender.

Empieza por políticas claras:

  • exigir MFA para administradores;
  • bloquear autenticación heredada;
  • exigir autenticación fuerte para operaciones sensibles;
  • controlar acceso desde ubicaciones inesperadas;
  • requerir dispositivo administrado para datos críticos;
  • limitar sesiones cuando el riesgo sube;
  • proteger portales administrativos;
  • excluir y proteger cuentas de emergencia de forma documentada.

Prueba primero en report-only o con grupos piloto. Una política mal diseñada puede bloquear operación, dejar fuera a usuarios críticos o generar demasiadas excepciones informales.

El objetivo es aplicar más control donde el riesgo es mayor: cuentas privilegiadas, datos sensibles, accesos desde ubicaciones inusuales, dispositivos no administrados y acciones administrativas.

4. Revisa consentimiento OAuth y aplicaciones conectadas

Muchas intrusiones no necesitan robar una contraseña si logran que alguien autorice una aplicación con permisos amplios.

Revisa en Microsoft Entra:

  • aplicaciones empresariales;
  • registros de aplicaciones;
  • permisos concedidos por usuarios;
  • permisos concedidos por administradores;
  • secretos y certificados de aplicaciones;
  • aplicaciones sin dueño claro;
  • aplicaciones que piden acceso a correo, archivos o directorio;
  • apps de proveedores que ya no se usan.

Una política razonable debe limitar quién puede consentir aplicaciones, qué permisos requieren aprobación y cómo se revisan apps existentes. Microsoft documenta políticas de consentimiento de aplicaciones para controlar cuándo se puede conceder acceso y bajo qué criterios.

No bloquees todo sin proceso. Si el negocio usa integraciones legítimas, crea una ruta de aprobación: qué app se solicita, qué permisos pide, quién la necesita, qué datos toca y cuándo se revisará.

5. Fortalece correo contra phishing y abuso interno

El correo sigue siendo una ruta común para credenciales, malware, fraude y movimiento dentro de la organización.

Revisa:

  • SPF, DKIM y DMARC;
  • reglas de reenvío externo;
  • reglas de inbox sospechosas;
  • buzones compartidos con permisos excesivos;
  • cuentas con envío masivo inesperado;
  • alertas por phishing reportado;
  • impersonación de dominios o usuarios;
  • adjuntos y enlaces de alto riesgo;
  • políticas de cuarentena y liberación.

Un atacante con una cuenta válida puede crear reglas para ocultar mensajes, reenviar correos o usar la confianza interna para pedir pagos, documentos o cambios de proveedor.

Por eso el endurecimiento de Microsoft 365 debe incluir correo y no quedarse solo en login.

6. Activa y usa logs que sirvan para investigar

Tener Microsoft 365 no garantiza que puedas responder bien a un incidente. Necesitas saber qué eventos están disponibles, cuánto tiempo se retienen y quién los revisa.

Como mínimo, busca visibilidad sobre:

  • inicios de sesión exitosos y fallidos;
  • cambios de roles administrativos;
  • cambios en métodos de autenticación;
  • consentimiento de aplicaciones;
  • creación o modificación de reglas de correo;
  • acceso a buzones y archivos;
  • actividad en SharePoint, OneDrive y Teams;
  • cambios en políticas de seguridad;
  • eventos de alto riesgo en Entra ID.

CISA publicó un playbook para Microsoft Expanded Cloud Logs que busca ayudar a las organizaciones a usar logs de Microsoft Purview Audit (Standard) como parte accionable de detección, threat hunting y respuesta a incidentes.

La salida práctica debe ser simple: qué evento importa, dónde se consulta, cuánto tiempo se retiene, qué alerta dispara y quién responde.

7. Controla invitados y colaboración externa

Microsoft 365 facilita compartir archivos, canales y sitios. Eso es útil, pero también puede dejar acceso abierto más tiempo del necesario.

Revisa:

  • usuarios invitados activos;
  • dominios externos permitidos;
  • sitios de SharePoint con enlaces públicos;
  • archivos compartidos con “cualquier persona con el vínculo”;
  • permisos heredados en carpetas;
  • propietarios de Teams y sitios;
  • usuarios externos sin actividad reciente;
  • grupos que dan acceso a demasiados recursos.

No toda colaboración externa es mala. El riesgo aparece cuando nadie sabe quién puede ver qué, por cuánto tiempo y con qué justificación.

Define revisiones periódicas para invitados y enlaces compartidos. Si un proveedor terminó su trabajo, su acceso también debe terminar.

8. Revisa dispositivos y sesiones

Una cuenta protegida con MFA puede seguir en riesgo si una sesión queda comprometida o si el acceso se permite desde dispositivos sin control.

Preguntas útiles:

  • ¿qué dispositivos se conectan a Microsoft 365?
  • ¿hay dispositivos personales accediendo a datos sensibles?
  • ¿se requiere dispositivo administrado para áreas críticas?
  • ¿cuándo se revocan sesiones?
  • ¿qué pasa si un usuario reporta phishing?
  • ¿cómo se responde ante token robado o inicio de sesión sospechoso?

Para usuarios de alto impacto, el acceso debe considerar identidad, dispositivo, ubicación, aplicación y sensibilidad de datos. La contraseña ya no es el único punto de decisión.

Checklist mensual de endurecimiento

Una revisión mensual puede cubrir:

  • nuevos administradores o cambios de roles;
  • cuentas sin MFA fuerte;
  • inicios de sesión desde ubicaciones inusuales;
  • uso de autenticación heredada;
  • aplicaciones OAuth nuevas o con permisos amplios;
  • reglas de correo sospechosas;
  • reenvíos externos;
  • invitados y enlaces compartidos;
  • alertas de alto riesgo;
  • cuentas sin actividad;
  • dispositivos no administrados con acceso a datos sensibles;
  • logs disponibles para investigación.

La revisión no debe quedarse en capturas de pantalla. Convierte hallazgos en tickets con responsable, prioridad, evidencia y fecha de cierre.

Errores comunes

Estos errores se repiten mucho:

  • medir seguridad solo por “MFA activado”;
  • dejar SMS como alternativa para administradores;
  • no bloquear autenticación heredada;
  • permitir consentimiento de apps sin control;
  • no revisar reglas de inbox ni reenvíos externos;
  • conservar invitados sin fecha de salida;
  • no tener cuentas de emergencia documentadas;
  • no saber qué logs existen ni cómo consultarlos;
  • no probar políticas antes de aplicarlas a todos;
  • dejar excepciones sin dueño ni caducidad.

El problema no suele ser falta de herramientas. Suele ser falta de revisión, dueños claros y decisiones documentadas.

Por dónde empezar si tienes poco tiempo

Si solo puedes atacar lo más importante, empieza así:

  1. Lista cuentas administrativas y reduce privilegios.
  2. Exige MFA fuerte para administradores.
  3. Revisa si existe autenticación heredada.
  4. Identifica aplicaciones OAuth con permisos amplios.
  5. Revisa reglas de reenvío externo y reglas de inbox.
  6. Activa o valida logs de auditoría relevantes.
  7. Revisa invitados y enlaces compartidos.
  8. Documenta excepciones con fecha de revisión.

Esta primera pasada no deja el tenant perfecto, pero reduce incertidumbre y te da una ruta de mejora real.

Señales que requieren respuesta rápida

Actúa rápido si detectas:

  • inicio de sesión administrativo desde ubicación inusual;
  • cambio de método MFA sin solicitud conocida;
  • consentimiento de app con permisos amplios;
  • creación de regla para borrar, mover u ocultar correos;
  • reenvío externo nuevo;
  • elevación de privilegios inesperada;
  • múltiples fallos de inicio de sesión contra una cuenta crítica;
  • acceso a buzón o archivos después de phishing;
  • invitado externo con acceso a datos sensibles sin responsable.

Estas señales no siempre confirman una intrusión. Sí justifican revisar logs, revocar sesiones, rotar credenciales, validar permisos y documentar acciones.

Cómo puede apoyar Syscore

Syscore puede ayudarte a revisar Microsoft 365 con enfoque práctico: identidad, MFA, acceso condicional, permisos, aplicaciones OAuth, correo, colaboración externa, logs y respuesta ante señales sospechosas.

También podemos conectar esta revisión con monitoreo y análisis de seguridad, servicios de ciberseguridad para empresas y gestión de incidentes para que el endurecimiento no sea una tarea aislada.

Preguntas frecuentes

¿Security Defaults es suficiente?

Puede ser un buen punto de partida para tenants pequeños o sin licencias avanzadas. Pero si tu empresa necesita reglas por riesgo, ubicación, dispositivo, aplicación o rol, conviene evaluar Conditional Access y una configuración más granular.

¿Todos los usuarios necesitan MFA resistente al phishing?

Lo ideal es avanzar hacia métodos más resistentes, pero la prioridad debe empezar por administradores, usuarios con acceso a datos sensibles y roles de alto impacto. Después puedes ampliar por grupos.

¿Bloquear autenticación heredada puede romper algo?

Sí puede afectar clientes antiguos, scripts o sistemas que dependan de protocolos viejos. Por eso conviene revisar logs, probar en report-only cuando aplique y migrar dependencias antes de bloquear de forma general.

¿Cada cuánto debo revisar aplicaciones OAuth?

Al menos de forma mensual para empresas con cambios frecuentes. También debe revisarse cuando entra un proveedor nuevo, se conecta una herramienta externa o se detecta phishing.

Referencias útiles

Enlaces internos útiles

Microsoft 365 cambia con cada usuario, app, permiso, archivo compartido y política. Por eso endurecerlo no debe ser un proyecto de una sola vez: debe convertirse en una revisión recurrente de identidad, colaboración y visibilidad.