☕ 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 ICSF. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta ICSF. Mostrar todas as mensagens

quinta-feira, 9 de abril de 2026

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

 

Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)


☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.


🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

  • RACF
  • SAF
  • E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso


🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

  • SAF → interface (o “porteiro”)
  • RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄


🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

  • Admin RACF → gerencia segurança
  • Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável


💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.


🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

  • Dados em disco
  • Dados em trânsito
  • Dados protegidos sem mudar aplicação

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

  • Master Keys → topo da cadeia
  • Symmetric → performance
  • Asymmetric → troca segura
  • Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.


⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express


🛡️ Níveis de proteção (isso é ouro de prova)

NívelSegurança
Clear Key😬
Protected Key👍
Secure Key🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)


💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

  • código malicioso
  • erro catastrófico

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

  • TCP/IP (moderno)
  • SNA (legado que ainda vive 😄)

Segurança:

  • TLS → camada transporte
  • IPSec → VPN (nível rede)

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar


🧪 Caso real (estilo Bellacosa)

Empresa com:

  • RACF instalado
  • Criptografia ativa
  • Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.


🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”


🔥 Frases pra tatuar no cérebro

  • “SAF conecta, RACF decide”
  • “Sem PROTECTALL, está exposto”
  • “Sem chave, não há segurança”
  • “ALL = mostra tudo”
  • “SPECIAL = poder total (cuidado!)”

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

  • Foi projetado assim
  • Evoluiu assim
  • Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.


☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

segunda-feira, 5 de janeiro de 2026

🔥 SEU RACF ESTÁ TE PROTEGENDO… OU TE TRAINDO?

 

Bellacosa Mainframe em uma conversa sobre segurança mainframe

🔥 SEU RACF ESTÁ TE PROTEGENDO… OU TE TRAINDO?

🧪 LAB PRÁTICO — Do Acesso Liberado ao Controle Total no z/OS


☕ Introdução — Bem-vindo ao caos controlado

Hoje você não vai só aprender…

👉 Você vai quebrar a segurança do sistema
👉 E depois consertar como um verdadeiro admin raiz

💡 Estilo Bellacosa:

“Se você nunca viu um sistema inseguro… você ainda não entendeu segurança.”


🎯 Objetivo do LAB

Você vai:

  • ❌ Criar um cenário inseguro (sem proteção)
  • 🔍 Explorar a falha
  • 🛡️ Corrigir com RACF
  • 🔐 Validar segurança

⚠️ Cenário

Você é admin e recebe:

“Precisamos liberar rápido o dataset PROD.FINANCEIRO.*”

😈 Spoiler: isso vai dar ruim.


🧪 FASE 1 — Criando o problema (sim, de propósito)

1️⃣ Criar dataset “sensível”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=PROD.FINANCEIRO.DADOS,
//      DISP=(NEW,CATLG),
//      SPACE=(TRK,(1,1)),
//      DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)

2️⃣ NÃO criar perfil RACF

👉 Sim… você vai deixar sem proteção

💡 Easter egg:

Isso acontece mais em produção do que você imagina 😅


3️⃣ Testar acesso com outro usuário

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Se PROTECTALL estiver OFF:

💥 Acesso permitido


💣 Resultado

Dataset crítico → sem perfil → acesso liberado 😱

🧠 REFLEXÃO

Você acabou de:

  • Criar uma falha real
  • Simular um incidente comum

👉 E ninguém hackeou nada


🛡️ FASE 2 — Corrigindo como profissional

1️⃣ Criar perfil de dataset

RDEFINE DATASET PROD.FINANCEIRO.* UACC(NONE)

2️⃣ Permitir acesso controlado

PERMIT PROD.FINANCEIRO.* CLASS(DATASET) ID(FINUSR) ACCESS(READ)

3️⃣ Ativar proteção

SETROPTS RACLIST(DATASET) REFRESH

4️⃣ (CRÍTICO) Ativar PROTECTALL

SETROPTS PROTECTALL

💥 Agora sim:

👉 Dataset sem perfil = acesso negado


🔍 FASE 3 — Validando segurança

Teste novamente:

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Resultado esperado:

ICH408I USER NOT AUTHORIZED

🔥 Agora você está protegido


⚙️ FASE 4 — Explorando comando “ALL”

LD DA('PROD.FINANCEIRO.*') ALL

👉 Vai mostrar:

  • Dono
  • Permissões
  • UACC
  • Detalhes completos

💡 Frase pra vida:

“ALL = mostra tudo. Sem ALL = você está voando no escuro.”


🔐 FASE 5 — Elevando nível com SPECIAL

Criar usuário admin

ADDUSER ADMIN1 SPECIAL

👉 Esse usuário pode:

  • Alterar tudo
  • Criar perfis
  • Controlar segurança

⚠️ Cuidado:

SPECIAL = poder total


⚙️ FASE 6 — Simulando programa privilegiado (APF)

👉 Imagine:

Um programa precisa acessar memória sensível

Sem APF:

❌ Falha

Com APF:

✅ Executa com privilégio

💡 Curiosidade:

Muitos ataques internos exploram programas mal autorizados no APF


🔐 FASE 7 — Criptografia (visão prática)

👉 Fluxo real:

App → ICSF → Crypto Express → dado protegido

Você não vê… mas está acontecendo.


📊 FASE 8 — Auditoria com SMF

👉 Tudo que você fez pode ser registrado:

  • Acesso ao dataset
  • Tentativas negadas
  • Alterações

💡 Mas só se estiver configurado 😉


🧠 Easter Eggs do LAB

  • PROTECTALL OFF = caos silencioso
  • UACC(READ) mal usado = vazamento
  • SPECIAL demais = bomba relógio
  • Sem log = sem prova

🏁 Checklist final

Você aprendeu:

  • ✔ Criar falha real
  • ✔ Corrigir com RACF
  • ✔ Controlar acesso
  • ✔ Validar segurança
  • ✔ Entender impacto

☕ Conclusão estilo Bellacosa

Segurança no mainframe não é:

  • ferramenta
  • comando
  • checklist

É:

Mentalidade.

Porque no final…

👉 O sistema nunca erra
👉 Quem erra é quem configura


🔥 Desafio final

Responda:

Seu ambiente hoje está protegido…
ou só parece?

 

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