Cita:
Empezado por sglorka
Cita:
|
a. La integridad e inalterabilidad de los registros de facturación de forma que, una vez generados y registrados, no puedan ser alterados sin que el sistema informático lo detecte y avise de ello.
|
|
Este requisito está imponiendo a los sistemas que controlen sus datos anteriores para asegurarse que no hay fraude.
Cita:
|
Se entiende que, una vez generados los registros, de alguna manera, tenemos que garantizar que fueron los originales que se crearon en un primer momento. No confundir esto con la adición de huellas hash o firmado electrónico de los registros para garantizar que no han sido modificados (que también hay que cumplir).
|
Pero sí puedes usar huellas para cumplirlo. Y creo que te incentivan a esto...
Cita:
|
Tenemos que demostrar que esos registros fueron los originales que se generaron en un primer momento
|
No creo que vaya a tanto. Tienes que poder detectar si hay un registro alterado, y en tal caso avisar.
Nota también que un sistema puede cumplir avisando si hay meras sospechas de alteración, aunque los registros son los originales, solo si pasa algo que no le cuadra al programa.
Otra cosa: hay casos que precisan de ensanchar los registros del sistema de facturación. El sistema debe continuar a cumplir aunque necesariamente los registros ya no son los originales (que eran más estrechos).
Cita:
|
[...] ya que podemos generar una serie de registros simulados a posteriori alterando las fechas de creación de los registros mediante utilizades archiconocidas y manteniendo su encadenamiento y huellas hash. Estos registros simulados son tan válidos como los originales.
|
Si cambias algún dato en un registro, siga una fecha o cualquier otra cosa, la huella SHA256 del registro no será la misma; si los registros están encadenados —es decir, la huella del precedente es parte de los datos del registro— cambiar la huella SHA256 de uno cambia todas los siguientes huellas; incluyendo entonces el último registro.
Por tanto, si al generar o validar un registro compruebas que la huella del precedente (él que era el último) no coincide con la esperada, sabes que hay alguna alteración, y debes señalarla.
Y ocurre que en su gran sabiduría, AEAT nos pide guardar dicha huella dentro del nuevo registro...
Cita:
|
Entiendo que deberíamos generar una clave hash de todo el fichero y almacenarla en una tabla donde se registre cada registro de facturación emitido. De esta manera, podemos comparar el hash del archivo de registro de facturación con el hash que tenemos en nuestra tabla de registros
|
Me parece una manera complicada de cumplir con la normativa. Mi archivo actual de facturación pesa más de 500 MiB, no me veo calculando la huella SHA256 a cada vez que quiero generar un nuevo registro. Además, un fichero de base de datos tiene habitualmente bytes de relleno sin usar que puedan cambiar de valor sin alterar los registros en sí (aunque esto sí puede ser un ejemplo de lo que he escrito arriba sobre las sospechas).