Single-Sign-On Índice de contenido

Transcripción

1 Single-Sign-On Índice de contenido Introducción...2 Que es Single Sign-On...2 Descripción del esquema y componentes...2 Kerberos...3 LDAP...5 Consideraciones de Seguridad...6 Alcances de la solución implementada

2 Introducción El objetivo de este documento es presentar a un nivel de detalles técnicos adecuado como para que resulte comprensible por personal no técnico, el esquema de Single-Sign-On implementado como parte del Proyecto Munix en la Municipalidad de Rosario. Que es Single Sign-On Tal como indica el significado del término, Single Sign-On hace referencia a la posibilidad de que los usuarios de sistemas informáticos realicen por única vez el procedimiento de identificación y autenticación para el acceso a los diferentes servicios brindados dentro de la infraestructura informática local. El mecanismo habitual para lograr esta funcionalidad es que el procedimiento de identificación y autenticación de como resultado un conjunto de credenciales que pueden ser posteriormente utilizadas para demostrar la identidad de los usuarios en el acceso a los diferentes servicios, sin necesidad de volver a proporcionar la información de autenticación. A continuación se describe el esquema y el software utilizando para implementar esta solución dentro de Municipalidad de Rosario. Descripción del esquema y componentes En el área de Seguridad Informática de la Municipalidad de Rosario se estudiaron varias alternativas disponibles en software libre para hacer frente al cada vez más frecuente reclamo de los usuarios de tener una contraseña única para el acceso a todos los servidores. Se valoró particularmente la posibilidad de que, además de ser única, dicha contraseña sea ingresada sólo una vez al día (excepto bloqueo intencional o por inactividad de las sesiones), como parte del procedimiento de identificación y autenticación, y permita a los usuarios trabajar en todos los servidores autorizados sin necesidad de volver a ingresarla. Es decir, que el procedimiento de identificación y autenticación sea contra la infraestructura informática local y no contra cada servidor en particular. Como resultado de ese estudio se determinó que la solución mas conveniente, considerando las diferentes variantes de sistemas operativos existentes, consistía en utilizar las siguientes herramientas: Kerberos (versión 5) como servicio de autenticación y de Single-Sign-On, y LDAP como servicio de directorio para tener un repositorio centralizado con la información de las cuentas de usuarios, y como solución de contingencias ante la falla del primero. A continuación se detallan brevemente cada una de estas herramientas. 2-7

3 Kerberos Kerberos es un servicio cuyo objetivo es desempeñar el rol de un tercero confiable dentro de la infraestructura informática local. Se compone por una base de datos con información de autenticación centralizada, junto con varios servicios que interactúan con esta base de datos para permitir que los usuarios puedan ser autenticados sin necesidad de transferir contraseñas en formato plano por la red, (evitando de esta forma que las mismas puedan ser interceptadas utilizando técnicas de hacking. Ej: sniffing), con la ventaja adicional de que, tal como se menciono anteriormente, el resultado del procedimiento de identificación y autenticación de usuarios da como resultado un conjunto de credenciales que pueden ser posteriormente utilizadas para demostrar la identidad en el acceso a servicios, sin necesidad de volver a ingresar una contraseña. Las credenciales otorgadas por kerberos reciben en la práctica el nombre de tickets, dado que el funcionamiento del servicio tiene correspondencia con el uso de tickets en la vida cotidiana, así que en adelante nos referiremos a estas credenciales utilizando la palabra ticket. Para describir mejor la forma en que opera Kerberos para ofrecer single-sign-on, se presenta la siguiente figura en donde se observan los componentes involucrados y la interacción entre ellos, que se explica a continuación: Kerberos TGS Usuario/ Cliente 5 Servidor La interacción indicada por los números 1 y 2 en la figura es la que esquematiza el procedimiento de identificación y autenticación. Este procedimiento se realiza una única vez por sesión y se compone de dos pasos: En primer lugar (flecha 1) el usuario envía al servidor Kerberos los datos necesarios (entre ellos el login, o nombre de usuario) como para permitirle al servidor identificar al usuario, y utilizar la información almacenada en su base para autenticar que realmente el usuario es quien dice ser. 3-7

4 Para ello, la información que se almacena en la base de datos del servicio Kerberos es justamente un secreto (contraseña) compartido únicamente entre el usuario y el servidor kerberos, de forma que este secreto pueda ser utilizado por el usuario para demostrar su identidad, y por el servicio para comprobar la identidad del mismo. En segundo lugar (flecha 2), si la cuenta es válida, es decir, si se pudo completar correctamente procedimiento anterior, el servidor Kerberos le entrega al usuario un Ticket que le permitirá comunicarse con el servidor TGS (Ticket Granting Service) para tramitar futuras conexiones a otros servidores y/o servicios. El Ticket entregado por el servidor Kerberos esta cifrado utilizando el secreto almacenado en la base de datos de autenticación, de forma que el mismo pueda ser utilizado únicamente por el usuario solicitante. Si se trata de un impostor o de alguien que capturó el ticket en su transito por la red, el mismo le será inútil si desconoce la contraseña con la que ha sido cifrado. El Ticket que obtiene inicialmente el usuario recibe el nombre de Ticket Granting Ticket (TGT), dado que podrá ser utilizado por el usuario para demostrar su identidad ante el servicio TGS de forma de conseguir los tickets necesarios para utilizar servicios disponibles en otros servidores. Para acceder a un servicio sin necesidad de volver a autenticarse, el usuario debe conseguir y presentar un Ticket específico para dicho servicio. La generación de este tipo de tickets es tarea del servidor TGS, y permite a quien lo recibe identificar al usuario y corroborar que el ticket fue emitido realmente por el servicio TGS. Las interacciones con números 3, 4 y 5 en la figura esquematizan el procedimiento de conexión a los servicios con Kerberos habilitado en cualquiera de los servidores de la Municipalidad, y se realiza tantas veces como sea necesario, según la actividad de los usuarios. Cuando un usuario desea utilizar un servicio (por ejemplo: abrir una terminal en un servidor utilizando SSH o Telnet), el cliente del servicio (comando ssh o telnet, para este ejemplo) verifica si dispone en el cache del usuario de algún Ticket obtenido con anterioridad para establecer la conexión. Si el Ticket esta disponible, se lo presenta al servidor en el que desea abrir la terminal, quien después de verificar los datos del usuario y corroborar que esta autorizado para hacer uso de ese servicio, le brinda el acceso sin necesidad de autenticación adicional. En caso de que no se disponga de un Ticket para utilizar el servicio deseado, el cliente del aplicativo tramita de forma transparente para el usuario la obtención del Ticket necesario. Para ello, se comunica con el Ticket Granting Server (TGS) utilizando el Ticket Granting Ticket (TGT) obtenido como parte del procedimiento de identificación y autenticación. Lo que hace es presentar el Ticket y una solicitud para el servicio que desea acceder (flecha 3), y el servidor TGS después 4-7

5 de verificar la validez del TGT le entrega (flecha 4) un Ticket específico para que pueda utilizar el servicio solicitado. Este último se almacena en el caché del usuario, y es utilizado en adelante para conectarse al servicio en cuestión. Cuando el usuario cierra su sesión en el servidor, el caché del usuario es eliminado. De esta forma se garantiza que abrir una nueva sesión obligue a pasar exitosamente el procedimiento de identificación y autenticación. LDAP LDAP significa Lightweight Directory Access Protocol, y tal como el nombre lo indica, se trata de un servicio de directorio, esto es, una base de datos que permite armar una estructura jerárquica con información de la organización. En Municipalidad de Rosario, este servicio cubre un rol fundamental, puesto que fue utilizado para almacenar la información de identificación de usuarios, y toda la información relacionada con la configuración de los puestos de trabajo (clientes delgados). Más aún, con el objeto de poder brindar una solución de contingencias para Kerberos, se añadió a LDAP también información de autenticación de usuarios, que se mantiene sincronizada con la información de Kerberos siempre que se modifica la contraseña de algún usuario. La información de identificación disponible en LDAP es similar a la información contenida en los archivos /etc/passwd, /etc/shadow y /etc/group del sistema operativo Linux. Entre otros atributos, se encuentran particularmente: el login, el shell que utiliza el usuario y grupos a los que pertenece. Todos los servidores de aplicaciones utilizan la misma rama dentro de la estructura jerárquica de LDAP como raíz para obtener el listado de sus usuarios, de forma que los usuarios se creen, borren y/o modifiquen en un único lugar, y los cambios automáticamente tomen efecto sobre todos los servidores de aplicaciones. Los servidores de archivos, a su vez, también comparten la misma rama de LDAP, con la diferencia de que en estos últimos esta prohibido el inicio de sesión. Está información se utiliza únicamente para asignar correctamente los permisos sobre archivos, y las cuotas de disco correspondientes. Para proveer una solución robusta y tolerante a fallas, se configuraron varias réplicas de los servidores de Kerberos y LDAP, y se desplegó la solución de forma de tolerar caídas en vínculos de comunicaciones. Los clientes de estos servicios fueron configurados de manera que accedan 5-7

6 siempre al servidor LDAP que se encuentre físicamente más cercano, y como segunda alternativa, en caso de que no se pueda acceder al servidor principal, a la réplica de Kerberos mas cercana. Para ambos servicios, las réplicas son unidireccionales, de forma que todos los cambios se realizan sobre la réplica maestra, y desde ésta se replican los cambios hacia las réplicas esclavas. Consideraciones de Seguridad La solución implementada permite a los usuarios definir (y por ende la necesidad de recordar) una única contraseña con la cual pueden acceder a los distintos sistemas administrativos municipales. Al analizar esta situación respecto de la situación anterior, aunque parezca lo contrario se logra una mejora significativa desde el punto de vista de la seguridad de la información, puesto que la situación anterior obligaba al usuario a recordar contraseñas distintas para el acceso a los diferentes sistemas y/o servicios, cada una con su cronograma de expiración particular, lo que derivaba en el uso de contraseñas fáciles de adivinar y/o contraseñas escritas en papel sobre los puestos de trabajo. El hecho de que cada usuario tenga ahora una única contraseña, permitió a los administradores imponer normas mucho mas estrictas para en control de la calidad de las contraseñas. Como parte de las medidas implementadas: 1. se fuerza una longitud mínima de 8 caracteres, 2. se acepta un cambio de contraseña sólo si la nueva tiene al menos dos clases de caracteres distintas, 3. se acepta la contraseña solo si pasó exitosamente el chequeo contra varios diccionarios, que se actualizan periódicamente, 4. se bloquean automáticamente las sesiones en los puestos de trabajo después de cierto período de inactividad, y se requiere el ingreso de la contraseña del usuario para volver a habilitar el puesto, 5. se impone un tiempo de vida máximo de 4 meses para las contraseñas, 6. se bloquean automáticamente las cuentas con contraseñas demasiado viejas, 7. se bloquean por servidor las cuentas de los usuarios en caso de que se observen varios intentos de acceso no exitosos A pesar de las medidas de seguridad implementadas, o de aquellas que se puedan implementar y/o controlar mediante el uso de herramientas de software, consideramos que la mejor solución es una que involucre a los usuarios (el eslabón mas débil en una cadena de seguridad). Por este 6-7

7 motivo, como parte del proyecto Munix se consideró como factor fundamental la capacitación de usuarios, donde se les comunicó que si bien Single-Sign-On significa una comodidad y ventaja para ellos, implica una mayor responsabilidad respecto al uso de sus puestos de trabajo. Se los entrenó para que pongan en práctica, como mínimo, los siguientes mecanismos de protección para evitar que terceros puedan ejecutar aplicaciones en su nombre: 1) Cerrar la sesión iniciada en su puesto de trabajo cada vez que se retire del mismo por períodos de tiempo prolongado, 2)No dejar escrito en lugares a los que puedan tener acceso otras personas su contraseña de acceso. Se les recomendó elegir contraseñas fáciles de recordar de forma de no necesitar escribir nunca la contraseña en papel, 3) Elegir una contraseña de calidad, y cambiarla periódicamente, 4) No ingresar su contraseña delante de personas que puedan ver el teclado mientras la escribe, 5) Cambiar inmediatamente la contraseña en caso de sospechas de divulgación. Alcances de la solución implementada La solución de Single-Sign-On implementada abarca a todos los servicios que corren sobre las diferentes variantes de sistemas operativos basados en Unix disponibles en la Municipalidad de Rosario (Linux, SCO OS5, SYSV). A su vez, para aquellos servicios para los que no fue posible habilitar Kerberos (dado que el servicio no ofrece la posibilidad de hacerlo), se implementó, utilizando el módulo de autenticación de Kerberos para PAM (Pluggable Authentication Modules), el uso de la contraseña única. Dentro de los servicios y/o servidores no comprendidos como parte de la solución implementada, se encuentran todos los servicios que corren sobre plataformas Windows. Si bien Microsoft Windows 2000, y productos relacionados, viene con la posibilidad de utilizar la misma base de datos de autenticación Kerberos (de hecho, Active Directory de Windows 2000 es precisamente Kerberos + LDAP, tal como la solución que hemos implementado), el objetivo del proyecto Munix es la migración a Software Libre. Sumando a esto el hecho de que los servicios que permanecen sobre estas plataformas son pocos y próximos a ser migrados, se decidió no extender la solución implementada a estas plataformas. 7-7