✨ 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
🐒 QUANDO UM MILHÃO DE CHIMPANZÉS ABRIRAM O BARRIL DE SAQUÊ PREMIUM
Portas dos fundos humanas, “sabe com quem você está falando?”, jatinhos emprestados, togas, garotas de programa, despesas de representação, compliance, Red Team, Security — e o estranho dia em que descobrimos que o maior privilégio de um sistema talvez não estivesse cadastrado no RACF.
🎬 PRÓLOGO — O SISTEMA ESTAVA SEGURO
O jovem programador COBOL tinha certeza.
O RACF estava configurado.
As senhas eram fortes.
MFA estava habilitado.
Os datasets críticos estavam protegidos.
Os acessos privilegiados eram registrados.
O SIEM recebia eventos.
O SOC monitorava alertas.
Auditores possuíam relatórios.
Havia segregação de funções.
Existia política de Zero Trust.
Tudo perfeito.
Até que alguém apareceu na porta e pronunciou uma sequência de palavras contra a qual nenhum firewall havia sido configurado:
— Você sabe com quem está falando?
O jovem programador olhou para o veterano.
— Onde cadastro isso no RACF?
O velho tomou um gole de café.
— Em lugar nenhum.
— Então estamos protegidos?
— Muito pelo contrário, Padawan.
Eram 03:17.
O incidente estava apenas começando.
🐒 CAPÍTULO 1 — O MILHÃO DE CHIMPANZÉS
Existe uma velha brincadeira segundo a qual, colocando infinitos chimpanzés diante de máquinas de escrever durante tempo suficiente, algum deles acabaria escrevendo Shakespeare.
No Bellacosa Mainframe decidimos modernizar a experiência.
Colocamos um milhão de chimpanzés diante de terminais 3270.
Mas alguém cometeu um erro operacional gravíssimo.
Em vez de café, abriram um barril de saquê premium.
Depois do terceiro copo, nenhum chimpanzé queria mais escrever Shakespeare.
Queriam fazer auditoria.
E descobriram uma coisa extraordinária:
os sistemas mais protegidos do mundo frequentemente possuem portas que não aparecem nos diagramas de arquitetura.
Não são portas TCP.
Não estão no firewall.
Não possuem CVE.
Não aparecem no Nessus.
Não estão no OWASP Top 10.
São portas humanas.
🚪 CAPÍTULO 2 — A BACKDOOR QUE NÃO ESTAVA NO CÓDIGO
Imagine um sistema extremamente seguro.
Um funcionário tenta acessar determinado ambiente.
ACCESS DENIED.
Perfeito.
Agora chega um diretor.
ACCESS DENIED.
Tecnicamente, continua perfeito.
Então o diretor olha para o funcionário:
— Você sabe quem eu sou?
Nesse instante surge uma nova interface de autenticação.
Não existe API.
Não existe documentação.
Mas todo mundo conhece o protocolo:
IDENTIDADE: DIRETOR
AUTORIZAÇÃO: NÃO
PRESSÃO HIERÁRQUICA: ALTA
RISCO DE RETALIAÇÃO: ALTO
RESULTADO ESPERADO PELO SISTEMA:
DENY
RESULTADO ESPERADO PELO HUMANO:
TALVEZ SEJA MELHOR LIBERAR
O VIP pode utilizar ambientes completamente diferentes, sujeitos aos controles específicos daquela modalidade de aviação.
Nada disso significa automaticamente irregularidade.
Mas, para um Red Team, aparece imediatamente uma pergunta:
os controles continuam oferecendo rastreabilidade suficiente quando o usuário é VIP?
A pergunta não é:
“Como alguém poderia burlar isso?”
A pergunta correta é:
“Conseguimos reconstruir posteriormente quem entrou, quem saiu, quem autorizou e quem pagou?”
Essa é a diferença entre procurar uma vulnerabilidade e ensinar sua exploração.
Bellacosa Mainframe e uma historia que não esta no gibi
⚖️ CAPÍTULO 5 — A TOGA NÃO É UM TOKEN DE AUTENTICAÇÃO
Os chimpanzés continuaram investigando.
Encontraram pessoas poderosas.
Executivos.
Autoridades.
Magistrados.
Políticos.
Empresários.
E perceberam uma coisa.
Quanto maior o poder de uma pessoa, maior pode ser a tentação social de transformar sua posição em credencial.
Mas uma toga não deveria funcionar como:
PERMIT * ACCESS(ALTER)
Nem um cargo de CEO.
Nem um cartão VIP.
Nem amizade com o presidente.
Porque segurança baseada em prestígio possui uma vulnerabilidade fundamental:
ela funciona melhor justamente contra quem oferece menos risco institucional para quem aplica a regra.
🍽️ CAPÍTULO 6 — DESPESAS DE REPRESENTAÇÃO
Agora os chimpanzés chegaram ao departamento financeiro.
Encontraram uma expressão maravilhosa:
DESPESAS DE REPRESENTAÇÃO.
Jantares.
Viagens.
Eventos.
Hospitalidade.
Entretenimento.
Presentes.
Tudo pode possuir finalidade comercial perfeitamente legítima.
O problema começa quando alguém confunde:
DOCUMENTO EXISTE
com
TRANSAÇÃO É LEGÍTIMA.
São coisas completamente diferentes.
Um sistema ruim pergunta:
Tem comprovante?
Um sistema melhor pergunta:
O comprovante representa aquilo que realmente aconteceu?
🧾 CAPÍTULO 7 — COMPLIANCE NÃO É COLECIONAR PDF
Imagine:
DESPESA REAL = A
DOCUMENTO = B
CONTABILIDADE = B
ERP = B
RELATÓRIO = B
AUDITORIA SUPERFICIAL = OK
Cinco sistemas concordam.
E cinco sistemas podem estar errados.
Porque todos receberam a mesma representação incorreta da realidade.
Esse é um problema fascinante para quem trabalha com sistemas.
Garbage in, garbage out também funciona em compliance.
Uma transação pode possuir:
✔ documento ✔ aprovação ✔ centro de custo ✔ fornecedor ✔ lançamento ✔ pagamento
e ainda exigir investigação.
O auditor experiente não pergunta apenas:
“Existe nota?”
Pergunta:
“Esta nota conta a história verdadeira?”
👠 CAPÍTULO 8 — AS GAROTAS QUE ROUBARAM A MANCHETE
Então apareceram profissionais do sexo.
E todos os chimpanzés abandonaram imediatamente a arquitetura de segurança.
A imprensa também.
Porque:
CONFLITO DE INTERESSES EM COMPLEXA REDE DE RELACIONAMENTOS
é uma manchete chata.
Mas:
TOGA + JATINHO + GAROTA + FESTA
é praticamente o renascimento do Notícias Populares.
Só que existe uma armadilha intelectual aí.
Sexo consensual entre adultos pode não ser a questão relevante.
A pergunta interessante é outra:
quem proporcionou o benefício?
E depois:
por quê?
E depois:
para quem?
E finalmente:
o beneficiário possuía poder sobre algum interesse de quem estava pagando?
O Red Team abandona a fofoca e segue o fluxo.
💰 CAPÍTULO 9 — FOLLOW THE MONEY
Dinheiro possui uma qualidade maravilhosa para auditoria:
ele deixa rastros.
Mas o auditor iniciante procura somente:
A → B
O experiente procura:
A
│
├── empresa
├── consultoria
├── escritório
├── fornecedor
├── instituto
├── evento
├── viagem
└── benefício
│
▼
B
Isso não significa que cada seta represente corrupção.
Muito pelo contrário.
A maior parte das relações econômicas é perfeitamente legítima.
O objetivo é descobrir o significado das relações, não criminalizar relacionamentos.
🕵️ CAPÍTULO 10 — RED TEAM NÃO PROCURA APENAS BUG
Essa talvez seja a maior lição.
Red Team não precisa perguntar somente:
“Consigo quebrar o software?”
Pode perguntar:
“Consigo quebrar o processo?”
E depois:
“Consigo fazer alguém autorizado executar algo que eu não conseguiria executar?”
E finalmente:
“Existe alguém tão poderoso que os controles deixam de funcionar normalmente quando ele aparece?”
Essa última pergunta é assustadoramente poderosa.
🧠 CAPÍTULO 11 — O CONTROLE INVISÍVEL
Imagine duas políticas.
A política oficial:
Ninguém entra sem autorização.
E a política cultural:
Ninguém entra sem autorização, exceto pessoas importantes porque ninguém quer confusão.
Qual delas controla realmente a organização?
A segunda.
Mesmo sem estar escrita.
Esse é o Shadow Security Policy.
E ele pode ser mais poderoso que o RACF.
🐵 CAPÍTULO 12 — O CHIMPANZÉ AUDITOR
Depois de consumir quantidades preocupantes de saquê, um chimpanzé apresentou sua metodologia.
Ele escreveu no quadro:
QUEM?
↓
PEDIU O QUÊ?
↓
QUEM AUTORIZOU?
↓
QUEM PAGOU?
↓
QUEM RECEBEU?
↓
QUEM SE BENEFICIOU?
↓
HAVIA INTERESSE?
↓
HOUVE ATO POSTERIOR?
↓
EXISTE AUDIT TRAIL?
A sala ficou silenciosa.
O chimpanzé havia acabado de inventar uma investigação melhor que muito checklist corporativo.
🔐 CAPÍTULO 13 — ZERO TRUST PARA PODEROSOS
Talvez precisemos atualizar o conceito.
Zero Trust costuma ser explicado assim:
Never trust, always verify.
Mas existe uma versão organizacional:
Never trust status. Always verify authorization.
Porque existem duas formas de privilégio.
O privilégio técnico:
SPECIAL
OPERATIONS
AUDITOR
ALTER
CONTROL
E o privilégio social:
CEO
DIRETOR
VIP
AUTORIDADE
AMIGO DO DONO
O primeiro aparece nos relatórios.
O segundo raramente.
E justamente por isso merece atenção.
🧯 CAPÍTULO 14 — O FUNCIONÁRIO QUE DISSE NÃO
Existe ainda outro controle que quase nunca aparece no diagrama:
a pessoa que executa a política.
Se ela disser NÃO corretamente e receber punição por isso, a organização acabou de executar um treinamento informal.
Todos aprenderam:
Na próxima vez, diga SIM.
É assim que controles morrem sem ninguém alterar uma única linha de configuração.
O RACF continua perfeito.
O manual continua perfeito.
A auditoria continua recebendo relatórios verdes.
Mas ninguém mais deseja aplicar a regra contra determinadas pessoas.
🏛️ CAPÍTULO 15 — O PRINCÍPIO DA DISTÂNCIA ZERO
Relacionamento não é crime.
Networking não é crime.
Jantar não é crime.
Viajar não é crime.
Ter amigos poderosos não é crime.
Contratar serviços não é crime.
A pergunta de governança é:
essas relações conseguem alterar decisões que deveriam ser independentes?
Esse é o ponto em que compliance deixa de ser moralismo e vira arquitetura institucional.
📰 CAPÍTULO 16 — O EFEITO NOTÍCIAS POPULARES
Existe ainda um perigo para quem investiga.
Encontrar algo escandaloso demais.
Sexo.
Luxo.
Celebridades.
Jatinhos.
Festas.
Tudo isso produz atenção.
Mas atenção pode destruir investigação.
Porque o público passa a discutir:
“Quem dormiu com quem?”
quando deveria perguntar:
“Quem pagou o quê para quem e qual interesse existia?”
O espetáculo pode funcionar como fumaça sobre o problema verdadeiro.
🐒 EPÍLOGO — SHAKESPEARE NÃO VEIO
Depois de milhares de horas, o milhão de chimpanzés não escreveu Shakespeare.
Produziu algo muito mais útil.
Um relatório de auditoria.
Na última página havia apenas quatro linhas:
IDENTIDADE NÃO É AUTORIZAÇÃO.
DOCUMENTAÇÃO NÃO É VERDADE.
PODER NÃO É CREDENCIAL.
E TODO PRIVILÉGIO PRECISA DE AUDIT TRAIL.
O jovem programador olhou para o veterano.
— Então qual é a porta dos fundos mais perigosa?
O velho terminou o café.
Olhou para o relógio.
03:17.
— Aquela que todo mundo conhece, Padawan.
— Então por que ninguém fecha?
O veterano levantou-se.
— Porque às vezes quem passa por ela é justamente quem poderia mandar fechá-la.
No fundo da sala, um chimpanzé levantou o copo de saquê.
Quando o sistema deixa de perguntar “o que você fez?” e começa a perguntar “por que você deixou de se comportar como você mesmo?”
Há uma coisa que Diabolik entende melhor do que muitos sistemas antifraude.
A melhor maneira de atravessar uma porta protegida não é necessariamente arrombá-la.
É fazer com que a porta acredite que você deveria estar entrando por ela.
Máscara correta.
Documento correto.
Horário plausível.
Comportamento esperado.
Uma história suficientemente coerente.
Separadamente, cada detalhe parece normal.
E justamente aí começa nossa história.
Porque, em algum lugar dentro de uma enorme instituição financeira, existe um IBM Mainframe processando milhões de eventos e tentando responder a uma pergunta aparentemente simples:
este comportamento faz sentido para esta pessoa?
Bem-vindo ao Risk Scoring Humano.
E nosso guia será Diabolik.
🕶️ CAPÍTULO 1 — Diabolik não quer parecer Diabolik
Imagine um sistema antifraude bastante primitivo.
Sua lógica poderia ser parecida com:
IF TRANSACTION-AMOUNT > 10000
MOVE 'HIGH-RISK' TO RISK-LEVEL
END-IF.
Funciona?
Às vezes.
Mas qualquer pessoa que conheça a regra aprende rapidamente que R$ 10.001 chama atenção e R$ 9.999 talvez não.
Esse é o problema das regras determinísticas isoladas.
Diabolik olha para isso e sorri.
Ele não precisa destruir a regra.
Precisa apenas parecer normal para ela.
Um sistema moderno precisa fazer outra pergunta:
R$ 9.999 é normal para quem está fazendo essa operação?
Para uma grande empresa, talvez seja banal.
Para uma conta que recebe R$ 1.800 por mês e nunca movimentou mais de R$ 3.000, pode ser extraordinário.
JOÃO
│
├── recebe 8 transferências incomuns
├── acessa de novo dispositivo
├── muda telefone
├── realiza operação internacional
├── adiciona beneficiário
└── transfere praticamente todo o saldo
Talvez cada evento seja legítimo.
O problema é a combinação.
Diabolik conseguiu uma identidade verdadeira.
Mas ainda precisa aprender a ser João.
📸 CAPÍTULO 3 — O velho sistema guardava fotografias
Durante décadas, instituições trabalharam muito bem com fotografias cadastrais.
NOME
CPF
ENDEREÇO
RENDA
PROFISSÃO
IDADE
TELEFONE
É uma fotografia.
Ela responde:
Quem é Vagner?
Mas Risk Scoring moderno quer assistir ao filme.
08:03 login
08:04 consulta saldo
08:06 novo favorecido
08:07 alteração cadastral
08:11 transferência
08:13 segunda transferência
08:17 tentativa internacional
Agora temos comportamento.
E comportamento possui uma propriedade fascinante:
Para transações financeiras modernas, também poderíamos integrar APIs, mensageria e plataformas analíticas externas.
O mainframe não precisa fazer sozinho toda a ciência de dados.
Ele pode ser justamente o coração transacional que pergunta:
“Posso autorizar?”
E recebe:
APPROVE
REVIEW
CHALLENGE
DECLINE
💳 CAPÍTULO 6 — 200 OK não significa “é confiável”
Imagine:
CLIENTE
↓
APP
↓
API
↓
BANK
↓
MAINFRAME
A autenticação está correta.
Token correto.
Senha correta.
Dispositivo reconhecido.
Isso demonstra que determinadas credenciais foram aceitas.
Não demonstra necessariamente que a intenção seja legítima.
Essa distinção é fundamental:
AUTHENTICATION
≠
AUTHORIZATION
≠
TRUST
Diabolik adora quando confundimos essas três coisas.
Ele não precisa falsificar necessariamente tudo.
Talvez tenha acesso legítimo a uma credencial comprometida.
O sistema precisa analisar contexto.
🧠 CAPÍTULO 7 — Risk Scoring não deveria perguntar apenas “quem é você?”
Perguntas melhores:
Quem é você?
De onde costuma acessar?
Quando costuma acessar?
Quanto costuma movimentar?
Para quem costuma transferir?
Quais dispositivos utiliza?
Qual é sua velocidade normal de operações?
Que relacionamento possui com o destinatário?
Esse comportamento já aconteceu anteriormente?
Isso produz uma identidade dinâmica.
Chamaremos de:
Behavioral Identity.
Não é simplesmente CPF.
É uma combinação histórica de comportamentos.
🕸️ CAPÍTULO 8 — E então descobrimos o grafo
Diabolik consegue imitar Marco.
Excelente.
Mas existe um problema.
Ele precisa mandar o dinheiro para algum lugar.
Surge Maria.
MARCO → MARIA
Nada necessariamente estranho.
Mas Maria recebe também de:
JOÃO ──┐
PEDRO ─┤
ANA ───┼──→ MARIA
LUÍS ──┤
MARCO ─┘
Interessante.
Maria envia para Empresa X.
MARIA → EMPRESA X
Empresa X está relacionada a outras entidades.
Agora nossa análise deixa de olhar somente para transações.
Estamos construindo um:
GRAPH.
🕷️ CAPÍTULO 9 — O grafo destrói algumas máscaras
Uma pessoa pode alterar:
nome utilizado,
telefone,
conta,
empresa,
dispositivo,
endereço.
Mas relacionamentos podem revelar padrões.
Imagine:
PESSOA A
│
├── telefone → PESSOA B
│
├── endereço → EMPRESA C
│
├── dispositivo → CONTA D
│
└── transferência → PESSOA E
Cada aresta adiciona contexto.
Agora descobrimos:
PESSOA E
↓
EMPRESA F
↓
CONTA G
↓
PESSOA B
Fechamos um ciclo.
É por isso que Graph Analytics é tão poderoso em fraude e AML.
Ele não pergunta apenas:
Quem recebeu dinheiro?
Pergunta:
Como essas entidades estão relacionadas?
🧩 CAPÍTULO 10 — Risk Scoring humano não significa julgar pessoas
Aqui existe uma distinção ética essencial.
Um sistema não deveria concluir:
“Essa pessoa é criminosa.”
Risk Scoring deve trabalhar com algo muito mais limitado:
“Esta operação apresenta características que justificam controles adicionais.”
Essa diferença protege clientes e instituição.
Score não deveria ser sentença.
Deveria ser sinal.
Por isso podemos ter:
LOW RISK
↓
PROCESS
MEDIUM RISK
↓
ADDITIONAL AUTHENTICATION
HIGH RISK
↓
MANUAL REVIEW
CRITICAL
↓
BLOCK / INVESTIGATION
Dependendo da política, legislação e natureza da operação.
🔎 CAPÍTULO 11 — O caso Gritzbach mostra outro tipo de Risk Scoring
Aqui podemos utilizar o caso apenas como analogia analítica, sem transformar acusações ainda controvertidas em fatos.
Segundo a reconstrução jornalística, Antônio Vinícius Lopes Gritzbach teria atravessado simultaneamente diferentes redes de relacionamento envolvendo integrantes do PCC, negócios, dinheiro, criptomoedas, autoridades e policiais. Ele posteriormente tornou-se colaborador do Ministério Público.
A questão interessante para nosso estudo não é tentar reproduzir qualquer “score do PCC”.
É observar algo universal:
pessoas também existem dentro de grafos de confiança.
IF WS-NEW-DEVICE = 'Y'
ADD 15 TO WS-RISK-SCORE
END-IF
IF WS-NEW-BENEFICIARY = 'Y'
ADD 20 TO WS-RISK-SCORE
END-IF
IF WS-HIGH-AMOUNT = 'Y'
ADD 25 TO WS-RISK-SCORE
END-IF
IF WS-PROFILE-CHANGE = 'Y'
ADD 10 TO WS-RISK-SCORE
END-IF.
Depois:
EVALUATE TRUE
WHEN WS-RISK-SCORE >= 70
MOVE 'REVIEW' TO WS-DECISION
WHEN WS-RISK-SCORE >= 40
MOVE 'CHALLENGE' TO WS-DECISION
WHEN OTHER
MOVE 'APPROVE' TO WS-DECISION
END-EVALUATE.
Didaticamente funciona.
Mas Diabolik imediatamente descobriria um problema.
😈 CAPÍTULO 15 — Diabolik aprende nossas regras
Se:
70 = REVIEW
ele tentará permanecer em:
69
Esse fenômeno é fundamental em sistemas antifraude.
Quando atacantes compreendem controles, adaptam comportamento.
Ele pode revelar mudanças que um grafo estático esconderia.
🏦 CAPÍTULO 18 — E onde entra o IBM Mainframe?
No lugar mais interessante possível.
No coração das operações.
Imagine uma arquitetura:
MOBILE
│
INTERNET
│
▼
API LAYER
│
z/OS Connect
│
▼
┌─────────────────────────────────┐
│ IBM Z │
│ │
│ CICS │
│ │ │
│ ▼ │
│ COBOL ───────► Db2 │
│ │ │
│ ▼ │
│ RISK REQUEST │
│ │ │
└─────┼───────────────────────────┘
│
▼
ANALYTICS / GRAPH / ML
│
▼
RISK SCORE
│
▼
IBM Z
│
▼
DECISION
E isso é importante:
modernização não significa necessariamente retirar o COBOL.
Pode significar permitir que COBOL converse com tecnologias especializadas.
⚡ CAPÍTULO 19 — Porque autorização não pode tomar café
Imagine cartão.
Cliente encosta na máquina.
TAP
↓
ACQUIRER
↓
NETWORK
↓
ISSUER
↓
AUTHORIZATION
O cliente está olhando para o terminal.
Não podemos dizer:
“Aguarde vinte minutos enquanto nosso algoritmo termina.”
A decisão precisa ocorrer rapidamente.
É exatamente aí que sistemas transacionais de alta disponibilidade continuam extremamente relevantes.
Risk Scoring precisa entrar no fluxo sem destruir SLA.
🔐 CAPÍTULO 20 — False Positive: quando prendemos o mordomo
Existe outro perigo.
Se o sistema ficar paranoico:
QUALQUER COISA DIFERENTE
↓
BLOCK
teremos milhares de clientes legítimos irritados.
Chamamos isso de:
false positive.
O cliente viajou para Roma.
Compra jantar.
Sistema:
FRAUDE!
Cliente:
Estou com fome!
😄
Risk Scoring precisa equilibrar:
FRAUD LOSS
↕
CUSTOMER FRICTION
Bloquear tudo é fácil.
Autorizar corretamente é difícil.
🎯 CAPÍTULO 21 — Risk Score não é prova
Isso merece ficar gravado no monitor do programador:
RISK SCORE ≠ GUILT
Score 92 não significa:
“92% criminoso.”
Pode significar apenas que um modelo específico identificou uma combinação de sinais considerada de alto risco segundo sua própria calibração.
A interpretação depende do modelo.
Esse cuidado torna-se ainda mais importante quando falamos em Risk Scoring Humano.
Algoritmos podem produzir vieses.
Dados podem estar errados.
Cadastros podem estar desatualizados.
Relacionamentos podem ser coincidências.
Por isso decisões de grande impacto precisam de governança adequada.
🧪 CAPÍTULO 22 — Explainability: por que deu 92?
Imagine o analista recebendo:
RISK SCORE = 92
Ele pergunta:
Por quê?
Sistema:
Porque sim.
Inaceitável.
Precisamos de reason codes.
R01 NEW DEVICE
R07 NEW BENEFICIARY
R13 UNUSUAL AMOUNT
R22 HIGH VELOCITY
R31 GRAPH RELATION
Então:
SCORE 92
REASONS:
HIGH VELOCITY
NEW DEVICE
NEW BENEFICIARY
BEHAVIOR DEVIATION
Agora existe explicabilidade operacional.
E o COBOL pode desempenhar papel importantíssimo na integração desses reason codes ao fluxo transacional.
🗃️ CAPÍTULO 23 — Não jogue fora os dados antigos!
Aqui existe uma vantagem maravilhosa dos ambientes Mainframe.
Histórico.
Décadas de histórico podem existir.
Isso é ouro para análise comportamental — desde que seja utilizado com governança, finalidade legítima, qualidade e respeito às regras de proteção de dados.
Porque comportamento exige comparação:
HOJE
versus
ONTEM
versus
30 DIAS
versus
1 ANO
Um sistema que conhece apenas hoje não conhece comportamento.
Conhece eventos.
🕵️ CAPÍTULO 24 — Diabolik finalmente comete seu erro
Nosso Diabolik conseguiu:
credencial,
identidade,
dispositivo,
horário plausível,
valor plausível.
Ele parece perfeito.
Mas precisa transferir recursos.
O sistema observa:
DIABOLIK-AS-MARCO
↓
CONTA X
↓
CONTA Y
↓
EMPRESA Z
E o Graph Engine percebe:
EMPRESA Z
↑
CONTA Q
↑
CASO ANTERIOR
A transação não era necessariamente anormal.
O relacionamento era.
E finalmente encontramos aquilo que Diabolik não conseguiu falsificar perfeitamente:
o contexto.
🧠 CAPÍTULO 25 — A verdadeira evolução do antifraude
E PORQUE WS-RISK > 80 não será resposta suficiente.
Diabolik talvez consiga enganar uma regra.
Talvez consiga enganar uma câmera.
Talvez consiga uma identidade perfeita.
Talvez consiga inclusive parecer estatisticamente normal durante algum tempo.
Mas quanto mais dimensões independentes um sistema correlaciona — histórico, comportamento, dispositivo, velocidade, relacionamentos e tempo — mais difícil se torna sustentar uma identidade artificial coerente.
Essa é a batalha moderna.
Não é:
COBOL contra inteligência artificial.
É:
COBOL
+
CICS
+
Db2
+
APIs
+
EVENTS
+
RULES
+
ML
+
GRAPH ANALYTICS
+
HUMAN ANALYST
Cada tecnologia fazendo aquilo que sabe fazer melhor.
E no centro de tudo continua existindo aquela pergunta simples que começou nossa investigação:
“Isto é normal?”
Diabolik ajusta a gravata, olha para o terminal e sorri.
🧟 Mainframe Evolution — O Pesadelo Open Source que Entrou na LPAR
Segurança, observabilidade e escala no IBM Z, investigadas sob a ótica de Dylan Dog, o Investigador do Pesadelo
Há casos que chegam ao escritório de Dylan Dog embrulhados em jornais velhos, acompanhados por fotografias borradas e pelo depoimento de alguma testemunha dizendo ter visto uma criatura impossível atravessar a parede à meia-noite.
Este caso chegou de maneira ainda mais suspeita.
Em uma apresentação apareceu a frase:
Mainframe Evolution: Securing, Monitoring, and Scaling with Next-Gen Open Source
Dylan olhou para o papel.
Groucho olhou para Dylan.
— Chefe, acho que descobriram algo mais antigo que os vampiros.
— O quê?
— COBOL.
Silêncio.
Em algum lugar distante, uma fita magnética girou sozinha.
Bem-vindo a mais uma investigação do Bellacosa Mainframe.
Desta vez nosso cliente afirma que existe open source dentro do mainframe.
Para muitos programadores, isso parece perfeitamente normal em 2026.
Para outros, principalmente aqueles que ainda imaginam o mainframe como uma fortaleza isolada onde todos entram pelo TSO e qualquer alteração precisa de três formulários, dois CABs e o sangue de um analista de produção, a afirmação parece paranormal.
Dylan Dog foi chamado.
Vamos investigar.
🕵️ CAPÍTULO 1 — O cadáver que se recusava a morrer
A primeira coisa que chamou a atenção de Dylan foi a idade da vítima.
O mainframe já havia sido declarado morto tantas vezes que seu prontuário parecia uma coleção de obituários.
Client/server iria matá-lo.
Depois Unix.
Depois Windows.
Depois servidores x86.
Depois Java.
Depois a Web.
Depois cloud.
Depois containers.
Depois Kubernetes.
Agora inteligência artificial.
Dylan abriu o arquivo.
STATUS: EXECUTING.
— Estranho — comentou ele.
Muito estranho.
Talvez estivéssemos procurando o cadáver errado.
Porque o IBM Z moderno não é simplesmente um computador gigantesco escondido no porão executando programas COBOL escritos quando os Beatles ainda tocavam juntos.
Ele é uma plataforma capaz de reunir tecnologias de gerações muito diferentes.
Podemos encontrar algo parecido com:
IBM Z
│
┌──────────┼──────────┐
│ │ │
z/OS Linux z/VM
│ │ │
COBOL Python Virtualização
CICS Java
IMS Open Source
Db2 Containers
MQ
A primeira pista estava diante de Dylan.
Talvez evolução do mainframe não significasse substituição.
Significasse incorporação.
🧟 CAPÍTULO 2 — Frankenstein não precisava morrer
Existe uma velha tentação em tecnologia.
Quando encontramos algo antigo, imediatamente pensamos:
"Precisamos substituir isso."
Imagine um banco possuindo milhões de linhas COBOL responsáveis por contas, cartões, pagamentos, empréstimos e liquidação financeira.
Alguém entra na reunião e anuncia:
— Temos uma ideia revolucionária! Vamos reescrever tudo!
Porque abstração sem fundamento produz profissionais que sabem apertar botões, mas não entendem o que acontece quando o botão falha.
Porém acrescentaria outra coluna:
MAINFRAME CLÁSSICO ENGENHARIA MODERNA
TSO/ISPF VS Code
JCL Pipelines
COBOL Git
CICS APIs
Db2 Observability
RACF IAM concepts
SDSF Automation
SMF Telemetry
USS Open Source
Não são inimigos.
São camadas de conhecimento.
O profissional interessante do futuro sabe atravessar essa ponte.
Não confie no monstro apenas porque ele fala educadamente.
Código gerado precisa ser revisado.
JCL precisa ser entendido.
Sugestões precisam ser validadas.
Segurança precisa permanecer sob controle.
Imagine uma IA sugerindo:
PERMIT * CLASS(DATASET) ACCESS(ALTER)
e alguém respondendo:
"A inteligência artificial recomendou."
Nesse momento o verdadeiro terror começou.
IA deve aumentar a capacidade do engenheiro.
Não abolir julgamento técnico.
🕯️ CAPÍTULO 19 — O Easter Egg das 03:17
Às 03:17, todos os dashboards ficaram vermelhos.
CPU?
Normal.
Storage?
Normal.
CICS?
UP.
Db2?
UP.
MQ?
UP.
Kubernetes?
Healthy.
O operador escreveu:
03:17:22 - USERS REPORTING PAYMENT TIMEOUT
Dylan olhou para o dashboard.
Tudo verde.
Olhou novamente para o cliente.
Tudo quebrado.
E finalmente percebeu o verdadeiro pesadelo:
Todos monitoravam componentes. Ninguém monitorava a experiência completa.
O sistema poderia estar tecnicamente saudável enquanto o serviço estava funcionalmente morto.
Essa talvez seja a melhor explicação de por que observabilidade tornou-se tão importante.
🧩 CAPÍTULO 20 — Security + Monitoring + Scaling
Finalmente podemos retornar ao título:
Securing
Garantir que as novas portas abertas pela modernização não destruam décadas de controles.
Monitoring
Sair da visão isolada do componente e compreender a transação ponta a ponta.
Scaling
Fazer ambientes distribuídos e mainframe responderem à demanda sem simplesmente transferir o gargalo de uma camada para outra.
E existe um quarto elemento escondido:
Integrating
Porque todos os anteriores dependem dele.
MAINFRAME EVOLUTION
│
┌──────────────┼──────────────┐
│ │ │
SECURITY OBSERVABILITY SCALE
│ │ │
└──────────────┼──────────────┘
│
INTEGRATION
│
OPEN SOURCE
│
AUTOMATION
│
IBM Z
☕ EPÍLOGO — Dylan fecha o caso
O sol começava a nascer.
Groucho trouxe café.
Dylan fechou a pasta.
Na capa escreveu:
CASE CLOSED?
Depois riscou o ponto de interrogação.
E tornou a colocá-lo.
Porque sistemas nunca ficam realmente prontos.
Eles evoluem.
O ponto central de Mainframe Evolution: Securing, Monitoring, and Scaling with Next-Gen Open Source não precisa ser interpretado como uma guerra entre dois mundos.
Não é:
MAINFRAME
VS
OPEN SOURCE
Também não é:
OLD
↓
DELETE
↓
NEW
É algo muito mais interessante:
60+ ANOS DE ENGENHARIA
│
▼
IBM Z
│
┌─────────┼─────────┐
│ │ │
z/OS Linux Open Source
│ │ │
COBOL/CICS Apps Tools
Db2/IMS/MQ Cloud Automation
│ │ │
└─────────┼─────────┘
│
APIs
│
Git
│
CI/CD
│
Observability
│
Security
│
AI
│
▼
MODERN ENTERPRISE
E isso nos conduz a uma conclusão deliciosa para alguém que trabalha com mainframe.
Durante décadas perguntaram:
"Quando o mainframe vai morrer?"
Talvez a pergunta estivesse errada.
A pergunta mais interessante em 2026 é:
"Quantas tecnologias novas o mainframe ainda conseguirá absorver sem deixar de ser mainframe?"
Até agora, a resposta parece ser:
muitas.
Talvez seja exatamente isso que explique sua longevidade.
O mainframe não sobreviveu apesar das mudanças.
Em boa medida, sobreviveu porque aprendeu a incorporá-las.
Dylan Dog saiu do data center.
As luzes se apagaram.
Uma última mensagem apareceu no console:
IEF404I BELLACOSA - ENDED - TIME=04.17.00
Groucho olhou para a tela.
— Então o monstro morreu?
Dylan vestiu o casaco.
— Não.
— E agora?
Ao fundo, outra mensagem apareceu:
$HASP100 BELLACOSA ON READER
O JOB seguinte acabara de entrar.
☕ Bellacosa Mainframe — porque no mainframe até os fantasmas têm retrocompatibilidade.
Bellacosa Mainframe e o processamento do cartão de credito
☕ Um Café no Bellacosa Mainframe
💳 BELLACARD — Como seria um sistema de cartões de crédito dentro de um IBM Mainframe?
Do “BIP!” da maquininha ao COBOL, CICS, Db2, MQ, JCL, RACF, criptografia, antifraude, clearing, settlement e bilhões de transações que ninguém percebe.
Imagine a cena.
Você entra numa cafeteria, pede um café, aproxima o cartão da maquininha e...
BIP!
TRANSAÇÃO APROVADA
R$ 17,50
Você guarda o cartão, pega o café e continua a vida.
Talvez tenham se passado dois segundos.
Para o consumidor, acabou.
Para um programador mainframe curioso, porém, aconteceu uma pequena maravilha tecnológica.
Aqueles poucos segundos podem envolver terminal de pagamento, adquirente, rede de cartões, banco emissor, sistemas de autorização, criptografia, verificação do cartão, consulta de limites, regras de segurança, sistemas antifraude, bancos de dados, logs, mensagens entre plataformas e uma resposta que precisa percorrer boa parte desse caminho no sentido contrário.
E ainda não acabou.
Mais tarde haverá processamento financeiro, clearing, settlement, conciliação, lançamento da compra, fechamento da fatura, eventual parcelamento, pagamento, contabilização, estorno, contestação e talvez até um chargeback.
A humilde compra do café abriu uma pequena saga computacional.
E é exatamente por isso que cartões de crédito são um excelente laboratório para entender por que mainframes existem.
Então coloque café na caneca.
Hoje construiremos mentalmente o:
💳 BELLACARD — Credit Card Processing System for z/OS
Não será o projeto real de nenhum banco ou bandeira. Será uma arquitetura didática para entendermos como tecnologias como COBOL, CICS, Db2, MQ, JCL/JES2, RACF, criptografia, SMF, WLM e Parallel Sysplex podem participar de um grande sistema financeiro.
🏪 Capítulo 1 — Tudo começa com R$ 100
Imagine uma compra:
CLIENTE: JOÃO
VALOR: R$ 100,00
ESTABELECIMENTO: CAFÉ DO MAINFRAME
FORMA: CARTÃO
O cartão é apresentado.
A maquininha não conhece necessariamente o saldo da conta do cliente.
O estabelecimento também não.
A adquirente não é necessariamente quem concedeu o crédito.
Visa e Mastercard, por exemplo, operam redes que conectam os participantes do ecossistema.
O banco emissor é quem conhece o cartão, sua situação, conta relacionada, limite e diversas regras necessárias para decidir se aquela operação pode prosseguir.
Portanto, eventualmente surge uma pergunta:
“Banco, você autoriza esta compra?”
É aí que nosso BELLACARD acorda.
📨 Capítulo 2 — Uma mensagem bate à porta
Imagine que recebamos uma representação simplificada da operação:
TRANSACTION TYPE : PURCHASE
CARD TOKEN : 987654321
AMOUNT : 100.00
CURRENCY : BRL
MERCHANT ID : 785932
MCC : 5812
COUNTRY : BRA
ENTRY MODE : CONTACTLESS
DATE : 20260914
TIME : 031700
Sim.
03:17.
Quem acompanha o Bellacosa Mainframe sabe que esse horário nunca aparece por acidente.
😏
Nosso primeiro easter egg já foi registrado.
Em sistemas reais, mensagens de cartões podem utilizar padrões e protocolos próprios do setor, incluindo famílias baseadas em ISO 8583, além de APIs e formatos modernos dependendo da integração.
Para nosso iniciante COBOL, entretanto, vamos imaginar simplesmente um registro chegando ao mainframe.
🖥️ Capítulo 3 — CICS, atenda a porta!
Dentro do z/OS poderíamos possuir uma transação CICS:
Valores decimais, regras empresariais, processamento de registros e grandes volumes de dados são precisamente o tipo de problema para o qual COBOL nasceu.
🇧🇷 Capítulo 15 — A entidade brasileira chamada PARCELAMENTO
Agora compramos:
R$ 1.200 em 12x
Nosso sistema registra:
PURCHASE_ID = 9838172
TOTAL = 1200.00
QTY = 12
E teremos:
01/12 100
02/12 100
03/12 100
...
12/12 100
Parece simples.
Até alguém perguntar:
“E se houver estorno na parcela 7?”
Ou:
“E se for estorno parcial?”
Ou:
“E se o cliente contestar a compra?”
Ou:
“E se houver renegociação?”
Ou:
“E se existir juros?”
Ou:
“E se o comerciante fizer refund?”
É assim que programas pequenos envelhecem e viram programas COBOL de 30 mil linhas.
Não necessariamente porque os programadores antigos eram malucos.
Frequentemente porque 30 anos de realidade foram sendo incorporados ao código.
Essa é uma lição importantíssima para quem entra hoje no mainframe.
Código legado muitas vezes é também:
regra de negócio fossilizada.
Não apague antes de descobrir por que existe.
🔐 Capítulo 16 — RACF: não, estagiário, você não pode consultar todos os cartões
WHO
CAN DO WHAT
TO WHICH RESOURCE
UNDER WHICH CONDITIONS
RACF pode participar do controle de acesso ao ambiente z/OS.
Podemos proteger datasets, transações, usuários, grupos e diversos recursos.
Conceitualmente:
USER VAGNER
│
├── AUTH → READ/EXECUTE
├── BILL → READ
└── ADMIN → NO ACCESS
O princípio essencial é:
LEAST PRIVILEGE.
Um programa deve possuir apenas os acessos necessários.
Um operador também.
Um desenvolvedor também.
E definitivamente ninguém deveria possuir acesso porque:
“Vai que um dia eu precise.”
🔑 Capítulo 17 — E as chaves criptográficas?
Agora entramos em território ainda mais sensível.
Cartões envolvem criptografia, autenticação, tokens, PINs e material criptográfico.
A regra de ouro é:
chaves críticas não devem virar variáveis COBOL espalhadas pela aplicação.
Algo como:
01 SUPER-SECRET-KEY PIC X(32)
VALUE 'MINHACHAVE123...'.
é praticamente uma carta de demissão escrita em COBOL.
😂
Ambientes financeiros utilizam infraestrutura criptográfica especializada e HSMs — Hardware Security Modules — para determinadas operações e proteção de chaves.
A aplicação solicita uma operação criptográfica.
O segredo permanece protegido.
🕵️ Capítulo 18 — “Eu não fiz essa compra.”
Três meses depois o cliente telefona:
Eu nunca fiz essa compra.
O sistema precisa reconstruir o passado.
Queremos saber:
QUANDO?
QUAL CARTÃO?
QUAL MERCHANT?
QUAL VALOR?
QUAL CANAL?
QUAL RESPOSTA?
QUAL SISTEMA?
QUAL REGRA?
QUAL RESULTADO?
Logs e trilhas de auditoria tornam-se fundamentais.
No universo z/OS, SMF e informações produzidas pelos subsistemas ajudam a construir observabilidade e auditoria.
Nosso sistema deveria conseguir reconstruir algo como:
03:17:00.103 REQUEST RECEIVED
03:17:00.108 CARD VALIDATED
03:17:00.112 STATUS ACTIVE
03:17:00.119 LIMIT OK
03:17:00.127 RISK SCORE 214
03:17:00.133 AUTH CREATED
03:17:00.139 LIMIT RESERVED
03:17:00.145 COMMIT
03:17:00.151 APPROVED
E aí descobrimos outra característica dos sistemas financeiros:
não basta fazer certo. Precisamos conseguir demonstrar posteriormente o que aconteceu.
🏰 Capítulo 19 — E se o mainframe cair?
Imagine milhões de pessoas tentando pagar almoço e recebendo:
HOST UNAVAILABLE
O problema deixa rapidamente de ser “um incidente de TI”.
Vira problema comercial, financeiro e reputacional.
Daí entram conceitos de alta disponibilidade e arquiteturas como Parallel Sysplex.
Didaticamente:
REQUESTS
│
▼
WORKLOAD ROUTING
│
┌──────────┴──────────┐
▼ ▼
z/OS A z/OS B
CICS CICS
│ │
└──────────┬──────────┘
▼
Db2
Data Sharing
Falhou um componente?
A arquitetura é desenhada para evitar que isso necessariamente signifique:
TODO MUNDO PARA.
É aqui que redundância, recuperação, data sharing, workload management, automação operacional e engenharia de resiliência deixam de ser palavras bonitas de PowerPoint.
🏙️ Capítulo 20 — As duas cidades do cartão
Eu gosto de imaginar o BELLACARD dividido em duas grandes cidades.
Talvez essa seja uma das melhores maneiras de explicar mainframe para alguém que está começando.
Não comece dizendo:
“COBOL possui DIVISION, SECTION e PARAGRAPH.”
Comece dizendo:
“Você acabou de passar um cartão. Quer descobrir o que pode existir atrás daquele BIP?”
Então COBOL ganha propósito.
CICS ganha propósito.
Db2 ganha propósito.
MQ ganha propósito.
JCL ganha propósito.
RACF ganha propósito.
SMF ganha propósito.
WLM ganha propósito.
Parallel Sysplex ganha propósito.
O iniciante deixa de decorar siglas e começa a compreender problemas.
E tecnologia empresarial é exatamente isso:
uma coleção de soluções para problemas que ficaram grandes demais para serem resolvidos de qualquer jeito.
Da próxima vez que aproximar seu cartão e ouvir:
BIP!
talvez você enxergue algo diferente.
Não apenas uma compra.
Mas uma mensagem atravessando redes, chegando a sistemas que verificam identidade, estado, crédito e risco; uma unidade de trabalho sendo protegida; registros sendo preservados; eventos sendo produzidos; sistemas financeiros preparando o que acontecerá depois.
E talvez exista, em algum canto de algum sistema que ninguém ousa desligar, um programa COBOL escrito décadas atrás, trabalhando silenciosamente para que seu café seja pago.
Sem aplausos.
Sem interface bonita.
Sem ninguém perceber.
Como tantas outras coisas no mainframe.
Porque a melhor infraestrutura é aquela que desaparece atrás do serviço que presta.
E enquanto o mundo vê apenas o BIP, nós sabemos que atrás dele pode existir uma verdadeira catedral transacional construída byte por byte, regra por regra e geração por geração de programadores.
☕ Um Café no Bellacosa Mainframe
Onde até uma compra de R$ 17,50 pode acabar em CICS, Db2, COBOL e uma War Room às 03:17.
☕ Um Café no Bellacosa Mainframe
🕵️ The Mentalist no Mainframe — O Caso dos R$ 100
que Atravessaram um Sistema de Cartões
Entenda como uma compra de R$ 100 atravessa POS, adquirente,
bandeira, emissor, autorização, plafond, clearing, settlement,
cobrança, contabilidade e reconciliação em um ambiente bancário
e mainframe.
💳 Como funciona uma transação de cartão de crédito?
Uma compra aparentemente simples percorre diversos participantes
e sistemas. O cliente apresenta o cartão ao estabelecimento,
a maquininha envia a transação ao adquirente, a rede encaminha
a solicitação ao emissor e o banco verifica cartão, conta,
produto, plafond, regras e risco antes de autorizar ou recusar.
Depois da autorização, a transação ainda pode passar por
reversal, clearing, settlement, faturamento, cobrança,
contabilização, reconciliação, disputa e chargeback.
Principais assuntos:
IBM Mainframe, IBM Z, COBOL, CICS, Db2, cartões de crédito,
POS, adquirente, emissor, autorização, plafond, clearing,
settlement, tarifas, cobrança, contabilidade e reconciliação.
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
