Contenido
- 1 Criterios Generales (CCGG)
- 1.1 Criterio 1. Documento publicado con la política del servicio.
- 1.2 Criterio 2. Evitar el uso de LDAP V2.
- 1.3 Criterio 3. Hacer uso de esquemas estándares.
- 1.4 Criterio 4. Gestión de Identidad.
- 1.5 Criterio 5. Uso de administraciones delegadas. Facilidades de administración.
- 1.6 Criterio 6. Existencia de un entorno de pre-producción.
- 2 Criterios de Seguridad (CCS)
- 3 Criterios de Aplicación (CCA)
- 3.1 Criterio 16. Aplicativo actualizado.
- 3.2 Criterio 17. Hacer uso de SSL/TLS.
- 3.3 Criterio 18. Existencia de réplicas de sólo lectura.
- 3.4 Criterio 19. Cuentas de consulta.
- 3.5 Criterio 20. Evitar accesos anónimos. Acceso no público.
- 3.6 Criterio 21. Definición de límites.
- 3.7 Criterio 22. Definición de ACL's.
- 3.8 Criterio 23. Almacenamiento seguro y política de contraseñas.
- 3.9 Criterio 24. Estudio de los ficheros de Logs
- 3.10 Criterio 25. Definición de una política de copias de seguridad.
1 Criterios Generales (CCGG)
1.1 Criterio 1. Documento publicado con la política del servicio.
Valoración: 200 puntos
La institución debe disponer de un documento que contenga la política del servicio de directorio. Ese documento será, al menos, público dentro de la institución. El documento contendrá como mínimo los siguientes capítulos o secciones:
1.1.1 Política de usuarios y contraseñas
Descripción de la política de usuarios de la institución indicando quien tienen derecho a disponer de una cuenta en la misma y bajo qué condiciones. Es importante igualmente hacer pública la política de contraseñas indicando aspectos como el mecanismo de cambio de contraseñas, una descripción de la complejidad mínima que deben tener las mismas y su política de caducidad caso de existir. Un aspecto recomendable es que la caducidad de una contraseña no supere un año.
1.1.2 Accesos al servicio
En este capítulo se podrá detallar la/s forma/s de acceso al servicio de directorio. Se determinará si se debe hacer (o no) doble bind, si se permiten (o no) los accesos anónimos, así como si las conexiones son cifradas o no. Se publicarán igualmente las formas de acceso de las cuentas de consulta (cuentas que se facilitarán a los responsables de las diferentes aplicaciones que se conecten al directorio para realizar labores de autenticación y/o autorización). Se podrán publicar los distintos controles que se realizarán en el servicio de directorio para evitar problemas mayores así como los mecanismos de bloqueo de cuentas de consulta.
1.1.3 Gestión de Identidad
Esta sección del documento incluirá el proceso que siguen los datos asociados a las personas desde que se tiene conocimiento de ellos hasta que conforman la identidad de una persona física en el servicio directorio. Deben quedar reflejados los procesos de creación de cuentas (altas), los cambios dentro de la institución (qué pasa cuando su relación con la institución cambia) y, finalmente, qué ocurre cuando la persona finaliza su relación con la institución (baja).
1.1.4 Política de copias de seguridad
En este capítulo se detallarán las formas y periodicidades de las copias de seguridad realizadas sobre el servicio de directorio.
1.2 Criterio 2. Evitar el uso de LDAP V2.
Valoración: 50 puntos
El servicio de directorio debe configurarse haciendo uso del protocolo LDAP v3 y evitar así el uso del protocolo LDAP v2. Las principales mejoras que ofrece LDAPv3 sobre LDAPv2 son las siguientes:
- Autenticación fuerte haciendo uso de SASL
- Protección de integridad y confidencialidad haciendo uso de TLS (SSL)
- Internacionalización gracias al uso de Unicode
- Remisiones y continuaciones
- Descubrimiento de esquemas
- Extensibilidad (controles, operaciones extendidas y más)
1.3 Criterio 3. Hacer uso de esquemas estándares.
Valoración: 100 puntos
A la hora de definir cómo almacenar la información en el directorio es importante la elección que se realice de los esquemas a utilizar. Es recomendable que se utilicen esquemas estándares para almacenar la información en el directorio puesto que dicha elección facilitará tanto labores de administración como de interoperabilidad con otras instituciones. El esquema recomendado por el grupo de identidad de RedIRIS es IrisEduPerson basado en un modelo por capas de la siguiente forma:
inetOrgPerson - eduPerson - schac* - iris* - locales
Toda la información relativa al mismo está disponible en la página LDAP de RedIRIS: https://www.rediris.es/ldap/schema/iriseduperson/
1.4 Criterio 4. Gestión de Identidad.
Valoración: 100 puntos
Un directorio es sólo un conjunto de objetos y atributos. Mantenerlo actualizado define el verdadero valor del directorio. Para ello es necesario describir los flujos de datos que se producen en las identidades de la institución y hacerlos efectivos sobre los datos del directorio. Cada cambio de estado de una persona en la institución se debe traducir en uno o más cambios de datos en el directorio. A todo ese conjunto de acciones sobre el directorio en función de los cambios que se producen en el mundo real se llama "Gestión de Identidad". Se recomienda por tanto definir una gestión de la identidad coherente que permita mantener los datos del directorio actualizados. Como mínimo deben quedar definidos dentro de la institución la periodicidad y automatización de procesos y procedimientos que estén encaminados en conseguir este criterio de calidad.
1.5 Criterio 5. Uso de administraciones delegadas. Facilidades de administración.
Valoración: 100 puntos
Es habitual que aparezcan necesidades de creación/modificación/borrado de elementos del directorio por parte de servicios/unidades/grupos que no son responsables de la administración del servicio de directorio. En estos casos, el directorio no se debe gestionar con la cuenta de superusuario puesto que si así fuese la seguridad del servicio se vería afectada. Para facilitar la labor de actualización de datos sin menoscabo de la seguridad del directorio se recomienda hacer uso de administraciones delegadas que permitan gestionar parte del directorio con los controles y accesos explícitamente definidos y configurados.
1.6 Criterio 6. Existencia de un entorno de pre-producción.
Valoración: 100 puntos
Se recomienda la utilización de un entorno de pre-producción con las mismas características que el entorno de producción. Este entorno de pre-producción permitirá poder realizar las pruebas y configuraciones alternativas que se estimen oportunas y evitar así realizarlas directamente en el entorno de producción. En el caso de que haya que hacer desarrollos específicos sobre el servicio de directorio, se debe prever un tercer entorno para los desarrolladores (entorno de desarrollo). Para cada intervención en el directorio, es aconsejable definir los mecanismos de traslación de cambios y configuraciones de un entorno a otro así como los que permitan realizar una vuelta atrás en caso de necesidad.
2 Criterios de Seguridad (CCS)
2.1 CCS a nivel de SO
2.1.1 Criterio 7. Sistema Operativo actualizado.
Valoración: 50 puntos
En general, para evitar problemas es fundamental mantener actualizado el sistema operativo del servidor sobre el que se tiene desplegado el servicio de directorio. Esto no implica que sea un requerimiento tener instalada la última versión del sistema operativo pero sí debe ser una versión estable del sistema con actualizaciones del fabricante. Es importante mantener la atención en la publicación de parches y revisiones en cada caso estableciendo unos canales fiables y rápidos de comunicación como pueden ser las suscripciones a listas de distribución específicas y/o dedicadas.
2.1.2 Criterio 8. Hacer uso de un sistema dedicado.
Valoración: 50 puntos
Una buena práctica a la hora de dar un servicio concreto es dedicar un nodo o servidor al despliegue de la aplicación concreta que va a permitir dar el servicio en cuestión. De ahí que se entienda que es una medida de calidad asociada al servicio de directorio (y a cualquiera en general) tener desplegado el aplicativo en un sistema dedicado e independiente.
2.1.3 Criterio 9. Disponer de alta disponibilidad.
Valoración: 100 puntos
A la hora de dar un servicio, y mucho más tratándose de un servicio crítico como es el servicio de directorio, se hace imprescindible contar con una infraestructura hardware y/o software que permita ofrecer el servicio en alta disponibilidad. Las opciones para implementar la alta disponibilidad de un servicio son amplias (desde la redundancia de infraestructura apoyada en sistemas software que permitan seguir dando servicio ante caídas del nodo principal, hasta arquitecturas virtualizadas) y cualquiera de ellas es válida a la hora de acreditar este criterio. La alta disponibilidad se debe entender tanto en lectura como en escritura, si bien en un servicio de directorio, el porcentaje de escritura es mucho menor se debe procurar disponer de una arquitectura multimaster. Se asignarán 50 puntos si se dispone de alta disponibilidad en lectura y otros 50 si se dispone de alta disponibilidad en escritura.
2.1.4 Criterio 10. Sistema protegido (FW).
Valoración: 50 puntos
A día de hoy se hace necesario disponer de una infraestructura de seguridad perimetral protegiendo servicios críticos como puede ser el directorio. Entendiendo que los accesos al mismo estarán definidos en este entorno de seguridad perimetral permitiendo sólo y exclusivamente los accesos necesarios para dar el servicio y en todo caso, para administrar remotamente los servidores que lo albergan. En este último caso, los accesos tendrían que ir definidos por IPs privilegiadas. En el caso de no disponer de un sistema específico para suministrar la seguridad perimetral, se considerará igualmente superado el criterio si el servidor que alberga el servicio se encuentra “bastionado” o protegido y por tanto cumple los requisitos mencionados en el párrafo anterior.
2.1.5 Criterio 11. Permisos y propietarios adecuados en LDAP.
Valoración: 50 puntos
El servicio de directorio debe ejecutarse bajo un usuario no privilegiado del sistema que estará definido para uso exclusivo del software de directorio. Los ficheros y directorios de la aplicación tendrán que tener los propietarios adecuados. En este caso que nos ocupa, tendrían que ser propiedad del usuario no privilegiado bajo el que se ejecuta el software. Por último, los permisos de los distintos ficheros y directorios de la aplicación, deben ser los adecuados para el correcto uso de la misma sin incurrir en otorgar permisos más amplios de los que sean realmente necesarios.
2.2 CCS a nivel de aplicaciones que se conectan al directorio
2.2.1 Criterio 12. Evitar exponer directamente el servidor LDAP a Internet.
Valoración: 100 puntos
El servidor LDAP suele convertirse en un punto crítico a la hora de autenticar usuarios para así permitir la entrada en la mayoría de los aplicativos de la institución. Esta situación unida a que el servicio de directorio como tal no suele prestar servicios al usuario final hace que el hecho de no estar expuesto directamente a Internet constituya por sí solo un criterio más a tener en cuenta en aras de obtener una certificación de calidad.
2.2.2 Criterio 13.Acceso controlado de las aplicaciones
Valoración: 200 puntos
Se propone una lista de recomendaciones o posibles medidas a implementar sobre aplicaciones que hacen uso del directorio:
- 1. La aplicación se conectará al directorio autenticándose con una cuenta de consulta especifica para este aplicativo.
- 2. Si se transmiten credenciales o datos sensibles el servicio ofrecido por la aplicación integrada con el directorio debe realizarse a través de protocolo https.
- 3. Chequear los datos recibidos desde el cliente antes de enviarlos al directorio.
- 4. Chequear los datos enviados al cliente y comprobar la cantidad de información enviada.
- 5. Es responsabilidad de la aplicación hacer uso de atributos indexados en las búsquedas.
- 6. Es deseable que las consultas al directorio se realicen mediante webservices. De este modo el administrador del directorio garantiza que se cumplan los puntos anteriores.
- 7. Es deseable que la integración con el directorio se realice en el entorno de pre-producción antes de pasar a producción.
- 8. Es recomendable disponer de un contacto como responsable de la aplicación.
- 9. Algunos navegadores almacenan las contraseñas en claro. Para evitar que nuestros usuarios puedan dejar guardadas las contraseñas basta con añadir en el formulario de login autocomplete="OFF" : <form action="autenticar.php" method="post" autocomplete="OFF">
2.2.3 Criterio 14. Autenticación centralizada de usuarios
Valoración: 200 puntos
Uno de los principales objetivos del servicio de directorio es la autenticación de usuarios. A través de un sistema centralizado de autenticación, o Single Sign On, se logra un punto de entrada único a todos los aplicativos de la institución, proporcionando una capa más dentro de una arquitectura de seguridad en profundidad. De este modo se consiguen varios objetivos:
- sólo es necesario controlar este único punto de autenticación de usuarios, evitando así tener que auditar todos y cada uno de los diferentes sistema de autenticación de usuarios de las diferentes aplicaciones.
- las aplicaciones nunca tendrán acceso a las contraseñas de los usuarios.
- los usuarios se acostumbrarán a una pantalla de autenticación corporativa y esto hará que el usuario sea menos proclive a facilitar su contraseña en páginas web falsas.
- los usuarios se autenticarán una única vez para acceder a todos los servicios.
2.2.4 Criterio 15. Validación correcta de usuarios (doble bind).
Valoración: 150 puntos
En el caso de que una aplicación no esté integrada con el sistema SSO debe autenticar contra el directorio de forma adecuada. El objetivo de activar el doble bind a través de cuentas de consulta específicamente creadas a tal efecto es evitar problemas de seguridad en el servicio de directorio. A continuación se detallan seis pasos que constituyen un estándar de conexión a cualquier servidor LDAP, con cualquier estructura, cualquier tecnología de cifrado o cualquier otro criterio:
- 1. Se parte del nombre de usuario y contraseña que aporta el usuario cuando intenta autenticarse en la aplicación A.
- 2. La aplicación A enlaza con el LDAP (hace un bind) con una cuenta de consulta (cuenta privilegiado) creada para la aplicación en cuestión.
- 3. Una vez dentro del directorio se localiza mediante una búsqueda el DN asociado al nombre del usuario (el que éste dio en el paso 1 cuando se conectó a la aplicación A).
- 4. Si la búsqueda devuelve una entrada y solo una, éste es el DN del usuario buscado. Si hay cero o más de una entrada, se devolverá usuario no encontrado.
- 5. Se vuelve a hacer un bind al LDAP (de ahí el nombre de doble bind) con el DN devuelto en el paso 4 y la contraseña del paso 1.
- 6. Si LDAP permite el bind significa que el login ha tenido éxito. En otro caso devuelve “password no válida”.
Es fundamental realizar la autenticación correctamente, no solo para que las políticas de bloqueos de contraseñas ante binds fallidos sean efectivas, sino también para evitar ataques de “ldap injection”. Para forzar el uso de este criterio la mejor opción es poner una lista de control de acceso (ACL) que evite que ningún usuario pueda leer las contraseñas del resto de usuarios.
3 Criterios de Aplicación (CCA)
3.1 Criterio 16. Aplicativo actualizado.
Valoración: 50 puntos
Al igual que ocurre con el sistema operativo, el aplicativo que presta el servicio de directorio debe estar actualizado, siguiendo en todo momento las recomendaciones de los fabricantes o desarrolladores, sobre todo en el caso de actualizaciones de seguridad. Es importante mantener la atención en la publicación de parches y revisiones en cada caso estableciendo unos canales fiables y rápidos de comunicación como pueden ser las suscripciones a listas de distribución específicas y/o dedicadas. Se proponen dos opciones:
- instalar desde los paquetes que mantiene el fabricante del Sistema Operativo, lo que garantiza las actualizaciones de seguridad aunque no se disponga de la última versión del software. Esto sería suficiente si no se requiere alguna funcionalidad específica de las últimas versiones del aplicativo.
- utilizar el software que distribuye el fabricante aunque esto implique una compilación e instalación algo mas engorrosa. De este modo tenemos un software más actualizado y optimizado.
Se debe mantener la misma versión del software en todos los servidores.
3.2 Criterio 17. Hacer uso de SSL/TLS.
Valoración: 50 puntos
El protocolo SSL/TLS proporciona una capa de seguridad a otros protocolos que no son seguros. Por un lado demuestra al cliente la autenticidad del servidor y por otro permite la confidencialidad en la comunicación al cifrar la transmisión de datos. Para ello se aconseja seguir las recomendaciones de seguridad SSL. http://wiki.rediris.es/gtidentidad/RequisitosTLS
3.3 Criterio 18. Existencia de réplicas de sólo lectura.
Valoración: 100 puntos
Las réplicas que van a proporcionar el servicio deben estar configuradas sólo en modo lectura de manera que las aplicaciones que no requieran escribir en el directorio no puedan hacerlo. Si existen aplicaciones que deben realizar modificaciones de atributos/usuarios, se deben utilizar accesos privilegiados a sistemas de lectura/escritura que se deben proteger con listas de control de acceso (ACLs).
3.4 Criterio 19. Cuentas de consulta.
Valoración: 200 puntos
Todos los usuarios del directorio podrán conectarse al mismo para visualizar y/o modificar algunos de sus propios atributos a través de alguna aplicación específica. Sin embargo las aplicaciones que hacen uso del directorio necesitan obtener información de todos o parte de los usuarios registrados. Para este tipo de acceso privilegiado se debe utilizar una cuenta de consulta dedicada, de manera que cada cuenta será específica para un único aplicativo con privilegios explícitamente definidos con el mínimo nivel de accesos que permita cumplir sus funciones. Es recomendable utilizar diferentes cuentas de consulta para tareas que requieran distintos niveles de privilegio dentro de un mismo aplicativo.
3.5 Criterio 20. Evitar accesos anónimos. Acceso no público.
Valoración: 100 puntos
Por lo general los datos almacenados en los servicios de directorio van a ser datos sensibles y por tanto, no deben estar (todos) a disposición de cualquier usuario. Este motivo hace que se desaconseje el uso del usuario anónimo estableciendo el servicio como privado y controlando el acceso de aplicaciones y usuarios con los métodos indicados en otros criterios.
3.6 Criterio 21. Definición de límites.
Valoración: 100 puntos
Es conveniente definir umbrales superiores para el número de entradas devueltas por el directorio ante una búsqueda determinada así como al tiempo máximo para realizarla. De esta manera se incrementa el trabajo para los atacantes con ldap injection, se evita cargar al servidor de manera innecesaria y se detectan aplicaciones mal programadas.
3.6.1 Número de entradas devueltas
Valoración: 50 puntos
Las búsquedas que se pueden hacer en un directorio son o pueden ser de muchos tipos. Desde los casos en que sólo se requiere la devolución de una entrada, como cuando se realiza una consulta para devolver el DN del usuario que pretende validarse, a otros casos en los que se puede solicitar que se devuelvan varias entradas para una búsqueda concreta (Es importante no olvidar otros casos como la circunstancia de que no deban existir limites para las entidades encargadas de mantener las réplicas sincronizadas con los servidores maestros). En los distintos servicios de directorio se define un número de entradas devueltas por defecto. De esta forma, al realizar una consulta sobre el caso concreto de OpenLDAP se devuelven 500 resultados, en Oracle Directory Server se devuelven 1000, en Active Directory 1000 y en Directory Server de Sun no se limita el número de entradas devueltas. Es buena medida definir un límite general y especificar límites concretos para determinadas entidades. Si se alcanza ese límite general, el directorio devolverá todos los registros encontrados hasta llegar al límite establecido, más un mensaje de error “size limit exceed”. En algunos directorios también se puede especificar el número máximo de registros que pueden ser seleccionados como candidatos para realizar una búsqueda.
3.6.2 Tiempo máximo de respuesta
Valoración: 50 puntos
El límite establecido por defecto depende de nuevo del directorio que se esté utilizando. En OpenLDAP, Sun y Oracle son 3600 segundos y en Active Directory son 120 segundos. El comportamiento de un servicio directorio ante una consulta, por definición del propio protocolo en uso debe ser rápido. Constituye una buena medida establecer el tiempo máximo de respuesta por debajo de los 100 segundos. De esta manera se evita que el servidor se colapse con consultas mal programadas o ataques intencionados. Habrá entidades, como las encargadas de la sincronización de las réplicas, que no deben estar afectadas por estos límites.
3.7 Criterio 22. Definición de ACL's.
Valoración: 300 puntos
El mecanismo para autorizar o denegar accesos a ciertas partes del directorio son las ACLs (Listas de Control de Accesos).
3.7.1 Coherencia en la definición
Valoración: 200 puntos
La definición de ACLs es muy versátil y potente: Se puede limitar desde qué máquinas se pueden realizar conexiones con determinadas identidades. Conceder permisos a una identidad concreta, a un grupo o a una rama del directorio. Especificar sobre qué objetos (atributos, ramas o identidades ) se están concediendo dichos permisos. Especificar qué permisos: autenticación, lectura, escritura, búsqueda. Se pueden utilizar expresiones regulares, lo que proporciona una gran potencia para crear ACLs complejas. Las ACLs globales afectan a todo el directorio y por tanto a todos los backends. De ahí que se protejan en este bloque sólo las siguientes partes del directorio: rootDSE y cn=Subschema. Las ACLs de los backends sobrescribirán las directivas globales. En primer lugar se deben escribir las reglas relacionadas con el origen de la conexión, es decir limitar desde que IPs o nombre de dominio se pueden conectar ciertas cuentas de consulta o grupos. A continuación las ACLs que afectarán a usuarios privilegiados como el encargado de mantener las réplicas, administradores de partes del directorio, etc. Y después el resto de reglas que configuren la política de seguridad del directorio. Estas reglas se deben analizar y evaluar muy concienzuda y rigurosamente pues es relativamente fácil cometer errores en este proceso.
3.7.2 Sincronización de ACLs en las réplicas
Valoración: 100 puntos
Las ACLs no viajan con los datos por lo que es importante mantener actualizadas las mismas políticas de seguridad en todas las réplicas del directorio. La cuenta encargada de mantener las réplicas debe tener acceso de lectura a todas las ramas que se van a replicar o a todo el directorio si la réplica es completa. Además no debe estar afectada por los límites generales de número de entradas devueltas en una búsqueda o de tiempo empleado en realizar dichas búsquedas. En el máster se debe controlar desde donde se podrá conectar dicha cuenta, es decir, sólo desde las réplicas y, principalmente si se trata de réplicas fuera de la DMZ las conexiones se deben realizar sobre TLS para asegurar la confidencialidad en la comunicación.
3.8 Criterio 23. Almacenamiento seguro y política de contraseñas.
Valoración: 200 puntos
Una de las principales misiones del directorio es la autenticación de usuarios. Este es el motivo por el que las contraseñas almacenadas en él deben ser tratadas con extrema precaución. Para almacenar las contraseñas se debe escoger un esquema de almacenamiento con un cifrado seguro, se debe implementar y mantener una política de contraseñas, exigiendo complejidad y cambios periódicos, y se debe disponer de un sistema de bloqueo temporal de cuentas tras varias conexiones fallidas.
3.8.1 Almacenamiento cifrado de las contraseñas
Valoración: 100 puntos
Aunque se utilicen esquemas de almacenamiento cifrados, las contraseñas se deben proteger como si estuvieran en texto plano. El atributo que se suele utilizar es userPassword; es multivaluado y cada valor puede estar almacenado con un formato diferente. Al validar al usuario el servidor LDAP realiza una iteración con cada valor. Es recomendable restringir el acceso al atributo userPassword de manera que ningún usuario debe poder leerlo. Una ACL del tipo de acceso “=xw” sólo permite autenticar contra el atributo y actualizarlo pero no leerlo. Es recomendable escoger un esquema de almacenamiento cifrado que incluya Salt para evitar que sean vulnerables ataques por diccionario. El esquema CRYPT es ampliamente utilizado, como herencia de haber importado los usuarios de sistemas Unix. Este esquema sólo comprueba los primeros 8 caracteres de la contraseña y no incluye Salt, por lo que debería evitarse. Merece especial atención el password del rootdn. Es preferible no especificarlo en el archivo de configuración, y menos aún en claro. Se puede crear una entrada en el directorio para el rootdn; de esta forma cuando se acceda con este usuario se realizará un bind y se podrá controlar desde donde se permitirán estas conexiones.
3.8.2 Política de contraseñas y bloqueo tras intentos de autenticación fallidos
Valoración: 100 puntos
Crear una política de contraseñas es importante pero puede ser complejo de implementar así como de hacer que los usuarios se adapten a ella. Esta política debe formar parte de la política de seguridad de la institución. Los puntos que debe recoger son los siguientes:
- Complejidad de las contraseñas: Controlar la fortaleza de las contraseñas: mínimo 6 caracteres con números, mayúsculas, minúsculas y algún carácter especial.
- Evitar que contengan el alias o que pertenezcan al diccionario.
- Obligar a realizar cambios periódicos: como mínimo una vez al año, como se establece en el artículo 93 del RD 1720/2007.
- Bloqueos de cuentas tras varios intentos de autenticación fallidos. Este bloqueo puede ser temporal o permanente hasta que el administrador lo desbloquee.
3.9 Criterio 24. Estudio de los ficheros de Logs
Valoración: 100 puntos
Un análisis habitual de los logs del sistema permite detectar posibles incidentes antes de que lleguen a constituir un problema real y tengan un mayor grado de complejidad. Esto permite a grandes rasgos actuar de manera proactiva, incidiendo positiva y directamente en la calidad del servicio ofrecido. Los directorios ofrecen diferentes niveles de logs, algunos excesivamente amplios y muy útiles durante el análisis de un problema concreto pero excesivos para ser almacenados habitualmente. Sugerencia: Si utiliza el sistema syslog, es preferible configurarlo en modo no síncrono (-/ruta/ldap.log) para evitar que afecte al rendimiento del servidor ldap.
3.9.1 Política y análisis de logs
Valoración: 75 puntos
Es aconsejable que exista una política de logs y se preste especial atención a: Definir el nivel de log adecuado cuando el servicio directorio esté en explotación así como la frecuencia de rotado, almacenamiento y periodos de conservación. Definir métodos de análisis y detallar procedimientos asociados a los hallazgos detectados. Ejemplos:
- Analizar si se realizan búsquedas frecuentes por atributos no indexados.
- Si se están realizando demasiadas conexiones fallidas desde la misma IP.
- Si se superan los límites.
- Análisis de cachés
Nota: como sugerencia, aportar que para OpenLDAP es muy interesante el siguiente script escrito en perl: http://prefetch.net/code/ldap-stats.pl.txt y sobre Sun DS (ODS), la herramienta SunOne Access Log Analyzer, realiza un estudio completo de los logs, obteniendo datos de accesos, búsquedas y errores. Se dan datos de acceso por IP y por usuario, estableciendo listas de aquellos que utilizan más el directorio. Al final del informe, se indican soluciones a los problemas encontrados.
3.9.2 Estadísticas
Valoración: 25 puntos
Se recomienda generar estadísticas gráficas del uso del directorio y de la carga del sistema y la red. Estas estadísticas serán muy útiles para analizar posibles necesidades a la hora de tomar decisiones sobre el redimensionamiento del servicio, suministrar réplicas con determinadas ramas en alguna VLAN concreta, etc. Para este caso se pueden utilizar herramientas como cacti, nagios …
3.10 Criterio 25. Definición de una política de copias de seguridad.
Valoración: 100 puntos
Un método efectivo de recuperación ante desastres es contar con una copia de la base de datos o un volcado completo del directorio en un archivo ldif reciente y así poder restaurarlo. Teniendo en cuenta que en el directorio se almacenan las credenciales de los usuarios y otros datos de los mismos de carácter privado es aconsejable que estas copias se guarden cifradas.
3.10.1 Política de copias de seguridad
Valoración: 50 puntos
Se recomienda tener definido un documento interno con la política de copias de seguridad, especificando :
- Frecuencia de las copias
- En que formato se guardan
- Si se almacenan cifradas
- Donde se almacenan
- Durante cuanto tiempo se guarda una copia
- Procedimiento de eliminación de dichas copias
3.10.2 Procedimiento de recuperación
Valoración: 50 puntos
Se debe tener definido y documentado un procedimiento de recuperación del directorio tras un desastre. Este procedimiento debe ejecutarse en el momento de su definición para probar su efectividad y los tiempos de recuperación, y además, debe repetirse al menos una vez al año.