 |
| Bellacosa Mainframe apresenta criptografia |
☕ Um Café no Bellacosa Mainframe
Criptografia sem Mistérios para Programadores COBOL
Quando um Programador Descobre que o AES-256 Nunca Levou um ABEND... Mas as Decisões da Arquitetura Derrubaram Todo o Sistema Antes do Primeiro EXEC CICS
"Não entre em pânico. Tenha sempre uma toalha... e nunca armazene a chave criptográfica no mesmo dataset dos dados."
— Guia do Viajante das Galáxias, edição especial para Administradores RACF.
Introdução
Existe uma velha piada entre administradores de sistemas:
"A criptografia é perfeita... até alguém colocar a senha em um arquivo TXT chamado SENHAS.TXT."
Parece brincadeira.
Mas praticamente todos os grandes vazamentos de dados dos últimos anos seguiram exatamente esse roteiro.
Pouquíssimos ataques realmente quebraram algoritmos criptográficos.
Quase todos contornaram a criptografia.
Isso muda completamente a forma como devemos enxergar segurança.
Durante décadas, aprendemos que bastava usar um algoritmo forte.
AES.
RSA.
SHA.
TLS.
Fim do problema.
Mas a realidade é muito mais interessante.
Na verdade, criptografia não é um software.
Também não é um hardware.
Muito menos um botão que alguém ativa.
Ela é uma decisão arquitetural.
E é justamente aí que mora o verdadeiro desafio.
Hoje vamos fazer uma viagem pelo universo da criptografia usando uma analogia que qualquer profissional de Mainframe consegue entender.
Prepare seu terminal 3270.
Pegue seu café.
Vamos descobrir por que um ambiente IBM Z parece muito mais com a Millennium Falcon do que você imaginava.
O Universo Não Quebra AES
Imagine a seguinte situação.
Você trabalha em um banco.
O banco anuncia:
"Todos os dados utilizam AES-256."
Excelente.
Mas logo depois você descobre que:
a chave AES está gravada em um arquivo JCL;
o backup está em texto puro;
o Load Balancer descriptografa tudo;
o administrador copia os datasets antes da criptografia.
Parabéns.
Você possui uma Ferrari estacionada numa garagem sem porta.
A Ferrari continua excelente.
Mas qualquer um entra e leva.
Essa é exatamente a diferença entre:
Segurança criptográfica
e
Segurança arquitetural.
A Criptografia é Como um Cofre
Imagine um enorme cofre de banco.
O aço possui 50 centímetros.
Blindagem militar.
Fechadura quântica.
Sensores.
Laser.
Tudo perfeito.
Agora imagine que alguém pendurou a chave do lado de fora.
Acabou.
Ninguém precisou explodir o cofre.
Apenas abriu a porta.
É exatamente isso que acontece diariamente em milhares de empresas.
Bellacosa Mainframe Explica
Vamos imaginar que um Data Center seja uma cidade.
No centro existe o Mainframe.
Ao redor:
CICS
Db2
MQ
RACF
z/OS
VSAM
IMS
APIs
Web Services
Todos conversam.
Todos trocam informações.
Todos precisam confiar uns nos outros.
Agora imagine que essa cidade tenha oito decisões importantes para sobreviver.
São exatamente as oito decisões mostradas na imagem.
Primeira Decisão — Escolhendo o Algoritmo
Todo iniciante acredita que criptografia significa:
AES.
Fim.
Mas escolher algoritmo é parecido com escolher linguagem de programação.
Você faria um sistema bancário novo usando COBOL de 1974 sem manutenção?
Provavelmente não.
Então por que ainda existem aplicações usando:
MD5
SHA-1
DES
RC4
Porque segurança envelhece.
Assim como hardware.
Assim como software.
Um algoritmo forte hoje pode virar legado amanhã.
Curiosidade
DES possuía apenas 56 bits.
Na década de 70 parecia impossível quebrar.
Hoje existem placas de vídeo domésticas capazes de fazer bilhões de operações por segundo.
O impossível virou exercício de laboratório.
Easter Egg nº 1
No universo Star Wars seria como proteger a Estrela da Morte usando apenas uma fechadura mecânica.
O problema nunca foi o aço.
Foi esquecer um pequeno ponto vulnerável...
Luke Skywalker agradece.
Segunda Decisão — Dados em Repouso
Imagine um VSAM.
Imagine um Db2.
Imagine milhares de datasets.
Agora imagine que alguém roubou o storage.
Sem criptografia:
todos os arquivos podem ser lidos.
Com criptografia:
o disco parece um monte de números aleatórios.
É exatamente isso que chamamos de:
Data at Rest.
No IBM Z isso evoluiu para algo espetacular.
Pervasive Encryption.
Em vez de perguntar:
"Quais dados devo criptografar?"
A IBM mudou a pergunta para:
"Por que ainda existe alguma informação sem criptografia?"
Essa mudança de filosofia foi revolucionária.
Curiosidade
Pervasive Encryption foi um dos maiores diferenciais apresentados no IBM z14.
Ela tornou possível criptografar praticamente todo o ambiente com impacto mínimo graças ao CPACF e aos aceleradores criptográficos.
Foi uma mudança de paradigma: a criptografia deixou de ser exceção e passou a ser o comportamento padrão.
Terceira Decisão — Dados em Trânsito
Muitos administradores antigos ainda pensam:
"Dentro da empresa ninguém invade."
Essa frase envelheceu muito mal.
Hoje existem:
Cloud.
Containers.
APIs.
Microservices.
Kubernetes.
Docker.
VPN.
Internet.
Zero Trust.
Tudo conversa.
Tudo trafega pela rede.
Logo...
Tudo precisa de TLS.
Inclusive entre servidores internos.
Analogia Bellacosa
Imagine vários programas COBOL.
Programa A
↓
Programa B
↓
Programa C
↓
MQ
↓
Db2
↓
IMS
Cada conversa precisa ser protegida.
Caso contrário basta alguém "escutar" a rede.
É como ouvir uma conversa telefônica.
Easter Egg nº 2
No Guia do Mochileiro das Galáxias existe um peixe Babel que traduz qualquer idioma.
TLS faz algo parecido.
Ele permite que dois sistemas conversem em segurança enquanto o restante do universo apenas observa ruído criptográfico.
Quarta Decisão — O Verdadeiro Tesouro São as Chaves
Aqui está o maior erro encontrado em auditorias.
Programadores fazem isto:
01 AES-KEY PIC X(32)
VALUE "123456789ABCDEF..."
Pronto.
A criptografia acabou.
Porque a chave virou parte do programa.
É como esconder a chave do cofre dentro do próprio cofre.
No Mainframe existe um verdadeiro "Banco Central das Chaves".
Ele chama-se:
ICSF.
Integrated Cryptographic Service Facility.
Ele conversa diretamente com:
Crypto Express.
CPACF.
RACF.
Certificados.
PKI.
Tokens.
Assinaturas digitais.
Toda a inteligência criptográfica mora ali.
Curiosidade
Crypto Express possui hardware resistente a ataques físicos.
Se alguém tentar abrir o equipamento, ele pode apagar automaticamente informações sensíveis armazenadas internamente.
É literalmente um cofre eletrônico.
Quinta Decisão — End-to-End Encryption
Imagine enviar uma carta.
Sem criptografia ponta-a-ponta.
Pessoa A
↓
Correios
↓
Carteiro
↓
Centro de Distribuição
↓
Destino
Todos conseguem abrir o envelope.
Agora imagine um envelope que somente o destinatário consegue abrir.
Nem o correio consegue.
Esse é o conceito de End-to-End Encryption.
WhatsApp.
Signal.
iMessage.
Todos utilizam esse princípio.
No ambiente corporativo isso reduz enormemente:
espionagem;
vazamentos internos;
ataques contra intermediários;
inspeção indevida de dados sensíveis.
Sexta Decisão — Backup Também é Produção
Essa talvez seja a maior surpresa para iniciantes.
Empresas gastam milhões protegendo produção.
Depois gravam backups em texto puro.
É como construir um bunker nuclear e deixar uma cópia da chave embaixo do tapete da recepção.
Backups precisam da mesma proteção que produção.
Ou até maior.
Porque normalmente contêm:
todos os clientes;
todos os históricos;
todos os documentos;
todas as senhas;
todas as contas.
Bellacosa Mainframe
DFSMS.
DFDSS.
Storage Protect.
FDR.
Fitas.
Cloud Object Storage.
Tudo isso também precisa de criptografia.
Não existe "backup seguro" sem gerenciamento correto de chaves.
Sétima Decisão — Onde o TLS Termina?
Essa é uma decisão de arquitetura.
Imagine:
Cliente
↓
HTTPS
↓
Load Balancer
↓
HTTP
↓
Servidor
O usuário vê o cadeado.
Mas internamente...
Tudo está aberto.
Agora imagine:
HTTPS
↓
Load Balancer
↓
HTTPS
↓
API Gateway
↓
HTTPS
↓
CICS
↓
HTTPS
↓
Db2
Muito melhor.
Quanto menor o trecho sem criptografia, menor a superfície de ataque.
O Conceito de Zero Trust
Durante décadas dizia-se:
"Confie na rede interna."
Hoje a filosofia mudou.
Zero Trust afirma:
Nunca confie. Sempre verifique.
Até mesmo um servidor interno precisa provar quem é.
Essa mentalidade se encaixa perfeitamente em ambientes híbridos, APIs e aplicações distribuídas.
Oitava Decisão — Nem Todo Dado Vale Ouro
Essa talvez seja a decisão mais inteligente.
Não adianta gastar recursos criptografando imagens públicas.
Mas:
CPF.
PIX.
Cartão.
Biometria.
Prontuário médico.
Credenciais RACF.
Tokens OAuth.
Esses precisam de proteção máxima.
Esse conceito chama-se:
Classificação da Informação.
Sem classificação não existe segurança eficiente.
A IA Mudou o Cenário
Em 2026 a Inteligência Artificial trouxe um novo desafio.
Os agentes de IA conseguem:
acessar APIs;
consultar bancos;
ler documentos;
consumir logs;
integrar sistemas.
Se eles receberem permissões excessivas, a criptografia pode continuar perfeita e, ainda assim, dados sensíveis serem expostos por meio de uma consulta autorizada.
Por isso surgiram conceitos como:
AI Governance;
Secret Management;
Identity Federation;
Least Privilege para Agentes;
Auditoria de Prompts;
Vaults para Credenciais.
A IA não precisa quebrar a criptografia.
Basta receber a chave por engano.
Criptografia no Universo IBM Z
O IBM Z foi projetado para tratar criptografia como parte da infraestrutura.
Entre seus principais recursos estão:
CPACF (Central Processor Assist for Cryptographic Function): aceleração criptográfica por hardware diretamente nos processadores, reduzindo o impacto de desempenho de operações como AES e SHA.
Crypto Express: módulos HSM dedicados para operações de alta segurança, geração e proteção de chaves, assinaturas digitais e criptografia assimétrica.
ICSF (Integrated Cryptographic Service Facility): camada de software que integra aplicações COBOL, CICS, Db2 e RACF aos recursos criptográficos do hardware.
RACF: controla autenticação, autorização e integra-se ao gerenciamento de certificados e políticas de acesso.
Pervasive Encryption: permite criptografar datasets, bancos de dados, sistemas de arquivos e outros recursos de forma transparente.
Essa combinação faz do IBM Z uma das plataformas mais robustas para ambientes regulados, como bancos, seguradoras e governos.
Passo a Passo para um Programador COBOL Iniciante
Se você está começando agora, siga uma evolução prática:
Entenda a diferença entre criptografia, hash e assinatura digital. Eles resolvem problemas diferentes.
Aprenda onde a criptografia é aplicada: dados em repouso, em trânsito e em uso.
Nunca codifique chaves diretamente no programa COBOL. Utilize serviços apropriados como ICSF ou um gerenciador de segredos.
Conheça TLS e certificados digitais, mesmo que seu foco seja desenvolvimento COBOL. Grande parte das integrações modernas depende deles.
Estude RACF e gerenciamento de identidades, pois autenticação e autorização caminham junto com a criptografia.
Entenda o papel do CPACF e do Crypto Express, percebendo como o hardware acelera e protege operações criptográficas.
Aprenda sobre Pervasive Encryption e como ela protege datasets e bancos de dados sem exigir alterações nas aplicações.
Estude Zero Trust. A arquitetura de segurança moderna assume que nenhum componente é confiável por padrão.
Curiosidades que Pouca Gente Conhece
Um hash (SHA-256) não é criptografia reversível. Seu objetivo é verificar integridade, não esconder dados.
AES é um algoritmo simétrico: a mesma chave cifra e decifra.
RSA e ECC são algoritmos assimétricos: utilizam pares de chaves pública e privada.
O TLS normalmente combina criptografia assimétrica (para troca segura de chaves) e simétrica (para transmissão eficiente dos dados).
O IBM Z consegue executar bilhões de operações criptográficas por dia com aceleração em hardware, protegendo transações financeiras em escala global.
Muitos ataques famosos exploraram credenciais roubadas ou segredos mal armazenados, e não fraquezas nos algoritmos criptográficos.
O Grande Easter Egg Bellacosa Mainframe
Imagine que o Data Center seja a nave USS Enterprise.
O RACF é o oficial de segurança.
O ICSF é o cofre da Federação.
O Crypto Express é o motor de dobra criptográfico.
O CICS é o centro de operações.
O Db2 é a memória da nave.
O MQ é o sistema de comunicações.
O CPACF é o computador que acelera tudo.
E o programador COBOL?
É o engenheiro-chefe, responsável por garantir que todas essas peças funcionem em perfeita harmonia.
Porque, no fim das contas, a segurança não depende apenas da tecnologia. Ela depende das decisões tomadas por quem projeta e desenvolve o sistema.
Conclusão
Existe uma frase muito conhecida na engenharia de software:
"Sistemas raramente falham por causa da tecnologia; eles falham por causa das decisões."
Na criptografia acontece exatamente o mesmo.
AES continua extremamente seguro.
TLS continua extremamente seguro.
SHA-256 continua extremamente seguro.
O que costuma falhar é a arquitetura construída ao redor deles.
Uma chave armazenada junto aos dados, um backup sem criptografia, um ponto de término TLS mal definido ou um segredo exposto em um repositório Git são suficientes para transformar uma infraestrutura sofisticada em um castelo de cartas.
Para o programador COBOL que está entrando no universo do IBM Z, a grande lição é compreender que segurança deixou de ser responsabilidade exclusiva do administrador de sistemas. Ela faz parte do ciclo completo de desenvolvimento, desde a escrita do primeiro EXEC CICS até a proteção dos datasets, APIs, certificados, backups e integrações.
Como diria o Guia do Viajante das Galáxias:
"Não entre em pânico."
Mas acrescente uma nova regra ao manual do viajante dos Data Centers:
"Nunca subestime o poder de uma boa decisão arquitetural. Os melhores algoritmos do mundo não conseguem proteger um sistema projetado para confiar em tudo."
É essa mentalidade — muito mais do que qualquer algoritmo isolado — que diferencia um simples desenvolvedor de um verdadeiro arquiteto de soluções seguras em ambientes IBM Mainframe.
