Conditional Access: políticas pensadas para una sede con sala de trading

Qué vas a conseguir

Un conjunto de políticas de acceso condicional que entiende la sede: dentro de la oficina, con un equipo gestionado, el trader trabaja sin fricción; fuera, o con un equipo que no es de la empresa, se le pide más o no entra. Las aplicaciones de trading y las consolas de administración tienen sus propias reglas, más duras. Y nada de eso se activa sin haberlo visto antes en modo solo informe, porque una política mal hecha a las 8:00 deja a una sala entera sin acceso a la apertura.

Antes de empezar

• Las IP públicas de salida de la sede, de todos los circuitos (principal y respaldo) y del proveedor de proxy o SASE si el tráfico sale por él. Te las da el equipo de redes, no una prueba en un navegador.
• Licencias Microsoft Entra ID P1 como mínimo (P2 si vas a usar condiciones de riesgo).
• Los equipos gestionados con Intune y su política de cumplimiento funcionando.
• Las dos cuentas de emergencia creadas y documentadas antes de tocar nada.
• La lista de aplicaciones que el negocio considera críticas: plataforma de órdenes, portales de mercado con SSO, consolas de administración.

1. La sede como ubicación con nombre

• Todos los circuitos: si solo das de alta el principal, el día que el tráfico salga por el respaldo la sede dejará de ser "de confianza". Es el ticket de la sección 5.
• Un nombre que diga qué es y de dónde sale. Si hay varias sedes, una ubicación por sede y un grupo de ubicaciones solo si de verdad las tratas igual.
• La ubicación no sustituye al dispositivo conforme: una IP de la oficina con un portátil personal conectado a la WiFi de invitados (si sale por la misma IP) no debería tener el mismo trato. Por eso la red de invitados sale por otra IP.

2. El diseño por capas

• Las apps de trading suelen tener una regla de negocio detrás: no se opera desde casa o solo desde equipos de la mesa. La política la refleja, no la inventa: pide la regla por escrito.
• Las consolas de administración y los roles privilegiados piden FIDO2 o Windows Hello for Business, desde cualquier sitio, también desde la sede.
• Evita una política por cada excepción. Si un caso no encaja, primero pregunta si el caso es correcto.

3. Cuentas de emergencia y otras exclusiones

• Las dos cuentas de emergencia se excluyen de todas las políticas mediante un grupo, solo de nube, con credenciales resistentes a phishing guardadas en sitios distintos. Cada inicio de sesión de esas cuentas genera una alerta que llega al equipo.
• Las cuentas de recurso de las salas (Teams Rooms) y las cuentas de servicio no deben quedar sin control: van excluidas de las políticas de usuarios y cubiertas por una suya (solo desde la sede, solo las aplicaciones que usan).
• Cada exclusión tiene dueño y motivo en la descripción de la política. La revisión mensual las repasa.

4. Primero en modo solo informe

Toda política nueva o cambiada se crea en Solo informe al menos una semana, con un día de mercado completo dentro. Mientras tanto:

• En los registros de inicio de sesión, la pestaña de acceso condicional muestra qué habría hecho cada política en modo solo informe. Busca los "Solo informe: error" y entiende cada uno antes de activar.
• Activa en martes o miércoles fuera de horario de mercado, nunca un lunes a primera hora ni el día antes de un cierre.

5. El ticket: "en la sede de repente piden MFA todo el rato"

Martes, 9:20. Varias mesas dicen que Outlook y Teams les piden MFA una y otra vez, y que la plataforma de órdenes no les deja entrar. Ayer todo iba bien.

1. El patrón: es a todos los de la sede y desde la misma hora. Eso apunta a la ubicación, no a los usuarios ni a los equipos.
2. Desde qué IP llegan los inicios de sesión:

›Connect-MgGraph -Scopes AuditLog.Read.All, Policy.Read.All›Get-MgAuditLogSignIn -Filter "createdDateTime ge 2026-10-27T07:00:00Z" -Top 500 | Group-Object IpAddress | Sort-Object Count -Descending | Select-Object -First 2 Count, NameCount Name----- ----  412 198.51.100.44   61 203.0.113.18›$loc = Get-MgIdentityConditionalAccessNamedLocation | Where-Object DisplayName -eq 'SEDE-MADRID-SALIDA'›$loc.AdditionalProperties.ipRanges.cidrAddress203.0.113.16/29

1. La causa: el tráfico de la sede sale desde esta mañana por 198.51.100.44, el circuito de respaldo, y ese rango no está en la ubicación con nombre. Para Entra ID, la sede está "fuera".
2. Confírmalo con redes: una caída del circuito principal, un cambio del proveedor o un ajuste del SD-WAN en el firewall. Si el cambio es legítimo, añade el rango del respaldo a la ubicación (con su cambio registrado) y los avisos paran en minutos.
3. Que no se repita: el procedimiento de cambios de red incluye "actualizar ubicaciones con nombre" y la alerta de caída del circuito principal avisa también al equipo de identidades.

No resuelvas el ticket desactivando la política o añadiendo "todas las IP" como confianza. Es la forma más rápida de abrir la puerta a cualquier sitio.

6. Lo que revisas cada mes

• Las IP de la ubicación contra lo que el equipo de redes dice que existe hoy.
• Las exclusiones de cada política: quién está y por qué.
• Los inicios de sesión de las cuentas de emergencia (debería haber cero, salvo la prueba trimestral).
• Las políticas que siguen en solo informe más de un mes: o se activan o se borran.
• Los errores de acceso condicional del mes por política, para detectar una regla que bloquea más de lo previsto.

Siguientes pasos

• La guía de Entra ID: Conditional Access del Nivel 3 explica cada condición y control y cómo se construye una política paso a paso.
• La guía de Intune cubre la política de cumplimiento en la que se apoya CA02.
• La de Microsoft 365: Global Admin y PIM cubre los roles privilegiados de CA05.
• La de Fortinet FortiGate explica por qué circuito sale el tráfico de la sede.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.