☕ 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.
Sem comentários:
Enviar um comentário