☕ Um Café no Bellacosa Mainframe
Mr. Robot Entrou no CPD — O Dia em que o Terminal Verde Descobriu que Não Era Invisível
Ou: por que um programa COBOL perfeito não impede um ataque, o que RACF, CICS, JCL, USS e SMF estão fazendo na mesma cena, e como não virar figurante no episódio em que alguém “só tinha uma conta de teste”
“Olá, amigo.”
Não, não é o seu colega do suporte chamando no Teams. É Elliot Alderson, encostado numa porta de emergência do data center, olhando para um terminal 3270 e fazendo aquela cara de quem acabou de perceber uma coisa muito desconfortável:
“Todo mundo acha que o mainframe é seguro porque é velho. Mas velho não é uma política de segurança.”
Elliot não está totalmente certo — nem totalmente errado.
Mas existe uma diferença importante entre ter uma plataforma com controles fortíssimos e ter esses controles realmente bem configurados, revisados e monitorados.
É aqui que entram expressões que parecem saídas de uma série: Red Team, Pentest, Reconnaissance, Privilege Escalation, Exfiltration.
Calma. Este artigo não é um manual para atacar ninguém, nem um convite para experimentar comandos em ambiente corporativo. Segurança ofensiva só existe de forma legítima quando há autorização, escopo, ambiente controlado e profissionais responsáveis.
A ideia é outra: ensinar o programador COBOL iniciante a olhar para o mainframe com os olhos de quem protege o castelo — entendendo por quais portas um invasor tentaria passar e quais sinais o time de defesa deveria enxergar antes que a história vire uma reunião às 7h da manhã com todo mundo falando “impacto potencial”.
Prólogo — o mainframe não mora mais isolado no porão
Durante muito tempo, a imagem popular do mainframe foi esta: uma máquina enorme, escondida em um CPD gelado, acessível por terminal verde, tão misteriosa quanto um arquivo em fita sem etiqueta.
A realidade moderna é mais interessante.
O mainframe continua processando cargas críticas, mas agora conversa com:
aplicações web;
celulares;
APIs;
parceiros externos;
filas MQ;
nuvem;
redes corporativas;
Linux;
automações DevOps;
fornecedores;
ambientes distribuídos.
Ou seja: o mainframe não ficou fraco. Ele ficou conectado.
E toda conexão é uma porta que precisa de dono, finalidade, autenticação, criptografia, monitoramento e revisão. O problema raramente é “o IBM Z não é seguro”. O problema costuma ser mais humano e menos glamouroso:
uma conta técnica que ninguém desativou;
um grupo RACF criado há quinze anos “só para resolver uma urgência”;
uma transação CICS protegida de forma parcial;
uma biblioteca de JCL com alteração permissiva demais;
uma integração exposta sem o mesmo rigor aplicado ao core;
um alerta de segurança que existe, mas ninguém acompanha;
um usuário com mais autoridade do que precisa porque “sempre foi assim”.
No mundo de Mr. Robot, isso seria a cena em que o personagem não precisa destruir o cofre. Basta descobrir que alguém deixou a chave numa gaveta chamada TEMP.
No mainframe, a gaveta não se chama necessariamente TEMP. Às vezes ela se chama GRUPO-LEGADO, ID-TERCEIRO, USER=PROD ou “não mexe nisso porque pode parar a folha”.
1. Red Team: não é vandalismo com capuz
Vamos limpar a primeira confusão.
Um Red Team é uma equipe autorizada a pensar e agir como um adversário, dentro de regras formais. Ela tenta responder a uma pergunta que incomoda qualquer organização séria:
“Se uma identidade, uma aplicação ou uma integração fosse comprometida, alguém conseguiria chegar aos nossos ativos mais críticos?”
Não é uma prova para humilhar a equipe de z/OS. Não é competição de ego entre segurança e operação. Não é alguém entrando no CPD com uma mochila preta e uma música industrial de fundo.
É um teste de realidade.
O Red Team procura caminhos que podem combinar tecnologia, configuração, processos e comportamento humano. A defesa aprende se seus controles realmente funcionam.
Há quatro conceitos que andam juntos, mas não são iguais:
| Conceito | Pergunta principal |
|---|---|
| Assessment de segurança | “Os controles existem e estão configurados adequadamente?” |
| Pentest | “Uma vulnerabilidade pode ser explorada dentro do escopo?” |
| Red Team | “Um adversário simulado consegue atingir um objetivo relevante?” |
| Purple Team | “Ataque e defesa conseguem aprender juntos e melhorar a detecção?” |
O Purple Team é o encontro civilizado depois da pancadaria controlada. A equipe ofensiva mostra a técnica em um laboratório ou ambiente autorizado; a equipe defensiva ajusta logs, alertas, processos e controles. Em vez de esconder a falha até o relatório final, os dois lados transformam a experiência em melhoria contínua.
É quase como um ensaio de incêndio. A intenção não é provar que o prédio pega fogo. É descobrir se a saída está livre, se o alarme funciona e se alguém sabe quem tem a chave da porta.
2. A cadeia do ataque: do “oi” ao “por que esse usuário acessou isso?”
Um curso de segurança ofensiva de mainframe costuma falar em uma cadeia de ataque. Pense nela como uma investigação de CSI, mas o cadáver é a falsa sensação de segurança.
A história, em alto nível, segue esta sequência:
reconhecimento;
acesso inicial;
enumeração;
escalada de privilégio;
alcance do ativo crítico;
exfiltração ou impacto;
detecção e resposta.
Vamos traduzir isso para o dialeto do CPD.
Reconhecimento: antes de abrir a porta, alguém olha a fachada
Reconhecimento é a fase em que se descobre o que está exposto e como a organização funciona. Em uma avaliação legítima, isso pode incluir domínios públicos, documentação técnica publicada sem querer, nomes de produtos, integrações conhecidas, padrões de e-mail, serviços de rede e informações de fornecedores.
Para um atacante real, informação pública é uma peça de quebra-cabeça. Para a defesa, é um inventário de exposição.
O ponto não é esconder o nome “z/OS” como se fosse segredo de Estado. Segurança por obscuridade tem a mesma robustez de colocar uma placa “não entre” na porta do servidor. O ponto é não entregar desnecessariamente:
detalhes de arquitetura;
versões e componentes sem necessidade;
endereços, portas ou telas administrativas;
nomes de IDs técnicos;
fluxos internos;
documentos de operação com credenciais, exemplos reais ou dados sensíveis.
Acesso inicial: uma conta pequena pode contar uma história grande
Nem todo incidente começa com uma conta poderosa. Às vezes começa com uma identidade aparentemente sem importância.
Imagine um usuário de fornecedor autorizado a consultar algo específico. Ou uma conta de aplicação criada para integração. Ou um ID antigo que deveria ter sido removido quando alguém saiu da empresa e foi morar em Florianópolis para abrir uma pousada.
A pergunta de segurança é:
“Se este ID fosse comprometido, o estrago ficaria limitado ao que ele precisa fazer?”
Esse é o princípio do menor privilégio. Uma conta deve ter somente as permissões necessárias, durante o tempo necessário, para a função necessária.
Não é burocracia. É reduzir o raio da explosão.
Se uma conta de consulta consegue alterar um dataset de produção, submeter batch privilegiado ou acessar transações administrativas, ela não é uma conta de consulta. Ela é uma bomba com crachá.
3. TN3270: o terminal verde não é um portal mágico
O TN3270 permite que o clássico terminal 3270 trafegue pela rede TCP/IP. É uma ponte entre o universo “tela preta ou verde com PF3” e as redes modernas.
Para quem está começando, parece apenas uma forma bonita de chegar ao TSO ou ao CICS. Para segurança, ele traz perguntas importantes:
quem pode se conectar?
a sessão é protegida?
a autenticação é forte?
há tentativas de login anormais?
existe bloqueio, expiração e revisão de contas?
o serviço está exposto somente onde deveria?
os eventos chegam ao monitoramento?
O problema não é usar TN3270. O problema é tratá-lo como se fosse invisível porque a tela parece antiga.
Elliot chamaria isso de “nostalgia operacional”. O atacante chamaria de oportunidade. O profissional de segurança chama de superfície de ataque.
4. TSO, ISPF e RACF: o castelo tem corredores, portas e chaves
TSO é o ambiente interativo de trabalho. ISPF é aquela cidade organizada em painéis, datasets, membros, opções e comandos que todo iniciante aprende a respeitar depois de apagar algo no lugar errado uma única vez.
RACF é o grande porteiro — e, em muitos casos, o cartório, o condomínio, a portaria e o livro de ocorrências ao mesmo tempo.
Ele cuida de identidades, grupos, recursos, datasets, permissões, auditoria e decisões de acesso. Quando bem administrado, é uma das razões pelas quais o mainframe tem reputação tão forte em segurança.
Mas RACF não resolve intenções ruins automaticamente. Ele aplica a política que foi configurada.
Se a política diz que cinquenta pessoas podem alterar uma biblioteca crítica, o RACF fará isso de forma extremamente confiável. Se um grupo antigo acumula privilégios que ninguém mais entende, ele continuará obedecendo com a mesma disciplina.
Por isso, uma revisão RACF madura precisa perguntar:
Quem realmente precisa de
SPECIAL?Quem realmente precisa de
OPERATIONS?Há IDs compartilhados?
Há contas inativas?
Existem grupos com autoridade ampla demais?
Permissões temporárias foram removidas?
Os donos de recursos estão claros?
A segregação entre desenvolvimento, homologação e produção é real?
O programador COBOL iniciante não precisa decorar toda a sintaxe de RACF no primeiro dia. Mas precisa entender a consequência de uma autorização errada.
Quando você tenta abrir um dataset e recebe “not authorized”, não é o sistema sendo chato. É o sistema dizendo: “talvez esta porta não seja sua”.
E, em segurança, esse “não” é uma das palavras mais bonitas do dicionário.
5. USS: quando o z/OS também fala Unix
Unix System Services, ou USS, é o ambiente Unix do z/OS. Ele permite shell, diretórios, arquivos, scripts, serviços e ferramentas modernas convivendo com o mundo tradicional de datasets, JCL e transações.
É poderoso. E exatamente por isso precisa ser tratado com cuidado.
Um erro comum é pensar: “o mainframe é seguro; logo, tudo o que roda dentro dele é seguro”. Não. Permissões Unix mal configuradas continuam sendo permissões mal configuradas, mesmo quando a máquina custa mais que uma pequena frota de carros.
No USS, a defesa precisa observar:
propriedade e permissões de arquivos;
scripts e automações;
chaves e certificados;
contas técnicas;
serviços em execução;
acessos anormais;
integração entre identidade RACF e privilégios Unix.
O grande aprendizado é que a segurança moderna de IBM Z não cabe numa caixinha marcada “RACF”. Ela passa por RACF, USS, TCP/IP, CICS, Db2, middleware, aplicações e processos humanos.
6. CICS: autenticar não basta, é preciso autorizar
CICS é uma das joias da coroa. Ele hospeda transações que podem consultar saldo, movimentar dinheiro, atualizar cadastro, emitir documentos, processar pedidos ou falar com outros sistemas.
Uma transação pode estar protegida no RACF e ainda ter um problema de segurança de negócio.
Pense em um exemplo simples: um cliente entra em um aplicativo e pede para consultar a conta 12345. O sistema autentica corretamente o cliente. Ótimo.
Mas o programa valida se aquela conta pertence àquele cliente?
Se não valida, talvez o usuário autenticado consiga consultar uma conta que não deveria. Não é falha de senha. Não é necessariamente falha do RACF. É uma falha de autorização na lógica da aplicação.
Em COBOL, isso aparece em perguntas que deveriam estar no desenho do programa:
este usuário pode executar esta função?
este usuário pode acessar este cliente, contrato ou conta?
a regra de autorização é validada no backend?
o canal web ou API está confiando demais na informação recebida?
há trilha de auditoria para uma consulta sensível?
A autenticação responde: “quem é você?”
A autorização responde: “o que você pode fazer com isso?”
Mr. Robot ficaria muito feliz quando empresas confundem essas duas perguntas. Você, como programador COBOL, deve fazer o contrário.
7. JCL e REXX: o perigo de confundir automação com inocência
JCL é a receita do processamento batch. Ele define programas, datasets, parâmetros, classes, etapas e recursos para o job rodar.
REXX é uma ferramenta fantástica de automação, administração e produtividade. Pode ser o canivete suíço do profissional de z/OS.
Mas uma automação também pode amplificar permissões.
Imagine um job de produção. Ele roda com determinada autoridade, acessa determinados datasets e altera determinados recursos. Agora pergunte:
quem pode alterar o JCL?
quem pode alterar as procedures chamadas por ele?
quem controla os parâmetros?
quem pode promover um membro para produção?
quem pode disparar a execução?
quem revisa as mudanças?
Se quem altera uma entrada aparentemente “inofensiva” consegue influenciar um job poderoso, a segurança não está apenas no programa. Está em toda a cadeia de entrega.
Por isso DevOps em mainframe não é só compilar COBOL pelo VS Code e colocar um pipeline bonito no PowerPoint. É garantir trilha de auditoria, aprovação, separação de funções, controle de versão, promoção segura e rollback.
A regra de ouro é simples:
Nunca entregue a alguém a capacidade de alterar o que será executado com mais autoridade do que essa pessoa possui.
Isso vale para JCL, REXX, procedures, scripts USS, parâmetros CICS e configurações de integração.
8. Exfiltração: o dado não precisa “sumir” para ter sido roubado
Muita gente imagina incidente como arquivos sendo apagados, telas ficando pretas e alguém digitando frases em vermelho. Na vida real, o cenário mais perigoso pode ser silencioso.
Exfiltração é a retirada indevida de dados. Pode ocorrer por um canal aparentemente normal: consulta excessiva, relatório exportado, transferência autorizada, fila, API, arquivo intermediário ou credencial de integração usada fora do padrão.
O desafio da defesa é distinguir o legítimo do anômalo.
Um analista que acessa cem registros por dia pode precisar disso para trabalhar. Mas se passa a acessar milhões de registros, fora de horário, de uma área que nunca utilizou, é hora de investigar.
A ferramenta não deve apenas registrar que “o acesso aconteceu”. Ela deve ajudar a responder:
quem acessou?
a que recurso?
quando?
de onde?
com qual resultado?
isso é compatível com o comportamento esperado?
houve alteração de privilégio antes do evento?
houve tentativa de acesso negada antes do acesso aprovado?
É aqui que entra o SMF, o diário de bordo do z/OS.
9. SMF: as câmeras de segurança do prédio
SMF, System Management Facilities, coleta registros importantes sobre a atividade do sistema. Para segurança, os eventos RACF são particularmente valiosos.
Se alguém erra várias autenticações, recebe acessos negados, tenta recursos incomuns, altera perfis, muda privilégios ou usa uma identidade em padrão estranho, o sistema pode deixar rastros.
Mas rastros que ninguém analisa são como uma câmera de segurança desligada: tecnicamente ela está lá; operacionalmente, ela não ajuda muito.
Uma defesa madura integra eventos de RACF, CICS, USS, rede e operação a um processo de monitoramento. Pode ser um SIEM, uma plataforma de análise, uma equipe SOC ou uma rotina bem desenhada de auditoria. O nome da ferramenta importa menos do que a capacidade de enxergar correlação.
Por exemplo:
falhas repetidas de login;
uma conta bloqueada e reativada;
inclusão inesperada em grupo privilegiado;
acesso a dataset fora do perfil normal;
execução de job incomum;
atividade em horário atípico;
mudança de parâmetros seguida de processamento crítico.
Um evento isolado pode ser erro humano. Uma sequência coerente pode ser um incidente começando.
Easter egg para quem vive de mainframe: o verdadeiro “detetive particular” não é o painel ISPF. É o profissional que consegue olhar uma porção de SMF e perguntar: “por que esse userid apareceu aqui?”
10. O checklist do programador COBOL que quer dormir tranquilo
Você não precisa virar Red Teamer para escrever COBOL mais seguro. Mas precisa pensar como alguém que respeita fronteiras.
Antes de colocar uma função em produção, pergunte:
Quem pode chamar este programa ou transação?
A aplicação confere autorização de negócio, não apenas login?
Quais datasets, tabelas e recursos ela acessa?
Esses acessos são mínimos?
Dados sensíveis aparecem em logs, telas ou relatórios sem necessidade?
Há validação de entradas?
Erros revelam informação técnica demais?
O JCL, PROCs e parâmetros que cercam o programa estão protegidos?
Há auditoria de acessos e alterações?
Se a conta que chama o programa for comprometida, qual é o pior cenário?
Esse último item é ouro.
Segurança não é prometer que nada dará errado. É desenhar o sistema para que, quando algo der errado, o dano seja limitado, detectável e recuperável.
Epílogo — o terminal não é frágil, mas precisa de gente acordada
O maior equívoco sobre segurança em IBM Z é imaginar dois extremos.
De um lado, há quem diga: “mainframe é inviolável”. Não é.
Do outro, há quem diga: “qualquer terminal verde é uma bomba-relógio”. Também não é.
A verdade é muito mais madura: IBM Z oferece controles extraordinariamente sólidos, mas eles dependem de configuração, disciplina, revisão, segregação de funções, observabilidade e pessoas que entendam tanto o negócio quanto a tecnologia.
O Red Team mostra caminhos possíveis. O Blue Team detecta e bloqueia. O Purple Team transforma esse encontro em aprendizado. E o programador COBOL participa de tudo isso, porque a segurança de uma transação não termina quando o COMMIT retorna com sucesso.
Ela começa no requisito, passa pela lógica de autorização, pelos datasets, pelo RACF, pelo CICS, pelo JCL, pelo USS, pelos logs e pelo time que terá de explicar o incidente caso alguém tenha encontrado uma porta aberta.
Elliot Alderson provavelmente olharia para o painel do ISPF, respiraria fundo e diria:
“Controle de acesso não é segurança se ninguém sabe quem recebeu a chave.”
No Bellacosa Mainframe, a tradução é mais direta:
“Se o RACF liberou, o sistema obedeceu. Antes de culpar o mainframe, descubra quem deixou a chave em
PROD.”
Porque o verdadeiro hacker não é o sujeito de capuz. Às vezes é a pressa, o privilégio acumulado, a exceção que virou regra e aquele famoso aviso que ficou pendente “só até a próxima janela”.
E nós sabemos como termina esse “só até depois”.
Com café, incidente, reunião, planilha e alguém perguntando quem foi que aprovou aquilo em 2014.
Sem comentários:
Enviar um comentário