Come proteggere i trasferimenti di file e i dati in transito

Il Netwrix 2026 Data and Identity Security Report ha rilevato che il 69% delle organizzazioni non riesce a impedire istantaneamente e completamente che dati sensibili escano dagli endpoint verso strumenti esterni di IA, email personali o USB. Questa lacuna rende l'applicazione cross-channel un caso pratico per la consolidazione, poiché una singola policy consapevole del contenuto può coprire i percorsi di uscita che un protocollo di trasferimento sicuro non raggiunge mai.

Anche dopo che i team IT hanno implementato un server SSH File Transfer Protocol (SFTP) o uno strumento di condivisione approvato, un foglio di calcolo sensibile può comunque finire in una cartella cloud personale, come allegato email personale o in un prompt di chatbot.La ricerca di Harvard Business Review ha rilevato che i dipendenti spesso scelgono la via non autorizzata semplicemente perché quella approvata era più lenta o non sapevano che esistesse.

Questo crea due problemi distinti. La sicurezza del protocollo chiede se il canale autorizzato protegge i dati in transito. L'applicazione del trasferimento chiede se i dati sensibili utilizzano quel canale, e la maggior parte delle linee guida si ferma alla prima domanda. Insieme, questi controlli rafforzano la resilienza informatica e la postura di Data Security Posture Management, producendo prove affidabili per audit e indagini.

Cos'è il trasferimento sicuro di file?

Il trasferimento sicuro di file consiste nel muovere dati tra sistemi o persone in modo che rimangano illeggibili durante il transito, confermi chi li invia e li riceve, e lasci una traccia del trasferimento. NIST SP 800-53 Rev. 5 tratta crittografia, autenticazione e registrazione di audit come requisiti separati, quindi un protocollo da solo non può coprirli tutti. Proteggere i dati in movimento richiede tutti e tre, e ciascuno può fallire a modo suo.

Crittografia in transito

La crittografia dei dati in transito mantiene le informazioni illeggibili a chiunque le intercetti. Il National Cyber Security Center (NCSC) spiega nelle sue linee guida TLS che un Transport Layer Security (TLS) ben configurato impedisce a terzi di intercettare o manomettere i messaggi. Il NCSC raccomanda TLS 1.3 o 1.2, disabilitando le versioni 1.1 e 1.0. La configurazione è importante quanto il nome del protocollo, poiché un server che accetta ancora una vecchia versione può tornare a essa.

Autenticazione di entrambe le estremità

Un trasferimento sicuro verifica entrambe le parti prima che i dati vengano trasferiti. NIST definisce l'autenticazione reciproca come il processo in cui entrambe le entità in una transazione si verificano a vicenda, ma i protocolli comuni rendono opzionale la seconda parte. In TLS 1.3, il server si autentica sempre, mentre l'autenticazione del client è opzionale (RFC 8446). SFTP si basa su host keys for the server side, con il client che si autentica separatamente.

Una registrazione verificabile che è avvenuta

I log che mostrano cosa è stato spostato, quando e tra chi sono ciò di cui gli investigatori hanno bisogno in seguito. La violazione di MOVEit Transfer del 2023 illustra perché quel registro è importante anche su un canale crittografato. Secondo l'avviso di CISA sulla campagna, gli aggressori hanno sfruttato una vulnerabilità di injection SQL per bypassare completamente l'autenticazione, creare i propri account amministratore e distribuire una web shell che ha esfiltrato file.

La crittografia TLS ha protetto il canale durante tutto l’incidente. La vulnerabilità a livello applicativo ha invece compromesso l’autenticazione, motivo per cui crittografia, autenticazione e registrazione richiedono una validazione indipendente anziché un controllo che sostituisca gli altri due.

Quali sono i protocolli per il trasferimento sicuro dei file?

Il Protocollo di Trasferimento File semplice (FTP) e il Protocollo di Trasferimento Ipertestuale non crittografato (HTTP) sono le basi che i protocolli seguenti migliorano. FTP invia le password in chiaro tramite il comando PASSExpand (RFC 2577). La Cybersecurity and Infrastructure Security Agency (CISA) avverte nella sua Binding Operational Directive 18-01 che gli aggressori possono facilmente monitorare, modificare e impersonare le connessioni HTTP semplici.

SFTP (Protocollo di trasferimento file SSH)

SFTP è una scelta sensata per trasferimenti server-to-server e con partner. Esegue il trasferimento file all’interno di una sessione SSH, ereditando così la crittografia, l’autenticazione del server e la protezione dell’integrità dal trasporto SSH (RFC 4253). Una firma della chiave host autentica il server e l’utente si autentica con una chiave pubblica, password o metodo basato sull’host.

Tutto viaggia attraverso un unico tunnel multiplexato sulla porta 22, quindi SFTP necessita di meno aperture del firewall rispetto a FTPS. Per rafforzarlo, impostare StrictHostKeyChecking su yesExpand affinché i client rifiutino qualsiasi host la cui chiave sia cambiata.

Netwrix Endpoint Protector blocca il caricamento di dati sensibili su strumenti di IA attraverso endpoint e sessioni del browser, coprendo ciò che un server SFTP autorizzato non può vedere. Richiedi una demo.

FTPS (FTP su TLS/SSL)

FTPS incapsula FTP in TLS. Secondo RFC 4217, la sessione non è protetta finché il client non invia AUTH TLSExpand sulla connessione di controllo (porta 21) e il server si fida del client tramite certificati X.509. La modalità implicita sulla porta 990 è deprecata.

Il costo operativo è il canale dati separato, poiché la modalità passiva necessita di un intervallo di porte aperte e l'ispezione stateful del firewall non può leggere i comandi FTP crittografati. Questa complessità del firewall è uno dei motivi per cui i team scelgono comunemente SFTP per nuove implementazioni, anche se FTPS mantiene il suo posto quando i punti di accesso FTP esistenti e gli script dei partner devono essere aggiornati anziché riscritti.

Trasferimento basato su HTTPS

HTTPS, o HTTP su TLS, è il predefinito per caricamenti da browser, portali di download e trasferimenti API da app a app, tutti in esecuzione sulla porta 443. Il server è autenticato, l’intero scambio è criptato e il client verifica il nome host rispetto al certificato prima di fidarsi (RFC 9110, RFC 2818).

Per impostazione predefinita, HTTPS autentica solo il server; l'identità del caricatore deriva da un login o token separato che configuri e con cui effettui l'accesso separatamente. Per un caricamento tramite portale o API, il mittente controlla quel login, token o link a tempo limitato, quindi configurarlo con la stessa attenzione delle impostazioni TLS.

AS2 (Applicability Statement 2)

AS2 è progettato per transazioni business-to-business in cui entrambe le parti necessitano di una prova. Impacchetta formati di electronic data interchange (EDI), come X12 e Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), come Multipurpose Internet Mail Extensions (MIME) su HTTP (RFC 4130).

AS2 utilizza Secure/Multipurpose Internet Mail Extensions (S/MIME) per crittografia e firme e restituisce una Notifica di Disposizione del Messaggio firmata (MDN) come ricevuta. La chiave pubblica del partner verifica quell’MDN firmata, e un hash corrispondente fornisce la non ripudiabilità dell’origine e della ricezione tramite HTTP. Questo meccanismo è adatto per scambi B2B strutturati; la condivisione generale di file all’interno di un’organizzazione raramente ne ha bisogno.

Dove i dati sensibili vengono esposti quando si salta il canale sicuro

Ogni protocollo sopra protegge un canale, mentre le persone spesso spostano dati sensibili attraverso altri. La maggior parte di questi spostamenti deriva da dipendenti ordinari che scelgono una via più veloce piuttosto che da un'esfiltrazione intenzionale, il modello dietro la maggior parte degli insider threat incidenti.

Il Rapporto sulle Indagini sulle Violazioni dei Dati Verizon 2026 classifica shadow AI come la terza azione interna non dannosa più comune nel suo dataset DLP, con un aumento di quattro volte rispetto all'anno precedente. Questo schema corrisponde all'attrito operativo descritto in precedenza, poiché i percorsi approvati possono essere più lenti o semplicemente poco familiari.

Un account personale di archiviazione cloud

Un account personale di Dropbox o Google Drive è invisibile a un sistema progettato per monitorare solo il metodo di trasferimento approvato. Controllare quella via di uscita richiede qualcosa che possa distinguere un account organizzativo autorizzato da uno personale, non solo segnalare un dominio sconosciuto.

Un indirizzo email personale

Un allegato inviato a una casella personale bypassa completamente il sistema autorizzato, quindi una policy che copre solo quel sistema non lo vede mai. Anche le email possono fallire silenziosamente, poiché NCSC avverte che una negoziazione TLS fallita può far tornare il messaggio a una consegna in testo semplice.

Una chiavetta USB o un altro supporto rimovibile

I supporti rimovibili sfuggono a un programma che controlla solo i canali di rete perché una copia USB non genera traffico in uscita. L'auditing di Endpoint e device control devono coprire direttamente lo storage rimovibile.

La casella di input di uno strumento AI

Incollare il contenuto di un file in un chatbot è anche un trasferimento di file, e le vecchie linee guida sul trasferimento spesso non lo considerano.Il 2026 Verizon DBIR ha rilevato che il 67% degli utenti accede ai servizi AI con account non aziendali su dispositivi aziendali. Questo schema rende più pratico estendere una politica esistente consapevole del contenuto piuttosto che creare un programma di trasferimento AI separato.

Come trovare i canali non autorizzati e legacy già in uso

L'applicazione efficace inizia con un inventario dei canali che già trasportano dati, non con quelli che una policy presume siano in uso. La scoperta continua indirizza lo sforzo limitato verso ciò che le persone usano oggi.

Scansiona le regole del firewall e il traffico di rete per FTP legacy

Inizia con il firewall. SANS Internet Storm Center suggerisce di cercare log del firewall con grep /21 | grep -i permitExpand per evidenziare tutto ciò che è ancora consentito sulla porta di controllo FTP. I log del Domain Name System (DNS), o Sysmon Event ID 22, possono rivelare query verso il nome host di un vecchio file server. Per le attività pianificate che chiamano FTP, Get-ScheduledTaskExpand e Export-ScheduledTaskExpand mostrano la definizione di ogni attività, e l'Evento di Sicurezza di Windows 4698 si attiva per ogni nuova attività pianificata con il suo XML completo.

Leggi i log di uscita su proxy, firewall o CASB

Estrai un log di proxy web o firewall e controlla i domini di destinazione come dropbox.com e provider di webmail personali. Confronta ciò che trovi con le analisi di MITRE per T1567.002, che segnala processi insoliti che inviano dati a dropbox.com, drive.google.com e box.com.

Inserisci gli stessi log in un cloud access security broker (CASB) per creare un inventario shadow SaaS, a condizione che includano byte caricati, nomi utente e URL di destinazione. Per i supporti rimovibili, abilita Windows Security Event 6416 per rilevare nuovi dispositivi esterni e attiva Audit Removable Storage in modo che Event 4663 registra letture e scritture.

Integra il controllo negli strumenti già in uso, non come progetto autonomo

Integra questi controlli nel SIEM affinché nuovi strumenti e account non debbano aspettare un audit annuale. Una regola che si attiva al primo rilevamento di un dominio di destinazione o di un evento su supporti rimovibili segnala la modifica il giorno stesso in cui avviene.SigmaHQ pubblica regole per query DNS verso MEGA e altri siti di condivisione file, e una regola per dispositivi rimovibili visti per la prima volta può mappare direttamente la tecnica T1052.001.

Applicazione della policy al momento del trasferimento

Discovery mostra quali canali trasportano dati oggi. Con DLP consapevole del contenuto per il trasferimento di file, decidi cosa succede quando qualcuno tenta di spostare un file sensibile attraverso uno.

Scansione del contenuto prima che il trasferimento sia completato

I controlli basati sul canale verificano dove vanno i dati; i controlli consapevoli del contenuto verificano cosa sono.NIST SP 800-53 AC-4 copre il filtraggio sia delle informazioni dell’intestazione sia del contenuto del messaggio, consentendo a un sistema di bloccare, rimuovere, modificare o mettere in quarantena i dati quando un filtro fallisce. Esegui quell’ispezione sull’endpoint sia su file che su contenuti degli appunti, perché gli strumenti DLP per endpoint che analizzano solo i file salvati non rilevano il testo che un utente incolla ma non salva mai su disco.

Bloccare le destinazioni rischiose mantenendo attivi i trasferimenti legittimi

Bloccare tutto ciò che è sconosciuto genera soluzioni alternative, quindi invece mira a schemi rischiosi specifici, come dati regolamentati diretti a un account personale. Un sondaggio del 2025 di MIND and the Enterprise Strategy Group (ESG) ha rilevato che il 47% degli avvisi DLP ispezionati sono falsi positivi.

Crea regole di destinazione basate sul contesto dell’account, poiché un URL di ChatGPT serve sia account consumer che aziendali. Aiutano anche le azioni graduate, poiché un blocco con una giustificazione sovrascritta registra il motivo aziendale e mantiene il trasferimento su un percorso monitorato.

Una policy può esprimere direttamente quella decisione:

      IF content = regulated data AND account = personal
THEN block OR require justification override
      

Il principio di NIST di negare per default e consentire per eccezione (SC-7(5)) funziona quando l'elenco delle eccezioni riflette come le persone lavorano in pratica.

Estendere la stessa politica agli strumenti di IA

La regola che impedisce a una lista clienti di raggiungere un Google Drive personale dovrebbe anche impedirle di raggiungere la casella di prompt di Gemini. Una policy scritta solo per caricamenti di file e allegati non rileva il testo incollato nel campo prompt di un chatbot, che trasporta lo stesso contenuto sensibile attraverso un canale che la maggior parte delle configurazioni DLP non copre mai. Copri sia il testo digitato sia i file allegati, e tratta la casella di input di un chatbot come un ulteriore punto di uscita all’interno della stessa policy.

Mappatura dei controlli per il trasferimento sicuro dei file in base a ciò che si aspettano gli auditor

Gli auditor necessitano di prove, solitamente log, che dimostrino che un controllo è stato eseguito sui trasferimenti in ambito, e la sola disponibilità fornisce prove incomplete. Una politica coerente e consapevole del contenuto su tutti i canali offre inoltre ai team un unico modello di prova anziché un processo di raccolta separato per ogni percorso di uscita.

Secondo il Netwrix 2025 Cybersecurity Trends Report, il 43% delle organizzazioni ha sostenuto spese impreviste per affrontare carenze di sicurezza, quindi le prove di controllo riutilizzabili possono aiutare i team a evitare sorprese durante le verifiche e costi di rimedio reattivo.

PCI DSS: Crittografia dei dati del titolare della carta in transito

PCI DSS v4.x Requisito 4.2.1 richiede una crittografia forte per i numeri di conto primari (PAN) su reti pubbliche aperte. Ciò significa certificati affidabili e validi; versioni di protocollo sicure senza fallback; e almeno 112 bit di forza effettiva della chiave.

Gli valutatori esaminano le configurazioni di sistema, l'inventario di chiavi e certificati richiesto da 4.2.1.1 e le trasmissioni dei dati del titolare della carta mentre avvengono. Requisito 10 registra tutti gli accessi ai dati del titolare della carta, e i log di trasferimenti bloccati per email personale e USB possono integrare tali prove mostrando che un PAN è stato bloccato su un altro canale.

HIPAA: Lo standard di sicurezza per la trasmissione della Security Rule

Per le informazioni sanitarie elettroniche protette (ePHI), 45 CFR 164.312(e)(1) richiede alle entità regolamentate di proteggersi contro l'accesso non autorizzato a ePHI trasmessa su una rete elettronica. La crittografia ai sensi di (e)(2)(ii) è indirizzabile, il che significa che un'entità regolamentata la adotta quando una valutazione del rischio la ritiene ragionevole e appropriata, o documenta una misura equivalente.

L'Ufficio per i Diritti Civili esamina la politica di trasmissione, gli standard di crittografia, la gestione delle chiavi e la motivazione di eventuali carenze. I registri di ePHI bloccati dalla cloud personale e dalla webmail possono supportare tale decisione di rischio.

Una proposta di aggiornamento della Security Rule richiederebbe la crittografia di ePHI a riposo e in transito, con eccezioni limitate. HHS indica l'azione finale come una stima di pianificazione per luglio 2027.

GDPR: Misure tecniche appropriate dell'Articolo 32

Articolo 32(1) del GDPR richiede misure adeguate al rischio, inclusi test regolari della loro efficacia. L'Ufficio del Commissario per l'Informazione del Regno Unito (ICO) accetta TLS 1.2 o 1.3 correttamente configurati, rifiuta SSL completamente e si aspetta una politica di crittografia, documentazione sulla gestione delle chiavi e risultati dei test affinché i titolari possano dimostrare le azioni intraprese per conformarsi.

La sanzione dell'ICO del 2026 contro Police Scotland ha citato la procedura interna della forza che richiede la crittografia dei media in transito. I registri di crittografia dei media rimovibili dimostrano tale procedura nella pratica.

CMMC: Riservatezza della trasmissione per CUI

NIST SP 800-171 Rev. 2 il controllo 3.13.8 richiede meccanismi crittografici che impediscano la divulgazione non autorizzata di Controlled Unclassified Information (CUI) durante la trasmissione. Il controllo 3.13.11 richiede crittografia convalidata da Federal Information Processing Standards (FIPS). SP 800-171A richiede agli valutatori di esaminare il piano di sicurezza e le configurazioni, rivedere i log di audit, intervistare gli amministratori e testare direttamente i meccanismi.

La Cybersecurity Maturity Model Certification (CMMC) Guida alla Valutazione del Livello 2 chiarisce che utilizzare solo un algoritmo approvato non è sufficiente. Si richiede la crittografia CUI supportata da politiche e meccanismi di applicazione, citando un proxy che blocca il traffico non conforme. Un singolo obiettivo non raggiunto fa fallire l'intero requisito. All'endpoint, i log di trasferimenti bloccati e i record di crittografia USB mostrano lo stesso tipo di applicazione.

Come Netwrix supporta il trasferimento sicuro dei file nella pratica

Netwrix Endpoint Protector è un prodotto DLP per endpoint che blocca il caricamento di dati sensibili, controlla i supporti rimovibili e applica politiche consapevoli del contenuto su endpoint Windows, macOS e Linux. Copre i percorsi di uscita che un canale di trasferimento autorizzato non raggiunge.

Scansione dei trasferimenti per contenuti sensibili prima che vengano completati

Il modulo Content Aware Protection di Netwrix Endpoint Protector ispeziona i dati nei punti di uscita, inclusi browser, client di posta elettronica, webmail, client di sincronizzazione cloud e appunti. Il suo controllo degli appunti elimina i contenuti riservati quando vengono copiati, impedendone l’incolla. I log si esportano in Excel, PDF o CSV e vengono inoltrati a un SIEM tramite syslog.

Applicazione automatica della crittografia sui supporti rimovibili

Il modulo Enforced Encryption di Netwrix Endpoint Protector applica la crittografia USB convalidata FIPS 140-3 con cancellazione remota e reset della password. Il deployment è automatico una volta che una policy consente un dispositivo USB al Trusted Device Level 1 o superiore. Device Control copre lo storage USB e più di 45 classi di periferiche, anche offline. Enforced Encryption funziona solo su Windows e macOS; le policy di Device Control proteggono invece gli endpoint Linux.

NHS South East Coast Ambulance Service ha implementato Netwrix Endpoint Protector per soddisfare i requisiti del Data Security and Protection Toolkit (DSPT) relativi ai dispositivi che oltre 4.000 dipendenti utilizzano nella regione. Secondo Stewart Edwards, responsabile della sicurezza IT del trust, il rollout ha dato al team il controllo completo sulle porte USB e sui dispositivi, applicando la crittografia richiesta dal loro framework di conformità.

Blocco dei caricamenti sensibili agli strumenti di IA

Netwrix Endpoint Protector estende le stesse policy consapevoli del contenuto agli strumenti AI, coprendo ChatGPT, Microsoft Copilot, Google Gemini, Claude, DeepSeek, X AI Grok e altri strumenti elencati. La copertura si applica sia quando un utente digita contenuti sensibili sia quando li allega come file, e gli amministratori possono monitorare o bloccare tali contenuti prima che raggiungano un fornitore non approvato.

Colmare la distanza tra politica e pratica

Una decisione sicura per il trasferimento dei file deve considerare la protezione del canale, la visibilità delle vie di bypass, l’applicazione sugli endpoint e prove di audit coerenti. I team di sicurezza possono stabilire una baseline estraendo un mese di log proxy per domini cloud personali e webmail, verificando lo storage rimovibile su un campione di endpoint e controllando quali domini AI risolvono gli utenti.

Questi risultati mostrano dove dare priorità all'applicazione e applicare la stessa politica consapevole del contenuto al momento del trasferimento.

Richiedi una demo per vedere come Netwrix aiuta le organizzazioni a rafforzare la loro postura di sicurezza dei dati estendendo la visibilità e i controlli degli endpoint lungo i percorsi sensibili di trasferimento dati.