Acceso Condicional: Bloqueo de acceso por paises
Imagina que tu empresa trabaja únicamente en España. De repente, en los logs de Entra empiezas a ver intentos de acceso desde: Rusia, China, Estados Unidos, etc. La primera idea puede ser bastante sencilla: «Si no trabajamos allí, bloqueamos esos países.»
Y sí, Microsoft Entra Conditional Access permite hacerlo mediante las condiciones de Network/Location y las Named Locations. Podemos definir países o regiones y utilizarlos posteriormente en una política de acceso.
Vamos a verlo.
¿Cómo sabe Entra ID desde dónde me conecto?
Principalmente mediante la IP pública desde la que llega la conexión. Por tanto, no estamos diciendo:
«El usuario está físicamente en España.»
Estamos diciendo:
«La conexión que estoy viendo procede de una IP que Microsoft geolocaliza en España.»
Y esto es importante, porque las VPNs, proxies, redes corporativas, proveedores de Internet y otros escenarios pueden hacer que la ubicación detectada no coincida exactamente con la ubicación física del usuario, aunque normalmente salen desde el mismo país.
Microsoft también permite utilizar rangos IP como Named Locations, y en determinados escenarios puede utilizarse información GPS mediante Microsoft Authenticator.
¿Cómo montaría una política de bloqueo?
Un escenario bastante habitual sería:
Usuarios: Todos los usuarios
Recursos: Todos los recursos
Network: países/regiones que queremos bloquear
Access control: Block access
Y hay algo que no deberíamos olvidar: Excluir las cuentas de emergencia / break-glass.
Microsoft recomienda explícitamente excluirlas de las políticas para evitar quedarnos fuera del tenant por una mala configuración.
Y antes de bloquear… Report-only
Yo no activaría una política de este tipo directamente en producción.
Primero: Report-only → revisar Sign-in logs → validar impacto → activar
El modo Report-only nos permite comprobar qué habría ocurrido sin bloquear realmente al usuario. Y aquí es donde empiezan a aparecer las sorpresas.
Porque podemos descubrir:
- Usuarios que viajan
- Oficinas con salida a Internet en otro país
- Proxies
- VPN corporativa
- Usuarios con dispositivos móviles
- Proveedores externos
- Aplicaciones que utilizan identidades concretas
El pequeño problema «Me voy una semana a Estados Unidos»
Este es uno de los escenarios que más me gusta de este tipo de políticas. Porque inicialmente todo parece perfecto porque el cliente te confirma que solo trabajan en España. Hasta que llega el usuario solicitando en un ticket: «El lunes me voy a Estados Unidos y necesito acceder a Microsoft 365.»
Y aquí podemos acabar creando excepciones manuales, modificando grupos, cambiando políticas… Y después llega el siguiente viaje. Y el otro. Y el otro. Y esto acaba haciendo ruido…generando que hasta el propio cliente te solicite quitar esta política.
En Reddit hay administradores comentando precisamente este problema: organizaciones con geoblocking que terminan necesitando mecanismos temporales para permitir los viajes, incluso automatizando la inclusión y eliminación de usuarios de grupos de excepción.
Por eso, si nuestra organización tiene muchos usuarios viajeros, la excepción también debería estar diseñada.
Bloquear un país no significa que hayas detenido un ataque
Este punto me parece fundamental. Si bloqueamos China, por ejemplo, no significa que un atacante situado físicamente en China no pueda intentar acceder.
Puede utilizar otra infraestructura de salida y aparecer con una IP geolocalizada en otro lugar.
Por eso el bloqueo geográfico debe verse como una capa adicional de seguridad, no como nuestra defensa principal.
Conditional Access puede combinar la ubicación con otras señales y controles:
- MFA
- Riesgo de usuario
- Riesgo de inicio de sesión
- Estado de cumplimiento del dispositivo
- Red
- Método de autenticación
- Plataforma
- Aplicación cliente
Y hay un último detalle que me parece importante
Si utilizamos Continuous Access Evaluation (CAE), Microsoft indica que las ubicaciones basadas en países/regiones no tienen el mismo comportamiento de evaluación continua que las ubicaciones basadas en IP.
Para escenarios donde necesitamos evaluación en tiempo real de cambios de ubicación, Microsoft recomienda utilizar Named Locations basadas en rangos IP, incluyendo IPv4 e IPv6.
Es decir: Country/Region ≠ IP Named Location
Y entender esta diferencia antes de diseñar la arquitectura de Conditional Access puede ahorrarnos bastantes dolores de cabeza.
Mi enfoque
Si tuviera que implementar geoblocking en un tenant, mi checklist sería:
1. Definir desde qué países debería trabajar la organización.
2. Identificar usuarios que viajan.
3. Crear Named Locations.
4. Crear la política en Report-only.
5. Revisar Sign-in logs.
6. Excluir cuentas break-glass.
7. Diseñar un proceso para excepciones temporales.
8. Activar el bloqueo.
9. Monitorizar.
10. Revisar periódicamente las excepciones.
Y ahí es donde Conditional Access deja de ser simplemente una política de «permitir/bloquear» y empieza a convertirse en una pieza bastante potente de nuestra arquitectura de identidad.
