Zero Trust en Microsoft 365 y Azure: guía práctica para proteger identidades, dispositivos, correo, datos y cloud
Zero Trust en Microsoft 365 y Azure no consiste en instalar un producto ni en activar una única política de seguridad. Es un modelo que cambia la forma en la que una organización decide quién puede acceder, desde qué dispositivo, a qué aplicaciones, durante cuánto tiempo y bajo qué condiciones.
El modelo tradicional confiaba en gran medida en el perímetro: si un usuario estaba dentro de la oficina, conectado a la VPN o utilizando un equipo de la empresa, se asumía que el acceso era razonablemente seguro.
Ese planteamiento tiene cada vez menos sentido.
Los empleados trabajan desde distintas ubicaciones, los servicios corporativos están repartidos entre Microsoft 365, Azure y aplicaciones SaaS, existen usuarios invitados, dispositivos personales, aplicaciones conectadas mediante OAuth y procesos automatizados que acceden sin una persona detrás.
Además, una gran parte de los incidentes modernos comienza sin necesidad de atravesar ningún firewall: una credencial robada, una sesión comprometida, un consentimiento malicioso, un correo de phishing o un dispositivo que ya estaba autorizado.
Zero Trust parte por tanto de tres principios fundamentales:
verificar explícitamente, utilizar el mínimo privilegio necesario y asumir que puede producirse una brecha.
Microsoft proporciona numerosas tecnologías para aplicar estos principios: Microsoft Entra ID, Conditional Access, Identity Protection, Privileged Identity Management, Microsoft Intune, Microsoft Defender, Microsoft Purview, Microsoft Defender for Cloud, Azure Policy, Microsoft Sentinel y Secure Score, entre otras.
Pero disponer de todas estas herramientas no significa automáticamente disponer de una arquitectura Zero Trust.
Una empresa puede tener Microsoft 365 E5 y seguir utilizando administradores permanentes, MFA débil, aplicaciones OAuth sin revisar, dispositivos sin administrar, SharePoint sobrecompartido y políticas de acceso llenas de excepciones.
En Kloudeal planteamos Zero Trust como un proceso progresivo. Primero se identifica dónde existe mayor riesgo, después se aplican controles de alto impacto con pilotos y validación y, finalmente, se crea un ciclo continuo de revisión de identidad, dispositivos, datos, aplicaciones y cloud.
Esta guía explica cómo construir ese modelo en 2026 sin convertir el proyecto en una colección desordenada de políticas ni intentar activar toda la seguridad de Microsoft en un solo día.
Zero Trust no significa bloquear más: significa confiar mejor
| Modelo tradicional | Modelo Zero Trust |
|---|---|
| Está dentro de la red, puede acceder. | Verificamos identidad, dispositivo, aplicación, riesgo y contexto. |
| Administrador permanente. | Privilegio limitado y, cuando procede, activado solo cuando se necesita. |
| MFA genérico. | Autenticación adecuada al nivel de riesgo y métodos resistentes a phishing para accesos sensibles. |
| Dispositivo corporativo = confiable. | Debe seguir cumpliendo requisitos de seguridad. |
| Acceso concedido una vez. | El contexto puede volver a evaluarse. |
| Todo administrador puede hacer de todo. | Roles específicos y mínimo privilegio. |
| Protegemos el perímetro. | Protegemos identidades, endpoints, aplicaciones, datos e infraestructura. |
¿Queréis revisar la seguridad de vuestro entorno Microsoft?
Podemos analizar Microsoft Entra ID, Microsoft 365, Azure, administradores, MFA, Conditional Access, dispositivos, Defender, compartición y datos para identificar primero qué controles aportarían mayor reducción de riesgo.
Solicitar revisión de seguridad MicrosoftÍndice
- Qué es realmente Zero Trust
- Los tres principios de Zero Trust
- Los pilares de una arquitectura Zero Trust
- Por dónde empezar
- 1. Identidad: el nuevo perímetro
- MFA y métodos resistentes a phishing
- Conditional Access
- Políticas iniciales recomendadas
- Identity Protection y políticas basadas en riesgo
- PIM y acceso privilegiado
- Cuentas de emergencia
- Invitados y acceso externo
- Aplicaciones empresariales, OAuth y service principals
- 2. Dispositivos: Intune y cumplimiento
- Defender for Endpoint
- Endpoint Privilege Management
- Hotpatch y actualización
- 3. Correo: Exchange Online y Defender for Office 365
- SPF, DKIM y DMARC
- 4. Datos: Microsoft Purview
- SharePoint, OneDrive y sobreexposición
- Zero Trust y Microsoft 365 Copilot
- 5. Azure: identidad, red, workloads y datos
- RBAC, PIM y Managed Identities
- Red y exposición pública
- Defender for Cloud
- 6. Monitorización y respuesta
- Microsoft Secure Score
- Cloud Secure Score
- Licenciamiento
- Roadmap Zero Trust de 90 días
- Modelo de madurez
- Errores frecuentes
- Checklist Zero Trust
- Preguntas frecuentes
- Documentación oficial
Qué es realmente Zero Trust
Zero Trust no significa que una empresa “no confíe en nadie”.
Significa que la confianza no se concede únicamente por una condición estática como estar conectado desde la oficina.
Cada solicitud de acceso debe evaluarse utilizando el contexto disponible.
| Señal | Pregunta |
|---|---|
| Identidad | ¿Quién está intentando acceder? |
| Autenticación | ¿Cómo ha demostrado su identidad? |
| Riesgo | ¿Hay indicios de que la cuenta o el inicio de sesión estén comprometidos? |
| Dispositivo | ¿Está administrado y cumple la política? |
| Aplicación | ¿A qué servicio quiere acceder? |
| Ubicación | ¿Desde dónde se conecta? |
| Dato | ¿Qué sensibilidad tiene la información? |
| Privilegio | ¿Realmente necesita ese nivel de acceso? |
| Sesión | ¿Debe seguir siendo válida en las condiciones actuales? |
Microsoft Entra Conditional Access reúne muchas de estas señales y actúa como motor de decisión para el acceso.
Pero Zero Trust no termina en Conditional Access.
Una cuenta correctamente autenticada desde un portátil comprometido sigue suponiendo un riesgo. Un usuario legítimo que tiene acceso a demasiados datos también. Y una aplicación con permisos excesivos puede acceder sin que exista ningún login interactivo.
Referencia oficial: Microsoft – Zero Trust adoption framework.
Los tres principios de Zero Trust
1. Verificar explícitamente
La decisión debería utilizar tantas señales relevantes como sea razonable.
No basta con comprobar usuario y contraseña.
Podemos valorar:
MFA, autenticación resistente a phishing, dispositivo, ubicación, aplicación, riesgo y sensibilidad del recurso.
2. Utilizar mínimo privilegio
El usuario debería disponer únicamente del acceso que necesita.
Esto afecta tanto a:
roles administrativos, permisos Azure, SharePoint, grupos, aplicaciones empresariales, service principals y privilegios locales en Windows.
3. Asumir brecha
La arquitectura debe plantearse pensando que alguna credencial, dispositivo, aplicación o sesión puede terminar comprometida.
Eso significa limitar movimiento lateral, reducir privilegios, segmentar accesos, registrar actividad y disponer de capacidad para investigar y responder.
Pilares de una arquitectura Zero Trust en Microsoft 365 y Azure
| Pilar | Tecnologías Microsoft habituales | Objetivo |
|---|---|---|
| Identidades | Microsoft Entra ID, Conditional Access, Identity Protection, PIM. | Evitar que una credencial sea suficiente para acceder. |
| Dispositivos | Intune, Defender for Endpoint, Windows. | Evaluar y reducir el riesgo del endpoint. |
| Aplicaciones | Enterprise Applications, App registrations, Defender for Cloud Apps. | Controlar qué aplicaciones acceden y con qué permisos. |
| Correo | Exchange Online, EOP, Defender for Office 365. | Reducir phishing, malware, BEC y suplantación. |
| Datos | Microsoft Purview, SharePoint, OneDrive. | Clasificar, proteger y controlar información. |
| Infraestructura | Azure RBAC, Policy, Defender for Cloud, Key Vault. | Reducir exposición y privilegios de workloads. |
| Red | Azure networking, Firewall, Private Link y controles asociados. | Reducir exposición innecesaria. |
| Monitorización | Defender XDR, Sentinel, Secure Score. | Detectar, investigar y mejorar. |
Por dónde empezar: riesgo antes que producto
Uno de los errores más frecuentes es empezar preguntando:
“¿Qué funciones de E5 podemos activar?”
La pregunta debería ser:
“¿Cuáles son ahora mismo las formas más probables de comprometer nuestro entorno?”
En muchas organizaciones la prioridad inicial suele estar aquí
| Riesgo | Control inicial |
|---|---|
| Contraseña comprometida | MFA y políticas de autenticación. |
| Administrador comprometido | Autenticación resistente a phishing + mínimo privilegio. |
| Legacy authentication | Bloqueo tras análisis. |
| Portátiles inseguros | Intune + compliance + Defender. |
| Phishing/BEC | Defender for Office 365 y autenticación de dominio. |
| Información sobrecompartida | Revisión de permisos y Purview. |
| Administradores permanentes | PIM / reducción de roles. |
| Aplicaciones OAuth | Inventario y revisión de consentimiento. |
| Azure expuesto | Defender for Cloud, RBAC y revisión de red. |
1. Identidad: el nuevo perímetro de seguridad
Microsoft Entra ID controla gran parte del acceso a Microsoft 365, Azure y numerosas aplicaciones SaaS.
Por eso cualquier estrategia Zero Trust debería comenzar por comprender las identidades.
Inventario mínimo
| Objeto | Qué debemos revisar |
|---|---|
| Usuarios | Activos, deshabilitados, duplicados y cuentas antiguas. |
| Administradores | Quién tiene cada rol y por qué. |
| Guests | Quién sigue necesitando acceso. |
| Grupos | Propietarios y membresías. |
| Enterprise Applications | Permisos, propietarios y uso. |
| App registrations | Secretos, certificados y permisos Graph. |
| Service principals | Acceso no interactivo. |
| Workload identities | Aplicaciones y automatizaciones. |
Eliminar identidades innecesarias antes de añadir políticas
Una cuenta antigua que conserva permisos es un riesgo aunque tenga MFA.
Antes de sofisticar la autenticación merece la pena eliminar:
usuarios obsoletos, administradores innecesarios, aplicaciones abandonadas y permisos que ya no tienen propietario.
MFA: necesario, pero no todos los métodos ofrecen el mismo nivel de protección
La autenticación multifactor debería formar parte de la línea base de Microsoft 365.
Microsoft está además aplicando MFA obligatorio progresivamente a diferentes experiencias administrativas y de Azure.
Por tanto, no tiene sentido esperar a que la plataforma lo imponga.
El objetivo no debería ser únicamente “activar MFA”
También tenemos que decidir qué métodos consideramos adecuados para cada perfil.
| Perfil | Enfoque |
|---|---|
| Usuario general | MFA con métodos corporativos definidos. |
| Administrador | Priorizar MFA resistente a phishing. |
| Usuario de alto riesgo | Authentication strength superior cuando corresponda. |
| Cuenta de servicio | No diseñarla como usuario interactivo si existe una identidad de workload apropiada. |
Authentication Strengths
Microsoft Entra ofrece actualmente tres fortalezas integradas:
MFA, passwordless MFA y phishing-resistant MFA.
También permite crear combinaciones personalizadas.
Para administradores
Microsoft recomienda actualmente utilizar autenticación resistente a phishing para roles administrativos sensibles.
Entre los métodos adecuados se encuentran escenarios basados en:
FIDO2/passkeys y Windows Hello for Business
cuando cumplen los requisitos de la organización.
Preparar primero los métodos
Una política que exige autenticación resistente a phishing antes de que los administradores dispongan del método adecuado puede bloquear el acceso.
El orden debería ser:
registro → piloto → Report-only → validación → enforcement.
Referencias oficiales:
Conditional Access: el motor de políticas Zero Trust
Microsoft Entra Conditional Access evalúa señales y decide qué requisitos debe cumplir un acceso.
Puede utilizar información relacionada con:
usuarios, grupos, roles, recursos, aplicaciones, dispositivo, ubicación, riesgo, plataforma y método de autenticación.
Ejemplo conceptual
| Condición | Control |
|---|---|
| Administrador accede a un portal Microsoft. | Requerir autenticación resistente a phishing. |
| Usuario accede a una aplicación sensible. | Requerir dispositivo compatible. |
| Login con riesgo alto. | Bloquear o exigir remediación según política. |
| Legacy authentication. | Bloquear. |
| Dispositivo no gestionado. | Limitar o impedir determinados accesos. |
Conditional Access requiere licenciamiento
Las políticas de Conditional Access requieren Microsoft Entra ID P1 o un producto que incluya esa capacidad.
Por ejemplo:
Microsoft 365 Business Premium y Microsoft 365 E3.
Referencia oficial: Microsoft – Conditional Access Overview.
Qué políticas de Conditional Access plantearía primero
No recomendamos crear 30 políticas el primer día.
Un conjunto inicial más sencillo es más fácil de entender, probar y mantener.
| Política | Objetivo | Despliegue |
|---|---|---|
| MFA general | Evitar acceso únicamente con contraseña. | Piloto → Report-only → general. |
| Administradores | Authentication strength superior. | Después de registrar métodos. |
| Legacy authentication | Bloquear protocolos heredados. | Después de analizar logs. |
| Dispositivo compatible | Proteger aplicaciones críticas. | Después de desplegar Intune. |
| Riesgo | Responder a sign-ins o usuarios sospechosos. | Con Identity Protection. |
| Ubicaciones | Control adicional cuando exista justificación. | No usar como única señal de confianza. |
Report-only antes de bloquear
El modo Report-only permite evaluar qué habría ocurrido con una política sin aplicar el control durante la mayoría de escenarios.
Los resultados aparecen asociados a los registros de inicio de sesión.
Esto permite detectar:
usuarios afectados, aplicaciones incompatibles, cuentas especiales y excepciones legítimas.
What If
La herramienta What If de Conditional Access también ayuda a evaluar cómo podrían aplicarse las políticas a un escenario determinado.
Referencia oficial: Microsoft – Conditional Access report-only mode.
Identity Protection y políticas basadas en riesgo
Microsoft Entra ID Protection analiza señales para identificar riesgo de inicio de sesión y riesgo de usuario.
Sign-in risk
Representa la probabilidad de que un determinado intento de autenticación no sea legítimo.
User risk
Representa la probabilidad de que la identidad del usuario esté comprometida.
Respuesta adaptativa
Podemos diseñar políticas que, dependiendo del nivel de riesgo:
permitan, exijan MFA, requieran remediación, soliciten un cambio seguro de contraseña o bloqueen el acceso.
Cambio importante de 2026
Las antiguas políticas independientes de riesgo de Identity Protection se retiran el 1 de octubre de 2026.
Microsoft recomienda trasladar esos controles hacia políticas de riesgo dentro de Conditional Access.
Licenciamiento
Las capacidades de riesgo de Identity Protection requieren el licenciamiento correspondiente, habitualmente asociado a Microsoft Entra ID P2 o productos que lo incluyan.
Referencia oficial: Microsoft – Risk-based access policies.
PIM: que un administrador pueda administrar no significa que deba ser administrador todo el día
Los roles privilegiados permanentes aumentan el impacto potencial de una cuenta comprometida.
Microsoft Entra Privileged Identity Management permite transformar determinadas asignaciones permanentes en acceso elegible.
Ejemplo
En lugar de:
usuario → Global Administrator permanente
podemos plantear:
usuario → rol elegible → activación cuando lo necesita → MFA → justificación → duración limitada.
PIM puede proporcionar
| Control | Finalidad |
|---|---|
| Eligible assignment | El rol no está activo permanentemente. |
| Time limit | La activación caduca. |
| MFA | Verificación adicional. |
| Approval | Revisión antes de determinadas activaciones. |
| Justification | Motivo de uso. |
| Notification | Visibilidad de activaciones. |
| Access review | Revisar si el acceso sigue siendo necesario. |
No todo administrador necesita Global Administrator
También deberíamos utilizar roles específicos:
Exchange Administrator, SharePoint Administrator, Teams Administrator, Intune Administrator, Security Administrator
cuando cubren la tarea necesaria.
Licenciamiento actualizado
PIM puede utilizarse actualmente mediante Microsoft Entra ID P2 o Microsoft Entra ID Governance, según el escenario y los requisitos de licencia.
Referencia oficial: Microsoft – Privileged Identity Management.
Cuentas de emergencia: prepararse para el error de nuestras propias políticas
Conditional Access es una herramienta muy potente.
Precisamente por eso una configuración incorrecta puede bloquear a los propios administradores.
Emergency access
Microsoft recomienda disponer de cuentas de emergencia cuidadosamente protegidas y supervisadas.
Estas cuentas no son usuarios normales
No deberían utilizarse para:
correo diario, navegación, Teams o administración rutinaria.
Qué deberíamos controlar
| Aspecto | Práctica |
|---|---|
| Uso | Exclusivamente emergencia. |
| Credenciales | Protegidas y gestionadas. |
| Monitorización | Alertar si se utilizan. |
| Pruebas | Validarlas periódicamente. |
| Exclusiones | Documentadas y mínimas. |
Invitados y colaboración externa
Zero Trust también debe cubrir usuarios externos.
SharePoint, Teams y otras aplicaciones permiten colaborar con clientes, proveedores y partners.
El objetivo no debería ser deshabilitar toda colaboración externa, sino gobernarla.
Preguntas importantes
| Pregunta | Control |
|---|---|
| ¿Quién puede invitar? | Políticas de colaboración. |
| ¿Cuánto dura el acceso? | Revisión/ciclo de vida. |
| ¿Quién es propietario? | Accountability. |
| ¿El invitado sigue trabajando con nosotros? | Access Reviews. |
| ¿Qué aplicaciones puede utilizar? | Conditional Access y permisos. |
Access Reviews
Las revisiones de acceso permiten volver a certificar periódicamente si determinados usuarios siguen necesitando pertenecer a grupos o acceder a recursos.
Referencia oficial: Microsoft – Access Reviews.
Aplicaciones empresariales, OAuth y service principals: el acceso que no siempre vemos
Una buena arquitectura Zero Trust no puede centrarse únicamente en usuarios humanos.
Las aplicaciones también obtienen permisos.
Enterprise Applications
Conviene revisar periódicamente:
aplicaciones activas, usuarios asignados, permisos concedidos, propietarios y último uso.
App registrations
Un registro de aplicación puede disponer de:
permisos delegados, permisos de aplicación, secretos y certificados.
Los permisos de aplicación son especialmente sensibles
Una aplicación con permisos como acceso amplio a correo, sitios SharePoint o directorio puede actuar sin que un usuario pulse ningún botón.
Buenas decisiones de diseño
| Situación | Mejor enfoque |
|---|---|
| Secretos que nunca caducan | Evitar cuando sea posible. |
| Aplicación sin propietario | Asignar ownership o retirarla. |
| Permiso Global Administrator para una tarea puntual | Utilizar el permiso mínimo necesario. |
| Workload Azure | Evaluar Managed Identity. |
| Consentimiento de terceros | Revisar antes de aprobar globalmente. |
2. Dispositivos: la identidad puede ser correcta y el equipo estar comprometido
Si un atacante controla un endpoint que ya tiene una sesión válida, MFA por sí solo puede no ser suficiente.
Por eso Zero Trust incorpora el estado del dispositivo dentro de la decisión de acceso.
Microsoft Intune
Intune puede administrar:
configuración, compliance, aplicaciones, actualizaciones, cifrado y diferentes políticas de seguridad.
Compliant no significa “seguro para siempre”
La conformidad es el resultado de una política en un momento determinado.
Debemos combinar:
gestión + actualización + protección endpoint + Conditional Access + monitorización.
Ejemplo de compliance
| Control | Posible requisito |
|---|---|
| OS | Versión mínima. |
| Encryption | BitLocker. |
| Password | Política apropiada. |
| Threat level | Integración con Defender. |
| Root/Jailbreak | No permitido. |
Microsoft Defender for Endpoint
Defender for Endpoint aporta capacidades de protección, detección y respuesta en endpoints dentro de los planes compatibles.
La combinación con Intune resulta especialmente útil porque podemos incorporar determinadas señales de riesgo del dispositivo a las políticas de acceso.
Un endpoint comprometido no debería conservar acceso ilimitado
Una arquitectura madura intenta conectar:
detección → estado del dispositivo → política de acceso → respuesta.
Endpoint Privilege Management: menos administradores locales permanentes
Muchos usuarios tienen privilegios de administrador local porque alguna aplicación los necesitó en algún momento.
Eso incrementa el impacto de malware, ejecución de scripts y movimiento lateral.
Microsoft Intune Endpoint Privilege Management permite que el usuario trabaje como estándar y eleve únicamente tareas controladas.
No quitar primero admin local y preguntar después
La implantación debería empezar por observar qué elevaciones se realizan.
| Fase | Acción |
|---|---|
| Inventario | Identificar quién es admin local. |
| Reporting | Observar elevaciones. |
| Reglas | Permitir aplicaciones concretas. |
| Piloto | Usuarios representativos. |
| Retirada | Reducir administradores permanentes. |
| Revisión | Auditar nuevas solicitudes. |
Licenciamiento 2026
Endpoint Privilege Management necesita una capacidad de licencia específica.
Puede adquirirse como add-on/Intune Suite y, tras los cambios de empaquetado de 2026, forma parte también de Microsoft 365 E5 en el nuevo paquete comercial.
Referencia oficial: Microsoft – Endpoint Privilege Management.
Hotpatch: reducir determinados reinicios, no eliminarlos
Hotpatch puede aplicar determinadas actualizaciones de calidad sin realizar el reinicio habitual de una actualización acumulativa completa.
Pero no significa:
“Windows nunca vuelve a reiniciarse”.
Requisitos actuales
Microsoft documenta actualmente Hotpatch para determinados dispositivos con:
Windows 11 24H2 o posterior, licencia elegible e Intune para administrar la política.
Licencias elegibles documentadas
Entre las actuales se encuentran:
Windows Enterprise E3/E5, Microsoft 365 F3, Microsoft 365 Business Premium y Windows 365 Enterprise, además de determinados planes Education.
Baseline updates
Los dispositivos siguen necesitando actualizaciones de línea base periódicas que pueden requerir reinicio.
Referencia oficial: Microsoft – Hotpatch updates.
3. Correo: Exchange Online y Defender for Office 365
El correo sigue siendo uno de los vectores de ataque más relevantes para cualquier organización.
Zero Trust debe considerar:
phishing, Business Email Compromise, malware, URLs maliciosas, adjuntos, suplantación y abuso de cuentas comprometidas.
Exchange Online Protection
Los buzones cloud disponen de capacidades base de protección mediante Exchange Online Protection.
Defender for Office 365 Plan 1
Añade controles adicionales para correo y colaboración, como funcionalidades relacionadas con:
Safe Links, Safe Attachments y protección frente a determinadas amenazas avanzadas.
Defender for Office 365 Plan 2
Añade capacidades superiores relacionadas con:
investigación, hunting, automatización, respuesta y Attack Simulation Training.
Standard y Strict
Microsoft publica configuraciones recomendadas agrupadas en dos niveles:
Standard y Strict.
Las políticas deben adaptarse al riesgo y a la experiencia del usuario, pero partir de las recomendaciones del fabricante es preferible a crear todos los valores desde cero sin referencia.
Referencia oficial: Microsoft – Recommended security settings for EOP and Defender for Office 365.
SPF, DKIM y DMARC: proteger la identidad del dominio
Una arquitectura de correo segura no termina en Defender.
También debemos demostrar qué servicios pueden enviar legítimamente en nombre de nuestros dominios.
| Tecnología | Función |
|---|---|
| SPF | Identifica sistemas autorizados para enviar. |
| DKIM | Firma criptográficamente mensajes salientes. |
| DMARC | Comprueba alineación y define política. |
No implementar DMARC a ciegas
Antes de aplicar p=reject deberíamos conocer todas las fuentes legítimas:
Microsoft 365, CRM, ERP, web, marketing, tickets y cualquier plataforma SaaS.
Secuencia práctica
inventario → SPF/DKIM → DMARC monitorización → análisis → quarantine/reject.
Referencias oficiales:
4. Datos: Zero Trust también debe preguntar qué información estamos protegiendo
Un usuario puede superar correctamente MFA, utilizar un dispositivo conforme y seguir teniendo acceso a información que nunca debería haber visto.
La protección del dato necesita por tanto su propia estrategia.
Microsoft Purview
Purview agrupa diferentes soluciones relacionadas con:
| Necesidad | Capacidad relacionada |
|---|---|
| Clasificación | Sensitivity Labels. |
| Protección | Information Protection. |
| Prevención de fugas | Data Loss Prevention. |
| Ciclo de vida | Retention. |
| Registros | Records Management. |
| Investigaciones | eDiscovery. |
| Auditoría | Audit. |
| Riesgo interno | Insider Risk Management. |
No empezar con 20 etiquetas
Una clasificación demasiado compleja hace que los usuarios dejen de entender el sistema.
Es preferible comenzar con una taxonomía sencilla y ampliarla cuando exista una necesidad real.
DLP primero en modo de prueba
Una política que bloquea números de identificación o información financiera puede generar falsos positivos.
Antes de bloquear deberíamos:
detectar → medir → ajustar → comunicar → aplicar.
Referencias oficiales:
SharePoint, OneDrive y Teams: el permiso histórico también es riesgo
Una parte muy importante de la seguridad del dato no está en Purview, sino en los permisos.
Ejemplos de riesgo
| Situación | Problema |
|---|---|
| Everyone excepto invitados | Acceso interno demasiado amplio. |
| Links anónimos sin control | Información compartida sin identidad. |
| Invitados antiguos | Acceso que ya no tiene propósito. |
| Propietarios que abandonaron la empresa | Sitio sin responsabilidad. |
| OneDrive usado como repositorio departamental | Información corporativa ligada a una persona. |
Revisar antes de añadir IA
Cuanto mejor se organiza y gobierna SharePoint, más fácil resulta aplicar posteriormente búsqueda, Copilot, Purview y otras capacidades de información.
Zero Trust y Microsoft 365 Copilot
Las experiencias de inteligencia artificial aumentan todavía más la importancia de controlar identidad, permisos y datos.
Microsoft 365 Copilot utiliza información a la que el usuario tiene acceso.
Por tanto:
Copilot no crea por sí mismo un permiso incorrecto, pero puede hacer mucho más fácil encontrar información que ya estaba sobrecompartida.
Antes de un despliegue amplio
| Área | Revisión |
|---|---|
| SharePoint | Sitios y permisos excesivos. |
| OneDrive | Compartición. |
| Guests | Acceso externo. |
| Sensitive data | Clasificación. |
| Apps | Permisos de Graph. |
| Identity | MFA y Conditional Access. |
5. Zero Trust en Azure
Azure amplía considerablemente la superficie que debemos proteger.
Además de usuarios tenemos:
suscripciones, recursos, máquinas virtuales, aplicaciones, redes, storage accounts, bases de datos, Kubernetes, Key Vault, managed identities y service principals.
Una buena arquitectura Azure debería preguntarse
| Área | Pregunta |
|---|---|
| Identidad | ¿Quién puede administrar? |
| RBAC | ¿Tiene más privilegios de los necesarios? |
| Red | ¿El recurso necesita realmente Internet? |
| Secrets | ¿Dónde se almacenan? |
| Workload identity | ¿Podemos utilizar Managed Identity? |
| Policy | ¿Podemos impedir configuraciones inseguras? |
| Posture | ¿Qué recomienda Defender for Cloud? |
| Logs | ¿Podremos investigar un incidente? |
RBAC, PIM y Managed Identities en Azure
El principio de mínimo privilegio es especialmente importante en Azure.
Evitar Owner global por comodidad
Asignar Owner a nivel de suscripción para resolver cualquier problema rápidamente genera una superficie de privilegios excesiva.
Conviene utilizar:
roles específicos + scopes específicos + PIM cuando corresponda.
Managed Identities
Cuando un recurso Azure necesita autenticarse contra otro servicio, una Managed Identity puede evitar almacenar credenciales o secretos en el código.
Service principals
Cuando sea necesario utilizar una aplicación:
limitar permisos, utilizar certificados cuando resulte apropiado, rotar credenciales y asignar propietarios.
Red y exposición pública en Azure
Zero Trust no significa que la red deje de importar.
Significa que la red deja de ser la única frontera de confianza.
Revisar exposición
Especialmente:
RDP, SSH, bases de datos, storage, APIs, aplicaciones web y paneles administrativos.
Servicios PaaS
Cuando el caso lo justifique pueden utilizarse controles como:
Private Endpoints, firewall del servicio, restricciones IP y Managed Identities.
Segmentación
Las redes deberían diseñarse para limitar movimiento lateral y separar workloads con necesidades diferentes.
Microsoft Defender for Cloud
Defender for Cloud ayuda a evaluar la postura de seguridad de los recursos y workloads.
Proporciona recomendaciones relacionadas con:
configuración, vulnerabilidades, identidad, exposición, cifrado, endpoints, logging y otros controles.
Microsoft Cloud Security Benchmark
Al habilitar Defender for Cloud se utiliza Microsoft Cloud Security Benchmark como referencia predeterminada para evaluar los recursos en alcance.
Más que Azure
Defender for Cloud también puede extenderse a entornos multicloud compatibles como AWS y Google Cloud.
Cambio relevante en 2026
Desde junio de 2026, más recomendaciones multicloud contribuyen al Secure Score de Defender for Cloud.
Por tanto, una variación del porcentaje no siempre significa que la seguridad haya empeorado; puede deberse a que ahora estamos evaluando más activos y recomendaciones.
Referencia oficial: Microsoft – Defender for Cloud Secure Score.
6. Monitorización y respuesta: asumir brecha implica poder verla
Zero Trust no termina bloqueando accesos.
También debemos responder a la posibilidad de que un control falle.
Microsoft Defender XDR
Permite correlacionar señales procedentes de diferentes áreas compatibles del entorno Microsoft.
Microsoft Sentinel
Puede utilizarse como SIEM/SOAR cuando la organización necesita centralizar registros, correlacionar eventos y automatizar determinados procesos de respuesta.
Qué debería existir como mínimo
| Elemento | Pregunta |
|---|---|
| Alertas | ¿Quién las revisa? |
| Severidad | ¿Qué se considera crítico? |
| Escalado | ¿A quién avisamos? |
| Contención | ¿Podemos bloquear usuario/dispositivo rápidamente? |
| Evidence | ¿Conservamos los registros necesarios? |
| Runbook | ¿Existe un procedimiento? |
Microsoft Secure Score: utilizarlo como brújula, no como nota de examen
Microsoft Secure Score mide la postura de seguridad según acciones recomendadas dentro de productos Microsoft compatibles.
Puede ayudarnos a:
identificar mejoras, priorizar acciones, observar tendencias y comparar el estado a lo largo del tiempo.
No existe un porcentaje universal correcto
Un objetivo arbitrario como:
“tenemos que llegar al 90 %”
puede conducir a aplicar controles que no tienen sentido para nuestro contexto.
Evaluar cada recomendación
| Criterio | Pregunta |
|---|---|
| Riesgo | ¿Qué amenaza reduce? |
| Impacto | ¿Afectará a usuarios? |
| Licencia | ¿Podemos implementarla? |
| Alternativa | ¿Ya tenemos otro control equivalente? |
| Complejidad | ¿Cuánto cuesta mantenerlo? |
Secure Score no garantiza seguridad
Microsoft deja expresamente claro que la puntuación no representa una probabilidad absoluta de sufrir o no una brecha.
Referencia oficial: Microsoft – Microsoft Secure Score.
Cloud Secure Score: el modelo de Defender for Cloud también está evolucionando
En 2026 conviene distinguir entre distintos modelos de puntuación.
Modelo clásico
Continúa disponible desde Azure y se basa en recomendaciones agrupadas dentro de controles de seguridad.
Nuevo Cloud Secure Score
Microsoft dispone ahora de un modelo basado en riesgo dentro del portal de Defender.
Además del número de recomendaciones abiertas puede considerar factores como:
criticidad del activo, exposición y riesgo.
Los valores no son directamente equivalentes
Por tanto, no deberíamos comparar sin contexto el número del modelo clásico con el nuevo Cloud Secure Score.
Licencias: qué capacidades requiere cada nivel
El licenciamiento de seguridad de Microsoft es una de las partes que más cambia.
La siguiente tabla refleja el enfoque vigente en 2026 y debe volver a validarse antes de contratar.
| Capacidad | Business Premium | Microsoft 365 E3 | Microsoft 365 E5 |
|---|---|---|---|
| Conditional Access | Sí, Entra ID P1. | Sí, Entra ID P1. | Sí. |
| Identity Protection / riesgo | Requiere capacidad P2 adicional. | Requiere P2 o producto compatible. | Incluido mediante Entra ID P2. |
| PIM | Requiere P2 / Entra ID Governance. | Requiere P2 / Entra ID Governance. | Incluido mediante capacidades P2 vigentes. |
| Intune Plan 1 | Sí. | Sí. | Sí. |
| Intune Plan 2 | No como capacidad base equivalente. | Incluido con el empaquetado 2026. | Incluido. |
| Intune Remote Help | Revisar add-on. | Incluido con el empaquetado 2026. | Incluido. |
| Endpoint Privilege Management | Add-on / Intune Suite. | Add-on / Intune Suite. | Incluido con el empaquetado 2026. |
| Defender for Office 365 P1 | Incluido actualmente. | Incluido con el empaquetado 2026. | Sí. |
| Defender for Office 365 P2 | Add-on. | Add-on. | Incluido. |
| Security Copilot | Revisar licenciamiento específico. | Revisar licenciamiento específico. | Incorporado al empaquetado comercial 2026. |
| Purview avanzado | Depende de la función. | Depende de la función. | Mayor número de capacidades incluidas. |
Business Premium sigue siendo especialmente interesante para PYME
Porque reúne en una misma suite:
Microsoft Entra ID P1 + Intune + Defender for Business + Defender for Office 365 Plan 1
además de las aplicaciones y servicios de productividad correspondientes.
E3 ha cambiado bastante en 2026
Muchas comparativas antiguas han quedado obsoletas porque Microsoft 365 E3 incorpora ahora capacidades adicionales como:
Defender for Office 365 Plan 1, Intune Plan 2, Intune Remote Help e Intune Advanced Analytics.
E5
El nuevo empaquetado añade sobre E3 capacidades como:
Security Copilot, Endpoint Privilege Management, Cloud PKI y Enterprise Application Management.
Referencia oficial: Microsoft – Microsoft 365 Packaging and Pricing Updates 2026.
¿Tenéis licencias de seguridad pero no sabéis qué está realmente implantado?
Podemos revisar qué funcionalidades tenéis disponibles, cuáles están configuradas, qué políticas presentan riesgo y qué mejoras aportarían más valor antes de contratar nuevos add-ons.
Revisar seguridad y licenciamientoRoadmap Zero Trust de 90 días
No existe un roadmap universal, pero esta secuencia permite avanzar desde los controles de identidad más críticos hacia dispositivos, datos, aplicaciones y cloud sin intentar transformar todo el entorno simultáneamente.
Días 1–15: saber qué tenemos
| Acción | Resultado esperado |
|---|---|
| Inventariar administradores. | Conocer privilegios. |
| Inventariar usuarios e invitados. | Eliminar accesos innecesarios. |
| Inventariar aplicaciones empresariales. | Detectar permisos desconocidos. |
| Revisar métodos MFA. | Conocer cobertura. |
| Identificar legacy authentication. | Preparar bloqueo. |
| Crear/revisar emergency access. | Evitar lockout. |
| Obtener Secure Score inicial. | Línea base. |
Días 16–30: proteger identidad
| Acción | Despliegue |
|---|---|
| MFA general. | Piloto y ampliación. |
| Phishing-resistant MFA administradores. | Registrar métodos primero. |
| Conditional Access. | Report-only. |
| Bloqueo legacy authentication. | Después de analizar logs. |
| Revisar roles privilegiados. | Reducir permanentes. |
Días 31–45: correo y dominio
| Acción | Objetivo |
|---|---|
| Revisar anti-phishing. | Mejorar protección. |
| Aplicar Standard/Strict donde proceda. | Baseline Microsoft. |
| SPF. | Autorizar senders. |
| DKIM. | Firmar correo. |
| DMARC. | Monitorizar primero. |
| Revisar forwarding externo. | Reducir fuga y abuso. |
Días 46–60: endpoints
| Acción | Objetivo |
|---|---|
| Inventariar dispositivos. | Conocer cobertura. |
| Intune. | Administración. |
| Compliance. | Crear señal de confianza. |
| Defender. | Protección y detección. |
| Administradores locales. | Reducir privilegio. |
| EPM. | Evaluar según necesidad/licencia. |
Días 61–75: información y aplicaciones
| Acción | Objetivo |
|---|---|
| Revisar sharing externo. | Reducir sobreexposición. |
| Revisar permisos SharePoint. | Aplicar mínimo acceso. |
| Diseñar etiquetas simples. | Clasificación. |
| DLP en audit/test. | Medir impacto. |
| Revisar apps OAuth. | Reducir permisos innecesarios. |
| Revisar secretos. | Rotación y ownership. |
Días 76–90: Azure y mejora continua
| Acción | Objetivo |
|---|---|
| Revisar Azure RBAC. | Mínimo privilegio. |
| PIM Azure. | Reducir roles permanentes. |
| Defender for Cloud. | Priorizar recomendaciones. |
| Revisar exposición pública. | Reducir superficie. |
| Secure Score. | Medir evolución. |
| Documentar excepciones. | Gobierno. |
| Definir revisión trimestral. | Mejora continua. |
Zero Trust no se termina: evoluciona
| Nivel | Descripción |
|---|---|
| Inicial | Controles aislados y administración manual. |
| Básico | MFA, CA inicial, dispositivos y correo protegidos. |
| Gestionado | PIM, compliance, Defender, gobierno de datos y reporting. |
| Adaptativo | Riesgo, automatización, XDR, SIEM y remediación. |
| Continuo | Políticas y accesos revisados en función de señales y riesgo. |
No todas las empresas necesitan alcanzar inmediatamente el último nivel.
La madurez adecuada depende del riesgo, tamaño, regulación, recursos disponibles y complejidad de la organización.
Errores frecuentes al implantar Zero Trust
| Error | Consecuencia | Mejor enfoque |
|---|---|---|
| Comprar E5 y considerar terminado el proyecto | Funciones sin configurar. | Diseñar controles. |
| Confundir Zero Trust con MFA | Otros riesgos quedan sin tratar. | Identidad + dispositivos + datos + apps. |
| Aplicar CA directamente en On | Bloqueos. | Report-only y piloto. |
| Exigir phishing-resistant MFA antes de registrarlo | Administradores bloqueados. | Preparar métodos primero. |
| Confiar en ubicaciones corporativas | La red vuelve a convertirse en confianza implícita. | Usar varias señales. |
| Mantener Global Admin permanente | Elevado impacto de compromiso. | Roles específicos y PIM. |
| No disponer de emergency access | Lockout del tenant. | Cuentas controladas. |
| Ignorar aplicaciones OAuth | Acceso persistente no humano. | Inventario y revisión. |
| Guardar secretos indefinidamente | Credenciales reutilizables. | Certificados/Managed Identity cuando proceda. |
| Considerar compliant = seguro | Falsa confianza. | Combinar con Defender y señales. |
| Retirar admin local sin inventario | Aplicaciones dejan de funcionar. | Reporting/EPM/piloto. |
| Activar DLP bloqueando desde el principio | Falsos positivos. | Audit/test. |
| Crear demasiadas sensitivity labels | Baja adopción. | Modelo simple. |
| Activar Copilot sin revisar permisos | Mayor descubribilidad de contenido sobrecompartido. | Revisar permisos antes. |
| Perseguir un Secure Score concreto | Controles sin contexto. | Priorizar riesgo. |
| Ignorar Azure porque “solo usamos unas pocas VMs” | Infraestructura fuera del modelo. | Extender Zero Trust a cloud. |
| No documentar excepciones | Excepciones eternas. | Owner + motivo + caducidad. |
Checklist Zero Trust para Microsoft 365 y Azure
| Área | Comprobación |
|---|---|
| Identidades | Usuarios obsoletos eliminados/deshabilitados. |
| Administradores | Roles revisados. |
| MFA | Cobertura general. |
| Admins | Phishing-resistant MFA evaluado. |
| Authentication methods | Política definida. |
| Conditional Access | Políticas documentadas. |
| Report-only | Utilizado antes de enforcement. |
| Legacy authentication | Bloqueada cuando es posible. |
| Emergency access | Configurado y monitorizado. |
| Identity Protection | Políticas de riesgo en Conditional Access. |
| PIM | Evaluado para privilegios. |
| Guests | Revisados periódicamente. |
| Enterprise Apps | Inventariadas. |
| OAuth | Consentimientos revisados. |
| App secrets | Caducidad/rotación controladas. |
| Devices | Inventario disponible. |
| Intune | Dispositivos incluidos según alcance. |
| Compliance | Política definida. |
| Defender Endpoint | Protección y reporting revisados. |
| Local Admin | Justificación revisada. |
| EPM | Evaluado cuando procede. |
| Exchange | Políticas antiphishing revisadas. |
| SPF | Correcto. |
| DKIM | Habilitado para dominios relevantes. |
| DMARC | Despliegue controlado. |
| SharePoint | Compartición externa revisada. |
| OneDrive | Compartición revisada. |
| Purview | Clasificación y DLP evaluados. |
| Copilot | Permisos revisados antes del despliegue amplio. |
| Azure RBAC | Mínimo privilegio. |
| Azure PIM | Roles privilegiados evaluados. |
| Managed Identities | Utilizadas cuando corresponda. |
| Azure Network | Exposición pública revisada. |
| Defender for Cloud | Recomendaciones priorizadas. |
| Secure Score | Tendencia revisada. |
| Incidentes | Responsables definidos. |
| Excepciones | Owner, motivo y caducidad. |
| Revisión | Ciclo periódico establecido. |
Preguntas frecuentes sobre Zero Trust en Microsoft 365 y Azure
Es un modelo de seguridad basado en verificar explícitamente los accesos, utilizar el mínimo privilegio y asumir que puede producirse una brecha.
En Microsoft 365 intervienen servicios como Microsoft Entra ID, Conditional Access, Intune, Defender y Purview.
No.
Es un modelo de seguridad.
Microsoft proporciona diferentes productos que permiten implementar sus principios.
No.
Significa que el acceso se concede en función de identidad, contexto y riesgo y no simplemente por encontrarse dentro de una red corporativa.
No.
MFA es una pieza fundamental, pero Zero Trust también incluye dispositivos, aplicaciones, privilegios, datos, correo, infraestructura, monitorización y respuesta.
Es el motor de políticas Zero Trust de Microsoft Entra.
Utiliza señales como usuario, dispositivo, aplicación, ubicación o riesgo para decidir qué controles debe cumplir un acceso.
Requiere Microsoft Entra ID P1 o una licencia que lo incluya.
Business Premium y Microsoft 365 E3 son ejemplos habituales.
No es recomendable.
Microsoft proporciona Report-only y otras herramientas para evaluar impacto antes de aplicar el control en producción.
Es un estado de Conditional Access que permite evaluar gran parte del comportamiento de una política sin aplicar efectivamente sus controles.
Los resultados pueden revisarse posteriormente en los registros de inicio de sesión.
Microsoft recomienda actualmente autenticación resistente a phishing para determinados roles administrativos sensibles.
La organización debe preparar primero los métodos compatibles antes de exigirlos mediante Conditional Access.
Es una condición de Conditional Access que permite especificar qué combinaciones de métodos de autenticación son aceptables para acceder a un recurso.
Microsoft Entra ID Protection identifica riesgos relacionados con usuarios e inicios de sesión y permite utilizar esas señales dentro de Conditional Access.
Microsoft retira las políticas heredadas de riesgo de usuario e inicio de sesión el 1 de octubre de 2026.
La recomendación actual es utilizar políticas basadas en riesgo dentro de Conditional Access.
Las capacidades de Identity Protection necesitan el licenciamiento correspondiente, habitualmente Microsoft Entra ID P2 o una suite que lo incluya.
Privileged Identity Management permite gestionar privilegios con acceso just-in-time, activaciones temporales, MFA, justificación, aprobación y otras capacidades.
PIM puede utilizarse actualmente mediante licencias Microsoft Entra ID P2 o Microsoft Entra ID Governance según el escenario.
No.
Conviene utilizar roles específicos y asignar únicamente el privilegio necesario.
Es una cuenta de emergencia diseñada para recuperar acceso administrativo cuando los mecanismos normales no pueden utilizarse.
Debe estar especialmente protegida, monitorizada y fuera del uso cotidiano.
Sí.
Los invitados deben tener un ciclo de vida, propietarios, controles de acceso y revisiones apropiadas.
Permiten revisar periódicamente si usuarios o invitados siguen necesitando determinados accesos, grupos o roles.
Sí.
Una aplicación puede disponer de permisos muy amplios sobre Microsoft 365 sin utilizar una cuenta administrativa interactiva.
Es una identidad administrada por Azure que permite a determinados recursos autenticarse frente a otros servicios sin almacenar credenciales convencionales en el código.
Intune permite administrar dispositivos y generar señales de cumplimiento que pueden utilizarse dentro de decisiones de acceso.
No.
Compliance indica que cumple las condiciones definidas en la política, pero debe combinarse con protección endpoint, actualización y monitorización.
Es una capacidad de Intune que permite mantener a los usuarios como estándar y autorizar elevaciones controladas para determinadas tareas o aplicaciones.
Microsoft incorporó Endpoint Privilege Management al empaquetado comercial de Microsoft 365 E5 durante la actualización de 2026.
Para otros planes puede necesitarse un add-on o Intune Suite.
No.
Reduce determinados reinicios de actualizaciones en dispositivos compatibles, pero siguen existiendo actualizaciones de línea base y otros escenarios que pueden necesitar reinicio.
Microsoft incluye actualmente Microsoft 365 Business Premium entre las licencias elegibles para Hotpatch en Windows 11 compatible, sujeto al resto de requisitos técnicos.
Plan 1 incorpora protección avanzada de correo y colaboración.
Plan 2 añade capacidades superiores de investigación, hunting, automatización, respuesta y Attack Simulation Training.
Microsoft lo incorporó al empaquetado comercial de Microsoft 365 E3 durante la actualización de 2026.
No.
Son tecnologías de autenticación de dominio y complementan, pero no sustituyen, las capacidades antiphishing y de protección de correo.
Purview permite trabajar con clasificación, protección de información, DLP, retención, auditoría, eDiscovery y otras capacidades de gobierno y cumplimiento según licencia.
No suele ser lo recomendable.
Conviene primero observar el comportamiento, ajustar reglas y evaluar falsos positivos.
Porque el acceso a los datos depende en gran medida de permisos, grupos y enlaces compartidos.
Una buena autenticación no corrige automáticamente un sitio con permisos excesivos.
Copilot utiliza información a la que el usuario ya puede acceder.
Por eso conviene revisar identidad, permisos y sobreexposición de datos antes de un despliegue amplio.
Sí.
Azure introduce identidades, workloads, redes, storage, bases de datos, aplicaciones y permisos que necesitan el mismo enfoque de verificación, mínimo privilegio y reducción de exposición.
Ayuda a evaluar la postura de seguridad de recursos cloud y proporciona recomendaciones relacionadas con configuración, vulnerabilidades, identidad, red, cifrado y otras áreas.
Es una medición de la postura de seguridad basada en acciones recomendadas dentro de los productos compatibles de Microsoft.
Sirve para orientar mejoras, pero no garantiza que el entorno sea seguro.
No existe un porcentaje universal.
Las recomendaciones deben priorizarse según riesgo, impacto operativo, licencias y controles alternativos.
Microsoft Defender for Cloud dispone actualmente de un modelo de Cloud Secure Score basado en riesgo que tiene en cuenta recomendaciones y factores relacionados con los activos.
El modelo clásico continúa disponible en Azure.
No necesariamente.
El roadmap de 90 días sirve para iniciar una transformación estructurada y abordar controles prioritarios.
Zero Trust debe mantenerse como un proceso continuo.
Permite implantar una base muy sólida para muchas PYMES porque incluye, entre otras capacidades, Microsoft Entra ID P1, Intune y diferentes soluciones Defender.
Las funciones avanzadas de riesgo, PIM, Purview o Intune pueden requerir licencias adicionales.
No.
Zero Trust es un modelo, no una licencia.
E5 proporciona muchas capacidades avanzadas, pero una organización puede empezar con controles relevantes utilizando otros planes.
Como punto de partida resulta útil conocer número de usuarios, licencias Microsoft 365, uso de Azure, dispositivos, identidad híbrida si existe, aplicaciones empresariales, políticas actuales y requisitos de seguridad o cumplimiento.
Conclusión: Zero Trust es una forma de administrar el riesgo, no una lista de productos
Implantar Zero Trust en Microsoft 365 y Azure no consiste en activar todas las opciones disponibles en Microsoft Defender, Entra, Intune o Purview.
El objetivo es construir un sistema en el que cada acceso tenga una justificación adecuada y donde el compromiso de una identidad, un dispositivo o una aplicación no implique automáticamente acceso ilimitado al resto del entorno.
El punto de partida suele ser la identidad.
Usuarios y administradores deben estar correctamente inventariados, MFA debe formar parte de la línea base y los accesos privilegiados deberían reducirse al mínimo necesario.
Para administradores y recursos sensibles merece la pena avanzar hacia métodos de autenticación resistentes a phishing.
Conditional Access permite después incorporar señales como riesgo, dispositivo y aplicación. Pero estas políticas deben probarse en Report-only y desplegarse progresivamente para evitar que un control de seguridad se convierta en una interrupción operativa.
Los dispositivos son el siguiente componente.
Intune, Defender for Endpoint, compliance y Endpoint Privilege Management permiten reducir la dependencia de administradores locales y utilizar el estado del equipo dentro de las decisiones de acceso.
El correo requiere su propia estrategia con Defender for Office 365, protección antiphishing y una configuración adecuada de SPF, DKIM y DMARC.
Y proteger el acceso no sirve de mucho si los datos están sobrecompartidos.
SharePoint, OneDrive, Teams y Microsoft Purview necesitan un modelo coherente de permisos, clasificación y ciclo de vida, especialmente antes de ampliar el uso de Microsoft 365 Copilot.
En Azure, Zero Trust debe extenderse a RBAC, PIM, Managed Identities, redes, secretos, políticas, exposición pública y Defender for Cloud.
Finalmente necesitamos medir.
Microsoft Secure Score y Cloud Secure Score pueden ayudar a identificar áreas de mejora, pero no deberían convertirse en una competición por conseguir el porcentaje más alto.
La métrica importante sigue siendo otra:
qué riesgo estamos reduciendo, qué control lo mitiga, qué impacto tiene en el negocio y cómo sabemos que sigue funcionando dentro de seis meses.
Ese ciclo de inventario, protección, validación y revisión continua es lo que convierte una colección de productos Microsoft en una estrategia Zero Trust real.
¿Queréis mejorar la seguridad de Microsoft 365 o Azure?
En Kloudeal podemos revisar vuestro entorno actual, identificar los riesgos prioritarios y definir un roadmap adaptado a las licencias y necesidades de la organización.
Podemos trabajar sobre Microsoft Entra ID, MFA, Conditional Access, Identity Protection, PIM, aplicaciones empresariales, Microsoft Intune, Defender, Purview, SharePoint, Azure, Defender for Cloud, Secure Score y gobierno de seguridad.
El objetivo es priorizar controles útiles, probarlos antes de aplicarlos y dejar una arquitectura que pueda administrarse y evolucionar con el tiempo.
Solicitar revisión Zero TrustDocumentación oficial recomendada
Zero Trust
Microsoft Entra ID y Conditional Access
- Microsoft – Conditional Access
- Microsoft – Report-only mode
- Microsoft – Authentication Strengths
- Microsoft – Phishing-resistant MFA for administrators
- Microsoft – Mandatory MFA
Identity Protection y PIM
- Microsoft – Risk-based access policies
- Microsoft – Privileged Identity Management
- Microsoft – Entra ID Governance licensing
- Microsoft – Access Reviews
Microsoft Defender for Office 365
- Microsoft – Defender for Office 365
- Microsoft – Recommended EOP and Defender settings
- Microsoft – Safe Links
- Microsoft – Safe Attachments
SPF, DKIM y DMARC
Microsoft Intune
- Microsoft – Intune Licensing
- Microsoft – Endpoint Privilege Management
- Microsoft – Deploy Endpoint Privilege Management
- Microsoft – Hotpatch