Custodia institucional y gestión de claves · Lección 3 de 5
Niveles de billeteras, políticas de transacción y flujos de firma
9 min de lectura
Las claves sólidas no sirven de mucho si una sola persona puede ordenar que firmen cualquier cosa. Los controles en torno a la firma determinan dónde se guardan las claves, qué transacciones se permiten, quién debe aprobarlas y qué ven realmente los firmantes; ahí es donde la mayoría de las pérdidas institucionales se detienen o se hacen posibles. En esta lección, seguiremos una transacción desde la solicitud hasta su difusión.
Billeteras calientes, templadas y frías
Los custodios y los exchanges dividen los activos en niveles. Cada nivel intercambia velocidad por seguridad.
| Nivel | Dónde están las claves | Quién o qué firma | Velocidad típica | Uso típico |
|---|---|---|---|---|
| Caliente | Servidores conectados a Internet, nodos MPC o HSM en la nube | De forma automatizada, dentro de los límites de la política | Segundos | Retiros habituales de clientes |
| Templada | En línea, pero la firma requiere aprobación humana | Aprobadores mediante un motor de políticas | De minutos a horas | Recargar la billetera caliente, transferencias grandes de clientes |
| Fría | Fuera de línea: HSM aislados de la red o dispositivos en bóvedas | Varias personas, a menudo presentes físicamente | De horas a días | La mayor parte de los activos |
La billetera caliente solo debería contener lo que necesitan las operaciones. A modo de ilustración, pensemos en un exchange con USD 2.000 millones en activos de clientes y retiros netos diarios promedio de USD 30 millones. Podría mantener entre USD 40 y 60 millones en caliente (2–3 %), suficiente para un día normal más un margen de reserva. Los depósitos excedentes se transfieren periódicamente al almacenamiento templado o frío, y la billetera caliente se recarga mediante un proceso controlado. Estas cifras son un ejemplo, no un estándar. El tamaño adecuado depende de los patrones de retiro, los compromisos de nivel de servicio y las condiciones del seguro.
«Frío» no significa que esté a salvo de todos los ataques. Las claves frías están fuera de línea, pero las personas aún deben aprobar las transacciones, y los procesos de aprobación pueden ser engañados. El robo de Bybit en febrero de 2025 comenzó como una transferencia rutinaria desde una billetera fría (consulta la lección Amenazas y controles de seguridad operativa).
Motores de políticas
Un motor de políticas verifica cada solicitud de transacción frente a un conjunto de reglas antes de que cualquier clave o fragmento de clave firme. Tipos de reglas habituales:
| Tipo de regla | Ejemplo |
|---|---|
| Umbral de importe | Por encima de USD 1 millón: dirigir por la ruta fría y añadir un aprobador de riesgos |
| Destino | Permitir solo direcciones incluidas en la lista de permitidas; no hacer transferencias a direcciones nuevas |
| Activo y red | Solo USDC en cadenas aprobadas; bloquear contratos de tokens desconocidos |
| Velocidad | Máximo de USD 10 millones por billetera cada 24 horas |
| Iniciador | Solo el rol de operaciones de tesorería puede iniciar retiros |
| Intervalo horario | Las transferencias grandes solo pueden hacerse durante el horario con personal disponible |
| Tipo de transacción | Bloquear llamadas a contratos que cambien la titularidad, actualicen el código o utilicen delegatecall, salvo que reciban una aprobación especial |
Dos aspectos de diseño son importantes. Primero, la política debe aplicarse donde se realiza la firma: dentro del entorno seguro del HSM, por los cofirmantes MPC o en la billetera de contrato inteligente. Si solo se verifica en una aplicación web, alguien con acceso al servidor puede eludirla. Segundo, los cambios a la política son, por sí mismos, transacciones de alto riesgo. Añadir un aprobador, aumentar un límite o editar la lista de permitidas debería requerir su propio quórum y un retraso.
Un motor de políticas también genera evidencia. Cada solicitud, evaluación de reglas, aprobación y rechazo debería registrarse en un registro que no pueda alterarse, junto con el usuario, el dispositivo y la hora. Los auditores prueban los controles usando estos registros, y los equipos de respuesta a incidentes los usan para reconstruir lo sucedido. También hay que prestar atención a las solicitudes rechazadas: una serie de intentos bloqueados hacia direcciones nuevas puede ser la primera señal de un ataque.
Quórums y segregación de funciones
Un quórum es el número de aprobaciones necesarias, expresado como m-de-n (por ejemplo, 3-de-5). El quórum solo funciona si los aprobadores son verdaderamente independientes.
La segregación de funciones separa los roles que, de otro modo, podrían combinarse para cometer fraude:
- El iniciador crea la solicitud, pero no puede aprobarla.
- Los aprobadores revisan y aprueban, pero no pueden cambiar el destino.
- Los firmantes o custodios de claves operan las claves, a menudo sin poder iniciar transacciones.
- Los administradores de políticas gestionan las reglas y los usuarios, pero no pueden transferir fondos.
Entre los fallos habituales se encuentra el colapso del quórum: en un esquema de 3-de-5 en el que tres aprobadores pertenecen al mismo equipo, un gerente o una campaña de phishing puede alcanzar el quórum. Otros fallos incluyen que personas que dejan la organización conserven el acceso después de cambiar de puesto y el uso de credenciales compartidas. Las buenas prácticas consisten en distribuir a los aprobadores entre departamentos y ubicaciones, revisar los accesos al menos cada trimestre, revocar el acceso el mismo día en que alguien se va y exigir control dual —dos personas en todo momento— para el acceso físico al almacenamiento en frío.
Listas de permitidas, límites de velocidad y bloqueos temporales
Las listas de permitidas (también llamadas listas blancas) restringen los retiros a direcciones aprobadas previamente. Solo detienen la mayoría de los ataques de sustitución de direcciones si añadir una dirección es difícil. Un proceso sólido requiere:
- una solicitud respaldada por pruebas de quién es el propietario de la dirección
- confirmación por un canal independiente, mediante un número de teléfono que ya figure en el registro y que no sea el de la solicitud
- una pequeña transferencia de prueba que la contraparte confirme
- un período de espera, a menudo de 24 a 48 horas, antes de que se pueda usar la dirección
Los límites de velocidad limitan el valor por transacción, por hora y por día; idealmente, se suman en una moneda de referencia a través de todos los activos, para que un atacante no pueda dividir un robo en muchos movimientos pequeños.
Los bloqueos temporales añaden un retraso entre la aprobación y la difusión, o entre la difusión y la posibilidad de gastar los fondos. Ese intervalo permite que los equipos de monitoreo detecten y cancelen una transacción maliciosa. Pueden funcionar fuera de la cadena, como una cola de pendientes en la plataforma de custodia, o en la cadena. Bitcoin admite bloqueos temporales en la cadena mediante CHECKLOCKTIMEVERIFY (BIP 65) y CHECKSEQUENCEVERIFY (BIP 112), y los diseños de «bóveda» los utilizan para dar tiempo a una clave de recuperación para reclamar los fondos. En las cadenas EVM, los contratos de bloqueo temporal cumplen la misma función. El costo es la velocidad, por lo que los acuerdos con los clientes deben especificar tiempos de retiro que contemplen estos retrasos.
Simulación de transacciones y firma clara
Un firmante debería saber exactamente qué hará una firma. Dos técnicas lo hacen posible.
La simulación de transacciones ejecuta la transacción sobre el estado actual de la cadena antes de que se firme. Informa de lo que ocurrirá: qué saldos cambiarán, qué aprobaciones de tokens se concederán, a qué contratos se llamará y si la llamada utiliza delegatecall o cambia los propietarios o el código de la billetera. Una simulación que muestre «–5.000.000 USDC salen de la billetera, +5.000.000 USDC van a 0xAb…9F, ningún otro cambio» ofrece al aprobador algo concreto que verificar.
La firma clara significa que el dispositivo de firma muestra un significado legible para las personas (destinatario, importe, nombre de la función y parámetros) en lugar de un hash o datos hexadecimales sin procesar. Lo contrario es la firma ciega: aprobar datos que el firmante no puede leer. Estándares como EIP-712 (datos estructurados tipados) ayudan a las billeteras a mostrar el significado de un mensaje. Cuando un dispositivo no puede decodificar una transacción, la opción segura por defecto es rechazarla, no firmarla de todos modos.
La firma clara solo funciona si se puede confiar en la pantalla. Si el equipo que prepara la transacción está comprometido, puede mostrar una cosa y enviar otra. Una buena práctica es verificarla mediante un canal independiente. Por ejemplo, calcular el hash esperado de la transacción en otra máquina limpia y comparar el resultado con el hash que aparece en el dispositivo físico antes de aprobar.
Ejemplo práctico: un retiro de USD 5 millones
Un cliente corporativo solicita retirar USD 5 millones en USDC a una dirección propia.
- Solicitud. Un analista de operaciones de tesorería ingresa la solicitud. La plataforma registra quién la inició y cuándo.
- Verificación de la política. La dirección lleva 60 días en la lista de permitidas. El importe supera el umbral de USD 1 millón, por lo que se aplica la ruta fría. El límite de velocidad diario aún tiene margen. El tipo de transacción es una transferencia sencilla de tokens.
- Aprobaciones. El quórum es de 3-de-5: un aprobador de operaciones, uno de riesgos y un directivo sénior. El iniciador no puede ser uno de ellos.
- Simulación y firma clara. La simulación muestra exactamente 5.000.000 USDC que salen hacia la dirección permitida, sin otras llamadas. Los firmantes confirman los mismos detalles en sus dispositivos y verifican el hash en una máquina independiente.
- Bloqueo temporal y difusión. Un retraso de cuatro horas permite cancelar la transacción. Luego, la transacción se firma y se difunde, y la conciliación posterior a la operación confirma el cambio de saldo en la cadena frente al libro contable interno.
Cada paso detiene un fallo distinto. La lista de permitidas detiene una dirección mal escrita o sustituida. El quórum impide que un único empleado deshonesto actúe. La simulación y la verificación independiente del hash detectan una interfaz comprometida. El bloqueo temporal ofrece al monitoreo una última oportunidad.
Enfoque del examen: las características de las billeteras calientes, templadas y frías, y por qué la billetera caliente solo debería contener lo que necesitan las operaciones; qué verifica un motor de políticas y por qué debe aplicarse donde se realiza la firma; el diseño del quórum y la segregación de funciones (iniciador, aprobador, firmante, administrador de políticas), y el riesgo de colapso del quórum; un proceso seguro para añadir direcciones a la lista de permitidas con una verificación por un canal independiente y un período de espera; los límites de velocidad y los bloqueos temporales (colas fuera de la cadena o bloqueos en la cadena); la simulación de transacciones, la firma clara frente a la firma ciega y la verificación independiente de lo que se firma.