Como ya hemos comentado en anteriores apuntes, las aplicaciones construidas con Notes no serían nada sin aspectos tan relevantes como la seguridad. El manejo de la seguridad en Notes es algo inherente a ella. No se trata de un complemento - plugin -, añadido o parche como necesitan otros sistemas (o millares de ellos). En este artículo vamos a ver los pilares básicos para el acceso a la información de aplicaciones o bases de datos que residan en un servidor Domino o estación local Notes. El ID de NotesEl identificador de Notes (ID) es un pequeño archivo de entre 3-10 KB (Kilo bytes) con extensión ID que identifica de manera unívoca y suficiente a un servidor Domino o a un usuario de Notes. Se dice que identifica de manera suficiente porque contiene todas las condiciones que deben cumplirse para que un usuario o un servidor obtengan acceso a los datos. Para poder acceder a un servidor Domino con el cliente Notes es necesario haber sido registrado en él. Esta operación actualizará el Directorio de Domino o Address Book, una base de datos estándar en el que el servidor Domino guarda, entre otras cosas, una lista de todas las personas registradas y el tipo de perfil básico de acceso de cada uno de ellos. Históricamente, tres son los perfiles definidos por Lotus en este sentido: Diseñador, Usuario de aplicaciones y Usuario de Correo. Con el primer nivel de acceso pueden diseñarse aplicaciones, con el segundo pueden accederse a las aplicaciones y con el tercero sólo a la aplicación de correo. Como veremos en otro artículo estos perfiles clásicos han evolucionado y se han simplificado. [Nota: en el próximo evento del ESLUG habrá una ponencia sobre el licenciamiento de Domino / Notes, tipos de acceso, etc.] El proceso de registro de un nuevo usuario culmina con la emisión por parte del servidor de un certificado de acceso que se recoge dentro de un fichero de identificación con extensión ID. Este fichero es la clave para que alguien, desde un entorno cliente Notes o servidor Domino, pueda conectarse y tener acceso a las aplicaciones del servidor. Además define qué tipo de perfil básico tiene y si podrá diseñar aplicaciones o no. Cuando el acceso se realiza desde Internet la cosa cambia. Los navegadores son aplicaciones altamente inseguras y, de entrada, no hay fichero ID de identificación de persona. El acceso desde Internet (usuario anónimo) podrá realizarlo cualquiera si la aplicación Notes permite específicamente la entrada de usuarios anónimos. Un ejemplo es la propia aplicación de blog sobre la que Usted está leyendo este artículo. Para que los usuarios anónimos puedan escribir comentarios es necesario otorgarles el perfil de acceso Autor. Otro ejemplo es la aplicación de foro del ESLUG que necesita registro previo de la persona. En este caso, los usuarios anónimos - sin registro - disponen sólo del perfil de acceso Lector por lo que no pueden escribir en la aplicación sin previo registro. Los archivos de identificación de usuario se crean automáticamente en el proceso de registro y permiten a un usuario Notes conectarse a un servidor Domino. Un usuario Notes sin archivo ID no se puede conectar a un servidor Domino, salvo que sea un usuario de Internet/Intranet o POP3 y el servidor tenga activados los servicios TCP/IP necesarios o el servidor permita específicamente el acceso anónimo a nivel de servidor. Cada archivo ID de usuario o servidor contiene los siguientes ítems.  Visualización de la información del IDPara consultar la información contenida en un archivo ID se pueden utilizar dos métodos. 1) Desde el cliente IBM Lotus Notes, elija Archivo --> Seguridad --> Seguridad del Usuario para ver la información del ID de usuario o servidor activo. 2) Desde el cliente IBM Domino Administrator --> Pestaña Configuración --> Panel Certificación --> Propiedades del ID...  Evidentemente, para acceder al contenido del fichero ID - ya sea de usuario, servidor o certificador - habrá que introducir previamente la contraseña o contraseñas en caso de que hubiera. Esto nos garantiza que un administrador - ni siquiera con derechos de Full Admin en la configuración del servidor - pudiera acceder o espiar las claves personales de codificación almacenadas en un fichero de ID de usuario (no la contraseña del fichero ID).  Consultar la información del fichero ID de usuario nos puede servir, por ejemplo, para consultar la fecha de caducidad del certificado ID, para consultar las claves de codificación, verificar si disponemos de certificados de Internet, averiguar el tamaño (seguridad) de la clave pública o confirmar si nuestro ID está sincronizado con el repositorio centralizado o caja fuerte de archivos (ID Vault). Vamos a ver un ejemplo práctico. Expondremos los detalles de dos ficheros ID de usuario de dos servidores Domino distintos y auditaremos sus propiedades. Fichero ID de usuario (Servidor Domino A)  Como auditores, ¿qué factores importantes deberíamos anotar? Veamos la respuesta. Los factores que se identifican en el fichero ID del servidor Domino de la empresa A son los siguientes: - El tamaño (seguridad) del ID de codificación es de RC2 de 64 bits. Es un valor bajo. Estudiaremos en otro artículo los tamaños de la clave de codificación y la seguridad asociada. - La fecha de caducidad o renovación del fichero ID es en el año 2023. Estudiaremos en otro artículo cómo bloquear accesos con ficheros ID no caducados. - El usuario deberá cambiar la contraseña el próximo 1 de agosto de 2011 por lo que deducimos que el servidor tiene activado la verificación de contraseñas en el documento de persona del usuario. Esto proporciona gran seguridad pues garantiza que no hay usos ilegales de los archivos ID de usuario, es decir, no hay suplantación de identidad. - La sesión de la estación Notes no se bloquea automáticamente pasados unos minutos (!) - Y no existe una copia del fichero ID en el repositorio ID Vault. Puede ser porque el servidor Domino no esté en versión 8.5 o superior o no esté configurado por el administrador. (!) Fichero ID de usuario (Servidor Domino B)  A continuación exponemos los factores que identifican a simple vista el fichero ID del servidor Domino de la empresa B. - El tamaño (seguridad) del ID de codificación es de RC2 de 128 bits. Es un valor mayor y proporciona mayor seguridad comparado con el fichero ID de la empresa A. - La fecha de caducidad o renovación del fichero ID es en el año 2013. El usuario deberá renovar la validez de un fichero ID en esa fecha. - El usuario no tiene activada la verificación de la contraseña del fichero ID contra el servidor Domino por lo que puede existir suplantación de identidad con una copia de su fichero ID por parte de otra persona. Esta desviación es importante y debe corregirse. (!) - La sesión de la estación Notes se bloquea automáticamente pasados unos minutos. Mayor seguridad. - Existe una copia del fichero ID en el repositorio ID Vault. Esta configuración proporciona gran seguridad a la infraestructura Domino pues permite una gestión centralizada de los ficheros ID de usuario y permite recuperar la contraseña del usuario sin hacer uso de "copias" de archivos de ID de usuario. ContraseñasTodos los usuarios y servidores disponen de contraseñas para proteger sus archivos ID. Una contraseña es una cadena alfanumérica que puede tener una longitud máxima de 63 caracteres. Se utiliza para permitir o denegar el acceso a un servidor, una base de datos basada en servidor o un archivo ID. Para obtener un mayor nivel de control de acceso, Domino ofrece mecanismos de protección adicionales, como el uso de varias contraseñas, el retraso temporal y el mecanismo anti-imitaciones. Mecanismo de protección por varias contraseñasLos archivos ID de Notes pueden configurarse de modo que soliciten varias contraseñas, lo cual impide el acceso a cualquier persona. El administrador puede determinar el número de contraseñas correctas requerido para poder utilizar el archivo ID. El uso de varias contraseñas proporciona una mejora de la seguridad para los archivos ID de servidores y certificadores. Imaginemos que tenemos un servidor con contraseña en el fichero server.id que tiene información altamente confidencial. Podemos configurarlos para que solicite varias contraseñas lo cual le confiere una muy alta seguridad. Otro escenario posible para definir varias contraseñas para un archivo ID es por ejemplo en un archivo ID de certificador para evitar que un único administrador sea capaz de registrar o certificar usuarios. Otro escenario de ejemplo. Imaginemos por ejemplo una aplicación de RR.HH. con documentación confidencial. Para poder acceder a la aplicación, podríamos configurar el ID para que necesite la introducción de 2 contraseñas. Una conocida sólo por la Directora de RRHH. Otra contraseña diferente conocida por el Administrador Notes y otra contraseña conocida sólo por el Director Financiero. Para poder acceder a la aplicación se necesitaría la "validación" de 2 personas físicas, o sea, la introducción de su clave para ese ID específico por al menos 2 personas autorizadas. Hemos introducido como personas autorizadas a 3 personas, de esta manera también se cubriría la contingencia de una posible baja o vacaciones de una de ellas lo cual impediría acceder a la aplicación.  Como hemos podido observar, este mecanismo proporciona una altísima seguridad durante el acceso a una aplicación Notes con información altamente confidencial. Retraso temporalLas contraseñas llevan incluido un mecanismo de retraso temporal para disuadir a los programas de adivinación de contraseñas. Cuando un usuario escribe la contraseña correcta almacenada en el fichero ID, Notes permite el acceso prácticamente inmediato. Sin embargo, si se introduce una contraseña incorrecta, Notes incrementa el tiempo requerido para poder continuar. Cada vez que se utiliza una contraseña incorrecta, se incrementa sustancialmente el retraso de tiempo.  Anti-imitaciones de la entradaAlguien podría pensar que los jeroglíficos que aparecen en el cuadro de diálogo de Lotus Notes es una paranoia de algún programador frikie. Nada más lejos de la realidad. Usted anda muy equivocado. Es un mecanismo que crea un icono único con la apariencia de un patrón de jeroglíficos cuando se escribe una contraseña que impide intentos de robar una contraseña escribiendo un programa de captura de contraseñas con el mismo aspecto que el cuadro de diálogo de solicitud de contraseña. Además, incluye un mecanismo "anti curiosos" que intenten contar el número de caracteres que estamos introduciendo variando la longitud del número de caracteres introducidos añadiendo varias exis en el patrón de la contraseña.  En este artículo, hemos introducido el elemento fundamental de toda arquitectura Domino/Notes, los archivos ID y hemos descrito algunos mecanismos de seguridad. En un próximo artículo pondremos a prueba la seguridad de Notes y veremos un ataque de fuerza bruta a un fichero de ID de usuario y comprobaremos los resultados. |
