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 lab seu cics sob ataque

🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

Hands-on prático com CICS + DB2 para aprender segurança na marra

---

☕ INTRODUÇÃO

Você não vai só aprender…

👉 você vai:

• explorar vulnerabilidade
• corrigir
• validar

💣 exatamente como um atacante faria

---

🧪 LAB 1 — SQL INJECTION NO DB2

🎯 Objetivo

Mostrar como um COBOL pode ser vulnerável

---

💻 Código vulnerável

IDENTIFICATION DIVISION.
PROGRAM-ID. LOGIN.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER     PIC X(20).
01 WS-PASS     PIC X(20).

PROCEDURE DIVISION.

EXEC SQL
  SELECT NAME INTO :WS-USER
  FROM USERS
  WHERE NAME = :WS-USER
  AND PASSWORD = :WS-PASS
END-EXEC.

---

💣 Ataque

Input:

' OR '1'='1

---

💥 Resultado

👉 bypass de autenticação

---

✅ Correção

IF WS-USER NOT ALPHABETIC
   DISPLAY "INVALID INPUT"
   STOP RUN
END-IF.

---

💬 Insight

👉 validação é a primeira defesa

---

🧪 LAB 2 — BUFFER / TAMANHO DE INPUT

🎯 Objetivo

Evitar overflow e dados inválidos

---

💻 Problema

01 WS-NAME PIC X(10).

Input:

AAAAAAAAAAAAAAAAAAAAAAAAAAAA

---

💥 Resultado

👉 truncamento / corrupção

---

✅ Correção

IF LENGTH OF WS-NAME > 10
   DISPLAY "INPUT TOO LONG"
END-IF.

---

🧪 LAB 3 — HARDCODED PASSWORD

🎯 Objetivo

Eliminar segredo no código

---

❌ Código

MOVE "DB123456" TO WS-PASS.

---

💣 Problema

👉 vazamento garantido

---

✅ Correção

• usar RACF
• usar external security

👉 RACF

---

🧪 LAB 4 — VALIDAÇÃO DE COMMAREA (CICS)

🎯 Objetivo

Proteger entrada CICS

---

💻 Código vulnerável

MOVE DFHCOMMAREA TO WS-DATA.

---

💣 Problema

👉 dados maliciosos

---

✅ Correção

IF EIBCALEN = 0
   DISPLAY "NO DATA"
   RETURN
END-IF.

---

🧪 LAB 5 — LOGGING SEGURO

🎯 Objetivo

Evitar vazamento de dados

---

❌ Errado

DISPLAY "PASSWORD: " WS-PASS.

---

💣 Problema

👉 senha em log

---

✅ Correção

DISPLAY "LOGIN ATTEMPT".

---

🧪 LAB 6 — CONTROLE DE ACESSO (RACF)

🎯 Objetivo

Simular autorização

---

💻 Exemplo

CALL 'RACROUTE' USING ...

---

💬 Resultado

👉 só usuários autorizados acessam

---

🧪 LAB 7 — INTEGRAÇÃO COM API (RISCO REAL)

🎯 Objetivo

Simular API via CICS

---

💣 Problema

👉 input externo não confiável

---

✅ Solução

• validar JSON
• sanitizar campos

---

🧪 LAB 8 — TRATAMENTO DE ERRO

🎯 Objetivo

Não expor sistema

---

❌ Errado

DISPLAY SQLCODE.

---

💣 Problema

👉 revela estrutura interna

---

✅ Correto

DISPLAY "ERROR OCCURRED".

---

🧪 LAB 9 — CONTROLE DE TRANSAÇÃO

🎯 Objetivo

Evitar inconsistência

---

💻 Uso

EXEC CICS SYNCPOINT
END-EXEC.

---

💬 Importante

👉 protege integridade

---

🧪 LAB 10 — SIMULAR ATAQUE REAL

🎯 Objetivo

Mentalidade hacker

---

💻 Faça

• testar inputs inválidos
• tentar bypass
• observar comportamento

---

💥 Resultado

👉 descobrir falhas reais

---

🧠 VISÃO FINAL

Você fez:

• ataque
• defesa
• validação

👉 isso é segurança real

---

💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

 

Bellacosa Mainframe apresenta segurança em codigo

🔥💀 “SEU CÓDIGO ESTÁ SEGURO… OU SÓ AINDA NÃO FOI HACKEADO?”

Do Cartão Perfurado ao DevSecOps: como as mesmas falhas continuam derrubando sistemas — inclusive o seu

---

☕ INTRODUÇÃO — O ERRO QUE ATRAVESSOU DÉCADAS

Se você acha que segurança de aplicação é algo “moderno”…

👉 você já começou errado.

Há mais de 20 anos, os mesmos problemas que aparecem hoje na lista da OWASP já existiam.

E o mais assustador:

💣 Eles continuam sendo explorados hoje.

---

🧠 UM POUCO DE HISTÓRIA (SIM, ISSO COMEÇA NO MAINFRAME)

Antes de:

• APIs REST
• microservices
• cloud

…existia:

🧱 Mainframe + COBOL + CICS + DB2

E adivinha?

👉 Os mesmos problemas já estavam lá:

• input sem validação
• acesso indevido
• dados sensíveis expostos

---

💀 EASTER EGG HISTÓRICO

Nos anos 70–80, segurança era baseada em:

👉 “ninguém tem acesso físico ao terminal”

Spoiler:

💣 isso não durou muito

---

🔐 O NASCIMENTO DA SEGURANÇA REAL

Ferramentas como o RACF surgiram para resolver:

• quem pode acessar
• o que pode acessar
• quando pode acessar

👉 primeiro passo para segurança moderna

---

💣 O PROBLEMA REAL: NÃO É TECNOLOGIA

👉 É comportamento

Hoje temos:

• scanners
• IA
• automação
• cloud

E mesmo assim…

💥 vazamentos continuam acontecendo

---

📊 DADO REAL (que assusta)

Tempo médio para detectar um breach:

👉 ~212 dias

Tempo suficiente para:

• invadir
• explorar
• exfiltrar dados
• desaparecer

---

🔥 OWASP TOP 10 — O MANUAL DO ATACANTE

A OWASP lista os erros mais explorados.

E aqui vai o choque:

👉 quase todos são básicos

---

💣 EXEMPLO 1 — SQL INJECTION (O DINOSSAURO QUE AINDA MATA)

' OR 1=1 --

👉 isso ainda quebra sistemas hoje

---

💣 EXEMPLO 2 — XSS (VOCÊ CONFIA NO USUÁRIO?)

<script>stealCookies()</script>

👉 o browser executa
👉 o atacante assume a sessão

---

💣 EXEMPLO 3 — DEPENDÊNCIAS VULNERÁVEIS

Você escreve:

👉 20% do código

O resto?

👉 bibliotecas externas 😬

---

🛠️ DEVSECOPS — A VIRADA DE JOGO

Antes:

👉 segurança era responsabilidade de outro time

Hoje:

👉 “You build it, you run it… and you secure it.”

---

🔄 PIPELINE MODERNO

code → scan → test → deploy → monitor

Ferramentas:

• SAST (ex: análise estática)
• DAST (ataque simulado)
• SCA (dependências)
• runtime protection

---

🧪 MÃO NA MASSA (O QUE VOCÊ PRATICOU)

Você fez:

🔍 SAST

• analisou código sem rodar

---

🌐 DAST

• atacou a aplicação com ferramentas

---

📦 SCA

• descobriu vulnerabilidade em libs

---

🔐 Secrets

• saiu do hardcode → Vault

---

🐳 Docker Security

• corrigiu imagem vulnerável

---

👉 isso é exatamente o que empresas fazem hoje

---

💀 ERRO CLÁSSICO (QUE DERRUBA EMPRESA)

password = "123456"

👉 parece inofensivo

👉 vira incidente milionário

---

🧠 A VERDADE QUE NINGUÉM TE CONTA

👉 Segurança não falha por falta de ferramenta

👉 Segurança falha por:

• pressa
• ignorância
• negligência

---

🔥 CURIOSIDADE (QUE MUDA SUA VISÃO)

O maior ataque da história recente (Log4j):

👉 veio de uma biblioteca

Não do código principal

---

🚀 DO DEV AO ENGENHEIRO DE SEGURANÇA

Depois desse conhecimento, você não é mais só dev:

👉 você entende:

• como atacar
• como defender
• onde estão os riscos

---

🧱 E O COBOL NISSO TUDO?

Tudo isso se aplica em:

• CICS
• DB2
• APIs via z/OS Connect

---

👉 Mainframe não é imune
👉 ele só é mais disciplinado

---

💬 FRASE PRA GRAVAR

“Você não precisa ser hackeado para estar vulnerável…
basta ignorar o básico.”

---

🔥 CONCLUSÃO (SEM FILTRO)

👉 Se você não:

• valida input
• protege secrets
• escaneia dependências
• monitora

💣 seu sistema já está em risco

---

🚀 CHAMADA FINAL

Agora você tem duas opções:

👉 continuar escrevendo código
ou
👉 começar a proteger sistemas