parte_44.txt

Daniel Vicente Perpiñá Castillo 18 TEMARIO OPOSICIONES COIICV | TEMA 39 También se pueden combinar los filtros con operador es lógicos. 4.4.2. Herramientas de gestión Para gestionar la información de un SD disponemos d e cuatro herramientas de gestión: • Add: Esta herramienta añade una entrada nueva...

Daniel Vicente Perpiñá Castillo 18 TEMARIO OPOSICIONES COIICV | TEMA 39 También se pueden combinar los filtros con operador es lógicos. 4.4.2. Herramientas de gestión Para gestionar la información de un SD disponemos d e cuatro herramientas de gestión: • Add: Esta herramienta añade una entrada nueva al di rectorio. El primer parámetro será el DN, que situará la entrada en el árbol del SD, segu ido de una lista con los atributos y sus valores. Además, la lista de atributos debe coincid ir con el esquema del SD. • Delete: Esta herramienta borra una entrada del dire ctorio. El único parámetro que requiere es el DN de la entrada a eliminar. Si la entrada co ntiene hijos no se podrá borrar. • Modify: Esta herramienta realiza cambios modificand o, añadiendo y/o borrando valores de los atributos • Rename. Esta herramienta realiza cambios en el árbo l del SD modificando el DN de las entradas. Esto, en esencia, mueve una entrada de un a rama a otra dentro del árbol. 4.4.3. Herramientas de Seguridad La conexión a un SD no está exenta de mecanismos de seguridad. Establece mecanismos de autenticación y autorización, debido a que es neces ario que la información almacenada en un SD sea accesible por las aplicaciones que requieran ut ilizarlo. Aún así, lo más probable es que las aplicaciones solo puedan realizar consultas y sean los administradores del SD los que puedan realizar modificaciones. Un SD es la plataforma ideal para la distribución d e certificados digitales, debido a que soluciona dos de los principales problemas que surgen en la i mplementación de una Infraestructura de Clave Pública (PKI): • La gestión de la PKI:
Adición. Permite añadir certificados al SD y permit e añadir datos del SD al certificado.
Distribución. Permite acceder y distribuir fácilmen te los certificados digitales.
Revocación. Permite la revocación de un certificado con una orden de borrado al SD. • Localización de los certificados. El SD es el lugar ideal donde almacenar certificados para que sean accesibles por otros usuarios o aplicacion es. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Servicios, marcos y técnicas de autenticación. Cert ificados. Clave pública. Servicios de directorio TEMARIO OPOSICIONES COIICV | TEMA 39 19 4.5. Servicio de Directorio vs Base de datos Aunque un SD sea un tipo concreto de Base de Datos (BD), hay varias diferencias a tener en cuenta entra un SD una BD relacional: • En una SD las operaciones de lectura de datos son d e mayor frecuencia que las operaciones de escritura. • La estructura de organización de datos es completam ente jerárquica. • El esquema de un SD permite modificar fácilmente el diseño de las entidades que almacena. Además, el esquema se define como clases de objeto, atributos, referencias y nombres. • En un SD los datos suelen ser redundantes. • Un SD es un componente esencial en la implementació n de las políticas de seguridad. No debe confundirse un SD con el Repositorio de Dir ectorio, siendo el Repositorio una BD administrada por el SD que alberga información sobr e los objetos de nombrado. 4.6. Servicios de Directorio vs Resolución de Nombr es Un SD tiene gran similitud con un DNS (Domain Name Server) o con un NIS (Network Information Service), que son servicios que sirven para la reso lución de nombres en la red. Ambos: • Resuelven nombres de usuarios y equipos. • Disponen de una BD jerárquica. • Permite la distribución de datos de autenticación y autorización de usuarios (NIS). En cambio, difieren en otros aspectos: • Un DNS o un NIS están optimizados para la tarea de resolver nombres, un SD está optimizado para propósitos generales. • Un SD permite actualizaciones, mientras que un DNS no. • Los DNS están orientados a transmisiones UDP, mient ras que un SD suele estar orientado a transmisiones TCP. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Daniel Vicente Perpiñá Castillo 20 TEMARIO OPOSICIONES COIICV | TEMA 39 4.7. Funciones de un SD Algunas de las funcionalidades que ofrece un SD son : • Sustitución de un servicio NIS. • Autenticación de usuarios de Sistemas Operativos, d e SAMBA o de redes UNIX. • Integración con aplicaciones de cliente de correo. • Integración con servidores de correo electrónico. • Integración con servidores DNS. • Integración con servidores Web. • Integración con PKI. 4.8. Diseño de un SD El sistema de nombres que usa un SD permite organiz ar de forma jerárquica los objetos. En este ejemplo, Figura 1: Jerarquía de un Servicio de Directorio. tenemos una organización (Pepito SA), donde hay dos Unidades Organizativas llamadas “usuarios” y “servidores”. Dentro de cada OU alojamos los nomb res de las aplicaciones o usuarios que se conectarán al SD. Esta estructura jerárquica ofrece la flexibilidad d e adaptarse a multitud de entornos y situaciones. Por ejemplo, podríamos querer agrupar a los trabaja dores por departamentos: Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Servicios, marcos y técnicas de autenticación. Cert ificados. Clave pública. Servicios de directorio TEMARIO OPOSICIONES COIICV | TEMA 39 21 Figura 2: Modificación de las unidades organizativa s. Cada objeto representa una entrada en el directorio . Hay un total de 11 entradas, cada una de ellas tiene un Distinguished Name (DN). La empresa, por ejemplo, tiene dc=Pepito, dc=SA como DN. Para cada entrada habrá una lista de atributos, alg unos atributos serán comunes en varias entradas, en cambio otros serán específicos. En la siguiente tabla se muestra un ejemplo de una entrada para el usuario “juan” de “contabilidad”. Tabla I: Entrada de un objeto en el directorio Clase del objeto Persona cn Juan Valdés Hondarrubia sn Valdés Hondarrubia telephoneNumber 699632125 mail [email protected] jpegPhoto nU6KNyVIYS817zVdf5YKF1Fr……… La estructura de un SD mantiene el formato de Árbol de Directorio (DIT, Director Information Tree). Partiendo de un elemento raíz, la estructura se ram ifica, siendo las ramas elementos finales, o elementos intermediarios que agrupan a otros elemen tos. Estos objetos normalmente son ROOT (raíz), C (país), DC (componente de dominio) y OU ( unidad organizativa). Cada objeto en el árbol tiene un identificador único, conocido como DN (Dis tinguished Name). El nivel más alto dentro del árbol será el DN Base y será lo primero que hay que definir en el DIT. Se define mediante los DC (Domain Components), en u na estructura similar al servicio DNS; de ahí su similitud. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Daniel Vicente Perpiñá Castillo 22 TEMARIO OPOSICIONES COIICV | TEMA 39 4.9. LDIF LDIF (LDAP Data Interchange Format) es un estándar que define el formato en que se representarán las entradas del directorio, sirve ad emás para importar y exportar datos independientemente del servidor LDAP que se esté ut ilizando. Independientemente de la plataforma empleada, LDIF permite la realización de copias de seguridad y la modificación de datos dentro del dir ectorio. El formato LDIF es una cadena de texto ASCII para e ntradas LDAP que consta de dos partes: El DN, o Nombre Distinguido (Distinguished Name), segu ido de los atributos. No existe un orden preestablecido, pero se aconseja seguir una serie de reglas, como listar el atributo objectclass en primer lugar para facilitar la lectura de entradas. Así, por ejemplo: Tabla II: Presentación de una entrada del directori o dn:uid=juan,ou=informática,ou=usuarios,o=uc3m,c=es objectclass:person objectclass:organizationalPerson objectclass:account uid:juan sn:Valdés Hondarrubia cn:Juan Valdés Hondarrubia mail:[email protected] telephoneNumber:699632125 Algunas de las reglas a tener en cuenta son: • El atributo va a la izquierda y el valor a la derec ha, separados por dos puntos (objectClass: account). • El primer valor de DN debe estar en la entrada LDIF por su atributo (uid:juan). • Los atributos “objectClass” se definen en base al e squema y deben tener su correspondiente entrada para cada valor. • Distingue mayúsculas y minúsculas. • Los caracteres especiales se deben escapar (). • En un archivo LDIF donde haya más de una entrada, c ada entrada deberá ir separada por un salto de línea. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Servicios, marcos y técnicas de autenticación. Cert ificados. Clave pública. Servicios de directorio TEMARIO OPOSICIONES COIICV | TEMA 39 23 En LDAP los atributos pueden tener valores múltiple s y/o repetidos. Un ejemplo de ello es el atributo “telephoneNumber”, que podemos tener repet ido varias veces para albergar los diferentes números de teléfono de un usuario. También es posib le que algunos atributos tengan la característica de ser únicos y no permitir más valo res o múltiples entradas, como por ejemplo el atributo “uidNumber”, que será único para cada usua rio. Es el esquema el que define que valores podemos escribir y en que atributos podremos escrib irlos. Todos los esquemas definen un atributo obligatorio llamado “objectClass. 4.10. Implementaciones de LDAP El funcionamiento de LDAP es sencillo, y sigue esta s pautas: 1. El cliente establece una conexión con el servido r LDAP. El servidor indica al cliente por el puerto por el que está comunicándose, por defecto el 389. El servidor autenticará al cliente o bien el cliente iniciará una sesión anónima con los parámet ros por defecto. 2. El cliente efectúa las operaciones requeridas. 3. Una vez finalizadas las operaciones, cliente y s ervidor cierran la sesión. Entre las implementaciones más conocidas y utilizad as tenemos: • Active Directory, de Microsoft. Utilizado desde Win dows Server 2000, es un SD donde se almacenan todos los perfiles de usuarios, recursos de red, permisos y políticas de seguridad. Además, permite la autenticación de usua rios dentro de una red. • OpenLDAP, proyecto Open Source. Es una aplicación b asada en el protocolo LDAP. Tiene las mismas funcionalidades que Active Directory de Windows. Además, se ha implementado en otras aplicaciones como: Red Hat Di rectory Server, Apache Directory Server o Open DS. 5. Marcos de autenticación Los marcos de autenticación son el conjunto de prot ocolos que conforman las tecnologías de autenticación. Estas tecnologías se encargan de aut enticar a los usuarios y de aplicar las políticas de acceso al sistema o a la red. Estas tecnologías implementan: • Almacenes de credenciales. Son los sistemas encarga dos de proteger y custodiar las credenciales de los usuarios. Por ejemplo, serían a lmacenes un SD como Active Directory o un sistema en la nube como una CA. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Daniel Vicente Perpiñá Castillo 24 TEMARIO OPOSICIONES COIICV | TEMA 39 • Aplicaciones de credenciales. Son las aplicaciones que se encargan de gestionar el proceso de autenticación, conectándose con el almac én de credenciales mediante un protocolo designado. Siguiendo el ejemplo, la panta lla de inicio de sesión sería la aplicación en Active Directory para el primer caso y una página web con conexión SSL podría ser el acceso a la aplicación en la nube. • Protocolos de autenticación. Son los estándares que definen como se realizará la autenticación. El protocolo define los mecanismos d e autenticación. En este caso, los protocolos serían el X.500 en Active Directory y el X.509 en las conexiones SSL. Podemos agrupar los marcos de autenticación en dos grandes categorías: • Tecnologías delegadas de control de acceso. Algunas de estas tecnologías delegadas son Kerberos, Radius y el estándar 802.1x. • Tecnologías para la gestión de identidades federada s. Algunas de estas tecnologías son OpenID, SAML, XACML y SPML. 5.1. Kerberos Es un protocolo de autenticación de redes creado po r el MIT. Se basa una arquitectura de cliente y servidor que proporciona cifrado con autenticación mutua, es decir cliente y servidor verifican la identidad del otro. Fue desarrollado para garantiza r una comunicación segura entre dos equipos a través de una red insegura. Emplea criptografía de clave simétrica y requiere de una tercera entidad de confianza. Ocasionalmente puede utilizar criptografía de clave asimétrica en determinados procesos de autenticación. El nombre de Kerberos hace referencia al perro guar dián de tres cabezas que custodiaba el Hades en la mitología griega. Los servicios más habituales de autenticación están basados en el factor del conocimiento, quiere decir, en contraseñas que sólo el usuario conoce. E n esta forma de autenticación, los datos enviados no viajan encriptados, de modo que un usua rio malintencionado que haya interceptado la comunicación tendrá acceso a la contraseña y, por e nde, podrá autenticarse en el servicio fraudulentamente. El objetivo de Kerberos es eliminar el envío de inf ormación de autenticación a través de la red. Para ello se dispone de una infraestructura en la q ue participan: • AS = Authentication Server o Servidor de autenticac ión. • TGS = Ticket Granting Server o Servidor emisor de t ickets. • SS = Service Server o Servidor que alberga el servi cio solicitado. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Servicios, marcos y técnicas de autenticación. Cert ificados. Clave pública. Servicios de directorio TEMARIO OPOSICIONES COIICV | TEMA 39 25 El procedimiento de autenticación para acceder al s ervicio solicitado es el siguiente: • Un usuario ingresa su nombre de usuario y contraseñ a en la aplicación cliente (el cliente). • El cliente genera una clave hash a partir de la con traseña y la usará como la clave secreta del cliente. • El cliente envía un mensaje en texto plano al AS so licitando servicio en nombre del usuario. Ni la clave secreta ni la contraseña son e nviados; solo la petición del servicio. • El AS comprueba si el cliente está en su base de da tos. Si es así, el AS genera la clave secreta utilizando la función hash con la password del cliente encontrado en su base de datos. Entonces envía dos mensajes al cliente:
Mensaje A: Client/TGS session key cifrada usando la clave secreta del usuario.
Mensaje B: Ticket-Granting Ticket (que incluye el I D de cliente, la dirección de red del cliente, el período de validez y el Client/TGS sess ion key) cifrado usando la clave secreta del TGS. • Una vez que el cliente ha recibido los mensajes, de scifra el mensaje A para obtener el client/TGS session key. Esta session key se usa par a las posteriores comunicaciones con el TGS. (El cliente no puede descifrar el mensaje B pues para cifrar éste se ha usado la clave del TGS). En este momento el cliente ya se pu ede autenticar contra el TGS. • Entonces el cliente envía los siguientes mensajes a l TGS:
Mensaje C: Compuesto del Ticket-Granting Ticket del mensaje B y el ID del servicio solicitado.
Mensaje D: Autenticador (compuesto por el ID de cli ente y una marca de tiempo), cifrado usando el client/TGS session key. • Cuando recibe los mensajes anteriores, el TGS desci fra el mensaje D (autenticador) usando el client/TGS session key y envía los siguie ntes mensajes al cliente:
Mensaje E: Client-to-server ticket (que incluye el ID de cliente, la dirección de red del cliente, el período de validez y una Client/Server session key) cifrado usando la clave secreta del servicio.
Mensaje F: Client/server session key cifrada usando el client/TGS session key. • Cuando el cliente recibe los mensajes E y F, ya tie ne suficiente información para autenticarse contra el SS. El cliente se conecta al SS y envía los siguientes mensajes:
Mensaje E del paso anterior. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Daniel Vicente Perpiñá Castillo 26 TEMARIO OPOSICIONES COIICV | TEMA 39
Mensaje G: un nuevo Autenticador que incluye el ID de cliente, una marca de tiempo y que está cifrado usando el client/server session ke y. • El SS descifra el ticket usando su propia clave sec reta y envía el siguiente mensaje al cliente para confirmar su identidad:
Mensaje H: la marca de tiempo encontrada en el últi mo Autenticador recibido del cliente más uno, cifrado el client/server session k ey. • El cliente descifra la confirmación usando el clien t/server session key y chequea si la marca de tiempo está correctamente actualizada. Si esto es así, el cliente confiará en el servidor y podrá comenzar a usar el servicio que es te ofrece. • A partir de este momento, el servidor provee del se rvicio al cliente. Figura 3: Autenticación en Kerberos El protocolo Kerberos presupone que el entorno en e l que se realiza la autenticación no es seguro. Se implementa Kerberos para conseguir un nivel supe rior de seguridad. Pese a ello Kerberos mantiene algunas limitaciones: • Kerberos no protege contra ataques DDoS (Denegación del Servicio por ataque distribuido). Un usuario malintencionado podría rea lizar múltiples solicitudes al servidor desde varios puntos de conexión, generando inestabi lidad en el servidor, tiempos de respuesta intolerables y finalmente consiguiendo la denegación de la comunicación con el servidor a nuevos usuarios, con el objetivo final d e que la aplicación no pueda acabar realizando los pasos de autenticación correctamente . • Kerberos no protege contra las vulnerabilidades aso ciadas a las contraseñas, como compartir la contraseña con otra persona o usar una fecha de nacimiento propia que pueda ser adivinada. Un usuario malintencionado podría ad quirir la clave de sesión cifrada de Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019