Il panorama delle minacce
Gli strumenti di desktop remoto sono obiettivi di alto valore per gli attaccanti. Chi prende il controllo di una sessione remota ha:
- Accesso a tutto ciò che l'utente loggato all'host può vedere + fare
- Possibilità di installare malware
- Possibilità di muoversi lateralmente nella rete
Gli attacchi più frequenti nel 2025/2026:
- Credential stuffing sul portale web dell'editore
- Phishing per ID sessione + PIN (spesso via tech-support scam)
- Furto di token su un dispositivo compromesso
- Man-in-the-middle in caso di configurazione TLS debole
Sette livelli che un buon strumento deve avere
1. Cifratura end-to-end per sessione
Ogni sessione riceve una chiave AES-256 effimera via ECDH (P-256). La chiave viene eliminata al termine della sessione. Nemmeno l'editore può decifrare le sessioni a posteriori, anche se costretto.
2. Token dispositivo legati all'hardware
Il token che autentica il dispositivo presso l'editore deve essere cifrato hardware:
- Windows: TPM 2.0
- macOS Apple Silicon: Secure Enclave
- Linux: TPM 2.0 + tpm2-tools
Un file di token rubato su un'altra macchina è inutilizzabile.
3. Autenticazione multi-fattore per gli account
TOTP (app authenticator) o passkey (FIDO2/WebAuthn) devono essere obbligatori per i ruoli admin, raccomandati per tutti. Niente password da sola.
4. Autenticazione fresca per azioni sensibili
Revocare un dispositivo, cambiare ruolo, annullare l'abbonamento → re-conferma password o passkey con finestra di freschezza breve (es. 10 min). Impedisce che una sessione compromessa esegua queste azioni inosservata.
5. Audit trail di default
Registro di connessioni, abbinamenti e modifiche di permessi, filtrabile per host e periodo. In caso di sospetto incidente: ricostruzione forense possibile.
6. Indicatori anti-tech-scam
Un indicatore sempre visibile sull'host che mostra che una sessione è attiva, con la possibilità di terminarla da lì. Impedisce che l'utente finale « dimentichi » la sessione mentre l'attaccante la mantiene in background.
7. Rate-limiting sull'ID sessione
In caso di brute-force su ID + PIN: dopo X tentativi falliti l'ID viene invalidato, deve essere generata una nuova sessione. Impedisce agli attaccanti di esaurire il PIN a 6 cifre.
Checklist setup pratico per fornitori IT
□ Piano Pro sottoscritto (audit trail attivato)
□ Ruolo Admin: 2FA obbligatorio (passkey preferito)
□ Ruoli Supporter: 2FA raccomandato, notifica login via e-mail
□ Ruolo sola lettura per junior senza diritti di intervento
□ Token hardware attivati su ogni host
□ Cronologia sessioni controllata settimanalmente (anomalie?)
□ DPA standard firmato con ogni cliente
□ Procedura d'emergenza documentata: token compromesso → revoca → nuovo
□ Metodo MFA di backup configurato (codici di recupero fisici sicuri)
A cosa fare attenzione presso un editore
- L'editore può vedere le chiavi? End-to-end = no.
- Dove sono i server? Ideale: Svizzera/UE.
- Quali certificazioni di conformità? Audit è un plus, ISO 27001 ideale.
- Come funziona il miglioramento incrementale? Bug bounty? Politica di disclosure CVE? Avvisi di sicurezza?
- Cosa succede in caso di insolvenza dell'editore? Puoi continuare ad accedere, o i dati spariscono?
Concretamente in WinDesk
- AES-256-GCM + ECDH P-256 per sessione
- Login dell'host legato al chip di sicurezza, dove presente (TPM su Windows e Linux, Secure Enclave su Mac)
- 2FA obbligatorio per admin, supporto passkey per tutti
- Azioni sensibili: re-auth freschezza 10 min
- Registro delle attività di default
- Anti-scam: finché qualcuno è connesso, l'host mostra sul bordo dello schermo l'indicazione «Supporto remoto attivo» con la durata della connessione (comprimibile, non nascondibile)
- Nessun audit di sicurezza esterno e nessun penetration test — lo diciamo apertamente invece di indicare una data
- Bug report a security@windesk.ch; politica CVE onesta