Arquitectura de evidencia

Cómo convertir recibos aleatorios en evidencia revisable

Una fila de base de datos sirve para operar, pero es evidencia débil si el mismo operador puede cambiarla o borrarla sin dejar rastro. Un diseño más sólido une cada solicitud a un recibo y conecta los recibos en estructuras verificables.

Actualizado

Puntos clave

  • El recibo identifica solicitud, operación, hash de resultado, uso y tiempo sin publicar necesariamente el resultado.
  • La cadena hash conserva el orden; cambiar un registro rompe la relación posterior.
  • La prueba de Merkle verifica pertenencia a un lote con una ruta compacta.

Función del recibo por solicitud

El recibo es la unidad que el cliente recupera cuando se cuestiona un resultado. Debe contener identificadores estables y campos normalizados suficientes para recalcular el hash. Los datos sensibles deben quedar fuera o representarse mediante un resumen.

No cada byte necesita evidencia duradera, por lo que la creación puede ser opcional. La política debe ser explícita: con recibos activados, el sistema registra o devuelve un error claro. Omitir evidencia silenciosamente al alcanzar un límite produce una cobertura falsa.

La cadena hash hace visible un cambio de secuencia

Cada recibo puede incluir el hash del anterior dentro del mismo ámbito. Reordenar, cambiar o eliminar un registro altera los enlaces siguientes. No evita todos los fallos, pero permite detectar ediciones posteriores durante la verificación.

El ámbito importa. Una cadena por tenant permite revisar sus registros sin revelar el historial de otro cliente. El verificador debe conocer identificador de cadena y reglas de secuencia.

Merkle reduce el coste de verificar un lote

Un árbol de Merkle combina hashes hasta obtener una raíz para el lote. Para probar la inclusión de un recibo se exportan su hash, los hashes hermanos de la ruta y la raíz. El verificador recalcula la ruta y compara la raíz.

La prueba demuestra pertenencia al lote registrado. Gana valor si la raíz se conserva por separado, se firma o se entrega a una ubicación independiente. Una raíz que solo existe en el mismo sistema mutable ofrece un alcance más limitado.

Conservación, exportación y borrado forman una política

La conservación debe coincidir con el periodo contractual de revisión. La expiración debe incluir datos, índices, exportaciones y copias recuperables. Antes del borrado puede ser necesario exportar recibos, cadenas, pruebas e instrucciones del verificador.

  • Pruebe verificación normal y verificación de campos alterados.
  • Registre la creación y descarga de exportaciones.
  • Publique algoritmos de hash y firma con versión.
  • Mantenga un procedimiento de replay para fallos y colas de mensajes muertos.

Decida qué resultados necesitan evidencia

Podemos relacionar volumen, conservación, exportación y verificación con un plan operativo antes de implementar.

Revisar la política