Admin: /* 1. Objeto */

2025-10-24T13:30:59Z

1. Objeto

← Revisión anterior		Revisión del 13:30 24 oct 2025
Línea 4:		Línea 4:
	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'''.		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 — ~~Disponibilidad y continuidad~~''' del [[Privado:Plan de Ensayos de Software PiTemp2.0\|Plan de Ensayos de Software PiTemp 2.0]].		Este método de ensayo está asociado al punto '''6 — Inmutabilidad del registro''' del [[Privado:Plan de Ensayos de Software PiTemp2.0\|Plan de Ensayos de Software PiTemp 2.0]].

	== 2. Alcance ==		== 2. Alcance ==

Admin: /* 1. Objeto */

2025-10-24T13:30:45Z

1. Objeto

← Revisión anterior		Revisión del 13:30 24 oct 2025
Línea 3:		Línea 3:
	== 1. Objeto ==		== 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'''.		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 — Disponibilidad y continuidad''' del [[Privado:Plan de Ensayos de Software PiTemp2.0\|Plan de Ensayos de Software PiTemp 2.0]].

	== 2. Alcance ==		== 2. Alcance ==

Admin: /* 2. Alcance */

2025-10-21T16:23:15Z

2. Alcance

← Revisión anterior		Revisión del 16:23 21 oct 2025
Línea 8:		Línea 8:
	* Registros de temperatura procedentes de sensores.		* Registros de temperatura procedentes de sensores.
	* Logs de comunicación y verificación.		* Logs de comunicación y verificación.
	* Bases de datos de almacenamiento histórico ~~(PostgreSQL)~~.		* Bases de datos de almacenamiento histórico.
	* Archivos firmados y verificados.		* Archivos firmados y verificados.

Admin: Página creada con «= 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'''. == 2. Alcance == Este ensayo se aplica a todos los datos de medición y eventos generados por el sistema, desde su adquisición ha…»

2025-10-21T16:22:43Z

Página creada con «= 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'''. == 2. Alcance == Este ensayo se aplica a todos los datos de medición y eventos generados por el sistema, desde su adquisición ha…»

Página nueva

= 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'''.

== 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 (PostgreSQL).
* 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'''.

Privado:Inmutabilidad del registro - Historial de revisiones

Admin: /* 1. Objeto */

Admin: /* 1. Objeto */

Admin: /* 2. Alcance */