Algures dentro de um grande banco, uma equipa de engenheiros concluiu recentemente a tradução de dois milhões de linhas de COBOL para Java — uma migração que demorou catorze meses, passou por todas as suites de testes e entrou em produção dentro do prazo, apenas para a equipa de segurança descobrir na primeira semana que números de cartões de crédito, números de Segurança Social e saldos de contas estavam a fluir desprotegidos através de endpoints de API, de um pipeline Kafka e de um data lake de análise que a arquitetura original do mainframe nunca tinha exposto.
A modernização foi bem-sucedida, mas a proteção de dados não, e este cenário acontece com muito mais frequência do que a maioria das empresas estaria disposta a admitir.
Os investimentos na modernização de mainframes estão a acelerar, mas a conversa continua predominantemente focada na tradução de código, infraestrutura cloud e redução de custos, enquanto a segurança dos dados — o único fator que determina se um projeto de modernização cria ou elimina riscos — raramente recebe a atenção que merece até que algo falhe.
O problema do perímetro que a modernização cria
Os mainframes legados nunca foram concebidos para ser seguros no sentido moderno; foram concebidos para ser inacessíveis. Os ambientes IBM z/OS dependiam do isolamento físico, dos controlos de acesso RACF e da pura obscuridade da sua arquitetura para proteger dados sensíveis, e durante décadas os dados permaneceram dentro do perímetro porque não havia outro lugar para onde ir.
A modernização altera fundamentalmente esta equação, porque no momento em que uma organização migra uma aplicação COBOL para a cloud ou replica tabelas DB2 para um data warehouse, os dados sensíveis começam a cruzar fronteiras de confiança que nunca existiram antes, e cada novo ponto de integração — seja uma chamada de API, um pipeline de dados ou uma plataforma de análise downstream — torna-se uma superfície de ataque que o modelo de segurança original nunca foi criado para proteger.
O desafio é agravado pela idade destes sistemas — o código COBOL está fortemente acoplado a lógica de negócio que ninguém documenta completamente, os programadores que o escreveram estão a reformar-se, e praticamente todas as empresas que utilizam um mainframe partilham a mesma política: não instalar agentes, não modificar código de produção, não arriscar interromper cargas de trabalho que processam transações críticas para o negócio.
Porque a tradução de código por si só não é suficiente
As ferramentas de tradução de código assistidas por IA aceleraram o processo de migração — o que antes demorava anos pode agora ser concluído em meses — mas traduzir COBOL para Java ou Python não traduz os controlos de segurança que protegiam os dados enquanto estes se encontravam dentro do mainframe. Numa implementação típica de z/OS, a encriptação é tratada ao nível do hardware através de processadores criptográficos dedicados, o controlo de acesso é aplicado através de RACF ou ACF2, e os dados nunca saem sem passar por processos batch rigorosamente controlados.
Quando esses mesmos dados migram para um ambiente cloud-nativo, porém, o modelo de proteção muda completamente: os dados estão agora distribuídos por múltiplos serviços, regiões e fornecedores, e o âmbito de conformidade ao abrigo do PCI DSS, HIPAA e RGPD expande-se a todos os sistemas que tocam nos dados sensíveis depois de saírem do z/OS. Sem uma estratégia de proteção de dados concebida antes de a migração começar, as organizações descobrirão que não modernizaram tanto a sua segurança como migraram o seu risco.
Proteger os dados sem tocar no mainframe
As abordagens mais práticas para proteger dados durante e após a modernização operam ao nível da camada de rede em vez da camada de aplicação, e esta distinção é importante porque modificar aplicações COBOL legadas raramente é viável e instalar agentes em mainframes de produção introduz um risco operacional inaceitável. As soluções de proteção de dados sem agente intercetam os dados à medida que fluem entre o mainframe e os sistemas downstream — tokenizando, mascarando ou encriptando campos sensíveis em tempo real sem alterações ao código do mainframe, esquemas de bases de dados ou fluxos de trabalho existentes — e as melhores soluções de atualização e modernização de mainframes integram agora este tipo de segurança inline como um componente central em vez de uma consideração tardia.
A tokenização, em particular, emergiu como o método preferido para empresas que operam em ambientes de mainframe. Os tokens com preservação de formato mantêm a estrutura de dados que as verificações de validação legadas esperam — como a verificação de Luhn para números de cartões de crédito — enquanto eliminam a relação matemática entre o token e o valor original, o que significa que os tokens podem fluir através de pipelines cloud, plataformas de análise e integrações de terceiros sem expor dados sensíveis ou quebrar os sistemas downstream que dependem de formatos consistentes.
O que as empresas devem avaliar antes de migrar
As organizações que planeiam programas de modernização de mainframes devem avaliar a sua postura de segurança dos dados antes de a primeira carga de trabalho ser movida — especificamente, onde residem os dados sensíveis nas bases de dados do mainframe e nos repositórios de dados das aplicações, quais os caminhos de migração que irão expor esses dados a novos ambientes e como a proteção se manterá depois de os dados chegarem à cloud. As empresas que acertam na modernização tratam a segurança dos dados como uma restrição de conceção desde o primeiro dia, e não como uma caixa de verificação de conformidade aplicada retroativamente, enquanto as que erram tendem a descobrir — muitas vezes demasiado tarde — que construíram uma versão mais rápida, mais barata e, no total, mais vulnerável do que já tinham.
