☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Crypto Express. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Crypto Express. Mostrar todas as mensagens

quarta-feira, 4 de setembro de 2019

☕💥 A Jornada do Padawan COBOL – Parte 9 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o call em cobol parte ix

☕💥 A Jornada do Padawan COBOL – Parte 9

Desvendando o Universo dos CALLs no Mainframe

JES2, SMF Internals, RMF, SRM, HiperSockets, Sysplex Distributor, Crypto Express, Telum AI e os Segredos dos Engenheiros IBM

Ou como descobrir que existe um universo inteiro trabalhando em silêncio enquanto seu COBOL executa um simples CALL

Por Vagner Bellacosa – Bellacosa Mainframe


O Dia em que o Padawan Descobre que o Mainframe Nunca Dorme

Depois de nove cafés, oito artigos, alguns S0C4 e incontáveis CALLs, o Padawan finalmente acredita que compreendeu o Mainframe.

Até que um Sysprog abre um painel do SDSF.

E mostra:

D A,L

D XCF

D OMVS

D WLM

D ASM

D SMF,O

Padawan:

— O que é isso?

Sysprog:

— Apenas o coração do z/OS batendo.


JES2

O Grande Mestre dos Jobs

Muitos desenvolvedores acreditam que JCL executa programas.

Na verdade não.

JCL conversa com JES.

JES conversa com o Initiator.

Initiator conversa com LE.

LE conversa com o programa.


Visualmente

JCL

↓

JES2

↓

Initiator

↓

LE

↓

COBOL

↓

CALL

↓

SUBPGM

O que JES2 faz?

Fila Jobs

Spool

Classes

Routing

Prioridades

Output

SYSOUT

Checkpoint


O easter egg

Existe banco executando:

300 mil jobs/dia

E JES2 nem sua.


SMF

O Diário do Mainframe

Padawan acha que logs são:

LOG4J

Splunk

ELK

CloudWatch

IBM criou algo décadas antes.

SMF.


SMF registra praticamente tudo.


Exemplos

SMF30

Batch

SMF70

CPU

SMF72

WLM

SMF110

CICS

SMF116

MQ

SMF101

DB2


Exemplo

SMF30

Programa

CPU

Elapsed

EXCP

Storage

RC

RMF

Resource Measurement Facility


O médico do Mainframe.


Ele mede:

CPU

I/O

Canal

Memória

Coupling Facility

WLM


Padawan pergunta:

— Meu programa está lento.

RMF responde:

— Seu programa está esperando disco.


SRM

System Resource Manager

Pouca gente conhece.

Mas todos usam.


SRM decide:

Quem usa CPU.

Quem espera.

Quem recebe prioridade.


Visualmente

Banco


↑


SRM


↓


Teste




WLM

Já vimos.

Mas agora profundamente.


Workload Manager


Ele pensa:

Cliente VIP?

Alta prioridade.

Teste?

Espera.


Exemplo

Classe A


99%



Classe B


40%



Classe C


10%

HiperSockets

Uma maravilha IBM.


Rede interna.

Sem cabo.

Sem switch.


LPAR

fala com

LPAR

pela memória.


Visualmente

LPAR A


====


MEMÓRIA



====


LPAR B

Latência?

Ridícula.


Sysplex Distributor

Balanceador.

IBM style.


Recebe.

Distribui.

Escolhe melhor LPAR.


Como um:

Nginx

Mas muito caro.

E muito bonito.


Crypto Express

O guardião.

Do reino.


Hardware dedicado.

Criptografia.


PIX

TLS

SSL

JWT

Open Banking


Tudo passa aqui.


Telum

IBM surpreendeu.


CPU

com IA.

No chip.


Exemplo

Fraude.

Cartão.

Pix.

Score.


Tempo.

Milissegundos.


O CALL invisível

Padawan escreve:

CALL 'AUTORIZA'

Na prática.

Pode envolver:

COBOL


↓

CICS


↓

MQ


↓

DB2


↓

Crypto Express


↓

Telum


↓

Sysplex


↓

CF


↓

Resposta




Enclave SRBs

Território avançado.


Permitem.

Executar trabalho.

Em engines especiais.


zIIP.

Ama isso.


Performance extrema

Veteranos observam:

SMF72

RMF

APA

Strobe


Exemplo

Programa

CPU

8 segundos

Após ajuste

500 ms


Como?

Mover.

XML.

Para zIIP.


Melhorar.

Storage.

Buffer.


Ajustar.

WLM.


Checklist Bellacosa

Dica 1

Leia SMF.


Dica 2

Aprenda RMF.


Dica 3

Conheça JES.


Dica 4

Use HiperSockets.


Dica 5

WLM é obrigatório.


Dica 6

Entenda Telum.


Dica 7

Crypto Express é fascinante.


Easter Egg Mainframe

Existe um pequeno grupo.

Capaz de olhar:

RMF Monitor III


SMF72


CF Activity


WLM Delay


SRB Time


E descobrir.

Em cinco minutos.

Por que um sistema bancário inteiro ficou lento.


Eles recebem muitos telefonemas.

Muito café.

Pouco reconhecimento.


São conhecidos.

Como:

Os Engenheiros IBM Z


Filosofia Jedi da Parte 9

O Padawan iniciante acredita:

Meu programa executa sozinho.

O desenvolvedor experiente pensa:

Meu programa depende do sistema.

O Mestre Mainframe entende:

Nenhum CALL existe isoladamente.

Ele depende de:

  • JES2

  • LE

  • WLM

  • SRM

  • RMF

  • SMF

  • XCF

  • Sysplex

  • Coupling Facility

  • Crypto Express

  • Telum AI

  • zIIP

  • HiperSockets

E o Arquiteto Supremo IBM Z sabe que, quando um desenvolvedor digita:

CALL 'SUBPGM'

ele está acionando silenciosamente décadas de engenharia IBM, dezenas de subsistemas, hardware especializado e mecanismos refinados durante mais de meio século, permitindo que bilhões de transações sejam executadas todos os dias com disponibilidade que continua sendo referência para toda a indústria.


Próxima aventura do Padawan COBOL – Parte 10

"As Últimas Runas do IBM Z: Telum II, Spyre AI Accelerator, Quantum Safe Cryptography, z/OS Connect Enterprise Edition, OpenTelemetry, Ansible, Zowe, DevOps e a Nova Ordem dos Arquitetos IBM Z."


segunda-feira, 2 de abril de 2018

IBM Mainframe Discovery : Capítulo IV — A Sala dos Cofres Cósmicos

 

Bellacosa Mainframe apresenta o ibm mainframe parte IV

☕ Um Café no Bellacosa Mainframe

Capítulo IV — A Sala dos Cofres Cósmicos

Segurança no IBM Z: Por Que os Guardiões Dormem Tranquilos


PRIMEIRA REGRA DA SEGURANÇA INTERGALÁCTICA

Se alguém disser:

"Nossa nave nunca será invadida."

...desconfie imediatamente.

Porque o Universo possui uma característica curiosa.

Ele é povoado por três tipos de seres.

Os inteligentes.

Os curiosos.

E os curiosamente inteligentes.

Infelizmente, o terceiro grupo costuma dedicar boa parte da vida tentando descobrir como entrar onde não foi convidado.

Foi pensando nesses exploradores inconvenientes que nasceu uma das arquiteturas de segurança mais sofisticadas da história da computação.

Bem-vindo ao setor mais protegido da nave IBM Z.


A Fortaleza Invisível

Imagine uma gigantesca cidade espacial.

Nela existem:

Hospitais.

Bancos.

Laboratórios.

Centrais de energia.

Hangar militar.

Sala do comandante.

Agora imagine que todas essas instalações estão abertas.

Sem portas.

Sem crachás.

Sem vigilância.

Quanto tempo levaria até surgir o primeiro desastre?

Provavelmente menos tempo do que um operador leva para digitar:

TSO LOGON

Segurança Não Começa na Senha

Esse talvez seja o maior erro cometido por iniciantes.

Pensam que segurança significa:

senha.

Na verdade...

senha é apenas a campainha da porta.

O verdadeiro sistema de segurança está muito além.

Ele envolve:

identidade.

autorização.

criptografia.

hardware.

isolamento.

auditoria.

integridade.

No IBM Z, segurança nunca foi um programa instalado depois.

Ela faz parte da própria arquitetura.


O Bairro Proibido

Imagine nossa nave dividida em milhares de compartimentos.

Cada porta possui uma cor diferente.

Você recebeu uma chave azul.

Isso significa que pode abrir:

portas azuis.

Nada mais.

Mesmo que descubra onde está a sala do capitão...

...a porta simplesmente não abrirá.

Essa é exatamente a filosofia do Hardware Storage Key Protection.


As Chaves da Memória

Aqui encontramos um recurso extraordinário.

Cada bloco de memória de 4 KB recebe uma chave de proteção.

Quando um programa tenta acessar esse bloco...

o hardware pergunta:

— Sua chave corresponde à chave desta área?

Se sim...

entrada permitida.

Caso contrário...

acesso negado.

Tudo isso acontece diretamente no hardware.

Sem depender do sistema operacional.

Segundo Spruth, essa proteção praticamente impede que um programa comum sobrescreva áreas privilegiadas da memória, reduzindo drasticamente riscos como buffer overflows em regiões críticas do sistema.


O Guarda Nem Precisa Pensar

Observe algo interessante.

O processador não pergunta:

"Será que esse programa é confiável?"

Ele apenas compara chaves.

É rápido.

Determinístico.

Matemático.

Não existe interpretação.

Isso torna a segurança extremamente eficiente.


O Labirinto dos Buffer Overflows

Imagine uma biblioteca.

Cada sala possui paredes extremamente resistentes.

Você pode encher uma estante de livros.

Mas ela nunca atravessará a parede para invadir a sala vizinha.

Foi exatamente essa ideia que inspirou a proteção por Storage Keys.

Em muitas plataformas, erros de programação permitiram durante décadas que um processo escapasse de sua área de memória.

No IBM Z isso sempre foi muito mais difícil.


O Cofre Dentro do Cofre

Agora imagine que existe uma sala secreta.

Dentro dela há outro cofre.

Dentro desse cofre existe uma pequena caixa.

Dentro da caixa está a chave do banco da galáxia.

Parece exagero?

Não para quem administra bilhões de dólares diariamente.

É aqui que entra a criptografia do IBM Z.


Dois Magos da Criptografia

O relatório apresenta dois personagens extremamente importantes.

O primeiro é:

CPACF

(CP Assist for Cryptographic Functions)

Ele vive dentro da própria CPU.

Sua missão é acelerar algoritmos criptográficos.

O segundo é:

Crypto Express

Uma placa especializada.

Muito mais poderosa.

Muito mais protegida.

Cada uma possui responsabilidades diferentes.

Enquanto o CPACF acelera operações criptográficas diretamente no processador, o Crypto Express executa funções avançadas envolvendo gerenciamento seguro de chaves, assinaturas digitais, geração de números aleatórios e criptografia assimétrica.


A Chave Que Nunca Sai do Cofre

Este talvez seja o conceito mais elegante de todo o capítulo.

O nome é:

Master Key.

Imagine um rei.

Ele nunca sai do castelo.

Nunca participa das batalhas.

Nunca atravessa fronteiras.

Todas as outras chaves viajam.

Mas o rei permanece protegido.

No IBM Z acontece exatamente isso.

A Master Key permanece armazenada dentro do hardware criptográfico.

Ela nunca aparece em memória.

Nunca vai para disco.

Nunca é enviada pela rede.

Segundo o relatório, apenas cópias criptografadas das chaves de aplicação circulam pelo sistema; sua descriptografia ocorre exclusivamente dentro do coprocesso seguro.


O Cofre Autodestrutivo

Agora imagine que alguém tente abrir esse cofre usando uma furadeira.

Ou calor.

Ou eletricidade.

Ou qualquer outro ataque físico.

O que acontece?

O cofre destrói imediatamente seu segredo.

Parece filme.

Mas é engenharia.

As placas Crypto Express utilizam módulos resistentes à violação física (Tamper Resistant Security Module).

Caso detectem tentativa de invasão, podem apagar automaticamente as chaves armazenadas.


A Grande Biblioteca das Permissões

Até agora falamos sobre hardware.

Mas alguém precisa decidir:

Quem pode fazer o quê?

É aqui que encontramos dois dos personagens mais famosos do z/OS.


SAF — O Porteiro da Nave

Imagine um enorme edifício.

Em cada porta existe um segurança.

Mas esse segurança não toma decisões.

Ele apenas pergunta:

— Posso deixar esta pessoa entrar?

Quem responde?

Outro departamento.

Esse segurança chama-se:

SAF.

Security Authorization Facility.

Ele identifica eventos de segurança e encaminha a decisão ao mecanismo responsável pela autorização.


RACF — O Conselho Galáctico

O verdadeiro juiz chama-se:

RACF

(Resource Access Control Facility).

Imagine um gigantesco livro de regras.

Ele contém milhões de decisões.

Quem pode acessar:

arquivos.

programas.

transações.

impressoras.

bancos.

datasets.

comandos.

Cada tentativa de acesso consulta esse conjunto de perfis e regras.

Spruth observa que o RACF utiliza perfis e mecanismos de autorização extremamente granulares, tornando-se um dos pilares da segurança no z/OS.


APF — O Conselho dos Mestres

Existe um erro muito comum.

Pensar que todo programa privilegiado deveria ter acesso total.

No IBM Z isso seria considerado um péssimo projeto.

Surge então o:

Authorized Program Facility

APF.

Imagine uma nave.

Alguns oficiais podem abrir a sala de máquinas.

Outros podem acessar o hangar.

Pouquíssimos chegam ao núcleo do reator.

Cada um recebe apenas os privilégios necessários.

Nada além disso.

Segundo Spruth, o APF funciona como um guardião da integridade do sistema, permitindo que apenas programas autorizados utilizem determinados serviços privilegiados do z/OS.


O Pecado Mortal: Dar Poder Demais

Em muitos sistemas operacionais existe apenas:

Administrador.

Usuário.

Fim.

No IBM Z a filosofia é diferente.

Autorizações são extremamente específicas.

Esse princípio ficou conhecido muitos anos depois como:

Princípio do Menor Privilégio.

Curiosamente...

o Mainframe já vivia isso muito antes do termo virar moda.


A Cidade Que Nunca Dorme

Imagine bilhões de habitantes.

Todos entrando.

Saindo.

Movimentando dinheiro.

Consultando informações.

Transferindo recursos.

Como saber quem fez cada ação?

Resposta:

auditoria.

Embora o relatório foque principalmente em SAF, RACF e APF, toda essa arquitetura trabalha em conjunto com mecanismos de registro e rastreabilidade do z/OS, permitindo acompanhar eventos relevantes de segurança.

Porque segurança sem auditoria é apenas esperança.


Um Curioso Comentário de Spruth

Há uma frase no relatório que chama atenção.

O autor comenta que não conhecia casos de infecção por vírus ou ataques bem-sucedidos comprometendo sistemas z/OS na época em que escreveu o documento.

Hoje sabemos que nenhum sistema deve ser considerado absolutamente imune.

As ameaças evoluem constantemente.

Ainda assim, o histórico do IBM Z continua sendo um dos mais sólidos da indústria, justamente porque sua arquitetura foi concebida com isolamento, controle de acesso e defesa em profundidade.


O Que Mudou Desde 2010?

Desde a publicação do relatório, o ecossistema IBM Z ganhou novos recursos importantes:

  • algoritmos criptográficos mais modernos;

  • suporte ampliado para curvas elípticas e TLS atualizado;

  • integração com autenticação multifator;

  • criptografia preparada para desafios futuros;

  • Secure Execution para cargas Linux;

  • gerenciamento avançado de certificados;

  • proteção de APIs;

  • integração com ambientes híbridos e Zero Trust.

Mas observe algo curioso.

Os princípios fundamentais permanecem exatamente os mesmos.


A Filosofia dos Antigos Engenheiros

Os engenheiros do System/360 pareciam seguir uma máxima curiosa.

Não confie em ninguém.

Nem no usuário.

Nem no operador.

Nem no programa.

Nem no hardware.

Nem no futuro.

Cada camada protege a próxima.

Cada componente verifica o anterior.

Cada privilégio precisa ser justificado.

É quase como construir uma nave supondo que, em algum momento, alguém inevitavelmente tentará entrar onde não deveria.


Curiosidades do Diário de Bordo

🔐 O IBM Z incorporou mecanismos de proteção em hardware décadas antes de muitos conceitos modernos de segurança se popularizarem.

🛡️ Storage Keys, APF, SAF e RACF formam uma cadeia de proteção em camadas, onde cada elemento tem uma função específica.

🔑 A Master Key jamais precisa sair do hardware criptográfico, reduzindo drasticamente o risco de exposição.

🌌 Segurança, no universo IBM Z, nunca foi tratada como um produto adicional. Ela faz parte da própria fundação da arquitetura.


Diário de Bordo do Padawan COBOL

Antes de deixar o setor de segurança da nave, registre estas coordenadas:

✅ Segurança começa na arquitetura, não na tela de login.

✅ Quanto menos privilégios um programa possuir, menor será o impacto de uma eventual falha.

✅ Criptografia eficiente depende tanto da proteção das chaves quanto dos algoritmos utilizados.

✅ A melhor defesa não é impedir que todos tentem entrar; é construir um sistema onde cada porta saiba exatamente quem pode atravessá-la.

No próximo capítulo seguiremos para um dos compartimentos mais fascinantes de toda a nave: o Subsistema de Entrada e Saída (I/O). Descobriremos por que, enquanto muitos computadores fazem a CPU esperar pelos discos, o IBM Z decidiu entregar essa missão a uma verdadeira frota de especialistas — transformando o I/O em uma operação digna de uma logística interplanetária.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

Capítulo V — A Frota Invisível do Transporte Interestelar

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

Abrir artigo

quarta-feira, 3 de agosto de 2016

Criptografia : Quando um Programador Descobre que o AES-256 Nunca Levou um ABEND

 

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:

  1. Entenda a diferença entre criptografia, hash e assinatura digital. Eles resolvem problemas diferentes.

  2. Aprenda onde a criptografia é aplicada: dados em repouso, em trânsito e em uso.

  3. Nunca codifique chaves diretamente no programa COBOL. Utilize serviços apropriados como ICSF ou um gerenciador de segredos.

  4. Conheça TLS e certificados digitais, mesmo que seu foco seja desenvolvimento COBOL. Grande parte das integrações modernas depende deles.

  5. Estude RACF e gerenciamento de identidades, pois autenticação e autorização caminham junto com a criptografia.

  6. Entenda o papel do CPACF e do Crypto Express, percebendo como o hardware acelera e protege operações criptográficas.

  7. Aprenda sobre Pervasive Encryption e como ela protege datasets e bancos de dados sem exigir alterações nas aplicações.

  8. 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.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...