Seguridad
IronFlock está diseñado para entornos IoT industriales y empresariales donde la seguridad no es opcional. El sistema sigue una arquitectura de confianza cero con defensa en profundidad en cada capa — desde la conectividad de dispositivos hasta el aislamiento de datos.
Sin puertos abiertos en los dispositivos
Los dispositivos de borde que ejecutan IronFlock no exponen ningún puerto abierto. El agente del dispositivo inicia todas las conexiones de forma saliente hacia el router de mensajes WAMP. Esto significa:
- No se necesitan reglas de firewall de entrada en la red del dispositivo.
- Los dispositivos no son descubribles ni directamente direccionables desde internet.
- El acceso remoto funciona a través de túneles inversos — el dispositivo se conecta hacia afuera, no al revés.
Esto elimina toda una clase de vectores de ataque comunes en despliegues IoT donde los dispositivos escuchan en puertos abiertos (SSH, HTTP, MQTT).
Autenticación
IronFlock utiliza OpenID Connect (OIDC) para la autenticación de usuarios.
Autenticación multifactor
Todas las cuentas soportan autenticación de dos factores basada en TOTP (contraseña de un solo uso basada en tiempo). Los usuarios pueden habilitar 2FA en la configuración de su cuenta usando cualquier app de autenticación estándar (Google Authenticator, Authy, 1Password, etc.).
Claves API
Para el acceso programático, los usuarios generan claves API que se autentican contra la API REST. Las claves API se validan en cada solicitud a través del backend antes de que se ejecute cualquier operación.
Autenticación de dispositivos
Los dispositivos se autentican usando WAMP-CRA (autenticación de desafío-respuesta) con credenciales por dispositivo. Cada dispositivo recibe un secreto único durante el proceso de flasheo que se almacena en el dispositivo y se usa para todas las conexiones posteriores.
Transporte cifrado
Toda la comunicación en IronFlock está cifrada:
| Conexión | Protocolo | Cifrado |
|---|---|---|
| Navegador a IronFlock | HTTPS | TLS 1.2+ |
| Dispositivo a router | WSS (WebSocket Secure) | TLS 1.2+ |
| Servicio a servicio | WSS | TLS (interno) |
| Conexiones a base de datos | PostgreSQL SSL | TLS |
| Túneles de acceso remoto | Proxy inverso sobre TLS | TLS |
No existe ninguna ruta de comunicación en texto plano en todo el sistema.
Aislamiento de mensajería
IronFlock utiliza WAMP (Web Application Messaging Protocol) para toda la comunicación en tiempo real. El router de mensajes aplica un aislamiento estricto entre proyectos:
Realms separados
Cada combinación de proyecto-app obtiene su propio realm de mensajería en el router WAMP. Un realm es un espacio de nombres completamente aislado — los mensajes publicados en un realm son invisibles para todos los demás realms.
Esto significa:
- Los dispositivos del Proyecto A no pueden ver mensajes del Proyecto B.
- La App X instalada en el Proyecto A tiene un realm diferente al de la App X instalada en el Proyecto B.
- Incluso si la misma app está instalada en dos proyectos, los flujos de datos son completamente separados.
Autenticación de realms
Cada conexión a un realm requiere autenticación. Los dispositivos, servicios backend y clientes de UI deben presentar credenciales válidas para unirse a un realm. Los clientes no autorizados no pueden suscribirse a temas ni llamar a procedimientos.
Aislamiento de base de datos
Cada proyecto obtiene sus propios recursos dedicados de base de datos en FleetDB (PostgreSQL):
- Tablas separadas — Cada combinación de proyecto-app tiene su propio conjunto de tablas de series temporales. No existe una tabla compartida donde los datos de diferentes proyectos puedan filtrarse.
- Credenciales separadas — Cada backend de datos tiene credenciales de conexión únicas. Las apps solo pueden acceder a los datos de su propio proyecto.
- Sin consultas entre proyectos — La capa de base de datos garantiza que las consultas no puedan abarcar límites de proyecto.
Este aislamiento se aplica a nivel de infraestructura, no solo a nivel de aplicación. Incluso una app comprometida no puede acceder a datos de otro proyecto.
Sistema de privilegios
IronFlock aplica un modelo de privilegios por recurso donde cada proyecto, dispositivo, grupo, app, dashboard y backend de datos tiene su propio control de acceso:
- El propietario de un recurso tiene control total y puede otorgar permisos a otros usuarios.
- El propietario del proyecto tiene automáticamente control total sobre todos los recursos dentro de ese proyecto.
- Cada permiso es un indicador booleano discreto — no existen roles “admin” amplios que otorguen acceso ilimitado.
- Todos los cambios de privilegios se registran en un registro de auditoría inmutable.
Consulta Privilegios para la lista completa de permisos por tipo de recurso.
Seguridad de la cadena de suministro de software
La seguridad no se limita a cómo se ejecuta el software — comienza con cómo se construye y se entrega el software. El Supervisor de IronFlock, el único componente de IronFlock que se ejecuta directamente en tus dispositivos, se construye a través de una cadena de suministro reforzada y totalmente automatizada, de modo que puedes confiar exactamente en lo que llega a tu flota.
- Superficie de ataque mínima — El Supervisor se distribuye como un único binario de Go enlazado estáticamente, sin dependencias externas en tiempo de ejecución y sin intérprete embebido. No hay gestor de paquetes, ni árbol de bibliotecas dinámicas, ni nada escuchando conexiones entrantes — lo que reduce drásticamente aquello a lo que un atacante podría apuntar.
- Análisis continuo de vulnerabilidades — Cada versión se analiza en busca de vulnerabilidades conocidas (CVE) tanto en nuestro propio código como en todas las dependencias, utilizando un análisis consciente de la alcanzabilidad que se centra en las rutas de código que el binario puede ejecutar realmente. Los análisis también se ejecutan de forma semanal, de modo que las vulnerabilidades divulgadas después de publicar una versión siguen apareciendo frente a las compilaciones ya desplegadas.
- Lista de materiales de software (SBOM) — Cada versión publica un SBOM CycloneDX completo — un inventario completo de cada componente y versión que se incorporó al binario. Esto te da, a ti y a tus auditores, una transparencia exacta sobre lo que estás ejecutando.
- Compilaciones firmadas y verificables — Cada binario de versión incluye una atestación de procedencia firmada con sigstore vinculada criptográficamente a su contenido exacto. La firma es a prueba de manipulaciones y verificable de forma independiente, de modo que puedes confirmar que un binario fue producido por la canalización de IronFlock y que no ha sido alterado durante el tránsito.
- Versiones automatizadas y controladas — La compilación, la firma y la publicación ocurren en una canalización de CI controlada — nunca en la máquina de un desarrollador individual. No se publica nada a menos que se supere la suite completa y automatizada de pruebas y seguridad, garantizando que el artefacto que se distribuye es exactamente el que se probó y se atestó.
- Actualizaciones seguras por aire (OTA) — Las actualizaciones OTA se entregan a través de canales cifrados y provienen únicamente de compilaciones firmadas y publicadas por IronFlock — de modo que los dispositivos se actualizan a sí mismos sin abrir nunca un puerto entrante ni confiar en un artefacto no verificado.
En conjunto, estos controles te proporcionan una cadena de custodia verificable desde el código fuente hasta el binario que se ejecuta en cada dispositivo.
Cumplimiento
La arquitectura de seguridad de IronFlock soporta el cumplimiento con:
- IEC 62443 — Seguridad de sistemas de automatización y control industrial
- ISO 27001 — Gestión de seguridad de la información
- SOC 2 — Controles de organización de servicios para seguridad de datos
- GDPR — Datos almacenados en centros de datos de la UE (configurable), registro de auditoría para acceso a datos
- EU Cyber Resilience Act (CRA) — Los SBOM por versión y un proceso documentado y continuo de gestión de vulnerabilidades abordan directamente las obligaciones fundamentales del CRA para productos con elementos digitales.
- SLSA / NIST SSDF — La procedencia de compilación firmada y una canalización de CI controlada se alinean con los marcos reconocidos de integridad de la cadena de suministro y de desarrollo seguro de software.
La combinación de transporte cifrado, autenticación, aislamiento de datos por proyecto, privilegios granulares, registro de auditoría integral y una cadena de suministro de software reforzada proporciona los controles requeridos por estos marcos normativos.