✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Git
↓
Commit
↓
Jenkins
↓
DBB
↓
Compile
↓
Unit Test
↓
Deploy
↓
Production
Galasa
Poucos conhecem.
Fantástico.
Testes automatizados.
CICS.
Batch.
MQ.
DB2.
OpenAPI
Hoje.
COBOL pode gerar.
Swagger.
Cliente.
Nem imagina.
Que existe COBOL.
Ele apenas vê.
POST
/api/pix
Observabilidade
Palavra bonita.
Muito importante.
Métricas.
Logs.
Traces.
Exemplo.
CALL CPFVAL
32 ms
SQL
8 ms
MQ
2 ms
API
15 ms
Problema resolvido.
Rapidamente.
Platform Engineering
Nova moda.
IBM já fazia.
Há décadas.
Sysplex.
WLM.
Automation.
Provisioning.
Hoje ganhou.
Nome bonito.
IA para Mainframe
Já existe.
Watsonx.
Copilot.
Assistentes.
Análise código.
Exemplo.
Perguntar.
Por que este COBOL deu S0C7?
IA responde.
Sugere correção.
Easter Egg IBM
Existe um grupo.
De profissionais.
Que conseguem.
Usar.
COBOL.
Git.
Zowe.
Ansible.
Terraform.
Kubernetes.
OpenTelemetry.
IA.
MQ.
DB2.
Assembler.
E ainda.
Conseguem.
Explicar tudo.
Em um café.
São conhecidos.
Como.
Arquitetos da Nova Ordem IBM Z
Checklist Jedi
✅ Estudar Telum II
✅ Conhecer Spyre
✅ Aprender OpenTelemetry
✅ Instalar Zowe
✅ Conhecer DBB
✅ Automatizar com Ansible
✅ Explorar Galasa
✅ Entender Quantum Safe
✅ Aprender Git
✅ Integrar APIs
✅ Testar IA
A Filosofia Jedi da Parte 10
O Padawan iniciante acredita:
Mainframe é legado.
O desenvolvedor intermediário pensa:
Mainframe é estável.
O especialista compreende:
Mainframe é uma plataforma moderna.
O Arquiteto IBM Z entende algo ainda maior:
O Mainframe nunca foi uma tecnologia presa ao passado.
Ele apenas teve a rara capacidade de continuar evoluindo sem descartar aquilo que funciona.
Enquanto muitas plataformas nasceram, cresceram e desapareceram em poucas décadas, o IBM Z continuou refinando sua arquitetura, incorporando criptografia avançada, IA embarcada, observabilidade, DevOps, APIs, automação e aceleração de inferência, mantendo a mesma promessa feita há mais de cinquenta anos:
Processar o trabalho mais importante do planeta com segurança, disponibilidade e eficiência.
Próxima aventura do Padawan COBOL – Parte 11
"As Crônicas Perdidas do IBM Z: GRS, ENQ/DEQ, RESERVE, Catalog Internals, VVDS, VTOC, UCB, IOS, Channel Subsystem, FICON, PDFs, PIDB e os mistérios que poucos Sysprogs ousam explorar."
Requests, Responses, HTTP, JSON, autenticação, autorização, Test Data, ambientes, segurança, automação e aquele 200 OK que jurava que estava tudo bem
Há uma regra que aprendi depois de muitos anos diante de terminais verdes, JCLs, CICS, dumps, arquivos VSAM e bancos de dados:
quando um sistema diz que está tudo bem depressa demais, comece a desconfiar.
John Constantine provavelmente concordaria.
Constantine não é exatamente o sujeito que você chama quando a torneira está vazando. Ele aparece quando a torneira começa a falar latim, o encanador desaparece e alguém encontra um pentagrama desenhado atrás da caixa-d'água.
Com APIs acontece algo semelhante.
Você manda:
GET /customers/42
e recebe:
HTTP/1.1 200 OK
O programador iniciante sorri.
Constantine acende um cigarro imaginário, olha para o monitor e pergunta:
— OK para quem?
Essa é a pergunta que guiará nossa investigação.
Porque uma API pode responder 200 OK enquanto devolve os dados errados. Pode autenticar João e entregar os registros de Maria. Pode registrar uma compra duas vezes. Pode diminuir o estoque três vezes. Pode devolver um CPF que jamais deveria estar naquela resposta.
E existe algo ainda mais diabólico.
Às vezes o sistema está certo...
...e o teste é que está errado.
Bem-vindo ao submundo de API Testing.
🕯️ CAPÍTULO 1 — O que diabos é uma API?
API significa:
Application Programming Interface.
Uma definição simples seria:
uma interface que permite que dois componentes de software se comuniquem seguindo regras previamente estabelecidas.
O exemplo clássico é o restaurante.
Temos:
CLIENTE
↓
GARÇOM
↓
COZINHA
O cliente não entra na cozinha para preparar o prato.
Ele faz um pedido.
O garçom leva esse pedido à cozinha.
A cozinha trabalha.
O garçom retorna com o resultado.
No mundo computacional:
APLICAÇÃO
↓
API
↓
SERVIDOR
Uma aplicação meteorológica poderia solicitar:
GET /weather?city=Itatiba
e receber:
{
"temp": 28,
"condition": "Cloudy"
}
A aplicação não precisa saber como o servidor calculou aquilo.
GET → consultar
POST → criar/processar
PUT → substituir
PATCH → alterar parcialmente
DELETE → remover
Uma sequência CRUD poderia ser:
POST /users
GET /users/42
PATCH /users/42
DELETE /users/42
Mas cuidado com uma simplificação comum.
HTTP não é CRUD.
Podemos perfeitamente encontrar:
POST /payments/123/capture
Nesse caso não estamos simplesmente dizendo "CREATE".
Estamos solicitando uma operação de negócio.
Existem ainda métodos como HEAD e OPTIONS, e os métodos permitidos também fazem parte da superfície que merece testes de segurança. A OWASP recomenda verificar métodos HTTP disponíveis e controles de acesso associados, inclusive tentando operações com métodos alternativos quando apropriado.
e consegue reconstruir a passagem daquela transação pelos diversos componentes.
Nos sistemas distribuídos, correlação é praticamente trabalho de detetive.
👹 CAPÍTULO 7 — Os números da besta... HTTP
Não é exatamente 666.
Temos famílias:
1xx → informacional
2xx → sucesso
3xx → redirecionamento
4xx → problema relacionado à requisição/cliente
5xx → falha do lado servidor
Alguns velhos conhecidos:
200 OK
201 Created
204 No Content
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
429 Too Many Requests
500 Internal Server Error
503 Service Unavailable
Mas existe uma distinção especialmente importante:
401 ≠ 403
Simplificando:
401 — você não está adequadamente autenticado.
403 — sabemos quem você é, mas você não pode fazer aquilo.
É a diferença entre Constantine chegar à porta sem a chave e chegar com a chave correta de uma sala para a qual ele continua não tendo autorização.
🧿 CAPÍTULO 8 — Authentication não é Authorization
Temos duas perguntas:
AUTHENTICATION
Quem é você?
AUTHORIZATION
O que você pode fazer?
Considere:
João → autenticado
Maria → autenticada
Isso não significa:
João → pode consultar dados privados de Maria
Teste:
GET /users/43
Authorization: Bearer TOKEN_DO_JOAO
Se 43 pertence a Maria e João não possui autorização para acessar aquele objeto, a aplicação precisa impedir o acesso.
Esse tipo de vulnerabilidade é importante o bastante para aparecer como Broken Object Level Authorization — BOLA no OWASP API Security Top 10.
O teste profissional, portanto, não pergunta apenas:
Tenho token?
Pergunta:
TOKEN A pode acessar RECURSO A?
TOKEN A pode acessar RECURSO B?
TOKEN B pode acessar RECURSO A?
USER pode executar operação ADMIN?
ADMIN pode?
GET é permitido?
DELETE também?
PATCH?
É uma matriz.
ATOR × RECURSO × AÇÃO
A OWASP descreve justamente esse modelo ator–recurso–ação como uma forma útil de representar e automatizar testes de autorização.
🧪 CAPÍTULO 9 — Positive, Negative e Boundary Testing
Suponha:
idade permitida = 18 até 60
Teste positivo:
25 → ACCEPT
Teste negativo:
"CONSTANTINE" → REJECT
Agora vêm os limites:
17
18
60
61
Por quê?
Porque um humilde:
IF WS-AGE > 18
em vez de:
IF WS-AGE >= 18
pode mandar o jovem de exatamente 18 anos diretamente para o purgatório da regra de negócio.
Os bugs adoram morar nas fronteiras.
Isso vale para:
quantidade
tamanho de senha
valor financeiro
número de itens
datas
paginação
strings
limites de crédito
Sempre pergunte:
o que acontece exatamente antes, exatamente no limite e exatamente depois?
🧟 CAPÍTULO 10 — Um erro correto também é PASS
Esta é deliciosa.
Mandamos:
{}
para uma operação que exige email.
Esperamos:
400
ou talvez 422, conforme o contrato adotado.
E algo como:
{
"code": "EMAIL_REQUIRED",
"message": "Email is required",
"field": "email"
}
Se a aplicação rejeitar corretamente a requisição inválida...
o teste passou.
Parece contraditório somente enquanto confundimos:
API retornou erro
com:
TESTE falhou
Um teste negativo pode perfeitamente produzir:
HTTP ERROR + TEST PASS
O que seria ruim?
Enviar uma requisição inválida e receber:
500 Internal Server Error
quando o contrato previa uma rejeição controlada.
Ou pior:
400 Bad Request
mas metade da transação já foi gravada.
Constantine abre o banco de dados.
E encontra o demônio escondido lá.
🏦 CAPÍTULO 11 — COMMIT e ROLLBACK entram no exorcismo
Em vez de amarrar recursos diretamente ao programa, usamos mecanismos externos de configuração.
No JCL:
//CLIENTE DD DSN=BELLACOSA.QA.CLIENTES,DISP=SHR
e posteriormente:
//CLIENTE DD DSN=BELLACOSA.PROD.CLIENTES,DISP=SHR
O programa não precisa ser recompilado porque mudamos de dataset.
O mesmo princípio reaparece no mundo moderno:
separe código de configuração.
☠️ CAPÍTULO 15 — .env não é um círculo mágico
Um arquivo:
.env.qa
pode conter configuração de QA.
Ótimo.
Mas cuidado:
.env ≠ Secret Vault
Colocar:
PASSWORD=123456
TOKEN=abc123
fora do source principal não torna magicamente esses valores seguros.
Segredos exigem tratamento apropriado durante armazenamento, distribuição, utilização, logging e rotação. A OWASP recomenda evitar segredos hardcoded, minimizar sua exposição e usar soluções adequadas de gestão de segredos conforme a arquitetura.
E jamais faça:
console.log(token);
e depois mande o log inteiro para:
CI REPORT
LOG SERVER
EMAIL
SLACK
ARQUIVO
Você acabou de transformar observabilidade em distribuição de credenciais.
👥 CAPÍTULO 16 — O fantasma chamado USER_ID=42
Suponha que todos os testes utilizem:
USER_ID=42
Pipeline A:
altera usuário 42
Pipeline B:
remove usuário 42
Pipeline C:
consulta usuário 42
Agora temos:
A ──┐
B ──┼── USER 42
C ──┘
Resultado?
Caos.
Um teste passa.
Outro falha.
Executamos novamente.
Passa.
Executamos amanhã.
Falha.
Nasceu o:
👻 FLAKY TEST
E então surge a frase mais perigosa do departamento de QA:
"Roda de novo."
Quando a segunda execução passa, todos vão embora.
Pouco a pouco ninguém acredita mais na suíte automatizada.
Isso destrói o valor do CI/CD.
🧬 CAPÍTULO 17 — Dê uma identidade própria para cada criatura
Se a limpeza ocorrer somente quando o teste termina normalmente, justamente os testes problemáticos deixarão mais sujeira.
Constantine jamais abandonaria o pentagrama aberto no chão.
O QA também não deveria abandonar seus registros temporários.
🕵️ CAPÍTULO 19 — Nunca use o cadáver verdadeiro
A regra:
Never use real customer data.
merece atenção especial.
Copiar produção indiscriminadamente:
PROD DATABASE
↓
COPY
↓
QA DATABASE
pode transportar:
nomes
documentos
endereços
telefones
emails
informações financeiras
dados pessoais
para um ambiente que talvez possua controles diferentes de produção.
Dependendo da necessidade, estratégias podem envolver dados sintéticos, mascaramento, anonimização ou tokenização, considerando requisitos técnicos e regulatórios aplicáveis.
E há outro teste maravilhoso:
compare aquilo que a interface mostra com aquilo que a API realmente devolve.
status
+
headers
+
schema
+
body
+
business rules
+
authorization
+
side effects
+
cleanup
E executar automaticamente:
COMMIT
↓
BUILD
↓
UNIT TEST
↓
DEPLOY QA
↓
API TEST
↓
CONTRACT TEST
↓
AUTHORIZATION TEST
↓
INTEGRATION TEST
↓
SECURITY TEST
↓
REPORT
↓
QUALITY GATE
A OWASP também descreve a automação de testes de autorização como útil para detectar regressões durante o desenvolvimento e os releases.
🖥️ CAPÍTULO 23 — Constantine entra na LPAR
Agora traduzimos tudo para a língua ancestral.
API
Mainframe — analogia conceitual
Request
entrada da transação
JSON
estrutura de dados
Endpoint
ponto de entrada
HTTP Method
operação solicitada
HTTP Status
retorno técnico
Token
contexto de segurança
Authorization
RACF/controle de acesso conceitualmente
Request ID
correlation ID
Side Effect
resultado transacional
Database
Db2/IMS/VSAM
Queue
MQ
Rollback
desfazer LUW
Environment
região/subsistema/configuração
BASE_URL
configuração externa/endereço do destino
Test Data
massa de testes
Não são equivalências tecnológicas perfeitas.
São pontes mentais.
E elas mostram uma coisa fascinante:
muito daquilo que o mercado chama hoje de arquitetura moderna possui problemas que mainframeiros conhecem há décadas.
Estado.
Concorrência.
Segurança.
Transações.
Auditoria.
Ambientes.
Configuração.
Recuperação.
Integridade.
🕯️ CAPÍTULO 24 — O exorcismo final
Constantine está diante do monitor.
O teste apresenta:
HTTP/1.1 200 OK
Todo mundo comemora.
Ele não.
Primeira pergunta:
O usuário correto recebeu os dados?
Sim.
O schema está correto?
Sim.
A autorização foi verificada?
Sim.
Existe informação sensível extra?
Não.
O banco ficou consistente?
Sim.
A operação aconteceu uma única vez?
Sim.
As mensagens corretas foram produzidas?
Sim.
O tempo ficou dentro do objetivo definido?
Sim.
O teste utilizou dados isolados?
Sim.
O ambiente era realmente QA?
Sim.
Os segredos ficaram protegidos?
Sim.
A massa criada foi limpa?
Sim.
Agora Constantine olha novamente:
200 OK
E finalmente diz:
— Agora talvez esteja OK.
☕ EPÍLOGO — CC 0000 também pode mentir
Aqui está a lição que une o velho mainframe às APIs modernas.
Nós já aprendemos há décadas que:
CC 0000
não significa necessariamente:
NEGÓCIO CORRETO
Um batch COBOL pode terminar lindamente com:
MAXCC=0000
e ter atualizado 50.000 clientes com a tarifa errada.
Tecnicamente terminou.
Funcionalmente foi uma catástrofe.
Da mesma maneira:
HTTP 200 OK
não significa:
TEST PASSED
Nosso verdadeiro ritual é:
REQUEST VÁLIDO
+
CONTRATO CORRETO
+
AUTENTICAÇÃO
+
AUTORIZAÇÃO
+
DADOS CORRETOS
+
REGRA DE NEGÓCIO
+
SIDE EFFECT CORRETO
+
ESTADO CONSISTENTE
+
ISOLAMENTO
+
SEGURANÇA
+
PERFORMANCE
+
CLEANUP
=
PASS
E existe ainda uma última possibilidade, aquela que faria Constantine sorrir.
O sistema está correto.
O endpoint está correto.
O banco está correto.
A autorização está correta.
O COMMIT está correto.
Mas o pipeline acusa:
FAILED
Porque dois testes resolveram utilizar simultaneamente:
USER_ID=42
Nesse momento o verdadeiro monstro não está na API.
Está na suíte de testes.
E é por isso que o bom investigador nunca pergunta apenas:
“A API falhou?”
Ele pergunta:
“O que exatamente falhou: o request, o contrato, a autenticação, a autorização, a aplicação, a regra de negócio, a persistência, o ambiente, a configuração, a massa de dados... ou o próprio teste?”
Essa é a diferença entre apertar SEND no Postman e realmente compreender API Testing.
Às 03:17, quando o dashboard fica vermelho e alguém aparece no War Room dizendo “mas estava retornando 200!”, talvez seja tarde demais para chamar John Constantine.
Mas ainda dá tempo de chamar um velho programador COBOL.
Ele provavelmente olhará para aquele 200 OK, lembrará de todos os CC 0000 que já viu mentirem durante a carreira e fará a única pergunta que realmente importa:
Bellacosa Mainframe e os riscos ocultos no mainframe
☕ Um Café no Bellacosa Mainframe
🌀 DOUTOR ESTRANHO E AS 15 PORTAS INVISÍVEIS DO MAINFRAME
RACF, SMF, TCP/IP, CICS, Db2, IMS, MFA, TLS, phishing, DDoS, malware, SQL Injection, Zero Trust, Red Team — e o dia em que Stephen Strange descobriu que o invasor mais perigoso não precisava quebrar a porta porque alguém já havia lhe emprestado a chave.
Sob a tutela do Doutor Estranho, Mestre das Artes Místicas — e, por algumas horas, improvável instrutor de segurança do z/OS.
🎬 PRÓLOGO — O PORTAL QUE APARECEU NO MEIO DO ISPF
Nosso jovem programador COBOL estava diante de uma tela ISPF.
Nada particularmente emocionante.
OPTION ===> 3.4
Datasets.
Copybooks.
JCL.
COBOL.
Aquele universo confortável onde um programa começa educadamente com:
IDENTIFICATION DIVISION.
PROGRAM-ID. PAYROLL.
Até que surgiu um círculo dourado no meio da sala.
Faíscas.
O programador recuou.
Do portal saiu o Doutor Estranho.
— Você é o programador COBOL?
— Sim.
— Então temos um problema.
— ABEND?
— Pior.
Strange abriu outro portal.
Do outro lado havia uma arquitetura inteira:
Internet
│
Firewall
│
API Gateway
│
TCP/IP
│
IBM Z
│
┌─┼──────────────┐
│ │ │
CICS IMS
│ │
COBOL COBOL
│ │
Db2 Db2
│
RACF
O jovem ficou aliviado.
— Ah! Mainframe. Estamos seguros.
Strange fechou o portal.
— É exatamente por isso que estou aqui.
☕
🏰 CAPÍTULO 1 — MAINFRAME NÃO É UMA DIMENSÃO FORA DA INTERNET
Existe uma imagem clássica do mainframe:
uma máquina enorme, fechada, isolada, protegida por paredes invisíveis e administrada por pessoas misteriosas que falam coisas como:
APF
LPAR
RACF
SMF
VTAM
IPL
PARMLIB
Durante décadas, parte dessa percepção fez algum sentido porque muitos ambientes mainframe eram extremamente controlados.
Mas o IBM Z moderno participa de arquiteturas distribuídas.
Ele conversa com:
aplicações web;
dispositivos móveis;
parceiros;
cloud;
APIs;
MQ;
Kafka;
Linux;
OpenShift;
bancos distribuídos;
sistemas corporativos;
ferramentas DevOps.
Portanto, nossa primeira regra é:
Mainframe não é sinônimo de isolamento.
O IBM Z pode possuir dezenas ou centenas de caminhos de comunicação com o restante da organização.
O Doutor Estranho desenharia isso como vários portais:
☁ CLOUD
│
▼
MOBILE ──► API ─────────┐
│
PARTNER ─► MQ ──────────┤
▼
┌─────────┐
INTERNET ─────────►│ IBM Z │
└─────────┘
▲
DEVOPS ─► PIPELINE ─────┤
│
USERS ──► TN3270 ───────┘
Cada portal é útil.
E cada portal também precisa ser protegido.
🌐 CAPÍTULO 2 — SIM, EXISTE TCP/IP NO MAINFRAME
O iniciante COBOL frequentemente conhece:
COBOL
JCL
CICS
Db2
VSAM
mas esquece que existe uma enorme infraestrutura embaixo disso.
z/OS possui Communications Server, incluindo uma implementação completa da pilha TCP/IP.
Consequentemente, conceitos tradicionais de segurança de redes continuam importantes:
IP
TCP
UDP
DNS
TLS
certificados
sockets
portas
firewall
IPSec
Isso significa que um atacante interessado em reconhecer um ambiente pode procurar serviços acessíveis.
Não precisa começar pensando:
“Vou atacar COBOL.”
Ele pode pensar:
“O que existe neste endereço?”
Essa diferença é enorme.
🔭 CAPÍTULO 3 — O OLHO DE AGAMOTTO FAZ PORT SCANNING?
Imagine Strange olhando para uma máquina:
HOST
│
├── porta A
├── porta B
├── porta C
└── porta D
💥 CAPÍTULO 4 — DDoS E O FEITIÇO DOS DEZ MIL PEDIDOS
Suponha que Wong diga:
— Mestre, nosso CICS consegue processar uma quantidade absurda de transações.
Strange responde:
— Excelente.
Wong continua:
— Então somos imunes a DDoS.
Silêncio constrangedor.
DDoS significa Distributed Denial of Service.
O objetivo não precisa ser “quebrar o mainframe”.
Pode ser simplesmente tornar determinado serviço indisponível.
Imagine:
Bot
│
Bot ────────┼──────── Bot
│
Bot ────────┼──────── Bot
│
▼
API Gateway
│
X
│
CICS
Curiosamente, CICS pode estar saudável.
CPU pode estar normal.
Db2 pode estar normal.
COBOL pode estar esperando trabalho.
Mas o gateway ficou saturado.
Para o cliente:
“O mainframe caiu.”
Para o sysprog:
“O mainframe nem percebeu.”
Essa diferença é importantíssima em incidentes.
Disponibilidade precisa ser analisada fim a fim.
🕵️ CAPÍTULO 5 — MAN-IN-THE-MIDDLE: DORMAMMU NO MEIO DA CONVERSA
Temos:
CLIENTE ─────────────────► SERVIDOR
Tudo parece perfeito.
Mas imaginemos:
CLIENTE ──► ATACANTE ──► SERVIDOR
O intermediário tenta observar ou manipular a comunicação.
É o princípio do Man-in-the-Middle.
No mundo empresarial entram mecanismos como:
TLS
certificados digitais
IPSec
AT-TLS
E aqui existe uma característica muito interessante do z/OS: Application Transparent TLS — AT-TLS.
A ideia é poderosa porque permite aplicar proteção TLS através da infraestrutura TCP/IP para aplicações adequadamente configuradas, reduzindo a necessidade de cada aplicação implementar diretamente toda a lógica TLS.
É quase um feitiço de Strange:
Aplicação antiga
│
▼
AT-TLS
│
▼
Comunicação protegida
O programa pode continuar fazendo aquilo que sabe fazer.
A infraestrutura acrescenta proteção ao redor dele.
Essa capacidade de modernizar ao redor do legado é uma das características fascinantes do ecossistema mainframe.
🔑 CAPÍTULO 6 — RACF NÃO É UM CAMPO DE FORÇA
Agora Strange chega diante de uma porta.
Nela está escrito:
RACF
O jovem programador sorri.
— Pronto. Ninguém passa.
Strange pergunta:
— O que é RACF?
— Segurança.
— Resposta perigosa.
RACF é muito mais precisamente parte fundamental da infraestrutura responsável por identidades, autenticação, autorização e proteção de recursos em muitos ambientes z/OS.
Simplificando:
QUEM É VOCÊ?
│
▼
AUTENTICAÇÃO
│
▼
O QUE VOCÊ PODE FAZER?
│
▼
AUTORIZAÇÃO
“Quantas coisas precisam dar errado para alguém chegar ao ativo crítico?”
Essa é uma pergunta muito melhor.
🧪 CAPÍTULO 21 — LABORATÓRIO MENTAL PARA O PROGRAMADOR COBOL
Quando receber um programa para manutenção, faça este exercício.
Comece desenhando:
ENTRADA
│
▼
PROGRAMA
│
▼
DADOS
Depois expanda:
Quem chama?
│
Como autentica?
│
Por onde entra?
│
Quem autoriza?
│
Que programa executa?
│
Que dados acessa?
│
Que sistema externo chama?
│
O que fica registrado?
Agora você não está mais apenas lendo COBOL.
Está fazendo threat modeling.
Por exemplo:
Mobile
│
API
│
CICS
│
COBOL
│
Db2
│
MQ
│
parceiro
Pergunte em cada seta:
Quem confia em quem?
Como prova identidade?
Existe criptografia?
Existe autorização?
Existe validação?
Existe auditoria?
A seta é tão importante quanto a caixa.
💡 CAPÍTULO 22 — 10 DICAS PARA O PADAWAN DA SEGURANÇA MAINFRAME
Não confunda RACF com toda a segurança do mainframe. Ele é uma peça fundamental, mas existe uma arquitetura inteira ao redor.
Aprenda TCP/IP. Um programador COBOL moderno ganha muito entendendo portas, TLS, certificados, DNS e sockets.
Entenda identidade e autorização separadamente. Saber quem alguém é não responde ao que essa pessoa deveria fazer.
Conheça SMF. Segurança sem evidência vira opinião.
Aprenda CICS e Db2 pensando também em segurança. Não apenas em funcionalidade.
Entenda APIs. O COBOL pode estar cinco camadas atrás de uma chamada proveniente da Internet.
Estude USS. Existe um universo UNIX dentro do z/OS que muitos desenvolvedores tradicionais quase nunca exploraram.
Entenda DevSecOps. Git, pipeline, build e deploy fazem parte da superfície de confiança.
Nunca pense “ninguém sabe que isso existe”. Obscuridade não deve ser o principal controle.
Pergunte sempre: “E se essa identidade legítima estiver comprometida?” Essa pergunta revela problemas que muitos checklists não encontram.
🥚 EASTER EGG — 03:17 E A DIMENSÃO DO ACCESS ALLOWED
São exatamente:
03:17:04
O SOC recebe um evento.
USER: PRODADM
AUTHENTICATION: SUCCESS
03:17:09:
RESOURCE: PROD.PAYROLL.MASTER
ACCESS: ALLOWED
03:17:14:
PROGRAM: EXECUTED
RESULT: SUCCESS
03:17:31:
TRANSFER: COMPLETED
O jovem programador corre até Strange.
— Mestre! Encontrei o problema!
— Qual?
— RACF falhou!
Strange olha os registros.
— Onde?
— O usuário acessou o arquivo!
— Ele tinha autorização?
— Tinha.
— A autenticação funcionou?
— Sim.
— O programa executou normalmente?
— Sim.
— Então onde está a falha do RACF?
O garoto permanece em silêncio.
Strange abre o Olho de Agamotto e volta alguns minutos no tempo.
03:02.
Um administrador abre um e-mail.
03:04.
Clica num link.
03:05.
Digita suas credenciais.
03:17.
Alguém do outro lado do mundo entra usando uma identidade válida.
Strange congela o tempo.
Na tela não aparece:
ICH408I
ACCESS DENIED
Aparece:
ACCESS ALLOWED
O jovem finalmente entende.
— Estávamos procurando alguém tentando arrombar a porta...
Strange sorri.
— ...quando deveríamos procurar quem roubou a chave.
☕
🌀 EPÍLOGO — O MAIOR FEITIÇO DO MAINFRAME É A CONFIANÇA
Quando começamos esta jornada, tínhamos cinco infográficos mostrando dezenas de ameaças:
DDoS, DoS, Man-in-the-Middle, DNS spoofing, ARP spoofing, sniffing, session hijacking, Evil Twin, port scanning, IP spoofing, brute force, dictionary attacks, credential stuffing, password spraying, phishing, engenharia social, malware, ransomware, spyware, rootkits, botnets, backdoors, SQL Injection, XSS, zero-days e muitas outras.
Transportá-las mecanicamente para o IBM Z seria um erro.
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
