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

terça-feira, 29 de setembro de 2026

🕵️ CHARLES PONZI ENTRA NO CPD — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE INTELIGÊNCIA É UM ENORME PERFORM UNTIL

 
Bellacosa Mainframe e System Security

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🕵️ CHARLES PONZI ENTRA NO CPD — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE INTELIGÊNCIA É UM ENORME PERFORM UNTIL

Mainframe Security, RACF, SMF, CICS, Db2, MQ, fraude, lavagem de dinheiro, inteligência financeira, graph analytics, entity resolution, threat hunting, IA, falsos positivos, narcossubmarinos, análise de esgoto — e o dia em que descobrimos que 17.390 hipóteses descartadas talvez ainda tivessem alguma coisa para contar.



🎬 PRÓLOGO — CHARLES PONZI ESTAVA ESPERANDO NO CPD

Eram 03:17 da manhã.

O programador COBOL entrou no CPD carregando um café que provavelmente já poderia ser classificado como material radioativo.

Na frente do terminal 3270 havia um homem de terno impecável.

— Quem é você?

— Charles Ponzi.

O programador quase derrubou o café.

— O Charles Ponzi?

— Depende. Se você estiver oferecendo investimentos, não. Se estiver tentando entender fraude, talvez eu possa ser útil como exemplo do que não fazer.

Na tela havia 80 milhões de registros.

Contas.

Empresas.

Transações.

Usuários.

Endereços.

Telefones.

Logs.

Eventos.

O programador olhou aquilo e perguntou:

— Qual deles é criminoso?

Ponzi sorriu.

— Você já começou fazendo a pergunta errada.

— Qual seria a pergunta certa?

Ele apontou para a tela.

Quais relações nesse sistema não deveriam existir?

E foi assim que começou nossa viagem.



🧠 CAPÍTULO 1 — PRIMEIRO: SEGURANÇA NÃO É RACF

Para quem está começando em mainframe, é tentador imaginar:

SEGURANÇA = RACF

RACF é importantíssimo.

Mas segurança de um ambiente IBM Z moderno é muito maior.

Temos algo aproximadamente assim:

                    IDENTIDADE
                        │
                       RACF
                        │
        ┌───────────────┼───────────────┐
        │               │               │
       TSO             USS             JES
        │               │               │
        └───────────────┼───────────────┘
                        │
          ┌─────────────┼─────────────┐
          │             │             │
        CICS           Db2            MQ
          │             │             │
          └─────────────┼─────────────┘
                        │
                      APIs
                        │
                 z/OS Connect
                        │
                  CLOUD / WEB

Um profissional de Bellacosa Mainframe Security precisa compreender as relações entre essas camadas.

Não basta perguntar:

“Vagner possui acesso ao dataset PROD.PAYROLL.MASTER?”

Precisamos perguntar:

VAGNER
  │
  ▼
GROUP-X
  │
  ▼
JCL
  │
  ▼
SUBMIT
  │
  ▼
STARTED TASK
  │
  ▼
PROGRAMA
  │
  ▼
Db2
  │
  ▼
PAYROLL

Talvez Vagner não tenha acesso direto ao dado.

Mas possui um caminho até ele.

Essa mudança parece pequena.

Não é.

Estamos deixando de pensar somente em permissões e começando a pensar em grafos.



🕸️ CAPÍTULO 2 — MAS O QUE DIABOS É UM GRAFO?

Nada de assustador.

Um grafo é basicamente:

NÓS + RELAÇÕES

Imagine:

VAGNER ── trabalha_em ──► EMPRESA_A

Temos dois nós:

VAGNER
EMPRESA_A

e uma relação:

trabalha_em

Agora adicionamos:

VAGNER ───── usa ───────► USER123
USER123 ─── acessa ─────► CICS01
CICS01 ─── executa ─────► PAY001
PAY001 ───── lê ────────► DB2.TABLE_X

Pronto.

Temos um pequeno grafo de segurança.

Agora imagine milhões de nós.

É aí que começa a diversão.



💰 CAPÍTULO 3 — CHARLES PONZI OLHA PARA UMA TRANSAÇÃO

Ponzi colocou uma transferência na tela:

CONTA A → R$ 49.850 → CONTA B

— Fraudulenta? — perguntou ele.

O programador analisou.

Conta existente.

Saldo suficiente.

Autenticação correta.

Transação autorizada.

Horário normal.

— Parece legítima.

Ponzi colocou outra:

CONTA C → R$ 48.970 → CONTA B

Depois:

CONTA D → R$ 51.120 → CONTA E
CONTA E → R$ 50.880 → EMPRESA X
CONTA F → R$ 49.310 → EMPRESA X
CONTA G → R$ 50.220 → EMPRESA X

Então perguntou:

— E agora?

A resposta mudou.

Não porque alguma transação individual necessariamente seja criminosa.

Mas porque surgiu um comportamento.

Essa é uma ideia fundamental:

Uma transação pode ser tecnicamente perfeita e ainda fazer parte de um comportamento que merece investigação.

O mainframe pode responder:

RACF ........ OK
CICS ........ OK
Db2 ......... OK
MQ .......... OK
SALDO ....... OK
CONTA ....... OK

E ainda assim alguma coisa pode estar errada no nível superior.



🔎 CAPÍTULO 4 — EVENTO NÃO É COMPORTAMENTO

Esse princípio vale também para cybersecurity.

Imagine:

02:13 USERX READ DATASET.A

Normal.

Depois:

02:17 USERX SUBMIT JOB77

Talvez normal.

Depois:

02:19 JOB77 ACCESS DB2.TABLE

Ainda plausível.

Depois:

02:22 MQ PUT QUEUE.EXTERNAL

Agora temos:

LOGIN
  ↓
DATASET
  ↓
JOB
  ↓
Db2
  ↓
MQ
  ↓
EXTERNAL

Individualmente:

evento → talvez normal

Coletivamente:

sequência → interessante

É aqui que SMF deixa de ser apenas auditoria e passa a ser matéria-prima para inteligência.


🐒 CAPÍTULO 5 — OS CHIMPANZÉS INVENTAM OS IFs

Ponzi perguntou:

— Como começamos?

O programador COBOL respondeu imediatamente:

IF ALGUMA-COISA-ESTRANHA
    PERFORM INVESTIGAR
END-IF

Ponzi suspirou.

— Depois dizem que COBOL está morto.

A ideia é simples.

Começamos com muitos IFs.

IF movimentação incompatível
IF empresa recém-criada
IF endereço compartilhado
IF telefone compartilhado
IF dispositivo compartilhado
IF procurador compartilhado
IF fluxo circular
IF concentração incomum
IF dispersão rápida
IF comportamento temporal incomum

Nenhum deles significa:

CRIMINOSO = TRUE

Isso seria perigosíssimo.

Eles significam:

INTERESSE-ANALITICO = INTERESSE-ANALITICO + 1

🎯 CAPÍTULO 6 — DE MILHÕES DE EVENTOS PARA QUATRO PERGUNTAS

Aqui surgiu uma das ideias centrais da nossa conversa.

Imagine:

80.000.000 eventos
        ↓
17.432 hipóteses
        ↓
correlação
        ↓
2.100
        ↓
contexto
        ↓
340
        ↓
entity resolution
        ↓
42
        ↓
fontes independentes
        ↓
4

A função da IA não deveria ser anunciar:

“ENCONTREI QUATRO CRIMINOSOS!”

Não.

A função seria dizer:

“Estas quatro estruturas merecem que investigadores humanos gastem tempo entendendo o que está acontecendo.”

Essa diferença é gigantesca.

Temos:

ANOMALIA ≠ FRAUDE
CORRELAÇÃO ≠ CAUSALIDADE
RELAÇÃO ≠ CUMPLICIDADE
HIPÓTESE ≠ EVIDÊNCIA
EVIDÊNCIA ≠ CONDENAÇÃO

Grave isso.


👥 CAPÍTULO 7 — ENTITY RESOLUTION

Agora surge outro problema.

Quem é “João”?

Temos:

JOÃO
 │
 ├── CPF
 ├── telefone
 ├── endereço
 ├── conta
 ├── cartão
 ├── empresa
 ├── dispositivo
 └── e-mail

Outra empresa utiliza o mesmo endereço.

Outra conta utiliza o mesmo telefone.

Outra pessoa utiliza o mesmo dispositivo.

Outra empresa possui o mesmo procurador.

O que pareciam cem entidades independentes talvez formem um cluster.

É isso que Entity Resolution tenta resolver:

Quais registros representam a mesma entidade ou entidades relacionadas?

Esse problema aparece em bancos, seguradoras, telecomunicações, e-commerce, segurança e inteligência.


🕸️ CAPÍTULO 8 — NÃO PROCURE SOMENTE O MAIOR NÓ

Imagine:

A ─ B ─ C
│   │   │
D ─ X ─ E
    │
F ─ G ─ H

X talvez nem movimente mais dinheiro.

Mas praticamente todos os grupos passam por ele.

Isso introduz conceitos de centralidade em grafos.

Um nó pode ser importante porque:

  • possui muitas conexões;

  • conecta comunidades diferentes;

  • aparece em muitos caminhos;

  • controla um recurso;

  • concentra relacionamentos incomuns.

Às vezes a conta movimentando R$ 100 milhões chama atenção.

Mas o contador, procurador, dispositivo ou empresa que conecta quinze estruturas aparentemente independentes pode ser analiticamente muito mais interessante.

Dinheiro mostra volume. Conectividade pode revelar estrutura.


🔄 CAPÍTULO 9 — AS 17.390 HIPÓTESES NÃO MORRERAM

Aqui nossos chimpanzés tiveram outra crise existencial.

Suponha:

17.432 hipóteses

Após análise:

42 relevantes
17.390 descartadas

DELETE?

Jamais.

Talvez:

STATUS = LOW-PRIORITY

Porque hoje temos:

X → Y

Existe explicação comercial plausível.

Baixa prioridade.

Seis meses depois:

X → Y → Z → Q
        │
        └────► NOVA ENTIDADE RELEVANTE

Subitamente aquela transação antiga ganha outro significado.

O evento não mudou.

Nosso conhecimento mudou.


🦖 CAPÍTULO 10 — SMF JÁ SABIA

Isso é deliciosamente mainframe.

Imagine que um incidente seja descoberto em setembro.

Então alguém pergunta:

“Esse usuário já havia feito isso antes?”

Você consulta registros históricos.

E encontra:

MARÇO
USERX → DATASET.A

ABRIL
USERX → JOB77

MAIO
JOB77 → MQ.X

JUNHO
USERX → USS

Na época, eram eventos aparentemente desconectados.

Agora possuem contexto.

É por isso que retenção, integridade, timestamps e correlação histórica são tão importantes.

O passado pode adquirir novo significado.


♻️ CAPÍTULO 11 — O SISTEMA COMEÇA A APRENDER

Agora temos um loop:

OBSERVAR
   ↓
HIPÓTESE
   ↓
TESTAR
   ↓
INVESTIGAR
   ↓
RESULTADO
   ↓
APRENDER
   ↓
REANALISAR
   ↺

Se uma investigação confirmar determinada estrutura, aprendemos.

Se concluir que era perfeitamente legítima, também aprendemos.

Precisamos guardar:

TRUE POSITIVE
FALSE POSITIVE
FALSE NEGATIVE
TRUE NEGATIVE

Isso permite melhorar priorização futura.

Mas existe uma armadilha.


⚠️ CAPÍTULO 12 — A IA NÃO PODE CONFIRMAR A SI MESMA

Imagine:

IA suspeita de João
       ↓
João recebe mais investigação
       ↓
coletamos mais dados sobre João
       ↓
encontramos mais coisas incomuns
       ↓
IA conclui:
"EU TINHA RAZÃO!"

Talvez não.

Quanto mais observamos alguém, maior a chance de encontrarmos alguma anomalia.

Criamos um feedback loop de viés.

Portanto precisamos separar claramente:

OBSERVAÇÃO
     │
INFERÊNCIA
     │
HIPÓTESE
     │
EVIDÊNCIA INDEPENDENTE
     │
RESULTADO INVESTIGATIVO

A hipótese produzida pela IA não pode virar evidência para confirmar a própria hipótese.


🚽 CAPÍTULO 13 — QUANDO O ESGOTO VIROU TELEMETRIA

E então nossa conversa ficou realmente estranha.

Descobrimos que pesquisadores conseguem analisar águas residuais de cidades procurando metabólitos associados ao consumo de drogas.

Para cocaína, um marcador utilizado é a benzoilecgonina (BE).

A EUDA informa que seu estudo de 2025 envolveu 115 cidades europeias. Entre as 85 com dados comparáveis entre 2024 e 2025, 48 apresentaram aumento da carga de BE; no agregado comparável, houve aumento de aproximadamente 22%.

Isso não significa identificar indivíduos.

É uma medida populacional.

Em linguagem Bellacosa:

o esgoto virou uma espécie de SMF da cidade.

😂

Temos outro sensor independente:

APREENSÕES ───────────┐
                      │
PREÇO/PUREZA ─────────┤
                      │
ESGOTO ───────────────┤
                      │
HOSPITAIS ────────────┤
                      ├──► MODELO
FLUXOS FINANCEIROS ───┤
                      │
PORTOS ───────────────┤
                      │
INTELIGÊNCIA ─────────┘

Nenhum sensor sozinho conta toda a história.

A convergência é que interessa.


🚢 CAPÍTULO 14 — O NARCOSSUBMARINO NÃO É O PROBLEMA

Outro chimpanzé olhou pela janela e perguntou:

— Como organizações criminosas conseguem construir semissubmersíveis?

Boa pergunta.

A UNODC documenta diferentes categorias de embarcações utilizadas no tráfico marítimo, incluindo Low Profile Vessels, semissubmersíveis autopropulsados e, mais raramente, veículos totalmente submersíveis. As capacidades descritas chegam a várias toneladas por embarcação.

Mas o interessante para nós não é aprender a construir uma.

É perguntar:

Que organização precisa existir para conseguir produzir e operar repetidamente algo complexo?

Um artefato pressupõe uma rede:

EMBARCAÇÃO
    ▲
    │
engenharia
    │
materiais
    │
fornecedores
    │
financiamento
    │
pessoas
    │
conhecimento
    │
logística
    │
origem ───────────── destino

Portanto:

Não procure apenas o objeto produzido pela organização. Procure a organização capaz de produzir o próximo.

Isso vale para cybersecurity.

Encontrar um malware não significa necessariamente eliminar o grupo capaz de criar outro.

Bloquear um usuário comprometido não elimina necessariamente o caminho utilizado para comprometê-lo.


🧠 CAPÍTULO 15 — CONHECIMENTO TAMBÉM É UM ATIVO

Uma organização complexa aprende.

Algo parecido com:

MISSÃO
  ↓
RESULTADO
  ↓
FEEDBACK
  ↓
APRENDIZADO
  ↓
PRÓXIMA MISSÃO

Isso é organizational learning.

A embarcação pode desaparecer.

Uma carga pode ser apreendida.

Um operador pode ser preso.

Mas se permanecerem:

CAPITAL
+
CONHECIMENTO
+
FORNECEDORES
+
RELACIONAMENTOS
+
LOGÍSTICA

a capacidade pode ser reconstruída.

É exatamente a diferença entre:

destruir uma instância

e:

eliminar a capacidade de criar novas instâncias

Programadores entendem isso imediatamente.

Você matou um processo.

Mas quem continua fazendo:

START TASK

?


🏛️ CAPÍTULO 16 — MAS O ESTADO NÃO PENSA NISSO?

Aqui tivemos outra pergunta importante.

Se uma pessoa tomando café consegue chegar a essas ideias, por que autoridades não fariam o mesmo?

Fazem.

O Brasil possui estruturas de inteligência financeira e cooperação institucional. O Coaf, por exemplo, utiliza processos automatizados de classificação de risco e posteriormente análise aprofundada por analistas; informações recebidas permanecem em sua base e podem ganhar relevância quando confrontadas com novos dados.

Somente em 2025 foram produzidos 20.548 Relatórios de Inteligência Financeira (RIFs).

Ou seja:

DADOS
 ↓
RISCO
 ↓
PRIORIZAÇÃO
 ↓
ANALISTA
 ↓
RIF

Nossa ideia não nasceu em Marte.

O desafio é escala, integração e efetividade.


🧱 CAPÍTULO 17 — O CRIMINOSO NÃO RESPEITA ORGANOGRAMA

Uma organização estatal pode possuir:

POLÍCIA
RECEITA
COAF
BANCO CENTRAL
CVM
MINISTÉRIO PÚBLICO
JUDICIÁRIO
ESTADOS
MUNICÍPIOS

Cada qual com competências, sistemas, autorizações e limites legais.

A rede criminosa não precisa respeitar essas fronteiras.

Ela pensa simplesmente:

DINHEIRO
  ↓
PESSOA
  ↓
EMPRESA
  ↓
TRANSPORTE
  ↓
OUTRA EMPRESA
  ↓
OUTRO PAÍS

Essa assimetria é importantíssima.

O FATF/GAFILAT reconheceu avanços brasileiros em avaliação de risco, cooperação internacional e coordenação, mas também apontou necessidade de fortalecer cooperação entre determinadas autoridades — particularmente polícia, Ministério Público e administração tributária — e melhorar a persecução da lavagem de dinheiro.

Portanto:

o problema não é necessariamente ausência de inteligência. Pode ser dificuldade de transformar inteligências distribuídas em uma visão operacional integrada.

Isso parece familiar?

Claro.

É um problema de integração de sistemas.


🦖 CAPÍTULO 18 — O PROGRAMADOR COBOL FINALMENTE ENTENDE

Imagine:

SISTEMA-A
SISTEMA-B
SISTEMA-C
SISTEMA-D

Cada um possui dados excelentes.

Mas nenhum conversa adequadamente com os demais.

Programadores mainframe conhecem essa história desde antes de muita gente nascer.

O desafio passa a ser:

EXTRACT
   ↓
NORMALIZE
   ↓
CORRELATE
   ↓
RESOLVE ENTITY
   ↓
BUILD GRAPH
   ↓
ANALYZE

De repente, décadas trabalhando com sistemas corporativos deixam de ser apenas experiência em tecnologia antiga.

Viraram experiência em:

dados críticos, integração, identidade, transações, auditoria, consistência e processamento em escala.


🛡️ CAPÍTULO 19 — NASCE O BELLACOSA MAINFRAME SECURITY

Nossa trilha começou assim:

SECURITY 101

RACF
 ↓
USS
 ↓
CICS
 ↓
Db2
 ↓
MQ
 ↓
TCP/IP
 ↓
TLS

Depois:

SECURITY 201

ICSF / PKI
 ↓
SMF
 ↓
SIEM
 ↓
MITRE ATT&CK
 ↓
DevSecOps
 ↓
API Security
 ↓
Cloud Security

E finalmente:

SECURITY 301

Threat Hunting
 ↓
Incident Response
 ↓
UEBA
 ↓
Graph Analytics
 ↓
Entity Resolution
 ↓
Fraud Analytics
 ↓
Threat Intelligence
 ↓
AI Security

Agora a pergunta mudou.

Não queremos somente saber:

Quem possui acesso?

Queremos saber:

O que essa identidade consegue fazer?

Depois:

Esse comportamento é normal?

Depois:

Com quem essa entidade está relacionada?

E finalmente:

Qual estrutura aparece quando observamos todas essas relações conjuntamente?


🤖 CAPÍTULO 20 — A IA DOMÉSTICA E A IA INSTITUCIONAL

Durante nossa conversa fizemos algo curioso.

Humano:

"e se...?"

IA:

"plausível, mas..."

Humano:

"então talvez..."

IA:

"vamos testar..."

E repetimos.

Isso cria:

HUMANO
  ↓
HIPÓTESE
  ↓
IA
  ↓
CONFRONTO
  ↓
CONTRADIÇÃO
  ↓
REFINAMENTO
  ↓
NOVA HIPÓTESE
  ↺

Agora imagine isso dentro de uma organização, trabalhando somente sobre dados aos quais ela esteja legalmente autorizada a acessar.

A diferença não seria uma IA “sem limites”.

Seria:

IA
+
DADOS AUTORIZADOS
+
GRAPH
+
MEMÓRIA
+
AUDITORIA
+
ANALISTAS

Muito mais poderoso.

E também muito mais perigoso se mal governado.

Por isso precisaríamos praticamente de um RACF para a própria IA:

WHO
 ↓
ACCESSED WHAT
 ↓
WHY
 ↓
UNDER WHICH AUTHORITY
 ↓
WHAT WAS INFERRED
 ↓
WHAT WAS DECIDED
 ↓
WHO APPROVED
 ↓
AUDIT

🔐 CAPÍTULO 21 — ZERO TRUST PARA A INTELIGÊNCIA

Uma IA investigativa não deveria possuir:

SPECIAL
OPERATIONS
AUDITOR

tudo ao mesmo tempo.

😂

Precisamos de:

  • least privilege;

  • segregação de funções;

  • trilha de auditoria;

  • controle de acesso;

  • retenção adequada;

  • justificativa de consulta;

  • proteção de dados;

  • revisão humana;

  • cadeia de custódia;

  • controles contra abuso.

A mesma filosofia usada para proteger sistemas críticos deve proteger a ferramenta utilizada para investigá-los.


🔁 CAPÍTULO 22 — O GRANDE PERFORM UNTIL

Finalmente Ponzi voltou ao terminal.

— Então qual é o algoritmo?

O programador COBOL começou a escrever:

PERFORM UNTIL INVESTIGATION-COMPLETE

    PERFORM COLLECT-OBSERVATIONS

    PERFORM GENERATE-HYPOTHESES

    PERFORM TEST-HYPOTHESES

    PERFORM FIND-CONTRADICTIONS

    PERFORM CORRELATE-ENTITIES

    PERFORM PRIORITIZE

    PERFORM HUMAN-REVIEW

    PERFORM LEARN-FROM-RESULTS

    PERFORM REANALYZE-HISTORY

END-PERFORM.

Ponzi olhou.

— Isso compila?

— Provavelmente não.

— Então para que serve?

— Para explicar o conceito.


🧪 CAPÍTULO 23 — COMO EXPERIMENTAR ISSO SEM INVESTIGAR NINGUÉM

Aqui existe um excelente projeto educacional.

Crie dados inteiramente sintéticos.

Por exemplo:

50.000 pessoas fictícias
10.000 empresas fictícias
200.000 contas fictícias
5.000.000 transações fictícias

Introduza artificialmente alguns padrões conhecidos no dataset.

Depois tente encontrá-los.

Pipeline:

1. GERAR DADOS
      ↓
2. CRIAR ENTIDADES
      ↓
3. CRIAR RELAÇÕES
      ↓
4. INTRODUZIR PADRÕES
      ↓
5. ESCONDER A RESPOSTA
      ↓
6. EXECUTAR DETECÇÃO
      ↓
7. CRIAR GRAFO
      ↓
8. PRIORIZAR CLUSTERS
      ↓
9. MEDIR FALSOS POSITIVOS
      ↓
10. RETROALIMENTAR

Isso permitiria estudar graph analytics, IA e detecção sem acusar pessoas reais nem manipular dados sensíveis.


💡 CAPÍTULO 24 — DICA PARA O PROGRAMADOR COBOL

Não tente aprender tudo simultaneamente.

Comece pelas coisas que você já conhece.

Primeiro:

RACF.

Depois:

SMF.

Pergunte:

Quem fez o quê, quando e usando qual identidade?

Depois leve os eventos para um SIEM.

Aprenda correlação.

Depois aprenda Python suficiente para analisar dados.

Depois SQL.

Depois fundamentos de grafos.

Depois uma linguagem de consulta de grafos.

Depois:

  • anomaly detection;

  • entity resolution;

  • UEBA;

  • threat intelligence;

  • machine learning;

  • LLMs aplicados à análise.

Seu conhecimento COBOL não é obstáculo.

É vantagem.

Você já sabe que:

INPUT
 ↓
VALIDATION
 ↓
PROCESSING
 ↓
STATE CHANGE
 ↓
OUTPUT
 ↓
LOG

Todo sistema transacional sério faz alguma variação disso.


🧠 CAPÍTULO 25 — A GRANDE LIÇÃO DOS CHIMPANZÉS

No começo da conversa tínhamos perguntas aparentemente desconectadas.

Crime organizado.

Fintech.

Bancos.

Lavagem.

Política.

Produção agrícola.

Rotas.

Semissubmersíveis.

Águas residuais.

Mainframe.

SMF.

Grafos.

IA.

Parecia uma bagunça.

Até percebermos:

TODOS SÃO SISTEMAS

Sistemas possuem:

ENTIDADES
RELAÇÕES
ENTRADAS
SAÍDAS
ESTADO
DEPENDÊNCIAS
GARGALOS
TELEMETRIA
ANOMALIAS

E isso muda completamente nossa maneira de olhar problemas.


🎁 EASTER EGG — O COPYBOOK DE PONZI

Antes de ir embora, Ponzi deixou um copybook sobre a mesa:

       01 WS-INVESTIGATION.
          05 WS-HYPOTHESIS          PIC X(100).
          05 WS-CONFIDENCE          PIC 9(03).
          05 WS-EVIDENCE-COUNT      PIC 9(05).
          05 WS-CONTRADICTION-COUNT PIC 9(05).
          05 WS-STATUS              PIC X(10).

             88 HYPOTHESIS-WEAK     VALUE 'WEAK'.
             88 HYPOTHESIS-ACTIVE   VALUE 'ACTIVE'.
             88 HYPOTHESIS-REFUTED  VALUE 'REFUTED'.
             88 NEEDS-HUMAN         VALUE 'REVIEW'.

Na última linha havia um comentário:

      *-------------------------------------------------------*
      * NEVER MOVE 'GUILTY' TO WS-STATUS.                    *
      * THAT FIELD BELONGS TO DUE PROCESS, NOT TO THIS JOB.   *
      *-------------------------------------------------------*

O programador sorriu.

Finalmente Ponzi tinha produzido alguma coisa que ele confiaria em produção.


☕ EPÍLOGO — NÃO PROCURE O CRIMINOSO. PROCURE A PERGUNTA CERTA.

Talvez essa tenha sido a principal descoberta dessa viagem.

Um sistema de inteligência moderno não precisa começar sabendo a resposta.

Ele precisa conseguir perguntar:

“E se?”

Depois:

“Que evidência sustentaria isso?”

Depois:

“Que evidência destruiria essa hipótese?”

Depois:

“Existem fontes independentes apontando para a mesma estrutura?”

Depois:

“Qual explicação legítima também produziria esse comportamento?”

E somente depois:

“Vale gastar tempo humano investigando isso?”

É uma mudança brutal.

De:

ENCONTRE O CULPADO

para:

ENCONTRE AS MELHORES PERGUNTAS

É exatamente aí que IA e inteligência humana podem formar uma simbiose poderosa.

O humano possui algo maravilhoso:

curiosidade.

Ele olha para um problema e pergunta:

“Mas espere... e se?”

A máquina possui outra capacidade:

escala.

Ela pode procurar essa possibilidade em milhões de registros.

O humano volta:

“Isso não prova nada. Que outra explicação existe?”

A máquina testa novamente.

E nasce o loop:

              HUMANO
                 │
              pergunta
                 ↓
                IA
                 │
               dados
                 ↓
               GRAFO
                 │
             hipótese
                 ↓
           contradições
                 │
                 ▼
              HUMANO
                 │
             nova pergunta
                 │
                 └──────────────↺

Talvez o futuro da inteligência não seja uma super-IA dizendo aos humanos o que aconteceu.

Talvez seja algo muito mais interessante:

um humano extremamente curioso fazendo perguntas cada vez melhores enquanto uma máquina extremamente paciente verifica milhões de possibilidades.

E para o programador COBOL iniciante existe uma deliciosa ironia.

Passamos décadas escrevendo:

IF ...
    PERFORM ...
END-IF

Agora estamos descobrindo que algumas das perguntas mais difíceis de segurança, fraude e inteligência do século XXI continuam começando exatamente da mesma maneira:

IF isso estiver relacionado àquilo...

    o que mais deveria ser verdade?

Não execute a sentença.

Execute a investigação.

☕ Bellacosa Mainframe Security

Porque proteger o computador é importante.

Mas compreender o sistema que existe ao redor dele é muito mais interessante.

quinta-feira, 17 de setembro de 2026

🎩 O CHAPELEIRO MALUCO E O PAÍS DAS PORTAS DOS FUNDOS

 

☕ Um Café no Bellacosa Mainframe

🎩 O CHAPELEIRO MALUCO E O PAÍS DAS PORTAS DOS FUNDOS

RACF, Zero Trust, jatinhos, VIPs, compliance, conflitos de interesse, despesas de representação, audit trail, Red Team — e o dia em que Alice descobriu que o sistema estava perfeitamente protegido contra todo mundo, exceto contra quem tinha poder suficiente para pedir uma exceção.




🎬 PRÓLOGO — ALICE CAIU NO BURACO ERRADO

Alice já conhecia o País das Maravilhas.

Coelhos atrasados.

Gatos que desapareciam.

Rainhas temperamentais.

Cartas de baralho que falavam.

Nada daquilo a surpreendia mais.

Até que encontrou uma porta onde estava escrito:

SECURITY — AUTHORIZED PERSONNEL ONLY

Alice tentou entrar.

A porta não abriu.

Uma tela verde respondeu:

ICH408I USER ALICE
NOT AUTHORIZED TO RESOURCE

— Excelente! — disse Alice. — Finalmente encontrei um lugar organizado.

Então apareceu um homem importante.

Tentou entrar.

A porta também não abriu.

ICH408I USER VIP001
NOT AUTHORIZED TO RESOURCE

Alice sorriu.

— Pelo menos as regras são iguais.

O homem aproximou-se do funcionário responsável pela porta e perguntou:

— Você sabe com quem está falando?

O funcionário empalideceu.

Pegou o telefone.

Cinco minutos depois, a porta abriu.

Alice ficou olhando.

Nesse momento surgiu o Chapeleiro Maluco carregando uma xícara de café.

— Bem-vinda à segurança corporativa, Alice.

— Mas o sistema negou!

— Exatamente.

— Então como ele entrou?

O Chapeleiro tomou um gole.

— O computador disse não. O organograma disse sim.

Eram exatamente 03:17.



🐇 CAPÍTULO 1 — O QUE APRENDEMOS COM O COELHO BRANCO?

Nossa conversa começou com um caso contemporâneo envolvendo um banco, seu controlador, autoridades, familiares, contratos, viagens e relações sociais.

Mas rapidamente percebemos que o assunto era muito maior.

As investigações envolvendo o Banco Master revelaram publicamente uma extensa rede de relacionamentos envolvendo diferentes setores do poder brasileiro. Isso não significa que toda pessoa mencionada tenha cometido irregularidade; contatos, contratos, viagens ou relações profissionais precisam ser examinados individualmente e com devido processo.

O verdadeiro aprendizado não está em perguntar:

“Quem conhece quem?”

Está em perguntar:

“Nosso sistema institucional consegue identificar quando um relacionamento legítimo começa a produzir conflito de interesses?”

Essa pergunta serve para Brasília.

Serve para bancos.

Serve para empresas.

E serve perfeitamente para o mainframe.



🔐 CAPÍTULO 2 — RACF NÃO PROTEGE CONTRA ORGANOGRAMA

Imagine que você está começando como programador COBOL.

Seu programa processa pagamentos.

O dataset é:

PROD.PAYROLL.MASTER

Seu USERID possui apenas:

READ

Você tenta alterar.

RACF responde:

ICH408I
NOT AUTHORIZED

Excelente.

Agora imagine que o presidente da empresa tente fazer a mesma coisa.

Tecnicamente, deveria acontecer exatamente a mesma coisa.

O RACF não deveria pensar:

“Nossa! É o presidente!”

Para o sistema, existem:

identidade → autenticação → autorização.

Cargo não substitui nenhuma delas.

Esse conceito precisa sair do mainframe e entrar na governança das organizações.



🪪 CAPÍTULO 3 — IDENTIDADE NÃO É AUTORIZAÇÃO

Essa talvez tenha sido a principal descoberta de toda nossa conversa.

Existem três conceitos diferentes:

Identificação

Quem você afirma ser?

USERID = ALICE

Autenticação

Você consegue provar que realmente é Alice?

Senha.

MFA.

Certificado.

Biometria.

Passkey.

Autorização

Alice pode executar aquela operação?

PERMIT ALICE
       CLASS(DATASET)
       ACCESS(READ)

É perfeitamente possível possuir:

IDENTITY       = VALID
AUTHENTICATION = SUCCESS
AUTHORIZATION  = DENIED

E isso não representa erro.

Representa segurança funcionando.

O problema aparece quando acrescentamos uma quarta variável:

STATUS = VIP

E alguém decide que VIP significa:

ACCESS = ALTER

Não deveria.



🎩 CAPÍTULO 4 — “VOCÊ SABE COM QUEM ESTÁ FALANDO?”

O Chapeleiro colocou quatro xícaras sobre a mesa.

Na primeira escreveu:

Política.

Na segunda:

Procedimento.

Na terceira:

Tecnologia.

Na quarta:

Cultura.

— Qual delas controla a empresa? — perguntou Alice.

— Política?

— Errado.

— Tecnologia?

— Também.

O Chapeleiro apontou para a quarta.

Cultura.

Uma organização pode possuir a política:

Ninguém entra sem autorização.

Mas possuir simultaneamente a cultura:

Não crie problema para diretor.

Qual das duas vence?

Normalmente a segunda.

Isso cria aquilo que poderíamos chamar de:

Shadow Security Policy

A política invisível.

Ela nunca foi aprovada.

Não existe PDF.

Não existe versão.

Não existe owner.

Mas todo funcionário aprende.


🧨 CAPÍTULO 5 — O FUNCIONÁRIO QUE DISSE NÃO

Nossa conversa trouxe um exemplo perfeito.

Um diretor solicitou determinado acesso.

O responsável sabia exatamente quem ele era.

Mas não havia autorização adequada.

A resposta foi:

não.

Só que não terminou aí.

Foi solicitado um e-mail formal.

Enquanto isso, houve confirmação independente com a pessoa competente para autorizar.

Isso é excelente segurança.

O fluxo ficou:

REQUEST
   |
   v
IDENTITY CONFIRMED
   |
   v
AUTHORIZATION MISSING
   |
   v
ACCESS DENIED
   |
   v
EXCEPTION REQUEST
   |
   v
INDEPENDENT VALIDATION
   |
   v
DOCUMENTED APPROVAL
   |
   v
CONTROLLED ACCESS

Observe algo importante:

o funcionário não decidiu conceder privilégio.

Quem possuía autoridade assumiu formalmente a responsabilidade.

Isso é accountability.


😡 CAPÍTULO 6 — QUANDO O DIRETOR FICA OFENDIDO

Só que existe um problema.

O diretor pode interpretar:

controle = desconfiança

ou:

procedimento = humilhação

ou:

registro = burocracia.

Se depois retaliar quem aplicou corretamente o procedimento, algo extremamente perigoso acontece.

Os demais funcionários aprendem.

Não através de treinamento oficial.

Aprendem observando.

A próxima pessoa importante aparece.

O funcionário lembra:

“Da última vez alguém seguiu a política e se ferrou.”

Então libera.

Nesse momento a empresa possui uma vulnerabilidade que:

Nessus não encontra.

Qualys não encontra.

SIEM não encontra.

Penetration test tradicional talvez não encontre.

Porque a vulnerabilidade está na cultura de poder.


✈️ CAPÍTULO 7 — ALICE ENCONTRA UM JATINHO

Depois apareceu o avião executivo.

Aqui descobrimos outra coisa importante.

Privacidade não é necessariamente anonimato.

Aviação executiva possui controles e regulamentação próprios, diferentes em vários aspectos do fluxo comercial comum.

Mas para governança existe uma pergunta essencial:

Conseguimos reconstruir posteriormente quem utilizou determinado recurso, quem autorizou e quem pagou?

Isso vale para avião.

Vale para carro corporativo.

Vale para hotel.

Vale para cartão empresarial.

Vale para dataset.

Vale para transação CICS.

Vale para API.

O nome técnico disso é:

Audit Trail


📜 CAPÍTULO 8 — SMF PARA O MUNDO REAL

No z/OS temos algo maravilhoso:

SMF — System Management Facilities.

O sistema registra acontecimentos.

Jobs.

Logons.

Uso de recursos.

Segurança.

Performance.

Accounting.

Agora imagine aplicar mentalidade semelhante à governança.

Queremos responder:

WHO?
WHAT?
WHEN?
WHERE?
WHY?
WHO AUTHORIZED?
WHO PAID?
WHO BENEFITED?

Isso é praticamente um SMF institucional.

E existe uma lição extraordinária:

quanto maior o privilégio, maior deveria ser a auditabilidade.

Muitas organizações fazem exatamente o contrário.

Funcionário comum:

30 controles.

Diretor:

“Pode deixar passar.”

Deveria ser:

mais poder → mais accountability.


🍽️ CAPÍTULO 9 — O JANTAR QUE TALVEZ NÃO FOSSE JANTAR

Chegamos então às despesas de representação.

Hospitalidade empresarial existe.

Jantares existem.

Eventos existem.

Viagens existem.

Relacionamento comercial existe.

Nada disso é automaticamente irregular.

Mas descobrimos outra diferença fundamental:

DOCUMENT EXISTS

não significa:

DOCUMENT REPRESENTS REALITY

Um compliance superficial verifica:

✔ nota fiscal
✔ centro de custo
✔ aprovação
✔ fornecedor
✔ valor

E encerra.

Um Red Team pergunta:

A natureza econômica da operação corresponde ao documento?

Essa pergunta muda tudo.


🧾 CAPÍTULO 10 — COMPLIANCE NÃO É COLECIONAR PDFs

Imagine:

REALIDADE       = A
DOCUMENTO       = B
ERP             = B
CONTABILIDADE   = B
RELATÓRIO       = B
AUDITORIA       = B

Todos os sistemas concordam.

Todos podem estar errados.

Por quê?

Porque todos receberam a mesma informação inicial.

Programadores conhecem isso há décadas:

Garbage In, Garbage Out.

Compliance também sofre de GIGO.


⚖️ CAPÍTULO 11 — A TOGA NÃO É SUPERUSER

Chegamos então à magistratura.

Aqui precisamos abandonar personagens específicos e pensar institucionalmente.

O Código de Ética da Magistratura Nacional estabelece princípios como independência, imparcialidade, transparência e integridade. Determina também que o magistrado mantenha distância equivalente das partes e evite comportamento que possa refletir favoritismo.

Isso é praticamente Zero Trust jurídico.

Não significa:

“Desconfie de todo juiz.”

Significa:

Construa mecanismos que não dependam exclusivamente da confiança pessoal.

Aliás, o próprio STF anunciou em fevereiro de 2026 a elaboração de seu Código de Ética específico, mencionando explicitamente prevenção de conflitos de interesse, transparência, responsabilidade e confiança pública.

O CNJ também avançou em 2026 numa proposta específica para identificação, declaração e tratamento de conflitos de interesses, incluindo sistemas eletrônicos de prevenção e estruturas de aconselhamento ético.

Ou seja:

o problema estrutural está sendo reconhecido institucionalmente.


❤️ CAPÍTULO 12 — CONFIANÇA NÃO PODE SER A ÚNICA DEFESA

Alice perguntou:

— Então devemos desconfiar de todo mundo?

O Chapeleiro respondeu:

— Claro que não!

— Mas você acabou de falar de Zero Trust.

— Alice, Zero Trust não significa que todos são desonestos.

Significa que honestidade não substitui controle.

Essa distinção é maravilhosa.

Não colocamos senha porque acreditamos que todos são criminosos.

Não utilizamos RACF porque acreditamos que todos os programadores querem roubar dados.

Não fazemos backup porque esperamos que o storage exploda amanhã.

Controles existem porque sistemas resilientes não dependem de pessoas perfeitas.


🕵️ CAPÍTULO 13 — ENTRE O INTERESSE PÚBLICO E O NOTÍCIAS POPULARES

Nossa conversa passou também por intimidade.

Sexo.

Profissionais do sexo.

Festas.

Luxo.

E aí existe uma armadilha.

Esses elementos são excelentes para manchetes.

Mas podem distrair da verdadeira questão.

A pergunta relevante não deveria ser:

“Com quem determinada autoridade dormiu?”

A pergunta institucional é:

“Um terceiro interessado financiou um benefício privado?”

Se não financiou, a intimidade pode continuar sendo simplesmente intimidade.

Se financiou, aparecem perguntas sobre:

conflito de interesses → vantagem → independência → eventual contrapartida.

O sexo vira quase detalhe contábil.

O dinheiro torna-se interessante.


🔎 CAPÍTULO 14 — FOLLOW THE MONEY NÃO É SUFICIENTE

Todo mundo conhece:

Follow the money.

O Chapeleiro discorda.

— Incompleto!

Ele escreveu:

FOLLOW THE MONEY
FOLLOW THE ACCESS
FOLLOW THE RELATIONSHIP
FOLLOW THE DECISION
FOLLOW THE EXCEPTION

Esse é um modelo muito melhor.

Imagine:

EMPRESA
   |
   +-- pagamento
   |
INTERMEDIÁRIO
   |
   +-- benefício
   |
PESSOA COM PODER
   |
   +-- decisão
   |
RESULTADO

Uma seta isolada pode não significar absolutamente nada.

O grafo completo pode contar uma história.


🧠 CAPÍTULO 15 — O QUE AINDA NÃO DESCOBRIMOS?

Aqui precisamos ter disciplina.

Não podemos afirmar que existem fatos escondidos específicos sem evidência.

Mas podemos perguntar:

Que classes de risco ainda podem estar invisíveis?

Essa é exatamente a função de threat modeling.

Possibilidades genéricas:

relações indiretas não declaradas

beneficiários econômicos difíceis de identificar

presentes e hospitalidade

viagens

intermediários

consultorias

empresas relacionadas

familiares

fundos

associações

institutos

eventos privados

exceções não documentadas

aprovações verbais

conflitos de interesse não percebidos

O objetivo não é presumir culpa.

É construir controles capazes de detectar situações relevantes.


🔴 CAPÍTULO 16 — ENTRA O RED TEAM

Finalmente chegamos ao Red Team.

Muita gente pensa:

Red Team = hacker tentando invadir servidor.

É muito pouco.

Um Red Team maduro pergunta:

Como este sistema pode falhar?

E “sistema” pode significar organização.

Começamos criando adversários hipotéticos.

Cenário 1 — VIP

Uma pessoa poderosa pede exceção.

O funcionário cede?

Cenário 2 — relacionamento

Fornecedor possui amizade com decisor.

O conflito é declarado?

Cenário 3 — benefício

Terceiro oferece viagem ou hospitalidade.

Existe registro?

Cenário 4 — intermediário

O benefício não vem diretamente do interessado.

O sistema identifica relacionamento indireto?

Cenário 5 — pressão hierárquica

Funcionário bloqueia operação irregular.

Ele é protegido ou punido?

Aqui encontramos uma métrica extraordinária.


🛡️ CAPÍTULO 17 — O TESTE DO FUNCIONÁRIO PROTEGIDO

Quer saber se uma organização possui cultura de segurança?

Faça esta pergunta:

O que acontece com o funcionário que corretamente diz NÃO para alguém poderoso?

Se ele recebe apoio:

boa cultura.

Se recebe bronca:

alerta.

Se sofre retaliação:

vulnerabilidade crítica.

Porque segurança depende de pessoas terem permissão organizacional para aplicar segurança.


🧪 CAPÍTULO 18 — RED TEAM DE GOVERNANÇA

Agora montamos nosso exercício.

Sem tentar cometer crimes.

Sem violar privacidade.

Sem burlar controles reais.

Usamos simulações autorizadas.

Passo 1 — Mapear ativos

Dados.

Dinheiro.

Decisões.

Acessos.

Contratos.

Viagens.

Presentes.

Passo 2 — Mapear privilégios

Quem pode aprovar?

Quem pode dispensar?

Quem pode autorizar exceções?

Passo 3 — Mapear relacionamentos

Fornecedores.

Clientes.

Familiares.

Representantes.

Consultores.

Passo 4 — Procurar Shadow Policies

Pergunte aos funcionários:

“O que realmente acontece quando um diretor pede exceção?”

A resposta pode ser completamente diferente do manual.

Passo 5 — Simular pressão

Em ambiente autorizado, teste se procedimentos continuam funcionando quando o solicitante possui status elevado.

Passo 6 — Verificar audit trail

Conseguimos reconstruir tudo posteriormente?

Passo 7 — Corrigir.

Não apenas tecnologia.

Processo + cultura + proteção ao funcionário + transparência.


🔧 CAPÍTULO 19 — COMO MELHORAMOS O SISTEMA?

O Chapeleiro apresentou sua arquitetura.

1. Zero Trust também para VIP

Nenhum cargo concede privilégio implícito.

2. Exceção sempre registrada

Se precisa quebrar regra:

REQUEST
APPROVER
REASON
TIME
RESOURCE
EXPIRATION
AUDIT

3. Four Eyes Principle

Operações sensíveis exigem segunda aprovação independente.

4. Conflict-of-interest by design

Não espere o conflito aparecer.

Crie sistemas para declará-lo antecipadamente.

5. Beneficial ownership

Saiba quem realmente está atrás de empresas e estruturas relevantes quando a legislação permitir e exigir essa verificação.

6. Hospitalidade transparente

Presentes, viagens e benefícios relevantes precisam de regras claras.

7. Proteção contra retaliação

Funcionário que aplica corretamente o controle não pode ser punido por fazê-lo.

8. Auditoria baseada em substância

Não verifique apenas documentos.

Verifique realidade econômica.

9. Analytics

Procure padrões.

Valores.

Recorrência.

Relacionamentos.

Concentração.

Exceções.

10. Red Team periódico

Ataque processos.

Não pessoas.


🤖 CAPÍTULO 20 — IA PODE AJUDAR

Agora entra 2026.

Imagine milhares de:

contratos,

pagamentos,

agendas,

fornecedores,

declarações,

processos,

aprovações.

Humanos não conseguem correlacionar tudo.

IA e graph analytics podem ajudar a encontrar:

PESSOA A
   |
EMPRESA B
   |
FUNDO C
   |
CONSULTORIA D
   |
FAMILIAR E
   |
PROCESSO F

Isso não prova irregularidade.

Produz:

sinal para investigação humana.

Essa distinção é fundamental.

IA não deveria declarar:

CULPADO.

Deveria dizer:

ANOMALIA — INVESTIGAR.


🏛️ CAPÍTULO 21 — TRANSPARÊNCIA É OBSERVABILIDADE INSTITUCIONAL

Programadores conhecem observabilidade.

Metrics.

Logs.

Traces.

Agora aplique isso à governança.

Metrics: quantas exceções existem?

Logs: quem autorizou?

Traces: como o benefício percorreu a organização?

De repente:

OBSERVABILITY

vira:

TRANSPARENCY

O próprio CNJ criou o ONIT para fortalecer integridade, ética, governança e transparência e identificar riscos como corrupção, conflitos de interesse e captura institucional.

A analogia é perfeita:

instituição sem transparência é produção sem logs.

Tudo parece funcionar.

Até ocorrer incidente.


🎩 CAPÍTULO 22 — O ÚLTIMO CHÁ DO CHAPELEIRO

Alice estava cansada.

— Então nunca teremos um sistema perfeito?

O Chapeleiro riu.

— Claro que não!

— Então para que tudo isso?

Ele colocou uma última xícara sobre a mesa.

Nela estava escrito:

RESILIENCE.

Segurança não significa impedir absolutamente todo problema.

Significa:

dificultar → detectar → registrar → responder → aprender → melhorar.

É exatamente aquilo que fazemos no mainframe.


🐒 EPÍLOGO — OS CHIMPANZÉS VOLTARAM

Alice retornou à porta do início.

O homem importante apareceu novamente.

Tentou entrar.

ICH408I
ACCESS DENIED

Olhou para o funcionário.

— Você sabe com quem está falando?

O funcionário respondeu calmamente:

— Sei perfeitamente, senhor.

— Então abra.

— Sua identidade está confirmada. Sua autorização, não.

O homem pegou o telefone.

Nada aconteceu.

Tentou ligar para um diretor.

Nada.

Tentou chamar um amigo.

Nada.

Alice ficou surpresa.

— O que vocês fizeram?

O Chapeleiro apontou para uma placa nova:

EXCEPTION WORKFLOW

REQUEST
   ↓
INDEPENDENT APPROVAL
   ↓
JUSTIFICATION
   ↓
TIME-LIMITED ACCESS
   ↓
LOG
   ↓
REVIEW

Ao lado havia outra:

Nenhum funcionário será punido por aplicar corretamente um controle de segurança.

Alice sorriu.

Os chimpanzés começaram a bater palmas.

O Chapeleiro olhou para o relógio.

03:17.

— Conseguimos fechar todas as portas dos fundos?

Alice perguntou.

Ele colocou o chapéu.

— Não.

— Então fracassamos?

— Pelo contrário.

Pegou a xícara.

— Agora sabemos que devemos continuar procurando.

No terminal 3270 surgiu a última mensagem:

BELLACOSA MAINFRAME

SECURITY IS NOT
A PRODUCT.

SECURITY IS
A SYSTEM OF
PEOPLE,
PROCESSES,
TECHNOLOGY
AND ACCOUNTABILITY.

READY

E em letras menores:

ZERO TRUST:
SAME RULES.
ESPECIALLY FOR
SUPERUSERS.

☕🎩

Porque talvez a maior lição de todas seja esta:

Uma organização não demonstra que possui bons controles quando consegue dizer NÃO para quem não tem poder.

Ela demonstra quando consegue dizer NÃO para quem tem.

E um bom Red Team existe justamente para descobrir se esse NÃO continua funcionando quando chega o próximo Chapeleiro Maluco perguntando por que todo mundo está seguindo regras numa terra onde ele sempre acreditou que as regras eram para os outros.

quarta-feira, 16 de setembro de 2026

🐒 QUANDO UM MILHÃO DE CHIMPANZÉS ABRIRAM O BARRIL DE SAQUÊ PREMIUM

 

☕ Um Café no Bellacosa Mainframe

🐒 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

Encontramos uma vulnerabilidade.

CVE-HUMAN-0001 — Sabe-Com-Quem-Está-Falando Privilege Escalation.



🪪 CAPÍTULO 3 — IDENTIDADE NÃO É AUTORIZAÇÃO

Aqui está uma lição fundamental de segurança:

Identification ≠ Authentication ≠ Authorization.

Eu posso saber exatamente quem você é.

Você pode realmente ser presidente.

Diretor.

CEO.

Ministro.

General.

Administrador.

DBA.

Isso não significa automaticamente que você esteja autorizado a acessar determinado recurso.

No RACF isso é banal.

No mundo humano, surpreendentemente, não.

O verdadeiro Zero Trust deveria conseguir dizer:

“Sei perfeitamente quem é o senhor. Agora preciso verificar se o senhor possui autorização.”

É fácil implementar Zero Trust contra o estagiário.

Quero ver implementar contra o presidente.



✈️ CAPÍTULO 4 — O JATINHO EMPRESTADO

Então os chimpanzés encontraram um hangar.

E descobriram outra propriedade curiosa do poder.

O cidadão comum viaja assim:

documento → check-in → fila → segurança → raio-X → portão → embarque.

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

ICH408I.

Access denied.

Desta vez, para todos.

☕

terça-feira, 15 de setembro de 2026

🧟 Mainframe Evolution — O Pesadelo Open Source que Entrou na LPAR

 

Bellacosa Mainframe e o Mainframe Evolution

☕ Um Café no Bellacosa Mainframe

🧟 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!

Dylan provavelmente perguntaria:

— Por quê?

Essa é uma excelente pergunta.

Modernização não significa obrigatoriamente:

COBOL
  ↓
Java

Muito menos:

MAINFRAME
   ↓
CLOUD

Podemos modernizar ao redor da aplicação:

               Git
                │
VS Code ───► COBOL ◄─── CI/CD
                │
             Testing
                │
          Security Scan
                │
              APIs
                │
         Observability

O programa continua COBOL.

A lógica continua executando no z/OS.

CICS continua administrando transações.

Db2 continua guardando dados.

RACF continua controlando acessos.

Mas a maneira como desenvolvemos, testamos, implantamos, observamos e integramos essas aplicações pode mudar radicalmente.

Nosso monstro de Frankenstein não precisava ser destruído.

Precisávamos apenas entender como ele funcionava.



🔐 CAPÍTULO 3 — SECURING: alguém abriu novas portas no castelo

Dylan chegou à primeira cena do crime.

Uma enorme fortaleza.

Sobre o portão estava escrito:

RACF

Nada particularmente assustador.

O mainframe conhece controle de acesso há décadas.

Usuários possuem identidades.

Recursos possuem regras.

Datasets podem ser protegidos.

Transações CICS podem ser protegidas.

Recursos do sistema podem ser protegidos.

Aplicações podem ser protegidas.

Então apareceu o open source.

Depois vieram APIs.

CLI.

VS Code.

Git.

Jenkins.

Zowe.

Containers.

OpenShift.

Linux.

Cloud.

Service accounts.

Automação.

De repente, nosso castelo ganhou dezenas de portas.

                    IBM Z
                      │
     ┌────────────────┼────────────────┐
     │                │                │
    API              CLI             IDE
     │                │                │
 Jenkins            Zowe            VS Code
     │
   CI/CD

Nenhuma dessas tecnologias é inerentemente um problema.

O problema aparece quando adicionamos conectividade sem adicionar governança.



👻 CAPÍTULO 4 — O fantasma das credenciais

Groucho apareceu segurando um papel.

— Dylan, encontrei a senha.

— Onde?

— No script.

Isso é exatamente o tipo de fantasma que ninguém quer encontrar.

Imagine:

USER=DEPLOY01
PASSWORD=SUPERSECRET123

dentro de um script versionado.

Ou um token esquecido em um arquivo de configuração.

Ou uma service account com privilégios maiores que o necessário.

Automação multiplica produtividade.

Mas também pode multiplicar erros.

Um humano pode cometer um erro uma vez.

Um pipeline consegue cometer o mesmo erro automaticamente quinhentas vezes antes do café.

Por isso modernização exige pensar em:

Identity
Authentication
Authorization
Certificates
TLS
Secrets
Tokens
Audit
Least Privilege
API Security
Logging

O velho princípio continua válido:

Quem é você, o que você pode fazer e quem registrará que você fez?

RACF não ficou obsoleto porque apareceu DevOps.

Na verdade, DevOps torna essas perguntas ainda mais importantes.



🧪 CAPÍTULO 5 — Zowe entra na investigação

Dylan encontrou outra inscrição:

ZOWE

Aqui encontramos uma das pontes mais interessantes entre o mainframe tradicional e ferramentas modernas.

Imagine nosso jovem programador COBOL.

Ele conhece:

Git
VS Code
Terminal
REST
JSON
CLI

Então alguém apresenta:

TSO
ISPF
SDSF
JCL
3270

Nada disso é ruim.

Mas existe uma curva de aprendizagem.

Uma proposta importante do Zowe é permitir interfaces familiares ao desenvolvedor moderno para interação com o ecossistema z/OS.

Simplificando bastante:

VS Code ──────┐
              │
CLI ──────────┤
              │
REST ─────────┼──► Zowe ───► z/OS
              │
Scripts ──────┤
              │
Automation ───┘

Isso não significa abolir ISPF.

Nem significa transformar z/OS em Linux.

Significa criar novas maneiras de conversar com a plataforma.

Dylan anotou:

O suspeito não destruiu a porta antiga. Construiu outra entrada.


👁️ CAPÍTULO 6 — MONITORING: o mainframe sempre esteve olhando

Aqui nossa investigação fica especialmente interessante.

O mundo distribuído descobriu recentemente uma palavra maravilhosa:

observability.

Logs!

Metrics!

Traces!

Dashboards!

Alertas!

Dylan quase sorriu.

Porque no porão do mainframe encontrou arquivos muito mais antigos:

SMF
RMF
SYSLOG
OPERLOG
WLM
CICS Statistics
Db2 Accounting
IMS Logs
MQ Statistics

O mainframe sempre produziu uma quantidade extraordinária de informações operacionais.

Então qual é a novidade?

Correlação.


🔎 CAPÍTULO 7 — O cliente não sabe o que é uma LPAR

Imagine Maria pagando R$100 usando o celular.

Para ela:

CELULAR
  ↓
PAGAMENTO

Simples.

Agora acompanhemos o que pode acontecer por trás:

Mobile App
    ↓
Internet
    ↓
API Gateway
    ↓
OpenShift
    ↓
Java
    ↓
MQ
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
Db2

Maria liga:

— Meu pagamento demorou.

Ela não diz:

"Observei um aumento no response time da transaction class associada ao CICS."

Seria fantástico se dissesse.

Mas não diz.

Ela quer saber por que o botão demorou.

A empresa precisa investigar a transação inteira.

Esse é o grande salto entre simplesmente monitorar componentes e observar serviços distribuídos.


🔦 CAPÍTULO 8 — A lanterna chamada Trace ID

Dylan coloca uma etiqueta na vítima:

TRACE-ID: BELLACOSA-0317

Agora imagine essa identificação acompanhando a solicitação:

APP
 │
 │ 0317
 ▼
API
 │
 │ 0317
 ▼
OPENSHIFT
 │
 │ 0317
 ▼
MQ
 │
 │ 0317
 ▼
CICS
 │
 │ 0317
 ▼
COBOL
 │
 │ 0317
 ▼
DB2

Agora temos uma investigação de verdade.

Podemos descobrir:

APP            120 ms
API             80 ms
OPENSHIFT       90 ms
MQ              40 ms
CICS            70 ms
COBOL           20 ms
DB2           3.900 ms

A aplicação demorou aproximadamente 4,3 segundos.

E finalmente encontramos o suspeito.

Não era COBOL.

Era uma consulta no banco.

O pobre COBOL estava sendo acusado porque morava no bairro errado.


🩸 CAPÍTULO 9 — OpenTelemetry encontra SMF

Aqui existe uma possibilidade particularmente fascinante.

De um lado temos o universo tradicional:

SMF
RMF
WLM
CICS
Db2
IMS
MQ

Do outro:

OpenTelemetry
Prometheus
Grafana
Elastic
OpenSearch
Jaeger

Historicamente eles podem parecer dois mundos.

Mas uma aplicação empresarial moderna pode atravessar ambos.

Portanto, o verdadeiro objetivo passa a ser:

             BUSINESS TRANSACTION
                     │
       ┌─────────────┴─────────────┐
       │                           │
 DISTRIBUTED WORLD             MAINFRAME
       │                           │
 OpenTelemetry                   SMF
 Prometheus                      RMF
 Containers                      WLM
 Kubernetes                      CICS
 APIs                            Db2
       │                           │
       └─────────────┬─────────────┘
                     │
               OBSERVABILITY

Agora podemos começar a responder não apenas:

"A CPU está boa?"

Mas:

"Por que o cliente não conseguiu concluir a compra?"

Essa segunda pergunta vale dinheiro.


📈 CAPÍTULO 10 — SCALING: o monstro começou a crescer

Nosso terceiro mistério é escala.

Alguém poderia dizer:

— Finalmente Kubernetes ensinará mainframe a escalar!

Nesse momento talvez Dylan pedisse para Groucho retirar a pessoa da sala.

Mainframes foram construídos justamente para executar workloads enormes.

z/OS possui uma longa história de administração sofisticada de workloads.

Temos conceitos como:

LPAR
WLM
Parallel Sysplex
Coupling Facility
Capacity
Workload Management

O que mudou foi o ambiente ao redor.

Imagine:

               INTERNET
                   │
             LOAD BALANCER
                   │
          ┌────────┼────────┐
          │        │        │
         POD      POD      POD
          │        │        │
          └────────┼────────┘
                   │
                  MQ
                   │
                CICS
                   │
                COBOL
                   │
                 DB2

Kubernetes pode aumentar pods.

Ótimo.

Mas isso não significa capacidade infinita.


☠️ CAPÍTULO 11 — O horror do autoscaling cego

Aqui mora um monstro interessante.

Suponhamos:

3 PODS

O sistema detecta carga elevada.

Então:

3 → 6 → 12 → 24 → 48 PODS

Fantástico!

Exceto que todos atacam o mesmo backend.

48 PODS
   │
   │
   ▼
   MQ
   │
   ▼
  CICS
   │
   ▼
  DB2

Escalar frontend sem compreender backend pode simplesmente produzir um ataque DDoS patrocinado pela própria empresa.

Essa é uma das grandes lições de arquitetura híbrida.

Precisamos compreender:

  • throughput;

  • concorrência;

  • filas;

  • limites;

  • CPU;

  • I/O;

  • locks;

  • conexões;

  • response time;

  • prioridades;

  • capacidade do backend.

Escalabilidade não significa "crie mais coisas".

Significa administrar capacidade do sistema completo.


🐧 CAPÍTULO 12 — Há um pinguim no porão

Dylan ouviu um barulho.

Desceu mais um andar.

Encontrou Linux.

Sim, Linux no mainframe.

Essa confusão ainda existe:

MAINFRAME = z/OS

Não exatamente.

IBM Z pode hospedar diferentes ambientes e workloads.

Podemos pensar conceitualmente em:

IBM Z
 │
 ├── z/OS
 │    ├── COBOL
 │    ├── CICS
 │    ├── IMS
 │    └── Db2
 │
 ├── Linux on Z
 │    ├── Java
 │    ├── Python
 │    └── Open Source
 │
 └── Virtualização
      ├── z/VM
      └── outros ambientes suportados

Isso muda completamente a imagem mental de "computador antigo".

O hardware permanece centralizado e extremamente robusto.

O ecossistema de software, entretanto, tornou-se bastante heterogêneo.


🔧 CAPÍTULO 13 — DevOps encontra COBOL

Nosso programador iniciante agora recebe uma missão.

Modificar:

CUSTOMER.cbl

No fluxo tradicional poderia acontecer:

ISPF
 ↓
EDIT
 ↓
JCL
 ↓
COMPILE
 ↓
LINK
 ↓
TEST

Esse fluxo continua perfeitamente válido em muitos ambientes.

Mas podemos criar:

VS Code
   ↓
Git
   ↓
Commit
   ↓
Pull Request
   ↓
Automated Build
   ↓
Unit Test
   ↓
Security Scan
   ↓
Deploy
   ↓
Monitoring

Observe o detalhe.

Em nenhum momento fomos obrigados a escrever:

rm CUSTOMER.cbl

O COBOL continua lá.

Mudamos o software delivery lifecycle.

Essa diferença é fundamental.


🧠 CAPÍTULO 14 — O erro clássico: confundir modernização com linguagem

Dylan encontra finalmente uma testemunha.

— Eu vi tudo! Modernizaram o sistema!

— Como?

— Converteram COBOL para Java!

Dylan fecha o bloco de notas.

Isso pode ser modernização.

Mas não é a definição de modernização.

Um programa COBOL pode estar integrado a:

Git
CI/CD
Automated Tests
APIs
Modern IDE
Observability
Security Automation
AI Assistance

Enquanto um programa Java pode viver em:

FTP
manual deployment
no tests
hardcoded passwords
no monitoring
no documentation

Qual dos dois é realmente "legado"?

A linguagem não responde sozinha.

Processo, arquitetura, governança e manutenibilidade importam enormemente.


🕸️ CAPÍTULO 15 — O verdadeiro monstro é a complexidade

Depois de horas investigando, Dylan percebe algo.

Não existe apenas um assassino.

Existe uma teia.

                    USER
                      │
                     APP
                      │
                     API
                      │
                  KUBERNETES
                      │
                      MQ
                      │
               z/OS CONNECT
                      │
                    CICS
                      │
                    COBOL
                      │
                     DB2

Cada camada possui:

Security
Monitoring
Configuration
Capacity
Networking
Logging
Authentication
Authorization
Versioning
Dependencies

É aqui que open source pode ajudar muito.

Mas também é onde ele pode criar problemas se for adotado simplesmente porque "todo mundo usa".

Open source não elimina complexidade.

Às vezes ele democratiza ferramentas para administrá-la.

E às vezes adiciona outra camada.

Arquitetura continua exigindo engenharia.


🧰 CAPÍTULO 16 — O arsenal do Investigador do Pesadelo

Se Dylan Dog fosse engenheiro de plataforma IBM Z, sua mala talvez tivesse:

┌─────────────────────────────┐
│ DYLAN DOG TOOLBOX           │
├─────────────────────────────┤
│ RACF       → Security       │
│ SMF        → Evidence       │
│ RMF        → Performance    │
│ WLM        → Workloads      │
│ SDSF       → Operations     │
│ Zowe       → Integration    │
│ Git        → Versioning     │
│ CI/CD      → Automation     │
│ OTel       → Tracing        │
│ Grafana    → Visualization  │
│ Linux      → Open ecosystem │
└─────────────────────────────┘

Mas ferramentas não resolvem crimes sozinhas.

Precisamos saber que pergunta fazer.


🎓 CAPÍTULO 17 — O novo programador mainframe

Talvez esta seja a maior transformação.

Durante décadas uma trilha de formação poderia começar assim:

3270
 ↓
TSO
 ↓
ISPF
 ↓
JCL
 ↓
COBOL
 ↓
VSAM
 ↓
CICS
 ↓
DB2

Eu ainda ensinaria essa base.

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.


🧟 CAPÍTULO 18 — E a inteligência artificial?

Naturalmente nosso monstro mais recente aparece.

IA pode ajudar a:

explicar COBOL
gerar documentação
analisar dependências
sugerir testes
interpretar mensagens
auxiliar debugging
explicar JCL
produzir scripts
examinar código legado

Fantástico.

Mas existe uma regra Dylan Dog para isso:

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.



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