☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta 12 marcadores — 91 bytes IBM Z. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta 12 marcadores — 91 bytes IBM Z. Mostrar todas as mensagens

domingo, 22 de setembro de 2024

IBM Z Mainframe Security — 33 Anos de TCP/IP e o Dia em que Igor Instalou uma Porta para a Internet no Castelo

 
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:

  1. O computador abre uma conexão TCP.

  2. O cliente e o servidor negociam TN3270 ou TN3270E.

  3. O servidor Telnet do z/OS recebe a sessão.

  4. Uma LU pode ser selecionada ou associada.

  5. O VTAM conduz a sessão até uma aplicação.

  6. O usuário encontra TSO, CICS ou outro destino.

  7. 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:

  1. O software falhava durante a instalação.

  2. O fornecedor dizia que faltava autoridade.

  3. Alguém atribuía UID(0).

  4. O produto funcionava.

  5. A mudança entrava em produção.

  6. A revisão ficava para depois.

  7. 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:

PortaServiçoStarted taskCriptografiaOrigem permitidaProprietário
992TN3270 seguroTN3270TLSRede corporativaInfraestrutura
22SSH/SFTPSSHDSSHRede administrativaSegurança
443APIZOSCONNTLSGateway autorizadoAplicaçõ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 é:

  1. Coletar os registros.

  2. Preservá-los.

  3. Normalizá-los.

  4. Enviá-los ao SIEM.

  5. Correlacioná-los com RACF, CICS, Db2, USS e firewall.

  6. Criar alertas úteis.

  7. Investigar os desvios.

  8. 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

  1. O usuário conecta-se por um protocolo sem criptografia.

  2. A rede utilizada está comprometida.

  3. A credencial é capturada.

  4. O atacante faz logon.

  5. 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

  1. Um produto executa com UID(0).

  2. O produto possui uma vulnerabilidade.

  3. O invasor compromete o processo.

  4. A autoridade excessiva amplia o impacto.

  5. 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

  1. Uma credencial técnica de parceiro é comprometida.

  2. O atacante envia uma requisição formalmente válida.

  3. TLS funciona.

  4. O certificado funciona.

  5. RACF autoriza a conta.

  6. 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

  1. Inventarie certificados e algoritmos.

  2. Descubra onde RSA e ECC são utilizados.

  3. Identifique dados que precisam permanecer secretos por muitos anos.

  4. Localize protocolos e aplicações difíceis de atualizar.

  5. Avalie fornecedores e parceiros.

  6. Planeje a adoção de algoritmos pós-quânticos.

  7. Teste mecanismos híbridos.

  8. Defina renovação e substituição de certificados.

  9. Considere arquivos e backups conforme sua vida útil e sensibilidade.

  10. 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

  1. Inventarie todas as stacks TCP/IP.

  2. Liste interfaces, VIPAs e rotas.

  3. Identifique portas abertas.

  4. Relacione cada porta a uma started task.

  5. Localize TN3270, FTP, SSH, APIs e z/OSMF.

  6. Identifique conexões sem criptografia.

  7. Liste usuários com UID(0).

  8. Examine permissões de arquivos críticos no USS.

  9. Localize IDs genéricos e contas sem proprietário.

  10. Verifique quais registros SMF são produzidos.

Dias 31 a 60 — Reduzir

  1. Feche serviços não utilizados.

  2. Restrinja redes de origem.

  3. Revise regras de firewall.

  4. Implemente ou fortaleça TLS e AT-TLS.

  5. Remova UID(0) quando houver alternativa segura.

  6. Corrija permissões USS.

  7. Desative contas órfãs.

  8. Reserve portas para as identidades corretas.

  9. Atualize produtos e correções.

  10. Documente exceções.

Dias 61 a 90 — Provar

  1. Execute uma avaliação de vulnerabilidades.

  2. Realize pentest autorizado.

  3. Teste controles SAF de rede.

  4. Integre SMF ao SIEM.

  5. Crie alertas para tentativas anormais.

  6. Simule credencial comprometida.

  7. Simule abuso de conta técnica.

  8. Teste resposta a incidente.

  9. Verifique se a equipe detectou o exercício.

  10. 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.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , ,

domingo, 24 de março de 2024

O Mentalista Entra no CPD — O Dia em que Patrick Jane Olhou para um APPLY CHECK e Descobriu Quem Estava Mentindo sobre a PTF

 
Bellacosa Mainframe apresenta o IBM SMP/E

☕ Um Café no Bellacosa Mainframe

O Mentalista Entra no CPD — O Dia em que Patrick Jane Olhou para um APPLY CHECK e Descobriu Quem Estava Mentindo sobre a PTF

Ou: como CSI, Global Zone, Target Zone, Distribution Zone, SYSMOD, FMID, HOLDDATA, HIPER, FIXCAT, RECEIVE, APPLY, ACCEPT, RESTORE e um programador COBOL iniciante descobriram que o SMP/E não lê pensamentos — ele apenas guarda evidências melhor do que todo mundo

São 03:17 da manhã.

Porque, evidentemente, todo problema realmente educativo em mainframe começa às 03:17.

O telefone toca.

Produção está funcionando.

Isso normalmente seria uma boa notícia.

Mas alguém resolve acrescentar:

— Precisamos instalar uma correção urgente.

Na tela aparece uma PTF.

O programador COBOL iniciante olha para aquilo com a mesma expressão de alguém que acabou de descobrir uma porta secreta atrás do PROCEDURE DIVISION.

O System Programmer pergunta:

— Você verificou a HOLDDATA?

Silêncio.

— Executou APPLY CHECK?

Mais silêncio.

— Conhece os requisites?

O silêncio agora já adquiriu status de documentação oficial.

Nesse instante, um homem entra no CPD carregando uma xícara de chá.

Não parece particularmente impressionado com o IBM Z, os monitores, os alertas nem com o fato de metade da equipe estar discutindo se deve ou não aplicar uma manutenção em produção.

Ele olha para a tela durante alguns segundos.

Depois olha para o programador.

— Você não sabe exatamente o que essa PTF faz.

— Como sabe?

— Porque você está olhando para o número dela esperando que ele lhe conte alguma coisa.

Patrick Jane sorri.

O operador franze a testa.

— E você entende de SMP/E?

— Não.

Ele toma um gole do chá.

— Mas entendo quando alguém está tentando tomar uma decisão sem observar as evidências.

Bem-vindo ao SMP/E.

E talvez essa seja uma das melhores maneiras de aprendê-lo.

Porque SMP/E não é essencialmente uma coleção de comandos.

É um sistema construído ao redor de uma obsessão muito parecida com a de um investigador:

nunca confie apenas no que alguém diz que aconteceu; descubra o que realmente aconteceu.


1. A primeira pista: SMP/E não é um instalador de PTF

O iniciante normalmente encontra SMP/E através de frases como:

“Usamos SMP/E para instalar manutenção no z/OS.”

A frase não está propriamente errada.

O problema é que ela é perigosamente incompleta.

Seria como dizer:

“Db2 serve para guardar dados.”

Ou:

“CICS serve para executar COBOL.”

Tecnicamente verdade.

Conceitualmente pobre.

SMP/E significa:

System Modification Program/Extended.

Sua função é administrar software e suas modificações dentro do ambiente z/OS.

Isso significa controlar coisas como:

  • o que está instalado;

  • quais modificações chegaram;

  • quais modificações foram aplicadas;

  • quais foram aceitas;

  • quais componentes foram alterados;

  • quais dependências existem;

  • quais correções substituem outras;

  • quais problemas conhecidos acompanham determinada manutenção;

  • quais alterações locais precisam ser preservadas.

Patrick Jane provavelmente resumiria assim:

“Você pensa que está investigando uma PTF. Na verdade está investigando a história dela.”

E essa história é justamente o que o SMP/E tenta preservar.


2. A cena do crime: software corporativo não permanece parado

Imagine instalar um produto IBM hoje.

Versão limpa.

Tudo documentado.

Tudo lindo.

Agora avance cinco anos.

Centenas de PTFs foram instaladas.

Algumas corrigiram APARs.

Outras foram substituídas posteriormente.

Uma equipe criou USERMODs.

Algumas correções possuem prerequisites.

Outras possuem coexistence requirements.

Uma manutenção crítica chegou depois.

Certos módulos foram modificados várias vezes.

Um novo release entrou no ambiente.

Agora alguém pergunta:

“Qual é exatamente o estado desse software?”

Sem um mecanismo estruturado para responder isso, você teria algo parecido com:

PROD_FINAL
PROD_FINAL2
PROD_FINAL_OK
PROD_FINAL_OK_MESMO
PROD_NAO_MEXER
PROD_ANTES_DA_CORRECAO

Patrick Jane olha para os nomes.

— Quem criou isso?

Ninguém responde.

Ele aponta para PROD_FINAL_OK_MESMO.

— O culpado está aqui.

O velho System Programmer suspira.

— Foi por isso que inventaram SMP/E.


3. CSI — a memória do investigador

Um dos conceitos mais importantes de SMP/E é o:

CSI — Consolidated Software Inventory.

Para o programador COBOL iniciante, vale pensar nele como a memória estruturada do SMP/E.

Não é simplesmente uma biblioteca contendo programas.

É um conjunto de informações que permite ao SMP/E conhecer o estado dos componentes e modificações que administra.

Dentro dessa arquitetura aparecem três conceitos fundamentais:

GLOBAL ZONE

TARGET ZONE

DISTRIBUTION ZONE

E aqui surge um erro comum.

Não pense:

GLOBAL = desenvolvimento

TARGET = homologação

DISTRIBUTION = produção

Não.

Essas zonas têm outra função.

Patrick Jane pega três cartões e coloca sobre uma mesa.

No primeiro escreve:

GLOBAL

No segundo:

TARGET

No terceiro:

DISTRIBUTION

— Não são lugares — diz ele. — São perspectivas diferentes sobre o mesmo caso.

É uma excelente maneira de pensar.


4. Global Zone — o arquivo geral do caso

A Global Zone contém informações administrativas de alcance global dentro daquele ambiente SMP/E.

É onde o SMP/E mantém conhecimento importante sobre material recebido e sobre as zonas que administra.

Podemos simplificar:

               GLOBAL
                  |
        +---------+---------+
        |                   |
     TARGET            DISTRIBUTION

A Global Zone funciona como uma espécie de índice administrativo da investigação.

Ela sabe que determinadas coisas existem.

Mas isso ainda não significa que estejam executando.

Essa diferença será fundamental quando chegarmos ao RECEIVE.

5. Target Zone — onde a modificação entra em jogo

A Target Zone representa informações relacionadas ao software instalado nas Target Libraries.

Esse é o ambiente utilizado para execução.

Quando determinada manutenção é aplicada, é ali que encontramos o estado correspondente ao software modificado para utilização.

Uma representação didática:

TARGET ZONE
    |
    v
TARGET LIBRARIES
    |
    v
SOFTWARE UTILIZADO

O iniciante normalmente chega aqui e pensa:

“Então APPLY coloca a correção no sistema?”

De maneira simplificada, sim.

Mas existe um mundo inteiro entre receber uma PTF e chegar a esse ponto.

E é exatamente aí que mora a diferença entre um profissional cuidadoso e alguém que acredita que manutenção consiste em copiar arquivos.

6. Distribution Zone — a referência controlada

A Distribution Zone representa as informações relacionadas às Distribution Libraries.

Essas bibliotecas funcionam como uma referência de distribuição controlada pelo SMP/E.

Quando ocorre ACCEPT, a manutenção correspondente é incorporada nesse universo.

Portanto temos uma ideia importante:

TARGET
   !=
DISTRIBUTION

E essa diferença explica por que:

APPLY

não significa a mesma coisa que:

ACCEPT

Voltaremos a isso.

Patrick Jane observa o programador anotando.

— Está começando a perceber.

— O quê?

— Que SMP/E não pensa em “arquivo novo” e “arquivo velho”. Ele pensa em estado.

Exatamente.

7. SYSMOD — o suspeito finalmente tem nome

No universo SMP/E encontramos SYSMODs.

System Modifications.

Eles representam modificações administradas pelo SMP/E.

Entre as categorias fundamentais encontramos:

FUNCTION
PTF
APAR
USERMOD

Aqui existe uma distinção importante.

O infográfico que originou nossa investigação apresentava também FMID próximo desses conceitos.

Mas FMID não deve ser entendido simplesmente como uma quinta categoria equivalente.

FMID — Function Modification Identifier identifica uma função/produto dentro desse ecossistema.

Enquanto FUNCTION, PTF, APAR e USERMOD descrevem tipos fundamentais de SYSMOD, FMID ajuda a estabelecer a qual função determinada manutenção está relacionada.

Parece detalhe.

Não é.

Mainframe é uma plataforma na qual detalhes aparentemente burocráticos frequentemente determinam se você sabe o que está modificando.

8. FUNCTION — quando uma função entra no universo SMP/E

Uma FUNCTION SYSMOD introduz uma função no ambiente controlado pelo SMP/E.

Pode representar a base de determinado produto ou funcionalidade.

Pense nisso como o primeiro capítulo do prontuário.

Depois dela chegam modificações.

9. APAR e PTF — problema e solução não são exatamente a mesma coisa

Outro erro comum é usar APAR e PTF como sinônimos.

APAR significa:

Authorized Program Analysis Report.

Ele está relacionado à identificação e tratamento formal de um problema.

A correção correspondente pode posteriormente ser disponibilizada como uma PTF — Program Temporary Fix.

Didaticamente:

problema identificado
        |
        v
      APAR
        |
        v
solução distribuída
        |
        v
       PTF

A realidade pode envolver nuances adicionais, mas para o iniciante essa separação já evita muita confusão.

Patrick Jane ergue a sobrancelha.

— Então APAR é o crime e PTF é o policial?

O System Programmer pensa alguns segundos.

— Não exatamente.

— Melhor ainda. Significa que você está aprendendo.

10. USERMOD — quando sua própria empresa entra na história

Agora temos algo particularmente interessante:

USERMOD.

Imagine que a instalação precise modificar um elemento fornecido pelo produto.

Poderia simplesmente alterar uma library diretamente.

Funcionaria.

Por algum tempo.

Até chegar uma PTF que modifica exatamente o mesmo elemento.

Agora você possui:

IBM modification
       +
local modification
       +
nova manutenção

Quem vence?

Quem sabe o que aconteceu?

Quem preservou documentação?

SMP/E permite registrar modificações locais através de USERMODs.

Isso transforma uma alteração invisível em algo administrável.

É uma mudança filosófica enorme.

Não é:

“Mexemos no módulo.”

É:

“Existe uma modificação local formalmente conhecida pelo sistema de gerenciamento.”

Patrick Jane sorri.

— Finalmente alguém deixou impressões digitais.

11. Dependências — ninguém trabalha sozinho

Aqui SMP/E começa a ficar realmente fascinante.

Imagine:

PTF A
 |
 +---- requires PTF B
 |
 +---- requires PTF C
            |
            +---- requires PTF D

Agora imagine centenas disso.

Uma PTF pode depender de outra.

Uma correção pode superseder outra.

Uma USERMOD pode entrar em conflito com manutenção nova.

Determinados requisites precisam ser satisfeitos antes que uma alteração possa ser instalada corretamente.

Isso transforma o conjunto de manutenção em um verdadeiro grafo de dependências.

Se você conhece:

  • npm;

  • Maven;

  • Gradle;

  • pip;

  • apt;

  • dnf;

o problema conceitual deveria parecer familiar.

O mainframe já enfrentava isso muito antes de dependency management virar assunto cotidiano no desenvolvimento moderno.

12. RECEIVE — a evidência chegou à delegacia

Agora chegamos ao primeiro dos comandos famosos.

RECEIVE

O iniciante costuma pensar:

“RECEIVE instala a PTF.”

Não.

RECEIVE significa que o material entra formalmente no domínio controlado pelo SMP/E.

Imagine uma delegacia recebendo uma caixa de evidências.

A caixa chegou.

Foi registrada.

Foi identificada.

Foi armazenada.

Mas ninguém apresentou aquilo ao tribunal ainda.

Isso é RECEIVE.

Podemos usar uma analogia simples:

RECEIVE = chegou ao almoxarifado

APPLY   = foi instalado

ACCEPT  = virou parte consolidada da referência

Essa analogia é imperfeita.

Mas é excelente pedagogicamente.

13. O MCS — a ficha que acompanha a modificação

Agora surge um elemento delicioso para quem gosta da arqueologia elegante do mainframe:

Modification Control Statements — MCS.

Você pode encontrar estruturas com elementos como:

++PTF(...)
++VER(...)
++MOD(...)

Os dois sinais de mais parecem ter sido projetados deliberadamente para assustar programadores Java.

Mas eles têm função.

Essas statements descrevem ao SMP/E informações necessárias para compreender aquela modificação.

Qual é?

A qual função pertence?

O que modifica?

Quais elementos estão envolvidos?

Quais relações existem?

Em outras palavras:

o código é o corpo da evidência; MCS é a documentação forense.

14. HOLDDATA — Patrick Jane encontra a informação que todos ignoraram

Voltamos ao incidente das 03:17.

Existe uma PTF.

Alguém diz:

— Precisamos instalar imediatamente.

Jane pergunta:

— Existe HOLDDATA?

Silêncio.

Aqui está um dos conceitos mais importantes da trilha inteira.

HOLDDATA contém informações que podem indicar que determinado SYSMOD possui condições que precisam ser conhecidas antes de seu processamento.

Isto pode significar:

“Há um problema conhecido.”

“Existe uma ação necessária.”

“Leia antes de continuar.”

O programador iniciante pergunta:

— Então é como um alerta?

Sim.

Mas é melhor pensar como inteligência operacional associada à manutenção.

A PTF diz:

“Eu existo.”

A HOLDDATA pergunta:

“Você sabe no que está se metendo?”

15. ERROR HOLD — existe problema conhecido aqui

Uma categoria importante envolve ERROR HOLD.

Ela pode indicar problema conhecido relacionado àquela manutenção.

Isso é extraordinariamente importante.

Imagine instalar uma correção destinada a resolver um problema e introduzir outro já conhecido.

Sem informação adequada:

surpresa.

Com HOLDDATA:

decisão consciente.

Existe uma diferença imensa entre as duas coisas.

16. HIPER — quando nem toda PTF merece a mesma prioridade

Outro conceito importantíssimo é:

HIPER — High Impact or PERvasive.

Certos problemas possuem impacto suficientemente importante para receber classificação especial.

E aqui SMP/E passa de simples instalação para gestão de risco.

Imagine 800 PTFs disponíveis.

O administrador não precisa apenas perguntar:

“Quais existem?”

Ele precisa perguntar:

“Quais realmente importam para o meu ambiente?”

É aí que metadata de manutenção torna-se extremamente valiosa.

17. FIXCAT — manutenção com contexto

Outro recurso importante é FIXCAT.

Fix Categories.

A ideia é associar determinadas correções a categorias relevantes.

Isso ajuda a responder perguntas muito melhores.

Em vez de:

“Quais PTFs ainda não instalei?”

podemos nos aproximar de:

“Quais correções estão relacionadas àquilo que estou tentando fazer?”

Essa mudança parece pequena.

Mas representa a transição de inventário para inteligência de manutenção.

18. APPLY CHECK — o momento Mentalista do SMP/E

Chegamos ao meu comando favorito para ensinar a iniciantes:

APPLY CHECK

Por quê?

Porque ele contém praticamente toda uma filosofia operacional.

Você está dizendo:

“SMP/E, diga-me o que aconteceria se eu executasse esta instalação.”

Mas ainda não está efetivamente aplicando aquela manutenção.

No universo moderno chamaríamos isso facilmente de:

dry-run

Patrick Jane apontaria para a tela:

— Está vendo?

— O quê?

— Você não precisa esperar o crime acontecer para procurar pistas.

É exatamente isso.

Antes de APPLY, você pode analisar.

Dependências.

HOLDs.

Requisites.

Condições.

Mensagens.

Resultados.

E somente depois tomar a decisão.

19. Nunca ignore as mensagens

O iniciante frequentemente procura apenas:

RC=00

Se recebeu zero, comemora.

Se recebeu oito, entra em pânico.

Esse comportamento precisa morrer cedo.

Troubleshooting de SMP/E exige observar:

  • mensagens;

  • sequence of events;

  • SYSMODs envolvidos;

  • requisites;

  • HOLDs;

  • zonas;

  • bibliotecas;

  • return codes;

  • relatórios.

Mensagens começando por:

GIM...

fazem parte do idioma operacional do SMP/E.

O System Programmer experiente não pergunta apenas:

“Qual foi o RC?”

Pergunta:

“O que o job realmente informou?”

Patrick Jane aprovaria.

Porque investigadores ruins procuram confissões.

Investigadores bons procuram contexto.

20. APPLY — agora sim mexemos no ambiente

Depois de receber, analisar HOLDDATA, verificar dependências e executar CHECK, chegamos a:

APPLY

Agora a manutenção é instalada em relação ao Target.

Aqui o nível de responsabilidade muda.

Antes estávamos preparando evidência.

Agora estamos alterando o estado do software utilizado.

Por isso o processo deveria parecer algo como:

RECEIVE
   |
   v
HOLDDATA
   |
   v
APPLY CHECK
   |
   v
ANALYSIS
   |
   v
APPLY

Nunca:

baixou
  |
  v
APPLY
  |
  v
rezar

Embora algumas empresas aparentemente tenham adotado o segundo método durante certas décadas.

21. Testar é parte da manutenção

Após APPLY existe uma janela preciosa.

APPLY
  |
  v
TARGET
  |
  v
TEST

Isso deveria fazer parte explicitamente da mentalidade do iniciante.

Software alterado precisa ser validado.

O fato de SMP/E concluir uma operação não significa automaticamente:

“Sua aplicação de negócio está perfeita.”

SMP/E administra manutenção.

Seu ambiente precisa verificar comportamento.

Testes técnicos.

Testes funcionais.

Smoke tests.

Validações específicas.

Dependendo do componente:

IPL.

Restart.

CICS recycle.

Db2 considerations.

Subsystem actions.

Tudo depende do software e da mudança.

22. ACCEPT — o erro clássico é pensar que é APPLY 2.0

Depois de testar e validar, chegamos ao:

ACCEPT

Esse comando possui significado diferente.

Ele consolida a manutenção correspondente no universo das Distribution Libraries.

Por isso APPLY e ACCEPT representam momentos distintos.

Didaticamente:

RECEIVE
    |
    v
APPLY
    |
    v
TEST
    |
    +---- PROBLEM ---> RECOVERY
    |
    v
ACCEPT

O intervalo entre APPLY e ACCEPT possui importância operacional.

Não trate ACCEPT como simplesmente:

“Agora aperto o segundo botão.”

Ele representa outra decisão.

23. ACCEPT CHECK — sim, investigue de novo

Se APPLY CHECK é importante, ACCEPT CHECK segue a mesma filosofia:

“Antes de consolidar, quero entender o que acontecerá.”

É uma mentalidade que deveria acompanhar qualquer profissional de infraestrutura:

simule
analise
execute
valide
consolide

Essa sequência não pertence apenas ao SMP/E.

Pertence à engenharia madura.

24. RESTORE — todo bom plano precisa saber voltar

Agora imagine que algo deu errado depois do APPLY.

Dependendo do estado e das condições da manutenção, RESTORE entra como parte das capacidades de recuperação.

Esse é outro conceito gigantesco para um iniciante:

Uma mudança não está completamente planejada enquanto o caminho de retorno não foi entendido.

Antes de executar:

APPLY

a pergunta não deve ser apenas:

“Como instalo?”

Também precisa existir:

“Como me recupero?”

Essa pergunta distingue laboratório de produção.

25. REJECT — removendo aquilo que ainda não deveria permanecer

Dentro da administração SMP/E também encontramos REJECT, associado à remoção/rejeição de determinados SYSMODs recebidos conforme contexto apropriado.

Mais uma vez aparece a ideia de estado.

Material pode:

  • chegar;

  • ser conhecido;

  • ser aplicado;

  • ser removido;

  • ser aceito;

  • ser rejeitado.

SMP/E não está apenas manipulando bytes.

Ele está administrando transições de estado.

26. LIST e REPORT — o investigador começa a fazer perguntas

Um curso que ensine apenas:

RECEIVE
APPLY
ACCEPT

ensina SMP/E como alguém ensinaria SQL apenas com:

INSERT
UPDATE
DELETE

e esquecesse:

SELECT

Você precisa ser capaz de perguntar ao sistema:

“O que você sabe?”

É aí que LIST, REPORT e outras formas de consulta tornam-se extremamente importantes.

Um administrador precisa investigar.

Quais SYSMODs existem?

Qual é o estado?

Quais problemas estão registrados?

Qual manutenção falta?

Que relações estão presentes?

SMP/E também é uma ferramenta de interrogação do inventário de software.

27. REPORT ERRSYSMODS — procurando suspeitos perigosos

Um dos exemplos interessantes de análise é:

REPORT ERRSYSMODS

Utilizado juntamente com informações relevantes de HOLDDATA, ajuda a analisar situações relacionadas a SYSMODs problemáticos e manutenção correspondente.

Isso representa novamente aquela filosofia:

Não espere descobrir o problema depois de tropeçar nele.

Procure informações sobre problemas conhecidos.

Patrick Jane fecha os olhos.

— O criminoso cometeu um erro.

— Qual?

— Ele achou que ninguém consultaria o relatório.

28. RECEIVE ORDER — o SMP/E descobriu a Internet

Muita gente imagina SMP/E como uma espécie de ritual envolvendo fitas magnéticas trazidas por uma van da IBM.

A realidade moderna é diferente.

Existe:

RECEIVE ORDER

que permite aquisição eletrônica de manutenção e informações associadas através dos mecanismos correspondentes de service delivery.

Isso pode inclusive fazer parte de processos automatizados.

Então temos algo como:

IBM SERVICE
     |
     v
RECEIVE ORDER
     |
     +---- PTF
     |
     +---- HOLDDATA
     |
     v
    SMP/E

O dinossauro está online.

E, ao contrário de alguns sistemas modernos, ainda lembra perfeitamente o que instalou vinte anos atrás.

29. SMP/E e automação — não confunda antigo com manual

Um erro recorrente na tecnologia é:

antigo = manual.

Não necessariamente.

Processos de obtenção de manutenção podem ser automatizados.

Jobs podem ser estruturados.

Relatórios podem ser analisados.

Rotinas de manutenção podem ser padronizadas.

O verdadeiro objetivo da automação não é transformar SMP/E em:

AUTOAPPLY EVERYTHING

Pelo amor do Sysplex, não.

É automatizar tarefas repetitivas enquanto preserva:

controle + análise + aprovação + auditabilidade.

30. O fluxo completo do caso

Patrick Jane caminha até o quadro branco.

Apaga tudo.

E escreve:

        SERVICE / SYSMOD
               |
               v
           RECEIVE
               |
               v
          HOLDDATA
               |
               v
         APPLY CHECK
               |
        +------+------+
        |             |
   REQUISITES       HOLDS
        |             |
        +------+------+
               |
               v
            ANALYSIS
               |
               v
             APPLY
               |
               v
        TARGET LIBRARIES
               |
               v
        TEST / VALIDATION
             /     \
          FAIL       OK
           |          |
           v          v
       RESTORE    ACCEPT CHECK
                      |
                      v
                   ACCEPT
                      |
                      v
           DISTRIBUTION LIBRARIES
                      |
                      v
              REPORT / AUDIT

O programador COBOL olha para o desenho.

— Agora entendi.

Jane sorri.

— Não. Agora você sabe quais perguntas fazer.

Essa provavelmente é a melhor definição de aprendizagem técnica que existe.

31. Exercício prático — o caso da PTF desaparecida

Se eu montasse essa trilha para um iniciante, o projeto final não teria vinte perguntas de múltipla escolha.

Eu entregaria um caso.

Missão

Uma nova manutenção precisa ser instalada.

O aluno deverá:

  1. identificar a função correspondente;

  2. localizar o FMID;

  3. analisar o SYSMOD;

  4. executar RECEIVE;

  5. examinar HOLDDATA;

  6. identificar requisitos;

  7. executar APPLY CHECK;

  8. interpretar mensagens SMP/E;

  9. resolver um prerequisite propositalmente ausente;

  10. executar APPLY;

  11. validar Target Libraries;

  12. executar testes;

  13. simular um problema;

  14. determinar estratégia de recovery;

  15. utilizar RESTORE quando apropriado;

  16. reaplicar corretamente;

  17. executar ACCEPT CHECK;

  18. executar ACCEPT;

  19. gerar REPORT;

  20. documentar todo o procedimento.

Agora sim temos treinamento.

O aluno não decorou comandos.

Ele administrou uma mudança.

32. Dica Bellacosa para quem vem de COBOL

Programadores COBOL frequentemente ficam assustados com SMP/E porque ele parece pertencer a outro universo.

Mas você já possui boa parte da mentalidade necessária.

COBOL ensina disciplina.

Mainframe ensina estado.

JCL ensina dependência entre etapas.

Db2 ensina integridade.

CICS ensina contexto transacional.

RACF ensina que nada deveria acontecer sem autorização adequada.

SMP/E acrescenta:

mudança controlada.

Você pode imaginar o ecossistema como uma cidade:

COBOL = trabalhadores

CICS = central de atendimento

Db2 = cartório

RACF = polícia

JES2 = logística

WLM = controle de tráfego

SMF = câmeras de segurança

SMP/E = departamento que sabe exatamente
        quais peças da cidade foram substituídas

E quando Patrick Jane chega?

Ele simplesmente lê o SMF enquanto toma chá.

33. Easter egg — Red John instalou uma USERMOD

Às 04:42, toda a manutenção finalmente funciona.

O programador prepara-se para sair.

Patrick Jane continua olhando para uma saída do SMP/E.

— Temos outro problema.

Todos congelam.

— O quê?

Ele aponta.

Existe uma USERMOD antiga.

Sem documentação atual.

Modifica exatamente o mesmo elemento envolvido na manutenção.

No comentário existe apenas:

/* DO NOT REMOVE - IMPORTANT */

Jane sorri.

— Encontramos nosso Red John.

O System Programmer começa a rir.

O programador COBOL não entende.

Ainda.

Daqui a quinze anos entenderá perfeitamente.

34. A verdadeira lição do SMP/E

Depois de muitas páginas, dezenas de conceitos e uma quantidade ligeiramente irresponsável de café, podemos finalmente responder:

Para que serve SMP/E?

Uma resposta superficial:

Para instalar manutenção no z/OS.

Uma resposta melhor:

Para controlar instalação e manutenção de software.

Uma resposta ainda melhor:

Para manter conhecimento estruturado sobre componentes, modificações, dependências e níveis de software administrados dentro do z/OS.

Mas existe uma resposta Bellacosa:

SMP/E existe para impedir que o futuro precise adivinhar o que o passado fez.

Isso é tremendamente importante.

Sistemas críticos vivem décadas.

Equipes mudam.

Funcionários se aposentam.

Fornecedores atualizam produtos.

Arquiteturas evoluem.

Documentações desaparecem.

Memórias humanas falham.

Mas alguém precisa continuar sabendo:

o que foi instalado?
quando?
sobre qual produto?
qual dependência existia?
qual correção substituiu qual?
qual modificação local estava presente?
qual problema conhecido existia?
qual é o estado atual?

Essa é a inteligência que SMP/E tenta preservar.

35. Patrick Jane fecha o caso

São 05:03.

Produção está estável.

A PTF foi aplicada.

Os testes passaram.

A equipe documentou a mudança.

HOLDDATA foi analisada.

Requisites foram satisfeitos.

Ninguém executou comandos no escuro.

O programador COBOL, que algumas horas antes achava que SMP/E era apenas “aquela coisa que instala PTF”, olha novamente para o CSI.

Agora ele enxerga outra coisa.

História.

Relações.

Estado.

Evidências.

Patrick Jane termina o chá.

— Então você realmente não lê pensamentos? — pergunta o programador.

Jane sorri.

— Quase nunca é necessário.

Ele aponta para o spool.

— As pessoas deixam pistas por toda parte.

O velho System Programmer concorda.

— Principalmente quando esquecem de olhar a HOLDDATA.

Jane caminha para a saída.

Antes de atravessar a porta, vira-se uma última vez.

— E execute CHECK primeiro.

O programador ri.

— Sempre?

Patrick Jane olha para ele.

— Você pretende descobrir em produção que estava errado?

Silêncio.

Ele desaparece pelo corredor.

No monitor permanece:

RECEIVE
   ↓
ANALYZE
   ↓
APPLY CHECK
   ↓
APPLY
   ↓
TEST
   ↓
ACCEPT

E talvez seja esse o verdadeiro segredo do SMP/E.

Ele não prevê o futuro.

Ele faz algo muito mais útil:

obriga você a investigar o presente antes de modificá-lo.

☕🦖

E, no mainframe, prevenção continua sendo uma habilidade quase sobrenatural.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , ,
Subscrever: Mensagens (Atom)
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
☕ Um Café no Bellacosa Mainframe
Conhecimento legado preparando o futuro.
Conheça minha trajetória
Autor Contato Política de Privacidade Política de Cookies
GitHub LinkedIn
Inicializando conteúdo...