 |
| Bellacosa Mainframe em uma introducao a segurança cibernetica |
☕ Um Café no Bellacosa Mainframe
Em parceria com o Dr. Strangelove — que prometeu não ensinar o z/OS a cavalgar uma bomba, desde que ninguém deixe Igor perto do painel de emergência
Segurança Cibernética para Quem Escreve COBOL — Quando o Mainframe Descobriu que o Inimigo Não Precisava Arrombar a Porta, Bastava Pedir Acesso com Educação
Ou: o programador iniciante achava que segurança era coisa do RACF, até descobrir que uma senha roubada, uma API sem validação, uma biblioteca vulnerável e um log sem horário certo podiam reunir-se no mesmo JCL para produzir um ABEND de proporções cinematográficas
O Dr. Strangelove entrou no Bellacosa Mainframe Café às sete da manhã usando uma luva preta, um terno amarrotado e a expressão de quem acabara de receber autorização para transformar um diagrama de rede em uma arma estratégica.
— Cavalheiros — disse ele, olhando para o quadro branco —, hoje falaremos de segurança.
Igor, que estava instalando um cabo de rede entre a máquina de café e um terminal 3270, levantou a mão:
— É aquela coisa do cadeado, doutor?
— Não, Igor. O cadeado é apenas o desenho que vendemos para convencer as pessoas de que controlamos alguma coisa.
E, pela primeira vez, o jovem programador COBOL sentado no balcão percebeu que segurança não era uma disciplina distante, feita de capuzes pretos, telas verdes e pessoas digitando depressa em filmes ruins. Segurança era o motivo pelo qual um salário não aparecia na tela errada. Era o motivo pelo qual uma transação não podia ser alterada em silêncio. Era o motivo pelo qual o sistema continuava funcionando numa sexta-feira de pagamento, mesmo quando metade da internet resolveu tentar entrar ao mesmo tempo.
Em outras palavras: segurança era negócio, continuidade e confiança usando capacete.
Prólogo — O cofre, a porta e o sujeito que já estava lá dentro
A primeira imagem daquele caderno de cibersegurança fala de confidencialidade, integridade e disponibilidade: a velha tríade CIA. Não é agência de espionagem; é a fundação de quase tudo.
Confidencialidade: somente quem deve ver consegue ver.
Integridade: o dado permanece correto, completo e protegido contra alteração indevida.
Disponibilidade: sistema e informação estão acessíveis quando autorizados precisam deles.
Pense num sistema de folha de pagamento em COBOL.
A confidencialidade impede que o operador do turno noturno veja salários, contas bancárias e descontos médicos de todos os funcionários. A integridade impede que alguém transforme discretamente 00000500000 em 00050000000 no campo de salário. E a disponibilidade garante que o batch de pagamento não fique parado porque um servidor periférico decidiu tirar férias no meio da madrugada.
Dr. Strangelove bateu a colher no pires.
— O problema, meus caros, é que os humanos tratam segurança como se fosse uma fechadura. Mas ela é uma cidade inteira: ruas, chaves, guardas, câmeras, regras, mapas de fuga e alguém responsável por acordar quando o alarme toca.
No mainframe, muita gente se acostumou — com alguma razão — a enxergar o ambiente como um cofre. RACF, segregação, datasets protegidos, auditoria, controle de job, CICS, Db2, JES2: há décadas de engenharia séria aí. Mas o cofre moderno ganhou APIs REST, Java, USS, FTP legado, TN3270, pipelines DevOps, conexões cloud e notebooks de usuários. A porta de aço continua forte; o problema é que agora ela tem interfone, Wi-Fi e formulário web.
1. A cadeia do desastre: ameaça, vulnerabilidade, exploit, impacto e risco
Antes de comprar qualquer ferramenta com painel cheio de gráficos verdes, é preciso aprender as palavras certas.
Uma ameaça é algo capaz de causar dano: criminoso, ransomware, insider malicioso, funcionário enganado, fornecedor comprometido, falha operacional. Uma vulnerabilidade é a fraqueza: software sem patch, senha fraca, serviço exposto, permissão excessiva, código que confia na entrada do usuário.
O exploit é a técnica usada para aproveitar a vulnerabilidade. E o impacto é o estrago: vazamento, fraude, interrupção, multa, perda de confiança, trabalho no fim de semana e café tomado com raiva.
Risco é a possibilidade de uma ameaça explorar uma vulnerabilidade e causar impacto.
O desenho simplifica isso como:
Risco = probabilidade × impacto
É uma boa fórmula para começar, mas não use como se fosse a tabela periódica. Uma vulnerabilidade CVSS 9.8 em um laboratório isolado não tem necessariamente prioridade maior que uma falha CVSS 6.5 em uma API pública que dá acesso a dados de clientes.
A pergunta madura não é “qual é a nota da CVE?”. É:
Esse ativo é crítico?
Está exposto à internet?
Existe exploit público?
Há sinais de exploração ativa?
Que dados ele manipula?
Temos controles compensatórios?
Se ele parar agora, quem deixa de trabalhar, receber ou vender?
Igor anotou: “não discutir com a CVSS; perguntar onde ela mora”.
Boa anotação, Igor.
2. Rede: não existe ataque mágico, existe caminho
Um programa COBOL pode parecer morar exclusivamente dentro do mainframe, mas hoje ele conversa com CICS, Db2, MQ, arquivos, APIs, z/OS Connect, bancos externos, portais, aplicativos móveis e outros sistemas que alguém chama de “integração simples” cinco minutos antes da produção parar.
Por isso, o programador precisa entender a rua por onde os dados passam.
IP é o endereço lógico de um equipamento na rede.
Porta identifica o serviço: 443 costuma ser HTTPS; 22, SSH; 53, DNS.
DNS traduz nome em endereço.
TCP prioriza entrega confiável; UDP costuma priorizar velocidade e menor sobrecarga.
TLS protege uma comunicação, criando canal criptografado e autenticado.
A analogia do Café é simples: o IP informa em qual prédio você está; a porta diz qual departamento atende; o protocolo define como a conversa acontece; TLS põe a conversa dentro de um envelope lacrado.
Firewall é a portaria. Ele pode dizer “essa origem não entra por esta porta”, mas não entende sozinho toda a lógica do negócio. Se uma requisição HTTPS legítima traz uma ordem de pagamento fraudulenta usando credenciais válidas, ela pode atravessar o firewall sorrindo e mostrando um crachá roubado.
Por isso existe defesa em profundidade:
rede segmentada;
firewall;
IDS e IPS;
controle de acesso;
MFA;
endpoint protegido;
aplicação segura;
criptografia;
logs;
backups;
resposta a incidentes.
Não é redundância inútil. É a admissão honesta de que um controle pode falhar.
No z/OS, segmentar também significa pensar em ambientes, LPARs, redes, acessos a USS, perfis RACF, zonas de administração e fluxos entre componentes. O objetivo não é criar uma burocracia que faz qualquer mudança exigir seis luas cheias. É impedir que o comprometimento de um ponto vire passeio turístico pelo datacenter.
3. Autenticar não é autorizar — e RACF não lê pensamentos
Esta é uma das distinções mais importantes de toda a segurança:
Autenticação pergunta: “quem é você?”
Autorização pergunta: “o que você pode fazer?”
Controle de acesso aplica a decisão e registra o resultado.
Uma senha, um token, um certificado ou uma biometria ajudam a autenticar. Já uma regra RACF, uma role, uma ACL ou uma política de API ajudam a autorizar.
Você pode provar que é o Vagner Bellacosa. Isso não quer dizer que pode alterar a tabela de salários, cancelar produção, dar SPECIAL para todos ou substituir a produção por um JOB chamado DOUTOR.STRANGELOVE.NUCLEAR.TESTE.
O princípio é o do menor privilégio: usuário, processo e serviço recebem somente o acesso necessário para executar a tarefa — nem uma migalha a mais.
Há modelos clássicos:
RBAC: acesso por função. Ex.: operador, auditor, administrador.
ABAC: acesso por atributos e contexto. Ex.: permitir somente se o usuário pertence à área correta, usa dispositivo gerenciado, está no horário permitido e acessa o caso atribuído.
DAC: o proprietário decide quem acessa.
MAC: acesso baseado em classificação formal, comum em contextos militares e governamentais.
A evolução moderna é o Zero Trust: não confiar automaticamente porque alguém está na rede interna, usa notebook corporativo ou teve acesso ontem. Cada solicitação importante deve ser avaliada com contexto.
É o oposto do velho pensamento: “está dentro do castelo, então é amigo”. O invasor moderno frequentemente já está dentro — usando conta válida, VPN, token, e-mail ou sessão roubada.
4. Criptografia: Base64 não é capa de invisibilidade, Igor
O caderno faz bem em separar três coisas que muita gente mistura.
Criptografia transforma informação legível em informação protegida por chave. Serve para confidencialidade.
Hash gera uma impressão digital do conteúdo. Ele ajuda a verificar integridade, mas não foi feito para recuperar o original.
Encoding, como Base64, só muda o formato. Não protege segredo algum. Se alguém “escondeu” senha em Base64, não criou segurança; apenas colocou bigode falso no dado.
Há duas famílias principais de criptografia:
Simétrica: usa uma chave secreta compartilhada. É veloz e ótima para grandes volumes de dados.
Assimétrica: usa par de chaves pública e privada. É muito útil para identidade, assinatura e troca segura de chaves.
No HTTPS moderno, o navegador e o servidor usam mecanismos assimétricos para estabelecer confiança e negociar segredos; depois, protegem a sessão com criptografia simétrica, mais rápida. É por isso que um site pode proteger milhões de conexões sem exigir que o datacenter compre uma usina nuclear do Dr. Strangelove.
Para quem trabalha em ambiente corporativo, as regras são pouco glamourosas e absolutamente vitais:
nunca grave segredos no código;
nunca suba senha ou token em repositório;
proteja chave privada como ativo crítico;
roteie segredos por cofre apropriado;
rotacione chaves e credenciais;
use TLS em trânsito;
proteja dados sensíveis em repouso;
valide certificados, não apenas “aceite qualquer um para o teste funcionar”.
No IBM Z, recursos criptográficos e serviços como ICSF não existem apenas para colocar siglas bonitas em apresentação. Eles permitem proteger chaves e operar criptografia com controles e desempenho compatíveis com dados de alto valor.
5. Aplicação segura: o bug também pode ser uma regra de negócio
Quando se fala em segurança web, o povo lembra de SQL Injection, escreve uma query parametrizada e vai dormir em paz. Seria lindo se o monstro fosse tão educado.
A segurança de aplicação inclui:
controle de acesso quebrado;
falhas de autenticação;
injeção;
configuração insegura;
componentes desatualizados;
segredos expostos;
erros de integridade de software;
logs insuficientes;
desenho inseguro.
O exemplo mais perigoso para um iniciante entender é Broken Access Control.
Imagine uma API que recebe:
/cliente/123/extrato
Se o usuário autenticado troca 123 por 124 e a aplicação devolve o extrato de outra pessoa, não faltou criptografia. Faltou autorização no nível do objeto. O sistema verificou “você entrou?”, mas esqueceu de verificar “você pode ver exatamente este cliente?”.
Em COBOL e CICS, o equivalente pode aparecer em telas, transações, arquivos, bancos, serviços e integrações. Segurança não é só colocar uma rotina de login na entrada. É verificar regra de negócio em cada operação sensível.
E há uma frase que deveria morar na parede de todo time:
WAF é cinto de segurança; não é permissão para dirigir contra o muro.
WAF, firewall e scanner ajudam, mas não corrigem uma aplicação cujo desenho permite que um usuário aprove pagamento para a própria conta sem segregação de funções.
6. DevSecOps: segurança não entra na última janela de mudança
DevSecOps é a tentativa de fazer segurança acompanhar o ciclo de desenvolvimento em vez de aparecer no fim dizendo “encontrei 417 problemas, cancelem a entrega”.
O ideal é incluir segurança em todas as etapas:
Requisitos: quais dados existem? Quais obrigações legais? O que pode dar errado?
Desenho: modelar ameaças, definir fronteiras, privilégios e fluxos.
Desenvolvimento: revisão de código, práticas seguras, análise estática.
Build: verificar dependências, segredos, integridade de artefatos.
Testes: análise dinâmica, testes de integração, cenários de abuso.
Deploy: validar infraestrutura como código, configuração e permissões.
Operação: monitorar, detectar, responder e aprender.
Para COBOL, isso não significa jogar fora o processo de mudança confiável para fingir que tudo agora é container. Significa trazer princípios modernos para a casa: versionamento, revisão, testes automatizados onde possível, evidência de mudança, análise de dependências em componentes integrados, trilha de auditoria e separação adequada entre desenvolvimento e produção.
Dr. Strangelove olhou para Igor:
— E se o programador insistir em gravar a senha num literal COBOL?
— A gente chama de constante, doutor?
— Chamamos de incidente aguardando data de abertura.
7. Vulnerabilidade, endpoint e nuvem: scanner não é oráculo
Gestão de vulnerabilidades é processo contínuo:
inventariar → descobrir → analisar → priorizar → corrigir ou mitigar → validar → medir → repetir
O erro clássico é rodar scanner, gerar um PDF de 300 páginas e declarar vitória. Scanner não corrige patch, não remove privilégio excessivo, não fecha serviço, não atualiza imagem e não convence um dono de aplicação a testar a mudança.
O ativo desconhecido é especialmente perigoso. Um servidor “aposentado” pode continuar ligado com um serviço vulnerável, uma conta antiga e uma conexão esquecida. É o equivalente técnico daquele JCL que ninguém sabe quem criou, mas todos têm medo de apagar.
No endpoint, segurança é feita em camadas:
hardening do sistema operacional;
configuração segura;
atualização;
antimalware;
EDR;
controle de aplicações;
criptografia e proteção física.
EDR é mais do que antivírus: observa comportamento e ajuda na investigação e resposta. Mas não deve virar desculpa para não aplicar patch, manter contas administrativas ou deixar software desconhecido rodar.
Na cloud, a pegadinha é a responsabilidade compartilhada. O provedor protege partes da infraestrutura; você continua responsável por identidade, dados, configuração, permissões, chaves, aplicações e uso correto dos serviços. Bucket público por engano não é “falha da nuvem”. Geralmente é uma porta aberta pela própria empresa.
8. SIEM, MITRE e o momento em que log vira história
Log isolado é ruído. Correlação transforma peças em narrativa.
Um login falho pode ser erro de digitação. Cinco tentativas falhas podem ser usuário esquecendo senha. Mas login falho na VPN, seguido de autenticação bem-sucedida de local impossível, depois elevação de privilégio e transferência anormal de dados: aí o SOC tem uma história para investigar.
SIEM recebe e organiza eventos de servidores, rede, aplicações, cloud, firewall, identidades e endpoints. Seu valor não está no painel colorido. Está em responder:
o que aconteceu?
quando?
com qual conta?
em qual ativo?
de onde veio?
que dados foram tocados?
até onde o evento chegou?
Por isso, horário correto importa. Sem NTP, os logs são como testemunhas de boteco depois do quinto copo: todos têm certeza, ninguém concorda sobre a ordem dos fatos.
MITRE ATT&CK entra como vocabulário para comportamento adversário: acesso inicial, execução, persistência, roubo de credenciais, movimento lateral, exfiltração e impacto. Não é checklist de “tenho ferramenta para tudo?”. É ferramenta para perguntar: “se o atacante fizer isso, consigo ver? Consigo bloquear? Consigo investigar?”
9. Phishing e resposta a incidente: o ataque não começa no malware
Muitos ataques começam com uma história plausível: e-mail de fornecedor, chamada urgente do diretor, convite de reunião, QR code, documento compartilhado, WhatsApp ou voz clonada.
O phishing moderno pode ser perfeitamente escrito. Então a defesa não pode depender de procurar erro de português.
A defesa madura mistura:
MFA;
filtros e sandbox;
autenticação de domínio;
confirmação fora de banda para pagamento;
bloqueio de anexos perigosos;
cultura de reporte sem punição;
treinamento baseado em situações reais.
Se a pessoa clicou e avisou em dois minutos, ela ajudou a organização. Não a transforme em inimiga. O inimigo agradeceria.
Quando há incidente, o ciclo é:
Preparar: papéis, playbooks, contatos, ferramentas, backups e exercícios.
Identificar: validar alerta, classificar, coletar evidência.
Conter: limitar propagação e preservar negócio.
Erradicar: remover causa, persistência e vulnerabilidade.
Recuperar: restaurar com segurança e monitorar.
Aprender: corrigir processo, controle, treinamento e arquitetura.
A regra de ouro é: não apague pistas antes de saber o que aconteceu. Isolar a máquina pode ser correto. Sair removendo arquivos, reiniciando tudo e destruindo evidência pode transformar um incidente investigável em uma novela de 14 capítulos.
Epílogo — O botão vermelho não é um plano de segurança
No fim do café, Dr. Strangelove desenhou uma arquitetura inteira no guardanapo:
identidade + menor privilégio + segmentação + código seguro + criptografia + patch + logs + detecção + resposta + backup
Igor olhou para a lista.
— Então qual é o controle mais importante, doutor?
A luva preta tentou subir até uma saudação, mas ele a segurou.
— O mais importante é não depender de apenas um.
Para o programador COBOL iniciante, este é o aprendizado de verdade: segurança não mora num produto, nem numa sigla, nem apenas no RACF, no firewall ou no SOC. Ela aparece quando você define um campo, trata uma entrada, autoriza uma transação, revisa uma mudança, registra uma ação, protege um segredo e pergunta: “o que acontece se isto falhar — ou se alguém tentar abusar?”
O mainframe não é velho. Velha é a ideia de que um sistema central, poderoso e conectado ao mundo pode sobreviver apenas porque sempre sobreviveu.
E, enquanto o sistema estiver processando pagamentos, hospitais, impostos, cartões, seguros e histórias inteiras de pessoas, segurança continuará sendo o trabalho silencioso de garantir que o próximo RETURN-CODE não venha acompanhado de sirenes.
Igor desligou o cabo da máquina de café.
O Dr. Strangelove respirou aliviado.
E o Bellacosa Mainframe Café permaneceu aberto.
Sem comentários:
Enviar um comentário