Qué detiene realmente una transacción
Todo producto de custodia tiene una página de funciones con una lista de controles: listas blancas, límites de gasto, bloqueos temporales, flujos de aprobación, restricciones por IP. Todos son reales y todos son útiles. Pero no son todos el mismo tipo de cosa, y tratarlos como intercambiables es la forma en que las organizaciones acaban con un modelo de seguridad más débil de lo que insinuaba el marketing.
Hay una pregunta que los separa con nitidez: si todo el software del sistema estuviera equivocado o fuera hostil, ¿seguiría sosteniéndose este control?
Para la mayoría de la lista, la respuesta es no. Para exactamente uno, la respuesta es sí. Este artículo va de distinguirlos.
Tres capas, no una
Entre que alguien quiere mover fondos y que los fondos se mueven de verdad, SSP Enterprise tiene tres barreras distintas. Fallan de forma diferente, y saber cuál es cuál es todo el asunto.
Las capas no están ordenadas por utilidad. Están ordenadas por lo que hace falta para derrotarlas.
Capa 1: la capa de coordinación
Es el motor de políticas, y ahí vive la mayoría de las funciones. SSP Enterprise admite listas blancas de direcciones, restricciones por tipo de destino, bloqueos temporales que retrasan transacciones por encima de un umbral de valor, reglas que exigen aprobación de un administrador a partir de cierto importe y restricciones de IP para el acceso a la organización. Las plantillas de políticas te dan configuraciones sensatas que después se materializan como reglas reales y editables.
Estas cosas hacen trabajo genuino. Una lista blanca impide que una dirección mal tecleada llegue siquiera a ser una propuesta. Un bloqueo temporal da a un equipo de tesorería una ventana para notar que algo va mal. Una regla de aprobación convierte una transferencia grande en una conversación entre dos personas en lugar de la tarde de una sola.
Lo que no son es imposición de custodia. Estas reglas viven en el software de SSP y las evalúan los servidores de SSP. No forman parte de la dirección de la bóveda, y la cadena de bloques jamás ha oído hablar de ellas. Si se sorteara el motor de políticas —por un fallo, un servidor comprometido o un operador hostil—, las reglas sencillamente no se aplicarían.
Lo decimos con claridad porque la alternativa es peor. Un equipo que cree que su lista blanca es una garantía de custodia dimensionará su umbral en consecuencia, y ese es exactamente el error que convierte un incidente sobrevivible en uno que no lo es.
Capa 2: tus dispositivos
La segunda barrera es el par de dispositivos que tiene cada firmante, y es más fuerte que la primera en un aspecto importante: tampoco se fía de SSP.
Cuando una propuesta llega a un firmante, sus dispositivos decodifican localmente los bytes en crudo de la transacción y comparan el resultado con lo que se está mostrando. Destinatario, importe, token: leídos de los bytes, no tomados de la descripción del servidor. En Solana esta comparación es explícita e inflexible: si los bytes decodificados contradicen el contenido mostrado, la firma se bloquea de forma dura en lugar de advertirse, porque una discrepancia ahí indica un ataque activo y no un fallo de representación.
Los dispositivos también imponen su propio techo independiente a los reembolsos de comisiones. El relay propone la comisión; la cartera se niega a firmar una por encima de un máximo fijado en el código, diga lo que diga el relay, lo que acota cualquier drenaje por vía de comisiones incluso si el relay es del todo hostil. La simulación también se ejecuta antes de la aprobación, ejecutando la propuesta contra el estado actual de la cadena para que la pantalla de revisión pueda mostrar qué haría realmente la transacción; eso llegó con la simulación de transacciones y avisos de riesgo.
Esta capa derrota a un servidor comprometido. Lo que no puede derrotar es un dispositivo comprometido, ni a un firmante que aprueba sin leer. También requiere ambos dispositivos del firmante, y por eso importa el 2-de-2 por firmante: la capa 2 es tan fuerte como el más débil de los dos dispositivos, y son deliberadamente clases de hardware distintas.
Capa 3: la cadena
La tercera barrera es la única que se sostiene cuando todo lo demás ha fallado.
La dirección de una bóveda se deriva del conjunto de firmantes y del umbral de aprobación. Una transacción que no lleve el número requerido de firmas válidas no es una transacción rechazada: es una transacción inválida. Todos los nodos de la red llegan de forma independiente a la misma conclusión, y ningún grado de acceso a la infraestructura de SSP cambia esa aritmética.
Por eso el umbral es el número que más reflexión merece al crear una bóveda, y por eso no se puede editar después. Configurar tu primera bóveda empresarial cubre la mecánica; 2-de-2 frente a 2-de-3 y m-de-n cubre cómo elegir el número.
Dónde falla cada capa
Poner los modos de fallo uno al lado del otro deja obvio el trabajo de diseño.
| Escenario | Capa de coordinación | Tus dispositivos | La cadena |
|---|---|---|---|
| Un firmante teclea mal una dirección | Lo detiene | Lo detiene si lee | Le da igual |
| Engañan a un firmante para que apruebe | Lo detiene si no está en la lista blanca | Muestra la verdad; aun así puede aprobar | Le da igual |
| El relay de SSP está comprometido | Falla | Aguanta: los bytes se decodifican localmente | Aguanta |
| El motor de políticas de SSP tiene un fallo | Falla | Aguanta | Aguanta |
| El portátil de un firmante está comprometido | No está diseñada para esto | En parte: el teléfono sigue comprobando | Aguanta |
| Un atacante controla menos de M firmantes | No está diseñada para esto | Aguanta | Aguanta |
| Un atacante controla M firmantes o más | Falla | Falla | Falla |
La última fila es el fondo honesto del modelo. El multisig protege frente a que se comprometa una minoría de tus firmantes. No protege frente a una mayoría, y ningún producto puede afirmar lo contrario sin mentir. Por eso el umbral y la independencia de tus firmantes importan más que cualquier lista de funciones.
Qué implica esto para cómo lo montas
Diseña la bóveda para que sea segura solo con la capa 3. Elige el umbral y el conjunto de firmantes como si el motor de políticas no existiera. Si la respuesta te incomoda, el arreglo es otro umbral u otros firmantes, no más políticas.
Después añade políticas por aquello en lo que las políticas son buenas. Las listas blancas atrapan errores humanos. Los bloqueos temporales compran tiempo de reacción. Las reglas de aprobación crean un segundo par de ojos sobre importes grandes. Son mejoras de proceso y reducen incidentes de verdad; simplemente no son lo que se interpone entre un atacante y tu tesorería.
Mantén a tus firmantes genuinamente independientes. Dos firmantes en el mismo portátil, en el mismo edificio, con el mismo esquema de recuperación, están más cerca de ser un firmante que dos. La fuerza de la capa 3 viene de la dificultad de comprometer a M personas distintas con M pares de dispositivos distintos.
Haz que los firmantes lean de verdad la pantalla de revisión. La capa 2 es la única barrera capaz de atrapar una propuesta con aspecto legítimo pero equivocada, y solo funciona si un humano se implica con lo que decodificó su dispositivo. Un viaje de ida y vuelta ensayado al crear la bóveda ayuda a construir ese hábito sin nada en juego.
Haz a otros proveedores de custodia la misma pregunta. Uses SSP o no, este marco es portátil: para cada control de la página de funciones, pregunta si sobrevive a que el propio software del proveedor esté equivocado. Las respuestas suelen ser instructivas, y un proveedor que responde con claridad te está diciendo algo bueno sobre cómo piensa.
Sobre las maneras en que un montaje multiclave se socava en la práctica, modos de fallo del multisig y cómo los mitiga SSP los recorre uno a uno, y SSP Enterprise: bóvedas multisig para equipos es la visión general de cómo encajan las piezas.
