Una contraseña Microsoft 365 comprometida nunca debe ser suficiente para abrir la puerta a los datos de la empresa. Este es todo el propósito de esta guía de acceso condicional Microsoft: decidir, para cada intento de conexión, si el acceso es legítimo, suficientemente protegido y compatible con el nivel de riesgo aceptado por su organización.
El acceso condicional transforma Microsoft Entra ID en un punto de control de su seguridad en la nube. En lugar de confiar en una identidad porque conoce su contraseña, usted cruza el contexto: usuario, aplicación solicitada, dispositivo utilizado, ubicación, nivel de riesgo y método de autenticación. Este enfoque limita directamente el impacto del phishing, del robo de sesión y de los dispositivos no controlados.
Lo que realmente controla el acceso condicional
Una política de acceso condicional no reemplaza la protección de endpoint, ni la conciencia del usuario, ni una supervisión activa. Complementa estas defensas previniendo un acceso arriesgado antes de que se convierta en un incidente. Es un control particularmente decisivo para los entornos Microsoft 365, donde el correo electrónico, SharePoint, OneDrive y Teams concentran información operacional crítica.
Una regla de acceso condicional se basa en una lógica simple: si un usuario o aplicación cumple ciertos criterios, Microsoft aplica una decisión. Esta decisión puede requerir autenticación multifactor, imponer un dispositivo conforme, solicitar un cambio de contraseña, restringir una sesión o bloquear el acceso.
La elección de la condición siempre debe corresponder a un escenario de riesgo concreto. Requerir MFA a todos los usuarios es una base útil. Bloquear las conexiones desde dispositivos no gestionados puede ser relevante para un puesto administrativo, pero mucho menos para un equipo de campo que utiliza dispositivos personales. La seguridad efectiva no consiste en aplicar el máximo de restricciones en todas partes: consiste en reducir el riesgo sin interrumpir innecesariamente las operaciones.
Los requisitos previos antes de crear la primera política
Antes de cualquier despliegue, establezca el inventario de identidades, aplicaciones y modos de trabajo. Identifique las cuentas privilegiadas, las cuentas de servicio, los colaboradores externos, los dispositivos gestionados y las aplicaciones que aún utilizan autenticación heredada. Una política mal preparada puede bloquear una aplicación de negocio o impedir que un equipo TI intervenga en el momento en que más la necesita.
La licencia también cuenta. Las políticas de acceso condicional generalmente requieren Microsoft Entra ID P1. Los controles basados en el riesgo de inicio de sesión o el riesgo del usuario se apoyan en capacidades avanzadas, a menudo asociadas con Entra ID P2. Las funcionalidades disponibles en su tenant deben validarse antes de definir una arquitectura de seguridad.
Cree también al menos dos cuentas de emergencia, a veces llamadas cuentas "break glass". Deben estar fuertemente protegidas, supervisadas y excluidas con precisión de ciertas políticas críticas para preservar una vía de administración en caso de fallo de MFA, problema de federación o error de configuración. Excluirlas no significa olvidarlas: todo uso de estas cuentas debe activar una alerta y ser objeto de una revisión inmediata.
Finalmente, documente su estado inicial. ¿Cuántos usuarios utilizan MFA? ¿Qué dispositivos están registrados y conformes? ¿Qué aplicaciones aún aceptan protocolos antiguos? Sin esta visibilidad, no podrá ni medir el progreso ni explicar un posible impacto a los negocios.
Guía de acceso condicional Microsoft: el orden de despliegue
El despliegue debe ser progresivo. Comenzar con una política global y agresiva es tentador, pero expone a la empresa a bloqueos costosos. Es preferible avanzar por olas, con un grupo piloto representativo, un seguimiento de los registros de conexión y una comunicación clara con los usuarios afectados.
1. Bloquear la autenticación heredada
Los protocolos de autenticación antiguos a menudo contornean las protecciones modernas, en particular la MFA. POP, IMAP o SMTP autenticado pueden seguir siendo necesarios en algunos casos, pero constituyen frecuentemente una superficie de ataque evitable. Comience por identificar los usos reales en los registros, luego bloquee estos protocolos con una política dedicada.
Prevea excepciones limitadas, justificadas y revisadas. Una excepción permanente para una impresora, una aplicación o un equipo antiguo se convierte rápidamente en un punto ciego. Si una modernización inmediata es imposible, aisle la necesidad, reduzca los permisos y establezca una fecha de retiro.
2. Imponer una MFA resistente al phishing
La MFA reduce significativamente el riesgo relacionado con la contraseña, pero no todos los métodos son iguales. Las notificaciones a validar en el smartphone siguen siendo vulnerables a la fatiga de MFA: el usuario puede aceptar una solicitud fraudulenta repetida. Para cuentas de administrador y accesos sensibles, privilegie métodos resistentes al phishing, como claves de seguridad FIDO2, passkeys o Windows Hello for Business según su entorno.
Una política puede dirigirse primero a los administradores, luego a los usuarios que acceden a aplicaciones en la nube. Defina fuerzas de autenticación adaptadas en lugar de una regla uniforme. Un ejecutivo en viaje, un operador de fábrica y un administrador Microsoft 365 no tienen el mismo perfil de exposición ni las mismas limitaciones de acceso.
3. Exigir dispositivos gestionados para datos sensibles
Un dispositivo conforme es un dispositivo cuyo estado de seguridad cumple con los requisitos de la empresa: cifrado activado, parches aplicados, antivirus o EDR operacional, ausencia de compromiso conocido y reglas de gestión respetadas. Al asociar Microsoft Intune y el acceso condicional, puede reservar los datos más sensibles a dispositivos que cumplan estos criterios.
Esta política es particularmente relevante para SharePoint, OneDrive y Exchange Online. Cuando el acceso desde un dispositivo personal sigue siendo necesario, una restricción de sesión puede ofrecer un compromiso: acceso a través del navegador, descarga limitada o protección de aplicación para usos móviles. El arbitraje correcto depende del valor de los datos, del rol del usuario y de la capacidad real de la empresa para gestionar su parque.
4. Asegurar los roles de administración sin excepciones
Las cuentas con privilegios elevados deben estar sujetas a reglas distintas. Exija MFA resistente al phishing, bloquee accesos desde dispositivos no conformes y limite sesiones cuando sea posible. Si su organización utiliza gestión de privilegios just-in-time, asóciela con acceso condicional para reducir el tiempo durante el cual una cuenta tiene derechos elevados.
No mezcle administradores y usuarios estándar en la misma lógica de protección. Un incidente en una cuenta administrativa puede modificar políticas, crear identidades o acceder a datos a gran escala. El nivel de exigencia debe reflejar este riesgo.
Probar antes de aplicar: una regla de continuidad
Microsoft ofrece un modo de solo informe. Úselo sistemáticamente para observar lo que una política habría bloqueado o requerido sin afectar a los usuarios. Analice los resultados durante varios días, incluso fuera del horario comercial, para detectar los servicios automatizados, los dispositivos compartidos y los accesos nómadas que podrían haber sido olvidados.
Los registros de conexión son su fuente de verdad. Muestran la política evaluada, el control aplicado, el estado del dispositivo y la razón de un fallo. Un aumento en los rechazos no indica necesariamente una mejor seguridad: puede señalar una configuración mal dirigida o una experiencia de usuario degradada.
Después del paso a producción, mantenga un período de supervisión reforzada. Prepare un circuito de asistencia para los usuarios, un procedimiento de retroceso y un responsable claramente identificado para validar excepciones. Toda excepción debe tener un propietario, una justificación de negocio, un perímetro limitado y una fecha de revisión.
Los errores que debilitan la estrategia
El primer error es desplegar políticas sin cuentas de emergencia ni procedimiento de recuperación. El segundo es conformarse con activar MFA sin tratar la autenticación heredada, los privilegios administrativos y la conformidad de dispositivos. El tercero es crear demasiadas políticas que se solapan: su combinación se vuelve difícil de entender, mantener y auditar.
Evite también las exclusiones basadas únicamente en una dirección IP o una ubicación considerada "confiable". Una dirección de red interna no es prueba de que un dispositivo o usuario sea legítimo. Las ubicaciones con nombre pueden ayudar a reducir fricciones en casos específicos, pero no deben convertirse en un contorno de los controles esenciales.
El acceso condicional debe evolucionar con los cambios en su empresa: llegada de una nueva aplicación SaaS, teletrabajo, fusión, cambio de proveedor o incidente de seguridad. Una revisión trimestral de políticas, exclusiones y registros permite mantener una defensa adaptada a la realidad operacional.
Una política bien construida da a los equipos la libertad de trabajar sin dar a los atacantes la misma libertad. Para una empresa, el valor del acceso condicional se mide menos por el número de reglas creadas que por su capacidad de mantener la actividad cuando cada conexión cuenta.