Si stima che il COBOL gestisca ancora il 95% delle transazioni bancomat, l'80% delle transazioni POS effettuate di persona e la logica di elaborazione centrale della maggior parte delle principali banche, compagnie assicurative e agenzie governative in tutto il mondo. Le organizzazioni che utilizzano questo codice sono inoltre soggette ai quadri normativi più stringenti nel settore tecnologico: GDPR, DORA, HIPAA, PCI-DSS, Basilea III e normative specifiche di settore imposte dalla FCA, dall'OCC, dall'APRA e da decine di altre autorità nazionali. Quando queste organizzazioni prendono in considerazione la migrazione dei carichi di lavoro sul cloud, la questione non è solo tecnica. È anche legale, contrattuale e dimostrabile a un revisore esterno entro una specifica tempistica.
Il cloud ibrido, che mantiene alcuni carichi di lavoro on-premise e ne sposta altri sull'infrastruttura cloud, non è una soluzione di compromesso per le organizzazioni regolamentate che utilizzano COBOL. Spesso rappresenta la risposta architetturalmente corretta. I requisiti di residenza dei dati previsti dal GDPR e dalle sue equivalenti normative nazionali possono legalmente impedire che determinati dati escano da una specifica giurisdizione. I requisiti di resilienza operativa previsti dal DORA richiedono la dimostrazione che le funzioni finanziarie critiche possano resistere alle interruzioni del servizio del fornitore di servizi cloud. I requisiti di integrità dei calcoli per il capitale regolamentare previsti da Basilea III richiedono che specifici calcoli siano riproducibili, verificabili e a prova di manomissione, proprietà che sono più facili da dimostrare quando il calcolo avviene su un'infrastruttura controllata dall'organizzazione.
Individua le lacune di conformità prima dell'inizio della migrazione.
SMART TS XL Vengono alla luce credenziali codificate in modo rigido, tracce di controllo mancanti e modelli di dati regolamentati nel codice sorgente COBOL.
Maggiori InformazioniLa sfida consiste nel fatto che l'architettura cloud ibrida per COBOL regolamentato è più vincolata di quanto riconosciuto dalle linee guida generiche sul cloud ibrido. La vostra strategia di integrazione cloud ibrida fornisce un equilibrio essenziale tra innovazione e stabilità durante la migrazione dal mainframe al cloud. Tale equilibrio è corretto in linea di principio. Ciò che omette è l'architettura tecnica e di conformità specifica necessaria per definire il confine tra on-premise e cloud in un punto che soddisfi i requisiti normativi, preservi la continuità operativa e crei un percorso di migrazione anziché una separazione permanente.
Questa guida illustra come ciascun quadro normativo principale influenzi la decisione relativa ai confini degli ambienti ibridi, i quattro modelli architetturali adatti agli ambienti COBOL regolamentati, le modalità di fallimento della conformità che le architetture ibride introducono se non progettate per gestirle, e cosa effettivamente esaminano i revisori quando verificano un ambiente COBOL ibrido.
Come le normative plasmano il confine ibrido
La decisione più importante nell'architettura cloud ibrida per un'organizzazione soggetta a normative non è quale fornitore di servizi cloud utilizzare o quali carichi di lavoro migrare per primi. È piuttosto dove tracciare il confine di conformità: quali dati e quali elaborazioni devono rimanere on-premise e quali possono essere spostati sull'infrastruttura cloud senza incorrere in violazioni normative.
Ciascun quadro normativo principale impone requisiti diversi a tale confine:
| Regolamento | Giurisdizione | Vincolo ibrido primario | Ciò che deve rimanere in loco |
|---|---|---|---|
| GDPR / nFADP | UE, Svizzera | Residenza dei dati personali dei residenti nell'UE/SEE | Qualsiasi sistema COBOL che elabora dati personali dell'UE senza una decisione di adeguatezza per la regione cloud di destinazione |
| DORA | Servizi finanziari dell'UE | Resilienza operativa; gestione del rischio di terze parti per i fornitori di servizi ICT | Le funzioni critiche o importanti devono avere strategie di uscita; si applicano i limiti di rischio di concentrazione. |
| HIPAA | Sanità statunitense | Le informazioni sanitarie protette (PHI) non possono essere elaborate dal fornitore di servizi cloud senza BAA; requisiti di crittografia | Le informazioni sanitarie elettroniche (ePHI) in transito e a riposo su qualsiasi percorso cloud richiedono controlli documentati |
| PCI-DSS v4.0 | Pagamenti globali (con carta) | L'ambiente dei dati dei titolari di carta deve essere isolato dalla rete. | Sistemi di elaborazione CHD; gestione delle chiavi di crittografia |
| Basilea III/IV | Globale (settore bancario) | I calcoli relativi al capitale regolamentare devono essere riproducibili e verificabili. | Motori di calcolo in cui la verificabilità è dimostrata tramite il controllo dell'infrastruttura |
| FCA / PRA (Regno Unito) | Servizi finanziari del Regno Unito | Resilienza operativa; i servizi aziendali importanti devono soddisfare le tolleranze di impatto | Dipende dalla dimostrabilità dell'SLA; il cloud non è escluso ma deve essere comprovato |
| OCC (settore bancario statunitense) | Banche nazionali statunitensi | Gestione del rischio dei fornitori; due diligence su terze parti | Non vi è alcun divieto assoluto, ma è necessario valutare il rischio di concentrazione e predisporre piani di uscita. |
La conseguenza pratica per i carichi di lavoro COBOL:
Un programma batch COBOL che elabora i dati degli account dei clienti UE non può essere migrato su una piattaforma cloud al di fuori dell'UE/SEE a meno che la giurisdizione del fornitore di servizi cloud non abbia ricevuto una decisione di adeguatezza o non siano in vigore garanzie appropriate (clausole contrattuali standard). Lo stesso programma, se elabora solo dati operativi interni, gode di molta più flessibilità.
Prima di definire il confine ibrido, ogni organizzazione regolamentata dovrebbe completare una classificazione dei dati del proprio portfolio COBOL: quali programmi gestiscono dati personali, quali gestiscono dati dei titolari di carte, quali gestiscono informazioni sanitarie protette (PHI) e quali elaborano i calcoli relativi al capitale regolamentare. Tale classificazione determina quali programmi possono migrare liberamente e quali devono rimanere entro i limiti di conformità, indipendentemente dalle preferenze tecniche.
Il problema della conformità COBOL di cui nessuno parla
I programmi COBOL introducono rischi di conformità specifici del linguaggio e del suo contesto storico, che le linee guida generiche sulla conformità al cloud non affrontano. Questi rischi esistono già oggi negli ambienti on-premise e diventano problemi di visibilità in un ambiente ibrido, dove l'auditor si aspetta di vedere i controlli su entrambi i lati del confine.
Lacune nella tracciabilità delle transazioni. I programmi COBOL in genere scrivono su file e database senza una registrazione nativa delle transazioni. Un aggiornamento VSAM KSDS in COBOL, per impostazione predefinita, non produce una registrazione immutabile di chi ha modificato cosa, quando e da quale valore a quale valore. In un ambiente regolamentato, questa rappresenta una lacuna di conformità e il trasferimento di un programma con questa lacuna in un ambiente ibrido, dove il lato cloud dispone di una moderna registrazione delle transazioni, rende la lacuna più evidente, non meno.
Credenziali e chiavi di crittografia hardcoded. Le applicazioni COBOL legacy spesso non dispongono di funzionalità moderne come il controllo degli accessi basato sui ruoli, il monitoraggio in tempo reale e i protocolli di crittografia, il che le rende vulnerabili a sofisticate minacce informatiche. L'analisi statica dei programmi COBOL rivela regolarmente chiavi hardcoded, password in WORKING-STORAGE e stringhe di connessione incorporate nel codice sorgente. In un ambiente ibrido che deve soddisfare i requisiti di gestione delle chiavi PCI-DSS o i controlli di crittografia HIPAA, questi schemi richiedono una correzione prima della migrazione, non dopo.
Riproducibilità dei calcoli. L'aritmetica decimale compressa (COMP-3) di COBOL presenta specifiche caratteristiche di precisione e arrotondamento. Un calcolo del capitale regolamentare che viene eseguito correttamente su z/OS potrebbe produrre risultati diversi su Linux a causa delle differenze tra i compilatori nella gestione dei decimali. La differenza potrebbe essere di pochi centesimi per transazione, oppure potrebbe essere significativa per un coefficiente patrimoniale. Gli ambienti ibridi che suddividono i componenti di calcolo su diverse piattaforme devono convalidare esplicitamente l'equivalenza numerica.
Quattro modelli architettonici ibridi per COBOL regolamentato
Carichi di lavoro regolamentati differenti richiedono architetture ibride differenti. Non esiste un modello universale, ma queste quattro coprono la gamma di situazioni che la maggior parte delle organizzazioni soggette a regolamentazione si trova ad affrontare.
Modello 1: Il gateway API per la conformità
Ideale per: Organizzazioni in cui la logica di business COBOL deve rimanere on-premise per motivi normativi, ma le applicazioni moderne, l'analisi dei dati e i servizi rivolti ai clienti possono essere migrati al cloud.
I programmi COBOL rimangono sul mainframe. Un sottile strato API, in genere in esecuzione su infrastrutture adiacenti al cloud o all'interno della rete privata dell'organizzazione, espone le funzionalità COBOL come endpoint REST o gRPC. Le applicazioni basate sul cloud richiamano questi endpoint. Il programma COBOL non si sposta mai; è l'interfaccia ad esso che viene spostata.
Cloud Region (permitted) Compliance Boundary On-Premises (required)
┌─────────────────────┐ │ ┌──────────────────────────┐
│ New cloud-native │ │ │ COBOL programs │
│ applications │──── API ─────┤──────────────│ (regulated processing) │
│ │ call │ │ │
│ Analytics │ │ │ VSAM files (PHI/CHD) │
│ platforms │ │ │ │
│ │ │ │ Audit logs │
└─────────────────────┘ │ └──────────────────────────┘Vantaggio in termini di conformità: i dati regolamentati non oltrepassano mai il confine. Il gateway API gestisce l'autenticazione, l'autorizzazione e la registrazione al confine, fornendo una traccia di controllo che il programma COBOL stesso potrebbe non generare. Il cloud non elabora mai direttamente i dati regolamentati.
Requisito operativo: il livello API deve essere progettato per gestire il modello sincrono richiesta-risposta di COBOL. I processi batch COBOL di lunga durata richiedono modelli asincroni con meccanismi di callback o polling, anziché chiamate API sincrone che vanno in timeout.
Schema 2: Classificazione dei dati in base alla sensibilità normativa
Ideale per: Organizzazioni con dati sia regolamentati che non regolamentati nello stesso ambiente COBOL, dove i dati regolamentati possono essere separati dai dati operativi.
I dati transazionali che comportano requisiti normativi, i dati personali, i dati dei titolari di carte e le informazioni sanitarie protette (PHI) rimangono in locale. I dati aggregati, anonimizzati o operativi che non comportano restrizioni normative vengono trasferiti all'archiviazione e all'elaborazione nel cloud. I programmi COBOL che producono output soggetti a normative continuano a essere eseguiti sul mainframe. I programmi di reporting che utilizzano dati aggregati vengono eseguiti nel cloud.
Requisito critico di implementazione: la fase di aggregazione e anonimizzazione deve essere verificabile. Il processo che trasforma i dati regolamentati in dati non regolamentati per la trasmissione nel cloud deve essere a sua volta registrato, testato e soggetto a controlli specifici. Un processo di de-identificazione che fallisce in determinate condizioni di input può produrre dati nel cloud che re-identificano inavvertitamente le persone, configurando una violazione del GDPR causata da un'architettura progettata per prevenirla.
Schema 3: Validazione a doppia esecuzione
Ideale per: Organizzazioni che migrano carichi di lavoro COBOL che eseguono calcoli regolamentati, dove l'equivalenza funzionale tra i vecchi e i nuovi sistemi deve essere dimostrata a un ente regolatore prima del passaggio definitivo.
Il programma COBOL originale continua a essere eseguito sul mainframe, elaborando dati in tempo reale. Un'implementazione parallela, riprogettata o riorganizzata, viene eseguita simultaneamente su un'infrastruttura cloud, elaborando gli stessi dati di input. Gli output vengono confrontati in tempo reale. Le discrepanze vengono segnalate, analizzate e risolte prima che l'implementazione cloud venga certificata come sistema di riferimento.
Valore di conformità: la doppia esecuzione soddisfa il requisito di equivalenza dimostrabile imposto dagli enti regolatori alle modifiche apportate ai sistemi che eseguono calcoli regolamentari. L'organizzazione può mostrare al revisore una registrazione di N mesi di funzionamento parallelo, il processo di riconciliazione applicato alle discrepanze e la prova che il nuovo sistema produce risultati sostanzialmente identici in tutte le condizioni di input testate.
Costi operativi: far funzionare due sistemi in parallelo è costoso. Il funzionamento in parallelo è un meccanismo di transizione, non un'architettura permanente. La tempistica per il completamento della validazione e il passaggio al nuovo sistema deve essere specificata nel piano di progetto e concordata con l'ente regolatore competente laddove sia richiesta un'approvazione preventiva (come previsto dal DORA per le modifiche alle funzioni critiche).
Modello 4: Fico strangolatore con confine di conformità
Ideale per: Organizzazioni che sviluppano nuove funzionalità nel cloud mantenendo al contempo carichi di lavoro COBOL regolamentati on-premise a lungo termine, con un percorso di migrazione definito per ciascun carico di lavoro al raggiungimento della certificazione.
Le nuove funzionalità e le funzioni rivolte al cliente vengono sviluppate fin dall'inizio come servizi cloud-native. I carichi di lavoro COBOL regolamentati rimangono on-premise, accessibili tramite il modello API gateway. Nel tempo, i singoli programmi COBOL vengono certificati per la distribuzione nel cloud, completando la convalida dual-run, ottenendo l'approvazione preventiva da parte degli enti regolatori ove richiesto e migrando verso il lato cloud. Il mainframe si riduce progressivamente man mano che ciascun programma completa la propria certificazione di conformità.
Perché funziona per le organizzazioni regolamentate: consente di accelerare la modernizzazione dei carichi di lavoro non regolamentati, applicando al contempo il rigore necessario a quelli regolamentati. Il confine di conformità è esplicito, verificabile e si muove in un'unica direzione. L'organizzazione può dimostrare alle autorità di regolamentazione che ogni carico di lavoro sul cloud ha seguito un processo di certificazione definito e che ogni carico di lavoro on-premise dispone di una roadmap di certificazione.
Cosa chiedono realmente i revisori contabili in merito agli ambienti COBOL ibridi
La conformità non è uno stato, ma un processo dimostrabile. La questione non è se la tua architettura ibrida sia conforme, ma se tu possa dimostrarlo a chi ha il compito di individuare i problemi.
Ecco le domande che i revisori dei principali organismi di regolamentazione pongono nel contesto degli ambienti COBOL ibridi e quali prove sono necessarie per soddisfarle:
“Dove risiedono questi dati e in quali giurisdizioni?” Richiesto: una mappa dei dati aggiornata che mostri ogni datastore, file VSAM, tabella DB2, storage di oggetti cloud, con giurisdizione, classificazione e controlli in atto. I programmi COBOL che scrivono sui dataset devono essere presenti in questa mappa con i relativi output classificati.
"Mostrami la traccia di controllo per questa transazione." È richiesto: una traccia completa dall'avvio della transazione fino a ogni sistema che ha elaborato i dati, incluso il programma COBOL che li ha elaborati. Se il programma COBOL non genera i propri record di controllo, l'infrastruttura circostante deve compensare, una funzione che deve essere esplicitamente progettata e non data per scontata.
"Cosa succede alle vostre funzioni critiche se il vostro fornitore di servizi cloud subisce un'interruzione?" Requisiti (DORA): scenari di resilienza operativa documentati, RPO e RTO testati per le funzioni critiche e prove che i sistemi on-premise possano operare indipendentemente dalle dipendenze dal cloud per la durata specificata nella politica di resilienza dell'organizzazione.
"Come si fa a sapere che il sistema migrato produce gli stessi risultati di quello originale?" Richiesto: il record di riconciliazione delle due esecuzioni, la copertura dei casi di test e, per i carichi di lavoro sensibili ai calcoli, un'analisi di equivalenza numerica.
Chi può accedere ai dati regolamentati sul cloud e quali autorizzazioni disciplinano tale accesso? Documentazione richiesta: documentazione relativa alle policy IAM, registri di gestione degli accessi privilegiati e prova che i controlli di accesso sul cloud siano almeno altrettanto restrittivi di quelli on-premise.
Un quadro decisionale per la definizione del confine ibrido
Non tutti i programmi COBOL appartengono allo stesso lato del confine ibrido. Questa checklist determina il posizionamento per ogni carico di lavoro:
Passa al cloud senza vincoli normativi:
- Il programma non elabora dati personali di individui residenti in giurisdizioni soggette al GDPR/nFADP.
- Il programma non elabora dati relativi ai titolari di carta (esclusione dall'ambito di applicazione dello standard PCI-DSS confermata).
- Il programma non elabora alcuna informazione sanitaria protetta (esclusione dall'ambito di applicazione dell'HIPAA confermata).
- Il programma non esegue calcoli che costituiscono input per i coefficienti patrimoniali regolamentari
- Il programma non contiene credenziali o chiavi di crittografia codificate direttamente nel codice sorgente.
- I risultati del programma non sono soggetti a requisiti di residenza dei dati in alcuna giurisdizione.
Richiede una progettazione conforme prima della migrazione al cloud:
- Il programma genera o elabora dati personali; completare la valutazione d'impatto sui dati.
- Il programma rientra nell'ambito di applicazione dello standard PCI-DSS, con SAQ/ROC completo per l'ambiente cloud.
- Il programma esegue calcoli di capitale regolamentare e un'analisi completa di equivalenza numerica.
- Il programma non genera tracce di controllo; progettare controlli compensativi prima della migrazione.
- Il programma contiene chiavi codificate in modo rigido; è necessario correggerle prima di esporlo al percorso di rete cloud.
Deve rimanere in loco fino all'approvazione preventiva da parte dell'ente regolatore:
- Il programma è classificato come funzione critica o importante ai sensi del DORA
- Il programma è soggetto ai requisiti di resilienza operativa della FCA/PRA in quanto servizio aziendale importante.
- L'autorità di regolamentazione ha espressamente richiesto la notifica o l'approvazione preventiva per le modifiche al sistema (pratica comune nei sistemi bancari centrali).
Come SMART TS XL Supporta la pianificazione dell'architettura ibrida per COBOL regolamentato
Le decisioni descritte in questa guida, ovvero dove posizionare il confine di conformità, quali programmi elaborano dati regolamentati, quali contengono requisiti di correzione della sicurezza, quali eseguono funzioni di calcolo che necessitano di convalida di equivalenza, richiedono una conoscenza strutturale accurata di ogni programma nel portfolio COBOL. Tale conoscenza non può essere desunta dalla documentazione. Negli ambienti COBOL regolamentati, la documentazione esistente è stata in genere redatta per un sistema che da allora è stato modificato decine di volte senza corrispondenti aggiornamenti della documentazione.
SMART TS XL'S analisi statica del codice Vengono messi in luce i modelli di sicurezza e conformità nel codice sorgente COBOL che determinano da quale lato del confine ibrido appartiene ciascun programma: credenziali hardcoded in WORKING-STORAGE, gestione delle chiavi di crittografia, generazione (o assenza) dei log di controllo e modelli di calcolo che influiscono sul capitale regolamentare. Questi risultati supportano il lavoro di progettazione della conformità che deve precedere il posizionamento del confine ibrido per i carichi di lavoro regolamentati.
La mappatura delle dipendenze tra applicazioni mostra quali programmi condividono dati con quali altri, e i modelli di accesso ai dataset tra programmi che determinano se il posizionamento di un programma nel cloud crea un flusso di dati regolamentato attraverso il confine che non era stato previsto. Un programma COBOL che apparentemente elabora solo dati operativi potrebbe leggere da un file VSAM che contiene anche dati personali scritti da un programma diverso. La mappa delle dipendenze rende visibili queste relazioni di condivisione dei dati prima che venga tracciato il confine ibrido.
La funzionalità di analisi d'impatto rende verificabili le modifiche ai confini: quando un programma viene spostato da un ambiente locale al cloud, l'analisi d'impatto elenca tutti gli altri programmi interessati da tale spostamento, i chiamanti, i consumatori di dataset, i flussi di job JCL , fornendo la portata della modifica come prova per l'autorità di regolamentazione e come base per il programma di test di equivalenza.
La funzionalità di ricerca aziendale rende l'inventario di conformità interrogabile in tutto il programma ibrido: è possibile trovare in pochi secondi ogni programma che elabora un tipo di dati specifico, ogni programma che accede a un cluster VSAM specifico, ogni file sorgente COBOL contenente un modello specifico, su milioni di righe. Per un'organizzazione regolamentata che deve dimostrare a un revisore che tutti i programmi rientranti nell'ambito di applicazione sono stati identificati e valutati, questo inventario interrogabile rappresenta la prova che sostituisce l'attestazione manuale.
L'ente regolatore non si preoccupa della tempistica della tua migrazione.
Il cloud ibrido non è una soluzione temporanea per le organizzazioni regolamentate che utilizzano COBOL. Per molte di esse, rappresenta il modello operativo permanente, non per limitazioni tecniche, ma perché il quadro normativo che disciplina i loro dati e le loro funzioni richiede il controllo on-premise di specifici carichi di lavoro a tempo indeterminato. La domanda giusta non è "come possiamo abbandonare il mainframe", ma "quali carichi di lavoro possono migrare al cloud, con quale architettura di conformità e con quali prove che il confine sia adeguatamente controllato".
Le configurazioni ibride offrono alle organizzazioni la flessibilità di mantenere i componenti legacy on-premise, consentendo al contempo l'integrazione con il cloud. Per i settori regolamentati, tale flessibilità non è un'opzione, ma un requisito obbligatorio per specifiche categorie di carichi di lavoro. Le organizzazioni che ottengono successo con le architetture COBOL ibride sono quelle che definiscono esplicitamente il confine di conformità, lo strumentano per la verificabilità fin dall'inizio e considerano la produzione di documentazione di conformità come un requisito architetturale, piuttosto che come un elemento da aggiungere in un secondo momento.
