Los d铆as en los que los empleados se sentaban en sus puestos de trabajo e interactuaban exclusivamente con aplicaciones nativas han pasado, pero no se han olvidado: persiste a煤n el legado de las contrase帽as 煤nicas para servicios/aplicaciones, lo que agrava las frustraciones tanto de los administradores de TI como de los usuarios.
Esto es especialmente cierto en el caso de las infraestructuras en la nube, donde la exposici贸n de las credenciales a trav茅s de la red y la posibilidad de una multitud de contrase帽as d茅biles dificulta la productividad de los usuarios y aumenta los riesgos. Existe una soluci贸n mejor: El inicio de sesi贸n 煤nico (SSO, por sus siglas en ingl茅s).
驴Qu茅 es el inicio de sesi贸n 煤nico (SSO)?
El SSO es una soluci贸n que muchas grandes organizaciones han adoptado para modernizar la autenticaci贸n y la gesti贸n de identidades, as铆 como para lograr una incorporaci贸n y salida de empleados sin fricciones. Al principio se utiliza una contrase帽a 煤nica y segura, pero luego las cosas empiezan a funcionar de forma muy diferente.
SSO utiliza SAML, un mecanismo que comparte identidades entre organizaciones y aplicaciones. SAML no env铆a contrase帽as a trav茅s de la web para cada inicio de sesi贸n, sino que utiliza un sistema de tokens seguros que reduce los riesgos de seguridad cuando se aplica correctamente. En pocas palabras, un futuro “sin contrase帽as” con est谩ndares de autenticaci贸n modernos como SAML y OAuth es algo que deber铆a estar en su hoja de ruta.
Quiz谩 se pregunte por qu茅 la adopci贸n de SSO no es universal. La respuesta es complicada: muchas peque帽as y medianas empresas (PyMEs) se encuentran inmersas en entornos de directorios heredados que utilizan el protocolo de red Kerberos para asegurar la autenticaci贸n en las redes locales.
Funcionaba bien en ese escenario, pero las infraestructuras de TI de hoy en d铆a no son todas locales y utilizar contrase帽as para autenticarse en cada servicio es esencialmente resolver un problema con otro. La mentalidad centrada en contrase帽as que Kerberos estableci贸 se ha vuelto perjudicial para la seguridad, y es complejo y arriesgado utilizarlo para despliegues entre dominios (lo que significa que si A conf铆a en B y B conf铆a en C, A podr铆a confiar en C).
Tambi茅n descubrir谩 que este complicado protocolo heredado es dif铆cil de arreglar, verificar las garant铆as de seguridad y tiene el potencial de delegar permisos sin restricciones. Los resultados m谩s perniciosos de esta deuda t茅cnica son: la dif铆cil gesti贸n de contrase帽as, el riesgo de la reutilizaci贸n de contrase帽as y las violaciones de datos que exponen esas credenciales.
Todas estas cosas aumentan los riesgos (no aceptados), haciendo que sea m谩s probable que se produzcan violaciones de datos. El SSO es una forma moderna y sencilla de abordar todos estos problemas, pero su configuraci贸n lleva cierto tiempo.
Sinceramente, “SSO es dif铆cil de probar” es otro refr谩n com煤n. Usted no codificar铆a un sitio web sin ver el producto y realizar pruebas de agitaci贸n antes de entrar en producci贸n. Su marca, reputaci贸n y satisfacci贸n del usuario se ver铆an perjudicadas, y no tiene sentido hacerlo. Lo mismo ocurre con el SSO:
- A nivel de infraestructura, se intercambia informaci贸n relacionada con los puntos finales, la seguridad y la privacidad,
- A nivel de 辫谤别蝉别苍迟补肠颈贸苍, se crea una 煤nica credencial para la experiencia de inicio de sesi贸n.
Los recursos de prueba no suelen estar a disposici贸n del p煤blico o son pruebas de duraci贸n limitada que pueden no coincidir con su cronograma.
No espere: el SSO debe ser una prioridad.
Antes de empezar: la importancia del SSO como requisito b谩sico de seguridad no siempre es evidente a primera vista. La inmensa mayor铆a de los son “drive-bys” en los que los atacantes se aprovechan de una higiene inform谩tica deficiente, como contrase帽as d茅biles.
Las complicadas Amenazas Persistentes Avanzadas (APT, por sus siglas en ingl茅s) no suelen ser lo que expone a los datos y usuarios de una empresa; lo es la falta de proactividad y de adopci贸n de soluciones modernas. A esto hay que a帽adir la dificultad de gestionar credenciales y permisos de usuario dispares, lo que provoca dolores de cabeza a los administradores de TI s贸lo de pensarlo. La filtraci贸n de Colonial Pipeline es un ejemplo de ello y fue consecuencia de a las que el departamento de TI hab铆a perdido la pista.
Los IdP y los recursos de pruebas f谩cilmente accesibles le permiten “hacerlo ahora”, en lugar de posponer un proyecto de alta prioridad. Una matriz de prioridades estandarizada le ayudar谩 a argumentar internamente, bas谩ndose en un sistema que clasifica todos sus proyectos con un entendimiento mutuo entre los supervisores de TI y de nivel C, teniendo en cuenta el presupuesto y la urgencia.
Un uso juicioso de todas las capacidades de su IdP, como el SSO, contribuir谩 en gran medida a salvaguardar su organizaci贸n. La adopci贸n de SSO debe ser una prioridad dentro de su evaluaci贸n de cualquier plataforma para el directorio y la autenticaci贸n, lo cual es posible mediante la utilizaci贸n del SAML Test Service Provider (SP) gratuito.
Permite evaluar completamente la soluci贸n SSO antes de realizar una compra, lo que favorece su experiencia, as铆 como la confidencialidad, integridad y disponibilidad de los activos de TI que son vitales para su empresa. Una brecha cuesta mucho m谩s que un SSO. Utilizar el SP de prueba es f谩cil, y se describe en detalle a continuaci贸n.
Ahora, a trabajar en las pruebas.
El proveedor de servicios de pruebas SAML y la selecci贸n de proveedores
- Existen tres entidades a considerar al iniciar su proyecto SSO:El proveedor de identidades (IdP, por sus siglas en ingl茅s), es decir, un directorio de usuarios y capacidades de autenticaci贸n.
- El proveedor de servicios (SP, por sus siglas en ingl茅s), o aplicaci贸n web
- Un usuario que tiene una cuenta y una identidad establecidas en el IdP.
Las herramientas de prueba tambi茅n ayudan, y un servicio gratuito llamado est谩 disponible de forma gratuita para acelerar sus esfuerzos de SSO. Muchos IdP no se muestran dispuestos a proporcionar un entorno de pruebas, as铆 que sea diligente a la hora de elegir el suyo. Tambi茅n es importante tener en cuenta el soporte de SSO al seleccionar un proveedor de servicios. Los SP pueden convertirse en un obst谩culo para la adopci贸n de SSO cuando los precios se aprovechan de su deseo de mejores pr谩cticas de seguridad.
El SSO es una necesidad cr铆tica para las organizaciones con m谩s de 5 miembros, no un lujo, pero capacidades como la compatibilidad con SAML suelen estar vinculadas a niveles de servicio superiores dentro de las aplicaciones web (tambi茅n denominados anteriormente proveedores de servicios).
A esto se le conoce informalmente como 鈥溾��, y hace que los proyectos resulten m谩s dif铆ciles de justificar cuando los costos se multiplican.Utilice un proveedor de servicios que ofrezca SSO como una caracter铆stica b谩sica del producto; de lo contrario, esta capacidad vital puede estar fuera del alcance del presupuesto de su organizaci贸n.
Otro punto problem谩tico com煤n al que se enfrentar谩 el proveedor de servicios de pruebas es la preparaci贸n: SAML convierte la migraci贸n en una propuesta de “todo o nada”. Todos los usuarios deben autenticarse a trav茅s de SSO desde el principio, por lo que probar su implementaci贸n con suficiente antelaci贸n dar谩 sus frutos con un recurso de formaci贸n f谩cilmente disponible, lo que permitir谩 a los usuarios obtener un nivel b谩sico de comodidad y competencia con el proceso de inicio de sesi贸n en el portal antes del cambio.
Primeros pasos con SAML Test Service Provider
Existen dos formas de realizar las pruebas:SSO iniciado por IdP y SSO iniciado por SP. 黑料海角91入口 es el IdP en este ejemplo en combinaci贸n con el proveedor de pruebas gratuito.
SSO iniciado por IdP
SAML y metadatos IdP:
El paso inicial para utilizar el proveedor de servicios de prueba es a trav茅s del m茅todo iniciado por el IdP. Puede obtener metadatos SAML del SP de prueba, que est谩n . Los metadatos son informaci贸n que describe el servicio para que su IdP pueda consumirlo.
Su IdP dispondr谩 de una interfaz para crear un gen茅rico (nota: los IdP suelen disponer de una biblioteca de conectores prefabricados listos para los servicios m谩s utilizados). Este paso integrar谩 su IdP con la herramienta de pruebas SAML con una configuraci贸n predeterminada.
se describe la posibilidad de personalizar su aspecto. Sin embargo, no es necesario personalizar nada para realizar pruebas funcionales b谩sicas con la herramienta gratuita. He 补辩耻铆 algunos recursos que desmitificar谩n el inicio de este proceso:
SSO iniciado por SP
Utilice los metadatos de su IdP
El paso de metadatos es un prerrequisito para el SSO iniciado por SP. Seguir谩 un procedimiento similar para el SSO iniciado por SP descargando (o cortando y pegando) los metadatos del IdP en la herramienta de pruebas. El resultado ser谩 la creaci贸n de una URL 煤nica que utilizar谩 para iniciar sesi贸n durante las pruebas.
URL de prueba
La URL se asigna de nuevo al IdP, que hace el trabajo pesado para toda la gesti贸n de identidades y autenticaci贸n. Las instrucciones hacen hincapi茅 en guardar en favoritos esa URL y en que al acceder a ella se enviar谩 una SAML AuthNRequest a su IdP, que no es m谩s que un mensaje enviado desde el SP solicitando autenticar la sesi贸n de un usuario determinado.
El proceso de importaci贸n de metadatos del IdP debe repetirse dentro de la herramienta si lo pierde, por lo que se le aconseja tenerlo a la mano durante toda la duraci贸n de la prueba (no se preocupe, hay instrucciones detalladas en la p谩gina web del servicio de pruebas). Lo m谩s importante es contar con un IdP que le permita experimentar a su propio ritmo.
Formas de autenticar SSO
El sitio de pruebas incluye informaci贸n adicional, pero tambi茅n cuenta con un “AuthNRequest Wizard” una vez que un usuario se autentica con 茅xito que se muestra en la parte superior de la p谩gina. Puede utilizarlo para determinar un m茅todo espec铆fico de autenticaci贸n desde el IdP (AuthenticationContextClassRef) o marcar que la autenticaci贸n inicial ha tenido lugar para que el IdP pueda entonces seleccionar un factor m谩s fuerte para aumentar su seguridad.
Es muy recomendable utilizar la MFA (autenticaci贸n multi-factor), pero siempre hay que tener en cuenta el lado humano de la implementaci贸n y el uso cotidiano. Diferentes formas de autenticaci贸n son m谩s f谩ciles y otras son m谩s dif铆ciles de dominar para el usuario. Las notificaciones push suelen describirse como las m谩s f谩ciles de usar.
Atributos y personalizaciones del SSO
Elija un color, cualquier color
Querr谩 un portal que los usuarios reconozcan inmediatamente y en el que conf铆en con la marca y el esquema de color adecuados. La herramienta de prueba tiene una funci贸n llamada “RelayState” que personaliza la apariencia de la p谩gina protegida; establece el atributo a un color compatible en el lado del IdP (NameID) o desencadena un cambio de color sin modificar la configuraci贸n a帽adiendo la URL 煤nica del sitio de prueba — por ejemplo, “https://sptest.iamshowcase.com/protected?color=blue”.
Mensajes de bienvenida del SSO y otras personalizaciones
NameID, una declaraci贸n de atributo SAML, es donde se establecen otras personalizaciones, como un mensaje de bienvenida. Puede encontrar informaci贸n adicional sobre atributos (descarga de PDF). El sitio de pruebas proporciona el siguiente ejemplo espec铆fico de la herramienta:
“Hola <nombre> <apellido>”
Para rellenar <nombre> y/o <apellido>, intentar谩 encontrar un atributo llamado “givenname” o “firstname” para <nombre> y “sn”, “lastname”, “surname” o “name” para <apellido>. Todo esto ignora totalmente las may煤sculas o min煤sculas del nombre del atributo, por lo que givenName, Givenname, givenname, GiVeNnAmE son todos lo mismo (si crees que GiVeNnAmE es una buena idea… 隆te saludamos!).
Integridad del usuario
Tenga en cuenta que la herramienta de prueba es s贸lo para fines de demostraci贸n y que algunas caracter铆sticas avanzadas de seguridad no son compatibles en este momento, incluyendo y cifradas, que son los datos que se comunican entre el SP y el IdP sobre el estado de autorizaci贸n del usuario (lo que significa que usted es un usuario leg铆timo). Los detalles sobre atributos y declaraciones de atributos se encuentran en la herramienta de pruebas.
Cumplimiento y conservaci贸n de datos para SSO
Tambi茅n es posible que desee registrar todas las autenticaciones SAML por motivos de cumplimiento si pertenece a un sector regulado o si sus analistas de seguridad y administradores de TI realizan un seguimiento del acceso a los recursos. Los reg铆menes de cumplimiento espec铆ficos exigen el registro del acceso de puntos finales designados, como: Cumplimiento de PCI DSS para entornos de datos de titulares de tarjetas (CDE); HIPAA e informaci贸n de salud personal (PHI); y la amplia visi贸n de GDPR de los datos almacenados para residentes en la UE.
颁辞苍肠濒耻蝉颈贸苍
El proveedor de servicios de prueba de SAML elimina los obst谩culos para adoptar SSO, junto con un IdP que ofrece un entorno sandbox (de prueba) que se ajusta a los plazos de su proyecto. Es aconsejable considerar si un SP (aplicaci贸n web) proporciona soporte nativo y gratuito de SAML SSO antes de seleccionar ese proveedor. El riesgo y el gasto de no hacer SSO es menos aceptable como:
- Su organizaci贸n crece
- Consume m谩s servicios
- La autenticaci贸n Kerberos y las contrase帽as heredadas resultan inadecuadas para los servicios en la nube,
- El entorno de las amenazas a la ciberseguridad es cada vez m谩s dif铆cil de controlar y analizar.
Las pruebas son importantes para estar preparados para el cambio a SAML, que es global y podr铆a interrumpir las operaciones sin la adecuada aceptaci贸n y formaci贸n de los usuarios.
Las ventajas del SSO son esenciales para la infraestructura en la nube y no deben quedar relegadas al dominio de las grandes empresas con mayores presupuestos. Puede utilizar una plantilla de matriz de prioridades para determinar qu茅 lugar debe ocupar el SSO en su agenda de TI: los resultados pueden sorprenderle.
Puede probar el de forma gratuita iniciando una prueba hoy.
