Translate

Mostrar mensagens com a etiqueta FREE. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta FREE. Mostrar todas as mensagens

sexta-feira, 14 de março de 2025

Passwords vs Passphrases no RACF: O Escudo Jedi do Sysprog Padawan na Era do IBM z17

 

Bellacosa Mainframe apresenta passwords e passphrases no racf zos

Passwords vs Passphrases no RACF: O Escudo Jedi do Sysprog Padawan na Era do IBM z17

Quando oito caracteres já não conseguem proteger uma galáxia inteira

Por Vagner Bellacosa – Bellacosa Mainframe

"O medo leva ao improviso. O improviso leva ao post-it. O post-it leva ao incidente de segurança."

Introdução – O Jovem Padawan e a Porta do Datacenter

Todo Sysprog Padawan passa por um momento peculiar em sua jornada.

Ele aprende sobre JES2.

Descobre o SDSF.

Sobrevive ao primeiro ABEND.

Começa a entender o funcionamento do RACF.

Admira a elegância dos perfis FACILITY.

Tem pesadelos ocasionais com UACC(READ).

E, inevitavelmente, faz uma pergunta aparentemente inocente:

Mestre Bellacosa, por que ainda existem senhas de oito caracteres em um computador capaz de processar bilhões de transações por dia?

A pergunta é excelente.

E a resposta nos leva para uma viagem que começa na década de 1970 e termina nos sofisticados ambientes Zero Trust do IBM z17.

Este artigo não pretende apenas explicar a diferença entre Passwords e Passphrases no RACF.

Pretende mostrar como a evolução das credenciais acompanha a própria evolução do IBM Z.

Porque segurança em mainframe nunca foi apenas uma questão técnica.

Ela é uma filosofia operacional.

Uma disciplina.

E, em muitos aspectos, uma forma de arte.


O IBM Z nunca foi um computador comum

Muitas pessoas enxergam o mainframe apenas como um computador grande.

O Sysprog sabe que isso está longe da verdade.

O IBM Z é um ecossistema.

Ele é projetado para atender requisitos que poucas plataformas conseguem oferecer simultaneamente.

Disponibilidade próxima de 100%.

Escalabilidade extrema.

Auditoria detalhada.

Criptografia integrada.

Virtualização massiva.

Processamento transacional absurdo.

Em muitos bancos brasileiros, um único complexo IBM Z é responsável por:

PIX;

TED;

DOC;

Cartões;

Previdência;

Empréstimos;

Internet Banking;

Aplicativos móveis;

Open Finance.

Uma falha de autenticação em um ambiente desses não representa apenas um problema técnico.

Representa potencialmente milhões de reais em perdas.

Representa vazamento de informações.

Representa riscos regulatórios.

Representa danos reputacionais.

Por isso RACF existe.


RACF: O Mestre Guardião da Ordem Jedi

RACF significa:

Resource Access Control Facility.

Ele não é apenas um produto.

Ele é praticamente o sistema imunológico do z/OS.

RACF controla:

Usuários;

Grupos;

Datasets;

CICS;

DB2;

TSO;

UNIX System Services;

MQ;

JES;

Operações especiais.

Quando um usuário digita:

LOGON VAGNER

RACF faz inúmeras verificações.

Quem é você?

Você realmente é você?

Sua senha expirou?

Está revogada?

Tentou errar várias vezes?

Está autorizado ao dataset?

É quase como um Jedi verificando um visitante tentando entrar no Templo de Coruscant.


O legado das senhas de oito caracteres

Um jovem profissional pode achar estranho.

Como assim apenas oito caracteres?

A explicação está na história.

RACF surgiu em uma época muito diferente.

Década de 70.

Redes fechadas.

Terminais 3270.

Linhas SNA.

Poucos usuários externos.

Ataques pela Internet?

Praticamente inexistentes.

Botnets?

Não.

GPUs especializadas?

Não.

Malwares ladrões de credenciais?

Não.

Naquele contexto:

ABCD1234

Era aceitável.

Não porque fosse forte.

Mas porque o modelo de ameaças era outro.


O universo mudou

Hoje o cenário é completamente diferente.

Temos:

Credential stuffing.

Ataques automatizados.

Malwares infostealers.

Phishing.

Engenharia social.

Ataques offline.

Data breaches.

Dark web.

Inteligência artificial.

Sistemas expostos por APIs.

Open Banking.

Open Finance.

Cloud híbrida.

VPNs comprometidas.

O atacante atual possui recursos que um hacker dos anos 80 jamais sonharia possuir.


Entropia: o combustível da Força

Um dos conceitos mais importantes em segurança é a entropia.

Podemos simplificar:

Quanto mais possibilidades existem, maior a entropia.

Quanto maior a entropia, mais difícil é descobrir a credencial.

Imagine um cofre.

Primeiro cofre.

100 combinações.

Segundo cofre.

10 bilhões de combinações.

Qual deles você escolheria?

A resposta é óbvia.


O limite matemático das Passwords

Uma senha de oito caracteres possui restrições.

Mesmo utilizando:

Maiúsculas

Minúsculas

Números

Caracteres especiais

Existe um teto.

Por exemplo.

66 opções possíveis.

Elevadas à oitava potência.

66⁸

Aproximadamente.

360 trilhões.

Parece muito.

Mas não é.

Não para hardware especializado.


O grande inimigo chama-se previsibilidade

Padawans adoram criar senhas criativas.

Infelizmente os atacantes também adoram.

Exemplos clássicos:

IBM2026

Cobol65

Mainframe1

Banco123

Bellacosa2026

Parece forte.

Mas é previsível.

Ferramentas modernas usam regras.

Substituições.

Palavras comuns.

Datas.

Nomes próprios.

Centenas de milhões de combinações inteligentes.

Em poucos minutos.


A ascensão das Passphrases

IBM percebeu essa limitação.

E RACF evoluiu.

Surgiu o conceito de Passphrase.

Inicialmente:

14 caracteres mínimos.

Posteriormente.

9 até 100 caracteres.

Uma enorme evolução.


Regras do RACF para Passphrases

O RACF não permite qualquer frase.

Existem salvaguardas.

Não conter o userid.

Possuir duas letras.

Possuir dois caracteres especiais.

Não repetir três caracteres iguais.

Exemplo:

Errado.

VAGNER2026

Errado.

AAAAAAAAAAAA

Errado.

Bellacosa!!!

Correto.

MeuCafeNoMainframe@2026

O crescimento exponencial da segurança

Aqui está o ponto mais fascinante.

Adicionar caracteres produz crescimento exponencial.

Não linear.

Imagine.

8 caracteres.

66⁸

14 caracteres.

66¹⁴

A diferença é quase incompreensível.

É como comparar.

Um copo de água.

Com o Oceano Pacífico.


O ataque de força bruta

Suponhamos.

Um laboratório possui capacidade de testar.

100 bilhões de combinações por segundo.

Uma senha simples.

Pode ser quebrada rapidamente.

Uma passphrase longa.

Poderia levar bilhões de anos.

Na prática.

É impossível.


O paradoxo do ser humano

Até aqui tudo parece resolvido.

Use passphrases.

Fim do artigo.

Não.

Existe um detalhe.

O usuário.

O elo mais imprevisível.


Cenário 1

Senha impossível.

Q7#Xt29L@P

Usuário esquece.

Anota.

Cola no monitor.

Segurança destruída.


Cenário 2

Mesma senha em vinte sistemas.

Vazamento único.

Comprometimento múltiplo.


Cenário 3

Passphrase amigável.

EuTomoCafeNoBellacosa@TodaManha2026

Grande.

Memorável.

Complexa.

Excelente.


O ensinamento do XKCD

Existe uma famosa tirinha.

Ela revolucionou a discussão sobre senhas.

Mostra algo interessante.

Senha.

Tr0ub4dor&3

Difícil lembrar.

Passphrase.

correct horse battery staple

Muito maior.

Muito mais fácil.

Muito mais segura.

A indústria inteira começou a reconsiderar suas práticas.


O NIST mudou de ideia

Antigamente.

As organizações exigiam.

Trocar senha mensalmente.

Símbolos obrigatórios.

Perguntas secretas.

Regras absurdas.

Exemplos.

SenhaJan2026
SenhaFev2026
SenhaMar2026

O usuário apenas incrementava o mês.

Nada realmente melhorava.

Hoje.

O NIST recomenda.

Passphrases longas.

Bloqueio contra senhas vazadas.

MFA.

FIDO2.

Autenticação forte.


O IBM z17 e a era Passwordless

O IBM z17 representa outra etapa evolutiva.

O objetivo não é apenas fortalecer senhas.

É eliminar senhas.

Tecnologias disponíveis.

Certificados.

Smartcards.

PIV.

Kerberos.

RACF MFA.

Passkeys.

Tokens.

Biometria.


MFA: Dois sabres de luz são melhores que um

Autenticação multifator funciona porque exige mais de um elemento.

Algo que você sabe.

Passphrase.

Algo que possui.

Token.

Algo que é.

Biometria.

Um atacante pode roubar uma senha.

Pode até enganar um usuário.

Mas roubar múltiplos fatores simultaneamente é muito mais difícil.


IDs Técnicos também merecem atenção

Muitos ambientes possuem.

USRBATCH.

DB2ADM.

CICSSTC.

MQMGR.

FTPUSER.

Estas contas frequentemente permanecem anos sem revisão.

Grande erro.

Devemos utilizar.

Rotação automática.

Vault corporativo.

Segredos temporários.

Auditoria constante.


O Sysprog Padawan em 2026

O Padawan moderno não pode ser apenas especialista em JCL.

Ele precisa entender.

Zero Trust.

Identidade.

Criptografia.

OAuth.

JWT.

OpenID.

PKI.

MFA.

Threat Hunting.

SIEM.

Compliance.

Porque o papel do Sysprog mudou.

Ele deixou de ser apenas um operador do sistema.

Tornou-se um arquiteto de confiança digital.


A recomendação do Mestre Bellacosa

Se eu estivesse formando uma academia para Sysprogs Padawans em 2026, minhas recomendações seriam:

Usuário comum.

Passphrase com vinte caracteres.

Desenvolvedor.

Passphrase mais MFA.

Administrador RACF.

MFA obrigatório.

IDs privilegiados.

Certificados digitais.

APIs.

OAuth2.

Serviços automatizados.

Segredos rotacionados.

Parceiros externos.

Autenticação federada.


Considerações finais – A verdadeira lição do RACF

No final das contas, a discussão sobre Passwords versus Passphrases não trata apenas de matemática.

Também não trata apenas de criptografia.

Ela fala sobre pessoas.

Sobre hábitos.

Sobre comportamento.

Sobre cultura organizacional.

Sobre engenharia de confiança.

O RACF continua sendo um dos sistemas de controle de acesso mais sofisticados já construídos.

Mas nem mesmo um IBM z17 equipado com processadores criptográficos dedicados consegue proteger uma organização cujo administrador utiliza uma senha anotada em um caderno escondido sob o teclado.

A verdadeira segurança surge quando tecnologia, processos e pessoas trabalham em harmonia.

E talvez esta seja a maior lição para todo Sysprog Padawan.

Aprender comandos é importante.

Dominar SETROPTS é valioso.

Entender SURROGAT, FACILITY e OPERCMDS é fundamental.

Mas compreender que segurança é uma disciplina viva, que evolui constantemente diante de novas ameaças, é o que realmente separa um aprendiz de um Mestre da Ordem Mainframe.

E lembre-se sempre:

No IBM Z, a Força não está apenas no processador. Ela também está na credencial que impede o lado sombrio de assumir o controle da galáxia corporativa.

 

terça-feira, 7 de maio de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas - Parte II

 

Brellacosa Mainframe e os ponteiros de memoria do Cobol parte II

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas

Quando o Padawan Descobre que Pode Construir Estruturas que Não Existem Até Serem Invocadas

Por Bellacosa Mainframe


"Um registro em WORKING-STORAGE nasce junto com o programa. Um registro BASED espera pacientemente até que alguém lhe conceda um endereço. É quase como invocar um sabre de luz que ainda não possui cristal."

Mestre Sysprog Bellacosa


Introdução

Na Parte 1 aprendemos sobre:

  • USAGE POINTER

  • ADDRESS OF

  • SET

  • Stack

  • Heap

  • AMODE 24/31/64

  • Ponteiros inválidos

  • Dangling pointers

Agora vamos atravessar uma das fronteiras mais desconhecidas do COBOL moderno.

Chegou o momento do Padawan descobrir algo surpreendente.

No COBOL, podemos criar estruturas que não ocupam memória alguma até receberem um endereço válido.

Sim.

Existe praticamente uma espécie de objeto fantasma.

Uma descrição.

Uma planta arquitetônica.

Um molde.

Sem existência física.

Até alguém dizer:

SET ADDRESS OF ALGUMA-COISA

ou

ALLOCATE

E então...

A estrutura ganha vida.


O que é BASED?

BASED é provavelmente uma das palavras menos utilizadas no COBOL corporativo.

Exemplo:

01 WS-CLIENTE BASED.

O compilador entende:

"Existe uma estrutura chamada WS-CLIENTE."

Mas também entende:

"Não reserve memória para ela."


Diferença entre WS tradicional

Working Storage

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.

Ao carregar o programa.

Memória:

1000 WS-NOME

1030 WS-IDADE

Sempre existe.


BASED

01 WS-CLIENTE BASED.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.

Memória:

Nada.

Zero.

Inexistente.


Como BASED funciona?

Pense em um apartamento na planta.

Temos:

Sala

Cozinha

Banheiro

Quarto

Tudo desenhado.

Mas ainda não foi construído.


BASED é exatamente isso.


O papel do ponteiro

Precisamos de alguém para dizer:

Mestre...

O apartamento agora fica naquele endereço.


Exemplo

01 PTR-CLIENTE.

USAGE POINTER.

Associando

SET ADDRESS OF WS-CLIENTE

TO PTR-CLIENTE

Pronto.

WS-CLIENTE agora existe.


Primeiro exemplo completo

Passo 1

Definir ponteiro

01 PTR-CLI POINTER.

Passo 2

Criar estrutura BASED

01 REG-CLIENTE BASED.

   05 CLI-ID.
      PIC 9(5).

   05 CLI-NOME.
      PIC X(30).

   05 CLI-SALDO.
      PIC S9(7)V99.

Passo 3

Criar memória real

01 WS-AREA.

   PIC X(40).

Passo 4

Associar

SET PTR-CLI

TO ADDRESS OF WS-AREA

Passo 5

Ativar

SET ADDRESS OF REG-CLIENTE

TO PTR-CLI

Passo 6

Usar

MOVE 1000

TO CLI-ID


MOVE 'BELLACOSA'

TO CLI-NOME

Resultado.

Funciona.

Mesmo sendo BASED.


O que aconteceu?

Antes

REG-CLIENTE


inexistente

Depois

PTR-CLI


↓

70001000




REG-CLIENTE


usa memória 70001000

ALLOCATE

Agora começa a magia.

Não queremos usar WS.

Queremos memória nova.

Dinâmica.


Exemplo

ALLOCATE REG-CLIENTE

Compilador solicita memória.

Heap.


Visualmente

Antes

HEAP


vazio

Depois

HEAP


7000000


REG-CLIENTE

FREE

Toda magia tem preço.

Precisamos liberar.


Exemplo

FREE REG-CLIENTE

Se esquecer.

Memory leak.


CEEGTST

Muito utilizado.

LE Runtime.


Significa.

Get Storage.


Exemplo conceitual

CALL 'CEEGTST'

LE devolve.

Endereço.


Ponteiro recebe.


Mais sofisticado.

Mais profissional.


CEEFRET

Libera memória.


Equivalente.

malloc()


free()

No mundo C.


Comparação

COBOLC
ALLOCATEmalloc
FREEfree
CEEGTSTmalloc avançado
CEEFRETfree

Criando lista encadeada

Agora o lado Jedi aparece.


Estrutura

01 NODE BASED.


05 DADO.
PIC 9(5).


05 NEXT POINTER.

Visualmente

NODE


DADO


NEXT

Primeiro nó

100


PTR=2000

Segundo

200


PTR=3000

Terceiro

300


NULL

Ligando nós

SET NEXT

TO PTR-NODE2

Pronto.

Lista encadeada.


Navegando

Começamos.

HEAD

Enquanto

PTR <> NULL

Exibe.

Avança.


Exemplo

DISPLAY DADO


SET PTR

TO NEXT

Filas

Também possível.

FIFO.


Cliente 1

Cliente 2

Cliente 3


Pilhas

LIFO.


Push

Pop

Peek


Tudo em COBOL.


Árvores

Mais interessante.


          50


      20      80


   10   30

Estrutura

LEFT POINTER


RIGHT POINTER

Muito elegante.


Tabelas dinâmicas

Outra vantagem.


OCCURS tradicional.

1000 TIMES

Sempre ocupa.


Dinâmica.

Somente o necessário.


XML

Parser.


Nós.

Filhos.

Pai.


Ponteiros ajudam muito.


JSON

Excelente caso.


Objeto.

Array.

Subobjeto.


Estrutura árvore.


Performance

Muito boa.


Sem copiar dados.


Apenas endereço.


Mover.

8 bytes.


Mover.

1 MB.

Muito pior.


Heap

Mais lenta.

Que Working Storage.


Mas muito flexível.


Cuidados

Nunca esquecer FREE


Não usar memória liberada


Inicializar ponteiros

SET PTR TO NULL

Verificar retorno


Documentar


Curiosidade

Pouquíssimos desenvolvedores COBOL já implementaram uma lista encadeada real em produção.

Mas praticamente todos os produtos IBM utilizam estruturas semelhantes internamente.

CICS.

MQ.

DB2.

LE.

z/OS.

Todos.


O Conselho do Mestre Bellacosa

BASED é provavelmente a funcionalidade que mais aproxima COBOL do universo das linguagens de sistemas.

Ela permite abandonar parcialmente o modelo tradicional de registros fixos e entrar em um mundo onde estruturas podem nascer, crescer, conectar-se umas às outras e desaparecer dinamicamente.

Mas o jovem Padawan deve compreender uma verdade fundamental.

Quando utilizamos BASED, ALLOCATE, CEEGTST e ponteiros encadeados, deixamos o confortável universo dos datasets catalogados, dos OCCURS previsíveis e dos registros estáticos.

Passamos a caminhar pelos corredores escuros do Heap do Language Environment.

E nesses corredores existem criaturas perigosas chamadas:

  • Memory Leak

  • Dangling Pointer

  • Heap Corruption

  • S0C4

  • Storage Overlay

  • Abend U4038

O verdadeiro Mestre COBOL não teme essas criaturas.

Ele simplesmente sabe exatamente onde elas vivem.


Continua na Parte 3

O Lado Sombrio dos Ponteiros: SOC4, Memory Leaks, Dumps, IPCS, Fault Analyzer e os Monstros Escondidos no Heap do IBM Z.


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
GitHub LinkedIn
Inicializando conteúdo...