En muchos proyectos he encontrado que se tiende a pensar en la “Seguridad” en la Gestión Documental como algo “técnico” que “ya aclararán los técnicos o administradores” y que no hace falta incluir en los requerimientos iniciales definidos por documentalistas y usuarios. Nada más peligroso, no solo desde el punto de vista de la seguridad sino como fuente de problemas y retrasos en el proyecto.; puede considerarse (casi) tan importante como la definición de tipologías documentales.
Aunque era una percepción «subjetiva», al buscar referencias para incluir en el texto me he encontrado que es difícil encontrar textos sobre el tema. Y eso que la mayor parte de los gestores documentales requieren definir muchos de los conceptos que comento posteriormente, ya sea para crear nuevos proyectos verticales o para utilizarlos recién instalados («out of the box» en inglés).
¿Qué incluimos en “Seguridad”?
Cuando se habla de «Seguridad», pueden surgir muchas interpretaciones y matices respecto a qué se debe incluir. Simplificando, podemos hablar de 3 aspectos en este tipo de proyectos:
- Seguridad de infraestructura: Asegurar que nadie puede acceder a los documentos si no es a través del programa o servicios correspondientes.
- Autenticación: Es decir, verificar que quien quiere utilizar las funciones o los servicios expuestos es quien dice ser.
- Autorización: Verificar que quien desea realizar una operación está autorizado para hacerlo.
Seguridad de infraestructura:
Este apartado incluiría elementos básicamente tecnológicos como el uso de comunicaciones seguras con https, encriptación de los datos almacenados, acceso al almacenamiento, copias de seguridad.
Esta serie de medidas evitarían situaciones como que alguien se conecte a la red y pueda captar datos o documentos cuando transitan por ella, o que alguien acceda a los discos donde se almacena la información y pueda recuperar documentos sin utilizar el programa. No puede asumirse que todas las medidas se apliquen «por defecto» ya que lógicamente todas ellas tienen un coste en complejidad, rendimiento y económicamente, por lo que no se aplicarán automáticamente “salvo que sea necesario”.
Y esa “necesidad” es una decisión que no es puramente técnica. Por ejemplo si se plantea manejar documentos cubiertos por el nivel alto de la LOPD, tal como explica el reglamento que desarrolla la LOPD u otros documentos de la Agencia de Protección de Datos (Guía de Seguridad), deberá disponerse de:
- Sistema de etiquetado confidencial.
- Cifrado de datos en la distribución de soportes.
- Cifrado de información en dispositivos portátiles fuera de las instalaciones
- Registro de accesos: usuario, hora, fichero, tipo de acceso, autorizado o denegado.
- Revisión mensual del registro por el responsable de seguridad.
- Conservación 2 años.
- Copia de respaldo y procedimientos de recuperación en lugar diferente del que se encuentren los equipos
- Destrucción de copias desechadas
- ….
Por tanto ciertos aspectos de la infraestructura (no todos desde luego) viene determinados por el hecho de que el documento esté sujeto (o puede estar sujeto en algún caso) a un nivel determinado de LOPD, que es fruto de un análisis del proceso documental y de los documentos del mismo, no es una decisión “técnica”.
Será por tanto imprescindible identificar en unas primeras etapas los requerimientos documentales (normativas, leyes, recomendaciones,..) que puedan afectar a la forma en que los documentos se introducen, viajan o se almacenan en el sistema.
Autenticación:
La autenticación suele realizarse por medio de usuario y clave, pero en ocasiones puede utilizarse otros sistemas, desde medios físicos o biométricos (tarjetas, huellas,..) a “confianza” en otros sistemas relacionados (SSO-Single Sign On).
Como en el caso anterior, la decisión de qué método utilizar vendrá determinada, entre otros criterios, por decisiones y requerimientos del proyecto. El determinar que usuarios y en qué condiciones necesitarán identificarse ante el sistema, determinará cómo puede realizarse la autenticación.
Por ejemplo si todos los usuarios son internos y disponen de tarjeta identificativa, podría utilizarse esa forma de acceso, sin embargo si son usuarios esporádicos o remotos, no sería factible. Si los usuarios accederán siempre desde una aplicación o portal de la entidad, puede no ser necesario realizar autenticación pues ya se ha comprobado su identidad previamente.
Por tanto el definir los distintos tipos de usuarios que utilizarán la aplicación documental y las condiciones en que se conectarán a la misma determinará las formas posibles de autenticación ante el sistema.
Autorización:
Esta es quizá la parte más importante y menos “técnica” de todas. ¿Cómo suele expresarse la autorización, es decir los permisos sobre un elemento?
En la mayoría de los casos, se hace por medio de Listas de Control de Acceso (ACL o Access Control List).
Ej: ACL: «Expedientes en Trámite».
| Grupo/Usuario | Permiso |
| Tramitadores | Escritura |
| Coordinadores | Lectura |
| Administradores | Borrado |
Estas listas suelen constar de un nombre (“Documentos Privados”, “Expedientes en Tramite”, ..) y una lista de personas o grupos de personas con sus permisos. Estos ACL se asignan a los distintos elementos (documentos, expedientes, fondos, ..) pudiendo cambiar durante la vida del elemento.
Ej. Un Expediente podrá tener inicialmente el ACL “Expediente en Tramite”, ser cambiado luego a “Expediente Restringido” y finalmente “Expediente Cerrado”, teniendo en cada caso los permisos adecuados para asegurar qué personas o grupos pueden manipularlo o leerlo en cada fase.
Otros sistemas más rudimentarios (asignar a los elementos o usuarios permisos lectura/escritura, indicar para cada elemento concreto los permisos de acceso de todos los usuarios) no son válidos, pues no tiene el detalle necesario (un usuario puede tener diferentes permisos para diferentes elementos) ni permiten cambiar según evoluciona el expediente o cambian las normas relativas al mismo (pues los valores están asignados uno a uno a cada elemento). Salvo casos muy limitados y particulares, es recomendable utilizar siempre ACL, que es el modelo seguido por la mayoría de herramientas de gestión documental de propósito general.
El definir esos ACL y los momentos en que se aplican es definir en detalle el proceso documental. Definir dentro del proyecto elementos como:
- ¿Qué estados existen? (no basta poner una marca de estado, además deberá estar estructurado que puede hacerse en cada estado y por parte de quien)
- ¿Quién puede hacer qué operaciones en cada momento? (preferentemente orientado a grupos/roles, no personas)
- ¿Quién accede a los documentos o expedientes? (criterios “jerárquicos”, territoriales, ambos, según el momento)
- ¿Qué grupos/roles existen y sobre que actúan? (los grupos pueden utilizarse con diversos criterios, para indicar tanto pertenencia a un organismo departamento como funciones de un grupo de usuarios, en general o dentro de un departamento)
Son preguntas que nos permitirán definir los ACL del proyecto y que se reflejarán posteriormente en un elemento “técnico” como pueden ser los ACL. Pero sin esas preguntas, no está definido en absoluto el proceso documental, solo existirá una serie de definiciones de elementos (tipos documentales, tipos de expedientes, etc.) estáticos y aislados.
En resumidas cuentas, con los ejemplos anteriores espero haber llamado la atención sobre la importancia de tener en cuenta los diversos aspectos de la seguridad dentro de todo el análisis y proyecto documental y no considerarlo un elemento totalmente independiente.
