✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta controle de acesso. Mostrar todas as mensagens

segunda-feira, 14 de junho de 2021

💀🔥 “Seu RACF está auditado… ou você só roda comando manual?”

Bellacosa Mainframe comenta sobre auditoria racf e segurança mainframe

💀🔥 “Seu RACF está auditado… ou você só roda comando manual?”

🧠 Checklist automatizado com JCL + REXX (nível banco, zero ilusão)

“Se sua auditoria depende de humano…
ela já falhou.”

🧠 📜 A verdade que ninguém te conta

No mundo real (banco, fintech, governo):

👉 Auditoria manual = teatro
👉 Auditoria automatizada = sobrevivência

E aqui entra a dupla lendária do mainframe:

JCL → orquestra
REXX → pensa, filtra, decide

💡 Curiosidade Bellacosa:

Antes de SIEM moderno… o mainframe já fazia auditoria automatizada com SMF + REXX.

⚙️ 🧬 Arquitetura do “scanner RACF”

👉 Fluxo real:

JCL executa comandos RACF
Output vai para dataset
REXX lê dataset
Aplica regras de auditoria
Gera relatório (ou alerta)

🧨 1. JCL — o motor da auditoria

🔥 Exemplo prático (coleta de evidências)


//AUDITRAC JOB (ACCT),'RACF SCAN',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=&&RACFOUT,DISP=(,PASS),
// SPACE=(CYL,(5,5)),UNIT=SYSDA
//SYSTSIN DD *
  SETROPTS LIST
  SEARCH CLASS(USER) MASK(*) SPECIAL
  RLIST DATASET * AUTHUSER(*)
/*

💥 O que isso faz:

lista configurações RACF
identifica usuários privilegiados
expõe acessos indevidos

🧠 2. REXX — o cérebro da auditoria

🔥 Exemplo prático (detecção de risco)


/* REXX */
parse arg dataset
"EXECIO * DISKR" dataset "(STEM LINES. FINIS"

do i = 1 to lines.0
  if pos('SPECIAL', lines.i) > 0 then do
     say 'ALERTA: usuário com SPECIAL -> ' lines.i
  end

  if pos('*PUBLIC', lines.i) > 0 then do
     say 'RISCO CRÍTICO: acesso público detectado -> ' lines.i
  end
end

💀 Resultado:

identifica risco automaticamente
elimina análise manual

🧬 3. Regras que um banco REAL usa

👉 Não é só listar — é interpretar

✔️ Nenhum *PUBLIC em dataset crítico
✔️ SPECIAL limitado
✔️ APF controlado
✔️ UID 0 auditado
✔️ FACILITY revisada
✔️ STARTED TASK mapeada

⚙️ 4. Evolução hardcore (nível enterprise)

👉 Automatização completa:

agendado via JES2 / scheduler
output versionado
comparação diária (drift detection)
envio de alerta (email / SIEM)

💡 Easter egg:

Drift de segurança é mais perigoso que invasão direta.

🧠 5. Comparação inteligente (ontem vs hoje)

🔥 Ideia poderosa

REXX pode comparar execuções:


if linha_hoje \= linha_ontem then
  say 'ALTERAÇÃO DETECTADA!'

💥 Isso detecta:

privilégio adicionado
acesso aberto
mudança suspeita

🧾 6. Output estilo auditor (nível banco)

👉 Não basta log — precisa ser auditável

Exemplo:


[CRITICAL] USER HACKER HAS SPECIAL
[HIGH] DATASET PROD.FINANCE WITH *PUBLIC READ
[MEDIUM] NEW APF LIBRARY DETECTED

💣 7. Onde mora o perigo real

👉 Não está no código… está na omissão

🔥 Problemas comuns:

script roda mas ninguém lê
alertas ignorados
baseline inexistente

💡 Insight:

Auditoria sem ação é só documentação bonita.

🧠 8. Easter eggs de quem vive isso

💡 IKJEFT01 é o “shell invisível” do z/OS
💡 REXX consegue parsear RACF melhor que muita ferramenta cara
💡 JES spool é fonte de ouro pra auditor
💡 dataset temporário mal protegido = vazamento

⚔️ 9. Fluxo real de ataque vs auditoria automatizada

👹 Ataque:

ganha acesso
eleva privilégio
altera RACF
mantém persistência

🛡️ Auditoria automatizada:

detecta alteração
gera alerta
compara baseline
bloqueia rapidamente

🏦 Realidade nível banco

👉 Banco não confia em:

print de tela
comando manual
auditor humano

👉 Banco confia em:

automação
evidência
histórico

💀🔥 Frase final Bellacosa

“Se o seu RACF muda e você não percebe…
quem percebe é o atacante.”

sábado, 1 de maio de 2021

💀🔥 “Seu RACF está seguro… ou você só acha?”

Bellacosa Mainframe alerta sobre riscos no racf mal configurado

💀🔥 “Seu RACF está seguro… ou você só acha?”

🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)

“RACF não falha…
quem falha é quem confia demais nele.”

🧠 📜 Contexto histórico (o começo de tudo)

O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).

👉 Naquela época:

segurança era controle de acesso
hoje é sobrevivência digital

💡 Curiosidade:

RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.

💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO

🧨 1. *PUBLIC — o vilão silencioso

👉 Procure:


// quem tem acesso aberto?
RLIST DATASET * AUTHUSER(*)

💥 Red flag:

datasets críticos com:


ID(*PUBLIC) ACCESS(READ ou UPDATE)

🔥 Insight Bellacosa:

80% das falhas começam aqui.

🧠 2. Usuários com SPECIAL / OPERATIONS

👉 Liste:


SEARCH CLASS(USER) MASK(*) SPECIAL

💥 Risco:

acesso total ao RACF

🎯 Dica senior:

separar:
- ADMIN ≠ AUDITOR

⚙️ 3. Grupos com autoridade excessiva

👉 Verifique:


LISTGRP * OMVS

💥 Problema:

grupo herdando privilégio indevido

🔥 Easter egg:

Um grupo mal configurado é pior que um usuário root.

🧬 4. Programas APF e AC=1

👉 Verifique APF:


D PROG,APF

💥 Risco:

execução em modo supervisor

🎯 Ataque clássico:

inserir loadlib malicioso

🔐 5. Password Policy (o calcanhar de aquiles)

👉 Cheque:


SETROPTS LIST

💥 Problemas comuns:

senha simples
sem expiração
sem history

🔥 Curiosidade:

Já vi banco com senha “123456” em ambiente produtivo.

🌐 6. FACILITY class (o “backdoor oficial”)

👉 Verifique:


RLIST FACILITY *

💥 Risco:

permissões ocultas

🎯 Exemplo crítico:

BPX.* (Unix System Services)

🧑‍💻 7. USS (Unix no mainframe = Linux feelings)

👉 Verifique:


LISTUSER USER OMVS

💥 Risco:

UID 0 (root)

🔥 Insight:

USS é o ponto favorito de pivot de atacante moderno.

🧾 8. Logging / SMF (sem isso você está cego)

👉 Cheque:

SMF 80 (RACF)
SMF 30 (jobs)

💥 Problema:

logs incompletos

🎯 Dica:

integrar com SIEM

🧠 9. Started Tasks (STC) — privilégio invisível

👉 Verifique:


RLIST STARTED *

💥 Risco:

tarefas com privilégios elevados

🔥 Easter egg:

STC mal protegido = root invisível rodando 24x7

🔗 10. Integrações externas (o novo campo de batalha)

👉 Verifique:

CICS
z/OS Connect

💥 Risco:

acesso indireto ao core

🎯 Realidade:

O ataque não entra pelo mainframe… entra pela API.

💀🔥 CHECKLIST RÁPIDO (modo auditor)

✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras

🧠💣 Fluxo real de ataque (pra abrir a mente)

credencial fraca
acesso TSO/FTP
enumeração RACF
exploração (APF / FACILITY / USS)
persistência
exfiltração

🧬 Easter Eggs que só senior percebe

💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe

🏦 Realidade nível banco

👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo

🔥 Frase final estilo Bellacosa

“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”

segunda-feira, 2 de abril de 2018

IBM Mainframe Discovery : Capítulo IV — A Sala dos Cofres Cósmicos

Bellacosa Mainframe apresenta o ibm mainframe parte IV

☕ Um Café no Bellacosa Mainframe

Capítulo IV — A Sala dos Cofres Cósmicos

Segurança no IBM Z: Por Que os Guardiões Dormem Tranquilos

PRIMEIRA REGRA DA SEGURANÇA INTERGALÁCTICA

Se alguém disser:

"Nossa nave nunca será invadida."

...desconfie imediatamente.

Porque o Universo possui uma característica curiosa.

Ele é povoado por três tipos de seres.

Os inteligentes.

Os curiosos.

E os curiosamente inteligentes.

Infelizmente, o terceiro grupo costuma dedicar boa parte da vida tentando descobrir como entrar onde não foi convidado.

Foi pensando nesses exploradores inconvenientes que nasceu uma das arquiteturas de segurança mais sofisticadas da história da computação.

Bem-vindo ao setor mais protegido da nave IBM Z.

A Fortaleza Invisível

Imagine uma gigantesca cidade espacial.

Nela existem:

Hospitais.

Bancos.

Laboratórios.

Centrais de energia.

Hangar militar.

Sala do comandante.

Agora imagine que todas essas instalações estão abertas.

Sem portas.

Sem crachás.

Sem vigilância.

Quanto tempo levaria até surgir o primeiro desastre?

Provavelmente menos tempo do que um operador leva para digitar:

TSO LOGON

Segurança Não Começa na Senha

Esse talvez seja o maior erro cometido por iniciantes.

Pensam que segurança significa:

senha.

Na verdade...

senha é apenas a campainha da porta.

O verdadeiro sistema de segurança está muito além.

Ele envolve:

identidade.

autorização.

criptografia.

hardware.

isolamento.

auditoria.

integridade.

No IBM Z, segurança nunca foi um programa instalado depois.

Ela faz parte da própria arquitetura.

O Bairro Proibido

Imagine nossa nave dividida em milhares de compartimentos.

Cada porta possui uma cor diferente.

Você recebeu uma chave azul.

Isso significa que pode abrir:

portas azuis.

Nada mais.

Mesmo que descubra onde está a sala do capitão...

...a porta simplesmente não abrirá.

Essa é exatamente a filosofia do Hardware Storage Key Protection.

As Chaves da Memória

Aqui encontramos um recurso extraordinário.

Cada bloco de memória de 4 KB recebe uma chave de proteção.

Quando um programa tenta acessar esse bloco...

o hardware pergunta:

— Sua chave corresponde à chave desta área?

Se sim...

entrada permitida.

Caso contrário...

acesso negado.

Tudo isso acontece diretamente no hardware.

Sem depender do sistema operacional.

Segundo Spruth, essa proteção praticamente impede que um programa comum sobrescreva áreas privilegiadas da memória, reduzindo drasticamente riscos como buffer overflows em regiões críticas do sistema.

O Guarda Nem Precisa Pensar

Observe algo interessante.

O processador não pergunta:

"Será que esse programa é confiável?"

Ele apenas compara chaves.

É rápido.

Determinístico.

Matemático.

Não existe interpretação.

Isso torna a segurança extremamente eficiente.

O Labirinto dos Buffer Overflows

Imagine uma biblioteca.

Cada sala possui paredes extremamente resistentes.

Você pode encher uma estante de livros.

Mas ela nunca atravessará a parede para invadir a sala vizinha.

Foi exatamente essa ideia que inspirou a proteção por Storage Keys.

Em muitas plataformas, erros de programação permitiram durante décadas que um processo escapasse de sua área de memória.

No IBM Z isso sempre foi muito mais difícil.

O Cofre Dentro do Cofre

Agora imagine que existe uma sala secreta.

Dentro dela há outro cofre.

Dentro desse cofre existe uma pequena caixa.

Dentro da caixa está a chave do banco da galáxia.

Parece exagero?

Não para quem administra bilhões de dólares diariamente.

É aqui que entra a criptografia do IBM Z.

Dois Magos da Criptografia

O relatório apresenta dois personagens extremamente importantes.

O primeiro é:

CPACF

(CP Assist for Cryptographic Functions)

Ele vive dentro da própria CPU.

Sua missão é acelerar algoritmos criptográficos.

O segundo é:

Crypto Express

Uma placa especializada.

Muito mais poderosa.

Muito mais protegida.

Cada uma possui responsabilidades diferentes.

Enquanto o CPACF acelera operações criptográficas diretamente no processador, o Crypto Express executa funções avançadas envolvendo gerenciamento seguro de chaves, assinaturas digitais, geração de números aleatórios e criptografia assimétrica.

A Chave Que Nunca Sai do Cofre

Este talvez seja o conceito mais elegante de todo o capítulo.

O nome é:

Master Key.

Imagine um rei.

Ele nunca sai do castelo.

Nunca participa das batalhas.

Nunca atravessa fronteiras.

Todas as outras chaves viajam.

Mas o rei permanece protegido.

No IBM Z acontece exatamente isso.

A Master Key permanece armazenada dentro do hardware criptográfico.

Ela nunca aparece em memória.

Nunca vai para disco.

Nunca é enviada pela rede.

Segundo o relatório, apenas cópias criptografadas das chaves de aplicação circulam pelo sistema; sua descriptografia ocorre exclusivamente dentro do coprocesso seguro.

O Cofre Autodestrutivo

Agora imagine que alguém tente abrir esse cofre usando uma furadeira.

Ou calor.

Ou eletricidade.

Ou qualquer outro ataque físico.

O que acontece?

O cofre destrói imediatamente seu segredo.

Parece filme.

Mas é engenharia.

As placas Crypto Express utilizam módulos resistentes à violação física (Tamper Resistant Security Module).

Caso detectem tentativa de invasão, podem apagar automaticamente as chaves armazenadas.

A Grande Biblioteca das Permissões

Até agora falamos sobre hardware.

Mas alguém precisa decidir:

Quem pode fazer o quê?

É aqui que encontramos dois dos personagens mais famosos do z/OS.

SAF — O Porteiro da Nave

Imagine um enorme edifício.

Em cada porta existe um segurança.

Mas esse segurança não toma decisões.

Ele apenas pergunta:

— Posso deixar esta pessoa entrar?

Quem responde?

Outro departamento.

Esse segurança chama-se:

SAF.

Security Authorization Facility.

Ele identifica eventos de segurança e encaminha a decisão ao mecanismo responsável pela autorização.

RACF — O Conselho Galáctico

O verdadeiro juiz chama-se:

RACF

(Resource Access Control Facility).

Imagine um gigantesco livro de regras.

Ele contém milhões de decisões.

Quem pode acessar:

arquivos.

programas.

transações.

impressoras.

bancos.

datasets.

comandos.

Cada tentativa de acesso consulta esse conjunto de perfis e regras.

Spruth observa que o RACF utiliza perfis e mecanismos de autorização extremamente granulares, tornando-se um dos pilares da segurança no z/OS.

APF — O Conselho dos Mestres

Existe um erro muito comum.

Pensar que todo programa privilegiado deveria ter acesso total.

No IBM Z isso seria considerado um péssimo projeto.

Surge então o:

Authorized Program Facility

APF.

Imagine uma nave.

Alguns oficiais podem abrir a sala de máquinas.

Outros podem acessar o hangar.

Pouquíssimos chegam ao núcleo do reator.

Cada um recebe apenas os privilégios necessários.

Nada além disso.

Segundo Spruth, o APF funciona como um guardião da integridade do sistema, permitindo que apenas programas autorizados utilizem determinados serviços privilegiados do z/OS.

O Pecado Mortal: Dar Poder Demais

Em muitos sistemas operacionais existe apenas:

Administrador.

Usuário.

Fim.

No IBM Z a filosofia é diferente.

Autorizações são extremamente específicas.

Esse princípio ficou conhecido muitos anos depois como:

Princípio do Menor Privilégio.

Curiosamente...

o Mainframe já vivia isso muito antes do termo virar moda.

A Cidade Que Nunca Dorme

Imagine bilhões de habitantes.

Todos entrando.

Saindo.

Movimentando dinheiro.

Consultando informações.

Transferindo recursos.

Como saber quem fez cada ação?

Resposta:

auditoria.

Embora o relatório foque principalmente em SAF, RACF e APF, toda essa arquitetura trabalha em conjunto com mecanismos de registro e rastreabilidade do z/OS, permitindo acompanhar eventos relevantes de segurança.

Porque segurança sem auditoria é apenas esperança.

Um Curioso Comentário de Spruth

Há uma frase no relatório que chama atenção.

O autor comenta que não conhecia casos de infecção por vírus ou ataques bem-sucedidos comprometendo sistemas z/OS na época em que escreveu o documento.

Hoje sabemos que nenhum sistema deve ser considerado absolutamente imune.

As ameaças evoluem constantemente.

Ainda assim, o histórico do IBM Z continua sendo um dos mais sólidos da indústria, justamente porque sua arquitetura foi concebida com isolamento, controle de acesso e defesa em profundidade.

O Que Mudou Desde 2010?

Desde a publicação do relatório, o ecossistema IBM Z ganhou novos recursos importantes:

algoritmos criptográficos mais modernos;
suporte ampliado para curvas elípticas e TLS atualizado;
integração com autenticação multifator;
criptografia preparada para desafios futuros;
Secure Execution para cargas Linux;
gerenciamento avançado de certificados;
proteção de APIs;
integração com ambientes híbridos e Zero Trust.

Mas observe algo curioso.

Os princípios fundamentais permanecem exatamente os mesmos.

A Filosofia dos Antigos Engenheiros

Os engenheiros do System/360 pareciam seguir uma máxima curiosa.

Não confie em ninguém.

Nem no usuário.

Nem no operador.

Nem no programa.

Nem no hardware.

Nem no futuro.

Cada camada protege a próxima.

Cada componente verifica o anterior.

Cada privilégio precisa ser justificado.

É quase como construir uma nave supondo que, em algum momento, alguém inevitavelmente tentará entrar onde não deveria.

Curiosidades do Diário de Bordo

🔐 O IBM Z incorporou mecanismos de proteção em hardware décadas antes de muitos conceitos modernos de segurança se popularizarem.

🛡️ Storage Keys, APF, SAF e RACF formam uma cadeia de proteção em camadas, onde cada elemento tem uma função específica.

🔑 A Master Key jamais precisa sair do hardware criptográfico, reduzindo drasticamente o risco de exposição.

🌌 Segurança, no universo IBM Z, nunca foi tratada como um produto adicional. Ela faz parte da própria fundação da arquitetura.

Diário de Bordo do Padawan COBOL

Antes de deixar o setor de segurança da nave, registre estas coordenadas:

✅ Segurança começa na arquitetura, não na tela de login.

✅ Quanto menos privilégios um programa possuir, menor será o impacto de uma eventual falha.

✅ Criptografia eficiente depende tanto da proteção das chaves quanto dos algoritmos utilizados.

✅ A melhor defesa não é impedir que todos tentem entrar; é construir um sistema onde cada porta saiba exatamente quem pode atravessá-la.

No próximo capítulo seguiremos para um dos compartimentos mais fascinantes de toda a nave: o Subsistema de Entrada e Saída (I/O). Descobriremos por que, enquanto muitos computadores fazem a CPU esperar pelos discos, o IBM Z decidiu entregar essa missão a uma verdadeira frota de especialistas — transformando o I/O em uma operação digna de uma logística interplanetária.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.