Sicurezza SaaS secondo DORA

Il Digital Operational Resilience Act (regolamento (UE) 2022/2554) è un corpus unico di regole per la resilienza operativa digitale del settore finanziario UE. Si applica direttamente in tutti gli Stati membri dal 17 gennaio 2025. Riguarda banche, assicurazioni, imprese di investimento, istituti di pagamento e di moneta elettronica e altri soggetti finanziari.

Il regolamento si basa su cinque pilastri: gestione del rischio ICT, gestione e segnalazione degli incidenti ICT, test di resilienza operativa digitale, gestione del rischio di terzi ICT e condivisione delle informazioni. Il SaaS ricade soprattutto nel pilastro del rischio di terzi.

Quasi ogni applicazione SaaS usata da un'istituzione finanziaria, come suite di collaborazione, CRM, HR, analisi o gestione documentale, è un servizio ICT fornito da un terzo. Il contratto diventa quindi un accordo con un terzo ICT, ai sensi del capitolo DORA sul rischio di terzi.

I fornitori designati come fornitori terzi critici di servizi ICT sono inoltre vigilati direttamente dalle Autorità europee di vigilanza. Questa vigilanza, però, non sposta la responsabilità: davanti al proprio supervisore, l'istituzione finanziaria risponde della resilienza delle funzioni sostenute dal SaaS.

DORA impone a ogni istituzione finanziaria di tenere un registro delle informazioni che copra tutti gli accordi con terzi ICT. Ogni contratto SaaS vi rientra. Il registro indica l'identità del fornitore, la descrizione dei servizi, se questi sostengono funzioni critiche o importanti, la catena dei subappalti, le sedi dei dati e i diritti di recesso.

Il registro è consegnato alle autorità competenti, che ne riferiscono alle Autorità europee di vigilanza. Le schede SaaS incomplete emergono quindi durante la revisione di vigilanza, invece di restare una lacuna interna. Un registro degli asset IT accurato ne è il punto di partenza pratico.

La valutazione è un dovere che copre tutto il ciclo di vita, non una semplice formalità d'acquisto. Prima di affidarsi a un servizio SaaS, l'istituzione deve valutare la capacità tecnica del fornitore, le sue pratiche di sicurezza, la qualità del supporto e la solidità finanziaria, e ripeterla quando cambiano le circostanze.

La concentrazione riceve un'attenzione specifica. Quando molte istituzioni dipendono dalle stesse poche piattaforme SaaS, il guasto di un solo fornitore diventa un evento di settore. Per questo il registro documenta anche quanto ogni servizio sia realmente sostituibile.

DORA fissa il contenuto minimo dei contratti di servizi ICT. In pratica, un accordo SaaS deve contenere almeno queste clausole:

DORA armonizza la classificazione e la segnalazione dei gravi incidenti legati a ICT. Un incidente che nasce presso un fornitore SaaS resta un incidente dell'istituzione. Questa deve rilevare che una dipendenza è degradata e valutare l'impatto sulle proprie funzioni.

Non ogni incidente grave è una violazione dei dati: anche l'interruzione di un fornitore che blocca un servizio critico può essere soggetta a segnalazione. I rapporti iniziale, intermedio e finale vanno consegnati nei termini previsti, e ciò richiede di sapere in anticipo quali funzioni poggiano su quali servizi.

I test di resilienza devono includere la dimensione dei terzi. I programmi di test, compresi i penetration test guidati dalle minacce (TLPT) per i soggetti designati dall'autorità, devono considerare scenari in cui un servizio SaaS è indisponibile, degradato o compromesso, e verificare che ripristino e strategie di uscita reggano sotto pressione.

Non ogni obbligo vale allo stesso modo per ogni servizio. Questi obblighi di solito si gestiscono nell'ambito di un processo di gestione della compliance, e lo stato indicato sotto dipende dal perimetro.

Nessun controllo da solo copre l'intero quadro SaaS. La revisione dei contratti verifica la carta, mentre inventario e registri di attività mostrano ciò che è davvero in uso. I servizi adottati senza autorizzazione, il cuore dello Shadow IT, restano nello spazio tra i due.

Il regolamento fissa gli obblighi, ma la pratica inizia dal sapere quali SaaS l'organizzazione usa davvero. I servizi adottati dai singoli team non entrano mai nel registro e non vengono mai valutati, eppure portano gli stessi flussi di dati di quelli approvati.

Nessuno dei controlli seguenti è citato per nome nel regolamento. Senza di essi, però, gli obblighi che il regolamento cita sono difficili da rispettare. Stabilire quali dati possono raggiungere quale servizio è il compito della prevenzione della perdita di dati.

1. 1

   Partire dall'inventario

   Censire ogni applicazione SaaS in uso, comprese quelle che i dipendenti adottano per conto proprio.

2. 2

   Classificare i dati

   Stabilire quali dati possono raggiungere quale servizio.

3. 3

   Coprire i canali di ingresso

   Applicare la prevenzione della perdita di dati a caricamenti dal browser, client di sincronizzazione ed email, così i dati regolati raggiungono solo i servizi del registro.

4. 4

   Registrare l'attività degli utenti

   Conservare una traccia probatoria dentro e attorno alle applicazioni SaaS, per la classificazione degli incidenti e le domande dei supervisori.

Si parte dai dati la cui esposizione farebbe più danni, poi si mappano i servizi che possono riceverli. Una policy di classificazione dei dati offre a ogni contratto e a ogni controllo lo stesso punto di riferimento.

Per approfondire: Il concetto di "Zero Trust".