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 fala sobre RACF e Zero Trust sobrevivendo na cloud

🔐🏛️ Do RACF ao Zero Trust: o Manual Secreto do Padawan para Sobreviver na Selva Cloud

“Na dúvida, negue o acesso.” — provavelmente um sábio administrador de RACF em 1987

Se você vem do mundo mainframe… parabéns.
Você já foi treinado na ordem Jedi da segurança corporativa.

Se você é novo… prepare-se.
A cloud é menos “datacenter climatizado” e mais Mad Max com APIs.

Este guia é um mapa completo — estilo Bellacosa — para entender Cloud Security de verdade, conectando:

🏛️ Mainframe
☁️ Cloud
🔐 Zero Trust
👤 IAM
🛡️ Criptografia
🚧 CASB, CSPM, RBAC e companhia

Tudo com exemplos práticos, curiosidades e alguns easter eggs 😄

---

🧠 Capítulo 1 — O maior mito da segurança antiga

Antigamente:

“Se está dentro da rede, pode confiar.”

Modelo 🏰 Castle & Moat

• Firewall na borda
• Rede interna confiável
• Usuários conhecidos
• Sistemas centralizados

Funcionava… até aparecer:

💣 Internet
💣 Mobilidade
💣 SaaS
💣 Trabalho remoto
💣 Phishing

---

💥 Problema fatal

Se o invasor entrasse…

➡️ Tinha acesso lateral quase ilimitado
➡️ Movimentação interna fácil
➡️ Detecção tardia

---

🧠 Capítulo 2 — Zero Trust: paranoia como arquitetura

🔐 “Never trust. Always verify.”

Zero Trust assume:

👉 O atacante pode já estar dentro
👉 Nenhum dispositivo é confiável
👉 Nenhum usuário é confiável
👉 Nem a rede interna é confiável

---

🧩 O que o Zero Trust protege

• 👤 Usuários
• 💻 Dispositivos
• 📦 Workloads
• 🌐 Tráfego
• 💾 Dados

---

💡 Easter egg mainframe

Se você conhece RACF:

👉 Zero Trust não é tão novo assim…

Mainframe já fazia:

✔ Least privilege
✔ Auditoria rigorosa
✔ Controle centralizado
✔ Autorização explícita

---

👤 Capítulo 3 — IAM: o novo perímetro

Na cloud:

🔑 Identidade = Firewall humano

IAM decide:

✔ Quem pode acessar
✔ O quê
✔ Como
✔ Quando
✔ Em quais condições

---

🔐 Trio sagrado da identidade

👤 IdP — armazena identidades

🚀 SSO — login único

🛡️ MFA — prova reforçada

---

💣 Exemplo real

Senha vazada:

❌ Sem MFA → invasão
✅ Com MFA → bloqueado

---

🎭 Capítulo 4 — RBAC: o acesso segue o cargo

RBAC = Role-Based Access Control

Permissões baseadas na função, não na pessoa.

---

🏢 Exemplo clássico

👩‍💼 RH → Folha de pagamento
🧑‍💻 Help Desk → Contas de login
👩‍💻 Dev → Código

---

⚠️ O erro mortal

Dar acesso demais.

Muitos incidentes começam com:

“Esse usuário não deveria ter acesso a isso…”

---

☁️ Capítulo 5 — Shared Responsibility: a armadilha da cloud

Muita gente acha:

“Está na cloud, então está seguro.”

❌ Errado.

Modelo correto:

🤝 Responsabilidade Compartilhada

---

☁️ Provedor protege

🏢 Datacenter
🧱 Hardware
🌐 Infraestrutura física

---

🧑‍💼 Cliente protege

👤 Usuários
💾 Dados
⚙️ Configurações
🔐 Permissões

---

💣 A maioria dos vazamentos ocorre por erro do cliente.

---

🔐 Capítulo 6 — Criptografia: dados que se protegem sozinhos

Cloud é distribuída.
Dados viajam.

Sem criptografia:

👉 Dados legíveis para qualquer interceptador.

---

🔒 Estados do dado

💾 At rest — armazenado
🚚 In transit — em movimento
🧠 In use — em processamento

---

🔑 Dois métodos fundamentais

🔒 Simétrica (AES)

• Rápida
• Grandes volumes
• Discos, bancos, storage

---

🔐 Assimétrica (RSA, ECC)

• Troca segura de chaves
• Certificados
• Identidade

---

🌐 TLS na prática

Quando você vê 🔒 no navegador:

1️⃣ Servidor apresenta certificado
2️⃣ Cliente verifica CA
3️⃣ Negociam chave
4️⃣ Comunicação segura

---

🏛️ Curiosidade poderosa — Mainframe novamente

IBM Z possui:

👉 Pervasive Encryption

Criptografa praticamente tudo por padrão:

• Disco
• Banco
• Rede
• Backup
• Dados exportados

Mainframe sendo futurista desde o século passado 😎

---

🚀 Capítulo 7 — FHE: criptografia nível ficção científica

Fully Homomorphic Encryption permite:

🧠 Processar dados SEM descriptografar

Imagine:

🏥 Hospital analisando dados médicos na cloud
🏦 Banco processando dados financeiros confidenciais

Sem revelar os dados.

Ainda emergente — mas revolucionário.

---

🌐 Capítulo 8 — CASB: o guarda da nuvem

Cloud Access Security Broker

Fica entre usuários e serviços cloud.

---

🔎 Detecta

✔ Uploads suspeitos
✔ Compartilhamento indevido
✔ Uso de apps não autorizados
✔ Vazamento de dados

---

💣 Combate Shadow IT

Funcionário usando ferramentas pessoais com dados corporativos.

Sem CASB → invisível
Com CASB → monitorado ou bloqueado

---

🔧 Capítulo 9 — CSPM: detector de erros humanos

Maior risco da cloud:

❌ Configuração incorreta

CSPM monitora:

• Storage público
• Permissões excessivas
• Falta de criptografia
• Serviços expostos

---

💥 Caso clássico

Bucket público com dados sensíveis.

Acontece mais do que você imagina.

---

📦 Capítulo 10 — CWPP e CNAPP: proteção total

📦 CWPP

Protege workloads:

• VMs
• Containers
• Apps

---

🚀 CNAPP

Combina:

✔ CSPM
✔ CWPP
✔ Segurança de apps
✔ Proteção em runtime

---

🧠 Capítulo 11 — Framework NIST: ciclo completo

Identify → Protect → Detect → Respond → Recover

Segurança não é um estado.

É um processo contínuo.

---

🏁 Conclusão — O verdadeiro segredo

🔐 Segurança moderna não protege apenas sistemas.
👤 Protege identidades.
💾 Protege dados.
🌐 Protege o negócio digital inteiro.

---

🏆 Mensagem final ao Padawan

Se você domina:

✔ Identidade
✔ Privilégio mínimo
✔ Criptografia
✔ Visibilidade
✔ Configuração correta

👉 Você domina a segurança na cloud.

---

☕ Easter Egg final (nível Bellacosa)

Se um administrador mainframe viajasse no tempo para hoje, ele provavelmente diria:

“Vocês reinventaram o RACF… só que distribuído e com marketing.”

 

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 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ê.”