In breve: l'autenticazione a due fattori per gli accessi admin fa sì che una password rubata o indovinata da sola non basti. Deve valere ovunque qualcuno possa modificare il Suo sito o il Suo server: CMS, hosting, pannello, SSH, dominio, DNS e le caselle degli admin. Altrettanto importanti dell'impostazione sono i codici di emergenza e una regola chiara su chi ha per cosa un accesso personale.
Perché le sole password non bastano per gli admin
Le password si perdono in molti modi: tramite e-mail di phishing, malware su un computer di lavoro, fughe di dati presso altri servizi o semplicemente per riutilizzo. Gli attacchi automatizzati provano senza sosta credenziali rubate contro pagine di login note.
Con un secondo fattore un aggressore ha bisogno in più di qualcosa che possiede solo l'utente autorizzato, ad esempio uno smartphone con app di autenticazione o una chiave di sicurezza. Ciò alza notevolmente l'ostacolo, soprattutto per gli account con diritti estesi.
Per la direzione è importante una distinzione: l'autenticazione a due fattori protegge gli accessi, non il software che sta dietro. Una vulnerabilità come PHP2Shell, che consente l'esecuzione di codice senza autenticazione, non viene chiusa in questo modo. Le due cose vanno insieme: software aggiornato e accessi ben protetti.
Quali metodi a due fattori sono adatti
I metodi differiscono per sicurezza e comodità d'uso. Per gli account admin dovrebbe usare almeno app di autenticazione, per gli accessi particolarmente critici chiavi di sicurezza o passkey.
| Metodo | Protezione dal phishing | Idoneità per gli admin |
|---|---|---|
| Codice SMS | bassa | solo come soluzione transitoria |
| App di autenticazione (TOTP) | media | buono standard |
| Conferma push | media, vulnerabile agli attacchi per stanchezza | adatta con confronto del numero |
| Chiave di sicurezza o passkey (FIDO2/WebAuthn) | alta | raccomandata per gli accessi critici |
| Chiave SSH con passphrase | alta | standard per gli accessi al server |
I codici monouso di un'app possono essere intercettati su una pagina di phishing ingannevolmente realistica e riutilizzati subito. I metodi FIDO2 verificano invece l'indirizzo della pagina e su una pagina falsa non funzionano. Per questo sono la scelta migliore per gli admin con accesso a molti sistemi.
Autenticazione a due fattori per gli accessi admin: l'elenco completo
Gli aggressori cercano l'accesso più debole. Passi quindi in rassegna tutti i punti in cui qualcuno può modificare il Suo sito, il Suo server o il Suo dominio:
- CMS e backend dello shop: WordPress, Shopware, TYPO3 e altri offrono l'autenticazione a due fattori nel core o tramite estensioni mantenute. Quale variante sia raccomandata è indicato nella documentazione del produttore.
- Account cliente dell'hosting: chi entra qui può spesso reimpostare password, scaricare backup o reinstallare il server.
- Pannello del server come Plesk o cPanel, se presente.
- SSH e SFTP: chiavi invece di password, vedi la sezione successiva.
- Registrar del dominio e DNS: un'impostazione DNS modificata reindirizza visitatori ed e-mail senza che il server sia coinvolto.
- Caselle e-mail degli admin: passano da lì i ripristini delle password per quasi tutti gli altri servizi.
- Repository del codice e deployment: chi può scrivere lì può rilasciare codice dannoso.
- CDN, WAF, Google Search Console e fornitori di pagamento.
Per ogni voce stabilisca chi ha accesso, se il secondo fattore è attivo e dove si trovano i codici di ripristino. Questo elenco è al tempo stesso una parte importante del Suo piano di emergenza, perché dopo un incidente proprio questi accessi devono essere verificati e rinnovati in breve tempo.
SSH: chiavi invece di password
Per gli accessi al server il login con chiave SSH è la consueta protezione forte. La chiave privata si trova sul dispositivo dell'admin ed è protetta da una passphrase; per i server particolarmente sensibili può trovarsi su una chiave hardware. Quando il login con chiave è configurato e provato per tutti gli admin, disattivi l'accesso con password:
# /etc/ssh/sshd_config (estratto)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Verificare la configurazione prima di ricaricare il servizio
sshd -t && systemctl reload ssh # sui sistemi RHEL: sshd
Durante il passaggio lasci aperta una sessione esistente e provi l'accesso in una seconda finestra. Così, in caso di errore, non si blocca da solo. Ogni admin riceve una chiave propria; le chiavi condivise per un intero team non si possono revocare in modo pulito quando singole persone se ne vanno. Ulteriori basi sono descritte in Mettere in sicurezza da soli root server e vServer.
Accesso di emergenza e codici di ripristino
Una buona introduzione pianifica anche il guasto. Gli smartphone si perdono, i collaboratori lasciano l'azienda, le chiavi di sicurezza si rompono. Senza un piano, nel momento sbagliato nessuno ha un accesso disponibile.
Registri per ogni account critico due fattori, ad esempio una chiave di sicurezza in ufficio e un'app di autenticazione, e conservi i codici di ripristino separatamente dalla password.
Altre regole che si sono dimostrate valide:
- Account personali invece di login admin condivisi, in modo che le modifiche siano tracciabili.
- Un accesso di emergenza documentato, con credenziali conservate separatamente, il cui uso salti all'occhio e venga registrato.
- Quando collaboratori o fornitori di servizi se ne vanno, revocare lo stesso giorno tutti gli accessi e le chiavi.
- Dopo un incidente di sicurezza verificare non solo le password, ma anche i fattori registrati e le sessioni attive.
Per l'introduzione nel team si è dimostrato valido un percorso chiaro. Inizi dagli account che possono causare il danno maggiore: hosting, dominio, DNS e le caselle e-mail degli admin. Seguono poi server, CMS e servizi. Fissi una data da cui gli accessi senza secondo fattore non sono più possibili e si assicuri prima che tutti gli interessati siano configurati.
Spieghi brevemente al team perché il passaggio è necessario e come funziona nella quotidianità. Una guida di una pagina con schermate riduce nettamente le domande. I fornitori di servizi esterni e le agenzie dovrebbero ricevere accessi propri e personali con secondo fattore invece di un login condiviso, in modo che gli accessi restino attribuibili e si possano revocare in modo pulito a fine progetto.
Come proteggere ulteriormente le pagine di login dai tentativi automatizzati è spiegato nella guida Proteggere i login admin dal brute force.
Come aiuta concretamente PHP SOS?
- Redigiamo con Lei un elenco completo di tutti gli accessi admin e mostriamo dove manca il secondo fattore.
- Portiamo gli accessi al server a chiavi SSH e disattiviamo in modo controllato i login con password nell'ambito dell'hardening del server.
- Documentiamo gli accessi di emergenza e le vie di ripristino in modo che funzionino nel momento critico.
- Nel contratto di manutenzione della sicurezza verifichiamo regolarmente gli accessi e rimuoviamo gli account orfani.
Domande frequenti
Quale metodo a due fattori è il più sicuro?
Le chiavi di sicurezza hardware e le passkey secondo lo standard FIDO2 sono considerate particolarmente resistenti al phishing, perché sono legate all'indirizzo reale. Le app di autenticazione con codici monouso sono un buono standard. L'SMS è meglio di niente, ma è la variante più debole.
Che cosa succede se si perde lo smartphone con l'app di autenticazione?
Per questo esistono i codici di ripristino, che vengono mostrati durante la configurazione. Vanno conservati in modo sicuro, ad esempio in cassaforte o in un gestore di password protetto. Inoltre almeno un secondo admin dovrebbe poter reimpostare l'accesso.
L'autenticazione a due fattori protegge anche da PHP2Shell?
No. PHP2Shell consente l'esecuzione di codice senza autenticazione, il login non viene nemmeno usato. Contro PHP2Shell aiuta solo l'aggiornamento a una versione corretta di PHP con riavvio di tutti i worker. L'autenticazione a due fattori protegge da password rubate o indovinate.
Basta l'autenticazione a due fattori nel CMS?
No, un aggressore sceglie l'accesso più debole. Account di hosting, pannello del server, SSH, gestione del dominio, DNS e le caselle e-mail degli admin devono essere protetti allo stesso modo, altrimenti la protezione del CMS si può aggirare.