Cómo mikroHUB protege su infraestructura de red
Versión del documento: 2026-03-22 · Preguntas: [email protected]
INTERNET
┌────────────────────┬──────────────────────┐
│ HTTPS/443 │ WSS/443 │ WG/UDP 51820
│ (TLS 1.2+) │ (WebSocket) │ (WireGuard)
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────┐
│ NGINX REVERSE PROXY (mikrohub.io) │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────────┐ │
│ │ Let's Encrypt │ │ HSTS Preload │ │ CSP + Security Headers │ │
│ │ ECDSA cert │ │ max-age=2yr │ │ X-Frame, X-Content │ │
│ └──────────────┘ └──────────────┘ └────────────────────────┘ │
│ Ports open : 80 (→301), 443, 51820/UDP │
│ Ports BLOCKED: 3001 (API), 6379 (Redis) │
└──────────┬──────────────────────┬───────────────────┬───────────┘
│ :3001 │ :3001/ws │ :51820
▼ ▼ ▼
┌──────────────────┐ ┌──────────────┐ ┌──────────────────────────┐
│ EXPRESS API │ │ WebSocket │ │ WireGuard (wg0) │
│ (Node.js) │ │ Server │ │ 10.99.0.1/16 │
│ │ │ One-time │ │ Per-device /32 peer │
│ JWT validation │ │ ticket auth │ │ No split tunnel │
│ 60s session cache│ │ (no JWT │ │ │
│ 1h max token age │ │ in URL) │ │ Devices: 10.99.x.y │
└────────┬─────────┘ └──────────────┘ └──────────────────────────┘
│
┌─────┴──────┐
▼ ▼
┌────────┐ ┌────────┐
│Supabase│ │ Redis │
│Postgres│ │ TLS │
│(cloud) │ │(local) │
│RLS on │ │ Auth │
│all tbl │ │ reqd │
└────────┘ └────────┘Todo el tráfico externo termina en Nginx con TLS 1.2+. Los servicios internos (puerto API 3001, puerto Redis 6379) están bloqueados en el nivel del firewall y nunca se exponen a Internet.
| Capa | Mecanismo |
|---|---|
Autenticación de usuarioPKCE | Autenticación Supabase con flujo PKCE (no implícito) |
Almacenamiento de tokensCOOKIE | Seguro + SameSite=Cookies laxas (no almacenamiento local) |
Vida útil del tokenTTL | 1 hora máximo, caché de 60 segundos, actualización forzada |
Revocación de sesiónREVOKE | Invalidación en memoria + lista negra de tokens |
Autenticación de WebSocketTICKET | Intercambio de boletos único (JWT nunca en URL) |
Autenticación de clave APISHA-256 | SHA-256 hash, ámbito por recurso, caducidad impuesta |
Autenticación del agente del dispositivoAGENT | Token hash SHA-256, velocidad limitada (2 solicitudes/30 s) |
Ministerio de Asuntos ExterioresMFA | TOTP (aplicación de autenticación) + WebAuthn/FIDO2 (claves de acceso, YubiKey) |
AES-256-GCM con IV aleatorio por entrada, etiqueta de autenticación validada
Almacenado como iv:tag:ciphertext en Supabase (nunca texto sin formato)
Descifrado sólo en el momento de la encuesta, en memoria, nunca registrado
RouterOS API-SSL con conexión cifrada TLS
Conexión TLS directa vía API-SSL (puerto 8729). Acceso completo a la gestión.
Túnel cifrado: no se requieren puertos abiertos en el enrutador.
Conexión TLS directa de solo lectura. No hay acceso de escritura al enrutador.
El dispositivo envía datos salientes a través de HTTPS. Nada entrante.
| Componente | Protección |
|---|---|
| ✓TLS | TLSv1.2 + TLSv1.3, cifrados ECDHE, precarga HSTS |
| ✓Cortafuegos (UFW) | Sólo 80, 443, 51820/UDP expuestos. API (3001) y Redis (6379) DENEGAR |
| ✓Redis | TLS habilitado, se requiere contraseña, enlace solo de host local |
| ✓Encabezados Nginx | HSTS, Opciones de marco X, Opciones de tipo de contenido X, CSP, Política de permisos |
| ✓Limitación de tasa | Global 300/15 min, autenticación 5/min, administrador 30/15 min, agente 2/30 s |
| ✓Parámetros DH | dhparam de 2048 bits para secreto directo |
| Estándar | Estado |
|---|---|
| HTTPS en todas partes | ✅aplicado |
| Cifrado en reposo | ✅AES-256-GCM para credenciales |
| Cifrado en tránsito | ✅TLS + WireGuard |
| Autenticación | ✅JWT + MFA + PKCE |
| Autorización | ✅RBAC + SPI |
| Pista de auditoría | ✅Registro de auditoría completo con seguimiento de IP |
| Eliminación de datos (GDPR) | ✅Punto final de borrado de cuenta |
| Gestión de sesiones | ✅Lista negra de tokens + actualización forzada |
Estaremos encantados de responder cualquier pregunta de posibles clientes y auditores.