Vai al contenuto
← Idee

Esportare dati da un SaaS: ambito, autorizzazioni e controlli per farlo in sicurezza

Un’esportazione utile parte dalla definizione dei dati da includere, di chi può richiederla e di come proteggere il file. Questa guida offre criteri pratici per progettarla.

Progettazione di un’esportazione di dati SaaS con autorizzazioni, ambito limitato e controlli di accesso

Consentire a un cliente di scaricare i propri dati può rispondere a esigenze quotidiane di analisi, riconciliazione o lavoro al di fuori dell’applicazione. Tuttavia, un’esportazione crea anche una copia che potrebbe non essere più soggetta ai controlli abituali del SaaS. Progettarla bene significa decidere quali dati includere, chi può richiederla, chi riceve il risultato e per quanto tempo resta accessibile.

La questione non riguarda soltanto il formato da offrire. I team di prodotto, business e tecnologia devono concordare lo scopo di ogni esportazione e definire controlli proporzionati alla sensibilità e al volume delle informazioni. Di seguito proponiamo un quadro per prendere queste decisioni senza confondere un download operativo con altri processi.

Definire il problema a cui risponde l’esportazione

Definire il problema a cui risponde l’esportazione

Un’esportazione operativa consente di consultare o riutilizzare dati specifici nelle attività abituali. Per esempio, un team potrebbe aver bisogno di un elenco filtrato per preparare una revisione o di un file con i movimenti di un determinato periodo per riconciliarli. L’ambito dovrebbe corrispondere a un’attività concreta e rimanere il più circoscritto possibile.

Non è la stessa cosa di un report, di un backup o di un’estrazione per la migrazione a un altro sistema. Un report presenta i dati per rispondere a domande, spesso con aggregazioni o visualizzazioni. Un backup è pensato per il ripristino e richiede controlli e procedure specifici. Un’estrazione per la migrazione può comprendere un ampio insieme di entità e relazioni da trasferire in un altro ambiente. Se un’esigenza self-service inizia ad assomigliare a un’estrazione completa, è opportuno trattarla come un flusso distinto, con valutazioni, autorizzazioni e supporto adeguati al suo impatto.

Prima di progettare l’interfaccia, documenta il caso d’uso, gli utenti coinvolti e la decisione che il file consentirà di prendere. Se non è possibile spiegare perché serve ciascun gruppo di dati, è un segnale per rivedere l’ambito, non per aggiungere altri campi per impostazione predefinita.

Circoscrivere dati, filtri e relazioni

Definisci con precisione quali entità esportare, quali filtri applicare e come rappresentare le relazioni. Per esempio, un download degli ordini potrebbe richiedere identificativi e date, ma non necessariamente note interne o dati di altri ambiti. Occorre anche chiarire se vengono mantenuti i filtri della schermata, se l’utente può scegliere un periodo e che cosa accade ai record archiviati o eliminati.

  • Includi ciò che serve per l’attività: evita i campi che non apportano valore all’uso dichiarato.
  • Rendi visibili i limiti: comunica il periodo, i filtri, il fuso orario e i criteri che determinano i dati esportati.
  • Definisci le relazioni: chiarisci se i dati associati vengono inclusi, omessi o rappresentati tramite identificativi.
  • Evita sorprese: distingui chiaramente tra la vista corrente, un insieme filtrato e un’esportazione completa.

Anche l’esclusione di alcuni campi richiede una decisione esplicita. Può essere opportuno non includere segreti, credenziali, informazioni interne o dati di cui il richiedente non ha bisogno per lo scopo previsto. Non presumere che nascondere una colonna nell’interfaccia la escluda automaticamente dal file: le autorizzazioni devono essere applicate ai dati generati.

Assegnare le autorizzazioni a chi richiede e a chi riceve il file

L’autorizzazione a visualizzare informazioni nell’applicazione non comporta sempre il permesso di estrarle in blocco. Definisci chi può avviare un’esportazione in base all’organizzazione, al ruolo e alla sensibilità dei dati. Per le informazioni con un impatto maggiore potrebbe essere necessaria una specifica autorizzazione, un’approvazione aggiuntiva o una limitazione a determinati ruoli. La scelta dipende dal contesto: aggiungere passaggi a tutti i download può ostacolare usi legittimi senza migliorare necessariamente la protezione.

Valuta separatamente chi richiede il file e chi potrà riceverlo. In un download diretto, di solito si tratta della stessa persona. Se il destinatario è diverso, occorre verificare che appartenga all’ambito autorizzato e che il file non sia accessibile a utenti estranei all’organizzazione. Evita di inviare automaticamente dati sensibili a un indirizzo inserito senza verificarlo.

Prima della conferma, l’interfaccia dovrebbe spiegare l’ambito dell’operazione e indicare chiaramente quando il file sarà pronto. Se l’azione può riguardare molti record, una conferma con il riepilogo del periodo o del numero di elementi può aiutare a individuare eventuali errori, purché queste informazioni non siano esposte a chi non ha l’autorizzazione necessaria.

Scegliere tra download immediato e generazione asincrona

Il download immediato è semplice quando l’insieme di dati è ridotto e può essere preparato senza bloccare l’applicazione o esaurire le risorse. Quando aumentano il volume o i tempi di elaborazione, può essere più adatta una generazione asincrona: l’utente richiede l’operazione, riceve un aggiornamento sullo stato e scarica il risultato quando è pronto.

Non esiste una soglia universale valida per tutti i SaaS. Valuta le dimensioni abituali delle richieste, la durata osservata, il carico sul sistema e le aspettative degli utenti. Se una richiesta impiega abbastanza tempo da lasciare la pagina in attesa, termina con errori o compete con operazioni importanti, potrebbe essere necessario cambiare flusso o restringere la query.

  • Per le richieste piccole e prevedibili, privilegia una risposta diretta e comprensibile.
  • Per le operazioni prolungate, mostra stati come in attesa, in elaborazione, pronta o non riuscita e spiega qual è il passaggio successivo.
  • Evita di avviare operazioni duplicate quando si aggiorna la pagina o si fa clic più volte; fornisci un riferimento all’operazione in corso.
  • Stabilisci limiti ragionevoli e mostra un messaggio utile quando la richiesta li supera, per esempio suggerendo di suddividerla per periodi.

L’elaborazione asincrona non elimina la necessità di controllare l’accesso. Per consultare lo stato e ottenere il risultato, l’utente deve autenticarsi; inoltre, quando necessario, il sistema deve verificare di nuovo che sia ancora autorizzato.

Proteggere il file e ridurre i rischi

Il risultato richiede controlli specifici: può contenere una concentrazione di informazioni che non compare tutta insieme in una singola schermata. Utilizza un archivio temporaneo con accesso limitato e definisci una scadenza adeguata all’uso previsto. Comunica quando il file non sarà più disponibile ed evita di conservarne copie più a lungo del necessario per completare l’attività.

È preferibile richiedere l’autenticazione e verificare le autorizzazioni in relazione all’organizzazione. Se usi link per il download, trattali come credenziali: limita la loro durata, evita che rivelino informazioni sensibili e valuta il rischio che vengano inoltrati. Un link difficile da indovinare non sostituisce, da solo, un’autorizzazione adeguata. È inoltre opportuno non esporre nomi di file o messaggi di errore che rivelino dati non necessari.

Definisci limiti che riducano errori accidentali e abusi senza impedire il normale svolgimento delle attività. A seconda del caso, possono includere un numero massimo di record, la frequenza delle richieste, il numero di operazioni simultanee o la suddivisione per periodi. Se gli utenti con esigenze legittime non riescono a completare le attività abituali, il controllo potrebbe essere troppo restrittivo. Se è troppo permissivo, potrebbero verificarsi volumi insoliti, tentativi ripetuti o estrazioni estranee al comportamento atteso. Rivedi i limiti sulla base dei dati operativi e dei riscontri degli utenti, non di valori arbitrari.

Registrare, convalidare e approvare prima del rilascio

Registrare, convalidare e approvare prima del rilascio

Registra informazioni sufficienti a indagare eventuali problemi: chi ha richiesto l’esportazione, a quale organizzazione appartiene, quando è stata avviata, quale ambito o quali filtri sono stati applicati e se l’operazione è terminata con successo o con un errore. Evita di inserire nei log il contenuto del file o dati sensibili non necessari. La tracciabilità deve consentire di ricostruire l’operazione senza diventare un’ulteriore copia dei dati.

Verifica anche che il file sia utilizzabile. Convalida il formato offerto, la codifica del testo, le intestazioni, i nomi dei campi, i valori vuoti e la coerenza delle relazioni. Un file generato correttamente dal punto di vista tecnico, ma ambiguo, può causare errori di interpretazione e richieste di assistenza. Spiega quali formati sono disponibili e indica eventuali limiti rilevanti; non dare per scontato che tutti gli utenti apriranno il risultato con lo stesso strumento.

Prima del rilascio, rivedi questa lista insieme ai team di prodotto e tecnologia e alle persone responsabili dell’accesso alle informazioni:

  • Lo scopo è documentato e distinto da report, backup e migrazioni?
  • Sono state definite entità, filtri, relazioni e campi da escludere?
  • Vengono verificati l’organizzazione, il ruolo e, quando serve, l’autorizzazione specifica?
  • È chiaro chi richiede il file e chi lo riceve?
  • L’esperienza e i limiti sono adeguati alle dimensioni e alla durata previste?
  • Il file ha accesso controllato, una scadenza e una politica di eliminazione?
  • Richieste, risultati ed errori vengono registrati con un livello di tracciabilità proporzionato?
  • Sono stati testati autorizzazioni, casi limite, formati e messaggi di errore?

Una funzione di esportazione ben progettata rende espliciti i propri limiti e permette di svolgere attività legittime senza aprire un percorso di accesso più ampio del necessario. Se il caso d’uso richiede dati completi, relazioni complesse o la consegna a terzi, la scelta corretta potrebbe essere creare un processo separato, invece di estendere un download operativo fino a trasformarlo in un’estrazione priva di controlli adeguati.

Fuentes y referencias

  1. MDN Web DocsMozilla
  2. Web performanceweb.dev
  3. OWASP Cheat Sheet SeriesOWASP Foundation