mikroHUB

Architektura bezpieczeństwa

Jak mikroHUB chroni Twoją infrastrukturę sieciową

Wersja dokumentu: 2026-03-22 · Pytania: [email protected]

Architektura sieci

                              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   │
└────────┘  └────────┘

Cały ruch zewnętrzny kończy się na Nginx z TLS 1.2+. Wewnętrzne usługi (API port 3001, Redis port 6379) są zablokowane na poziomie firewalla i nigdy nie są wystawione do internetu.

Uwierzytelnianie i autoryzacja

WarstwaMechanizm
Uwierzytelnianie użytkownikaPKCE
Supabase Auth z przepływem PKCE (nie implicit)
Przechowywanie tokenówCOOKIE
Cookies Secure + SameSite=Lax (nie localStorage)
Czas życia tokenuTTL
Maks. 1 godzina, cache 60 s, wymuszone odświeżanie
Unieważnianie sesjiREVOKE
Unieważnianie w pamięci + blacklist tokenów
Uwierzytelnianie WebSocketTICKET
Jednorazowy ticket (JWT nigdy w URL)
Uwierzytelnianie kluczem APISHA-256
Hash SHA-256, scope per-zasób, wymuszane wygasanie
Uwierzytelnianie agenta urządzeniaAGENT
Hash SHA-256 tokenu, rate-limit (2 zap./30 s)
MFAMFA
TOTP (aplikacja) + WebAuthn/FIDO2 (passkeys, YubiKey)

Izolacja danych (multi-tenant)

Org A — "ISP Gdańsk"
devices (org_id=1)
metrics (org_id=1)
backups (org_id=1)
logs (org_id=1)
✕
RLS ZABLOKOWANE
Org B — "Firma Warszawa"
devices (org_id=2)
metrics (org_id=2)
backups (org_id=2)
logs (org_id=2)
  • Row-Level Security (RLS) na WSZYSTKICH tabelach danych
  • Wymuszane na poziomie PostgreSQL — nawet SQL injection nie przekroczy granic tenanta
  • Middleware API podwójnie weryfikuje przynależność do org. przy każdym żądaniu
  • Subskrypcje WebSocket walidowane wobec org_members

Poświadczenia urządzeń

1

Szyfruj

AES-256-GCM z losowym IV dla każdego wpisu, walidowany auth tag

2

Przechowuj

Zapisane jako iv:tag:ciphertext w Supabase (nigdy plaintext)

3

Odszyfruj przy odpytywaniu

Deszyfrowane wyłącznie przy odpytywaniu, w pamięci, nigdy nie logowane

4

Połącz

RouterOS API-SSL z szyfrowanym połączeniem TLS

  • Klucz główny w zmiennej środowiskowej (nie w kodzie, nie w DB)
  • Poświadczenia deszyfrowane tylko gdy potrzebne do połączenia z urządzeniem
  • Komunikaty błędów ukrywają IP i poświadczenia regexem
  • Poświadczenia nigdy nie pojawiają się w logach, odpowiedziach ani audycie

Tryby połączenia

Zarządzanie przez API

Bezpośrednie połączenie TLS przez API-SSL (port 8729). Pełny dostęp zarządczy.

  • Szyfrowane TLS
  • Ograniczone do IP mikroHUB
  • Tylko port 8729

WireGuard

Szyfrowany tunel — zero otwartych portów na routerze.

  • Brak publicznych portów
  • Peer /32 na urządzenie
  • Bez split-tunnel
  • Jednorazowa konfiguracja kopiuj-wklej

Monitoring API

Bezpośrednie połączenie TLS tylko do odczytu. Brak dostępu do zapisu.

  • Tylko odczyt
  • Szyfrowane TLS
  • Ograniczone do IP

Agent

Urządzenie wysyła dane przez HTTPS. Brak ruchu przychodzącego.

  • Tylko wychodzące (HTTPS)
  • Brak otwartych portów
  • Model push-only
  • Rate-limit (2 zap./30 s)

Bezpieczeństwo infrastruktury

KomponentZabezpieczenie
✓TLSTLSv1.2 + TLSv1.3, szyfry ECDHE, HSTS preload
✓Firewall (UFW)Otwarte tylko 80, 443, 51820/UDP. API (3001) i Redis (6379) — DENY
✓RedisTLS włączone, hasło wymagane, bind tylko na localhost
✓Nagłówki NginxHSTS, X-Frame-Options, X-Content-Type-Options, CSP, Permissions-Policy
✓Rate limitingGlobalnie 300/15 min, Auth 5/min, Admin 30/15 min, Agent 2/30 s
✓Parametry DH2048-bit dhparam dla forward secrecy

Czego NIE robimy

  • ❌ Nigdy nie przechowujemy haseł plaintext
  • ❌ Nie używamy localStorage do tokenów
  • ❌ Nie wystawiamy wewnętrznych usług do internetu
  • ❌ Nie dopuszczamy dostępu do danych między tenantami
  • ❌ Nie logujemy poświadczeń ani danych wrażliwych
  • ❌ Nie wymagamy otwartych portów na routerze (tryb WireGuard)
  • ❌ Nie używamy plaintext API (SSL wymagane w trybie direct)

Zgodność

StandardStatus
HTTPS wszędzie✅Wymuszane
Szyfrowanie w spoczynku✅AES-256-GCM dla poświadczeń
Szyfrowanie w tranzycie✅TLS + WireGuard
Uwierzytelnianie✅JWT + MFA + PKCE
Autoryzacja✅RBAC + RLS
Ścieżka audytu✅Pełny log audytu z śledzeniem IP
Usuwanie danych (RODO)✅Endpoint usuwania konta
Zarządzanie sesjami✅Blacklist tokenów + wymuszone odświeżanie

Pytania o bezpieczeństwo?

Chętnie odpowiemy na pytania potencjalnych klientów i audytorów.

[email protected]