Privado:Inmutabilidad del registro

Privado: Inmutabilidad del registro

1. Objeto

Garantizar que los datos registrados por PiTemp 2.0 no puedan ser modificados, eliminados ni sustituidos una vez generados, preservando así la cadena de custodia electrónica y la integridad metrológica exigida por el Apéndice II del Anexo XI de la Orden ICT/155/2020.

Este método de ensayo está asociado al punto 6 — Inmutabilidad del registro del Plan de Ensayos de Software PiTemp 2.0.

2. Alcance

Este ensayo se aplica a todos los datos de medición y eventos generados por el sistema, desde su adquisición hasta su almacenamiento permanente:

• Registros de temperatura procedentes de sensores.
• Logs de comunicación y verificación.
• Bases de datos de almacenamiento histórico.
• Archivos firmados y verificados.

3. Principio del sistema

Cada registro generado por PiTemp 2.0 incorpora mecanismos de control que impiden su modificación posterior:

• Se calcula un hash SHA-256 individual para cada medición en el momento de la recepción.
• Los hashes se almacenan junto al registro en el archivo .signed, imposibilitando su alteración sin dejar evidencia.
• El acceso a escritura sobre los datos históricos está restringido únicamente al proceso de adquisición; los usuarios disponen solo de permisos de lectura o exportación.
• Cualquier intento de modificación directa en base de datos queda registrado en el log del sistema y genera alerta.

3.1. Limitaciones y control de privilegios

• El sistema operativo y la base de datos están protegidos mediante control de acceso y roles diferenciados.
• Solamente el usuario root o equivalente dispone de privilegios administrativos necesarios para mantenimiento del sistema. Este usuario solamente es accesible por los técnicos de 3innova.
• Cualquier acción realizada con dichos privilegios se considera intervención técnica y queda fuera del uso ordinario del software.
• Todas las acciones administrativas quedan registradas en los logs del sistema (syslog, journalctl) y no pueden eliminarse sin dejar evidencia.
• Los procedimientos de auditoría incluyen la revisión de estos logs y la comparación de copias de seguridad para detectar alteraciones.
• En caso de discrepancia entre los datos originales y las copias firmadas, se investiga la causa y se documenta la intervención técnica.

4. Procedimiento de verificación

• Verificación de integridad de archivos firmados: se selecciona una muestra de registros (.log.signed) y se recalcula el hash SHA-256. Los valores deben coincidir con los almacenados.
• Bloqueo de escritura en base de datos: se intenta modificar un registro histórico mediante una conexión de prueba; el sistema debe denegar la operación.
• Control de auditoría: se revisan los logs de acceso y escritura para confirmar que no se ha producido modificación alguna. Las actualizaciones válidas se realizan exclusivamente mediante inserción de nuevos registros.
• Verificación de exportaciones: se exportan registros a CSV o PDF y se comparan sus hashes con los originales. Los valores deben coincidir exactamente.

5. Criterios de aceptación

• Coincidencia del 100 % entre los hashes recalculados y los almacenados.
• Denegación total de intentos de escritura o modificación sobre registros históricos.
• Ausencia de discrepancias entre los datos exportados y los originales.
• Registro de todos los accesos de escritura en los logs de auditoría.
• Mantenimiento de los registros íntegros durante un mínimo de 5 años.

6. Evidencias generadas

• Archivos .log.signed y .log.signed.verified conservados en carpeta segura de ensayos.
• Logs de sistema que demuestran intentos de acceso y denegación de escritura.
• Informes de comparación de hash firmados electrónicamente.
• Captura del ajuste de permisos de sólo lectura en la base de datos (rol de adquisición exclusivo).
• Registro de eventos administrativos (root) con su correspondiente hash o checksum.

7. Gestión de no conformidades

• Hash no coincidente: investigación inmediata de causa y comparación con copia de seguridad.
• Intento de escritura detectado: bloqueo del usuario o proceso y notificación al responsable técnico.
• Modificación autorizada por error de calibración: debe registrarse mediante una nueva entrada, sin sobrescribir el valor anterior.
• Exportación con diferencias: verificación del formato y regeneración del archivo.

8. Periodicidad del ensayo

• Ensayo de recalculado de hashes: trimestral.
• Verificación de permisos de sólo lectura: anual o tras actualización del sistema.
• Revisión de logs de auditoría: mensual.

9. Conclusión

El sistema PiTemp 2.0 garantiza la inmutabilidad de los registros mediante el uso de firmas hash SHA-256, control de accesos, auditoría de logs y conservación de copias verificadas. Aunque las intervenciones administrativas con privilegios root son posibles, quedan fuera del uso ordinario del sistema y se registran en logs inalterables, lo que permite su detección y trazabilidad. Estos mecanismos aseguran que ningún dato puede ser alterado sin dejar evidencia, cumpliendo los requisitos de integridad y trazabilidad establecidos por la Orden ICT/155/2020.