---
title: "Detección de manipulación de datos"
description: "Cómo Fystack detecta la manipulación de la base de datos con firmas Ed25519, hashing SHA-256 y verificación automatizada para mantener confiables los datos de las billeteras."
url: https://docs.fystack.io/es/security/database-integrity
last_updated: 2026-11-13
---

> ## Documentation index
> Fetch the complete documentation index at: https://docs.fystack.io/llms.txt
> Use it to discover all available pages before exploring further.

# Detección de manipulación de datos

Fystack refuerza sus bases de datos operativas con una capa de integridad paralela que firma criptográficamente las filas sensibles. Cada registro protegido genera un hash SHA-256 que se firma con una clave Ed25519 almacenada en un SecretStore dedicado. Las firmas se guardan en su propia tabla de integridad, de modo que, incluso si un atacante altera los datos operativos, la manipulación se detecta de inmediato.

> **Info.** Este cambio ayuda a prevenir que atacantes internos accedan a la base de datos y modifiquen registros de forma encubierta, garantizando que cualquier cambio no autorizado se detecte al instante y deje evidencia demostrable de manipulación.

_Diagram: La manipulación de la base de datos por parte de un atacante o un empleado interno se detecta y genera una alerta_

_Image: Retiro bloqueado por datos de billetera manipulados_

El retiro se bloquea por datos de billetera manipulados

## 1. Flujo de integridad

### ¿Cómo funciona la capa de integridad?

_Diagram: Flujo de integridad: extraer, calcular hash, firmar, almacenar_

- **Serialización determinista:** los campos protegidos se ordenan y normalizan antes de calcular el hash, lo que garantiza el mismo flujo de bytes para los mismos datos lógicos.

### Qué se protege

- **Metadatos de la billetera:** ID de la billetera, workspace propietario, usuario propietario, configuración del umbral.
- **Claves públicas de la billetera:** contenido de la clave pública, familia de algoritmos (ECDSA/EdDSA), asociación con la billetera.
- **Configuración de la billetera:** límites de aprobación automática, políticas de gasto, controles de riesgo.
- **Direcciones de la billetera:** dirección on-chain, tipo de dirección, estándares de red.
- **Metadatos de claves HD:** índices de derivación, versiones de cifrado, tipo de blockchain.
- **Configuración de billeteras MPC:** umbrales de firma (2 de 3, etc.), versiones de la biblioteca MPC, revisiones del protocolo TSS.

### Ciclo de vida de firma y verificación

1. Extrae los campos marcados para la cobertura de integridad.
2. Serializa de forma determinista para que el orden y el formato de los campos nunca varíen.
3. Calcula el hash con SHA-256 para producir una huella compacta.
4. Firma el hash con una clave privada Ed25519 guardada en SecretStore o KMS.
5. Almacena la firma, el hash, la versión y los metadatos en la tabla de registros de integridad.

### Verificación

1. Obtén el registro operativo actual cuando se lee o se audita.
2. Recalcula el hash SHA-256 a partir de los valores actuales de los campos.
3. Compara el hash recalculado con el hash almacenado; cualquier diferencia indica manipulación.
4. Verifica la firma Ed25519 usando la versión actual de la clave pública desde la configuración (no desde la base de datos).
5. Si alguno de los pasos falla, bloquea la operación, alerta al equipo de seguridad y registra el intento.

## 2. Detección y monitoreo

### Umbral de billetera modificado

- Ataque: un DBA intenta cambiar una billetera de 2 de 3 a 1 de 3.
- Resultado: el hash no coincide → la verificación de la firma falla → se bloquean las operaciones de la billetera → se dispara una alerta.

### Límite de aprobación automática inflado

- Ataque: un empleado interno sube el límite de aprobación automática de $1,000 a $1,000,000.
- Resultado: cambia el campo de límite firmado → el sistema se niega a aplicar el valor manipulado y registra el incidente.

### Dirección de depósito sustituida

- Ataque: un atacante reemplaza una dirección de depósito por la suya.
- Resultado: el hash de la dirección difiere → la firma no coincide → se detiene el pago → se notifica al equipo de seguridad.

### Matriz de protección frente a amenazas

| Escenario | Protección |
| --- | --- |
| Credenciales de la base de datos comprometidas | Las filas manipuladas producen nuevos hashes, por lo que las firmas fallan la verificación de inmediato. |
| Restauración de un backup con datos editados | Los registros restaurados ya no coinciden con las firmas almacenadas, lo que activa la respuesta ante incidentes. |
| Un DBA malicioso cambia las políticas | Los campos de aprobación automática y de políticas están firmados; las operaciones se bloquean hasta una revisión de seguridad. |
| Una cuenta de administrador comprometida edita la configuración de billeteras | La verificación usa claves públicas fuera de banda, por lo que es imposible falsificar firmas. |