Se gestisci server Plesk per conto di clienti che rientrano nel perimetro della Direttiva NIS2, il 2026 è l’anno in cui non puoi più rimandare. Nella mia esperienza di system administrator per web agency, ho dovuto affrontare concretamente la questione: come rendere un server Plesk conforme ai requisiti NIS2 in termini di logging, action log esterno, autenticazione multi-fattore e gestione degli incidenti? In questo articolo vi mostro la procedura completa che ho applicato sui miei server, passo dopo passo.
La Direttiva NIS2 (Directive EU 2022/2555) è entrata in vigore in Italia con il D.Lgs. 138/2024 il 16 ottobre 2024. A partire da gennaio 2026, i soggetti essenziali e importanti devono rispettare gli obblighi di notifica degli incidenti significativi, ed entro ottobre 2026 dovranno dimostrare di aver adottato tutte le misure tecniche e organizzative minime. La cosa che molti sottovalutano è che la NIS2 non riguarda solo le grandi aziende: se la tua web agency fornisce servizi digitali (hosting, DNS, email) a enti che rientrano nei 18 settori critici, potresti essere coinvolto come parte della supply chain.
Ho scritto questa guida perché, all’inizio, credevo bastasse attivare qualche opzione in Plesk. Mi sbagliavo. La conformità NIS2 su Plesk richiede interventi a più livelli: configurazione del panel.ini, invio dei log a server esterni, enforcement della MFA, e una documentazione puntuale. Vediamo come fare.
Cos’è la Direttiva NIS2 e Perché Riguarda Chi Gestisce Server Plesk
La Direttiva NIS2 stabilisce un quadro giuridico unificato per la cybersecurity in 18 settori critici dell’UE. Rispetto alla precedente NIS1, introduce requisiti più stringenti su gestione del rischio, notifica degli incidenti, sicurezza della supply chain e responsabilità diretta del management. Le sanzioni possono arrivare fino a 10 milioni di euro o il 2% del fatturato globale annuo.
In Italia, l’ACN (Agenzia per la Cybersicurezza Nazionale) è l’autorità competente. A partire da ottobre 2026, potrà avviare attività ispettive, transitando dalla fase di accompagnamento alla fase di verifica. Questo significa che le misure devono essere documentate e verificabili.
Per chi gestisce server Plesk, il punto chiave è questo: Plesk offre una modalità di compatibilità NIS2 che rende impossibile disabilitare il logging delle modifiche DNS e degli eventi di autenticazione, e impedisce la cancellazione completa degli eventi dell’Action Log. Ma attivare questa modalità è solo il primo passo.
Step 1: Attivare la Modalità NIS2 Compatibility in Plesk
Plesk Obsidian include una sezione dedicata alla NIS2 Directive Compliance nella documentazione ufficiale. La modalità NIS2 rende impossibile la disabilitazione del logging degli eventi relativi a DNS e autenticazione (login riusciti e falliti) e impedisce la rimozione completa degli eventi dell’Action Log. Inoltre, in questa modalità, Plesk logga le richieste API che modificano le impostazioni.
Per attivarla, accedi via SSH al tuo server e modifica il file panel.ini:
# Percorso Linux:
/usr/local/psa/admin/conf/panel.ini
# Aggiungi o modifica la sezione:
[actionLog]
nis2 = trueDopo la modifica, riavvia il servizio Plesk:
systemctl restart psaVerifica che nella sezione Tools & Settings → Action Log non sia più possibile disabilitare il logging degli eventi critici. Se hai già configurato Fail2Ban su Plesk per bloccare gli attacchi brute force, questa modalità complementa perfettamente quella protezione, perché garantisce che ogni tentativo di login venga registrato in modo inalterabile.
Step 2: Configurare l’Invio dell’Action Log a un Server Esterno via Syslog
Questo è il passaggio più importante per la conformità NIS2. La direttiva richiede che i log siano completi, accurati e protetti contro modifiche o interruzioni non autorizzate. Per questo, bisogna configurare Plesk per inviare una copia degli Action Log a un server di log esterno.
Abilitare il Syslog nel panel.ini
Aggiungi queste righe al file panel.ini:
[actionLog]
syslog = true
syslogFacility = local0La direttiva syslog = true abilita l’invio degli eventi di Plesk al servizio di logging di sistema (syslog su Linux). La syslogFacility permette di scegliere la facility syslog da utilizzare (di default è local0).
Configurare rsyslog sul Server Plesk
Sul server Plesk, aggiungi al file /etc/rsyslog.conf (o crea un file in /etc/rsyslog.d/):
# Invia i log Plesk al server esterno
local0.* action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp")Sostituisci 192.168.1.100 con l’IP del tuo server di log esterno. Poi riavvia rsyslog:
systemctl restart rsyslogConfigurare il Server di Log Esterno
Sul server esterno (quello che riceverà i log), configura rsyslog per accettare connessioni TCP:
# In /etc/rsyslog.conf del server esterno
module(load="imtcp")
input(type="imtcp" port="514")
# Salva i log Plesk in un file dedicato
local0.* /var/log/pleskactionsRiavvia rsyslog sul server esterno:
systemctl restart rsyslogAttenzione GDPR: i log copiati dal server Plesk a quello esterno possono contenere dati personali (indirizzi IP, login, ecc.). Assicurati che il server esterno sia configurato correttamente per trattare questi dati nel rispetto del GDPR.
Se hai già implementato un sistema di monitoraggio con Grafana e Prometheus, puoi integrare anche l’analisi dei log tramite Loki o uno stack ELK per una visibilità ancora più completa.
Step 3: Attivare e Forzare l’Autenticazione Multi-Fattore (MFA)
La NIS2 richiede esplicitamente l’uso della multi-factor authentication dove appropriato. In Plesk, l’estensione MFA è installata di default e supporta app come Google Authenticator e Microsoft Authenticator. Ma attivarla per il singolo admin non basta: va imposta obbligatoriamente per tutti gli account.
Attivare la MFA per il proprio account
- Accedi a Plesk
- Vai su My Profile → sezione Multi-Factor Authentication (MFA)
- Attiva la checkbox Enable Multi-factor Authentication
- Scansiona il QR code con l’app di autenticazione
- Inserisci il codice di verifica e conferma
Forzare la MFA per tutti gli utenti Plesk
Questo è il passaggio cruciale per la conformità NIS2. Modifica il panel.ini:
[ext-mfa]
enforce = true
allowSkipEnforce = falseCon enforce = true, tutti gli utenti Plesk (amministratori, reseller, clienti) saranno obbligati ad abilitare la 2FA al prossimo login. Con allowSkipEnforce = false, non sarà possibile saltare l’attivazione. Nella mia esperienza, all’inizio qualche cliente si è lamentato, ma dopo aver spiegato che si tratta di un obbligo normativo, tutti hanno compreso.
Se gestisci anche la sicurezza WordPress contro attacchi brute force, ricorda che la MFA su Plesk protegge il pannello di gestione, ma dovresti implementare una protezione equivalente anche a livello applicativo sui siti WordPress dei tuoi clienti.
Step 4: Configurare la Retention dei Log e la Rotazione
La NIS2 richiede la conservazione dei log per un periodo adeguato. Alcune interpretazioni indicano almeno 18 mesi di conservazione. In Plesk, puoi configurare la retention dell’Action Log da Tools & Settings → Action Log → Settings.
Ho configurato i miei server per mantenere i log locali per 12 mesi in Plesk (per non sovraccaricare il database), mentre sul server esterno conservo i log per 24 mesi, usando logrotate per gestire lo spazio disco:
# /etc/logrotate.d/pleskactions
/var/log/pleskactions {
monthly
rotate 24
compress
delaycompress
missingok
notifempty
create 0640 root adm
}Per la gestione dei cronjob su Plesk, ho anche creato un job settimanale che verifica l’integrità dei file di log sul server esterno, calcolando un hash SHA-256 e salvandolo in un file separato.
Step 5: Logging Aggiuntivo per SSH e Accessi di Sistema
L’Action Log di Plesk registra le azioni eseguite tramite interfaccia grafica e API, ma non copre le azioni eseguite via CLI/SSH. Per una copertura completa conforme alla NIS2, è necessario inviare anche altri log al server esterno:
- /var/log/secure (o /var/log/auth.log su Debian/Ubuntu) – login SSH, sudo, autenticazione sistema
- /var/log/maillog – accessi ai servizi email
- Log di Apache/Nginx – accessi web e errori
Aggiungi queste regole a rsyslog:
# Invia auth log al server esterno
auth,authpriv.* action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp")
# Invia mail log
mail.* action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp")Se hai configurato SPF, DKIM e DMARC sui tuoi domini, il monitoraggio dei log email diventa ancora più rilevante per individuare tentativi di spoofing o utilizzo non autorizzato del servizio di posta.
Step 6: Documentazione e Procedure per la Notifica degli Incidenti
Dal 1° gennaio 2026, i soggetti NIS2 devono notificare gli incidenti significativi secondo tempistiche precise: preallerta entro 24 ore, notifica completa entro 72 ore e relazione finale entro un mese. Il canale ufficiale è il portale ACN collegato al CSIRT Italia.
Ho preparato per la mia web agency un runbook operativo che include:
- Rilevamento: come identificare un incidente significativo dai log di Plesk e del sistema
- Valutazione: criteri per determinare se l’incidente rientra negli obblighi di notifica
- Contenimento: procedure immediate (isolamento del server, blocco account compromessi)
- Notifica: template per la comunicazione al CSIRT tramite portale ACN
- Relazione finale: formato per il report conclusivo con root cause analysis
Consiglio di testare questa procedura almeno una volta al trimestre con una simulazione interna.
Checklist Pratica NIS2 per Server Plesk – Web Agency
Ecco la checklist che utilizzo per ogni server Plesk che gestisco. Stampala e usala come riferimento:
- ☐ Modalità NIS2 attivata nel panel.ini (
nis2 = true) - ☐ Syslog abilitato per l’Action Log (
syslog = true) - ☐ Action Log inviato a server esterno via rsyslog (TCP 514)
- ☐ Server esterno configurato per ricevere e conservare i log
- ☐ Retention dei log: minimo 18 mesi sul server esterno
- ☐ Logrotate configurato sul server esterno
- ☐ MFA attivata e forzata per tutti gli utenti Plesk (
enforce = true) - ☐ Auth log e mail log inviati al server esterno
- ☐ Fail2Ban attivo e configurato
- ☐ Procedure di notifica incidenti documentate e testate
- ☐ Backup remoti configurati (ho usato Wasabi S3 per i miei)
- ☐ SSL/TLS aggiornato su tutti i domini
- ☐ Aggiornamenti di sicurezza di Plesk e del sistema operativo automatizzati
- ☐ Audit plugin WordPress eseguito su tutti i siti ospitati
- ☐ Documentazione delle misure conservata e pronta per eventuali ispezioni ACN
Considerazioni sull’Aumento Costi e Alternative
Implementare la conformità NIS2 ha un costo, sia in termini di tempo che di risorse. Se stai anche valutando l’impatto dell’aumento prezzi Plesk 2026, sappi che al momento le funzionalità NIS2 di Plesk (modalità NIS2, syslog dell’Action Log, MFA enforcement) sono un vantaggio competitivo rispetto ad alcune alternative open source che non offrono queste funzionalità out-of-the-box.
Per ottimizzare le performance del server mentre implementi queste misure di sicurezza aggiuntive, ti consiglio di leggere anche la mia guida su come ottimizzare PHP-FPM e OPcache su Plesk.
FAQ
La mia web agency è obbligata a conformarsi alla NIS2?
Dipende. Se la tua web agency fornisce servizi digitali (hosting, DNS, email) a enti classificati come essenziali o importanti nei 18 settori critici della NIS2, potresti rientrare come parte della supply chain. La NIS2 richiede esplicitamente la sicurezza della catena di approvvigionamento, quindi i tuoi clienti potrebbero chiederti di dimostrare misure di sicurezza adeguate. Consulta l’ACN o un legale specializzato per una valutazione specifica.
Quanto tempo devo conservare i log per essere conforme alla NIS2?
La direttiva non specifica un periodo esatto valido per tutti, ma alcune interpretazioni e linee guida indicano almeno 18 mesi. Nel mio caso, conservo i log sul server esterno per 24 mesi, gestendo lo spazio con logrotate e compressione. La raccomandazione è di conservarli per un periodo sufficiente a supportare eventuali indagini su incidenti.
Posso usare un servizio cloud come server di log esterno?
Sì, puoi utilizzare servizi come Loggly, Datadog, o un’istanza dedicata su AWS/Hetzner. L’importante è che il servizio garantisca l’integrità e l’immutabilità dei log, sia conforme al GDPR (i log contengono IP e dati di login), e che tu possa dimostrare la catena di custodia dei dati in caso di ispezione.
La modalità NIS2 di Plesk è sufficiente per la conformità?
No, da sola non basta. La modalità NIS2 di Plesk è un buon punto di partenza perché impedisce la disabilitazione del logging critico e la cancellazione degli eventi. Ma la conformità completa richiede anche l’invio dei log a un server esterno, l’enforcement della MFA, procedure documentate di gestione incidenti, e una governance della sicurezza ben definita a livello organizzativo.
Quali sanzioni rischio se non mi adeguo alla NIS2?
Le sanzioni per la non conformità possono arrivare fino a 10 milioni di euro o il 2% del fatturato globale annuo per le entità essenziali. A partire da ottobre 2026, l’ACN potrà avviare attività ispettive. Oltre alle sanzioni economiche, è prevista anche la responsabilità personale del management, con possibili sospensioni temporanee dalle funzioni dirigenziali nei casi più gravi.
Conclusione: La Conformità NIS2 su Plesk È un Percorso, Non un Interruttore
Rendere un server Plesk conforme alla Direttiva NIS2 non si risolve con una singola configurazione. È un percorso che coinvolge logging avanzato, invio dei log a server esterni, autenticazione multi-fattore obbligatoria, procedure di incident response documentate e una governance della sicurezza che parte dal management.
Nella mia esperienza, il lavoro più impegnativo non è stato tecnico ma organizzativo: creare la documentazione, formare il team, testare le procedure. Ma una volta implementato tutto, ho la tranquillità di sapere che i server che gestisco sono pronti sia per un’eventuale ispezione ACN sia, soprattutto, per rispondere in modo efficace a un vero incidente di sicurezza.
Se hai dubbi o vuoi condividere la tua esperienza con la conformità NIS2 su Plesk, lascia un commento qui sotto. E se gestisci una web agency, ti consiglio di iniziare oggi: le scadenze di ottobre 2026 sono più vicine di quanto pensi.