Arquitectura de Netsocs¶

Netsocs emplea una arquitectura distribuida basada en microservicios, complementada con múltiples bases de datos especializadas según el caso de uso. Esta arquitectura modular permite que cada componente funcione dentro de un único servidor o se distribuya a través de múltiples servidores, lo que facilita escalar la solución hasta gestionar miles de objetos por instalación.

Todos los componentes están diseñados para ejecutarse sobre contenedores Docker, convirtiendo a Netsocs en una solución verdaderamente multiplataforma. Esto significa que puede desplegarse en entornos on-premise (en las instalaciones del cliente), como servicio SaaS (Software as a Service), en configuraciones híbridas que combinan ambos modelos, o sobre orquestadores de contenedores como Kubernetes.

INFO Esta sección está dirigida a administradores de sistemas, personal de DevOps y desarrolladores interesados en comprender el funcionamiento interno de la plataforma.

Arquitectura de Netsocs

Ventajas de correr Netsocs sobre Kubernetes¶

Al ejecutar Netsocs sobre Kubernetes, la solución obtiene beneficios adicionales significativos:

Escalabilidad automática: Kubernetes ajusta dinámicamente los recursos según la demanda, aumentando o reduciendo instancias de microservicios sin intervención manual.
Alta disponibilidad: Si un componente falla, Kubernetes lo reinicia automáticamente y redistribuye la carga, garantizando continuidad del servicio.
Gestión simplificada de actualizaciones: Permite implementar nuevas versiones sin tiempo de inactividad mediante despliegues progresivos (rolling updates).
Optimización de recursos: Distribuye eficientemente los contenedores entre los servidores disponibles, maximizando el uso del hardware.
Portabilidad total: La misma configuración funciona en cualquier proveedor de nube (AWS, Azure, Google Cloud) o infraestructura local que soporte Kubernetes.
Recuperación ante desastres: Facilita la configuración de réplicas geográficamente distribuidas y respaldos automatizados.

Componentes de la Arquitectura¶

Capa de Clientes¶

End-clients¶

Esta capa representa el punto de interacción entre los usuarios finales y Netsocs, ya sea a través del navegador web o la aplicación móvil. Los usuarios se conectan al servidor que aloja Traefik, el componente que actúa como puerta de entrada y enrutador del tráfico hacia los diferentes microservicios del sistema.

Por defecto, Netsocs utiliza Caddy para la generación automática de certificados SSL/TLS, simplificando la configuración de conexiones seguras mediante HTTPS. Caddy fue elegido por su capacidad de obtener y renovar certificados de forma completamente automática con Let's Encrypt, eliminando la complejidad de la gestión manual. En entornos de red interna con certificados privados, los dispositivos cliente necesitarán tener instalados estos certificados para establecer conexiones seguras.

Remote Site¶

Netsocs tiene la capacidad de integrarse con dispositivos independientemente de su ubicación geográfica o configuración de red mediante un concepto llamado site. Un site es un componente distribuido que actúa como puente entre la instalación principal de Netsocs y los dispositivos de campo.

Cada site aloja drivers especializados que establecen comunicación bidireccional con la instalación central: envían información de los dispositivos hacia Netsocs y reciben instrucciones que luego ejecutan localmente. Los drivers interpretan estas instrucciones y se comunican directamente con los dispositivos utilizando sus protocolos nativos (Modbus, BACnet, SNMP, entre otros).

Una característica fundamental del site es su capacidad de almacenamiento local de eventos y cambios de estado. Esto garantiza que, en caso de pérdida temporal de conectividad con la instalación principal, ningún dato se pierda. Una vez restablecida la conexión, toda la información almacenada se sincroniza automáticamente, manteniendo la integridad del sistema.

Capa de Drivers¶

Los drivers son componentes esenciales que actúan como traductores entre Netsocs y los dispositivos de campo. Cada driver es una pieza de software especializada que utiliza los protocolos de integración nativos del dispositivo (como Modbus, BACnet, SNMP, OPC-UA, entre otros) para establecer comunicación bidireccional.

Funcionamiento¶

El ciclo de operación de un driver incluye:

Recepción de instrucciones: El driver recibe comandos desde Netsocs (por ejemplo, cambiar un setpoint, activar un actuador, solicitar lecturas).
Traducción y ejecución: Convierte estas instrucciones al protocolo específico del dispositivo y las ejecuta.
Recolección de datos: Captura eventos, cambios de estado, alarmas y valores de las variables del dispositivo.
Envío al site: Transmite toda la información recolectada al site local, que posteriormente la sincroniza con la instalación principal de Netsocs.

Certificación y Documentación¶

Cada driver está respaldado por un manual de certificación que documenta:

Pruebas de integración realizadas y resultados obtenidos.
Objetos y puntos de datos que el driver crea en Netsocs.
Diagramas de comunicación y flujos de datos con el dispositivo.
Requisitos técnicos, limitaciones y configuraciones recomendadas.
Detalles operativos relevantes para los usuarios finales.

Esta documentación garantiza transparencia y facilita la implementación correcta de cada integración.

Criticidad y Recomendaciones¶

Los drivers son componentes extremadamente críticos en la arquitectura de Netsocs: si un driver no está disponible, se interrumpe por completo la comunicación entre el sistema y los dispositivos asociados. Por esta razón, se recomienda enfáticamente:

Implementar redundancia: Desplegar drivers duplicados en diferentes sites o servidores cuando sea posible.
Configurar monitoreo activo: Establecer alertas automáticas ante caídas o desconexiones de drivers.
Crear automatizaciones: Diseñar respuestas automáticas ante eventos de desconexión (notificaciones, intentos de reconexión, activación de drivers de respaldo).
Realizar mantenimiento preventivo: Revisar periódicamente logs y métricas de rendimiento de los drivers.

Capa de Servicios¶

Netsocs UI (Frontend)¶

Representa la interfaz operativa completa que se ejecuta en el navegador web de los usuarios que interactúan con Netsocs. Esta capa constituye toda la experiencia visual e interactiva mediante la cual los operadores, administradores y usuarios finales gestionan el sistema, visualizan datos en tiempo real, configuran dispositivos, analizan tendencias y ejecutan acciones de control.

Características de la Interfaz:

Diseño responsive: La interfaz se adapta automáticamente a cualquier tamaño de pantalla, garantizando una experiencia óptima tanto en computadoras de escritorio como en tablets y smartphones.
Acceso multiplataforma: Al ejecutarse en el navegador, los usuarios pueden acceder desde cualquier sistema operativo (Windows, macOS, Linux, iOS, Android) sin necesidad de instalar aplicaciones específicas, salvo la aplicación móvil nativa opcional.
Experiencia táctil optimizada: En dispositivos móviles y tablets, los controles están diseñados para interacción táctil, con botones y elementos de tamaño adecuado para facilitar la operación con los dedos.

Componentes Principales:

La interfaz incluye módulos como dashboards personalizables con gráficas en tiempo real, paneles de control de dispositivos, gestión de alarmas y eventos, configuración del sistema, reportes y analíticas, además de herramientas de administración de usuarios y permisos.

Driverhub (Core)¶

El DriverHub es el servicio central y neurálgico de Netsocs, responsable de orquestar toda la operatividad de los drivers y, por extensión, de las integraciones con dispositivos de campo. Este componente crítico actúa como el cerebro del sistema, coordinando la comunicación bidireccional entre la plataforma y los sites distribuidos, procesando millones de puntos de datos y garantizando la coherencia operativa de toda la infraestructura.

Gestión de Acciones y Comandos:

El DriverHub administra el ciclo completo de las acciones enviadas hacia los drivers:

Encolamiento inteligente: Recibe comandos desde la interfaz de usuario, automatizaciones, reglas de negocio o APIs externas, y los encola de forma priorizada según criticidad y dependencias.
Validación y seguridad: Verifica permisos de usuario, coherencia de parámetros y restricciones operativas antes de ejecutar cualquier comando.
Enrutamiento: Determina qué driver específico debe recibir cada instrucción y a través de qué site debe transmitirse.
Seguimiento de ejecución: Mantiene trazabilidad completa del estado de cada comando (pendiente, en ejecución, completado, fallido) y tiempos de respuesta.
Manejo de reintentos: Implementa políticas de reintento automático con backoff exponencial ante fallos temporales de comunicación.
Respuestas y confirmaciones: Procesa las respuestas de los drivers y actualiza el estado del sistema en tiempo real.

Administración de Sites:

Registro y descubrimiento: Mantiene un inventario actualizado de todos los sites activos, sus capacidades, versiones de software y drivers disponibles.
Monitoreo de salud: Supervisa continuamente el estado de conectividad, latencia, uso de recursos y disponibilidad de cada site.
Sincronización de configuración: Distribuye cambios de configuración, actualizaciones de credenciales y políticas operativas a los sites correspondientes.
Gestión de conectividad intermitente: Maneja inteligentemente escenarios de pérdida y recuperación de conexión, garantizando que no se pierdan datos ni comandos.
Balanceo de carga: Distribuye la carga operativa entre múltiples sites cuando existen configuraciones redundantes.

Sistema de Auditoría Integral:

Registro de acciones de usuario: Captura quién realizó qué acción, desde qué dispositivo, en qué momento y con qué resultado.
Trazabilidad de comandos: Documenta el flujo completo de cada comando desde su origen hasta su ejecución en el dispositivo final.
Cambios de configuración: Registra todas las modificaciones realizadas en la configuración de dispositivos, sites, drivers y del sistema en general.
Intentos de acceso: Monitorea tanto accesos exitosos como fallidos para detectar posibles amenazas de seguridad.
Cumplimiento normativo: Genera registros que facilitan el cumplimiento de regulaciones como GDPR, SOC 2, o normativas industriales específicas.
Retención configurable: Permite definir políticas de retención de logs según criticidad y requisitos legales.

Gestión de Eventos en Tiempo Real:

Ingesta masiva: Capaz de procesar miles de eventos por segundo desde múltiples sites simultáneamente.
Normalización: Estandariza eventos de diferentes fabricantes y protocolos a un formato común.
Filtrado y enriquecimiento: Aplica reglas de filtrado, descarta duplicados y enriquece eventos con contexto adicional (ubicación, criticidad, dispositivo relacionado).
Correlación de eventos: Identifica patrones y relaciones entre eventos aparentemente independientes para detectar situaciones complejas.
Distribución selectiva: Enruta eventos a los suscriptores apropiados (interfaz de usuario, motor de alarmas, sistemas externos, reglas de automatización).
Almacenamiento histórico: Persiste eventos en bases de datos optimizadas para consultas temporales y análisis retrospectivo.

Procesamiento de Cambios de Estado:

Detección de cambios: Identifica modificaciones en valores de variables, estados operativos de dispositivos y condiciones del sistema.
Propagación de estado: Actualiza instantáneamente las vistas de todos los usuarios conectados cuando ocurren cambios.
Gestión de conflictos: Resuelve situaciones donde múltiples comandos intentan modificar el mismo objeto simultáneamente.
Caché de estado: Mantiene una representación en memoria de los estados más recientes para respuesta instantánea.
Persistencia: Garantiza que los cambios de estado se almacenen de forma duradera en las bases de datos correspondientes.
Sincronización post-desconexión: Reconcilia estados cuando un site recupera conectividad después de operar en modo offline.

Reportes y Business Intelligence:

Agregación de datos: Consolida información de múltiples fuentes para crear vistas unificadas.
Reportes programados: Genera automáticamente reportes en intervalos definidos (diario, semanal, mensual).
Reportes bajo demanda: Permite a usuarios autorizados generar reportes ad-hoc con parámetros personalizados.
Múltiples formatos: Exporta reportes en PDF, Excel, CSV, JSON y otros formatos estándar.
KPIs y métricas: Calcula indicadores clave de desempeño como uptime, eficiencia energética y tiempos de respuesta.

Operaciones Predictivas y Machine Learning:

Detección de anomalías: Identifica patrones inusuales en el comportamiento de dispositivos que podrían indicar fallos inminentes.
Mantenimiento predictivo: Analiza tendencias históricas para predecir cuándo un equipo requerirá mantenimiento antes de que falle.
Optimización de energía: Aprende patrones de consumo y sugiere estrategias de optimización.
Predicción de carga: Anticipa demandas futuras basándose en patrones históricos y variables contextuales (clima, ocupación, calendario).

Servicio de Automatización¶

El Servicio de Automatización de Netsocs es una plataforma de orquestación de flujos de trabajo que permite crear, gestionar y ejecutar automatizaciones complejas mediante un modelo de ejecución basado en grafos. El servicio proporciona una API REST para la gestión completa de automatizaciones y sus ejecuciones, con soporte para disparadores (triggers), lógica condicional y diversos tipos de nodos de acción.

Autenticación y Autorización¶

La autenticación y autorización en Netsocs está gestionada por Keycloak, el sistema centralizado de Gestión de Identidad y Acceso (IAM) de la plataforma. Actúa como el guardián de la seguridad, controlando quién puede acceder al sistema, qué permisos tiene cada usuario y cómo se validan las identidades de forma segura.

Matriz de Protocolos y Funcionalidades:

Categoría	Característica	Descripción
Protocolos Core	SAML 2.0	Soporte completo para intercambio de datos de autenticación y autorización entre dominios de seguridad.
	OpenID Connect (OIDC)	Capa de identidad sobre el protocolo OAuth 2.0 para autenticación moderna.
	OAuth 2.0	Estándar de la industria para la delegación de autorización de APIs.
Federación	Identity Brokering	Capacidad de delegar la autenticación a proveedores externos (Google, GitHub, Facebook, etc.).
	User Federation	Sincronización con bases de usuarios existentes como LDAP o Active Directory.
Seguridad	Single Sign-On (SSO)	Un solo inicio de sesión para acceder a múltiples aplicaciones conectadas.
	Single Sign-Out	Cierre de sesión centralizado en todas las aplicaciones vinculadas.
	Multi-Factor (MFA)	Soporte nativo para OTP (Google Authenticator, FreeOTP) y WebAuthn.
Gestión	User Self-Service	Panel para que el usuario gestione su propia cuenta, contraseñas y sesiones.
	Role-Based Access (RBAC)	Asignación de permisos basados en roles jerárquicos y grupos.

Flujo de Datos¶

Dispositivo → Cliente de Netsocs (Entrante)¶

Este flujo describe cómo los datos generados por un dispositivo físico llegan a la pantalla del usuario final:

El dispositivo genera datos: Un dispositivo de campo (sensor, cámara, panel de alarma, etc.) produce un evento o cambio de estado (por ejemplo, un sensor de temperatura supera un umbral).
El driver captura el evento: El driver que corre en el site se comunica con el dispositivo usando su protocolo nativo (Modbus, BACnet, SNMP, etc.) y captura el dato crudo.
El driver envía al site: El driver transmite el evento normalizado al servicio local del site a través de la conexión TCP interna (puerto 3197). Si se pierde conectividad, el site almacena el evento localmente hasta que se reestablezca la conexión.
El site reenvía al DriverHub: El site envía el evento al DriverHub central por una conexión HTTPS, pasando por Traefik para validación y enrutamiento.
El DriverHub procesa: El DriverHub normaliza, enriquece y enruta el evento. Actualiza el caché de estado en memoria, persiste el cambio en MongoDB (state_changes, events) y/o MySQL (según el dominio de datos), y publica una notificación en el canal pub/sub de Redis.
Distribución en tiempo real: Los servicios suscritos al canal de Redis (servidor de UI, motor de automatizaciones, motor de alarmas) reciben la notificación de forma inmediata.
El cliente recibe la actualización: La Netsocs UI entrega el cambio de estado a todas las sesiones de usuario conectadas en tiempo real vía WebSocket, actualizando dashboards, mapas, sinópticos y paneles de alertas sin recargar la página.

Cliente de Netsocs → Dispositivo (Saliente)¶

Este flujo describe cómo una acción del usuario llega al dispositivo físico:

El usuario emite un comando: Un operador hace clic en un control de la Netsocs UI (por ejemplo, "abrir puerta", "activar relé", "cambiar setpoint") o una regla de automatización se dispara automáticamente.
La solicitud llega a Traefik: La petición HTTPS es recibida por Traefik, que valida el token de autenticación con Keycloak y la enruta al DriverHub.
El DriverHub valida y encola: El DriverHub verifica los permisos del usuario (vía caché de Redis), valida los parámetros del comando y lo encola con la prioridad adecuada para el driver destino.
El comando se despacha al site: El DriverHub envía el comando al site correspondiente por HTTPS, referenciando el driver y dispositivo específico.
El site entrega al driver: El site recibe el comando y lo despacha al driver objetivo mediante el proceso local administrado por systemctl.
El driver traduce y ejecuta: El driver convierte el comando de Netsocs al protocolo nativo del dispositivo y lo envía directamente al hardware.
El dispositivo confirma: El dispositivo ejecuta la acción y envía una confirmación o estado actualizado de vuelta al driver.
El resultado se propaga: El driver captura la confirmación y la envía de regreso por la cadena (driver → site → DriverHub), que actualiza el estado del sistema y notifica a los usuarios conectados en tiempo real.

TIP Si el site pierde conectividad con el DriverHub durante la ejecución de un comando, el comando se retiene en la cola y se reintenta con backoff exponencial. Los cambios de estado capturados en modo offline se sincronizan automáticamente una vez que se restaura la conectividad.

Integración con Tecnología IT Estándar¶

Docker¶

Se utiliza Docker para aislar los procesos de la aplicación, sus bibliotecas y configuraciones del sistema operativo anfitrión. Esto permite:

Portabilidad: Despliegue inmediato en cualquier infraestructura (Cloud, On-premise).
Aislamiento: Evitar conflictos entre versiones de lenguajes o dependencias.
Eficiencia: Menor consumo de recursos comparado con máquinas virtuales tradicionales.

MySQL¶

Para la persistencia de datos relacionales, la arquitectura utiliza MySQL (Versión 8.0+). Este motor fue seleccionado por su madurez, su estricto cumplimiento de las propiedades ACID y su excelente rendimiento en cargas de trabajo de lectura/escritura intensas.

Rol en la Arquitectura¶

MySQL actúa como la "fuente única de verdad" (Source of Truth) para:

Gestión de usuarios y sesiones.
Almacenamiento de metadatos del sistema.
Registros transaccionales.

Configuración y Optimización¶

Parámetro	Configuración	Justificación
Engine	`InnoDB`	Soporte de transacciones y recuperación ante fallos.
Charset	`utf8mb4`	Compatibilidad total con emojis y caracteres internacionales.
Max Connections	`150`	Control de carga para evitar saturación de memoria RAM.
Pool de Conexiones	Gestionado por la App	Evita el overhead de abrir/cerrar conexiones constantemente.

Integración con Docker¶

Persistencia: Se utiliza un Volumen de Docker mapeado a /var/lib/mysql para asegurar que los datos no se pierdan si el contenedor se reinicia o actualiza.
Variables de Entorno: Parámetros como MYSQL_ROOT_PASSWORD y MYSQL_DATABASE se gestionan externamente para no exponer secretos en el código fuente.

Estrategia de Backup y Mantenimiento¶

Backups Automáticos: Ejecución de mysqldump de forma diaria, comprimiendo el resultado en archivos .sql.gz.
Integridad: Periódicamente se realizan pruebas de restauración en entornos de Staging para verificar la validez de las copias de seguridad.
Logs de Errores: Centralizados mediante el driver de logs de Docker para monitorear deadlocks o consultas lentas (Slow Queries).

WARNING MySQL está configurado para aceptar conexiones únicamente desde la red interna de Docker. El puerto 3306 no debe mapearse al host en entornos de producción a menos que sea estrictamente necesario para tareas de auditoría.

Estrategias de Despliegue¶

Escenario A: MySQL Contenedorizado (Ideal para Dev/Staging/CI-CD)

En este modelo, MySQL corre como un servicio más dentro de la orquestación de Docker.

Ventajas: Despliegue "un solo clic" mediante docker-compose, paridad total entre entornos y aislamiento completo.
Gestión de Datos: Se requiere el uso estricto de Volumes externos para evitar la pérdida de información en el ciclo de vida del contenedor.
Configuración: Se recomienda limitar los recursos de memoria (mem_limit) en el archivo compose para evitar que un leak en la base de datos afecte al resto de los microservicios.

Escenario B: MySQL Externo / Bare Metal / Managed (Recomendado para Producción)

En entornos críticos, se desacopla la base de datos del clúster de aplicaciones, apuntando a un servidor dedicado o a un servicio gestionado (como AWS RDS, Azure Database o un servidor Linux dedicado).

Rendimiento: Acceso directo al hardware y al sistema de archivos del host, eliminando el overhead de la capa de red de Docker.
Resiliencia: Facilita la implementación de réplicas de lectura, clusters de alta disponibilidad (HA) y snapshots a nivel de infraestructura.
Conectividad: La aplicación se conecta mediante el Endpoint o IP del servidor externo. Es imperativo configurar correctamente los grupos de seguridad y el firewall para permitir el tráfico desde los nodos de Docker.

Matriz de Decisión:

Característica	MySQL en Docker	MySQL Externo / Gestionado
Persistencia	Dependiente de Docker Volumes	Independiente (EBS, SAN, etc.)
Escalabilidad	Vertical (limitada por el host)	Horizontal (Réplicas de lectura)
Backups	`docker exec` + `mysqldump`	Snapshots nativos / Point-in-time recovery
Uso recomendado	Desarrollo, QA, Microdespliegues	Producción, Big Data, Alta Concurrencia

Dominios de Datos y Responsabilidades de Persistencia¶

MySQL actúa como el repositorio relacional central, gestionando estados críticos distribuidos en cinco dominios principales:

A. Gestión de Identidad y Acceso (IAM)

Basado en el esquema de Keycloak, almacena toda la infraestructura de seguridad:

Realms y Clientes: Configuración de dominios de seguridad, aplicaciones registradas y flujos de autenticación OIDC/SAML.
Usuarios y Credenciales: Almacenamiento cifrado de identidades, atributos, pertenencia a grupos y mapeo de roles (RBAC).
Federación e Identidad Externa: Configuraciones de proveedores de identidad (IdP) externos y mapeos de protocolos.

B. Control de Acceso Físico y Gestión de Personas (AC)

Entidades Core: Registro de personas, empresas, visitas y tipos de identificación.
Configuración de Acceso: Niveles de acceso, políticas de puertas, horarios y documentos requeridos.
Infraestructura del Sitio: Definición de sitios, subsistemas y puntos de localización.

C. Gestión de Dispositivos e IoT

Inventario de Hardware: Registro de dispositivos, sensores, alarmas y sus políticas de permisos asociadas.
Estado Operacional: Políticas de usuario-dispositivo y configuraciones de fabricantes/marcas.

D. Orquestación y Automatización

Motores de Automatización: Definición de flujos, nodos de ejecución, conexiones y resultados de triggers automáticos.
Jobs del Sistema: Programación de tareas de mantenimiento, limpieza de eventos y reportes programados.

E. Personalización de Interfaz y Observabilidad (Dashboarding)

Layouts Dinámicos: Configuración personalizada de dashboards, widgets, pestañas y preferencias de usuario.
Logs y Auditoría: Almacenamiento persistente de logs de eventos, logs de auditoría de seguridad y filtros de visualización.

MongoDB¶

Netsocs utiliza MongoDB como motor de persistencia de documentos para gestionar datos no estructurados y de alta velocidad. Su diseño permite el almacenamiento de grandes volúmenes de información proveniente de dispositivos IoT y logs de auditoría sin la rigidez de un esquema relacional, facilitando la escalabilidad horizontal.

Las colecciones en MongoDB están optimizadas para operaciones de escritura intensiva y consultas de series temporales:

A. Telemetría y Estados de Dispositivos

device_state_changes / state_changes: Histórico detallado de las transiciones de estado de hardware y componentes lógicos.
gps_tracks: Almacenamiento de coordenadas geoespaciales y rutas, optimizado para consultas de geofencing y tracking histórico.

B. Eventos y Auditoría de Sistema

events: Repositorio central de eventos generados por el sistema (alertas, logs de sistema, notificaciones).
user_audits: Registro de actividad de usuario para cumplimiento (compliance) y forense, manteniendo un rastro inmutable de acciones en la plataforma.

C. Ejecución de Lógica y Acciones

object_actions / object_actions_execution: Definición y seguimiento de las acciones ejecutadas sobre objetos del sistema, incluyendo resultados de ejecución y errores de procesos.

D. Analítica y Representación Visual

kpis: Almacenamiento de indicadores clave de rendimiento calculados para visualización rápida en dashboards.
synoptics: Configuración de diagramas sinópticos y representaciones gráficas dinámicas de la planta o sitio.
meet_rooms: Gestión de estados y metadatos específicos para la reserva y operación de salas de reuniones.

Consideraciones de Infraestructura para IT¶

Estrategia de Indexación: Se requiere el uso de Índices Geoespaciales (2dsphere) para la colección gps_tracks e Índices TTL (Time-To-Live) para las colecciones de events o state_changes si se desea implementar una purga automática de datos antiguos.
Gestión de Memoria: MongoDB hace un uso intensivo del WiredTiger Cache. Se recomienda que el contenedor tenga una reserva de memoria dedicada para evitar el intercambio (swapping) en disco.
Persistencia en Docker: El volumen de datos (/data/db) debe residir en almacenamiento de estado sólido (SSD) para soportar las IOPS generadas por el flujo constante de state_changes.

Seguridad y Conectividad¶

Autenticación: Implementada mediante mecanismo SCRAM-SHA-256.
Aislamiento: La instancia no debe ser accesible desde redes públicas. El acceso se limita a la subred del backend y a herramientas de administración (como MongoDB Compass) vía túnel SSH o VPN.

Redis¶

Redis es un sistema de almacenamiento de datos en memoria de alta velocidad que cumple dos roles fundamentales en la arquitectura:

1. Sistema de Mensajería entre Servicios¶

Redis actúa como un canal de comunicación (pub/sub) que permite que diferentes componentes del sistema se comuniquen entre sí de manera eficiente y en tiempo real, sin necesidad de conocerse directamente.

Canales de comunicación activos:

Configuración de dispositivos: Canal para enviar y recibir configuraciones de hardware.
Servicios de video: Canal para solicitudes y respuestas relacionadas con grabaciones.
Gestión de eventos: Canal para la creación y notificación de eventos del sistema.
Cambios de estado: Canal para notificar modificaciones en el estado de objetos.

2. Sistema de Caché de Alto Rendimiento¶

Redis funciona como una memoria temporal de acceso rápido que almacena información consultada frecuentemente, evitando tener que buscarla repetidamente en la base de datos principal.

Actualmente se utiliza como caché para optimizar el módulo de permisos de objetos:

Permisos asignados a cada usuario.
Identificadores de recursos según tipo y usuario.
Verificaciones de permisos específicos sobre entidades.

TIP La información se mantiene en caché durante 1 minuto. Después de ese tiempo, se considera obsoleta y se consulta nuevamente desde la fuente principal para garantizar que siempre se trabaje con datos actualizados.

Traefik¶

Traefik es el punto de entrada unificado de la plataforma, actuando como un Gateway de Aplicaciones (API Gateway) que gestiona todo el tráfico que ingresa al sistema. Es el único punto de contacto visible para el mundo exterior; todas las comunicaciones con la plataforma pasan a través de Traefik antes de llegar a los servicios internos.

Enrutamiento Inteligente de Servicios¶

Traefik dirige cada solicitud al servicio apropiado basándose en la ruta solicitada, el dominio o los encabezados de la petición. Los servicios internos no necesitan ser visibles desde el exterior, lo que permite reorganizar la arquitectura interna sin afectar a los usuarios.

Middleware de Seguridad (Security Headers)¶

Traefik configura automáticamente los encabezados HTTP de seguridad siguiendo las mejores prácticas de OWASP:

Strict-Transport-Security (HSTS): Obliga a los navegadores a usar siempre conexiones HTTPS, previniendo ataques de degradación de protocolo.
X-Frame-Options: Configurado en modo sameorigin para prevenir ataques de clickjacking.
X-Content-Type-Options: Configurado como nosniff para prevenir que archivos maliciosos se interpreten como ejecutables.
Content-Security-Policy (CSP): Define una política detallada sobre qué recursos puede cargar la aplicación (scripts, estilos, fuentes, imágenes, workers, conexiones externas).
X-Permitted-Cross-Domain-Policies: Configurado como none, impide el acceso mediante tecnologías legacy como Flash o PDF desde otros dominios.
Cross-Origin-Opener-Policy: Configurado como same-origin para aislar la ventana del navegador de otros orígenes.
Cache-Control: Configurado para no almacenar información en caché, garantizando siempre datos actualizados.
Referrer-Policy: Envía información de referencia completa solo dentro del mismo protocolo HTTPS.
Ocultamiento de información del servidor: Se eliminan los headers Server y X-Powered-By para dificultar la identificación de vulnerabilidades.

Gestión de Autenticación y Autorización¶

Traefik actúa como el primer punto de validación de identidad. Si las credenciales no son válidas o están ausentes, rechaza la solicitud inmediatamente sin contactar al servicio de destino. Tipos de protección:

Validación de tokens de autenticación.
Verificación de sesiones activas.
Control de acceso basado en roles.
Autenticación básica HTTP (cuando aplique).

Protección contra Amenazas¶

Rate Limiting: Previene que un usuario o IP realice demasiadas solicitudes en poco tiempo, protegiendo contra ataques de denegación de servicio.
Filtrado de solicitudes malformadas: Rechaza solicitudes que no cumplan con los estándares HTTP.
Control de origen (CORS): Define qué dominios externos pueden acceder a los recursos de la plataforma.
Validación de tamaño: Limita el tamaño de las solicitudes para prevenir ataques de sobrecarga.

Caddy (Opcional)¶

Caddy es un servidor web moderno utilizado principalmente para proporcionar certificados SSL/TLS de forma automática y sin configuración compleja. Su característica principal es la capacidad de obtener, instalar y renovar certificados de seguridad HTTPS sin intervención manual, usando Let's Encrypt.

Caddy actúa como un proveedor rápido de SSL/TLS, facilitando que la plataforma cuente con conexiones seguras de manera inmediata y sin la complejidad típica asociada a la gestión de certificados.

Keycloak¶

Keycloak es el sistema centralizado de Gestión de Identidad y Acceso (Identity and Access Management - IAM) de la plataforma. Es la solución que permite a los usuarios iniciar sesión una sola vez y acceder a todos los servicios de la plataforma sin necesidad de autenticarse repetidamente en cada uno (Single Sign-On).

Keycloak es el centro de control de identidad de toda la plataforma, siendo responsable de:

Validar la identidad de los usuarios (autenticación).
Determinar qué puede hacer cada usuario (autorización).
Gestionar sesiones de usuario de forma segura.
Proporcionar un punto único de acceso (Single Sign-On).
Administrar credenciales y políticas de seguridad.