Permisos y copias de seguridad de un sistema de gestión: qué debe poder verificar el titular

Dos preguntas bastan para saber si un sistema de gestión está gobernado o solo encendido: quién ve qué, y cuánto trabajo se pierde si mañana por la mañana el sistema no está. Son preguntas de titular, no de técnico, y hay que hacerlas antes de firmar, porque después se convierten en peticiones de modificación que hay que presupuestar.

Para verificarlas no hacen falta competencias informáticas. Hacen falta dos documentos que cualquiera puede leer: una tabla de quién puede hacer qué, y el acta de una prueba de restauración realizada con éxito.

Los permisos no son una cuestión de confianza

La objeción más habitual es que en la empresa se confía en todos. El punto es otro: los permisos limitan los daños de los errores, de las credenciales robadas y de las salidas mal gestionadas, y hacen reconstruible quién ha hecho una modificación. Una persona honesta que se equivoca de línea puede borrar un año de fichas exactamente igual que una deshonesta.

• Un permiso se da por la actividad, no por la persona. Cuando cambia el puesto cambia el rol, en lugar de añadir una excepción.
• Ver, modificar, eliminar y exportar son acciones distintas. La exportación es la que se olvida y es aquella por la que los datos salen de verdad de la empresa.
• Algunos datos no hacen falta a quien no los necesita: costes de compra, márgenes, datos del personal, condiciones confidenciales acordadas con clientes concretos.

La matriz de roles y acciones

Es el documento que hace concreta la discusión. Se escribe con los responsables y luego se entrega al proveedor para que la construya, no al revés. Ejemplo ilustrativo para una empresa con almacén, comercial y administración.

La columna que de verdad importa es la última. Enumerar lo que un rol no debe poder hacer obliga a decidir; el listado de lo que puede hacer, por sí solo, tiende a hincharse hasta que ya no significa nada.

Entra, cambia de departamento, sale: el ciclo que nadie gobierna

Los permisos no se estropean el primer día. Se estropean en tres años, una excepción cada vez.

1. Entrada: la persona recibe el rol previsto, no la copia del usuario de un compañero. Copiar un usuario es la forma más rápida de propagar privilegios que nadie había decidido.
2. Cambio de puesto: se quita el rol antiguo y se da el nuevo. Sumar los dos es la causa principal de los permisos acumulados.
3. Sustituciones y delegaciones: tienen una fecha de fin escrita, de lo contrario se quedan.
4. Salida: el acceso se cierra ese mismo día, y en el listado entran también el correo, los archivos compartidos, los dispositivos y las cuentas de servicios externos.

Copias de seguridad: dos números que acordar, no una tranquilidad

A la pregunta «¿hay copias de seguridad?» la respuesta siempre es sí. La pregunta útil tiene dos partes, y ambas son decisiones vuestras antes que técnicas.

• Cuánto trabajo os podéis permitir perder. Si la copia es nocturna, una avería a las 17:00 cuesta una jornada de introducción de datos. Si un día es insostenible hay que aumentar la frecuencia, y esto tiene un coste que comparar con el de la pérdida.
• Cuánto tiempo podéis estar parados. Volver a poner en pie un sistema lleva horas, no minutos, y la duración depende de cuánto se haya preparado por adelantado.

Los dos valores deben escribirse en el contrato junto con lo que comprenden. Un ejemplo ilustrativo, con números por decidir caso por caso: copias diarias conservadas durante algunas semanas, una copia periódica conservada más tiempo, y al menos una copia en un lugar distinto que no se alcance con las mismas credenciales de los sistemas en uso.

• Qué se copia: la base de datos, pero también los adjuntos, los documentos generados, las configuraciones y las personalizaciones. Una restauración de solo la base de datos puede dejar fuera años de documentos.
• Quién controla que las copias se hagan de verdad y a quién se avisa cuando fallan. Una copia de seguridad que falla en silencio es la situación más habitual y la más peligrosa.
• Quién puede acceder a las copias: contienen los mismos datos que el sistema, con las mismas obligaciones de confidencialidad.

Una restauración no probada no existe

La única prueba de que una copia de seguridad funciona es haberla puesto en pie de nuevo. La prueba se hace en un entorno separado, con datos de demostración o con una copia, y se documenta en un acta. El acta es el documento que podéis pedir cada año sin discutir de tecnología.

1. Fecha de la prueba, quién la ejecutó y sobre qué copia.
2. Qué se ha restaurado: sistema, base de datos, adjuntos, configuraciones.
3. Cuánto tiempo ha llevado, desde el inicio hasta que el sistema vuelve a ser utilizable.
4. Qué se ha verificado después: algún documento abierto, algunas fichas comprobadas, una impresión hecha, un acceso probado con un usuario normal.
5. Qué no ha funcionado y cómo se ha corregido. Una primera prueba sin ningún problema detectado, por lo general, se ha hecho de forma demasiado cómoda.

Qué no se puede prometer

Ningún proveedor puede garantizar que un sistema nunca sea vulnerado o que los datos nunca se pierdan. Quien lo promete está vendiendo tranquilidad, no seguridad.

Lo que esta guía no cubre

Aquí se tratan requisitos verificables sobre accesos y recuperación: ninguna garantía absoluta de seguridad y ninguna declaración de conformidad. Las pruebas funcionales que hay que hacer antes de poner en uso un software, es decir, verificar que hace lo que hace falta en los casos reales, son otra cosa y van antes. También cómo evitar quedar atado a un único proveedor, con datos y credenciales que deben seguir siendo vuestros, merece un análisis propio.