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 te 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, usa ropa blanca y utiliza tu pie izquierdo para entrar al restaurante; de lo contrario, serás 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 simple respuesta de sí/no, la realidad a menudo es mucho más complicada que eso. A menudo, algunos escenarios aplicarán MFA para el acceso a la aplicación, mientras que diferentes escenarios permitirán el acceso sin MFA, a veces intencionalmente, pero a menudo no es así.
El problema con la fragmentación
Una de las principales características que se deben 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 cada uno implica.
Esta es una tarea fácil cuando se permite que solo un proveedor de identidad autentique 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 tipo central y radial, y diferentes aplicaciones SaaS que aplican diferentes reglas para los inicios de sesión directos y la aplicación de la Autenticación Multifactor (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):
- Las diferentes plataformas permiten el uso de varios factores (y, como resultado, algunas plataformas pueden ser accesibles solo para ciertas aplicaciones).
- Diferenciación entre dispositivos propiedad de la empresa y BYOD (Bring Your Own Device, Trae tu Propio Dispositivo)
- 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 considerarse al mostrar el estado de cumplimiento de una cuenta.
Vacíos accidentales en la configuración de la política
Los diferentes proveedores de identidad te permitirán configurar políticas de autenticación de diferentes maneras.
Si bien Okta utiliza un modelo basado en la prioridad para configurar las políticas de autenticación, otros proveedores configurarán políticas “globales” con la acción “más grave” que entre en vigor.
Si bien ambos métodos suenan equivalentes en la superficie, el segundo método hace que sea mucho más difícil crear excepciones de todas las políticas, lo que a menudo resulta en fallas de seguridad.
Aunque este ejemplo es simplista e improbable al configurar solo unas pocas políticas, vale la pena recordar lo siguiente:
- Las grandes organizaciones a menudo tienen docenas de políticas implementadas, lo que hace probable que se pierdan esos 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 User Agent, que se suplanta 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 existen múltiples formas de acceder a una cuenta determinada en una cierta 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 mediante una combinación de nombre de usuario y contraseña o mediante 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 de forma involuntaria. En algunos servicios, es posible que sea necesario desactivar el acceso con contraseña por usuario, incluso si se configura el SSO. 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 existe un comportamiento universal en el que se pueda confiar. Si la Autenticación Multifactor (MFA) está configurada para una cuenta, algunas aplicaciones aún lo solicitarán incluso si el usuario inicia sesión a través de SSO, mientras que algunas solo solicitarán MFA si el usuario ha iniciado sesión directamente. Otros servicios podrían incluso permitir configurar cuál de los dos comportamientos ocurrirá.
Múltiples proveedores de SSO
En muchos casos, se puede acceder a ciertas cuentas en una aplicación utilizando múltiples proveedores de identidad. Tales casos podrían ocurrir debido a:
- Diferentes subsidiarias o departamentos que utilizan diferentes proveedores de identidad, con potencial de superposiciones entre ellos
- Remanentes de soluciones de identidad anteriores, donde una migración ha habilitado el nuevo proveedor de identidad, pero nunca deshabilitó 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.
Solidez del factor
Hasta ahora, todo lo que hemos discutido ha tratado la “MFA/No-MFA” como una pregunta binaria, pero la realidad es más complicada que eso.
Dado que los mensajes SMS son susceptibles a la toma de control y los ataques de phishing son rampantes, es posible que tu organización prefiera aplicar solo factores resistentes al phishing, o incluso abandonar el MFA tradicional por completo para volverse sin contraseñas.
Tal esfuerzo requiere examinar esos diferentes escenarios de autenticación, ya que implica comprender la solidez de la autenticación en cada uno de ellos.
En esta publicación de blog, descubrimos las complejidades detrás de la aplicación de MFA. Factores como las políticas de autenticación, múltiples proveedores de SSO y las diferencias en los comportamientos de las aplicaciones hacen que sea cualquier cosa menos un estado simple de sí/no.
Para afrontar 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 regularmente 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? Contáctenos en eng_blogs@okta.com.
Explore más blogs de ingeniería perspicaces de Okta para ampliar sus conocimientos.
¿Listo para unirte a nuestro apasionado equipo de ingenieros excepcionales? Visita nuestra página de empleo.
Libere el potencial de la administración de identidades moderna y sofisticada para su organización. Póngase en contacto con el departamento de 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 comercial. Este blog tiene fines informativos generales únicamente y puede no reflejar los desarrollos legales, de privacidad y seguridad 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.
