 |
| Bellacosa Mainframe e uma pequena historia sobre o tcp/ip sna e protocolos de rede no mundo mainframe e alem |
☕ Um Café no Bellacosa Mainframe
IBM Z Mainframe Security — 33 Anos de TCP/IP e o Dia em que Igor Instalou uma Porta para a Internet no Castelo
Ou: o IBM Z continuou sendo um dos cofres mais sofisticados do planeta, mas alguém conectou Ethernet, TN3270, FTP, UNIX, APIs REST e pipelines DevOps — enquanto Igor jurava que UID(0) era apenas o número do crachá do laboratório
Prólogo — Igor, conecte o cabo. Qual cabo, doutor?
Imagine a seguinte cena.
Estamos em 1991. O datacenter está mergulhado naquela penumbra respeitável das grandes instalações. Há unidades de fita, controladoras, canais, terminais 3270, operadores carregando cartuchos 3480 e um mainframe processando a folha de pagamento de milhares de pessoas sem precisar reiniciar toda terça-feira.
No centro do laboratório, protegido por SNA, VTAM, controladoras, LUs e uma quantidade de siglas suficiente para assustar até um auditor, encontra-se o IBM Mainframe.
— Igor! — grita o doutor. — Precisamos conectar o RS/6000 ao mainframe!
— Excelente ideia, mestre! Trouxe um cabo Ethernet, um controlador 3172 e este livrinho sobre uma coisa chamada TCP/IP!
— Igor… de onde veio esse TCP/IP?
— Estava numa caixa marcada “Abby Normal Networking”.
O raio cai.
As luzes piscam.
O controlador 3172 desperta.
E, naquele instante simbólico, o mainframe deixa de conversar apenas dentro de seu universo proprietário e passa a participar de uma rede baseada nos mesmos protocolos usados por estações UNIX, servidores, computadores pessoais e, futuramente, pela Internet.
O monstro abre os olhos.
— Está vivo!
Sim, estava vivo. E agora tinha endereço IP.
Essa é a história dos aproximadamente 35 anos de convivência entre TCP/IP e IBM Z. Não é uma história sobre o TCP/IP ter destruído a segurança do mainframe. É a história de como um ambiente extremamente especializado ganhou os benefícios — e também os riscos — de participar de uma rede universal.
A grande conclusão pode ser colocada dentro da WORKING-STORAGE:
01 SEGURANCA-DO-MAINFRAME.
05 PLATAFORMA-SECURAVEL PIC X(03) VALUE 'SIM'.
05 AMBIENTE-SEGURO PIC X(07) VALUE 'DEPENDE'.
O IBM Z é uma plataforma extraordinariamente securável.
Mas “securável” não é sinônimo de “segura”.
1. Securável não significa automaticamente segura
Quando alguém afirma que o IBM Z é uma das plataformas mais seguras do mundo, existe uma boa razão.
Ao longo de décadas, a arquitetura acumulou mecanismos como:
isolamento por LPAR;
proteção de memória;
níveis de autorização;
RACF, ACF2 ou Top Secret;
System Authorization Facility, o SAF;
registros SMF;
separação entre usuários, grupos e processos;
criptografia em hardware;
gerenciamento de certificados;
proteção de bibliotecas autorizadas;
controle de datasets;
controle de comandos;
auditoria de acessos;
segurança para CICS, IMS, Db2, MQ e USS;
IP filtering;
IPsec;
AT-TLS;
zERT;
controle de portas;
detecção de intrusão.
É um belo laboratório.
O problema começa quando Igor encontra uma configuração difícil e resolve aplicar o método científico conhecido como:
“Dê autoridade total, faça funcionar e depois a gente revisa.”
O “depois” geralmente ocorre quinze anos mais tarde, durante uma auditoria, quando ninguém mais se lembra por que uma started task precisa de UID(0), acesso ALTER a uma árvore inteira de datasets e permissão para usar uma porta que oficialmente foi desativada em 2007.
A diferença é simples:
Securável é aquilo que a plataforma permite fazer.
Seguro é aquilo que a organização realmente configurou, monitorou, testou e manteve.
Um cofre pode possuir aço reforçado, sensores, câmeras e fechadura biométrica. Se alguém deixar a porta aberta porque o fornecedor precisava entregar café, a resistência do aço deixa de ser a questão principal.
2. Antes do TCP/IP: o castelo protegido por SNA
Para o programador COBOL iniciante, SNA pode parecer uma criatura encontrada nos porões do museu da IBM.
SNA significa Systems Network Architecture. Durante muitos anos, foi o grande modelo de comunicação dos ambientes IBM.
Nele apareciam conceitos como:
VTAM;
unidades físicas;
unidades lógicas;
LUs;
sessões;
BIND;
controladores;
subáreas;
APPN;
LU 6.2;
terminais 3270.
Não era uma arquitetura simples para um desconhecido.
Para alcançar uma aplicação, não bastava perguntar:
Qual é o endereço IP?
Qual é a porta?
Era necessário conhecer uma topologia e um conjunto de protocolos muito específicos do universo IBM.
Isso criava uma barreira natural. Um invasor familiarizado apenas com PCs, DOS ou UNIX podia olhar para aquele ambiente como Igor olhando para uma JCL de cinquenta passos:
— Doutor, tenho certeza de que isto faz alguma coisa, mas não pretendo encostar.
Entretanto, não devemos romantizar essa barreira.
SNA não era segura apenas porque poucas pessoas a conheciam. Obscuridade pode aumentar o esforço necessário para um ataque, mas não substitui autenticação, autorização, criptografia, segmentação e monitoramento.
O castelo era difícil de compreender. Isso não significa que suas muralhas não precisassem ser inspecionadas.
Curiosidade de laboratório
Muitas transações bancárias e corporativas que o consumidor executava sem pensar — inclusive operações em terminais e caixas eletrônicos — passavam por uma infraestrutura baseada em tecnologias IBM, CICS, IMS, VTAM e SNA.
Contudo, seria exagerado dizer que SNA é simplesmente “o protocolo de transação do CICS e do IMS”. Esses subsistemas evoluíram e suportam diferentes formas de comunicação. Hoje podem conversar por TCP/IP, MQ, APIs, conectores e diversas outras interfaces.
O monstro recebeu novos braços. Ele não precisou arrancar os antigos.
3. O controlador 3172 e a nova avenida até o mainframe
No início da década de 1990, empresas começaram a integrar seus mainframes com estações RS/6000 executando AIX e outras máquinas presentes em redes locais.
Um dos equipamentos importantes nessa transição foi o IBM 3172 Interconnect Controller.
Pense nele como um tradutor instalado na entrada do castelo. De um lado, o universo dos canais e do mainframe. Do outro, Ethernet, Token Ring, FDDI e os protocolos que circulavam pela rede corporativa.
O benefício era gigantesco:
integração entre plataformas;
transferência de arquivos;
acesso remoto;
compartilhamento de recursos;
comunicação com UNIX;
substituição progressiva de terminais físicos por emuladores;
utilização de padrões abertos.
Mas a consequência arquitetônica era igualmente importante:
Do ponto de vista da rede, o mainframe agora era um nó IP.
Isso não significa que ele tenha perdido sua arquitetura interna. LPAR, SAF, RACF e proteção de memória continuavam existindo.
Significa que agora havia uma avenida padronizada chegando até ele.
Um endereço IP pode representar:
uma interface;
um serviço;
uma rota;
uma possibilidade de administração;
uma dependência;
uma entrada;
uma saída;
uma superfície de ataque.
O protocolo não é culpado. A questão é quem consegue alcançar o endereço, quais portas estão disponíveis, que serviços escutam nessas portas e como esses serviços foram protegidos.
4. TN3270: o terminal verde mudou de roupa
Antes, era comum encontrar terminais 3270 físicos ligados à infraestrutura IBM.
Com o TN3270, um computador pessoal passou a executar um emulador de terminal e estabelecer uma conexão sobre TCP/IP.
Para o usuário, o resultado parecia familiar: a velha tela verde.
Por baixo do capô, porém, o caminho havia mudado.
De maneira simplificada:
O computador abre uma conexão TCP.
O cliente e o servidor negociam TN3270 ou TN3270E.
O servidor Telnet do z/OS recebe a sessão.
Uma LU pode ser selecionada ou associada.
O VTAM conduz a sessão até uma aplicação.
O usuário encontra TSO, CICS ou outro destino.
SAF e o gerenciador de segurança participam da autenticação e autorização.
Portanto, TN3270 não simplesmente matou SNA.
Em muitos cenários, TCP/IP passou a levar o usuário até uma fronteira na qual VTAM e os conceitos 3270 continuavam trabalhando.
É como substituir a estrada de terra até o castelo por uma rodovia asfaltada. O salão interno continua o mesmo, mas muito mais gente conhece o caminho até a portaria.
O perigo do terminal sem proteção
Considere um ambiente antigo:
TN3270 disponível numa rede extensa;
ausência de TLS;
tela de logon identificando claramente a organização;
mensagens diferentes para usuário válido e inválido;
IDs antigos ainda ativos;
pouca correlação entre tentativas de acesso;
emuladores sem controle;
credenciais reutilizadas.
Um atacante não precisa “quebrar o mainframe”. Ele pode capturar uma credencial antes de ela chegar ao RACF.
Depois, quando fizer logon, o sistema verá uma identidade aparentemente legítima.
O RACF terá feito seu trabalho corretamente. Quem falhou foi o caminho anterior à catraca.
Como proteger TN3270
Uma implementação moderna deve considerar:
TLS obrigatório;
protocolos e cifras atualizados;
certificados corretamente administrados;
limitação das redes de origem;
associação controlada de LUs;
restrição das aplicações disponíveis;
autenticação baseada em SAF;
certificados de cliente quando apropriado;
limitação de tentativas;
monitoramento dos registros;
mensagens que não facilitem enumeração de usuários;
MFA ou mecanismos equivalentes onde a arquitetura permitir.
Eis o primeiro princípio de Igor:
Uma tela verde não fica invisível apenas porque combina com a parede do laboratório.
5. OpenEdition, OMVS e o UNIX escondido no porão
A chegada do TCP/IP coincidiu com outra transformação importante: a introdução de um ambiente compatível com POSIX no sistema operacional.
Primeiro veio OpenEdition MVS. Depois, esse universo evoluiu para aquilo que hoje chamamos de z/OS UNIX System Services, ou USS.
O sysprog acostumado com:
datasets;
catálogos;
PDS e PDSE;
JCL;
TSO;
RACF;
comandos MVS;
passou a precisar entender:
diretórios;
arquivos;
proprietário;
grupo;
permissões;
UID;
GID;
processos;
shells;
daemons;
links simbólicos;
sockets;
sistemas de arquivos HFS e posteriormente zFS;
variáveis de ambiente.
Foi como encontrar uma escada atrás do painel do ISPF e descobrir que existia um UNIX inteiro morando no porão.
— Igor, por que há um diretório /etc dentro do mainframe?
— Não sei, doutor. Mas encontrei também /var, /tmp e uma criatura chamada inetd.
O problema não era apenas técnico. Era cultural.
Muitos profissionais dominavam profundamente MVS, JES2, VTAM, CICS e storage, mas não tinham sido formados em UNIX. Outros especialistas conheciam UNIX e TCP/IP, mas não compreendiam RACF, APF, SAF, subsistemas ou integridade do z/OS.
O risco crescia justamente no espaço entre as equipes.
6. A dupla identidade: RACF encontra UID e GID
No ambiente tradicional, um usuário possui uma identidade conhecida pelo gerenciador de segurança:
BELLACO
Quando esse usuário também precisa utilizar USS, seu perfil recebe um segmento OMVS contendo informações como:
UID
GID
HOME
PROGRAM
Assim, o mesmo indivíduo passa a existir nos dois mundos.
No universo z/OS tradicional, sua autoridade é controlada por perfis, classes, grupos e permissões do ESM.
No universo UNIX, entram também:
proprietário;
grupo;
bits de permissão;
ACLs;
UID;
GID;
perfis da classe UNIXPRIV;
recursos BPX;
controle de programas.
Isso não significa que USS seja um sistema separado abandonado no porão. A segurança UNIX é integrada ao SAF e ao gerenciador de segurança.
Mas essa integração só funciona adequadamente se for configurada e compreendida.
Exemplo para o COBOLzeiro
Imagine um programa COBOL que precisa ler um arquivo no USS.
Não basta considerar apenas:
O usuário tem acesso ao dataset?
Agora é necessário verificar:
quem é o proprietário do arquivo;
qual é o grupo;
quais permissões estão ativas;
se existe ACL;
qual UID executa o processo;
como a aplicação foi iniciada;
se há privilégios adicionais;
se o caminho inteiro até o arquivo permite acesso;
se um link simbólico pode redirecionar a operação.
É uma segunda árvore de decisões de segurança.
7. UID(0): a chave mestra encontrada no bolso de Igor
No UNIX, UID 0 representa o superusuário.
Ele possui uma capacidade extraordinária dentro do ambiente USS.
Não é tecnicamente idêntico a conceder SPECIAL no RACF, pois os domínios são diferentes. Entretanto, a comparação ajuda o iniciante a compreender o tamanho do risco.
Durante décadas, alguns procedimentos de instalação disseram:
“Defina a started task com UID(0).”
Em certos casos, isso podia ser tecnicamente necessário. Em outros, era apenas uma forma rápida de evitar o trabalho de descobrir quais privilégios específicos o produto realmente exigia.
O fluxo era conhecido:
O software falhava durante a instalação.
O fornecedor dizia que faltava autoridade.
Alguém atribuía UID(0).
O produto funcionava.
A mudança entrava em produção.
A revisão ficava para depois.
Quinze anos mais tarde, ninguém sabia remover o privilégio.
É o famoso padrão PERFORM ATE-QUE-FUNCIONE.
O z/OS oferece mecanismos mais granulares, incluindo perfis como:
BPX.SUPERUSER;BPX.DAEMON;BPX.SERVER;recursos da classe
UNIXPRIV;program control;
permissões específicas de filesystem.
A solução correta deve ser determinada conforme o produto e a função necessária.
O princípio é o menor privilégio:
Se o processo precisa abrir uma porta, não lhe dê autoridade para ressuscitar todos os mortos do cemitério.
Dica prática
Crie um inventário contendo:
todos os usuários com UID(0);
justificativa;
produto responsável;
proprietário técnico;
documentação do fornecedor;
alternativa granular disponível;
data da última revisão;
plano de remoção ou aceitação formal do risco.
Se ninguém souber explicar por que o privilégio existe, ele já merece investigação.
8. TCP/IP não enfraqueceu o mainframe: ampliou a superfície
É tentador dizer que a chegada do TCP/IP aumentou “exponencialmente” a probabilidade de ataque.
A ideia geral faz sentido, mas a palavra “exponencialmente” exigiria evidência matemática. O que podemos afirmar com segurança é que TCP/IP produziu três mudanças fundamentais.
8.1 Padronização
Atacantes e administradores conhecem:
TCP;
UDP;
portas;
DNS;
FTP;
Telnet;
SSH;
HTTP;
TLS;
APIs.
Já não é necessário dominar toda a arquitetura SNA para começar a reconhecer o ambiente.
8.2 Alcance
Um terminal físico tinha localização e conexão relativamente previsíveis.
Uma porta TCP pode ser alcançada por:
outra VLAN;
uma VPN;
um parceiro;
um servidor comprometido;
uma estação administrativa;
uma nuvem;
uma conexão de contingência;
ou, por erro de configuração, pela Internet.
8.3 Multiplicação de serviços
O assunto deixou de ser apenas TN3270.
Hoje o IBM Z pode oferecer ou consumir:
FTP e FTPS;
SSH e SFTP;
DNS;
SMTP;
SNMP;
NFS;
MQ;
APIs REST;
z/OSMF;
Zowe;
z/OS Connect;
servidores Java;
bancos de dados;
agentes de monitoramento;
serviços DevOps;
integrações com cloud e OpenShift.
Cada serviço traz:
uma porta;
uma identidade;
uma configuração;
certificados;
bibliotecas;
logs;
dependências;
vulnerabilidades;
um ciclo de atualização.
9. As sete portas do castelo
Para compreender segurança TCP/IP no z/OS, pense em sete camadas.
Porta 1 — Alcance de rede
Quem consegue chegar ao endereço?
Aqui entram:
firewalls;
VLANs;
roteamento;
VPN;
segmentação;
redes administrativas;
zonas de segurança;
controle de entrada e saída.
Se um serviço é usado apenas pela equipe interna, não deveria estar acessível a uma rede muito maior que a necessária.
Porta 2 — A pilha TCP/IP
O que a stack aceitará?
O z/OS Communications Server oferece controles como:
IP filtering;
IPsec;
múltiplas stacks;
políticas;
IDS;
restrições por interface;
controle de roteamento;
proteção de VIPAs.
Porta 3 — A porta propriamente dita
Qual processo pode abrir ou usar determinado número de porta?
As definições PORT e PORTRANGE, junto aos controles SAF, ajudam a reservar portas para aplicações e identidades específicas.
Imagine que a porta 5000 pertença à started task PAGADOR.
Sem reserva apropriada, outro processo poderia tentar ocupar a porta quando o serviço legítimo estivesse parado.
Com controle adequado, a stack sabe que aquela porta pertence ao serviço autorizado.
Porta 4 — O transporte
Os dados viajam protegidos?
Aqui entram:
TLS;
AT-TLS;
SSH;
IPsec;
certificados;
algoritmos;
key rings.
Uma conexão autenticada, mas transmitida em claro, ainda pode expor credenciais e informações.
Porta 5 — A identidade
Quem é o usuário ou processo?
Aqui trabalham:
SAF;
RACF;
ACF2;
Top Secret;
certificados;
IDs técnicos;
grupos;
perfis;
passphrases;
autenticação multifator.
Porta 6 — A aplicação
Mesmo autenticado, o que o usuário pode fazer?
É nesse ponto que entram:
transações CICS;
comandos;
recursos Db2;
filas MQ;
APIs;
datasets;
funções administrativas;
regras de negócio.
Autenticação responde “quem é você?”. Autorização responde “o que você pode fazer?”. A lógica de negócio ainda precisa responder “esta operação faz sentido?”.
Porta 7 — A evidência
Se algo acontecer, saberemos?
Aqui entram:
SMF;
logs de aplicação;
registros RACF;
SMF 119;
zERT;
SIEM;
alertas;
correlação;
retenção;
investigação.
Um log que ninguém lê é apenas o diário secreto do monstro.
10. SAF também protege a rede
O iniciante frequentemente associa SAF apenas à tentativa de abrir um dataset.
Mas o Communications Server também pode consultar SAF para decisões relacionadas à rede.
A classe SERVAUTH, por exemplo, pode participar de controles associados a:
acesso a redes;
utilização de portas;
serviços;
funções administrativas;
recursos Telnet;
comandos do Communications Server.
Isso permite sair de uma decisão simples:
A porta está aberta?
E chegar a uma decisão mais madura:
Esta identidade está autorizada a utilizar esta função de rede?
A porta não deve ser apenas um número escutando no escuro. Ela deve possuir proprietário, aplicação, identidade, justificativa e monitoramento.
Dica do Igor
Crie uma tabela para cada stack TCP/IP:
| Porta | Serviço | Started task | Criptografia | Origem permitida | Proprietário |
|---|---|---|---|---|---|
| 992 | TN3270 seguro | TN3270 | TLS | Rede corporativa | Infraestrutura |
| 22 | SSH/SFTP | SSHD | SSH | Rede administrativa | Segurança |
| 443 | API | ZOSCONN | TLS | Gateway autorizado | Aplicações |
Se aparecer uma porta que ninguém reconhece, não pergunte primeiro se pode fechá-la.
Pergunte por que uma porta desconhecida conseguiu permanecer aberta.
11. AT-TLS: colocando criptografia sem operar o coração do COBOL
AT-TLS significa Application Transparent Transport Layer Security.
Imagine uma aplicação antiga que utiliza sockets TCP, mas não sabe executar TLS. Alterar seu programa-fonte pode ser caro, arriscado ou demorado.
Com AT-TLS, o Communications Server pode aplicar TLS conforme políticas administradas pelo Policy Agent.
Para a aplicação, a comunicação ainda pode parecer um socket comum. A pilha realiza a negociação criptográfica.
É como se Igor colocasse um casaco blindado no pacote sem precisar modificar o cérebro da criatura.
Mas existe um detalhe importante: o AT-TLS não é magia.
É necessário definir:
qual tráfego será protegido;
origem e destino;
porta;
direção;
protocolos TLS permitidos;
certificados;
key rings;
autenticação do cliente;
comportamento em caso de falha;
registro e monitoramento.
Uma política configurada de maneira errada pode proteger o tráfego errado ou permitir comunicação sem TLS quando a intenção era bloqueá-la.
Por isso, não basta perguntar:
“Temos AT-TLS?”
A pergunta correta é:
“Quais conexões estão realmente protegidas, por qual política, usando qual versão de TLS e qual certificado?”
12. zERT: o inspetor que verifica se o casaco foi realmente vestido
zERT significa z/OS Encryption Readiness Technology.
Ele ajuda a descobrir e registrar atributos criptográficos das conexões.
Isso permite verificar:
se a conexão utilizou criptografia;
qual protocolo foi negociado;
qual versão;
quais algoritmos;
quais características de proteção;
quais fluxos permanecem sem criptografia.
Essa distinção é fundamental.
A documentação da aplicação pode dizer:
TODAS AS CONEXÕES DEVEM USAR TLS.
Mas a realidade pode ser:
97% usam TLS.
2% usam configuração antiga.
1% atravessa o laboratório sem calças.
O zERT ajuda a encontrar esse 1%.
A segurança madura não confia apenas na intenção da configuração. Ela observa o comportamento real.
13. SMF 119: a câmera da portaria
O Communications Server pode produzir registros SMF 119 relacionados a:
início e término de conexões;
estatísticas TCP/IP;
portas;
FTP;
túneis IPsec;
DVIPAs;
TN3270;
informações coletadas pelo zERT.
Com esses registros, a organização pode investigar:
quem se conectou;
quando;
de qual endereço;
em qual porta;
por quanto tempo;
usando qual proteção;
com qual comportamento;
em que volume.
Mas registrar não basta.
O processo ideal é:
Coletar os registros.
Preservá-los.
Normalizá-los.
Enviá-los ao SIEM.
Correlacioná-los com RACF, CICS, Db2, USS e firewall.
Criar alertas úteis.
Investigar os desvios.
Aprender com os incidentes.
Se o atacante fizer mil tentativas de conexão e o registro dormir numa fita até a auditoria anual, o sistema possui evidência, mas não possui defesa operacional.
14. Auditoria, STIG e pentest: os três médicos do monstro
Uma auditoria de segurança continua sendo importante.
Ela verifica políticas, segregação de funções, controles, evidências, conformidade e governança.
As STIGs ajudam a comparar configurações com baselines de endurecimento.
O IBM Health Checker pode examinar configurações ativas e compará-las com recomendações ou políticas definidas pela organização.
O pentest faz outra pergunta:
Um atacante autorizado consegue transformar essas fraquezas em impacto real?
Nenhuma dessas atividades substitui as demais.
Auditoria
Pergunta se o processo e os controles existem e são cumpridos.
Baseline ou STIG
Pergunta se a configuração está alinhada a um padrão seguro.
Vulnerability assessment
Procura vulnerabilidades conhecidas.
Pentest
Tenta explorar caminhos autorizados dentro de um escopo definido.
Purple team
Coloca atacantes e defensores colaborando para melhorar prevenção, detecção e resposta.
Monitoramento contínuo
Pergunta o que mudou depois da última fotografia.
Passar numa auditoria em março não prova que o ambiente continua seguro em agosto.
Segurança não é um JOB que termina com:
IEF142I SECURITY STEP WAS EXECUTED
MAXCC=0000
É uma started task permanente.
15. O atacante também ganhou um emulador
Em 1999, o projeto Hercules tornou possível emular arquiteturas mainframe em computadores comuns.
Seu valor educacional é imenso. Estudantes, pesquisadores e desenvolvedores passaram a experimentar sistemas históricos sem possuir um mainframe físico.
Documentação eletrônica, manuais, fóruns, ferramentas e ambientes de laboratório também reduziram a barreira de entrada.
Isso não significa que Hercules tenha “causado” invasões.
A ferramenta democratizou conhecimento. O mesmo conhecimento pode ser utilizado por:
estudantes;
desenvolvedores;
administradores;
pesquisadores;
pentesters;
atacantes.
O problema começa quando o invasor estuda o ambiente com mais profundidade que a equipe responsável por defendê-lo.
Hoje existem scanners e ferramentas capazes de reconhecer TN3270, identificar telas, testar configurações e auxiliar pesquisas de segurança.
O atacante já não está tateando no escuro.
Ele possui:
documentação;
scripts;
automação;
ambientes de teste;
mecanismos de busca;
inteligência artificial;
décadas de conhecimento acumulado.
Igor já não precisa roubar o manual do laboratório. Ele pode baixá-lo.
16. Três ataques que não precisam “quebrar o mainframe”
Primeiro ataque — roubar a credencial antes do RACF
O usuário conecta-se por um protocolo sem criptografia.
A rede utilizada está comprometida.
A credencial é capturada.
O atacante faz logon.
O RACF reconhece uma identidade válida.
O RACF não foi derrotado. A credencial foi roubada antes da catraca.
Segundo ataque — explorar uma started task privilegiada
Um produto executa com UID(0).
O produto possui uma vulnerabilidade.
O invasor compromete o processo.
A autoridade excessiva amplia o impacto.
A falha do produto torna-se uma falha do ambiente.
Por isso, menor privilégio limita o chamado raio da explosão.
Terceiro ataque — usar corretamente uma API mal protegida
Uma credencial técnica de parceiro é comprometida.
O atacante envia uma requisição formalmente válida.
TLS funciona.
O certificado funciona.
RACF autoriza a conta.
A aplicação não percebe que a transação é fraudulenta.
Tudo funcionou conforme configurado.
Esse é o terror elegante da segurança: controles técnicos corretos podem proteger uma operação de negócio mal concebida.
17. A arqueologia das configurações esquecidas
Os maiores riscos nem sempre foram instalados ontem.
Muitas vezes estão preservados como fósseis:
FTP ativo sem necessidade;
conta genérica sem proprietário;
UID(0) concedido em 1998;
diretório USS com permissão excessiva;
porta liberada para um parceiro que não existe mais;
segunda stack TCP/IP esquecida;
LPAR de contingência menos protegida;
certificado antigo;
started task com autoridade exagerada;
biblioteca APF contendo software desatualizado;
regra de firewall criada “temporariamente”;
usuário de emergência usado no cotidiano.
A longevidade é uma das maiores virtudes do mainframe.
Mas longevidade sem revisão transforma compatibilidade em dívida histórica de segurança.
Dica prática
Para cada exceção, registre:
o que é;
por que existe;
quem é o proprietário;
qual risco produz;
qual sistema depende dela;
quando foi revisada;
quando será removida;
qual controle compensatório existe.
Se a justificativa for “sempre foi assim”, Igor encontrou outro cérebro Abby Normal.
18. Passphrases: o parafuso estava invertido
O texto original afirma que passphrases seriam exponencialmente mais fáceis de quebrar que passwords.
Provavelmente houve uma inversão.
Uma passphrase longa, imprevisível e não reutilizada tende a ser muito mais resistente que uma senha curta.
Compare:
Senha curta:
V@gner12
Com uma frase longa e exclusiva:
Cafe-Lunar-Visita-7-Mainframes-Curiosos
Isso não significa copiar uma frase famosa, uma letra de música ou uma citação encontrada no LinkedIn. Comprimento sem imprevisibilidade pode criar apenas uma senha longa e óbvia.
Também não basta trocar senhas por passphrases e esquecer:
MFA;
bloqueio de credenciais comprometidas;
proteção contra phishing;
monitoração;
gerenciamento de contas;
autenticação por certificados;
passkeys onde aplicáveis.
E nunca devemos expor publicamente as senhas encontradas durante uma auditoria. A equipe pode apresentar padrões, categorias e estatísticas sem constranger usuários nem divulgar credenciais.
O objetivo é ensinar, não realizar um episódio de “Frau Blücher lê as senhas no auditório” — e todos os cavalos do datacenter relincham.
19. Computação quântica: o monstro ainda não comeu toda a criptografia
Existe uma ameaça real chamada harvest now, decrypt later.
Um adversário pode capturar dados criptografados hoje e guardá-los para tentar decifrá-los no futuro, quando computadores quânticos suficientemente poderosos estiverem disponíveis.
Mas isso não significa que toda criptografia desaparecerá de uma vez.
A preocupação principal envolve certos algoritmos de chave pública, como RSA e criptografia baseada em curvas elípticas.
O caminho correto é desenvolver criptoagilidade.
Passo a passo
Inventarie certificados e algoritmos.
Descubra onde RSA e ECC são utilizados.
Identifique dados que precisam permanecer secretos por muitos anos.
Localize protocolos e aplicações difíceis de atualizar.
Avalie fornecedores e parceiros.
Planeje a adoção de algoritmos pós-quânticos.
Teste mecanismos híbridos.
Defina renovação e substituição de certificados.
Considere arquivos e backups conforme sua vida útil e sensibilidade.
Repita o inventário periodicamente.
Não é necessário recriptografar, às cegas, cada cartucho produzido desde o Império Romano.
É necessário saber quais dados continuam sensíveis, quais algoritmos os protegem e quanto tempo essa proteção precisa durar.
20. O honeypot de Igor
A ideia de criar um ambiente isolado para observar tentativas de ataque pode ser útil.
Mas não devemos simplesmente abrir uma porta na Internet ligada à produção e anunciar:
— Igor, veja quem aparece!
Um laboratório, cyber range ou honeypot deve possuir:
autorização formal;
isolamento completo;
nenhuma informação verdadeira;
identidades artificiais;
controle de saída;
monitoramento detalhado;
limites de recursos;
plano de reconstrução;
ausência de rotas confiáveis para produção;
supervisão da equipe de segurança.
O objetivo é estudar o adversário.
Não é oferecer ao adversário um apartamento mobiliado no datacenter.
21. A nova fronteira: APIs, DevOps e nuvem
Em 1991, a discussão principal envolvia Ethernet, RS/6000, TN3270, FTP e UNIX.
Em 2024, a superfície inclui:
z/OSMF;
Zowe;
z/OS Connect;
APIs REST;
OpenSSH;
Git;
VS Code;
pipelines CI/CD;
Ansible;
Python;
Java;
containers;
zCX;
OpenShift;
observabilidade;
integração com cloud;
tokens;
secrets;
identidades de serviço;
cadeia de suprimentos de software.
Agora o risco pode surgir antes mesmo de o módulo chegar ao mainframe.
Uma credencial comprometida no pipeline pode modificar código. Uma extensão maliciosa pode capturar tokens. Um artefato adulterado pode entrar numa biblioteca. Uma API permissiva pode alcançar uma transação legítima por um caminho que os autores originais jamais imaginaram.
Por isso, modernização e segurança não são dois projetos executados em sequência.
Segurança deve estar dentro da modernização:
no desenho;
no código;
no build;
no deploy;
na identidade;
na rede;
nos testes;
nos logs;
na operação.
22. Plano de 90 dias para apertar os parafusos
Dias 1 a 30 — Descobrir
Inventarie todas as stacks TCP/IP.
Liste interfaces, VIPAs e rotas.
Identifique portas abertas.
Relacione cada porta a uma started task.
Localize TN3270, FTP, SSH, APIs e z/OSMF.
Identifique conexões sem criptografia.
Liste usuários com UID(0).
Examine permissões de arquivos críticos no USS.
Localize IDs genéricos e contas sem proprietário.
Verifique quais registros SMF são produzidos.
Dias 31 a 60 — Reduzir
Feche serviços não utilizados.
Restrinja redes de origem.
Revise regras de firewall.
Implemente ou fortaleça TLS e AT-TLS.
Remova UID(0) quando houver alternativa segura.
Corrija permissões USS.
Desative contas órfãs.
Reserve portas para as identidades corretas.
Atualize produtos e correções.
Documente exceções.
Dias 61 a 90 — Provar
Execute uma avaliação de vulnerabilidades.
Realize pentest autorizado.
Teste controles SAF de rede.
Integre SMF ao SIEM.
Crie alertas para tentativas anormais.
Simule credencial comprometida.
Simule abuso de conta técnica.
Teste resposta a incidente.
Verifique se a equipe detectou o exercício.
Registre riscos residuais e responsáveis.
Depois, execute novamente.
Segurança é um ciclo, não um projeto com festa de encerramento.
23. O encontro das gerações
Existe uma oportunidade maravilhosa nessa transformação.
De um lado, está o profissional veterano que conhece:
MVS;
RACF;
VTAM;
JES2;
CICS;
IMS;
canais;
integridade;
operação;
décadas de comportamento do ambiente.
Do outro, está o profissional mais novo que conhece:
Linux;
UNIX;
Python;
redes;
APIs;
VS Code;
containers;
pentest;
SIEM;
automação;
cloud.
Nenhum deles possui sozinho todo o mapa.
O veterano pode enxergar uma autoridade perigosa que o especialista em Linux não compreende.
O profissional moderno pode reconhecer uma exposição TCP/IP que o especialista tradicional nunca aprendeu a procurar.
Quando trabalham juntos, nasce uma equipe realmente poderosa.
O objetivo não é criar “eles contra nós”.
É colocar Gene Wilder, Igor, o COBOLzeiro, o hacker ético, o administrador RACF e o especialista em redes em volta da mesma mesa — preferencialmente antes da tempestade.
Epílogo — Puttin’ on the Ritz sobre TCP/IP
O IBM Z não perdeu sua segurança quando recebeu TCP/IP.
Ele ganhou conectividade.
E conectividade sempre cobra seu preço em superfície de ataque, complexidade, identidade, configuração e monitoramento.
A plataforma continua oferecendo alguns dos mecanismos defensivos mais sofisticados da indústria. Mas nenhum processador, HSM, ESM ou algoritmo consegue proteger sozinho um ambiente no qual:
ninguém revisa as portas;
contas antigas continuam ativas;
FTP transmite dados em claro;
processos executam com UID(0) sem necessidade;
certificados são esquecidos;
logs não são analisados;
exceções temporárias tornam-se permanentes;
a auditoria anual é confundida com segurança contínua.
O atacante não precisa derrotar simultaneamente RACF, SAF, LPAR, criptografia, CICS, Db2, VTAM e toda a arquitetura IBM Z.
Ele precisa encontrar apenas:
uma credencial;
uma porta;
uma configuração;
um produto vulnerável;
uma conta privilegiada;
um parceiro comprometido;
um diretório mal protegido;
um parafuso que Igor esqueceu de apertar.
Por isso, depois de aproximadamente 35 anos de TCP/IP, a pergunta não deve ser:
“O mainframe é seguro?”
A pergunta correta é:
“Nós conseguimos provar, hoje, que cada caminho até o mainframe está identificado, protegido, monitorado e testado?”
Se a resposta for sim, excelente.
Pode chamar a banda.
O mainframe coloca cartola e fraque. Igor sobe no palco. A criatura começa a dançar.
— Puttin’ on the Ritz!
Mas se ninguém souber quem abriu a porta 23, por que determinada started task possui UID(0) ou para onde aquela conexão FTP está enviando arquivos todas as madrugadas…
Bem, companheiro…
Talvez o cérebro instalado no laboratório fosse realmente Abby Normal.
