Bellacosa Mainframe fala sobre segurança mainframe RACF TSS ACF2

🔥 Quem Realmente Manda no Seu z/OS? — RACF vs TSS vs ACF2, a Guerra Silenciosa que Decide Tudo

Se você trabalha com mainframe há tempo suficiente, já sabe:
o sistema pode ser o mais estável do mundo… mas quem decide o que acontece nele não é o z/OS — é o ESM.

E aí entra o trio que moldou décadas de segurança no mainframe:

• IBM RACF
• CA Top Secret (TSS)
• CA ACF2

Três filosofias. Três formas de pensar segurança.
E, mais importante: três maneiras completamente diferentes de cometer erros — ou evitá-los.

---

🧠 Capítulo 1 — Origem: Quando Segurança Virou Necessidade (não luxo)

Volta para os anos 70/80.

Mainframe já processava:

• bancos
• governo
• folha de pagamento
• defesa

E aí veio a pergunta que mudou tudo:

“Quem pode acessar o quê?”

A resposta não era trivial — porque o z/OS (na época MVS) não nasceu com segurança robusta nativa.

🔵 RACF (IBM)

Criado pela própria IBM:

• integração total com o sistema
• modelo corporativo
• foco em governança

👉 DNA:

segurança como parte da arquitetura

---

🟢 TSS (CA Top Secret)

Criado pela CA:

• foco em simplicidade
• modelo centrado no usuário

👉 DNA:

segurança como controle direto

---

🟣 ACF2

Também da CA:

• abordagem radicalmente diferente
• rule-based

👉 DNA:

segurança como linguagem

---

🧬 Capítulo 2 — O DNA de Cada Um

🔵 RACF — O Burocrata Organizado

RACF pensa assim:

Usuário → Grupo → Recurso → Permissão

Ele cria estrutura.

Exemplo real:

ADDUSER DEV01 DFLTGRP(DEV)
PERMIT PROD.APP.* CLASS(DATASET) ID(DEV01) ACCESS(READ)

👉 RACF gosta de:

• hierarquia
• governança
• previsibilidade

---

🟢 TSS — O Operador Pragmático

TSS elimina intermediários:

ACID → Permissões

Exemplo:

TSS PERMIT(DEV01) DATASET(PROD.APP.*) ACCESS(READ)

👉 TSS gosta de:

• simplicidade
• rapidez
• controle direto

---

🟣 ACF2 — O Hacker Formal

ACF2 inverte tudo:

Recurso → Regra → Usuário

Exemplo:

$KEY(PROD)
 UID(DEV01) ALLOW

👉 ACF2 gosta de:

• regras
• lógica
• flexibilidade extrema

---

⚔️ Capítulo 3 — A Diferença que Ninguém Te Conta

Aqui está o ponto que separa júnior de sênior:

Esses produtos não são equivalentes — eles são modelos mentais diferentes

---

🧠 RACF pensa em “organização”

Você define estrutura e depois controla acesso.

---

🧠 TSS pensa em “identidade”

Você dá poder direto ao usuário.

---

🧠 ACF2 pensa em “lógica”

Você escreve regras e deixa o sistema decidir.

---

🧨 Capítulo 4 — Onde os Projetos Quebram

Vamos direto ao campo de batalha.

🔥 Caso real 1 — Migração TSS → RACF

Problema:

• TSS:

  DIVISION / DEPARTMENT
  

• RACF:

  GROUP
  

👉 Não existe equivalência direta.

Resultado:

• perda de contexto
• decisões arquiteturais obrigatórias

---

🔥 Caso real 2 — ACF2 mal governado

ACF2 permite:

• regras complexas
• lógica condicional

👉 Sem controle vira:

“ninguém entende mais quem tem acesso a quê”

---

🔥 Caso real 3 — RACF mal configurado

Erro clássico:

UACC(READ)

👉 Tradução:

você abriu o dataset para meio mundo

---

🧠 Capítulo 5 — Como Eles Funcionam HOJE (2026)

🔵 RACF hoje

• integrado ao z/OS
• forte com ferramentas como:
  • auditoria
  • compliance
• padrão de mercado

👉 Usado em:

• bancos
• governo
• grandes corporações

---

🟢 TSS hoje

• ainda muito presente
• especialmente em ambientes antigos

👉 Problema:

• escassez de profissionais
• pressão de custo

---

🟣 ACF2 hoje

• nicho forte
• ambientes altamente customizados

👉 Perfil:

• organizações com regras complexas

---

🧩 Capítulo 6 — Easter Eggs de Quem Já Viveu Isso

🥚 1. O mito do “ALL”

No TSS:

ACCESS(ALL)

👉 Pode significar mais do que você imagina…

---

🥚 2. O clássico “por que isso funcionava antes?”

Resposta:

porque estava no TSS… e ninguém sabia

---

🥚 3. O fantasma do dataset genérico

PROD.*

👉 Um único profile pode abrir acesso para centenas de datasets.

---

🥚 4. O usuário com SPECIAL no RACF

👉 Isso aqui é praticamente “root do mainframe”

---

🧠 Capítulo 7 — Comparação Brutal (sem filtro)

Critério	RACF	TSS	ACF2
Governança	Alta	Média	Alta
Simplicidade	Média	Alta	Baixa
Flexibilidade	Alta	Média	Extremamente alta
Risco operacional	Médio	Médio	Alto
Mercado atual	Dominante	Caindo	Nicho

---

💣 Capítulo 8 — A Verdade que Poucos Dizem

Não existe “melhor” absoluto.

Existe:

• o mais adequado ao seu ambiente
• o mais governável pela sua equipe
• o menos arriscado para auditoria

---

🧠 Insight de arquiteto

Se você precisa:

• padronização → RACF
• simplicidade → TSS
• controle extremo → ACF2

---

🔥 Conclusão — A Guerra Invisível

Enquanto todo mundo fala de:

• cloud
• APIs
• microservices

No mainframe, a pergunta continua sendo a mesma há 40 anos:

“Quem pode fazer o quê?”

E a resposta continua dependendo de um desses três.

---

☕ Frase final estilo Bellacosa

“Você pode modernizar o COBOL, migrar para APIs, colocar z/OS Connect…
mas se errar no RACF, TSS ou ACF2 — nada disso importa.”

 

 

Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)

---

☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.

---

🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

• RACF
• SAF
• E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso

---

🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

• SAF → interface (o “porteiro”)
• RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄

---

🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

• Admin RACF → gerencia segurança
• Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável

---

💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.

---

🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

• Dados em disco
• Dados em trânsito
• Dados protegidos sem mudar aplicação

---

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

• Master Keys → topo da cadeia
• Symmetric → performance
• Asymmetric → troca segura
• Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.

---

⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express

---

🛡️ Níveis de proteção (isso é ouro de prova)

Nível	Segurança
Clear Key	😬
Protected Key	👍
Secure Key	🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)

---

💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

• código malicioso
• erro catastrófico

---

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

• TCP/IP (moderno)
• SNA (legado que ainda vive 😄)

Segurança:

• TLS → camada transporte
• IPSec → VPN (nível rede)

---

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar

---

🧪 Caso real (estilo Bellacosa)

Empresa com:

• RACF instalado
• Criptografia ativa
• Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.

---

🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”

---

🔥 Frases pra tatuar no cérebro

• “SAF conecta, RACF decide”
• “Sem PROTECTALL, está exposto”
• “Sem chave, não há segurança”
• “ALL = mostra tudo”
• “SPECIAL = poder total (cuidado!)”

---

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

• Foi projetado assim
• Evoluiu assim
• Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.

---

☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

 

Bellacosa Mainframe em uma conversa sobre segurança mainframe

🔥 SEU RACF ESTÁ TE PROTEGENDO… OU TE TRAINDO?

🧪 LAB PRÁTICO — Do Acesso Liberado ao Controle Total no z/OS

---

☕ Introdução — Bem-vindo ao caos controlado

Hoje você não vai só aprender…

👉 Você vai quebrar a segurança do sistema
👉 E depois consertar como um verdadeiro admin raiz

💡 Estilo Bellacosa:

“Se você nunca viu um sistema inseguro… você ainda não entendeu segurança.”

---

🎯 Objetivo do LAB

Você vai:

• ❌ Criar um cenário inseguro (sem proteção)
• 🔍 Explorar a falha
• 🛡️ Corrigir com RACF
• 🔐 Validar segurança

---

⚠️ Cenário

Você é admin e recebe:

“Precisamos liberar rápido o dataset PROD.FINANCEIRO.*”

😈 Spoiler: isso vai dar ruim.

---

🧪 FASE 1 — Criando o problema (sim, de propósito)

1️⃣ Criar dataset “sensível”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=PROD.FINANCEIRO.DADOS,
//      DISP=(NEW,CATLG),
//      SPACE=(TRK,(1,1)),
//      DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)

---

2️⃣ NÃO criar perfil RACF

👉 Sim… você vai deixar sem proteção

💡 Easter egg:

Isso acontece mais em produção do que você imagina 😅

---

3️⃣ Testar acesso com outro usuário

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Se PROTECTALL estiver OFF:

💥 Acesso permitido

---

💣 Resultado

Dataset crítico → sem perfil → acesso liberado 😱

---

🧠 REFLEXÃO

Você acabou de:

• Criar uma falha real
• Simular um incidente comum

👉 E ninguém hackeou nada

---

🛡️ FASE 2 — Corrigindo como profissional

1️⃣ Criar perfil de dataset

RDEFINE DATASET PROD.FINANCEIRO.* UACC(NONE)

---

2️⃣ Permitir acesso controlado

PERMIT PROD.FINANCEIRO.* CLASS(DATASET) ID(FINUSR) ACCESS(READ)

---

3️⃣ Ativar proteção

SETROPTS RACLIST(DATASET) REFRESH

---

4️⃣ (CRÍTICO) Ativar PROTECTALL

SETROPTS PROTECTALL

💥 Agora sim:

👉 Dataset sem perfil = acesso negado

---

🔍 FASE 3 — Validando segurança

Teste novamente:

TSO LISTDS 'PROD.FINANCEIRO.DADOS'

👉 Resultado esperado:

ICH408I USER NOT AUTHORIZED

🔥 Agora você está protegido

---

⚙️ FASE 4 — Explorando comando “ALL”

LD DA('PROD.FINANCEIRO.*') ALL

👉 Vai mostrar:

• Dono
• Permissões
• UACC
• Detalhes completos

💡 Frase pra vida:

“ALL = mostra tudo. Sem ALL = você está voando no escuro.”

---

🔐 FASE 5 — Elevando nível com SPECIAL

Criar usuário admin

ADDUSER ADMIN1 SPECIAL

👉 Esse usuário pode:

• Alterar tudo
• Criar perfis
• Controlar segurança

⚠️ Cuidado:

SPECIAL = poder total

---

⚙️ FASE 6 — Simulando programa privilegiado (APF)

👉 Imagine:

Um programa precisa acessar memória sensível

Sem APF:

❌ Falha

Com APF:

✅ Executa com privilégio

💡 Curiosidade:

Muitos ataques internos exploram programas mal autorizados no APF

---

🔐 FASE 7 — Criptografia (visão prática)

👉 Fluxo real:

App → ICSF → Crypto Express → dado protegido

Você não vê… mas está acontecendo.

---

📊 FASE 8 — Auditoria com SMF

👉 Tudo que você fez pode ser registrado:

• Acesso ao dataset
• Tentativas negadas
• Alterações

💡 Mas só se estiver configurado 😉

---

🧠 Easter Eggs do LAB

• PROTECTALL OFF = caos silencioso
• UACC(READ) mal usado = vazamento
• SPECIAL demais = bomba relógio
• Sem log = sem prova

---

🏁 Checklist final

Você aprendeu:

• ✔ Criar falha real
• ✔ Corrigir com RACF
• ✔ Controlar acesso
• ✔ Validar segurança
• ✔ Entender impacto

---

☕ Conclusão estilo Bellacosa

Segurança no mainframe não é:

• ferramenta
• comando
• checklist

É:

Mentalidade.

Porque no final…

👉 O sistema nunca erra
👉 Quem erra é quem configura

---

🔥 Desafio final

Responda:

Seu ambiente hoje está protegido…
ou só parece?

 

 

Bellacosa Mainframe e o AMOS uma porta dos fundos para roubar dados

🧠 AMOS: O Ladrão Invisível Que Não Roda no z/OS… Mas Já Pode Estar Roubando Seus Dados

“Você protege seu RACF. Blinda seu CICS. Controla seu batch.
Mas… e o endpoint do seu desenvolvedor COBOL? Quem está protegendo isso?”

---

☕ Introdução ao Estilo Bellacosa

No mundo do mainframe, existe um mantra silencioso:

“Se está no z/OS, está seguro.”

E na maioria das vezes… está mesmo.

Mas aqui vai o plot twist que poucos analistas seniores querem encarar:

👉 O problema moderno não começa dentro do mainframe. Ele começa fora.

Hoje vamos dissecar uma ameaça real, atual e crescente:

🔥 Atomic Stealer (AMOS)

---

🧬 O que é o AMOS (Atomic Stealer)?

O Atomic Stealer, também conhecido como AMOS, é um malware do tipo infostealer, projetado inicialmente para sistemas macOS — sim, aquele ambiente que muitos ainda chamam de “seguro por padrão”.

Ele atua roubando:

• Credenciais (navegadores, FTP, SSH)
• Cookies de sessão
• Carteiras de criptomoedas
• Tokens de autenticação
• Dados sensíveis armazenados localmente

👉 Em outras palavras:
Ele não invade o mainframe… ele invade quem acessa o mainframe.

---

🧠 A Nova Superfície de Ataque do z/OS

Você, analista COBOL sênior, já domina:

• RACF
• ACF2 / Top Secret
• Segurança de dataset
• Auditoria SMF
• Controles de acesso CICS/DB2

Mas me responda com franqueza:

👉 Você controla o notebook do desenvolvedor que acessa o TSO?

👉 Você audita o browser onde está o plugin de emulador 3270?

👉 Você garante que tokens de sessão não estão sendo roubados?

Se a resposta for “não totalmente”…

Então o AMOS já encontrou um ponto de entrada.

---

🕵️‍♂️ Anatomia do Ataque

O AMOS não precisa de APF autorizado.
Ele não precisa de IPL.
Ele não precisa nem saber o que é um dataset VSAM.

Ele funciona assim:

🔓 1. Engenharia Social

• Usuário baixa software pirata, plugin ou update falso
• Ou acessa link malicioso (phishing)

🧬 2. Execução Silenciosa

• Malware roda no endpoint (Mac/Windows)
• Coleta credenciais, cookies, tokens

📤 3. Exfiltração

• Dados enviados para servidores do atacante

🎯 4. Uso Inteligente

• Hacker usa sessão válida
• Acessa sistemas corporativos como usuário legítimo

👉 Inclusive:

• Acessos TSO
• Ferramentas FTP para datasets
• APIs REST via z/OS Connect

---

⚠️ O Impacto no Mundo Mainframe

“Mas o z/OS não foi invadido…”

Correto.

👉 Mas os dados foram.

E isso muda tudo.

💥 Possíveis impactos:

• Vazamento de dados sensíveis (clientes, contas, CPF)
• Acesso indevido a sistemas batch
• Execução de jobs maliciosos
• Exfiltração de arquivos via FTP/SFTP
• Comprometimento de credenciais privilegiadas

---

⚖️ LGPD: Onde o Problema Fica Sério

No contexto da Lei Geral de Proteção de Dados:

👉 Não importa onde ocorreu a falha.

Se houve vazamento de dados pessoais:

• A empresa é responsável
• Pode sofrer multas
• Pode ter dano reputacional severo

E aqui vem a bomba:

“Mas foi no notebook do desenvolvedor…”

👉 Irrelevante para a LGPD.

---

🔍 Auditoria: O Que Você NÃO Está Vendo

Ferramentas clássicas de auditoria no z/OS:

• SMF
• RACF logging
• CICS journaling

Elas vão mostrar:

✔ Login válido
✔ Acesso autorizado
✔ Comandos corretos

👉 Ou seja:
Tudo parece normal.

Porque o atacante está usando:

A identidade legítima do usuário.

---

🧠 O Paradoxo da Segurança Mainframe

O mainframe continua sendo o ambiente mais seguro.

Mas…

👉 A confiança no perímetro humano virou o elo fraco.

---

🛡️ Controles que um Analista COBOL Sênior Precisa Entender

Você não precisa virar especialista em cibersegurança.

Mas precisa evoluir sua visão.

🔐 1. Zero Trust

• Nunca confiar implicitamente no usuário
• Validar continuamente identidade e contexto

🔑 2. MFA (Multi-Factor Authentication)

• TSO
• VPN
• Ferramentas de acesso

🧾 3. Monitoramento Comportamental

• Detectar acessos fora do padrão
• Horários incomuns
• Volume anormal de leitura de datasets

🧬 4. Proteção de Endpoint

• Antimalware corporativo
• EDR (Endpoint Detection and Response)

📡 5. Segmentação de Acesso

• Limitar privilégios
• Evitar acessos amplos desnecessários

---

🧠 Curiosidades & Easter Eggs

💡 AMOS é vendido como serviço (Malware-as-a-Service)
👉 Hackers “alugam” o malware — modelo parecido com SaaS.

💡 Foco inicial em macOS
👉 Porque muitos profissionais de TI usam Mac… incluindo devs mainframe.

💡 Interface amigável para criminosos
👉 Painel web para visualizar dados roubados.

💡 Tokens são mais valiosos que senhas
👉 Permitem acesso sem autenticação adicional.

---

🧨 O Problema Ético

Aqui vai uma reflexão forte:

👉 O analista COBOL tradicional sempre confiou no ambiente controlado.

Mas agora…

• Seu código pode ser seguro
• Seu JCL pode estar perfeito
• Seu RACF pode estar blindado

E mesmo assim…

Seus dados podem estar sendo vendidos na dark web.

---

🧭 Conclusão: O Novo Papel do Analista Mainframe

O analista COBOL sênior de hoje precisa ser:

• Técnico ✔
• Experiente ✔
• Consciente de segurança moderna ✔✔✔

Porque o jogo mudou:

O ataque não vem mais pelo JCL…
Vem pelo clique do usuário.

---

🚀 Provocação Final

👉 Você revisa seu código COBOL com atenção extrema.

Mas…

Você já revisou o ambiente onde esse código é acessado?

 

Bellacosa Mainframe e o risco da Shadow AI

🧠 Shadow AI no Mainframe: O Inimigo Invisível Já Está Rodando no Seu Batch?

“Você auditou o código. Você validou o JCL. Você conferiu o RACF.
Mas… você auditou a IA que seu time está usando escondido?”

---

☕ Introdução ao Café (ou ao Alerta)

Se você é um analista COBOL sênior, já sobreviveu a muita coisa: migração de VSAM, tuning de DB2, quedas de CICS às 3 da manhã…

Mas agora, um novo risco silencioso entrou no jogo — e ele não aparece no JES2, nem no SMF:

👉 Shadow AI

Não está no inventário.
Não passou pelo Change Management.
Não foi homologada.

Mas já está sendo usada.

---

👻 O que é Shadow AI?

Shadow AI é o uso não autorizado ou não governado de ferramentas de inteligência artificial dentro da empresa.

Não estamos falando de um projeto oficial aprovado pela IBM ou integrado ao seu pipeline corporativo.

Estamos falando de algo muito mais perigoso:

• Um desenvolvedor colando código COBOL no ChatGPT
• Um analista usando IA para gerar JCL em produção
• Um operador pedindo ajuda para interpretar dumps sensíveis

Tudo isso fora do radar corporativo.

---

🧬 Origem do Problema: A Nova Shadow IT

Shadow AI nasce da velha conhecida:

👉 Shadow IT

Lá nos anos 2000, usuários começaram a usar:

• Planilhas fora do controle
• Scripts locais
• Ferramentas não homologadas

Agora, evoluímos.

A diferença?

Shadow AI aprende com os dados que você entrega.

E isso muda completamente o jogo.

---

🔥 O Risco Real (e Subestimado)

1. Vazamento de Dados Sensíveis

Você cola um copybook COBOL com dados reais…

Pode estar expondo:

• CPF
• Dados bancários
• Regras de negócio sigilosas

Isso é um pesadelo sob a Lei Geral de Proteção de Dados (LGPD).

---

2. Compliance e Auditoria

Pergunta simples:

Você consegue provar para uma auditoria como uma decisão foi tomada por uma IA externa?

Se não consegue…

👉 Você já perdeu.

Auditores não aceitam:

• “foi a IA que sugeriu”
• “copiei da ferramenta”

No mundo mainframe, tudo precisa de:

• Rastreabilidade
• Evidência
• Controle

Shadow AI quebra os três.

---

3. Segurança e Hacker

Agora imagine isso:

Um atacante sabe que seu time usa IA.

Ele pode:

• Induzir respostas com código malicioso
• Explorar prompts
• Fazer engenharia social baseada em IA

Isso é o novo vetor de ataque.

O hacker não invade seu z/OS…
Ele invade a mente do operador via IA.

---

4. Ética e Responsabilidade

Quem é responsável por um erro gerado por IA?

• O analista?
• A empresa?
• A ferramenta?

No mainframe, sempre existiu uma cultura:

👉 Responsabilidade total sobre o que roda em produção

Shadow AI quebra esse princípio.

---

🧱 Impacto no Mundo Mainframe

Você pode pensar:

“Mainframe é fechado, isso não me afeta.”

Erro clássico.

Impactos diretos:

• Código COBOL gerado sem padrões corporativos
• Violação de políticas de segurança
• Exposição de regras críticas de negócio
• Dependência invisível de IA externa
• Perda de governança técnica

---

🧠 Curiosidade (Easter Egg da História)

Sabia que o conceito de “shadow systems” já existia nos anos 70?

Na época dos primeiros sistemas IBM:

• Desenvolvedores criavam rotinas paralelas fora do controle central
• Muitas vezes mais eficientes… e perigosas

👉 A história não se repete… ela evolui.

Shadow AI é o novo “programa clandestino”.

---

🧩 Pontos de Atenção para o Analista COBOL Sênior

Se você quer se manter relevante (e seguro), comece aqui:

🔍 1. Crie Consciência no Time

Fale sobre o tema. Shadow AI cresce no silêncio.

---

🛡️ 2. Nunca Compartilhe Dados Reais

Regra de ouro:

Se está em produção → não entra na IA

---

📜 3. Exija Políticas Claras

Empresas precisam definir:

• O que pode ou não pode usar
• Quais ferramentas são autorizadas
• Como auditar uso de IA

---

🧾 4. Registre Tudo

Se usar IA:

• Documente
• Versione
• Justifique

---

🧠 5. Use IA com Inteligência

IA deve ser:

👉 Assistente
Não decisor

---

⚠️ O Paradoxo Final

A IA pode aumentar sua produtividade…

Mas também pode:

• Comprometer sua carreira
• Expor sua empresa
• Violar leis

Tudo depende de como você usa.

---

☕ Comentário ao Estilo Bellacosa

Mainframe sempre foi sinônimo de:

• Controle
• Confiabilidade
• Disciplina

Shadow AI é o oposto disso:

• Invisível
• Não auditável
• Imprevisível

E é exatamente por isso que é perigosa.

---

🎯 Conclusão: O Inimigo Não Está no Código

O maior risco não está no COBOL.

Nem no JCL.
Nem no CICS.

Está aqui:

Na decisão silenciosa de usar algo fora do controle.

---

Se o mainframe sobreviveu por décadas…

Foi porque sempre existiu uma coisa:

👉 Governança

Sem isso, até o sistema mais robusto vira vulnerável.

 

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:

1. JCL executa comandos RACF
2. Output vai para dataset
3. REXX lê dataset
4. Aplica regras de auditoria
5. 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:

1. ganha acesso
2. eleva privilégio
3. altera RACF
4. mantém persistência

🛡️ Auditoria automatizada:

1. detecta alteração
2. gera alerta
3. compara baseline
4. 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.”

 

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)

1. credencial fraca
2. acesso TSO/FTP
3. enumeração RACF
4. exploração (APF / FACILITY / USS)
5. persistência
6. 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ê.”