Come accedere in modo sicuro a file da remoto? Il metodo software meno rischioso per evitare compromissioni

Chi deve lavorare da casa o in viaggio, chi gestisce una PMI, chi amministra uffici decentrati: tutti, negli ultimi mesi, hanno cercato un modo affidabile per consultare documenti aziendali a distanza senza correre rischi. Dove? Ovunque serva continuità operativa. Quando? In piena stagione di attacchi mirati e phishing evoluto. Perché? Per evitare compromissioni, blocchi e sanzioni. Come? Puntando su un metodo che riduca al minimo la superficie d’attacco e lasci tracce chiare per gli audit.

Il punto non è soltanto “riuscire a entrare”, ma farlo in modo che un errore umano non spalanchi le porte all’intruso. Nel mio lavoro di sviluppatore e consulente, nato tra corsie di magazzino e software su misura, ho imparato che il canale più sicuro è quello che espone meno, controlla di più e si configura una volta sola, bene.

Il rischio reale: porte esposte e VPN tradizionali

I numeri parlano chiaro: le scansioni automatiche su Internet cercano porte note per colpire protocolli remoti, dagli RDP aperti ai file server raggiungibili fuori rete. Una semplice svista nel port forwarding di un router domestico può trasformarsi in un invito a nozze per gli attaccanti.

Le VPN classiche migliorano la situazione, ma non sono una bacchetta magica. Portano l’utente “dentro” la rete, spesso con privilegi eccessivi, e se le credenziali finiscono in phishing o si riutilizzano password deboli, il movimento laterale diventa probabile. «Il problema non è solo l’accesso iniziale, ma tutto ciò che l’intruso può vedere una volta dentro», osserva un analista di sicurezza presso un SOC italiano.

Il metodo meno rischioso: SFTP su SSH dentro una rete zero trust

Fra le opzioni disponibili, il metodo software che riduce di più la superficie d’attacco per accedere ai file è usare SFTP via SSH incapsulato in un accesso di tipo Zero trust. In pratica, si combina un protocollo maturo e minimale (SFTP) con un modello che non espone porte su Internet e concede permessi per singola app/utente, “verificando sempre” e “fidandosi mai”.

Nel dettaglio, si allestisce un server con SSH configurato per fornire esclusivamente SFTP, senza shell interattiva, con chiavi crittografiche al posto delle password e, idealmente, un secondo fattore d’autenticazione. L’accesso avviene attraverso un broker zero trust o una rete overlay point-to-point, così da non pubblicare nulla sul perimetro: niente port forwarding, niente IP pubblico da scansionare.

Perché è meno rischioso?

• Riduce l’esposizione: il servizio non è visibile su Internet aperto.
• Restringe la funzione: solo trasferimento file, niente comandi o desktop remoto.
• Rafforza l’identità: chiavi, policy per dispositivo, MFA e autorizzazioni per utente.
• Rende gli audit più semplici: log granulari su chi accede, quando e a cosa.

Come configurarlo passo per passo

La buona notizia è che si può fare con strumenti gratuiti o già disponibili nel sistema.

• 1) Preparare il server: su Linux e macOS, OpenSSH è spesso preinstallato; su Windows, attivare il componente “OpenSSH Server”. Creare un account di servizio dedicato ai file, separato dagli amministratori.
• 2) Chiavi robuste: generare una coppia ED25519 con passphrase. Conservare la chiave privata nel portachiavi del sistema o, meglio, su una chiave di sicurezza compatibile FIDO2. Caricare la chiave pubblica nell’utente server.
• 3) Solo SFTP, niente shell: in sshd_config, impostare “PasswordAuthentication no”, “Subsystem sftp internal-sftp” e applicare “ForceCommand internal-sftp”. Abilitare un chroot sull’home dell’utente o su una directory dati, in sola lettura se necessario. Separare cartelle per team e progetto.
• 4) Secondo fattore: valutare MFA via hardware key o OTP abbinato alle chiavi, in base al sistema operativo. Dove possibile, limitare l’accesso a dispositivi conformi (disco cifrato, antivirus attivo, OS aggiornato).
• 5) Niente porte pubbliche: pubblicare l’accesso tramite una soluzione zero trust o una rete overlay che crea canali cifrati end-to-end tra client autorizzati e server. Definire ACL che permettono solo SFTP verso quell’host, non l’intera LAN.
• 6) Logging e backup: attivare log dettagliati di connessioni e trasferimenti, con retention coerente con la policy aziendale. Testare il ripristino dei backup: un file “raggiungibile” ma non recuperabile è un falso senso di sicurezza.

In ambienti con più utenti, un “bastion” SSH intermedio semplifica controllo e revoche. Ogni team ottiene chiavi nominali, scadenze e permessi minimi. In caso di incidente, si revoca la chiave compromessa senza bloccare il resto.

Alternative: quando hanno senso

Non esiste una ricetta unica. Alcune alternative possono essere più adatte a specifici scenari:

• Sincronizzazione end-to-end: per piccoli gruppi e cartelle limitate, una soluzione di sincronizzazione con cifratura client-side evita canali remoti persistenti. Pro: praticità. Contro: governance e versioning da curare con attenzione.
• Condivisione temporanea: link usa-e-getta con scadenza e protezione, utili per file singoli destinati a clienti o fornitori. Ridurre la durata e limitare i download.
• Desktop virtuale/VDI: utile quando i dati non devono mai uscire dal perimetro logico: l’utente lavora su un ambiente centrale e i file non toccano i device personali. Maggiori costi, ma controllo totale.
• VPN moderna segmentata: se serve l’accesso a più servizi legacy, una VPN con segmentazione stretta, policy per applicazione e MFA può andare, purché si eviti l’accesso “full LAN”.

Checklist rapida e buone pratiche

• Principio del minimo privilegio: accesso solo alle cartelle necessarie, in lettura quando basta.
• Aggiornamenti: sistema operativo e SSH sempre patchati; cifratura a riposo sul server.
• Identità forte: chiavi ED25519 con passphrase, MFA, revoche rapide e rotazione periodica (ad es. 90 giorni per utenze sensibili).
• Convalida host: fissare l’impronta della chiave host e verificare i cambi per evitare man-in-the-middle.
• Dispositivi conformi: cifratura disco, blocco schermo, antivirus/EDR, niente account condivisi.
• Telemetria e alert: avvisi su tentativi falliti ripetuti, upload/download anomali, accessi fuori orario.
• Piano B: backup immutabili, versioning e test di ripristino trimestrali.

La sintesi è semplice: meno si espone, meglio è. Un canale SFTP su SSH, incapsulato in accesso zero trust, con chiavi e MFA, offre un equilibrio virtuoso tra usabilità e rischio contenuto. È il tipo di soluzione che piace anche a chi, come me, ha iniziato ottimizzando magazzini: fa una cosa sola, la fa bene e lascia log chiari. Per chi deve accedere ai file da remoto oggi, è il punto di partenza più prudente.