☕ Um Café no Bellacosa Mainframe
Com Johnny Mnemonic no papel de mensageiro, Martin Bishop cuidando da porta dos fundos, e Igor tentando descobrir se “watchdog” é um cachorro que late para o JES2
Johnny Mnemonic e o Zoológico da Segurança da Informação — Quando 320 GB na Cabeça Pareciam Ficção e o Verdadeiro Perigo Já Estava Dentro da Rede
Ou: Johnny carregava dados demais, a Yakuza queria extraí-los, a Pharmakom queria enterrá-los, Jones era um golfinho hacker, e o programador COBOL descobriu que honeypot, canary token, logic bomb e dead man’s switch não são nomes de banda cyberpunk
Há filmes que envelhecem como leite esquecido no sol. Há outros que envelhecem como um log de segurança: ficam estranhos, incompletos, meio granulados, mas de repente ganham uma segunda vida porque o mundo decidiu correr atrás deles.
Johnny Mnemonic, de 1995, pertence à segunda categoria.
Assistir hoje à história de Johnny, o mensageiro de dados interpretado por Keanu Reeves, é observar uma visão de futuro que acertou e errou com a mesma elegância caótica de Igor configurando um RACF em produção sem pedir janela de mudança. O filme imaginava um mundo de congestionamento digital, corporações farmacêuticas com poder de Estado, redes clandestinas, implantes cerebrais, dados valendo mais que dinheiro e pessoas sendo perseguidas porque carregavam informação inconveniente.
Bom, colegas: alguém olhou pela janela da década de 2020?
Hoje não precisamos instalar 320 GB no cérebro — e talvez seja melhor assim, porque Johnny passou o filme inteiro com a cabeça parecendo uma LPAR em 99% de CPU. Mas carregamos no celular uma vida inteira: credenciais, banco, saúde, conversas, fotos, localização, tokens de autenticação e, com alguma sorte, uma foto da senha do Wi-Fi escrita num papel. A diferença entre a ficção cyberpunk e a vida corporativa moderna é que no filme os criminosos usam roupa de couro e fios fluorescentes; na empresa real, às vezes usam uma conta de fornecedor, uma VPN esquecida e uma planilha chamada LISTA-ATUALIZADA-FINAL-v7.xlsx.
Este café é para o programador COBOL iniciante que está começando a perceber que segurança não é apenas “colocar senha no TSO”, nem instalar antivírus no desktop da recepção. Segurança é entender quem pode fazer o quê, por qual caminho, em qual momento, com qual prova, e o que acontece quando alguém decide que a regra do sistema é apenas uma sugestão educada.
E, já que o universo técnico gosta de batizar ameaças com nomes de bichos, minas, bombas, fantasmas e portas secretas, vamos visitar esse zoológico.
Prólogo — Johnny não era hacker: era um pendrive humano
No filme, Johnny Mnemonic é um data courier: um contrabandista de informação. Para evitar que arquivos confidenciais sejam encontrados em dispositivos convencionais, ele os transporta numa memória implantada no próprio cérebro.
A ideia parece extravagante, mas o princípio é extremamente atual: dados sensíveis precisam ser protegidos durante o armazenamento, o processamento e o transporte.
Em linguagem de mainframe, imagine que uma empresa precisa enviar uma base sigilosa entre dois ambientes. Não basta dizer “o dataset está protegido”. É preciso perguntar:
Quem leu o dado antes da transferência?
O arquivo foi criptografado?
Quem possui a chave?
A rede entre origem e destino é confiável?
Há logs?
O destinatário é realmente quem diz ser?
O dado será apagado da área temporária?
Se o job falhar, onde ficaram os restos?
Johnny falha em quase todas as perguntas. Ele transporta o conteúdo, mas não controla adequadamente a capacidade, o contexto, a integridade nem o destino final. É o equivalente cyberpunk de subir um arquivo crítico para uma área temporária, deixar permissão ampla, enviar a senha pelo mesmo e-mail e escrever no rodapé: “favor não compartilhar”.
A primeira lição é simples e brutal:
Dado sensível não deixa de ser sensível porque está viajando.
No mundo COBOL, isso vale para arquivos de folha de pagamento, saldos, CPF, cartões, dados médicos, apólices, cadastros, chaves de transferência e relatórios de auditoria. O seu programa pode estar perfeito, o PERFORM VARYING pode estar elegante, o compilador pode não apontar um único erro — e ainda assim o sistema pode vazar uma fortuna porque alguém gravou um arquivo temporário em local inadequado.
1. Watchdog — o cachorro que não protege o castelo, mas avisa que o vigia dormiu
O watchdog é um mecanismo de supervisão. Ele observa se um processo, serviço, dispositivo ou sistema continua funcionando como deveria. Se o processo para de responder, trava ou deixa de enviar um sinal periódico, o watchdog pode alertar, reiniciar o componente ou colocar o ambiente em estado seguro.
Pense num vigia noturno do castelo Bellacosa. Ele não precisa saber escrever COBOL; basta aparecer no corredor a cada quinze minutos, bater o cajado no chão e dizer: “ainda estou vivo”. Se ninguém o ouve por tempo demais, algo está errado.
No mainframe, uma analogia útil é o controle operacional de jobs, started tasks, CICS regions, serviços TCP/IP, agentes de monitoramento e componentes de middleware. Um monitor detecta que algo parou, que uma fila cresceu além do esperado ou que uma transação deixou de responder.
Mas aqui existe uma pegadinha importante: watchdog não é segurança completa.
Ele pode identificar indisponibilidade. Pode ajudar a reduzir o tempo de recuperação. Pode reiniciar um processo tombado. Porém, se o processo continua respondendo enquanto rouba dados, responde com toda a educação do mundo enquanto executa uma fraude, ou foi comprometido por uma conta privilegiada, o cachorro pode estar vendo o ladrão passar com crachá e marmita.
Por isso, disponibilidade não é o mesmo que segurança.
Um serviço pode estar “verde” no painel e, ainda assim, estar vazando clientes em silencioso processamento em lote.
2. Honeypot e honeytoken — o pote de mel e o biscoito que ninguém deveria tocar
Um honeypot, literalmente “pote de mel”, é uma isca. Pode ser um servidor falso, uma conta que não deveria ser usada, uma API deliberadamente exposta para observação ou uma máquina que parece valiosa, mas foi criada para atrair e estudar atividade maliciosa.
No universo de Johnny Mnemonic, seria aquela sala cheia de servidores luminosos que parecem guardar o segredo da cura, mas na realidade existem para identificar quem entrou, como entrou e o que tentou fazer.
Já um honeytoken é uma isca menor: uma credencial falsa, um documento com um link rastreável, uma chave de API sem uso legítimo, uma conta administrativa criada apenas para disparar alerta se alguém tentar utilizá-la.
Exemplo prático: você cria uma conta chamada DB2-PROD-EMERGENCY, documenta internamente que ela não deve ser usada e monitora qualquer tentativa de login. Se essa conta aparece num log às 02h43, não é um “evento para analisar na reunião da outra semana”. É sirene, café forte e investigação.
O canary token é um tipo de honeytoken com nome particularmente bonito. A referência vem dos canários usados em minas de carvão. Se o canário adoecia ou morria, era sinal de gases perigosos antes que os mineiros percebessem.
Na segurança moderna, o canário não precisa morrer — felizmente a área de compliance agradece. Ele apenas “canta”: alguém abriu um documento-isca, tentou usar uma senha falsa, acessou uma URL exclusiva ou copiou um arquivo que não deveria sequer chamar atenção.
Para o programador iniciante, a lição é maravilhosa: não espere o invasor chegar ao cofre. Coloque sensores discretos no caminho até ele.
Mas cuidado: honeypot não substitui controle de acesso. Uma casa cheia de câmeras continua precisando trancar a porta. A isca serve para detectar e aprender; não é autorização para deixar produção aberta como bar de estrada.
3. Dead man’s switch e kill switch — dois botões para dois tipos de desastre
O dead man’s switch, ou “interruptor do homem morto”, funciona por ausência de sinal. Se uma pessoa ou processo deixa de confirmar que está ativo, alguma ação automática é disparada.
Nos trens, historicamente, há mecanismos assim: se o operador solta um controle ou deixa de agir por determinado tempo, o sistema entende que ele pode estar incapacitado e aciona o freio.
Em segurança, o conceito aparece em chaves que exigem renovação periódica, sessões que expiram, controles de continuidade e processos que entram em modo seguro caso não recebam confirmação.
Imagine uma integração de pagamentos. Enquanto o sistema recebe confirmações válidas do componente de autorização, opera normalmente. Se a comunicação falha, em vez de aprovar transações às cegas, entra em contingência ou bloqueia certas operações. Isso é mais inteligente do que dizer: “bom, não temos resposta, então vamos torcer”.
O kill switch, por sua vez, é mais direto: é o mecanismo para interromper algo deliberadamente. Revogar uma chave vazada, desabilitar uma conta, desligar uma integração, suspender uma API, conter uma máquina comprometida ou bloquear uma função crítica.
O botão vermelho do laboratório.
A confusão comum é pensar que kill switch é sinal de fracasso. Não. Um kill switch bem projetado é maturidade operacional. O fracasso é descobrir no meio de um incidente que ninguém sabe desligar o componente comprometido sem derrubar o banco inteiro, o CICS, o café e talvez a cidade de Itatiba.
Em COBOL e mainframe, pense em controles claros para interromper processamento sensível: flags de aplicação, perfis RACF, parâmetros externos, segregação de funções e procedimentos documentados. Não enterre um “desliga tudo” misterioso em uma IF obscura na Procedure Division. O mecanismo precisa ser protegido, auditável, testado e acessível à equipe certa.
4. Logic bomb e time bomb — quando o código parece normal até decidir virar vilão
Uma logic bomb é um trecho de código que permanece dormente até que uma condição seja satisfeita. Pode ser uma data, uma conta específica, uma demissão, a ausência de um arquivo ou determinado valor de negócio.
Uma time bomb é a variante ativada pelo tempo: “no dia X, faça Y”.
Isso parece coisa de filme? Claro. Também parece coisa de casos reais de sabotagem interna: um funcionário insatisfeito deixa uma rotina que apaga, altera ou bloqueia algo quando determinada condição acontece.
Para quem programa COBOL, a lição é menos “caçar vilões usando sobretudo” e mais “tratar regras escondidas como risco”.
Uma condição de negócio legítima deve responder a perguntas simples:
Por que ela existe?
Quem a aprovou?
Onde foi documentada?
Como ela é testada?
Quem revisou a alteração?
Que evidência fica quando ela é acionada?
Se existe código como:
IF WS-DATA-PROCESSAMENTO = '31/12/2026'
PERFORM ROTINA-ESPECIAL
END-IF
isso não é automaticamente uma bomba. Pode ser fechamento anual. Mas “ROTINA-ESPECIAL” não pode ser um porão escuro que ninguém compreende. Código crítico precisa de revisão, rastreabilidade, testes e separação entre quem escreve, quem aprova e quem implanta.
O inimigo não é apenas o malware. Pode ser uma regra de negócio que ninguém mais lembra por que foi criada.
5. Backdoor, trapdoor e a porta que Igor jurou ser “só para manutenção”
Backdoor é uma porta dos fundos: um meio oculto de acessar um sistema, normalmente contornando o processo esperado de autenticação ou autorização. Trapdoor é um nome mais antigo e quase sinônimo.
Nem toda porta alternativa nasce com intenção maliciosa. Desenvolvedores às vezes deixam um acesso de manutenção. Equipes criam usuários de emergência. Fornecedores pedem uma conta técnica. Em uma madrugada de crise, alguém cria um bypass “provisório”.
A palavra mais perigosa da tecnologia é “provisório”. Ela costuma sobreviver mais que o sistema que a originou.
No mundo z/OS, isso conversa diretamente com privilégios excessivos, IDs compartilhados, acessos UID(0), perfis genéricos amplos, contas de serviço sem dono claro e permissões concedidas “até segunda-feira” que continuam funcionando no Carnaval de três anos depois.
O princípio é o do menor privilégio: cada identidade deve ter apenas o acesso necessário, pelo tempo necessário, com uma finalidade conhecida.
Autenticar é provar quem você é. Autorizar é decidir o que pode fazer.
RACF não lê pensamentos. Um usuário pode autenticar perfeitamente e ainda não deveria ter acesso ao dataset, transação CICS, tabela Db2, recurso USS ou ambiente de produção solicitado.
Johnny tinha a informação. A Yakuza queria a informação. Pharmakom queria silenciá-la. Em todos os casos, o problema não era apenas “quem sabe a senha”; era quem possui o direito, a capacidade e a oportunidade de acessar o ativo.
6. Zombies, botnets e o perigo da máquina aparentemente normal
Um zombie é uma máquina comprometida e controlada remotamente. Uma botnet é a coleção dessas máquinas-zumbi, usada para ataques distribuídos, spam, fraude, mineração ilegal ou negação de serviço.
A imagem clássica é de milhares de computadores domésticos infectados. Mas o conceito é mais amplo: qualquer dispositivo administrado por quem não deveria administrá-lo pode virar soldado involuntário. Câmeras, roteadores, servidores, notebooks e máquinas virtuais podem entrar no exército.
A parte mais assustadora não é o zumbi gritando. É ele parecer perfeitamente normal.
Ele pode continuar processando, responder ao monitoramento, ter CPU razoável e até gerar logs aparentemente inocentes. A detecção depende de contexto: conexões estranhas, volume incomum de saída, comandos inesperados, acessos fora de horário, tentativas de privilégios e comportamento divergente da linha de base.
Em outras palavras: não procure apenas por monstro. Procure pelo funcionário que entrou no prédio, bateu ponto, tomou café, fez tudo certo — e carregou o cofre no bolso.
7. Phishing, baiting e engenharia social — o ataque que começa antes do teclado
Johnny Mnemonic vende uma estética de ataques ultratecnológicos, mas a segurança real muitas vezes cai pela arma mais velha do mundo: convencer alguém.
Phishing é a tentativa de roubar informações por mensagens falsas. Spear phishing é direcionado a uma pessoa ou equipe específica. Whaling mira executivos e pessoas com alto poder de aprovação. Smishing chega por SMS. Vishing vem por voz, geralmente com alguém fingindo ser banco, TI, fornecedor ou auditor.
Baiting é a isca: pendrive largado, arquivo “confidencial”, link para uma promoção, currículo ou relatório urgente. O invasor explora curiosidade, pressa, medo e hierarquia.
Você não precisa ensinar exploração técnica para entender o perigo. Basta imaginar esta mensagem:
“Olá, Vagner. Detectamos inconsistência em seu acesso corporativo. Abra o relatório e valide hoje para evitar bloqueio.”
Ela pode vir com logo bonito, português quase perfeito e urgência fabricada. Se a pessoa clica, entrega credenciais ou executa arquivo, o invasor não precisou derrubar firewall nenhum. Apenas pediu acesso com educação.
A resposta não é transformar todos em paranoicos incapazes de abrir e-mail. É criar hábitos:
Desconfie de urgência fora do padrão.
Verifique remetente e domínio real.
Não valide pedido sensível pelo mesmo canal que o recebeu.
Confirme com a pessoa ou área por contato conhecido.
Reporte, em vez de apenas apagar, quando houver suspeita.
Não use medo de parecer “chato” como critério de segurança.
O inimigo adora funcionários educados demais.
8. Man-in-the-Middle, Evil Twin e watering hole — o caminho também é parte do ataque
Um Man-in-the-Middle, ou MitM, é o atacante posicionado entre duas partes que acreditam conversar diretamente. Ele pode observar, modificar ou redirecionar a comunicação.
Um evil twin é uma rede Wi-Fi falsa que imita uma legítima: “Café_Bellacosa_Guest” versus “Cafe_Bellacosa_Guest”. O sujeito conecta na errada, aceita uma tela de login maliciosa e entrega credenciais como quem pede um cappuccino.
O watering hole, “poço d’água”, é uma estratégia em que criminosos comprometem um site frequentado pelo alvo. Em vez de caçar cada zebra, contaminam a fonte onde todas vão beber.
A lição é que segurança não mora apenas no servidor. Ela mora no trajeto, no certificado, na rede, no DNS, no navegador, no fornecedor, no dispositivo e na decisão de clicar.
Para aplicações corporativas, use conexões protegidas, valide certificados, evite segredos em texto claro, controle integrações e trate redes públicas como ambientes hostis. O Wi-Fi do aeroporto não é uma extensão espiritual do seu datacenter.
9. Zero Trust, crown jewels e blast radius — proteger tudo é bonito; proteger o essencial é sobrevivência
Zero Trust não significa “não confie em ninguém porque todos são vilões de filme noir”. Significa não conceder confiança automática apenas porque alguém está dentro da rede, usa um dispositivo corporativo ou tem um crachá antigo.
Cada acesso deve ser verificado de acordo com identidade, contexto, privilégio, dispositivo, risco e finalidade.
Os crown jewels, as “joias da coroa”, são os ativos mais importantes: dados de clientes, chaves criptográficas, contas privilegiadas, código-fonte, dados de pagamento, segredos industriais e sistemas que sustentam a operação.
Em um banco, talvez seja a autorização de transações. Em um hospital, prontuários e sistemas clínicos. Em uma empresa de varejo, pagamentos e dados pessoais. Em um ambiente mainframe, pode ser uma combinação de datasets críticos, bancos Db2, regiões CICS, IDs especiais e chaves que destrancam o castelo inteiro.
O blast radius é o raio da explosão: até onde o dano se espalha se uma conta, servidor ou integração for comprometida.
Se um único usuário pode ler toda a base de clientes, alterar tabelas de produção, submeter JCL, administrar segurança e copiar dados para fora, seu blast radius é do tamanho da galáxia de Johnny Mnemonic.
Segmente ambientes. Separe desenvolvimento, homologação e produção. Separe funções. Evite contas compartilhadas. Reduza privilégios. Registre ações importantes. Teste a recuperação.
É menos glamouroso que um golfinho cibernético, mas infinitamente mais útil.
10. O último recado de Johnny: dados são poder, e logs são memória
No fundo, Johnny Mnemonic não é só sobre tecnologia. É sobre informação concentrada, corporações decidindo o que o público pode saber e pessoas comuns pagando o preço de sistemas opacos.
Na segurança corporativa, isso se traduz em responsabilidade.
Um log não é apenas uma linha chata em arquivo. É a memória operacional do que aconteceu: quem acessou, o que tentou fazer, quando fez, de onde veio, se teve sucesso e que recurso foi tocado. Sem logs suficientes, uma investigação vira aquela reunião em que vinte pessoas dizem “não fui eu” enquanto Igor tenta achar evidência num print cortado do Teams.
Mas log sem contexto é apenas entulho digital. Segurança madura correlaciona eventos: um login estranho, uma escalada de privilégio, uma cópia de dados, uma conexão externa, uma alteração de regra e uma conta até então silenciosa. É quando o log vira narrativa.
Johnny carregava uma verdade que muita gente poderosa preferia apagar. No seu ambiente, a verdade pode estar no SMF, nos logs do RACF, no audit trail do Db2, no SIEM, no registro da aplicação ou na trilha de uma mudança de produção.
A pergunta é: você conseguirá encontrá-la antes do próximo ABEND?
Epílogo — o programador COBOL também é parte da muralha
Não existe “o pessoal de segurança” de um lado e “quem escreve programa” do outro. Toda linha que lê, grava, valida, transmite, mascara ou retém dados faz parte do desenho de segurança.
Você não precisa virar Johnny Mnemonic. Nem Martin Bishop. Nem um golfinho hacker chamado Jones.
Comece com o básico, que já é poderoso:
Saiba quais dados seu programa manipula.
Evite expor informações em telas, arquivos temporários e logs.
Valide entradas e regras de negócio.
Nunca trate acesso privilegiado como conveniência.
Documente exceções.
Peça revisão para mudanças sensíveis.
Desconfie de “usuário técnico sem dono”.
Entenda que disponibilidade, autenticação e autorização são coisas diferentes.
Aprenda a ler evidências de auditoria.
Pergunte sempre: “se isso der errado, até onde o estrago vai?”
A segurança da informação tem nomes curiosos porque ela nasceu tentando explicar perigos invisíveis: cães de guarda, canários, potes de mel, bombas lógicas, homens mortos, zumbis e portas secretas.
Mas, por trás de todos eles, existe a mesma verdade pouco cinematográfica: sistemas falham quando pessoas, processos e tecnologia deixam uma lacuna entre o que deveria acontecer e o que alguém consegue fazer.
E é justamente nessa lacuna que Johnny Mnemonic passa correndo, com 320 GB na cabeça, uma corporação atrás dele e Igor gritando do laboratório:
“Doutor! O canário cantou, o watchdog latiu e alguém deixou a conta ADMINISTRADOR aberta!”
Nesse momento, meu caro programador COBOL iniciante, você não precisa entrar em pânico.
Só precisa saber onde está a porta, quem tem a chave, o que há atrás dela — e onde fica o botão vermelho.
