 |
| Bellacosa Maifnrame do cobol ao hacker etico |
☕ Um Café no Bellacosa Mainframe
Sob o olhar atento de Martin Bishop e sua equipe — que prometeram não deixar Whistler sozinho perto do terminal, nem Carl aprender COBOL só para descobrir que o relatório de auditoria pode terminar com um ABEND
Do IDENTIFICATION DIVISION ao Hacker Ético — O Dia em que Martin Bishop Auditou o Mainframe e Descobriu que RACF Não Lê Pensamentos
Ou: o programador COBOL achava que segurança era uma senha de oito caracteres, até Martin Bishop apontar para a porta do datacenter e perguntar quem havia autorizado Igor a entrar com um crachá de visitante, uma chave de fenda e acesso em produção
Existe um infográfico circulando por aí com uma promessa irresistível: “From Beginner to Ethical Hacker”. Ele desenha dez caixas coloridas, põe Linux, redes, Python, ferramentas, cloud, certificações e uma figura encapuzada numa mistura que parece o catálogo da loja de magia do Diagon Alley para gente que usa terminal.
Não é um mapa ruim. Pelo contrário: é melhor do que a maioria, porque começa por fundamentos antes de chegar às ferramentas. Mas ele fica muito mais interessante quando traduzido para quem escreve COBOL, entende job, JCL, CICS, Db2, RACF e já descobriu que a palavra produção altera até o tom de voz de uma sala inteira.
É aí que Martin Bishop, de Sneakers (1992), senta no balcão do Bellacosa Mainframe. Ao seu lado estão Donald Crease, capaz de lembrar que toda arquitetura tem uma fraqueza humana; Darren “Mother” Roskow, que conhece as engrenagens; Carl Arbogast, o homem que entraria em pânico antes de entrar em um prédio; e Whistler, que escuta o que os sistemas deixam escapar. Eles não são modelo técnico perfeito de 2026 — afinal, o filme tem o charme de quando uma caixa preta podia parecer uma ameaça geopolítica —, mas oferecem a metáfora certa: segurança é observar sistemas, pessoas, regras e sinais antes de apertar qualquer botão.
E a primeira regra do clube é simples: hacker ético não é um invasor com bom coração. É alguém autorizado a testar, encontrar evidências, medir risco e ajudar a consertar. Sem autorização explícita, escopo definido e ambiente permitido, o “teste de segurança” pode ser apenas uma tentativa de invasão com vocabulário melhor.
Prólogo — Martin Bishop olha o organograma, não apenas o firewall
No começo de Sneakers, a equipe não sai quebrando fechaduras. Ela observa horários, hábitos, pessoas, telefones, rotinas e dependências. O filme exagera, claro, mas a intuição é correta: o caminho até um ativo valioso raramente é uma porta frontal escancarada. Muitas vezes é uma conta esquecida, uma exceção aprovada às pressas, uma integração antiga ou alguém que recebeu privilégio “só até terminar o projeto de sexta”.
Para quem vem de COBOL, pense numa rotina aparentemente inocente. Um programa lê um arquivo de clientes, chama um módulo, atualiza Db2 e escreve uma saída. Tudo funciona. Mas quem pode executar esse job? Quem altera o JCL? Quem lê o arquivo de entrada? Quem pode substituir a load module? Quem vê o spool? A aplicação é só um pedaço do sistema. A segurança mora no conjunto.
Essa é a grande diferença entre “segurança de ferramenta” e “segurança de arquitetura”. A ferramenta vê uma porta ou um cabeçalho HTTP. O analista maduro pergunta: que processo de negócio passa por aqui, qual dado está envolvido, quem deveria ter acesso e qual seria o estrago se a premissa falhasse?
1. Antes da máscara: fundamentos de computador
O roadmap começa com hardware, sistemas operacionais, sistemas de arquivos, linha de comando, protocolos e virtualização. É a ordem certa. Quem pula essa parte e parte direto para uma distribuição de testes costuma virar operador de menu: aperta botões, coleciona telas assustadoras e não consegue explicar o que encontrou.
Segurança exige entender como as coisas realmente vivem. CPU, memória, processos, arquivos, permissões, conexões, serviços, logs, usuários e atualizações parecem assuntos de administração de sistemas — porque são. A segurança não é uma ilha cercada de capas pretas; é uma camada de raciocínio sobre tudo isso.
No mainframe essa verdade vem de fábrica. Você sabe que um programa COBOL não aparece do nada. Houve fonte, compilação, link-edit, biblioteca, JCL, ambiente de execução, datasets, credenciais, regiões, logs e operadores. Num servidor Linux ou Windows é a mesma novela com outro elenco.
Uma dica de ouro para iniciante: quando encontrar qualquer achado, não pergunte primeiro “como exploro?”. Pergunte: o que é esse componente, por que existe, com que identidade roda, de onde recebe dados, o que grava e quem o administra? A investigação começa por compreender, não por atacar.
2. Redes — não existe ataque mágico, existe caminho
TCP/IP, DNS, DHCP, ARP, roteamento, firewalls, VPNs, VLANs, portas e análise de tráfego aparecem na segunda fase. Muita gente trata redes como decoreba de siglas. Na prática, rede é o mapa do crime, da defesa e do mal-entendido.
Quando uma pessoa abre um site da empresa, o navegador precisa descobrir o endereço pelo DNS, estabelecer conexão, negociar criptografia, atravessar controles de rede, falar com um proxy ou balanceador, atingir a aplicação e talvez buscar dados num banco. Cada passo pode registrar evidência ou criar uma falha.
Uma porta aberta não é automaticamente um problema; ela pode ser um serviço necessário. O problema é uma porta aberta sem necessidade, sem atualização, sem controle de origem, sem monitoramento ou exposta a quem não deveria alcançá-la. É parecido com deixar uma porta corta-fogo destrancada: pode ser útil durante uma mudança, mas, se fica assim para sempre, um dia ela vira capítulo de relatório.
Para o universo z/OS, pense em TN3270, FTP/SFTP, SSH no USS, APIs de z/OS Connect, MQ, Db2 DRDA e interfaces de automação. O IBM Z não vive isolado numa catedral de ar-condicionado. Ele conversa com Internet, nuvem, celulares, parceiros, pipelines e diretórios corporativos. A fortaleza continua sofisticada; apenas ganhou mais pontes levadiças.
Curiosidade de boteco: a camada “mais segura” do ambiente pode cair por algo que parece banal: DNS mal protegido, conta de serviço exposta, segmentação fraca ou log com horário errado. Sem relógios sincronizados, Whistler até ouve os sinais, mas não consegue reconstruir a sequência do incidente.
3. Linux e Windows — dois castelos, a mesma pergunta
No Linux, o roadmap cita instalação, shell, permissões, usuários, grupos, SSH, processos, serviços, cron e logs. No Windows, inclui servidor, Active Directory, controlador de domínio, DNS, DHCP, Group Policy, NTFS e PowerShell. A divisão faz sentido: sistemas operacionais estruturam identidades, processos e controles de formas diferentes.
O princípio, contudo, é universal: menor privilégio. Uma conta, processo ou serviço deve ter apenas a permissão necessária para sua tarefa. Não “tudo, por precaução”. No mundo real, excesso de privilégio é muitas vezes a ponte entre um pequeno erro e um incidente enorme.
Imagine um serviço que precisa ler um diretório de entrada e gravar um diretório de saída. Se ele roda com privilégios administrativos totais, uma falha no serviço pode ganhar poderes que jamais precisaria ter. A correção elegante não é torcer para que ninguém explore a falha: é reduzir o raio de explosão.
Em z/OS, isso conversa diretamente com RACF: usuários, grupos, perfis, ownership, acesso a datasets, recursos, comandos, started tasks e auditoria. RACF é excelente, mas não telepático. Se alguém cria uma regra permissiva porque “o batch estava falhando”, o software obedecerá com a frieza impecável de um maitre que entrega exatamente o prato pedido, inclusive se o prato for uma catástrofe.
Active Directory merece atenção especial. Ele não é uma agenda de usuários do Windows; é o coração identitário de muitas empresas. Uma configuração ruim ali pode afetar estações, servidores, compartilhamentos, aplicações e políticas. E aqui entra a frase que todo novato deveria colar no monitor: autenticar não é autorizar. Saber quem você é não significa que você pode ver o cliente 12345, alterar a tabela salarial ou reiniciar um serviço crítico.
4. Programar para compreender — e corrigir — a falha
Python, Bash, PowerShell, JavaScript, HTML, CSS, SQL e, em certas rotas, C/C++ aparecem no infográfico. O propósito não é transformar todo analista em personagem de filme digitando código verde em quinze monitores. É ganhar autonomia para entender lógica, automatizar tarefas, analisar dados e participar da correção.
COBOL dá uma vantagem mental ótima: você já sabe que entrada precisa ser validada, que regra de negócio importa, que um campo mal definido causa dor e que uma alteração mínima pode ter efeito colateral em produção. Segurança de aplicações é, em grande medida, disciplina de regra de negócio aplicada a um ambiente hostil.
Exemplo seguro e comum: uma API recebe um identificador de cliente e retorna um contrato. O sistema precisa verificar duas coisas: o formato do identificador é válido? E, principalmente, o usuário autenticado tem o direito de consultar aquele contrato? Validar apenas o formato resolve a primeira pergunta; autorização resolve a segunda. Confundir as duas é o tipo de defeito que um relatório de segurança chama de controle de acesso quebrado e o cliente chama de “por que outra pessoa viu meus dados?”.
SQL também merece respeito. Consulta parametrizada, credencial de banco com privilégio mínimo, logs sem segredos e validação do lado do servidor são práticas muito mais importantes que truques de laboratório. A melhor vitória de segurança é a falha que nunca chega ao atacante porque o desenho já fechou a porta.
5. Web, APIs e o mundo em que todo sistema ganhou uma janela
HTTP/HTTPS, cookies, sessões, APIs REST, JSON, servidores web e bancos de dados compõem a fase web. Hoje, até o sistema mais antigo pode aparecer atrás de uma API. Isso é poderoso: um aplicativo móvel pode consultar saldo, uma parceira pode iniciar processo, um portal pode puxar informações antes trancadas num terminal.
Mas cada interface nova amplia a superfície de ataque. Um endpoint não é perigoso porque tem nome em inglês; ele é perigoso se confia demais no pedido recebido, entrega dados demais, aceita permissões demais ou não deixa evidência suficiente.
Pense numa API como a portaria de um prédio. HTTPS protege a conversa da rua até a portaria; não garante que o porteiro confira se o visitante pode entrar no apartamento correto. Token prova uma identidade; não substitui a checagem de autorização. E um log bem feito registra quem pediu, o que pediu, quando e qual foi o resultado — sem despejar senha, token ou dado sensível no papel.
Martin Bishop certamente pediria o diagrama antes de aceitar a frase “é só uma APIzinha”. Quem chama quem? Quais dados atravessam a fronteira? Onde está a autenticação? Onde a autorização é decidida? Que dados são mascarados? Quem é avisado quando algo estranho ocorre? Essa conversa, feita no projeto, custa infinitamente menos do que a mesma conversa depois de um vazamento.
6. CIA, criptografia e o cadáver de Base64
A tríade CIA não tem ligação com agência secreta, embora Carl talvez discordasse. Ela significa Confidencialidade, Integridade e Disponibilidade.
Confidencialidade: só vê quem deve ver.
Integridade: dado e processo não são alterados indevidamente.
Disponibilidade: o serviço continua acessível quando necessário.
Uma transação bancária protegida precisa das três. Não adianta esconder o valor se ele pode ser alterado. Não adianta impedir alterações se o serviço passa seis horas indisponível. E não adianta manter o serviço de pé se qualquer pessoa consegue consultar o dado de qualquer cliente.
Outro tropeço clássico: confundir criptografia, hash e codificação. Criptografia protege informação e pode ser revertida por quem tem a chave adequada. Hash é uma impressão matemática usada, por exemplo, para verificar integridade e apoiar armazenamento seguro de senhas. Codificação muda a representação para transporte ou compatibilidade. Base64 é codificação — não é uma capa de invisibilidade. Igor pode colocar uma senha em Base64, girar a cadeira e anunciar “agora ninguém descobre”; Martin Bishop apenas ergueria uma sobrancelha.
Certificados digitais e PKI entram aqui porque ajudam a estabelecer confiança e proteger comunicações. Mas certificado válido não transforma aplicação mal autorizada em aplicação segura. É como uma porta blindada num prédio cujo porteiro entrega cópia da chave a qualquer pessoa simpática.
7. Ferramentas: scanner não é oráculo
Nmap, Wireshark, Burp Suite, OWASP ZAP, scanners de vulnerabilidade, ferramentas de análise de configuração e plataformas de teste aparecem no roadmap. São instrumentos úteis — e exigem contexto.
Um scanner pode informar que algo “parece vulnerável”. Isso é uma hipótese. O analista precisa validar versão, configuração, exposição, controles compensatórios, impacto e possibilidade real de exploração dentro do ambiente autorizado. Falso positivo existe. Prioridade errada existe. Descoberta sem risco prático existe. E, pior, falha simples com impacto gigantesco existe.
Por isso, o trabalho profissional não é “rodar ferramenta e mandar PDF”. É investigar, documentar e conversar. Um achado bem escrito contém ativo afetado, evidência, risco de negócio, causa provável, recomendação concreta, prioridade e como retestar depois da correção.
No ambiente COBOL, o equivalente é familiar: não basta dizer “o job deu ABEND”. Você identifica o código, o módulo, o dataset, a condição anterior, o impacto, a recuperação e a prevenção. Segurança madura é investigação operacional com vocabulário de risco.
8. Cloud, containers e a nova sala de máquinas
Cloud, Docker, Kubernetes, CI/CD, IAM, logs, monitoramento e SIEM são a parte moderna do mapa. O erro mais perigoso é imaginar que nuvem transfere a responsabilidade para algum ser etéreo de camiseta preta. O provedor protege partes da infraestrutura; a empresa continua responsável por identidades, dados, configurações, aplicações e permissões conforme o serviço usado.
Os incidentes atuais muitas vezes não começam por uma vulnerabilidade de cinema. Começam por uma chave exposta, um segredo no repositório, uma permissão IAM ampla demais, um armazenamento acessível publicamente, uma pipeline sem revisão ou um container que executa com privilégios excessivos.
DevSecOps significa colocar controles no fluxo de entrega: revisar código, verificar dependências, proteger segredos, testar configurações e manter rastreabilidade. É o velho controle de mudança com motor novo. Se alguém altera uma política crítica, deve haver evidência de quem aprovou, o que mudou e como voltar atrás. O mainframe já ensinava isso muito antes de o mercado inventar nomes em inglês para parecer moderno.
9. O que o infográfico esquece: pessoas, risco e resposta
O mapa é bom, mas eu acrescentaria governança, LGPD, threat modeling, resposta a incidentes, comunicação executiva e segurança de IA.
Threat modeling é fazer as perguntas desconfortáveis cedo: qual ativo importa? Quem pode atacá-lo? Por quais caminhos? Que controles existem? Qual é o impacto aceitável? É a reunião em que Mother desenha o prédio, Whistler escuta o ambiente, Crease desconfia de todo mundo e Martin Bishop impede Carl de apertar o botão vermelho antes de entender a missão.
Resposta a incidente também é essencial. Prevenção falha; pessoas erram; fornecedores são comprometidos; falhas desconhecidas aparecem. Então a organização precisa saber detectar, conter, investigar, recuperar e aprender. Evento não é incidente; alerta não é crise. A maturidade está em transformar sinais em decisões proporcionais.
E segurança de IA chegou à mesa: prompt injection, vazamento de contexto, permissões de agentes, bases RAG contaminadas, proveniência, logs e supervisão humana. Um modelo pode responder bonito, mas ainda precisa de autorização para agir e de trilha de auditoria para explicar o que fez. Uma IA com acesso amplo sem controle é apenas Igor recebendo as chaves do laboratório depois do terceiro café.
10. Um roteiro possível para o programador COBOL iniciante
Martin Bishop não recomendaria começar comprando dez certificações e baixando ferramentas aleatórias. Ele montaria um plano que produz entendimento e evidência.
Consolide redes. Entenda IP, DNS, TCP, TLS, HTTP, segmentação e logs.
Crie um laboratório isolado e autorizado. Máquinas virtuais, aplicações deliberadamente vulneráveis e dados fictícios; nunca um alvo de terceiros.
Aprenda Linux e Windows por administração. Usuários, permissões, serviços, patches, logs e hardening.
Aprofunde identidade. MFA, menor privilégio, contas de serviço, grupos, segregação de funções e revisão de acesso.
Use programação para automação e leitura de código. Python, PowerShell e SQL com foco em validação e evidência.
Estude aplicações web e APIs. Sessão, autorização, validação, gestão de segredo e logging.
Pratique avaliação e relatório. Todo laboratório deve terminar com: descoberta, impacto, recomendação e reteste.
Conecte ao seu diferencial. RACF, z/OS, USS, CICS, Db2, z/OSMF, APIs e DevSecOps híbrido.
Certificações podem ajudar a organizar o estudo e abrir portas; não substituem experiência. Uma progressão geral pode passar por fundamentos de redes e segurança, depois laboratórios práticos, segurança de aplicações, nuvem, operações defensivas ou testes autorizados — sempre conforme o objetivo profissional, orçamento e área escolhida.
Mas há um diferencial pouco explorado: gente capaz de falar com desenvolvedor COBOL, administrador z/OS, time de identidade, auditoria, cloud, SOC e negócio. Essa pessoa não é “o hacker do mainframe”. É o tradutor de risco entre mundos que normalmente trocam tickets, não ideias. E vale ouro.
Epílogo — a senha da caixa preta não é técnica
No fim de Sneakers, a grande descoberta não é apenas matemática ou tecnológica. É que informação, confiança e poder têm consequências humanas. Esse continua sendo o centro da segurança cibernética.
O roadmap da imagem serve como mapa, desde que você não confunda mapa com território. Aprenda ferramentas, sim; mas primeiro aprenda sistemas. Estude falhas, mas entenda negócios. Domine logs, redes e permissões, mas não esqueça que alguém precisa transformar tudo isso em decisão compreensível. E nunca faça teste sem autorização — Martin Bishop pode ter carisma, mas o jurídico raramente tem trilha sonora.
Para o programador COBOL, a boa notícia é que você já carrega parte do kit: pensamento estruturado, respeito por produção, noção de impacto, disciplina de mudança, apreço por logs e a experiência de saber que um caractere fora de lugar pode transformar uma tarde tranquila num incidente memorável.
Agora acrescente redes, identidade, APIs, nuvem, resposta e segurança de IA. Não para virar uma figura encapuzada do infográfico. Para ser a pessoa que olha para o castelo, a porta, o crachá, o log e o código — e percebe que o inimigo talvez não esteja arrombando nada. Talvez ele só tenha pedido acesso com educação.
Easter egg final: se você encontrou uma conta com mais privilégio do que precisa, um certificado vencido, uma API que confunde identidade com autorização e um log sem horário confiável, não chame a equipe de Sneakers. Abra um chamado, preserve a evidência e prepare o café. O filme começa aí.
Sem comentários:
Enviar um comentário