Sean Deuby

Y en el caso de las contraseñas, cada una -especialmente cada una olvidada- es un pequeño riesgo para la seguridad que se escabulle entre las sombras. Puede que creas que te has librado de ellas (o al menos las has reducido a una cantidad manejable), pero siguen apareciendo. Y como todos sabemos, las aplicaciones SaaS, ya sean aplicaciones personales o sociales como Facebook o las miles de aplicaciones empresariales que se utilizan hoy en día, han provocado que este problema, bueno... se multiplique rápidamente.

La principal razón por la que las ofertas de gestión de identidades como servicio (IDaaS), como Azure Active Directory, Okta y otras, son tan populares hoy en día es porque permiten el inicio de sesión único (SSO) en aplicaciones SaaS desde el navegador del usuario. También proporcionan una mayor seguridad mediante la gestión de estos userids y contraseñas. El usuario simplemente accede a un portal de la empresa que tiene iconos que representan las aplicaciones y hace clic en un icono para iniciar sesión.

Aunque esta capacidad es una mejora con respecto a un inicio de sesión no gestionado, sigue habiendo importantes riesgos de seguridad que debes conocer.

Gestión de contraseñas SaaS: Vaulting y Replay

En primer lugar, un poco de información sobre cómo las aplicaciones IDaaS manejan las credenciales del sitio web.

Las aplicaciones SaaS empresariales más grandes y populares de la actualidad, como Salesforce, Workday, Concur y varios cientos más, admiten la federación de identidades, lo que simplifica enormemente el inicio de sesión en una aplicación y aumenta su seguridad. Sin embargo, la gran mayoría de las aplicaciones SaaS del mercado requieren un identificador de usuario y una contraseña para iniciar sesión desde el navegador del usuario, una tarea engorrosa plagada de contraseñas olvidadas, contraseñas demasiado simples y blocs de notas con contraseñas escritas.

Los servicios IDaaS utilizan dos técnicas principales para ocuparse de esto por el usuario. En primer lugar, cuando un usuario inicia sesión en uno de estos sitios de "cumplimentación de formularios", una extensión de captura de contraseñas en su navegador le pregunta si desea almacenar sus credenciales en el almacén de contraseñas del servicio IDaaS. En segundo lugar, la próxima vez que el usuario quiera iniciar sesión en la aplicación SaaS, la extensión del navegador se comunica con el servicio IDaaS para reproducir las credenciales del usuario en los campos de identificación de usuario y contraseña, iniciando así la sesión sin ninguna acción por parte del usuario.

Las contraseñas que se perdieron

El almacenamiento de contraseñas simplifica en gran medida el inicio de sesión en estas aplicaciones, sobre todo si se compara con el usuario que intenta hacer un seguimiento de todo por sí mismo. Pero se trata de un enfoque de la seguridad de mascar chicle y tirar del cable por cinco razones.

  • En primer lugar, significa que las credenciales del usuario se almacenan en el servicio en la nube del proveedor de IDaaS, lo que es un no-no para las políticas de seguridad informática de muchas empresas.
  • En segundo lugar, por muy cifradas que estén las credenciales en la nube, deben transmitirse sin cifrar a la aplicación SaaS durante el proceso de reproducción. No hay forma de evitarlo. En tercer lugar, las páginas de inicio de sesión del usuario de la aplicación cambian de diseño todo el tiempo, por lo que el proveedor de IDaaS debe tratar de mantenerse al día con miles de estos cambios para que la repetición de la contraseña funcione correctamente.
  • En cuarto lugar, en la mayoría de los casos el usuario conoce su nombre de usuario y contraseña para la aplicación. (Sin duda los conocían antes de que tuvieran que acceder a la aplicación a través del portal de usuarios de la empresa). Esto significa que siempre pueden dar una vuelta al portal e iniciar sesión directamente. Si se trata de una nueva aplicación en servicio, algunos proveedores de IDaaS permiten que el administrador cargue las credenciales del usuario para que éste no las conozca y deba utilizar el portal, pero esto sólo funciona para la incorporación de nuevas aplicaciones. Algunos proveedores de IDaaS tienen una capacidad limitada para cambiar la contraseña de algunas aplicaciones, y algunos pueden ofuscar la URL de inicio de sesión de la aplicación, pero son una pequeña minoría. Para empeorar la situación, navegadores como Chrome o complementos de navegador como LastPass ofrecen guardar la contraseña del usuario cuando inicia sesión. ¿Y por qué no querría el usuario medio guardar la contraseña para no tener que volver a introducirla?

Por último, y lo más importante, las aplicaciones SaaS no están vinculadas al sistema de gestión del ciclo de vida de la identidad corporativa. ¿Qué significa esto? Significa que si se despide a un empleado y se desactiva su cuenta en su AD DS local, el usuario ya no podrá iniciar sesión en la red de la empresa ni acceder a sus recursos. Cuando esa desactivación se replica en el servicio IDaaS, el usuario no puede acceder a ningún recurso en la nube que requiera el servicio IDaaS, como aplicaciones federadas (Salesforce, Office 365). Esto es una bondad y hace feliz a la gente de seguridad.

Pero las aplicaciones SaaS de formulario no dependen de sus credenciales corporativas como lo hacen las aplicaciones SaaS federadas. Cuando se desactiva o elimina una cuenta de usuario AD DS, no ocurre nada en esa aplicación SaaS. No tiene ni idea de lo que ha ocurrido en la empresa. A menos que alguien tome la acción explícita de auditar a qué aplicaciones tiene acceso el usuario, y las deshabilite manualmente en cada aplicación, el usuario puede entrar. ¿Por qué? Todo lo que el usuario necesita es su nombre de usuario, contraseña y la URL de inicio de sesión de la aplicación.

Debo señalar que estos problemas no son culpa del proveedor de IDaaS; están haciendo lo mejor que pueden, utilizando diversas técnicas de humo y espejismo, para suavizar los fallos inherentes al escenario de inicio de sesión de aplicaciones SaaS rellenando formularios.

En resumen, el aprovisionamiento de usuarios a aplicaciones es relativamente sencillo. Desabastecerlos es otro asunto completamente distinto.

 Qué pueden hacer las organizaciones

Se trata de un problema muy difícil de solucionar con carácter retroactivo. En lugar de eso, hay que adelantarse:

  • Audite las aplicaciones SaaS a las que tiene acceso un usuario, almacenadas en una base de datos centralizada de derechos para saber a qué tiene acceso cada uno. Se trata más de un problema de políticas y procesos que de tecnología.
  • Utiliza la directiva de grupo para desactivar el gestor de contraseñas de Chrome.
  • Cuando sea posible, utilice una opción que genere y almacene automáticamente la contraseña del usuario para que éste no la conozca.
  • Cuando su organización esté evaluando aplicaciones SaaS, el inicio de sesión federado debe ser un requisito, no un "bonito detalle". Asegúrese de que el ISV lo sabe. Solo los requisitos de los clientes (es decir, las ventas) impulsan a los ISV a realizar cambios.

Los proveedores de IDaaS pueden ser un gran beneficio para sus usuarios al proporcionar SSO a muchas aplicaciones SaaS a través de un único portal de usuario y múltiples factores de forma. También son una gran ventaja para la seguridad de la información porque proporcionan cierto grado de gestión centralizada de estas aplicaciones. Sin embargo, hay que tomar medidas para que sea una solución segura.