Hay una pregunta que todo administrador de TI termina por dejar de hacerse en voz alta porque ha aceptado que no tiene una respuesta sencilla.
“¿Por qué lo sé todo sobre este dispositivo, y casi nada sobre quién está sentado frente a él ahora mismo?”
Tienes el estado de los parches, el nivel de cumplimiento, el inventario de aplicaciones y la ubicación. Puedes borrarlo de forma remota a las 2 de la madrugada desde tu teléfono. ¿Pero qué pasa con la persona que inicia sesión a las 9 de la mañana? Eso sigue siendo en gran medida un acuerdo verbal y una contraseña que probablemente alguien reutilizó de otras tres cuentas.
Esa brecha es la razón de ser de OneIdP. Y dos años después, aquí está la historia honesta de lo que hizo falta para cerrarla.
El mundo en el que realmente vivían los equipos de TI
La respuesta convencional ya estaba bien establecida: comprar una herramienta IAM, integrarla en su UEM y configurar el SSO en algún punto intermedio.
Diferentes proveedores, diferentes paneles de control y diferentes lugares donde su política puede contradecirse silenciosamente en el momento en que un caso excepcional entra por la puerta.
El problema más profundo era que Scalefusion Los entornos de TI empresariales reconocidos no se basan en escenarios ideales, sino en excepciones. Dispositivos compartidos, incorporación remota de empleados, contratistas que utilizan portátiles personales y equipos distribuidos en cinco zonas horarias, por mencionar solo algunos ejemplos.
No se trataba de casos excepcionales que debieran gestionarse de forma aislada. Eran las condiciones reales de funcionamiento.
Sin embargo, la mayoría de las estrategias de acceso seguían diseñadas para un mundo donde todos se presentaban en la misma oficina, con el mismo dispositivo administrado, todos los días. Así, la autenticación se convirtió en el mero trámite. Se la trataba como un problema resuelto: verificar la contraseña, conceder la sesión y listo.
La mayoría de las decisiones de acceso aún se tomaban con información incompleta. Porque saber quién es alguien no dice casi nada sobre desde qué dispositivo inicia sesión: si ese dispositivo está actualizado, si pertenece a la organización, si es el equipo registrado del trimestre anterior o un portátil personal en el vestíbulo de un hotel.
Esa era la brecha que nos propusimos cerrar.
Lo que enviamos el primer día y por qué fue solo el comienzo.
Cuando lanzamos OneIdP, tomamos una decisión deliberada que la mayoría de los equipos de producto no toman. Entregamos una base sólida en lugar de una lista de funcionalidades.
Un directorio en la nube. Acceso condicional mediante tarjeta de acceso. Autenticación multifactor integrada en el mismo panel de control que los equipos de TI ya utilizaban a diario. La base era sólida desde el principio, antes de incorporar numerosas funcionalidades.
cerradura de tarjeta Permite a los equipos de TI establecer condiciones de acceso reales: ubicaciones aprobadas, rangos de IP de confianza, redes Wi-Fi específicas y ventanas de tiempo predefinidas. Para los equipos que utilizan contraseñas compartidas e inicios de sesión sin contexto, incluso esa primera versión suponía una forma de trabajar diferente.
Terreno firme, antes de que empezáramos a construir.
Y entonces sucedió algo que nos indicó que la base realmente se había asentado. Y en cuestión de meses, los clientes ya no preguntaban si OneIdP funcionaba. Ya estaban pensando en lo que vendría después.
- Cómo integrar su configuración actual de Okta o Entra.
- Cómo tomar decisiones de acceso que reflejen la conformidad del dispositivo, no solo su identidad.
- Cómo lograr que funcione para equipos que trabajan por turnos y comparten máquinas durante toda una jornada laboral.
Ese era el mapa, y lo seguimos.
Dos años construyendo para esa realidad.
La mayoría de las herramientas de identificación se basan en suposiciones.
Que una credencial válida garantiza una sesión segura. Que los equipos de TI reconstruirán su directorio para adaptarlo a la nueva plataforma. Que habrá alguien con amplia experiencia en gestión de identidades y accesos (IAM) disponible para mantenerlo todo en funcionamiento.
Estas suposiciones han estado integradas en la gestión de acceso empresarial durante años, porque, sencillamente, nadie se paró a cuestionarlas.
Interrogamos a los tres.
1. La identidad es suficiente para otorgar acceso.
El inicio de sesión único (SSO), tal como se ha implementado tradicionalmente en la industria, finaliza en el momento en que se verifican las credenciales. El usuario es quien dice ser. Sesión concedida.
Lo que nunca preguntó fue qué hay detrás de la credencial. Si el dispositivo está actualizado. Si la solicitud proviene de una ubicación lógica. Si la aplicación a la que se accede debería estar abierta en esa máquina en particular en ese preciso momento.
Construimos Políticas de acceso extendido (XAP) preguntar precisamente eso.
Cada inicio de sesión se evalúa en función de la información completa. Las señales de cumplimiento del dispositivo en tiempo real de Veltar influyen directamente en la decisión de acceso. Si algo no se verifica, el acceso se bloquea antes de que se abra nada. Sin revisión manual. Sin intervención del administrador. La política simplemente funciona.
Luego analizamos la otra cara del mismo problema.
En un dispositivo que OneIdP ya reconoce y en el que confía, pedirle al usuario que vuelva a escribir su contraseña no aporta nada. Simplemente genera una fricción que, de forma implícita, le indica a la persona que está detrás de la pantalla que el departamento de TI no confía en ella. El inicio de sesión único mejorado en dispositivos gestionados elimina este problema por completo. El estado de cumplimiento del dispositivo se convierte en la credencial. La experiencia se vuelve imperceptible, en el mejor sentido posible.
2. Empezarás de cero con tu identidad.
Todas las propuestas del tipo "cámbiate a nuestra plataforma" tienen el mismo punto ciego.
Se parte de la premisa de que los equipos de TI abandonarán años de configuración de directorios, integraciones con proveedores de identidad y políticas de acceso, y lo reconstruirán todo desde cero con una nueva herramienta. Para un equipo que gestiona 800 dispositivos en dos continentes, esa no es una migración sencilla.
Identity Federation se creó para esa realidad.
OneIdP se sitúa como la capa de política de acceso sobre la infraestructura ya existente. Entra, Google Workspace, Okta, PingOne o las configuraciones de Active Directory locales anteriores al actual equipo de TI: todo permanece intacto.
Lo llevamos aún más lejos con SCIM Entrada y salida. Cuando alguien se une, el acceso se otorga automáticamente. Cuando cambia su rol, el acceso se adapta. Cuando se va, las cuentas se eliminan sin necesidad de abrir una incidencia ni omitir ningún paso manual. La información sobre la plantilla se mantiene actualizada en todas las aplicaciones conectadas.
3. Siempre habrá alguien para gestionarlo.
La decisión sobre la arquitectura es la parte fácil. Lo complicado suele ser la gestión de identidades al convivir con la plataforma.
Contraseñas de administrador local Son un buen ejemplo de un problema que permanece latente hasta que se hace evidente. Credenciales idénticas en cientos de máquinas, sin cambios durante meses, porque rotarlas manualmente es una tarea para la que nadie tiene tiempo. LAPS lo automatizó. La rotación se realiza según lo programado. Cada credencial se audita. El riesgo desaparece sin que nadie tenga que intervenir.
El portal de usuario ofrecía a los empleados un único lugar para encontrar todas las aplicaciones autorizadas. Gestionadas por el departamento de TI, siempre actualizadas y sin ambigüedades sobre lo que está aprobado. El tipo de herramienta que no genera elogios, pero que elimina de forma permanente una categoría específica de incidencias en el servicio de asistencia técnica.
El inicio de sesión único basado en dispositivos resolvió el problema de los dispositivos compartidos que permanecía sin solución desde su lanzamiento. Cualquier usuario registrado en una máquina administrada obtiene acceso a su aplicación. No es necesario volver a registrarse entre turnos. El acceso acompaña al usuario. El dispositivo permanece listo para quien lo utilice a continuación.
Los registros de acceso SSO proporcionaron a cada CISO el registro de auditoría que solicitaron en su primera revisión de seguridad, de forma automática, sin que nadie lo creara en una hoja de cálculo.
Tres supuestos. Tres decisiones deliberadas para construir de manera diferente.
Pero las decisiones que se toman sobre el papel y las decisiones que se toman en la práctica son dos cosas muy diferentes.
Así es como sucedieron las cosas en realidad.
La cronología, sinceramente
Resulta útil ver cómo se desarrolló todo esto, no como una hoja de ruta del producto, sino como una serie de respuestas a lo que íbamos aprendiendo:
Lanzamiento de OneIdP
Directorio, inicio de sesión único, tarjeta de acceso.
Integraciones de proveedores de identidad
GWS, Entra, Okta, PingOne, Active Directory local, etc.
Portal de usuario y federación de identidades
Portal gestionado y controlado por TI para cada solicitud aprobada.
SCIM v2.0 — Aprovisionamiento a escala
Los usuarios se sincronizan. Los empleados que se marchan se dan de baja automáticamente.
Políticas de acceso extendido (XAP)
Conceda acceso SSO en función del cumplimiento del dispositivo, la ubicación, la IP y la presencia de la aplicación.
SSO basado en dispositivos + LAPS
Permitir que los dispositivos gestionados que cumplen con los requisitos accedan a las aplicaciones independientemente del usuario que haya iniciado sesión.
Asignaciones de inicio de sesión único (SSO) basadas en grupos de usuarios
Agregue excepciones al acceso condicional en las configuraciones de SSO o asigne usuarios de forma masiva a las configuraciones de SSO mediante el grupo de usuarios.
Claves de paso
Inicio de sesión sin contraseña mediante datos biométricos, claves de seguridad y dispositivos de confianza. Gestionado centralmente por el departamento de TI, con autoservicio para los usuarios.
Así es como luce OneIdP hoy en día.
Cuando lanzamos el producto, las conversaciones giraban en torno a la creación de una base sólida. Integrar la confianza y la identidad de los dispositivos en la misma capa de políticas. Lograr que el acceso condicional reflejara realmente lo que sucedía en el dispositivo en tiempo real.
Hoy, las conversaciones giran en torno a lo que esa base puede abarcar. Integraciones más profundas, mayor cobertura de la flota, políticas de acceso que se extienden a toda la infraestructura, porque la plataforma fue diseñada para ello.
Esa progresión desde la base hasta la plataforma completa es exactamente adonde queríamos llegar.
OneIdP Hoy en día, la identidad, la confianza en el dispositivo y la política de acceso se evalúan conjuntamente: en cada inicio de sesión, en tiempo real y sin desajustes entre el dispositivo que administra y el acceso que controla. El dispositivo y la persona que lo utiliza comparten, por fin, el mismo marco de políticas.
Lo que hemos mantenido a lo largo del tiempo es algo que se pone a prueba constantemente en el desarrollo de productos: «la plataforma de acceso más sofisticada solo es valiosa en la medida en que el equipo de TI sea capaz de gestionarla. Un equipo reducido que administra una flota distribuida no debería necesitar un ingeniero de IAM dedicado para que todo funcione correctamente».
Cada lanzamiento de los últimos dos años se ha regido por ese principio: ser lo suficientemente potente para un entorno complejo y lo suficientemente funcional para las personas que realmente lo utilizan.
Ese equilibrio es de lo que más nos enorgullecemos.
Que viene
Dos años trabajando codo a codo con equipos de TI te enseñan algo útil: el problema siempre es mayor que el que acabas de resolver.
La confianza en los dispositivos generó preguntas sobre el acceso a la red. El acceso a la red generó preguntas sobre la infraestructura. La compatibilidad con Cloud RADIUS y el acceso SSH basado en identidad son las siguientes respuestas, que ya están en desarrollo y que surgieron de las mismas conversaciones que dieron origen a todo lo anterior.
El alcance de lo que debe gobernarse en materia de acceso de confianza cero sigue ampliándose, y tenemos la intención de ampliarlo con él.
