Okta tiene el compromiso de brindarles a nuestros clientes el nivel más alto de seguridad. Fuimos de los primeros proveedores de tecnología en prometer nuestro compromiso con los siete principios de Diseño Seguro de la Agencia de Seguridad Cibernética y de Infraestructura de los Estados Unidos (CISA), y hace un año, lanzamos el Compromiso de Okta con la Identidad Segura.
En el marco de estas iniciativas, hemos anunciado y entregado una serie de características y actualizaciones esenciales para nuestra infraestructura corporativa y cartera de productos. Esto incluye animar a los clientes a utilizar una de las medidas de seguridad más eficaces disponibles: un enfoque sólido y coherente de la autenticación multifactor (MFA). Para ayudar a elevar el nivel de seguridad para todos, comenzamos a aplicar MFA para todos los inicios de sesión de la consola de administración de Okta en 2024. Es un paso inteligente y necesario en nuestro compromiso compartido con la seguridad centrada en la identidad.
Hoy, nos enorgullece compartir que Okta ha logrado la aplicación del 100% de MFA a la Okta Admin Console para todos los tenants de Okta existentes en un año. Y para todos los tenants nuevos, MFA es un requisito predeterminado e inmutable para las políticas de acceso a la Okta Admin Console.
¿Por qué se aplica la Autenticación Multifactor (MFA) para la consola de administración de Okta?
La Consola de administración de Okta es el centro central para administrar usuarios de Okta, aplicaciones protegidas por Okta y políticas de seguridad de Okta. El acceso no autorizado a esta consola puede tener consecuencias devastadoras que incluyen:
- Filtraciones de datos: Los atacantes podrían acceder a información confidencial del usuario y datos de la aplicación.
- Compromiso del sistema: Los actores de amenazas pueden alterar la configuración de seguridad, crear cuentas de puerta trasera y deshabilitar las funciones de seguridad críticas.
- Interrupción del servicio: Los cambios no autorizados pueden provocar interrupciones y afectar a la funcionalidad para los usuarios finales.
- Daño a la reputación: Un incidente de seguridad puede afectar gravemente el negocio y la marca de una organización.
La MFA reduce significativamente el riesgo de estos resultados al requerir un segundo factor de verificación además de una contraseña, como una contraseña de un solo uso basada en el tiempo (TOTP) de una aplicación de autenticación móvil, un escaneo de huellas dactilares o un token de hardware. Si bien Okta solo exige MFA con dos factores de conocimiento, posesión o inherencia, Okta recomienda encarecidamente a los administradores que abandonen las contraseñas y habiliten los autenticadores más seguros disponibles, que incluyen autenticadores resistentes al phishing como Okta Verify FastPass y autenticadores FIDO2 WebAuthn.
Okta proporciona funciones sólidas para aplicar MFA para el acceso administrativo. Todos los tenants de Okta vienen con un número de referencia de factores admitidos, como Okta Verify TOTP, FastPass y correo electrónico, además de contraseñas. Okta también proporciona una política flexible que permite a los administradores aplicar MFA específicamente a la consola de administración de Okta.
La política de aplicación para la consola siempre ha requerido la Autenticación Multifactor (MFA) por defecto. Sin embargo, a los administradores se les permitía degradar la configuración a la autenticación de un solo factor (1FA), lo que muchos optaron por hacer por varias razones. Ahora, Okta evita que esta postura de seguridad predeterminada se degrade, y hemos ayudado a todos los clientes existentes a elevar su postura de seguridad con MFA.
Cómo convencimos a los clientes de Okta para que aplicaran MFA
Profundicemos en cómo ayudamos a los administradores a superar su necesidad real y percibida de mantener las políticas 1FA y adoptar MFA para asegurar el acceso a la Okta Admin Console. En general, los clientes aceptaron que MFA era algo bueno para inculcar. Sin embargo, había varias razones comunes por las que creían que tenían que permanecer en el nivel de garantía 1FA:
- Los administradores no sabían que tenían reglas de política que permitían el acceso de 1FA.
- Los administradores pensaron que no necesitaban MFA ya que guardaban sus contraseñas en bóvedas y las rotaban con cada uso.
- Los administradores completaron la MFA con un proveedor de identidad (IdP) diferente a Okta y se estaban federando en la Consola de administración de Okta.
- Los administradores tenían cuentas de prueba automatizadas que necesitaban iniciar sesión en la consola.
- Los administradores estaban preocupados por las operaciones de los agentes del Protocolo Ligero de Acceso a Directorio (Lightweight Directory Access Protocol, LDAP) y Active Directory (AD).
Nos esforzamos en abordar cada uno de estos obstáculos e inquietudes. Ese último problema fue bastante fácil de abordar con una simple confirmación de que no habría ningún impacto en las operaciones normales de los agentes.
Sin embargo, en cuanto al resto, primero publicamos advertencias a los administradores si tenían un inquilino con alguna regla que permitiera el acceso 1FA a través de nuestra función HealthInsights.
También publicamos advertencias de la política de Okta Admin Console, destacando estas reglas infractoras.
Para los administradores que creían que no necesitaban MFA ya que guardaban y rotaban sus contraseñas con regularidad, reforzamos que la protección MFA es superior. Si bien los clientes deben continuar guardando y rotando sus secretos, también deben agregar un requisito de factor adicional, específicamente un factor de posesión o biométrico. Si las contraseñas almacenadas se compartieron con varios usuarios, recomendamos que cada usuario tenga su propia cuenta única.
En cuanto a otros clientes, algunos han optado por completar la MFA en un IdP externo y federarse en la consola de administración de Okta. Hasta hace poco, Okta trataba esa federación entrante como un solo factor. Sin embargo, ahora tenemos una nueva función llamada claims sharing. El IdP puede enviar notificaciones de AMR basadas en estándares dentro de la respuesta SAML u OIDC, y Okta respetará los factores completados con el otro IdP como satisfactorios para la garantía de MFA. Por lo tanto, se eliminó otro obstáculo.
Para los clientes con cuentas de prueba automatizadas que iniciaban sesión en la consola para completar las pruebas, los administradores creían que proporcionar un factor adicional no sería posible para tales cuentas. Okta abordó este problema recomendando que las cuentas de prueba se registren en un factor TOTP y guarden el secreto compartido junto con la contraseña. Después de revisar la contraseña, el secreto compartido también se puede revisar y utilizar para generar programáticamente el TOTP en el momento del inicio de sesión.
Con todos estos desafíos de los clientes resueltos, nuestros clientes estaban listos para actuar.
Preparándose para implementar los cambios
Dado el gran número de tenants de Okta con los que estábamos tratando, que iban desde tenants de prueba gratuita y para desarrolladores hasta tenants con implementaciones grandes y complicadas, fue necesario escalonar el lanzamiento para ayudar a garantizar una interrupción mínima de las operaciones normales. Por lo tanto, empleamos varias tácticas para aplicar cuidadosamente la Autenticación Multifactor (MFA) a la consola de administración de Okta:
- Anunciar la iniciativa: además de los anuncios públicos y los blogs que indicaban la inminente aplicación de MFA, publicamos guías y banners en el producto en los portales de soporte y desarrolladores de Okta y enviamos correos electrónicos dirigidos a los administradores para informarles sobre los próximos cambios.
- Evitar la creación de todas las nuevas políticas de acceso 1FA: Como primer paso, Okta implementó cambios en todos los tenants para que no se pudiera establecer ninguna nueva política de acceso 1FA. La idea era detener el sangrado antes de que se implementara la solución completa.
- Dividir a los clientes en cohortes para la aplicación de MFA: Para mitigar el riesgo de una avalancha de tickets de soporte a Okta y evitar bloqueos administrativos innecesarios, implementamos este cambio por cohortes de clientes. Primero examinamos las configuraciones de cada inquilino y los agrupamos según los pasos de remediación que requerirían para aplicar la Autenticación Multifactor (MFA). Luego seleccionamos diferentes fechas de aplicación para cada cohorte y preparamos instrucciones de remediación específicas.
Se les indicó a los administradores que modificaran sus políticas de Okta Admin Console de las siguientes maneras:
- Las reglas con garantía de solo contraseña deben modificarse para requerir una contraseña y otro factor.
- Las reglas con cualquier garantía 1FA o garantía de solo factor de posesión deben modificarse para requerir dos factores.
Una vez que se realizó el cambio, los administradores no pudieron volver a degradar la garantía 1FA. Si un administrador no tomó medidas, Okta aplicó la MFA a la consola para ese inquilino en una fecha claramente comunicada.
Los clientes de Okta se pusieron en marcha hacia MFA
Dentro de los primeros cuatro meses del lanzamiento, Okta completó la aplicación de MFA en el 99% de todos los tenants aplicables. El 1% restante eran tenants que requerían soporte adicional de Okta, ya sea en forma de mejoras de funciones, como el uso compartido de notificaciones, o tiempo para actualizar varios procesos para operar en este nuevo nivel de seguridad requerido. Okta se mantuvo en contacto con este grupo de clientes para comprender profundamente sus puntos débiles y colaborar con ellos hasta que se sintieron seguros de avanzar en esta nueva dirección.
Con la aplicación de MFA al 100% a la consola de administración de Okta, los administradores ahora están aprovechando una variedad de factores y autenticadores para iniciar sesión en la consola. Los tres factores principales utilizados incluyen la contraseña, las notificaciones push de Okta Verify y Okta FastPass. Las combinaciones comunes de estos factores utilizados para completar un desafío de MFA incluyen la contraseña y el push de Okta Verify, así como la contraseña y Okta FastPass.
Hoy en día, el acceso MFA a la Okta Admin Console es un requisito no negociable para todos los administradores de Okta actuales y los recién incorporados. Al adoptar esta postura segura de forma predeterminada, los clientes se benefician de una superficie de ataque reducida y una mayor protección de la infraestructura de identidad crítica.
Obtén más información sobre el producto MFA de Okta visitando la página web de Adaptive MFA. Mantente al tanto de lo que Okta está haciendo para luchar contra los ataques basados en la identidad informándote sobre el Compromiso de Okta con la Identidad Segura.
