Registro de auditoría firmado criptográficamente y a prueba de manipulaciones.
Cada acción (sesiones, comandos, acceso a secretos, ediciones de políticas) se somete a hash, se enlaza con la entrada anterior y se firma con una clave Ed25519 sellada en hardware TPM en autoalojamiento; en la nube gestionada, protegida hoy por los mismos controles a nivel de host que el resto del servicio. Un administrador de la empresa verifica un rango mediante GET /audit/verify: el servidor recalcula el hash de cada fila y comprueba su firma contra la clave registrada; la clave pública de su empresa se publica en /audit/pubkey/:company_id.
🔒audit:8419 · tool.readb3:9f8c…
prev_hash↓
🔒audit:8420 · tool.edit7f:21c8…
prev_hash↓
🔒audit:8421 · session.spawna4:6055…
prev_hash↓
🔒audit:8422 · vault.readc8:1142…
verified↓
Chain intact · 1,284,309 entries—
Cómo funciona
1
Ocurre una acción
Un usuario lanza una sesión, un agente lee un archivo, un administrador edita una política.
2
Hash y enlace
La entrada se somete a hash (sha256) con una referencia al hash de la fila anterior.
3
Firma Ed25519
En autoalojamiento, la firma la produce una clave sellada en hardware TPM que nunca sale del chip. En la nube gestionada, por los mismos controles a nivel de host que el resto del servicio.
4
Verificación en el servidor
Un administrador de la empresa pide un rango de filas a GET /audit/verify; el servidor recalcula el hash de cada fila y comprueba su firma Ed25519 con la clave que guarda para esa cadena.
Análisis a fondo
Encadenamiento por hash
El campo prev_hash de cada entrada es el sha256 de la fila anterior. Elimina la fila N y las filas N+1 en adelante dejan de verificarse: la cadena se rompe de forma visible.
Firma y sellado en TPM
En autoalojamiento, la clave de firma se sella en el hardware TPM de su host y se desenvuelve solo dentro del proceso audit-signer. En la nube gestionada, hoy no hay TPM de hardware ni KMS en la nube configurado: la clave está protegida por los mismos controles a nivel de host que el resto del servicio, no por un backend de gestión de claves dedicado.
Verificación paginada
Una verificación sin paginación examina como máximo 10 000 filas; si el rango tiene más, se detiene ahí, lo marca como truncated y responde ok: false en lugar de hacer pasar un prefijo por el rango completo. Para recorrer una cadena de 1,2 M de filas, pasa batch= y ve página a página: cada página devuelve has_more, un cursor next_after_id y el prev_hash que enlaza con la siguiente petición, que es lo que mueve la barra de progreso en la interfaz de administración.
Verifique la cadena usted mismo
shell · verify CLI
$caldyr audit verify--from 8400 --to 8500
chain intact ✓
entries verified : 101
total in range : 101
last hash : 9f8ce4d27a91…3a4e
A prueba de manipulaciones, no solo resistente a ellas.
No te damos la promesa de no cambiar registros; te damos una cadena que hace detectable un cambio. Cada fila está enlazada por hash y firmada con Ed25519, así que una edición dentro de un rango verificado rompe el enlace y la verificación marca esa fila como manipulada. Conviene ser claro sobre quién hace la comprobación: /audit/verify es nuestro endpoint y la clave de firma contra la que compara la tenemos nosotros, así que lo que obtiene un administrador es evidencia para actuar, no una prueba independiente. La clave pública de tu empresa se publica en /audit/pubkey/:company_id; ninguna herramienta que distribuimos verifica todavía una cadena con ella.
Comparativa
Caldyr
Registros de BD comunes
Registro de solo anexión
A prueba de manipulaciones
sí
no
sin firma
Prueba criptográfica
Ed25519 + sha256
ninguna
ninguna
Clave pública publicada
sí · /audit/pubkey/:company_id
no
no
Clave de firma por inquilino
sellada en TPM (autoalojamiento)
no
clave compartida
Verificación paginada
paginación batch · tope 10 000
no
carga todo en memoria
Preguntas frecuentes
Se genera una clave nueva. Las filas previas a la rotación siguen siendo verificables con la clave pública anterior; las posteriores usan la nueva. Perderla sin rotar significa que la cadena pasa a ser de solo anexión, sin firmas futuras, pero todo lo firmado hasta ese punto sigue siendo verificable.
Un auditor verifica la cadena con la CLI de Caldyr: caldyr audit verify --from <n> --to <n>. La CLI necesita un token de API y llama a nuestro /audit/verify, que solo puede invocar un administrador de esa empresa: o le entregas al auditor un token así, o ejecutas el rango por él. La comprobación de la firma ocurre en el servidor, contra la clave registrada. Para retención a largo plazo, exporta el registro como CSV desde la pestaña de auditoría; en Enterprise el registro firmado completo también se transmite a su SIEM o a un bucket S3 WORM que ellos controlen.
La firma no está en el camino de la acción. Primero se escribe y se confirma la fila de auditoría; después un worker firmante en Node se despierta con un NOTIFY de Postgres y la firma: una firma Ed25519 por cada fila, en serie dentro de la cadena de cada empresa o usuario, con un sondeo cada 30 segundos como respaldo. Hasta que la fila esté firmada, una verificación la cuenta como pendiente.
Autoalojado en una máquina con TPM 2.0: sellada al chip, nunca exportada en claro, abierta solo en ese host. En el servicio gestionado el host no tiene TPM, así que la semilla es un fichero en ese host legible por la cuenta de servicio del firmante. En ambos casos la clave la tenemos nosotros y la verificación la ejecutamos nosotros, así que un rango limpio es nuestra atestación y no una comprobación independiente hecha por ti; la clave pública de esa cadena se publica en /audit/pubkey/:company_id y ninguna herramienta que distribuimos hoy comprueba una cadena sin nosotros.
¿Listo para gobernar su infraestructura de IA?
Solicite acceso en minutos, o hable con nosotros sobre su despliegue aislado de la red.