Algunas preguntas solo necesitan una respuesta de sí o no. Si llamas a un restaurante y preguntas: "¿Podría hacer una reservación para las 2 PM?" Algunas respuestas razonables serían "Sí", "No" o "Solo tenemos asientos al aire libre disponibles. ¿Está bien?
Probablemente le sorprendería escuchar: "Sí, pero un grupo de números impares debería reservar un asiento en la parte delantera del restaurante, mientras que un grupo de números pares debería reservar uno en la parte trasera". Además, por favor, use ropa blanca y use su pie izquierdo para entrar al restaurante; de lo contrario, será rechazado".
La sorpresa aquí sería doble: Primero, no esperabas una respuesta tan larga, y segundo, no parece que esas condiciones debieran existir en primer lugar.
Resulta que la aplicación de la autenticación multifactor (MFA) actúa de manera similar. Si bien esperarías que la pregunta "¿Está esta cuenta protegida por MFA?" tenga una respuesta simple de sí/no, la realidad suele ser mucho más complicada que eso. A menudo, algunos escenarios aplicarán MFA para el acceso a la aplicación, mientras que otros escenarios permitirán el acceso sin MFA, a veces intencionalmente, pero a menudo no.
El problema de la fragmentación
Una de las principales características que debe buscar en una solución como Okta Identity Security Posture Management es la capacidad de rastrear todos los escenarios de autenticación que conducen a cada cuenta en sus aplicaciones SaaS y comprender el estado de protección que implica cada uno.
Esta es una tarea fácil cuando se permite que solo un proveedor de identidad se autentique en una aplicación. Pero se vuelve mucho más complejo cuando se agregan políticas de autenticación variables, migraciones de soluciones de identidad anteriores, modelos de concentrador y radio, y diferentes aplicaciones SaaS que aplican diferentes reglas para inicios de sesión directos y aplicación de MFA. Todo esto resulta en múltiples escenarios de inicio de sesión, lo que hace que sea más difícil rastrearlos y protegerlos a todos.
En esta publicación de blog, profundizaremos en muchas de esas fuentes de fragmentación y exploraremos su impacto potencial.
Políticas de autenticación
Las políticas de autenticación, a menudo denominadas Políticas de Acceso Condicional, se utilizan para aplicar los requisitos de factor cuando los usuarios inician sesión en las aplicaciones o realizan determinadas acciones.
Hay muchas razones para permitir diferentes tipos de factores (o incluso permitir el inicio de sesión sin MFA):
- Diferentes plataformas permiten el uso de varios factores (y, como resultado, algunas plataformas pueden ser accesibles solo para ciertas aplicaciones)
- Diferenciación de dispositivos propiedad de la empresa y BYOD
- Exención para cuentas de servicio e identidades no humanas
- No requerir MFA al acceder a recursos no confidenciales para reducir la fatiga de MFA
Naturalmente, esas diferencias en los requisitos deben tenerse en cuenta al mostrar el estado de cumplimiento de una cuenta.
Brechas accidentales en la configuración de la política
Diferentes proveedores de identidad le permitirán configurar políticas de autenticación de diferentes maneras.
Si bien Okta utiliza un modelo basado en prioridades para configurar políticas de autenticación, otros proveedores configurarán políticas “globales” con la acción “más severa” que tenga efecto.
Si bien ambos métodos suenan equivalentes en la superficie, el segundo método hace que sea mucho más difícil excluir excepciones de todas las políticas, lo que a menudo resulta en brechas de seguridad.
Si bien este ejemplo es simplista e improbable al configurar solo unas pocas políticas, vale la pena recordar:
- Las grandes organizaciones a menudo tienen docenas de políticas implementadas, por lo que es probable que se pierdan tales casos (frecuentemente encontramos esas brechas en la práctica al analizar las políticas de acceso condicional configuradas en otros proveedores de identidad).
- Si bien es poco probable que alguien esté usando plataformas poco comunes al iniciar sesión, las condiciones de la plataforma se evalúan utilizando el Agente de Usuario, que se falsifica fácil y comúnmente durante las campañas de relleno de credenciales.
Métodos de inicio de sesión alternativos
Si bien la fuerza impulsora detrás del inicio de sesión único (SSO) es que el acceso a todas las aplicaciones se puede administrar desde una única ubicación, a menudo hay varias formas de acceder a una cuenta determinada en una determinada aplicación. Revisemos algunos de estos casos.
Inicio de sesión directo
A menudo, las cuentas que pueden acceder a una aplicación a través de SSO también pueden iniciar sesión directamente en la aplicación (ya sea utilizando una combinación de nombre de usuario y contraseña o utilizando claves de acceso).
Si bien a menudo es una elección deliberada (por ejemplo, para permitir el acceso de administrador de emergencia o durante la configuración de la aplicación), a veces puede suceder sin querer. En algunos servicios, es posible que sea necesario deshabilitar el acceso con contraseña por usuario, incluso si SSO está configurado. En otros servicios, las cuentas de administrador siempre pueden iniciar sesión directamente sin la opción de desactivarlo.
Lo clave para entender es que cada aplicación se comporta de manera diferente y no hay un comportamiento universal en el que confiar. Si la Autenticación Multifactor (MFA) está configurada para una cuenta, algunas aplicaciones seguirán solicitándola incluso si el usuario inicia sesión a través de SSO, mientras que algunas solo la solicitarán si el usuario ha iniciado sesión directamente. Otros servicios podrían incluso permitir configurar cuál de los dos comportamientos se producirá.
Múltiples proveedores de SSO
En muchos casos, se puede acceder a ciertas cuentas de una aplicación mediante varios proveedores de identidad. Estos casos podrían ocurrir debido a:
- Diferentes subsidiarias o departamentos que utilizan diferentes proveedores de identidad, con superposiciones potenciales entre ellos
- Remanentes de soluciones de identidad anteriores, donde una migración ha habilitado el nuevo proveedor de identidad pero nunca ha desactivado el anterior
- Configuraciones de prueba utilizadas para cuentas específicas o antes de inscribir a toda la organización
A veces, esos múltiples proveedores son conocidos y contabilizados; otras veces, estas configuraciones están ocultas y son fáciles de pasar por alto.
Fortaleza del factor
Hasta ahora, todo lo que hemos discutido ha tratado “MFA/Sin MFA” como una pregunta binaria, pero la realidad es más complicada que eso.
Dado que los mensajes SMS son susceptibles a la apropiación y los ataques de phishing son rampantes, es posible que su organización prefiera aplicar solo factores resistentes al phishing, o incluso deshacerse de la Autenticación Multifactor (MFA) tradicional por completo en favor de no usar contraseñas.
Tal esfuerzo requiere analizar esos diferentes escenarios de autenticación, ya que implica comprender la solidez de la autenticación en cada uno.
En esta entrada de blog, descubrimos las complejidades detrás de la aplicación de Autenticación Multifactor (MFA). Factores como las políticas de autenticación, los múltiples proveedores de Single Sign-On (SSO) y las diferencias en los comportamientos de las aplicaciones hacen que sea algo más que un simple estado de sí/no.
Para superar los retos que presenta esta complejidad, recomendamos adoptar una estrategia integral para mantener el estándar de autenticación de su organización y verificar periódicamente que todas las cuentas estén debidamente protegidas. Okta Identity Security Posture Management le ayuda a obtener visibilidad de los flujos de autenticación inesperados, garantizando un estándar coherente de autenticación en toda su organización.
¿Tiene preguntas sobre esta publicación de blog? Comuníquese con nosotros a eng_blogs@okta.com.
Explora más Blogs de Ingeniería perspicaces de Okta para ampliar tus conocimientos.
¿Listo para unirte a nuestro apasionado equipo de ingenieros excepcionales? Visite nuestra página de carreras.
Desbloquea el potencial de la administración de identidades moderna y sofisticada para tu organización. Ponte en contacto con Ventas para obtener más información.
Este blog y cualquier recomendación dentro del mismo no constituyen asesoramiento legal, de privacidad, de seguridad, de cumplimiento normativo o de negocios. Este blog tiene fines informativos generales únicamente y podría no reflejar los aspectos de seguridad, privacidad y legalidad más actuales, ni todos los problemas relevantes. Usted es responsable de obtener asesoramiento legal, de seguridad, de privacidad, de cumplimiento o empresarial de su propio abogado u otro asesor profesional, y no debe confiar en las recomendaciones en estos materiales. Okta no se hace responsable ante usted de ninguna pérdida o daño que pueda resultar de la implementación de las recomendaciones de estos materiales. Okta no hace declaraciones ni ofrece garantías u otras seguridades con respecto al contenido de estos materiales.
