Sicurezza del sito web: la checklist pratica per le PMI

La sicurezza di un sito web aziendale non dipende da un prodotto miracoloso, ma da poche abitudini ripetute nel tempo: software sempre aggiornato, accessi protetti con password robuste e doppio fattore, copie di sicurezza conservate fuori dal server, HTTPS ovunque, un controllo periodico di cosa succede e, soprattutto, una persona che se ne occupa per davvero. La maggior parte dei siti violati che ho visto non è stata colpita da attacchi sofisticati: è stata colpita perché nessuno aggiornava niente da anni.

Questa è la checklist che uso quando prendo in carico un sito, spiegata in modo che tu possa verificarla anche da solo.

Chi attacca il sito di una piccola azienda, e perché?

Quasi mai qualcuno ce l'ha con te in particolare. La grande maggioranza degli attacchi è automatica: programmi che girano giorno e notte su milioni di siti cercando una versione vecchia di un'estensione, una password debole, un modulo senza protezioni. Quando trovano una porta aperta entrano, a prescindere da chi sia il proprietario.

Una volta dentro, il sito viene usato per:

• pubblicare pagine di spam (farmaci, scommesse, prodotti contraffatti) che sfruttano la reputazione del tuo dominio su Google;
• reindirizzare i visitatori, spesso solo da telefono, verso truffe e siti malevoli;
• ospitare pagine di phishing che imitano banche o corrieri;
• inviare email di spam dal tuo server, finendo nelle liste nere;
• rubare i dati dei moduli, dei clienti o dei pagamenti.

Le conseguenze per l'azienda sono concrete: avvisi di Google che spaventano i visitatori, crollo delle posizioni, email aziendali che non arrivano più, possibili obblighi verso il Garante se sono coinvolti dati personali.

1. Aggiornamenti: chi li fa e ogni quanto?

È il punto più importante. Un sito è fatto di molti pezzi: il sistema di gestione dei contenuti (WordPress, ad esempio), il tema, le estensioni, il linguaggio su cui gira il server (spesso PHP), il database, il sistema operativo. Ognuno riceve correzioni di sicurezza, e le versioni vecchie smettono di riceverle.

La checklist:

• aggiornamenti di sicurezza applicati entro pochi giorni dall'uscita, non «quando capita»;
• estensioni e temi non usati eliminati, non solo disattivati;
• nessuna estensione abbandonata dal suo autore da anni;
• versione del linguaggio del server ancora supportata;
• un ambiente di prova dove testare gli aggiornamenti importanti prima di applicarli al sito vero.

Se nessuno sa dire chi aggiorna il tuo sito, la risposta è che nessuno lo aggiorna. È esattamente il lavoro che svolgo con il servizio di manutenzione e hosting.

2. Accessi: chi può entrare e come?

Il secondo punto debole sono gli accessi: pannello del sito, hosting, FTP, database, registrar del dominio.

• Password lunghe e uniche per ogni servizio, conservate in un gestore di password aziendale.
• Autenticazione a due fattori su tutto quello che la supporta, a partire da hosting, dominio e pannello di amministrazione.
• Un account per persona, con i permessi minimi necessari: chi scrive articoli non deve poter installare estensioni.
• Account dei collaboratori chiusi quando il rapporto finisce.
• Limite ai tentativi di accesso, per fermare chi prova migliaia di password.

Ho approfondito il tema nella guida all'autenticazione a due fattori e alle password aziendali.

3. Backup: esistono davvero e funzionano?

Un backup che non hai mai provato a ripristinare è una speranza, non un backup. Le regole minime:

• copie automatiche e frequenti di file e database;
• conservate fuori dal server del sito, così un attacco o un guasto non le cancella insieme al sito;
• più versioni nel tempo, perché un'infezione può restare nascosta per settimane;
• una prova di ripristino periodica, documentata.

4. HTTPS e configurazione del server

Il certificato HTTPS cifra la comunicazione tra visitatore e sito. Oggi è il minimo, e i browser segnalano sempre più duramente i siti che non lo usano. Oltre al certificato, controllo che:

• tutte le pagine rispondano solo in HTTPS, con il reindirizzamento automatico da HTTP;
• il rinnovo del certificato sia automatico, perché la durata massima si sta accorciando;
• siano attive le intestazioni di sicurezza che istruiscono il browser (ad esempio quella che impone HTTPS e quelle che limitano l'incorporamento del sito in pagine altrui);
• la lista dei file e delle cartelle non sia visibile dall'esterno;
• i file di configurazione e le copie di sicurezza non siano scaricabili da chiunque conosca l'indirizzo.

5. Moduli, pagamenti e dati dei clienti

Ogni modulo è una porta. Un modulo contatti senza protezioni viene usato per inviare spam o, peggio, per tentare di iniettare codice. I rischi principali sono descritti da anni dall'OWASP Top 10, l'elenco di riferimento delle vulnerabilità più diffuse nelle applicazioni web: controlli di accesso difettosi, iniezioni nei database, configurazioni sbagliate, componenti vulnerabili.

Le contromisure che applico di serie:

• validazione di tutto quello che arriva dai moduli, lato server;
• limiti al numero di invii e protezioni anti-spam che non complicano la vita alle persone;
• pagamenti gestiti da fornitori specializzati, così i dati delle carte non passano mai dal tuo server;
• dati personali raccolti solo se servono, e cancellati quando non servono più.

Non è solo buon senso: il GDPR chiede di raccogliere solo i dati necessari e, all'articolo 32, di adottare misure tecniche e organizzative adeguate al rischio, compresa la capacità di ripristinare l'accesso ai dati dopo un incidente.

6. Hosting: dove gira il sito?

L'hosting conta più di quanto sembri. Su un hosting condiviso di bassa qualità un sito compromesso può contagiare gli altri, gli aggiornamenti del server arrivano in ritardo e il supporto risponde dopo giorni. Le domande da fare al fornitore:

• i server sono in Europa?
• chi aggiorna il sistema operativo e il software del server?
• ci sono un firewall applicativo e una protezione dagli attacchi di saturazione?
• i siti dei clienti sono isolati tra loro?
• in quanto tempo risponde il supporto, e in che modo?

7. Monitoraggio: come mi accorgo che qualcosa non va?

Molti titolari scoprono che il sito è stato violato da un cliente che telefona, o da un avviso di Google settimane dopo. Un monitoraggio di base comprende:

• un controllo automatico che il sito sia raggiungibile, con avviso immediato se cade;
• Google Search Console attiva, che segnala problemi di sicurezza e pagine sospette;
• un controllo periodico dei file modificati e degli utenti amministratori;
• registri di accesso conservati per un tempo ragionevole.

Se il danno è già fatto, ho scritto una guida su cosa fare quando il sito è stato hackerato.

Un sito statico è più sicuro?

Spesso sì, e vale la pena saperlo quando si sceglie come costruire un sito. Un sito statico è fatto di pagine già pronte, generate in anticipo e servite così come sono: non c'è un database interrogato a ogni visita, non c'è un pannello di amministrazione esposto su internet, non ci sono estensioni da aggiornare sul server. La superficie d'attacco si riduce moltissimo.

Non è la soluzione per tutto. Un e-commerce, un'area clienti, un sistema di prenotazione hanno bisogno di una parte dinamica, e quella va protetta con tutte le attenzioni della checklist. Ma per un sito vetrina, che cambia qualche volta al mese, una struttura statica con i contenuti gestiti a parte è spesso la scelta più robusta e anche la più veloce.

Quando progetto un sito parto da questa domanda: quali parti devono davvero essere dinamiche? Tutto il resto può essere statico.

La checklist in breve

1. Aggiornamenti di sicurezza applicati entro pochi giorni.
2. Estensioni inutili eliminate.
3. Password uniche e doppio fattore su hosting, dominio e pannello.
4. Un account per persona, permessi minimi.
5. Backup automatici, fuori dal server, con prova di ripristino.
6. HTTPS ovunque, certificato con rinnovo automatico.
7. Intestazioni di sicurezza e file sensibili non accessibili.
8. Moduli protetti, pagamenti delegati a fornitori specializzati.
9. Hosting con server aggiornati e supporto reattivo.
10. Monitoraggio della raggiungibilità e di Search Console.

Se il tuo sito è costruito su basi così vecchie da non poter essere aggiornato senza rompersi, a volte la scelta più sicura è un rifacimento del sito su tecnologie mantenute.

Ne parliamo?

Se non sai quando è stato aggiornato l'ultima volta il tuo sito, o chi ha le chiavi, scrivimi dalla pagina contatti. Faccio un controllo di sicurezza e ti dico con chiarezza cosa sistemare e con che urgenza; se ti serve un parere più ampio sull'infrastruttura, posso affiancarti con una consulenza tecnica.

Fonti

• OWASP Top 10, i rischi più critici per le applicazioni web
• Regolamento (UE) 2016/679 (GDPR), articolo 32 sulla sicurezza del trattamento

Crediti delle immagini

• Copertina: foto di Sasun Bughdaryan su Unsplash