Estima-se que o COBOL ainda seja responsável por 95% das transações em caixas eletrônicos, 80% das transações presenciais em pontos de venda e pela lógica de processamento principal da maioria dos grandes bancos, seguradoras e agências governamentais do mundo. As organizações que executam esse código também estão sujeitas às estruturas regulatórias mais exigentes em tecnologia: GDPR, DORA, HIPAA, PCI-DSS, Basileia III e regimes específicos do setor aplicados pela FCA, OCC, APRA e dezenas de outras autoridades nacionais. Quando essas organizações consideram migrar cargas de trabalho para a nuvem, a questão não é apenas técnica. É uma questão legal, contratual e que precisa ser demonstrada a um auditor externo dentro de um prazo específico.
A nuvem híbrida, que mantém algumas cargas de trabalho em infraestruturas locais enquanto outras são migradas para a nuvem, não é uma solução de compromisso para organizações regulamentadas que utilizam COBOL. Muitas vezes, é a resposta arquiteturalmente correta. Os requisitos de residência de dados previstos no GDPR e em suas legislações nacionais equivalentes podem proibir legalmente que certos dados saiam de uma jurisdição específica. Os requisitos de resiliência operacional previstos na DORA exigem a demonstração de que as funções financeiras críticas podem suportar interrupções do provedor de nuvem. Os requisitos de integridade de cálculo para capital regulatório, conforme o Acordo de Basileia III, exigem que cálculos específicos sejam reproduzíveis, auditáveis e à prova de adulteração, propriedades que são mais fáceis de demonstrar quando o cálculo ocorre em uma infraestrutura controlada pela organização.
Identifique as lacunas de conformidade antes do início da migração.
SMART TS XL Identifica credenciais codificadas diretamente no código-fonte COBOL, falta de registros de auditoria e padrões de dados regulamentados.
Mais informaçõesO desafio reside no fato de que a arquitetura de nuvem híbrida para COBOL regulamentado é mais restritiva do que as diretrizes genéricas para nuvem híbrida reconhecem. Sua estratégia de integração de nuvem híbrida proporciona um equilíbrio essencial entre inovação e estabilidade durante a migração do mainframe para a nuvem. Esse equilíbrio está correto como princípio. O que ele omite é a arquitetura técnica e de conformidade específica necessária para definir a fronteira entre o ambiente local e a nuvem de forma a satisfazer os órgãos reguladores, preservar a continuidade operacional e criar um caminho de migração, em vez de uma divisão permanente.
Este guia aborda como cada estrutura regulatória principal influencia a decisão sobre os limites híbridos, os quatro padrões arquitetônicos que funcionam para ambientes COBOL regulamentados, os modos de falha de conformidade que as arquiteturas híbridas introduzem se não forem projetadas para eles e o que os auditores realmente examinam ao revisar um ambiente COBOL híbrido.
Como as regulamentações moldam a fronteira híbrida
A decisão mais importante na arquitetura de nuvem híbrida para uma organização regulamentada não é qual provedor de nuvem usar ou quais cargas de trabalho migrar primeiro. É onde traçar o limite de conformidade: quais dados e quais processos devem permanecer no ambiente local e quais podem ser migrados para a infraestrutura de nuvem sem infringir as normas regulatórias.
Cada estrutura principal impõe requisitos diferentes a esse limite:
| Regulamento | Jurisdição | Restrição Híbrida Primária | O que deve permanecer nas instalações |
|---|---|---|---|
| RGPD / nFADP | UE, Suíça | Residência de dados para dados pessoais de residentes da UE/EEE | Qualquer sistema COBOL que processe dados pessoais da UE sem uma decisão de adequação para a região de nuvem de destino. |
| DORA | Serviços financeiros da UE | Resiliência operacional; gestão de riscos de terceiros para fornecedores de TIC | Funções críticas ou importantes devem ter estratégias de saída; aplicam-se limites de risco de concentração. |
| HIPAA | Saúde dos EUA | PHI não pode ser processada pelo provedor de nuvem sem um BAA; requisitos de criptografia | Informações eletrônicas de saúde protegidas (ePHI) em trânsito e em repouso em qualquer caminho na nuvem exigem controles documentados. |
| PCI-DSS v4.0 | Global (pagamentos com cartão) | O ambiente de dados do titular do cartão deve ser isolado da rede. | Sistemas de processamento de CHD; gerenciamento de chaves de criptografia |
| Basileia III/IV | Global (bancário) | Os cálculos de capital regulatório devem ser reproduzíveis e auditáveis. | Mecanismos de cálculo onde a auditabilidade é demonstrada por meio do controle da infraestrutura. |
| FCA / PRA (Reino Unido) | Serviços financeiros do Reino Unido | Resiliência operacional; serviços essenciais para os negócios devem atender aos limites de tolerância a impactos. | Depende da comprovação do SLA; a nuvem não está excluída, mas deve ser comprovada. |
| OCC (Bancos dos EUA) | Bancos Nacionais dos EUA | Gestão de riscos de fornecedores; due diligence de terceiros | Não há proibição absoluta, mas são necessários planos de risco de concentração e de saída. |
A consequência prática para cargas de trabalho COBOL:
Um programa COBOL em lote que processa dados de contas de clientes da UE não pode ser migrado para uma região de nuvem fora da UE/EEE, a menos que a jurisdição do provedor de nuvem tenha recebido uma decisão de adequação ou que salvaguardas apropriadas (cláusulas contratuais padrão) estejam em vigor. O mesmo programa, processando apenas dados operacionais internos, possui muito mais flexibilidade.
Antes de definir o limite híbrido, toda organização regulamentada deve realizar uma classificação de dados em seu portfólio COBOL: quais programas acessam dados pessoais, quais acessam dados de titulares de cartões, quais acessam informações de saúde protegidas (PHI) e quais processam cálculos de capital regulatório. Essa classificação determina quais programas podem migrar livremente e quais devem permanecer dentro do limite de conformidade, independentemente da preferência técnica.
O problema de conformidade com COBOL que ninguém menciona
Os programas COBOL introduzem riscos de conformidade específicos da linguagem e da sua época, que as diretrizes genéricas de conformidade em nuvem não abordam. Esses riscos já existem em ambientes locais e se transformam em problemas de visibilidade em um ambiente híbrido, onde o auditor espera ver controles em ambos os lados da fronteira.
Lacunas no registro de auditoria. Os programas COBOL normalmente gravam em arquivos e bancos de dados sem registro de transações nativo. Uma atualização VSAM KSDS em COBOL não produz, por padrão, um registro imutável de quem alterou o quê, quando e de qual valor para qual valor. Em um ambiente regulamentado, isso representa uma lacuna de conformidade, e migrar um programa com essa lacuna para um ambiente híbrido onde a nuvem possui registro de auditoria moderno torna a lacuna mais visível, e não menos.
Credenciais e chaves de criptografia embutidas no código. Aplicações COBOL legadas frequentemente carecem de recursos modernos como controle de acesso baseado em funções, monitoramento em tempo real e protocolos de criptografia, tornando-as vulneráveis a ameaças cibernéticas sofisticadas. A análise estática de programas COBOL rotineiramente revela chaves embutidas no código, senhas na área de trabalho (WORKING-STORAGE) e strings de conexão incorporadas no código-fonte. Em um ambiente híbrido que precisa atender aos requisitos de gerenciamento de chaves PCI-DSS ou aos controles de criptografia HIPAA, esses padrões exigem correção antes da migração, não depois.
Reprodutibilidade dos cálculos. A aritmética decimal compactada do COBOL (COMP-3) possui características específicas de precisão e arredondamento. Um cálculo de capital regulatório que funciona corretamente no z/OS pode produzir resultados diferentes no Linux devido a diferenças no tratamento de decimais pelos compiladores. A diferença pode ser de centavos por transação ou pode ser significativa para um índice de capital. Ambientes híbridos que dividem os componentes de cálculo entre plataformas devem validar explicitamente a equivalência numérica.
Quatro padrões arquitetônicos híbridos para COBOL regulamentado
Diferentes cargas de trabalho regulamentadas exigem diferentes arquiteturas híbridas. Não existe um padrão universal, mas estas quatro abrangem a gama de situações que a maioria das organizações regulamentadas encontra.
Padrão 1: O Gateway de API de Limite de Conformidade
Ideal para: Organizações onde a lógica de negócios COBOL precisa permanecer em infraestruturas locais por motivos regulatórios, mas aplicativos modernos, análises e serviços voltados para o cliente podem ser migrados para a nuvem.
Os programas COBOL permanecem no mainframe. Uma camada de API simples, geralmente executada em infraestrutura próxima à nuvem ou dentro da rede privada da organização, expõe a funcionalidade COBOL como endpoints REST ou gRPC. Aplicativos baseados em nuvem acessam esses endpoints. O programa COBOL em si nunca é movido; o que muda é a interface com ele.
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 │
└─────────────────────┘ │ └──────────────────────────┘Vantagem de conformidade: Os dados regulamentados nunca cruzam a fronteira. O gateway de API lida com autenticação, autorização e registro na fronteira, fornecendo cobertura de trilha de auditoria que o próprio programa COBOL pode não gerar. A nuvem nunca processa dados regulamentados diretamente.
Requisito operacional: A camada de API deve ser projetada para lidar com o modelo síncrono de solicitação-resposta do COBOL. Tarefas em lote COBOL de longa duração exigem padrões assíncronos com mecanismos de retorno de chamada ou de sondagem, em vez de chamadas de API síncronas que expiram.
Padrão 2: Hierarquização de dados por sensibilidade regulatória
Ideal para: Organizações com dados regulamentados e não regulamentados no mesmo ambiente COBOL, onde os dados regulamentados podem ser separados dos dados operacionais.
Dados transacionais que acionam requisitos regulatórios, dados pessoais, dados de titulares de cartões e informações de saúde protegidas (PHI) permanecem no ambiente local. Dados agregados, anonimizados ou operacionais que não acionam restrições regulatórias são migrados para armazenamento e processamento em nuvem. Programas COBOL que geram resultados regulamentados continuam sendo executados no mainframe. Programas de geração de relatórios que consomem dados agregados são executados na nuvem.
Requisito crítico de implementação: A etapa de agregação e anonimização deve ser auditável. O processo que transforma dados regulamentados em dados não regulamentados para transmissão na nuvem deve ser registrado, testado e sujeito a seus próprios controles. Um processo de desidentificação que falhe sob condições específicas de entrada pode produzir dados na nuvem que inadvertidamente reidentificam indivíduos, uma violação do GDPR causada por uma arquitetura projetada para evitar tal violação.
Padrão 3: Validação de Execução Dupla
Ideal para: Organizações que estão migrando cargas de trabalho COBOL que realizam cálculos regulamentados, onde a equivalência funcional entre os sistemas antigo e novo precisa ser demonstrada a um órgão regulador antes da transição.
O programa COBOL original continua a ser executado no mainframe, processando dados em tempo real. Uma implementação paralela, replataformada ou reestruturada, é executada simultaneamente na infraestrutura de nuvem, processando os mesmos dados de entrada. As saídas são comparadas em tempo real. Discrepâncias são sinalizadas, investigadas e resolvidas antes que a implementação em nuvem seja certificada como o sistema oficial.
Valor de conformidade: A execução dupla satisfaz o requisito de equivalência demonstrável que os reguladores impõem às alterações em sistemas que realizam cálculos regulatórios. A organização pode apresentar ao auditor um registro de N meses de operação paralela, o processo de reconciliação aplicado às discrepâncias e a evidência de que o novo sistema produz resultados materialmente idênticos em todas as condições de entrada testadas.
Custo operacional: Operar dois sistemas em paralelo é caro. A execução dupla é um mecanismo de transição, não uma arquitetura permanente. O cronograma para concluir a validação e a migração deve ser especificado no plano do projeto e acordado com o órgão regulador competente, quando a aprovação prévia for necessária (como ocorre sob a DORA para alterações em funções críticas).
Padrão 4: Figueira-estranguladora com limite de conformidade
Ideal para: Organizações que estão desenvolvendo novas funcionalidades na nuvem, mantendo ao mesmo tempo as cargas de trabalho COBOL regulamentadas em infraestruturas locais a longo prazo, com um caminho de migração definido para cada carga de trabalho à medida que a certificação é obtida.
Novos recursos e funcionalidades voltadas para o cliente são desenvolvidos como serviços nativos da nuvem desde o início. As cargas de trabalho COBOL regulamentadas permanecem no ambiente local, acessadas por meio do padrão de gateway de API. Com o tempo, os programas COBOL individuais são certificados para implantação na nuvem, concluindo a validação de dupla execução, atendendo aos requisitos de pré-aprovação regulatória quando necessário e migrando para o lado da nuvem. O mainframe diminui progressivamente à medida que cada programa conclui sua certificação de conformidade.
Por que isso funciona para organizações regulamentadas: Permite a modernização acelerada de cargas de trabalho não regulamentadas, ao mesmo tempo que aplica o rigor apropriado às regulamentadas. O limite de conformidade é explícito, auditável e unidirecional. A organização pode demonstrar aos órgãos reguladores que cada carga de trabalho na nuvem passou por um processo de certificação definido e que cada carga de trabalho local possui um plano de certificação.
O que os auditores realmente perguntam sobre ambientes COBOL híbridos
A conformidade não é um estado, é um processo demonstrável. A questão não é se sua arquitetura híbrida está em conformidade. A questão é se você consegue provar isso para alguém cujo trabalho é encontrar problemas.
A seguir, apresentamos as perguntas que os auditores dos principais órgãos reguladores fazem no contexto de ambientes COBOL híbridos e as evidências que as respondem:
“Onde esses dados estão armazenados e em quais jurisdições?” Requisito: um mapa de dados atualizado mostrando todos os armazenamentos de dados, arquivos VSAM, tabelas DB2 e armazenamento de objetos na nuvem, com jurisdição, classificação e controles implementados. Os programas COBOL que gravam em conjuntos de dados devem aparecer neste mapa com suas saídas classificadas.
“Mostre-me o histórico de auditoria desta transação.” Requisito: um rastreamento de ponta a ponta, desde o início da transação até todos os sistemas que acessaram os dados, incluindo o programa COBOL que os processou. Se o programa COBOL não gerar seus próprios registros de auditoria, a infraestrutura subjacente deverá compensar essa limitação; essa função deve ser explicitamente projetada, e não presumida.
“O que acontece com suas funções críticas se o seu provedor de nuvem tiver uma interrupção?” Requisitos (DORA): cenários de resiliência operacional documentados, RPO e RTO testados para funções críticas e evidências de que os sistemas locais podem operar independentemente das dependências da nuvem durante o período especificado na política de resiliência da organização.
“Como você sabe que o sistema migrado produz os mesmos resultados que o original?” Requisitos: registro de reconciliação de execução dupla, cobertura de casos de teste e, para cargas de trabalho sensíveis a cálculos, uma análise de equivalência numérica.
“Quem pode acessar dados regulamentados na nuvem e quais aprovações regem esse acesso?” Requisitos: Documentação da política de IAM, registros de gerenciamento de acesso privilegiado e evidências de que os controles de acesso na nuvem são pelo menos tão restritivos quanto os do ambiente local.
Uma estrutura de decisão para definir a fronteira híbrida
Nem todos os programas COBOL pertencem ao mesmo lado da fronteira híbrida. Esta lista de verificação determina o posicionamento de cada carga de trabalho:
Migre para a nuvem sem restrições regulatórias:
- O programa não processa dados pessoais de indivíduos em jurisdições abrangidas pelo GDPR/nFADP.
- O programa não processa dados do titular do cartão (exclusão do escopo PCI-DSS confirmada)
- O programa não processa informações de saúde protegidas (exclusão do escopo da HIPAA confirmada).
- O programa não realiza cálculos que sejam utilizados como entrada para os índices de capital regulamentar.
- O programa não possui credenciais ou chaves de criptografia codificadas no código-fonte.
- Os resultados do programa não estão sujeitos a requisitos de residência de dados em nenhuma jurisdição.
É necessário um projeto de conformidade antes da migração para a nuvem:
- O programa gera ou processa dados pessoais; realize uma avaliação completa do impacto sobre os dados.
- O programa está em conformidade com o PCI-DSS, com SAQ/ROC completo para ambiente de nuvem.
- O programa realiza cálculos de capital regulatório e análises completas de equivalência numérica.
- O programa não gera trilhas de auditoria; projete controles compensatórios antes da migração.
- O programa contém chaves embutidas no código; corrija-as antes de expô-las ao caminho de rede na nuvem.
Deve permanecer nas instalações até a pré-aprovação regulatória:
- O programa é classificado como função crítica ou importante de acordo com a DORA.
- O programa está sujeito aos requisitos de resiliência operacional da FCA/PRA como um serviço comercial importante.
- O órgão regulador exigiu expressamente notificação ou aprovação prévia para alterações no sistema (comum em sistemas bancários centrais).
Como SMART TS XL Suporta o planejamento de arquitetura híbrida para COBOL regulamentado.
As decisões descritas neste guia — onde definir o limite de conformidade, quais programas processam dados regulamentados, quais contêm requisitos de remediação de segurança, quais executam funções de cálculo que precisam de validação de equivalência — exigem um conhecimento estrutural preciso de cada programa no portfólio COBOL. Esse conhecimento não pode ser presumido a partir da documentação. Em ambientes COBOL regulamentados, a documentação existente geralmente foi escrita para um sistema que foi modificado dezenas de vezes sem atualizações correspondentes na documentação.
SMART TS XL'S análise de código estático A pesquisa revela os padrões de segurança e conformidade no código-fonte COBOL que determinam a qual lado da fronteira híbrida cada programa pertence: credenciais embutidas no WORKING-STORAGE, gerenciamento de chaves de criptografia, geração (ou ausência) de logs de auditoria e padrões de cálculo que afetam o capital regulatório. Essas descobertas apoiam o trabalho de projeto de conformidade que deve preceder o posicionamento da fronteira híbrida para cargas de trabalho regulamentadas.
O mapeamento de dependências de aplicações mostra quais programas compartilham dados com quais outros, os padrões de acesso a conjuntos de dados entre programas que determinam se a implementação de um programa na nuvem cria um fluxo de dados regulamentado através da fronteira que não foi previsto. Um programa COBOL que aparentemente processa apenas dados operacionais pode ler um arquivo VSAM que também contém dados pessoais gravados por um programa diferente. O mapa de dependências torna esses relacionamentos de compartilhamento de dados visíveis antes mesmo da definição da fronteira híbrida.
A funcionalidade de análise de impacto torna as alterações de limites auditáveis: quando um programa é migrado de um ambiente local para a nuvem, a análise de impacto enumera todos os outros programas afetados por essa migração, os chamadores, os consumidores de conjuntos de dados e os fluxos de trabalho JCL , fornecendo o escopo da alteração como evidência para o órgão regulador e como base para o programa de testes de equivalência.
A funcionalidade de busca corporativa permite consultar o inventário de conformidade em todo o programa híbrido: encontre todos os programas que processam um tipo de dado específico, todos os programas que acessam um cluster VSAM específico, todos os arquivos-fonte COBOL que contêm um padrão específico, em milhões de linhas, em segundos. Para uma organização regulamentada que precisa demonstrar a um auditor que todos os programas abrangidos foram identificados e avaliados, esse inventário consultável é a evidência que substitui a atestação manual.
O órgão regulador não se importa com o seu cronograma de imigração.
A nuvem híbrida não é um estado temporário para organizações regulamentadas que utilizam COBOL. Para muitas delas, é o modelo operacional permanente, não por limitações técnicas, mas porque a estrutura regulatória que rege seus dados e suas funções exige controle local sobre cargas de trabalho específicas por tempo indeterminado. A pergunta correta não é "como nos livramos do mainframe", mas sim "quais cargas de trabalho podem migrar para a nuvem, sob qual arquitetura de conformidade e com quais evidências de que o controle de fronteira está sendo feito adequadamente".
As configurações híbridas oferecem às organizações a flexibilidade de manter componentes legados em infraestruturas locais, ao mesmo tempo que permitem integrações com a nuvem. Para setores regulamentados, essa flexibilidade não é opcional, mas sim obrigatória para categorias específicas de cargas de trabalho. As organizações que obtêm sucesso com arquiteturas híbridas de COBOL são aquelas que definem explicitamente o limite de conformidade, o instrumentam para auditoria desde o início e tratam a produção de evidências regulatórias como um requisito arquitetônico, e não como uma mera formalidade para fins de documentação.
