Restricciones de IP y horario: El dónde y el cuándo en el perímetro

El artículo anterior cerró con una pregunta: ¿desde dónde estás entrando y cuándo lo haces?

Quedó abierta a propósito. Mientras recorríamos la autenticación, los rangos de IP aparecieron más de una vez, y nunca se comportaron igual. A veces pedían un código de verificación. A veces rechazaban el login sin ofrecer ninguna alternativa.

Parecía un mismo control con dos comportamientos. Son dos controles distintos.

La autenticación resolvió quién sos. Contraseña, MFA, SSO, verificación de dispositivo: todo ese bloque responde una sola pregunta. Pero que seas quien decís ser no dice nada sobre desde dónde estás entrando ni a qué hora. Esas dos preguntas tienen sus propios controles.

El Well-Architected Framework de Salesforce lo resume en una línea: los rangos de IP y las horas de login restringen cómo y cuándo se conectan las identidades. No quién. Cómo y cuándo.

Esta fase cubre tres controles: Network Access, Login IP Ranges y Login Hours. Vamos a verlos uno por uno, y después vamos a ver algo que no suele estar a mano: en qué orden los evalúa Salesforce. Ese orden cambia cómo se leen los tres.

Empecemos por la confusión que más tickets genera.

Se parecen. Los dos son listas de direcciones IP. Los dos se cargan con una dirección de inicio y una de fin. Los dos suenan a «restringir el acceso por IP».

Hacen cosas distintas.

Network Access es una lista de confianza a nivel organización. Desde esas direcciones, el usuario entra sin recibir un desafío de verificación de identidad. No bloquea a nadie. Define quién se ahorra un paso.

Login IP Ranges es una restricción a nivel perfil. Cuando definís rangos en un perfil, un login desde cualquier otra dirección queda denegado. Acá sí se bloquea.

La propia página de Network Access lo aclara: si querés impedir que los usuarios entren desde direcciones no confiables, tenés que especificar rangos permitidos a nivel perfil.

Si te quedás con una sola idea del artículo, que sea esta: una lista de confianza no es una restricción.

Network Access: la lista de confianza

Network Access vive a nivel organización, está disponible en todas las ediciones y se administra con el permiso Manage IP Addresses.

El mecanismo detrás es simple. La primera vez que un usuario entra, su dirección IP queda guardada en el navegador; cada vez que entra desde otra dirección, se le pide verificar su identidad. Los rangos confiables son la forma de saltear ese paso, por ejemplo para que tus usuarios entren sin código cuando están en la oficina.

Quien está afuera de la lista no queda bloqueado. Supera un desafío, normalmente ingresando un código enviado al móvil o al correo, y entra.

Ese desafío tiene nombre, y lo conocés de la fase anterior: Device Activation. Salesforce lo define como la verificación de identidad que se exige al entrar desde un navegador o dispositivo no reconocido, o desde una ubicación fuera de un rango confiable. El método por defecto es un código al correo; si el usuario tiene registrado uno más fuerte, se usa ese.

Hay un efecto de Network Access que se pasa por alto: no afecta sólo a las personas. Desde una IP confiable, el usuario se ahorra la verificación en los logins de interfaz y el security token en las conexiones por API; las aplicaciones e integraciones no lo necesitan. De ahí sale una advertencia práctica: cargá también los rangos de tus aplicaciones e integraciones.

Y una contraintuitiva. Vaciar la lista no relaja nada. Si quitás todos los rangos confiables, todos los usuarios pasan a recibir el desafío de activación de dispositivo. La lista vacía es el estado más estricto, no el más permisivo.

Lo mismo vale si la administrás por metadata, y con una trampa extra. Network Access se despliega entero: para agregar un rango hay que desplegar todos los existentes más el nuevo, porque si no, los que mandás reemplazan a los que había. Y dejar el nodo vacío borra todos los rangos. Un despliegue parcial puede dejar a toda la organización recibiendo desafíos.

Login IP Ranges se configura en el perfil. Por defecto no hay nada: si no hacés nada, los usuarios pueden entrar desde cualquier dirección.

El interruptor es el primer rango. Alcanza con que exista uno para que todo lo demás quede denegado. No hay estado intermedio. Y por la misma razón, la forma de volver atrás es borrar todos los rangos del perfil, no dejar uno amplio.

Dónde se administra depende de la edición. En Enterprise, Performance, Unlimited y Developer, en el perfil. En Group y Personal, en Session Settings. En Professional depende del add-on «Edit Profiles & Page Layouts»: sin él, sólo existen los rangos de organización, en Network Access. Tenelo presente cuando alguien diga que «en Salesforce se restringe por IP en el perfil»: en algunas ediciones esa opción no existe.

El caso de uso que declara Salesforce es el de organizaciones cuyos usuarios entran por VPN o desde la IP pública de la red corporativa. Un límite de alcance a tener en cuenta: estas restricciones no aplican a los sitios alojados en Experience Delivery, que se protegen con Custom Firewall Rule Expressions.

El interruptor que cambia la naturaleza del control

Por defecto, Login IP Ranges se evalúa sólo en el login. Con el ajuste «Enforce login IP ranges on every request», los rangos se aplican en cada request de página, incluidas las de aplicaciones cliente.

Ese interruptor no vive en el perfil. Vive en Session Settings y afecta a todos los perfiles con restricciones de IP. En metadatos es lo mismo: enforceIpRangesEveryRequest es un campo de SessionSettings, no de Profile, y su valor por defecto es false. En Contact Manager, Group y Professional, además, los Login IP Ranges se cargan en esa misma página de Session Settings, y sólo después de activar el interruptor.

El Well-Architected Framework le da un rol que no es obvio. Bloquear la sesión a la IP de origen protege contra el robo de sesión, pero agrega fricción a los móviles y puede romper integraciones. Cuando ese bloqueo no es viable, la recomendación es Login IP Ranges estrictos en el perfil con este interruptor activo, como control compensatorio.

El orden de evaluación

Hasta acá, cada control por separado. Ahora la pregunta que los ordena: cuando alguien intenta entrar, ¿qué mira Salesforce primero?

La respuesta está documentada, aunque no donde uno la buscaría: en la guía de SOAP API, sección de seguridad. Y cubre los tres canales, el login por interfaz, por API y por cliente de escritorio.

Login Hours. Salesforce verifica si el perfil tiene restricciones de horario. Fuera de horario, el intento se deniega.
MFA. Si el usuario tiene el permiso de MFA para logins de interfaz, se le pide un método de verificación además de usuario y contraseña; hay un permiso equivalente para API.
Login IP Ranges. Salesforce verifica si el perfil define rangos. Si los define, los logins de afuera se deniegan, y si está activo el enforcement en cada request, se aplica a cada página.
Dispositivo y rangos confiables. La guía describe este paso para cuando el perfil no tiene restricciones de IP. Tiene tres salidas: dispositivo y navegador reconocidos, entra; IP en la lista confiable de la organización, entra; ninguna de las dos, bloqueado.
Verificación de identidad. No es un paso del recorrido: es lo que pasa después de un bloqueo. Cada vez que un login se bloquea, Salesforce verifica la identidad del usuario. Por interfaz, con Salesforce Authenticator o un código de verificación; por API o cliente, con un código TOTP si el permiso de MFA para API está activo. Y un detalle que explica consultas de soporte: en el primer login no se pide código de verificación.

Lo que cambia al leerlo en orden

Login Hours va primero, antes incluso que MFA. Si el horario de un perfil está mal configurado, no importa qué tan prolija esté la configuración de IP: nunca llega a evaluarse. Es el primer lugar para mirar cuando alguien no puede entrar.

Network Access es la rama alternativa, no el primer filtro. En la secuencia general, la lista confiable de la organización sólo entra en juego cuando el perfil no restringe por IP. Si el perfil tiene rangos, el control lo hace el perfil.

Con SSO, la lista deja de ser opcional para algunos canales. Con single sign-on habilitado, quien accede por API o cliente de escritorio no puede entrar salvo que su IP esté en la lista confiable de la organización o en el rango de su perfil.

La excepción: rangos demasiado amplios

La secuencia general tiene una excepción documentada, y conviene conocerla antes de que aparezca en un ticket.

Desde Winter ’26, los rangos tienen un tope: 16.777.216 direcciones IPv4. El límite vale para los dos niveles, organización y perfil, y el total se calcula sumando cada fila de rangos.

No es un límite administrativo. Viene de un cambio de seguridad: desde fines de octubre de 2025, cuando un login con usuario y contraseña ocurre con un conjunto excesivamente amplio de direcciones, en la organización o en el perfil, Device Activation se fuerza.

La regla completa: si los rangos del perfil o de la organización exceden el límite, se exige Device Activation aunque la IP del login esté permitida. Y cualquier login desde fuera del rango del perfil se sigue bloqueando. La guía de SOAP API no menciona esta excepción. Está en la documentación de producto de Login IP Ranges: si los rangos ya excedían el límite antes del cambio, Salesforce puede pedir activación de dispositivo aunque el usuario esté dentro del rango de su perfil.

Fijate lo que eso implica. En la secuencia general, con rangos en el perfil no hay chequeo de dispositivo. Con rangos que exceden el límite, sí lo hay. Un rango demasiado amplio deja de funcionar como lista de confianza, pero la restricción del perfil no se afloja.

Si desplegás por metadata rangos que se pasan del tope, el despliegue falla con un error explícito: «You reached the limit of 16,777,216 IP addresses across all of your IP ranges». La salida que recomienda Salesforce es reducir los rangos a las direcciones concretas de la empresa o de la VPN.

Qué ve el usuario

Con Network Access, el usuario de afuera ve el desafío de Device Activation y, si lo supera, entra. Si marca «Don’t ask again», el dispositivo queda recordado por un año; «Remember me» sólo guarda el usuario y no tiene nada que ver.

Con Login IP Ranges, el usuario de afuera no entra. Recibe un error al iniciar sesión y el intento queda registrado en Login History. Si tenés Event Monitoring, en el log de eventos ese intento queda registrado como «Restricted IP». Cuando alguien «no puede entrar y no entiende por qué», el registro tiene la respuesta.

Ahora juntemos las piezas. Elegí un escenario y mirá en qué orden Salesforce evalúa cada control. Empezá por «Ejecutivo desde casa». Después probá «Lista confiable vacía».

La tabla

	Network Access	Login IP Ranges
Nivel	Organización	Perfil
Qué hace	Exime de Device Activation	Deniega el login
Fuera de rango	Desafío; el usuario puede entrar	Acceso denegado
Lugar en la secuencia	Rama alternativa, si el perfil no tiene rangos	Paso 3, después de MFA
Ediciones	Todas	Todas (en el perfil: Enterprise, Performance, Unlimited, Developer)
Permiso	Manage IP Addresses	Manage Profiles and Permission Sets
Lista vacía	Todos reciben desafío	Nadie queda restringido

Las ediciones y permisos salen de las páginas de producto de cada control; el lugar en la secuencia, de la guía de SOAP API.

Login Hours responde el «cuándo». Para cada perfil podés especificar las horas en que sus usuarios pueden entrar. Está disponible en Enterprise, Performance, Unlimited, Developer y Database.com, con el permiso Manage Profiles and Permission Sets — el mismo que para editar Login IP Ranges.

No es casualidad: son la misma capa. En metadatos, loginHours y loginIpRanges son dos campos del mismo objeto Profile, y comparten la lógica del campo vacío: sin horas especificadas, el perfil no restringe el horario.

El modelo actual de Salesforce lo confirma. La recomendación vigente es usar los perfiles para la configuración base y los permission sets para el acceso, y Login hours y Login IP ranges figuran explícitamente entre lo que se administra en el perfil. Y como un usuario puede tener varios permission sets pero un solo perfil, su horario queda definido en un único lugar.

Si los administrás por metadata, tres detalles. Las horas se expresan en minutos desde la medianoche y sólo admiten horas completas. Para quitarle las restricciones a un perfil que las tenía, no alcanza con omitirlas: hay que mandar explícitamente un loginHours vacío. Y a diferencia de casi todo lo demás del perfil, los rangos de IP y las horas de login se recuperan siempre en un retrieve, pidas lo que pidas en el manifiesto.

Trailhead trae dos ejemplos. El primero es un call center: empleados que sólo necesitan ver datos de clientes mientras atienden llamadas, de nueve a cinco, sin acceso por las noches ni los fines de semana. El segundo combina los dos controles de esta fase: soporte sólo entra en horario de oficina, y el resto de los usuarios tiene acceso las 24 horas, pero desde la red de la empresa y la VPN.

En ese ejercicio, soporte queda de lunes a viernes de 8 a 18, y sábado y domingo de 12 AM a 12 AM. Esa es la forma documentada de bloquear un día entero; para permitir cualquier horario, se usa «Clear all times».

Lo que pasa cuando se termina el horario

Si los usuarios están conectados cuando terminan sus horas de login, pueden seguir viendo la página actual, pero no pueden realizar ninguna acción adicional. La misma frase aparece en Trailhead.

En la práctica, la pantalla que el usuario tiene abierta sigue ahí, y al intentar la próxima acción, la sesión se cierra.

No hay un texto documentado de la pantalla que ve el usuario, pero sí de lo que queda registrado: en el log de eventos, un login denegado por horario figura como «Restricted time». Cuando alguien no puede entrar fuera de horario, ese registro es la pista.

La trampa de la zona horaria

La primera vez que se configuran las horas de un perfil, se toman según la zona horaria por defecto de la organización, la de Company Information. Después, cambiar esa zona ya no afecta al perfil, y las horas tampoco se mueven aunque el usuario esté en otra zona horaria.

Hay una segunda capa. En el detalle del perfil las horas aparecen en tu zona horaria; en la pantalla de edición, en la zona por defecto de la organización. Dos admins en zonas distintas pueden mirar el mismo perfil y leer horarios distintos. No es un error: es el comportamiento documentado.

Por eso el ejercicio de Trailhead empieza pidiendo revisar la zona horaria de la organización antes de cargar las horas. Es un buen hábito para llevarse.

Dónde encaja todo esto

Salesforce ubica estos controles en su marco de arquitectura, y las recomendaciones son concretas.

Restricciones de IP: para perfiles administrativos y usuarios de integración. Sobre estos últimos, un dato que evita sorpresas: si un usuario de integración entra por la interfaz, pasa por Device Activation como cualquier otro, y por eso Salesforce recomienda asignarles API Only.

Login Hours: restringir las cuentas de servicio a sus ventanas operativas esperadas. Esto invierte la intuición. Uno piensa Login Hours como un control sobre personas, como el call center o el equipo de soporte. La recomendación apunta a las cuentas que no son personas.

En la misma línea, Salesforce Admins presenta los dos controles como medidas proactivas: ajustar las horas de login para reducir oportunidades de acceso no autorizado fuera del horario esperado, y configurar rangos confiables aplicándolos en cada request.

Trailhead lo resume en la misma lista que MFA, las restricciones de IP y los permission sets: medidas para protegerse del acceso no autorizado y de las filtraciones de datos.

Una aclaración necesaria: nada de esto equivale a cumplir con una normativa. Login Hours puede formar parte de una estrategia de control de acceso, pero por sí solo no constituye el cumplimiento de ningún marco regulatorio. La documentación consultada no nombra ninguno.

Lo que queda para la próxima fase

Quedó una pieza afuera a propósito. Las connected apps tienen su propio nivel de rangos confiables, y ahí vive IP Relaxation, que se puede aplicar a todas las aplicaciones cliente OAuth, incluidas las que usan OAuth y SAML para single sign-on. Es el tema de la próxima fase: cómo entran las integraciones, que no se comportan como un navegador.

Por ahora alcanza con el mapa. Login Hours decide cuándo, y se evalúa primero. Login IP Ranges decide desde dónde se puede entrar, y cuando existe, manda. Network Access decide quién se ahorra el desafío, y entra en juego cuando el perfil no restringe por IP, salvo que los rangos sean tan amplios que dejen de ser confiables. Tres controles, tres lugares distintos, y un orden que está documentado en una página que casi nadie mira.

Para seguir profundizando

Si querés profundizar en este tema, podés consultar la documentación oficial de Salesforce.