Vai al contenuto

Fragilità, Criticità Infrastrutturali ed Esigenze Sistemistiche

Questo documento delinea in modo oggettivo le vulnerabilità, i rischi operativi e i limiti architetturali attualmente presenti nell'infrastruttura MDM.

Lo scopo non è fornire una lista prescrittiva di compiti, bensì fotografare lo stato di fatto e mettere in luce le aree di fragilità sistemistica su cui è necessario il supporto specialistico del sistemista.

1. Matrice Sinottica dei Rischi e delle Fragilità

quadrantChart
    title "Matrice Impatto e Probabilita delle Fragilita"
    x-axis "Bassa Probabilita" --> "Alta Probabilita"
    y-axis "Basso Impatto" --> "Alto Impatto"
    quadrant-1 "Massima Priorita Operativa"
    quadrant-2 "Rischio Strutturale Grave"
    quadrant-3 "Da Monitorare"
    quadrant-4 "Rischio di Conformita"
    "SPOF Server Netsons": [0.30, 0.95]
    "SPOF pfSense VM 101": [0.45, 0.90]
    "VPN non Segmentata": [0.85, 0.85]
    "Backup solo Settimanali": [0.70, 0.80]
    "Redis Volume Anonimo": [0.75, 0.75]
    "Monitoraggio Raspberry": [0.80, 0.70]
    "Overcommit Disco Host": [0.55, 0.60]
    "Credenziali Condivise": [0.80, 0.50]
    "Subnet non RFC1918": [0.20, 0.35]
    "VM 400 Inutilizzata": [0.90, 0.25]
Hold "Ctrl" to enable pan & zoom

2. Single Point of Failure (SPOF) e Continuità Operativa

A. Host Fisico Netsons "la 229" (185.31.66.229)

  • Stato Attuale: Tutte le istanze (firewall perimetrale, centralino telefonico trombe, midserver di produzione, ambiente di test, postazione Windows) risiedono su un unico server hardware bare metal presso il datacenter Netsons di Milano. Non esiste alcun nodo secondario, cluster Proxmox o meccanismo di failover geografico.
  • Impatto Potenziale: Qualsiasi guasto hardware (alimentatore, scheda madre, controller RAID, switch di top-of-rack del datacenter) o manutenzione programmata della rete Netsons (come le 5 ore di fermo notturno verificatesi a luglio 2026) comporta il blocco totale e simultaneo di:
  • Tutti i 66 impianti periferici dei clienti (impossibilità di segnalare allarmi, inviare telemetria o trasmettere video).
  • Tutta la connettività tra la centrale operativa di Cava de' Tirreni e i server.
  • La telefonia VoIP di emergenza delle trombe acustiche.
  • Esigenza Sistemistica:
  • Analizzare la fattibilità e i costi per un server secondario (in altro datacenter Netsons o in sede) per implementare replica asincrona dello storage ZFS/LVM o un piano di Disaster Recovery verificato.
  • Ricezione diretta e gestione degli avvisi di manutenzione programmata dal portale Netsons.

B. Firewall Virtualizzato pfSense (VM 101)

  • Stato Attuale: pfSense è una singola macchina virtuale priva di ridondanza (nessuna configurazione CARP o appliance di backup). Gestisce la WAN, il routing della LAN, il NAT e termina contemporaneamente il tunnel VPN degli impianti (WG_VPN) e quello della sede di Cava (WG_STS_CAVA).
  • Impatto Potenziale: Un crash dell'OS FreeBSD, un kernel panic o un errore di configurazione isola istantaneamente l'intera infrastruttura sia verso internet che verso la VPN.
  • Esigenza Sistemistica:
  • Implementazione di procedure automatizzate di backup off-site del file di configurazione XML (config.xml) ad ogni modifica.
  • Valutazione dell'introduzione di una seconda istanza gateway o di un piano rapido di ripristino per pfSense.

3. Rete e Isolamento dei Flussi VPN (Mancata Segmentazione)

A. Esposizione delle Porte Interne sulla Rete VPN degli Impianti

  • Stato Attuale:
  • pfSense mappa l'indirizzo VPN 172.16.16.253 verso l'IP LAN 170.10.0.108 (ServerIT) con un NAT 1:1 aperto su tutte le porte.
  • Sul firewall pfSense, l'interfaccia WG_VPN è configurata con una regola permissive allow any -> any.
  • La limitazione del traffico è attualmente delegata solo al file di configurazione del client WireGuard a bordo del box (AllowedIPs = 172.16.16.1/32, 172.16.16.253/32, 172.16.16.254/32).
  • Impatto Potenziale:
  • La direttiva AllowedIPs è una configurazione lato client: chiunque ottenga l'accesso a un box cliente o manometta la tabella di routing locale può interrogare qualsiasi porta di ServerIT.
  • Dalla rete impianti risultano teoricamente raggiungibili:
    • MySQL di produzione (3306)
    • Redis (6379)
    • phpMyAdmin (7070)
    • Server di integrazione relè Sonoff eWeLink (8080, privo di autenticazione)
    • Interfaccia web di pfSense (http://172.16.16.1:80)
    • Potenzialmente, gli altri box clienti connessi alla stessa subnet 172.16.16.0/24.
  • Esigenza Sistemistica:
  • Configurazione di un set di regole rigide a livello di firewall su pfSense: limitare i box clienti esclusivamente alla porta 5000/TCP (API midserver) e 1883/TCP (MQTT Mosquitto).
  • Bloccare qualsiasi comunicazione diretta box-to-box (172.16.16.x → 172.16.16.y) e verso le porte amministrative/interne di ServerIT.
  • Preservare inalterati i flussi dalla sede di Cava (171.16.16.0/24), che deve continuare a raggiungere gli NVR e le porte video dei clienti (554, 8554, 10101-10105, 5005).

B. Indirizzi IP Pubblici Utilizzati in Rete Interna

  • Stato Attuale: Utilizzo delle subnet 170.10.0.0/24 (LAN interna VM) e 171.16.16.0/24 (Sede Cava).
  • Impatto Potenziale: Sono indirizzi IP non-RFC 1918 registrati pubblicamente su internet da terze parti; l'infrastruttura interna non è in grado di raggiungere gli host internet legittimi aventi quegli indirizzi.
  • Esigenza Sistemistica: Mantenere invariato lo stato attuale per evitare rotture sui client attivi, ma evitare rigorosamente l'allocazione di nuovi servizi su tali blocchi, predisponendo un futuro piano di migrazione verso indirizzamento privato standard (10.x.x.x o 172.16.x.x).

4. Politiche di Backup e Data Protection

A. Frequenza e Tipologia di Backup

  • Stato Attuale:
  • Viene eseguito esclusivamente uno snapshot completo delle VM Proxmox tramite vzdump con cadenza settimanale (ogni sabato notte alle ore 01:00) inviato via NFS sul NAS QNAP della sede di Cava.
  • Vengono mantenute solo le ultime 3 copie settimanali.
  • Nessun backup logico dedicato per MySQL: Il database q_alarm_mid su ServerIT non ha un cron job con mysqldump. Il recupero di una tabella o di un dato corrotto richiederebbe il ripristino dell'intera immagine VM da 200 GB.
  • Impatto Potenziale: In caso di crash o corruzione del database tra lunedì e venerdì, il Recovery Point Objective (RPO) effettivo è di diversi giorni, con potenziale perdita di registrazioni di nuovi impianti e configurazioni.
  • Esigenza Sistemistica:
  • Implementazione di backup logici orari o giornalieri del database MySQL con script dedicato e rotazione, inviati su storage sicuro (es. bucket AWS S3 o NAS).
  • Valutazione dell'acquisto di un disco dedicato aggiuntivo sull'host Netsons per backup locali giornalieri ad alta velocità prima della replica remota.

B. Persistenza dei Dati su Redis (ServerIT)

  • Stato Attuale:
  • Il container Redis in produzione utilizza un volume anonimo Docker su /data.
  • La modalità di persistenza AOF (Append Only File) è disattivata; è attivo solo lo snapshot RDB periodico.
  • Impatto Potenziale: L'esecuzione di un comando docker compose down seguito da docker compose up provoca la perdita immediata del volume anonimo, distruggendo lo stream degli eventi non ancora consumati e lo stato memorizzato dei 38 box attivi.
  • Esigenza Sistemistica:
  • Migrazione del container Redis verso un volume Docker con nome (named volume) o bind-mount persistente su disco host.
  • Valutazione dell'abilitazione di AOF per minimizzare la perdita di dati in caso di arresto anomalo.

5. Stato del Monitoraggio Infrastrutturale

A. Monitoraggio di Produzione Affidato a un Dispositivo Singolo

  • Stato Attuale:
  • L'unico sistema attivo che controlla la produzione è un Raspberry Pi fisico situato presso l'ufficio di Cava (192.168.200.220), gestito storicamente da Michele (in uscita dall'azienda).
  • Esegue script bash/PHP che interrogano 18 servizi, registrano i risultati su un database locale e inviano notifiche su un canale Telegram ("Controllo Infrastrutture").
  • Il Raspberry Pi non dispone di backup; sul medesimo dispositivo gira anche il controllo presenze / "uomo a terra" dell'operatore notturno.
  • Impatto Potenziale:
  • Un guasto hardware al Raspberry o all'alimentazione dell'ufficio elimina qualsiasi visibilità e allarmistica sullo stato dei server di Milano e della VPN.
  • Mancanza di documentazione puntuale sulle soglie e sulle logiche degli script di controllo.
  • Esigenza Sistemistica:
  • Sostituire il controllo artigianale con una soluzione di monitoraggio perimetrale enterprise (es. Uptime Kuma per ping/HTTP/porte con notifiche ridondate).
  • Promuovere e scalare lo stack di osservabilità moderno (Prometheus, Grafana, Loki, Alertmanager) attualmente confinato alla VM 200 di DEV per raccogliere metriche di sistema (RAM, CPU, spazio disco, stato container) anche dai server di produzione.

6. Risorse Hardware, Capacità e Nuove Macchine Virtuali

A. Analisi Risorse Host Proxmox

  • Storage Locale (local-lvm):
  • Capacità reale: 758 GB.
  • Spazio occupato: ~354 GB.
  • Spazio nominale assegnato ai dischi virtuali delle VM: circa 760 GB.
  • L'host opera in regime di thin provisioning: se le macchine virtuali dovessero espandere improvvisamente l'uso effettivo dei loro dischi, lo storage fisico dell'host andrebbe in saturazione, bloccando tutte le VM.
  • CPU e Memoria RAM:
  • 125 GB di RAM fisica: 52 GB allocati alle VM attive, oltre 70 GB liberi.
  • 20 thread CPU disponibili con load medio molto basso.

B. Opportunità di Recupero Risorse: Rimozione VM 400

  • Stato: La VM 400 (Server) è una vecchia istanza di sviluppo/collaudo attualmente spenta e non più utilizzata.
  • Risorse Impegnate: Blocca 16 vCPU, ben 32 GB di RAM e 300 GB di disco virtuale.
  • Esigenza Sistemistica: Previa verifica e backup definitivo su NAS, l'eliminazione della VM 400 permette di recuperare immediatamente 32 GB di memoria e 300 GB di spazio disco, eliminando il rischio di overcommit su local-lvm.

C. Valutazione Creazione Nuova Macchina Virtuale

  • Contesto Operativo: Attualmente la VM 500 (ServerIT) ospita sia componenti core di rete/database (MySQL, Redis, Mosquitto, OME) sia l'applicativo midserver. Per il futuro rilascio della nuova versione applicativa e di qAlarm è opportuno evitare di sovraffollare la VM 500.
  • Fattibilità Tecnica:
  • Lo spazio e la memoria sull'host sono ampiamente sufficienti per istanziare una nuova VM di Produzione Applicativa (es. Prod-Apps, 4 vCPU, 8-16 GB RAM, 80-100 GB disco).
  • L'indirizzo IP pubblico 185.31.66.186 dispone delle porte HTTP/HTTPS (80 e 443) completamente libere, permettendo di esporre la nuova VM su internet tramite NAT senza interferire con i servizi esistenti su 185.31.66.185.

7. Gestione Identità, Credenziali e Segreti

  • Stato Attuale:
  • Utilizzo diffuso di credenziali amministrative condivise (root per Proxmox, admin per il pannello pfSense, utente bsqsecurity con sudo senza password su tutti i server).
  • Nelle guide storiche di provisioning dei box clienti sono riportate password fisse condivise per root di MySQL e per l'accesso locale a Nginx Proxy Manager (porta 81).
  • Impatto Potenziale: Impossibilità di effettuare audit trail nominale delle modifiche sistemistiche e rischio elevato in caso di avvicendamento del personale.
  • Esigenza Sistemistica:
  • Creazione di account amministrativi individuali e nominali per i sistemisti su Proxmox e pfSense.
  • Configurazione di token API con permessi granulari (es. ruolo di sola lettura PVEAuditor per script e tool diagnostici).
  • Revisione e rotazione delle chiavi di accesso condivise.