Cloud per i servizi finanziari

Nessun provider può garantire la conformità, e chi afferma il contrario dovrebbe destare qualche sospetto. In base al DORA, gli obblighi ricadono sull'entità finanziaria: l’utente è responsabile del quadro di gestione del rischio ICT, del registro delle informazioni e del programma di verifica della resilienza. Il compito del provider è fornire le evidenze di cui ha bisogno il revisore: disposizioni contrattuali previste dall’articolo 30, dettagli relativi al subappalto e alla localizzazione dei dati richiesti dal registro, diritti di audit e accesso per l’utente e il suo revisore, notifica degli incidenti e supporto documentato in fase di uscita.

Datacenter localizzati in UE e accesso ai dati esclusivamente dall’UE non significano la stessa cosa. Il CLOUD Act statunitense si applica ai provider soggetti alla giurisdizione degli Stati Uniti, indipendentemente dal luogo fisico in cui si trovano i loro server. Questo significa che una Region a Francoforte o Parigi gestita da una società con sede negli Stati Uniti resta nell'ambito di applicazione di questa normativa. OVHcloud SAS è un’azienda a capitale francese, disciplinata dal diritto UE e senza capogruppo societario statunitense. Inoltre, per i requisiti più rigorosi, la qualifica SecNumCloud si aggiunge ai criteri verificati dall’ANSSI.

In fondo, queste due domande sono strettamente collegate. Il Private Cloud ospitato su VMware o Nutanix corrisponde allo stack attuale e consente una migrazione anziché una riscrittura, gestita workload per workload. Entrambi gli ambienti funzionano parallelamente fino a quando si decide di effettuare il cut over. Il Public Cloud utilizza invece standard aperti (OpenStack, Kubernetes, storage compatibile con S3) e non dipende quindi da API proprietarie che potrebbe essere difficile abbandonare in futuro. È questa la differenza tra un piano di uscita che esiste solo su carta e uno effettivamente attuabile.

Dipende dal workload: ciò che è valido per un ledger di core banking non lo sarà necessariamente anche per una piattaforma di reporting. Progettiamo Region 3-AZ per gestire eventuali guasti all’interno della Region e utilizziamo la replica multi-region per gli scenari che potrebbero essere oggetto di verifica da parte del revisore, con log di audit immutabili, backup immutabili e sistemi di recovery testati. In questo modo un attacco ransomware è seguito da una fase di restore invece che da una negoziazione. È importante richiedere sempre sia l’architettura di destinazione che le evidenze dei test: una senza l’altra non costituisce una dimostrazione sufficiente della resilienza.