Sì — il desktop remoto è sicuro quando lo strumento usa la crittografia end-to-end e connessioni peer-to-peer dirette; è rischioso quando si appoggia a una porta esposta o a un protocollo legacy non cifrato. Stai dando a un software il controllo completo del tuo computer, quindi merita più di una promessa su una pagina di marketing. Ecco la mappa delle minacce, le quattro difese che contano e sette risposte chiare alle domande che le persone fanno davvero.
La matrice delle minacce
La maggior parte degli articoli sulla sicurezza si apre con rassicurazioni vaghe. Noi apriamo con la superficie di attacco reale. Sono gli otto modi realistici in cui una sessione di desktop remoto può essere compromessa nel 2026, cosa fa Remio per ciascuno e cosa dovresti fare tu per il resto.
| Minaccia | Livello di rischio | Come si difende Remio | Cosa dovresti fare |
|---|---|---|---|
| Intercettazione di reteTHR-01 | ALTO | Crittografia end-to-end DTLS-SRTP su ogni pacchetto; le chiavi sono generate su ciascun endpoint e mai inviate a un server. | Evita il Wi-Fi pubblico per RDP semplice. Le app moderne con E2EE rendono questa minaccia già mitigata. |
| Man in the middleTHR-02 | ALTO | L'impronta del certificato DTLS viene scambiata su un canale autenticato del server di connessione; entrambi gli endpoint la verificano prima che passi qualsiasi contenuto multimediale. | Associa solo con un codice QR o un PIN che leggi dallo schermo del tuo host e rimuovi ogni dispositivo che non riconosci. |
| Furto di credenzialiTHR-03 | ALTO | Nessun account, nessuna email, nessuna password. L'associazione usa un codice QR oppure un ID dispositivo e un PIN, con un nuovo PIN quando vuoi. | Se il tuo strumento remoto richiede una password, usa un gestore di password e credenziali uniche per ogni servizio. |
| Dirottamento della sessioneTHR-04 | MEDIO | I token di sessione sono legati alla connessione DTLS e non possono essere riutilizzati. | Termina le sessioni in modo esplicito quando hai finito. Non lasciare un host incustodito con una connessione attiva. |
| Forza bruta su una porta in ascoltoTHR-05 | ALTO | Remio non richiede alcuna porta aperta da parte tua: entrambe le estremità si connettono verso l'esterno, quindi gli scanner di porte normalmente non trovano alcun servizio in ascolto da attaccare. Mac Host 3.3 può chiedere a un router che lo consente di aprire una porta per una sessione (attivo per impostazione predefinita, e opzionale). | Non esporre mai la porta RDP 3389 a internet. Mettile davanti almeno WireGuard o Tailscale. |
| Violazione del fornitore (supply chain)THR-06 | ALTO | Il nostro server di connessione vede solo ID dispositivo anonimi e metadati di handshake cifrati. Una compromissione totale del server non rivela alcun contenuto di sessione. | Prima di installare qualsiasi strumento remoto, cerca il nome del fornitore insieme alla parola violazione e leggi le comunicazioni degli ultimi due anni. |
| Minaccia interna al fornitoreTHR-07 | MEDIO | Le chiavi dei contenuti multimediali non raggiungono mai l'infrastruttura di Remio. Un dipendente infedele non può decifrare una sessione nemmeno con pieno accesso al server. | Per i carichi di lavoro regolamentati, preferisci i fornitori che pubblicano ogni anno un report SOC 2 Type II con ambito sulla gestione delle chiavi. |
| Firewall configurato maleTHR-08 | BASSO | Il design solo in uscita fa sì che un firewall configurato male fallisca chiudendo, non aprendo. La sessione semplicemente non si connette. | Controlla le regole del firewall in ingresso ogni trimestre. Blocca la porta 3389 in uscita sul perimetro a meno che non ti serva specificamente RDP. |
Da questa mappa emergono tre cose. Primo, ogni minaccia ad ALTO rischio contro un moderno desktop remoto con E2EE è già affrontata a livello di protocollo, non dalla disciplina dell'utente. Secondo, la peggiore superficie di attacco nella storia del desktop remoto resta Microsoft RDP esposto sulla porta 3389. Terzo, il fornitore stesso è il più grande rischio residuo in qualsiasi prodotto con relay nel cloud, perché una singola violazione colpisce tutti i clienti insieme.
Lo stack di difesa a quattro livelli
Se la matrice delle minacce è ciò che vedono gli attaccanti, lo stack di difesa è ciò che attraversano i tuoi pacchetti in uscita. Remio sovrappone quattro protezioni indipendenti. Ciascuna sarebbe utile da sola; insieme lasciano pochissimo da afferrare a un attaccante.
DTLS negozia un canale autenticato prima che qualsiasi pacchetto multimediale lasci il tuo dispositivo. SRTP poi cifra e autentica ogni frame video e ogni evento di input, con chiavi generate direttamente tra i tuoi due dispositivi — il tuo schermo non tocca mai i nostri server. Vedi RFC 5764.
Il nostro server di connessione usa TLS 1.3 e trasporta solo materiale di handshake opaco: indirizzi di connessione da provare, impronte DTLS e ID dispositivo effimeri. Il contenuto della sessione non attraversa mai il server di connessione. Vedi draft-ietf-rtcweb-security-arch.
Nessun account, nessuna email, nessuna password. L'associazione usa un codice QR oppure un ID dispositivo e un PIN, con un nuovo PIN quando vuoi, con limitazione dei tentativi da parte dell'host. Non c'è un database di credenziali da rubare perché non ci sono credenziali.
I frame vengono decodificati direttamente nella GPU e mai scritti su disco. I percorsi di appunti, trasferimento file e audio usano lo stesso canale DTLS-SRTP del video, quindi il livello dei dati eredita automaticamente le garanzie del livello di trasporto.
Il punto dello stack è l'indipendenza. Se un futuro bug rompe un livello, il successivo regge ancora. Se domani cambiassimo fornitore di relay, il livello dell'identità non ne risentirebbe. Se una vulnerabilità zero-day di TLS 1.3 colpisse il server di connessione, il canale multimediale DTLS-SRTP userebbe comunque chiavi con forward secrecy che non hanno mai toccato il percorso del server di connessione.
Microsoft RDP, l'elefante nella stanza
Se cerchi la sicurezza del desktop remoto, la maggior parte dei risultati riguarda Microsoft RDP. C'è un motivo. RDP è stato progettato nel 1998 per reti aziendali interne. Esporlo direttamente a internet sulla porta 3389 è il maggior fattore abilitante del ransomware dell'ultimo decennio.
Scanner automatici girano di continuo su tutto lo spazio IPv4 in cerca della porta 3389. Quando ne trovano una, provano le mille password più comuni. Se entrano, il ransomware viene distribuito nel giro di ore. Più report di threat intelligence attribuiscono a RDP esposto oltre il 60 percento degli incidenti di accesso iniziale del ransomware nel 2025.
Esporre RDP sulla porta 3389 è l'equivalente, in termini di sicurezza, di lasciare aperta la porta di casa con un cartello che elenca cosa c'è dentro.
La soluzione non è sottile. Non esporre mai RDP a internet. Fallo passare in un tunnel WireGuard, Tailscale o una VPN aziendale. Meglio ancora, usa un'app di desktop remoto costruita apposta che gestisce la rete solo in uscita, così non c'è alcuna porta in ascolto da attaccare in primo luogo.
Quando il fornitore subisce una violazione
Non sono scenari ipotetici. Sono accaduti negli ultimi due anni.
AnyDesk, febbraio 2024. AnyDesk ha confermato che degli attaccanti hanno compromesso i sistemi di produzione, esfiltrato il codice sorgente e rubato certificati di firma del codice. L'azienda ha revocato ogni certificato e imposto un azzeramento globale delle password. La violazione è rimasta non rilevata per settimane prima della comunicazione. Qualsiasi binario di AnyDesk scaricato in quella finestra poteva potenzialmente essere stato falsificato da attaccanti in possesso delle chiavi di firma originali.
TeamViewer, giugno 2024. TeamViewer ha comunicato che APT29, il gruppo sostenuto dallo Stato russo dietro l'attacco a SolarWinds, ha violato la loro rete aziendale. TeamViewer ha sostenuto che la violazione era limitata all'IT interno, ma APT29 di solito non se ne va a mani vuote. Il fatto che uno degli attori statali più sofisticati abbia preso di mira un fornitore di desktop remoto è già di per sé la notizia.
Lo schema è strutturale. Un fornitore di desktop remoto centralizzato custodisce credenziali, token di sessione e infrastruttura di instradamento per milioni di macchine. Violi il fornitore, erediti le chiavi. È l'attacco alla supply chain da manuale. L'unica architettura difendibile è quella in cui il fornitore non può aiutare un attaccante nemmeno se completamente compromesso, perché il fornitore non detiene in primo luogo alcuna chiave in grado di decifrare le sessioni.
Una checklist pratica
Indipendentemente dal prodotto che scegli, queste dieci pratiche riducono il rischio di un ordine di grandezza.
- Usa un'app di desktop remoto con crittografia end-to-end. RDP semplice esposto a internet non è accettabile nel 2026.
- Preferisci le connessioni peer-to-peer. Meno intermediari significano una superficie di attacco più piccola e latenza più bassa.
- Attiva l'autenticazione a più fattori su qualsiasi account che tocchi il tuo strumento remoto, compreso il sistema operativo stesso.
- Tieni aggiornati il software host e client. Per la maggior parte delle CVE una patch è disponibile prima che vengano sfruttate su larga scala.
- Non riutilizzare mai le password tra fornitori di desktop remoto. Password uniche contengono il raggio d'azione di qualsiasi singola violazione.
- Scegli PIN e password robusti. Un PIN di sei cifre dà un milione di combinazioni; ogni cifra in più le moltiplica per dieci.
- Disattiva l'accesso remoto quando non lo usi. La superficie di attacco più piccola è quella spenta.
- Controlla ogni settimana i dispositivi collegati. Rimuovi tutto ciò che non riconosci. La maggior parte degli strumenti remoti lo registra.
- Non installare mai software di desktop remoto da un link in un'email. Scaricalo sempre direttamente dal dominio del fornitore.
- Cerca il nome del fornitore e la parola violazione prima di installare. Se gli ultimi due anni hanno comunicazioni, tienine conto.
Domande comuni, con risposta
Le stesse domande tornano in ogni conversazione sulla sicurezza del desktop remoto. Ecco le risposte dirette.
Gli hacker possono accedere al tuo computer tramite desktop remoto?
Sì, se esponi Microsoft RDP sulla porta 3389 direttamente a internet senza una VPN o un gateway zero-trust. RDP esposto è stato il vettore di accesso iniziale in oltre il 60 percento degli incidenti ransomware segnalati nel 2025. Un'app moderna di desktop remoto che usa una connessione peer-to-peer cifrata end-to-end non è vulnerabile a questa classe di attacco, perché nessuna porta in ascolto è esposta agli scanner.
Il traffico del desktop remoto è cifrato?
Dipende dall'app. Microsoft RDP usa TLS 1.2 per impostazione predefinita e può essere configurato per richiedere TLS 1.3. App come Remio usano DTLS-SRTP per cifrare end-to-end ogni pacchetto video e di input, con chiavi negoziate direttamente tra i tuoi dispositivi. Le app con relay nel cloud di solito cifrano in transito ma detengono loro stesse le chiavi, il che significa che il fornitore, o chiunque lo violi, può decifrare la tua sessione.
Serve una VPN per il desktop remoto?
Se usi Microsoft RDP, sì. Fai sempre passare RDP in un tunnel WireGuard, Tailscale o una VPN aziendale. Se usi un'app moderna di desktop remoto con crittografia end-to-end, la connessione è già cifrata a entrambe le estremità e una VPN aggiunge latenza senza aggiungere sicurezza. Una VPN può comunque servire per conformità, mascheramento dell'IP o restrizioni geografiche, ma non rafforza una sessione già cifrata.
Qual è la differenza tra desktop remoto peer-to-peer e con relay nel cloud?
Le connessioni peer-to-peer scorrono direttamente tra i tuoi due dispositivi. Il server di connessione li aiuta soltanto a scoprirsi. Dopo di che nessuna terza parte vede il tuo traffico. Le app con relay nel cloud fanno passare ogni frame video e ogni battuta di tasto dal data center del fornitore. Il fornitore può tecnicamente ispezionare la tua sessione, e una singola violazione del fornitore espone tutte le sessioni attive insieme. Remio si connette direttamente per impostazione predefinita e usa un relay cifrato solo quando la tua rete lo impone — e anche allora il relay inoltra testo cifrato che non può leggere.
Qual è il protocollo di desktop remoto più sicuro nel 2026?
Uno stack basato sulla crittografia DTLS-SRTP, con generazione delle chiavi end-to-end sui dispositivi client, è l'opzione mainstream più solida. Combina l'autenticazione per pacchetto con uno scambio di chiavi con forward secrecy e non richiede che alcuna porta in ingresso venga aperta sulla macchina host. Le specifiche rilevanti sono RFC 5764 e draft-ietf-rtcweb-security-arch.
Come capisco se un'app di desktop remoto è cifrata end-to-end?
Leggi il whitepaper sulla sicurezza. Se il fornitore non sa dirti quali chiavi sono generate sul dispositivo e quali sono custodite lato server, l'app non è cifrata end-to-end. Una vera app E2EE dichiarerà che le chiavi dei contenuti multimediali non lasciano mai gli endpoint e che una compromissione del server non può decifrare sessioni passate o future. AnyDesk, TeamViewer e Chrome Remote Desktop non sono cifrati end-to-end per impostazione predefinita.
Devo disattivare il desktop remoto quando non lo uso?
Sì. La superficie di attacco più piccola è quella spenta. Se la tua app host supporta un'uscita per inattività o una modalità di non ascolto, attivala. Per Microsoft RDP, disattiva del tutto il servizio nelle impostazioni di Windows quando non sei reperibile. Riattivalo solo per il tempo in cui ti serve l'accesso.
Perché abbiamo costruito Remio così
Il principio di progetto è semplice. Remio non dovrebbe aver bisogno di essere considerato affidabile. La matrice delle minacce qui sopra non funziona come elenco di marketing se la tua sicurezza dipende dalla promessa di un fornitore di comportarsi bene. Funziona solo se il fornitore non può aiutare un attaccante nemmeno volendo, perché non detiene le chiavi.
Per questo l'associazione è un codice QR oppure un ID dispositivo e un PIN che controlli tu invece di un account. Per questo le chiavi dei contenuti multimediali vengono generate sui tuoi due dispositivi e non vengono mai inviate altrove. Per questo il server di connessione vede solo materiale di handshake opaco. Se la nostra infrastruttura fosse completamente compromessa domani, un attaccante erediterebbe un elenco di ID dispositivo anonimi che una volta hanno tentato di associarsi tra loro. Nessuna password. Nessuna registrazione di sessione. Nessun contenuto dello schermo. Niente di utile.
Per tutti i dettagli del protocollo, leggi il nostro whitepaper sulla sicurezza. Per vedere come questa architettura si confronta con i principali concorrenti storici, la guida onesta alle app di desktop remoto per Mac passa in rassegna un fornitore alla volta.
Ultimo aggiornamento 2026-05-20. Il panorama della sicurezza cambia in fretta; rivediamo questa guida man mano che arrivano nuove comunicazioni e aggiornamenti dei protocolli.
