Un sistema de pago puede tener reglas sólidas y aún así fallar cuando demasiada autoridad se concentra en manos equivocadas. En marzo de 2022, la red Ronin sufrió una brecha de seguridad importante que expuso el peligro de una autoridad de firma mal gestionada. Los atacantes comprometieron cinco de las nueve claves privadas de validadores de la red y las utilizaron para autorizar retiros fraudulentos desde el puente Ronin. Los activos robados ascendieron a 173.600 ETH y 25,5 millones de USDC. Lo interesante es que los atacantes no necesitaron romper el contrato inteligente del puente. Obtuvieron suficientes firmas válidas para cumplir con los requisitos de autorización existentes. Cuatro validadores comprometidos pertenecían a Sky Mavis. El quinto estaba asociado con Axie DAO, que previamente había permitido a Sky Mavis firmar en su nombre durante un período de alta demanda de transacciones. Ese permiso no se revocó después de que finalizó el acuerdo. El incidente demostró que distribuir la autoridad no es suficiente. Los permisos detrás de esa autoridad también deben gestionarse cuidadosamente. Fermah Pay aborda la seguridad del operador mediante múltiples capas. Su implementación en Stellar incluye gestión configurables de claves para operadores de terceros. El diseño documentado proporciona roles separados, un acuerdo administrativo 2-de-3, una reserva en frío y soporte para AWS KMS, módulos de seguridad hardware y otros almacenes de claves mediante una interfaz de firmante remoto. Cada componente aborda una parte diferente del problema de seguridad operativa. Los roles separados ayudan a dividir responsabilidades en lugar de otorgar a cada operador acceso ilimitado. La reserva en frío proporciona una capa separada para fondos que no deben exponerse a operaciones rutinarias. Los sistemas externos de gestión de claves ofrecen a los operadores opciones para proteger las credenciales de firma fuera de la propia aplicación. El acuerdo administrativo 2-de-3 es otra salvaguardia importante. Significa que una acción administrativa que requiera ese umbral no puede aprobarse con solo una de las tres claves designadas. Se requieren dos aprobaciones. Este no es el mismo mecanismo que utilizó Ronin. Ronin requería cinco firmas de nueve validadores para autorizar retiros del puente. El acuerdo 2-de-3 de Fermah Pay se refiere al control administrativo sobre su sistema, no a la validación de pagos individuales. Sin embargo, ambos diseños destacan por qué la autoridad no debe depender de una sola credencial o del control ilimitado de una sola persona. Hay otra lección en el incidente de Ronin: los permisos deben tener una fecha de finalización. El acuerdo de firma de Axie DAO se introdujo originalmente para ayudar a manejar el aumento de actividad de transacciones. Pero cuando ya no se necesitaba, la autorización permaneció activa. Ese permiso olvidado más tarde se convirtió en parte de la ruta de ataque. Para la infraestructura que maneja fondos de clientes, la gestión de acceso no puede detenerse en otorgar permisos. Los operadores también deben revisar el acceso existente, eliminar autoridades innecesarias y mantener claramente separadas las responsabilidades administrativas. El enfoque documentado de Fermah Pay hace que la gestión de claves y la aprobación administrativa sean partes explícitas de su infraestructura. Esto es relevante porque los sistemas de facturación sirven cada vez más a APIs, agentes de IA y otros servicios automatizados. Cuando los pagos ocurren en segundo plano, los usuarios dependen de más que del contrato de pago. También dependen de las personas, el software y las credenciales que operan el sistema. El incidente de Ronin nos recuerda que una firma válida no significa automáticamente que se haya tomado una decisión legítima. La seguridad debe proteger no solo cómo se mueve el dinero, sino también quién tiene la autoridad para hacerlo moverse. @fermah_xyz @7wealthh