Architettura e sicurezza SaaS: dal modello delle minacce al ripristino

Disegnare i confini di fiducia

Il modello delle minacce segue i dati: ingresso dal browser, passaggio nei servizi applicativi, accesso al database, esportazioni, notifiche e collegamenti a sistemi esterni. Per ogni passaggio si domanda chi può inviare una richiesta, quale identità viene riconosciuta e quali controlli impediscono un uso improprio. Un file caricato da un utente e una risposta ricevuta da un partner sono entrambi ingressi da validare, anche se arrivano attraverso canali abituali.

È utile lavorare su scenari di abuso concreti. Un operatore prova a leggere un allegato di un'altra azienda; una credenziale di integrazione viene usata da un dispositivo estraneo; un'esportazione troppo ampia espone campi non necessari. Questi scenari portano a requisiti verificabili e aiutano a stabilire priorità. Il risultato non è un documento da archiviare: va rivisto quando si aggiungono funzioni, ruoli e dipendenze.

Isolamento dei clienti e accesso agli oggetti

In un sistema che serve più organizzazioni, il contesto aziendale deve accompagnare ogni operazione autorizzata. Non basta nascondere un collegamento nell'interfaccia. Il servizio che restituisce un documento deve verificare che quel documento appartenga al perimetro accessibile all'identità corrente. La stessa regola si applica a download, ricerche, esportazioni, elaborazioni differite e strumenti di supporto. Un filtro presente nelle schermate ma assente in un processo batch lascia un confine incompleto.

Le scelte di separazione fisica o logica dei dati hanno costi e conseguenze differenti. Occorre valutarle insieme a gestione delle connessioni, backup, migrazioni e interventi di assistenza. Qualunque sia il modello, il collaudo deve includere tentativi di accesso trasversale, variazioni degli identificativi e controlli sui campi restituiti. Il progetto OWASP API Security richiama proprio la necessità di verificare le autorizzazioni sugli oggetti esposti dai servizi.

Identità, privilegi e account tecnici

Autenticazione e autorizzazione risolvono problemi diversi: la prima identifica il soggetto, la seconda determina ciò che può fare. I ruoli devono corrispondere ad attività comprensibili, con permessi sufficientemente precisi da separare consultazione, modifica, approvazione ed esportazione. Le operazioni più delicate richiedono controlli aggiuntivi proporzionati al contesto. Anche le sessioni hanno un ciclo di vita: scadenza, revoca e chiusura dopo cambiamenti rilevanti dell'account.

Gli account usati dalle integrazioni meritano una gestione dedicata. Una chiave tecnica non dovrebbe ereditare tutti i privilegi di un amministratore per comodità. Si definiscono ambito, proprietario, scadenza o rotazione, ambienti consentiti e procedura di revoca. Quando una persona cambia ruolo, le automazioni non devono dipendere da credenziali personali dimenticate. L'inventario delle identità tecniche è un documento operativo, da mantenere insieme all'inventario delle integrazioni.

Proteggere i dati lungo tutto il percorso

La protezione del canale è necessaria, ma non risolve da sola il problema della diffusione dei dati. Una richiesta può viaggiare cifrata e produrre comunque un file accessibile al destinatario sbagliato. Si devono seguire anche copie temporanee, allegati, notifiche, cache e ambienti di prova. Dove bastano identificativi o dati sintetici, replicare archivi completi aumenta inutilmente la superficie da gestire. Gli ambienti di sviluppo richiedono quindi regole esplicite di alimentazione e pulizia.

Le chiavi e gli altri segreti richiedono un sistema di gestione appropriato, con accessi limitati e tracciati. Non dovrebbero essere inseriti nel codice, nei messaggi di errore o nei registri applicativi. Anche la gestione dell'assistenza deve prevedere quali informazioni possono essere richieste e attraverso quali canali. Un buon disegno riduce la necessità di consultare dati reali e rende ogni accesso eccezionale riconoscibile e ricostruibile.

Dal backup alla dimostrazione del ripristino

Una copia esistente non dimostra che il servizio possa ripartire. La prova di ripristino deve ricostruire dati, configurazione e dipendenze in un ambiente controllato, verificando che l'applicazione torni a eseguire operazioni significative. La frequenza delle copie e il tempo necessario a ripristinarle vanno rapportati alla criticità del processo. RPO e RTO descrivono rispettivamente la perdita temporale di dati tollerata e l'obiettivo di ripresa; diventano utili quando sono associati a scenari e prove.

Anche l'errore operativo va considerato: cancellazione involontaria, importazione sbagliata e aggiornamento difettoso non coincidono con il guasto di un server. Può essere necessario recuperare un insieme circoscritto di dati, evitando di annullare il lavoro valido compiuto nel frattempo. Le procedure devono specificare chi autorizza il recupero, come si verifica la coerenza finale e come si documentano eventuali differenze residue.

Verificare un percorso completo: l'esportazione

L'esportazione di documenti è un buon esercizio per verificare più confini insieme. Un utente autorizzato richiede un file, il sistema prepara il lavoro in un secondo momento e infine rende disponibile il risultato. L'autorizzazione iniziale non risolve automaticamente l'accesso successivo: nel frattempo il ruolo potrebbe essere cambiato o l'account disattivato. La procedura deve decidere quando controllare nuovamente i privilegi e come impedire che un collegamento venga riutilizzato fuori dal contesto previsto.

Vanno considerati anche il contenuto e la durata della copia. Il file deve includere soltanto campi necessari, dichiarare il perimetro estratto ed essere disponibile per il tempo appropriato. La cancellazione automatica deve comprendere le copie temporanee dell'elaborazione. Se l'operazione fallisce, il messaggio non dovrebbe esporre percorsi interni o informazioni appartenenti ad altri utenti. Il registro conserva gli elementi necessari a ricostruire la richiesta senza replicare il contenuto dell'esportazione.

Un collaudo concreto prova accesso da una seconda identità, revoca durante l'elaborazione, richiesta ripetuta e download oltre la scadenza. Queste prove aiutano a scoprire discontinuità tra interfaccia, servizio e archivio. La stessa tecnica si può applicare ad allegati, report e link condivisi: seguire un oggetto fino alla fine del suo ciclo di vita rende visibili controlli che una revisione della sola schermata potrebbe trascurare.

Portare la sicurezza nel ciclo di sviluppo

La revisione del codice, il controllo delle dipendenze, i test di autorizzazione e la gestione delle vulnerabilità sono attività complementari. Nessun singolo controllo garantisce l'assenza di difetti. Serve un percorso che assegni responsabilità e priorità: come arriva una segnalazione, chi valuta l'impatto, quali tempi si concordano e come si verifica la correzione. Il NIST SSDF offre un riferimento per integrare pratiche di sviluppo sicuro nel ciclo di vita del software.

Per chi valuta il contesto d'uso, la guida al gestionale cloud di Gestionale sul Web affronta la scelta applicativa. Qui la prospettiva resta quella del progetto: ogni confine dichiarato deve avere un controllo, una prova e un responsabile. È questa disciplina, mantenuta nel tempo, che rende la sicurezza una proprietà operativa del servizio anziché una formula promozionale.