Procedimientos operativos estándar de seguridad (SOP)

Validador «Konomic» | Versión 1.1 | Última actualización: 16 de junio de 2025

1. Propósito y alcance

Este documento describe la organización de la seguridad, el funcionamiento y la supervisión del validador Konomic que opera en la red Solana Mainnet-Beta.

La política se aplica a:

  • El nodo validador principal (vote account) y los nodos de respaldo
  • Los servicios auxiliares (relay RPC, supervisión, almacenamiento off-chain)
  • Los empleados y procesos automatizados con acceso a las claves y la configuración

2. Gestión de claves

El acceso al HSM está restringido únicamente a dos operadores sénior. No se almacenan claves en instancias en línea; la autorización se realiza mediante transacciones firmadas sin conexión.

Tipo de claveMétodo de almacenamientoCopia de seguridadRotación
Vote e IdentityHSM FIPS-140-3 en segmento sin conexiónPortátil air-gapped (LUKS, TPM)Programada: cada 18 meses
De emergencia: ante sospecha de compromiso
Authorized VoterHSM FIPS-140-3 en segmento sin conexiónPortátil air-gapped (LUKS, TPM)Con cada actualización del protocolo
Authorized WithdrawerHSM FIPS-140-3 en segmento sin conexiónTarjeta microSD cifrada guardada en una caja fuerte e imagen cifrada en Cloud Secure StoreProgramada: cada 18 meses
De emergencia: ante sospecha de compromiso

3. Infraestructura y red

  • Centro de datos: Instalación Tier III en Fráncfort; respaldo: Iron Mountain AMS-1.
  • Segmentación: Validador alojado en un clúster dedicado de 3 servidores en un rack de 46U; los RPC públicos están aislados en una subred independiente sin reglas de salida hacia el validador.
  • Protección del perímetro: Firewall stateful multicapa, filtrado GeoIP y limitación de velocidad.
  • Mitigación de DDoS: Conmutación automática de la dirección Anycast externa al detectar tráfico anómalo.
  • Hardware: Cada servidor con 64 vCPU AMD EPYC 9555, 1024 GB de RAM DDR5 6000, 8 SSD NVMe Enterprise de 1,92 TB en RAID-1 + mirrors ZFS (16 en total); todas las unidades con cifrado por hardware.
  • Redundancia: La redundancia 2N garantiza la resiliencia ante fallos simultáneos y el mantenimiento programado.

4. Ciclo de vida del software

EtapaProceso
PruebasCada versión del cliente se prueba en un clúster privado de DevNet durante un mínimo de 6 horas.
ActualizaciónA la versión N.N.x: en un plazo de 24 horas desde la publicación de la Foundation. CVE críticas: en un plazo de 4 horas.
ReversiónSe admite la instantánea de slot en caliente; tiempo de inactividad ≤ 5 minutos.
ModificacionesNo se aplican parches al kernel ni compilaciones no estándar.

5. Supervisión y alertas

  • Métricas: skip-rate, vote-credit, ping-latency, CPU/IO-wait, tamaño del ledger.
  • Sistema: Prometheus → Alertmanager → Telegram/SMS; respaldo: pasarela de correo electrónico.
  • Umbrales:
    • skip-rate > 5 % durante 5 minutos: alerta crítica;
    • 32 slots perdidos consecutivos: reinicio de emergencia del nodo;
    • CPU > 85 % o IO-wait > 30 %: failover preventivo.

6. Respuesta a incidentes

  1. Detección (T₀): Alerta automática.
  2. Clasificación (T₀ + 5 min): El operador asigna la prioridad (P1/P2).
  3. Contención: Activación del validador de respaldo; el nodo principal pasa a solo lectura.
  4. Resolución: Parche/reinicio/cambio de configuración.
  5. Recuperación: Sincronización de slots, validación de la consistencia del ledger.
  6. Post-mortem (≤ 48 horas): Análisis de la causa raíz, publicación del informe interno.

RTO ≤ 30 minutos, RPO ≈ 0 slots.

7. Cumplimiento y auditoría

  • Auditoría interna: Trimestral, basada en la lista de verificación CIS Benchmark + NIST 800-53 (42 elementos seleccionados).
  • Pruebas de penetración: Anuales, realizadas por un grupo independiente; el informe está disponible para los delegadores tras la firma de un NDA.
  • Certificaciones: Centro de datos certificado según ISO 27001/9001/14001/50001, PCI-DSS, SOC 2/3, según lo confirmado por contrato.