Single Sign On: Preguntas que hacer

El abuelo siempre decía: “Nunca pruebes nada nuevo. Espera a ver si primero mata a alguien”. Recientemente, he estado involucrado en llevar a cabo varios proyectos de Single Sign On, y sus palabras han estado rondando constantemente en el fondo de mi mente. Una parte de mí dice: “Es una mala idea tener solo un nombre de usuario y contraseña para acceder a todo”. Si ocurre un ataque de hackers, el intruso se apodera de sus cosas, tienen acceso a todo. Pero la otra parte lo mira y dice: “A los usuarios les va a encantar esto”. Es una situación clásica de ser estúpido si lo haces, y estúpido si no lo haces. Entonces, ¿qué haces?

¿Qué es el Single Sign On?

Cuando uno observa por primera vez el Single Sign On (SSO) desde la perspectiva de alguien conocedor en seguridad, pero sin entender completamente de qué se trata, el SSO parece un suicidio a nivel empresarial. El propio nombre, Single Sign-On, evoca imágenes de usar un solo conjunto de credenciales para todo, pero la realidad es que está diseñado para facilitar la vida de los usuarios, sin comprometer la seguridad. Lo que estás haciendo es aprovechar algo llamado SAML (Security Assertion Markup Language, nada menos). Este es un formato de datos de código abierto basado en XML que nos permite intercambiar datos de autenticación y autorización entre diferentes aplicaciones o entidades. De hecho, refuerza un poco las cosas al agregar otra capa, por así decirlo, al aprovechar la información del usuario de AD o LDAP.

Así que hemos mejorado la seguridad vinculando cómo afectan los derechos ya otorgados en AD. En la mayoría de los casos, si hay un nombre de usuario/contraseña separados asociados con una aplicación, se introduce una vez, y la aplicación SSO nos da acceso. Suena un poco aterrador, pero ten en cuenta que los bloqueos típicos de AD aún funcionan, y tenemos el beneficio adicional de que si la cuenta está comprometida, la mayoría del software SSO viene con algunas características de informes realmente potentes. Así podemos detectar cuentas comprometidas y datos accedidos.

Preguntas que hacer antes de comprometerse con Single Sign On

Voy a hacer de abogado del diablo aquí y hacer la pregunta que todos tienen en mente. ¿Qué tan seguro es realmente?

Bueno, como el Diablo, voy a mantenerte en suspenso con la respuesta y decir, estaremos revisando eso en las próximas semanas. Por ahora, supongamos que quieres implementar Single Sign On en tu organización. Si deseas SSO en tu organización, aquí hay un par de cosas en las que pensar.

Primero en la lista, ¿estamos hablando de algo nuevo o de una actualización? Muchas veces se trata de un nuevo producto SSO que reemplaza a uno antiguo. Ahí mismo, necesitas comenzar a pensar en capacitación y comunicaciones. Comunicaciones, para que los usuarios sepan qué está sucediendo, capacitación (incluso si solo es un video en línea) sobre cómo usar el nuevo producto.

¿Qué estamos intentando hacer con ello? ¿Estamos tratando de centralizar el acceso? ¿Intentando mejorar la seguridad mejorando la autorización? ¿O qué tal simplemente una auditoría básica? Tal vez estemos tratando de lograr las tres cosas. La conclusión es que ciertamente ayuda a realizar un proyecto exitoso cuando sabes qué esperar al final de todo.

Decidir qué aplicaciones queremos proporcionar acceso desde el principio es muy importante. La mayoría de las aplicaciones funcionarán bien con un SSO, pero otras no. Las “otras” podrían complicarte mucho la vida e involucrar a terceros y más de un poco de creatividad para hacerlas funcionar. Así que espéralo.

¿Quién se va a encargar de ello? Alguien tiene que ser responsable del sistema, y puede involucrar a varias personas en diferentes niveles de la empresa para manejarlo. Por ejemplo, en un proyecto reciente de SSO, yo fui responsable de configurarlo en los servidores, ayudar a gestionar el proyecto y realizar las aplicaciones iniciales y el registro de usuarios. Pero se determinó desde el principio que, en el futuro, los nuevos usuarios serían añadidos por el personal de Nivel 1. Así que tuvimos que capacitarlos al menos hasta ese punto. Sin embargo, las aplicaciones, así como el cuidado y mantenimiento de los servidores (sin mencionar futuras actualizaciones y DR) quedarían firmemente en mis manos.

Probablemente la pieza más importante que necesitamos vigilar es si el SSO que compramos continúa creciendo y evolucionando a medida que la empresa crece y evoluciona.

Y como solían decir allá por los años 60, no toques el dial.