Article. What i write

Il rientro selettivo dal public cloud è tornato al centro dell’agenda dei CIO e dei CISO. Proviamo a capire quali sono i fattori scatenanti e a non confondere un cambiamento di perimetro con un aumento della sicurezza. Per oltre un decennio, la migrazione verso il cloud pubblico è stata considerata la direzione naturale di qualunque strategia infrastrutturale IT. Negli ultimi anni, tuttavia, un fenomeno complementare ha acquisito una rilevanza crescente: il cloud repatriation, ovvero il trasferimento di dati e applicazioni dal cloud pubblico verso ambienti on-premises, cloud privati o soluzioni di colocation. È necessario chiarire subito un equivoco. Il repatriation non rappresenta un rifiuto del cloud, ma una sua maturazione: secondo le rilevazioni di settore (in particolare i report annuali come lo State of the Cloud di Flexera), la quota di organizzazioni che riportano selettivamente i workload è ai massimi storici, nonostante la spesa complessiva per il cloud sia in aumento. Si tratta, dunque, di una ricalibrazione, non di un’inversione di rotta.

Analizziamo i quattro principali fattori che ricorrono con regolarità nelle decisioni di repatriation. Il primo è di natura economica: i modelli di pricing usage-based, ottimali per la domanda elastica, si rivelano spesso strutturalmente più onerosi per i workload steady-state a utilizzo prevedibile e continuativo; a ciò si somma il peso degli egress fees, che incidono in modo non trascurabile sul Total Cost of Ownership (TCO) effettivo. Il secondo riguarda il controllo delle prestazioni e della latenza, particolarmente rilevante per le applicazioni con forte data gravity. Il terzo aspetto attiene alla compliance e alla data sovereignty: l’esigenza di garantire che i dati restino soggetti alla giurisdizione del territorio in cui risiedono spinge verso un controllo più diretto della loro collocazione e delle architetture di riferimento adottate. Il quarto è il vendor lock-in, ovvero la dipendenza da API, formati e servizi proprietari che rende oneroso, dal punto di vista tecnico e contrattuale, il cambio di provider.

Questi fattori raramente agiscono in modo isolato. Un’analisi più approfondita del problema del lock-in evidenzia come la dipendenza si accentui man mano che le risorse migrano dall’on-premises al cloud, esponendo l’organizzazione a un rischio di portabilità che si manifesta nel momento in cui è necessario cambiare collocazione, spesso senza una pianificazione adeguata.

Dal punto di vista della sicurezza, l’errore più comune è quello di pensare che riportare i dati “in casa” li renda automaticamente più sicuri. Il repatriation modifica la superficie d’attacco e ridistribuisce le responsabilità, ma non riduce di per sé il rischio. Nel public cloud vige uno shared responsibility model in cui il provider si occupa della sicurezza dell’infrastruttura sottostante. Riportando un workload on-premises, l’organizzazione riassume integralmente gli oneri che in precedenza erano in parte delegati: patching dell’hardware, sicurezza fisica, ridondanza, capacità di detection e response. Per un CISO, il problema principale non è dove i dati sono più sicuri, ma dove l’organizzazione è effettivamente in grado di sostenere il livello di controllo richiesto, con le competenze e i budget a disposizione.

Anche dal punto di vista della data sovereignty il quadro è meno lineare di quanto possa sembrare. Mantenere i dati all’interno di una determinata giurisdizione può ridurre alcune esposizioni legali e regolamentari, ma le soluzioni che lo garantiscono, dalle architetture di riferimento alle misure crittografiche, impongono vincoli tecnologici ed economici, come un aumento dei costi computazionali, che devono essere presi in considerazione nella decisione finale. Va inoltre considerato che la fase di transizione è essa stessa un momento di rischio: ogni migrazione comporta la movimentazione dei dati, la riconfigurazione dei controlli e l’apertura di potenziali finestre di esposizione. La sicurezza dei workload rimpatriati deve essere reintegrata nei framework di governance esistenti e non deve essere ricostruita ex novo in modo frammentario.

La letteratura e la prassi convergono su un punto: il repatriation efficace è selettivo, non ideologico. Le evidenze indicano che le organizzazioni raramente riportano interi sistemi, ma piuttosto intervengono su workload specifici la cui collocazione non risulta più ottimale. Da qui l’opportunità di adottare una valutazione per singolo workload, idealmente su un orizzonte di dodici-trentasei mesi, che classifichi l’elasticità effettiva del carico, modelli il TCO con sensibilità a egress, traffico cross-zone, premi sui managed services e quantifichi l’effort di uscita.

Quest’ultimo elemento è decisivo. Una exit strategy andrebbe progettata fin dalla fase di adozione, privilegiando la portabilità, la containerizzazione e gli standard aperti per limitare il rischio di lock-in. In questa direzione, i framework predittivi del rischio di lock-in forniscono un supporto concreto e quantitativo: pesando fattori quali i costi di servizio, il data transfer, le funzionalità di sicurezza, l’aderenza alla compliance e le integrazioni tecniche, consentono di stimare il grado di dipendenza da un provider e i costi di un eventuale recesso prima che la decisione diventi irreversibile. Per quanto riguarda la gestione, la ricerca più recente sugli ecosistemi cloud conferma che il lock-in è prima di tutto un problema di governance e di mitigazione preventiva e non solo di natura tecnica.

In sintesi, il cloud repatriation non segna la fine del cloud, ma il passaggio da una logica cloud-first a una logica cloud-appropriate, in cui ogni workload viene collocato dove si ottiene il miglior equilibrio tra costo, prestazioni, controllo e conformità. Per i CISO e i CIO la questione non è scegliere tra il public cloud e l’on-premises, ma costruire architetture hybrid e multi-cloud effettivamente governabili, dotate di exit strategy credibili e di una postura di sicurezza coerente, a prescindere dal perimetro. In questa prospettiva, il repatriation è uno strumento di flessibilità strategica da tenere a disposizione ed esercitare con disciplina analitica, non una correzione di rotta dettata dal pentimento.