Crittografia lato client vs lato server per i caricamenti

Perché le scelte di crittografia contano per i documenti caricati

Se la tua app permette alle persone di caricare file, non stai solo memorizzando “documenti”. Spesso stai conservando una seconda identità dell'utente: contratti firmati, foto di passaporti o patenti, moduli medici e referti di laboratorio. I file sono piccoli. Il rischio collegato non lo è.

Un contratto trapelato può innescare conseguenze legali e finanziarie: prezzi che diventano pubblici, firme copiate e controversie che si aggravano rapidamente. Una scansione di un documento d'identità rubata può portare al furto d'identità e al takeover di account. Documenti medici possono esporre informazioni sanitarie private che le persone non si aspettavano di condividere oltre un piccolo gruppo. Un errore può danneggiare la fiducia per anni.

I team spesso dicono “archiviazione criptata” intendendo cose diverse. A volte significano che la connessione di upload è cifrata (HTTPS). A volte intendono che il file è cifrato su disco (crittografia a riposo). A volte intendono che il file è cifrato prima di lasciare il dispositivo dell'utente, quindi il server non vede mai il testo in chiaro (crittografia lato client). Queste non sono intercambiabili. Proteggono contro guasti diversi.

Le scelte di sicurezza modellano anche l'usabilità quotidiana e il supporto. Più privacy può significare più attrito: passaggi extra per visualizzare un file, condivisione più difficile, ricerca e anteprime limitate e recupero complicato quando qualcuno perde un dispositivo o una chiave. Un accesso più semplice può abilitare indicizzazione, scansione antivirus, anteprime e reset password, ma aumenta anche ciò che il tuo server (e chiunque lo comprometta) può vedere.

Immagina una piccola clinica che carica tessere assicurative e PDF medici. Lo staff ha bisogno di trovare il file giusto rapidamente, ma la clinica vuole anche ridurre i danni se un account amministratore viene violato. Il modello “giusto” dipende da quale fallimento farebbe più male e quale inconveniente gli utenti tollereranno.

Definizioni rapide: crittografia lato client vs lato server

La domanda pratica è semplice: quando il file è cifrato e chi può decifrarlo in seguito?

Crittografia lato server significa che il file arriva al tuo backend in forma leggibile e il tuo server lo cifra prima di salvarlo. Questa è la crittografia a riposo: se qualcuno ruba un disco o ottiene accesso grezzo a un bucket di storage, vede dati illeggibili. Il tuo server può comunque decifrare il file quando necessario.

Crittografia lato client significa che il file viene cifrato sul dispositivo dell'utente (browser o mobile) prima dell'upload. Il tuo server memorizza solo il testo cifrato. In condizioni normali, il server non può leggere il documento a meno che non abbia anche accesso alla chiave di decrittazione.

La proprietà delle chiavi è la vera linea di demarcazione:

• Con la crittografia lato server, le chiavi sono gestite dal tuo backend (spesso via un servizio di gestione chiavi) e il backend decripta i file per gli utenti autorizzati.
• Con la crittografia lato client, le chiavi sono controllate dall'utente, dal suo dispositivo o da un segreto detenuto dal client, e il backend si limita a far rispettare regole di storage e accesso.

In entrambi i modelli servono comunque autenticazione e permessi. La crittografia non sostituisce il controllo degli accessi.

La gente usa anche “end-to-end encryption” per indicare: il file è cifrato sul dispositivo del mittente, resta cifrato sul server e viene decriptato solo sul dispositivo del destinatario approvato. Questo può migliorare la riservatezza, ma rende anteprime lato server, ricerca full-text, scansione antivirus e recupero facile molto più difficili a meno che tu non sia disposto a cambiare il modello di minaccia.

Modelli di minaccia: cosa stai cercando davvero di fermare

La crittografia aiuta solo quando sei chiaro sui rischi che vuoi ridurre. “Nessuno tranne l'utente previsto può leggere il file” porta a scelte diverse rispetto a “ridurre i danni se lo storage viene leakato”.

Minacce comuni per le app che memorizzano contratti, documenti d'identità o documenti medici includono:

• Password rubate o riutilizzate (account takeover)
• Accesso interno più ampio del dovuto (supporto, amministratori, contractor)
• Account cloud compromesso o bucket di storage mal configurato
• Un bug o una perdita che espone database o backup
• Malware sul dispositivo dell'utente

Aiuta anche separare dove può avvenire l'esposizione:

• In transito: il file mentre si muove dal dispositivo al server
• A riposo: object storage, righe di database, backup, log
• Durante la visualizzazione/elaborazione: anteprime, OCR, ricerca, conversioni

Ecco la differenza fondamentale. Con la crittografia lato server, il tuo sistema può decriptare, quindi può mostrare anteprime, scansionare e indicizzare. Con la crittografia lato client, il server memorizza il testo cifrato e non può leggere il contenuto senza chiavi detenute dall'utente. Questo di solito riduce il raggio d'azione di compromessi del server e accessi interni.

La crittografia non ferma tutto. Se un dispositivo è infetto, il malware può prendere il file prima della cifratura o dopo la decrittazione. Se qualcuno può visualizzare un documento, può comunque fare uno screenshot, ricondividerlo o stamparlo.

Cosa protegge ciascun modello (e cosa no)

Un modo utile per confrontare questi approcci è chiedersi: chi può vedere il file in testo leggibile in qualsiasi momento? Questa risposta definisce l'impatto di una violazione, il rischio interno e la sicurezza dei backup.

Con crittografia lato server, una breccia sul server può ancora esporre molto. Il backend di solito ha accesso alle chiavi di decrittazione (o può richiederle) perché deve generare anteprime, eseguire controlli antivirus, supportare la ricerca o gestire la condivisione. Nel peggiore dei casi, un attaccante che ottiene sia i dati memorizzati sia l'accesso alle chiavi può decriptare tutto.

Con crittografia lato client, un attaccante che compromette la tua infrastruttura tipicamente ruba blob cifrati. Senza chiavi detenute dagli utenti, quei blob sono molto meno utili.

L'accesso interno è dove la differenza diventa più visibile. Con la crittografia lato server, un dipendente privilegiato, un amministratore cloud o un account di supporto compromesso può spesso accedere ai documenti impersonando l'app o interrogando lo storage. Con la crittografia lato client, la tua infrastruttura può memorizzare e spostare file, ma non può leggerli a meno che non vengano fornite le chiavi.

La crittografia lato client non risolve un dispositivo compromesso. Per caricamenti ad alto rischio come ID e PDF medici, la sicurezza del dispositivo e la protezione dell'account sono importanti quanto la crittografia dello storage.

Fai attenzione anche alle perdite fuori dallo “store di file”. Molti incidenti avvengono tramite:

• Backup e snapshot che catturano file decriptati o chiavi
• Log che registrano nomi file, metadati o testo estratto
• Miniature, anteprime e indici di ricerca
• Esportazioni verso email, chat o strumenti ticketing
• File temporanei creati durante l'upload o la conversione

Compromessi UX che gli utenti notano subito

La differenza principale non è la matematica. È ciò che gli utenti possono fare facilmente e cosa diventa difficile.

La crittografia lato server spesso è invisibile. Gli utenti fanno il login, caricano e vedono anteprime immediatamente. Il supporto può resettare accessi. Gli amministratori possono di solito riassegnare permessi quando qualcuno è assente.

La crittografia lato client cambia onboarding e lavoro quotidiano. Gli utenti possono avere bisogno di una passphrase più forte, una chiave locale memorizzata su un dispositivo o un passaggio di sblocco aggiuntivo. Cambiare dispositivo, cancellare il browser o reinstallare un'app può interrompere l'accesso a meno che non sia previsto un backup e recupero delle chiavi.

Il recupero account è dove i team si sorprendono. Se solo l'utente detiene la chiave di decrittazione, “ho dimenticato la password” può trasformarsi in “accesso perso”. Puoi aggiungere una chiave di recupero o un flusso di deposito (escrow), ma devi essere onesto su cosa implica e spiegarlo chiaramente.

La condivisione diventa anche più complicata. Con la crittografia lato server, condividere è per lo più una questione di permessi. Con la crittografia lato client, la condivisione spesso comporta anche la condivisione di chiavi, insieme a domande su revoca e cosa succede alle copie vecchie.

Funzionalità come ricerca e comodità possono forzare la decrittazione da qualche parte. Ricerca full-text, anteprime e OCR sono più semplici quando il server può leggere il file. Se vuoi privacy in stile end-to-end, potresti dover usare OCR lato client, indicizzazione locale o ricerca limitata (per esempio solo nomi file e tag).

Esempio: una clinica carica PDF di referti e vuole OCR per trovare i nomi dei pazienti all'interno delle scansioni. La crittografia lato server supporta OCR e ricerca veloci. La crittografia lato client sposta quel lavoro sui dispositivi degli utenti, che può essere più lento e difficile da supportare su web e mobile.

Esigenze specifiche per tipo di documento: contratti, documenti d'identità e cartelle cliniche

La scelta migliore dipende meno dal tipo di file e più dal flusso di lavoro: chi deve leggerlo, quanto veloce, quanto spesso e per quanto tempo.

Contratti

I contratti spesso coinvolgono revisione, modifiche, approvazioni e tracce di audit. I team vogliono anche ricerca affidabile, condivisione e regole di conservazione.

Se la tua app supporta la revisione collaborativa all'interno del prodotto, la crittografia lato server è spesso il default pratico perché il sistema può generare anteprime, eseguire ricerche e applicare l'accesso basato sui ruoli senza chiedere agli utenti di gestire chiavi.

La crittografia lato client può essere adatta se l'app è per lo più una cassaforte, per esempio conservare PDF firmati finali per un piccolo gruppo dirigente. Il compromesso è una comodità integrata più debole a meno che non aggiungi strumenti lato client.

Documenti d'identità (passaporti, patenti)

Gli ID sono ad alto rischio ma spesso a breve termine. Molte organizzazioni li conservano solo il tempo necessario per verificare una persona, poi li eliminano. Il flusso richiede visualizzazione rapida e gestione rigorosa, non collaborazione.

Un approccio comune è la crittografia lato server unita a controllo accessi rigoroso, forti log di audit e conservazione breve. La crittografia lato client può essere appropriata se il personale di supporto non deve mai poter vedere gli ID, ma in quel caso serve un altro modo per completare la verifica.

Documenti medici

I record medici hanno aspettative di riservatezza più stringenti. Gli utenti spesso si aspettano che solo il minimo necessario di persone possa accedervi.

La crittografia lato client può ridurre l'esposizione se il server viene violato o l'accesso amministrativo viene abusato. Ma può anche creare problemi UX e operativi reali: reset password, cambi dispositivo e accesso di emergenza diventano complicati.

Prima di scegliere, mappa ogni tipo di documento al flusso di lavoro:

• Chi deve leggerlo (e da dove)
• Quanto velocemente deve aprirsi
• Quanto tempo lo conservi
• Quali funzionalità prodotto sono importanti (anteprima, ricerca, eliminazione automatica)

Come scegliere: un processo decisionale passo passo

Inizia scrivendo cosa memorizzi e chi lo tocca. Una cartella chiamata “uploads” non è una policy.

Passo 1: mappa gli accessi, non solo “utenti”

Elenca i ruoli e rispondi a due domande: chi deve poter aprire il file e chi non deve mai poterlo aprire (inclusi gli amministratori)? Includi la conservazione mentre sei lì.

Passo 2: scegli le tue assunzioni sulle minacce

Sii diretto su cosa stai difendendo.

• Se il rischio interno è una preoccupazione primaria, la crittografia lato client diventa più attraente.
• Se la perdita di dispositivo e i reset password sono comuni, pagherai in complessità di recupero.

Poi metti alla prova l'esperienza:

1. Recupero e supporto: Cosa succede quando qualcuno dimentica la password o perde il telefono? Se devi recuperare l'accesso, la crittografia lato client pura potrebbe non andare bene.

2. Funzionalità indispensabili: Ti servono anteprime, ricerca, OCR, firma elettronica o elaborazione via API? Molte di queste sono più semplici con la decrittazione lato server da qualche parte nel flusso.

3. Audit e compliance: Hai bisogno di log chiari su chi ha visto cosa e quando? Entrambi i modelli possono loggare accessi, ma i design lato client richiedono cura extra per evitare risultati “non possiamo aiutarti”.

La maggior parte dei team finisce con un ibrido: crittografia lato server per la maggior parte dei documenti e crittografia lato client per un piccolo insieme di caricamenti “mai visibili allo staff”.

Errori comuni e trappole da evitare

La trappola più grande è trattare la crittografia come tutta la soluzione. Privacy e conformità dipendono anche da chi può accedere ai dati, come si approva l'accesso, cosa viene registrato, per quanto tempo i file vengono conservati e come si gestiscono le richieste di cancellazione.

Un secondo errore è costruire la crittografia lato client senza un piano di recupero. Se un utente perde un dispositivo, dimentica una passphrase o lascia l'azienda, puoi ripristinare l'accesso senza violare la promessa di sicurezza? “Non possiamo aiutarti” può andare bene per una cassaforte personale, ma di solito fallisce nelle app aziendali.

Questi errori causano veri leak e soluzioni alternative:

• Dare agli amministratori un percorso nascosto per “vedere tutto”, o permettere al supporto di impersonare utenti, senza log rigorosi e approvazioni secondarie.
• Decriptare nel browser o nell'app e lasciare copie residue (anteprime in cache, download temporanei, cartelle sincronizzate).
• Inviare documenti “sicuri” attraverso canali insicuri dopo (inviare PDF via email, incollare screenshot in chat, allegare file ai ticket).
• Rendere il flusso sicuro così complicato che gli utenti passano a drive personali o scattano foto dello schermo.
• Assumere che “crittografato a riposo” soddisfi automaticamente consenso, storico accessi, conservazione e requisiti di notifica delle violazioni.

Esempio: una clinica cifra i moduli di accettazione, poi il personale esporta un report di fatturazione che crea una cartella locale non cifrata. Quella cartella viene salvata nel backup su un drive condiviso. La perdita avviene nel flusso di lavoro, non nel cripto.

Checklist rapida prima di decidere

Scrivi una frase chiara: chi dovrebbe poter leggere questi file e chi non dovrebbe mai poterlo fare, anche se qualcuno ottiene accesso ai tuoi server.

Poi controlla:

• Chi può decriptare e quando? Elenca ruoli e condizioni esatte. Se la tua policy dice “solo chi carica”, non aggiungere silenziosamente una backdoor con chiavi condivise.
• Puoi revocare l'accesso rapidamente? L'offboarding è il test reale. Decidi se l'accesso è legato a un account, un dispositivo o un gruppo.
• Cosa succede dopo la perdita del dispositivo o i reset password? Se hai bisogno di recupero, proteggilo con approvazioni forti.
• Ti servono anteprime, scansione antivirus o OCR? Se sì, pianifica dove avviene la decrittazione e chi può avviarla.
• I tuoi log di audit sono sufficientemente dettagliati? Definisci cosa conta come “visualizzato” rispetto a “scaricato” e registra utente, orario, dispositivo e motivo.

Scenario esempio: un piccolo team che conserva ID e PDF medici

Una piccola clinica ha un'app dove lo staff carica referral dei pazienti (PDF) e foto di tessere assicurative. L'obiettivo è smistare rapidamente i documenti alle persone giuste, riducendo al contempo i danni da dispositivi persi, account compromessi o errori cloud.

Un approccio praticabile è la crittografia lato server con ruoli rigorosi. I file sono cifrati a riposo e l'accesso è controllato da permessi: il front desk può caricare, la fatturazione può vedere gli ID e i clinici possono vedere i referral. Questo è più semplice nella pratica quotidiana perché il personale può aprire documenti su desktop o mobile senza passaggi extra e i supervisori possono riassegnare accessi durante le assenze.

Un altro approccio usa la crittografia lato client per gli elementi più sensibili. Il file viene cifrato sul dispositivo prima dell'upload, così il server memorizza solo il ciphertext. Questo può ridurre l'impatto di una breccia server e dell'accesso interno, ma cambia le operazioni:

• I reset password possono ripristinare l'accesso normalmente con la crittografia lato server; con la crittografia lato client, i reset possono bloccare gli utenti a meno che le chiavi non siano state salvate in modo sicuro.
• Il turnover del personale è più semplice con la crittografia lato server; con la crittografia lato client serve un piano per trasferire o depositare le chiavi così che i documenti restino accessibili.

Gli utenti percepiscono attriti per la condivisione, l'accesso mobile e il recupero dopo la perdita del telefono. Questi dettagli contano tanto quanto il modello di crittografia.

Prossimi passi: decidere, documentare la policy e implementare

Inizia scrivendo le tue assunzioni sulle minacce in linguaggio chiaro. Scegli l'approccio più semplice che soddisfa il tuo rischio, poi rinforzalo solo dove i documenti lo giustificano.

Metti la decisione in una breve regola interna che le persone possano seguire:

• Quali tipi di file sono consentiti e dove possono essere conservati
• Chi può accedervi e condividerli, e come si approva l'accesso
• Regole di conservazione e cancellazione
• Come funziona il recupero dopo reset password e perdita del dispositivo
• Come vengono gestite le esportazioni (download, email, messaggistica) e quando sono bloccate

Poi progetta l'implementazione intorno a quelle regole: controlli sui ruoli, azioni auditate (visualizza, scarica, condividi), anteprime sicure e gestione attenta delle chiavi.

Se costruisci su una piattaforma no-code come AppMaster, aiuta modellare ruoli e flussi di approvazione presto, poi adattarli man mano che i requisiti cambiano senza riscrivere l'app. La parte importante è rendere la via sicura la via facile per gli utenti reali.