Uno degli errori più comuni e più gravi del self-hosting: un database esposto a internet. PostgreSQL (5432), MySQL/MariaDB (3306), MongoDB, Redis, Elasticsearch – lasciati in ascolto su tutte le interfacce, vengono trovati in minuti dagli scanner (Shodan ne cataloga milioni) e attaccati con brute force o, peggio, trovati senza autenticazione (il default storico di alcuni è stato disastroso). Innumerevoli breach di massa nascono esattamente così.
La regola d'oro: un database non deve MAI essere raggiungibile da internet – deve ascoltare solo dove serve:
- socket Unix dove il database e l'applicazione stanno sulla stessa macchina – nemmeno la rete locale è coinvolta, la comunicazione passa da un file di sistema. Il massimo dell'isolamento (e spesso più veloce)
localhost(127.0.0.1) – ascolta solo sulla macchina stessa:listen_addresses = 'localhost'in PostgreSQL,bind-address = 127.0.0.1in MariaDB- rete privata dove l'app è su un'altra macchina – ascolta solo sull'IP interno/VLAN dedicata, mai sull'IP pubblico, con firewall che chiude la porta all'esterno. Nei container: reti Docker interne, senza pubblicare la porta del database (
portsnon serve se solo altri container la usano)
Più le difese di contorno: password forti (mai le default), TLS se il traffico attraversa reti non fidate, minimo privilegio sugli utenti del database. È l'igiene più elementare che esista – verifica con ss -tlnp o nmap dall'esterno che le porte dei database non rispondano – eppure la sua assenza resta una delle cause principali di data breach. La domanda da farsi per ogni servizio: ha davvero bisogno di essere raggiungibile da fuori? Per un database, la risposta è quasi sempre no.