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

📘 Treinamento Completo de Auditoria z/OS

Bellacosa Mainframe treinamento em Auditoria em IBM Z/OS

📘 Treinamento Completo de Auditoria z/OS

Estilo Bellacosa Mainframe — do técnico ao auditável

"Auditoria em z/OS não é um evento. É um estado permanente de controle."

---

🎯 Objetivo do treinamento

Capacitar profissionais de mainframe a:

• Preparar ambientes z/OS para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Implementar governança contínua

Público-alvo:

• System Programmers

• Analistas de Segurança

• Auditores técnicos

• Arquitetos mainframe

---

🧱 Estrutura do treinamento

🧩 Módulo 1 – Fundamentos de Auditoria em z/OS

• O que o auditor realmente procura

• Tipos de auditoria (interna, externa, regulatória)

• Conceitos: evidência, rastreabilidade, segregação

• Por que z/OS já nasce auditável

📌 Entregável: checklist conceitual

---

🔐 Módulo 2 – Controle de Acesso (RACF)

• IDs privilegiados (SPECIAL, OPERATIONS)

• UACC e perfis genéricos

• Logging e SMF

• Revisão periódica de acessos

📌 Laboratório:

• Identificar riscos reais em perfis RACF

---

📦 Módulo 3 – SMP/E como pilar de integridade

• CSI, DLIB e TARGET

• RECEIVE, APPLY, ACCEPT

• APPLY CHECK

• ++HOLD, ++ERROR, ++VER

📌 Laboratório:

• Análise de PTF com HOLD de segurança

---

🧩 Módulo 4 – USERMOD e risco operacional

• Quando USERMOD é aceitável

• Documentação obrigatória

• Riscos em auditoria

• Plano de remoção

📌 Estudo de caso real

---

🔁 Módulo 5 – Gestão de Mudanças

• Integração SMP/E + Change Management

• Evidências exigidas

• Falhas clássicas em auditoria

📌 Oficina:

• Montar dossiê de mudança

---

🧪 Módulo 6 – Evidência técnica e rastreabilidade

• Outputs SMP/E

• Logs RACF

• SMF como prova

• Versionamento de JCL

📌 Laboratório:

• Criar pacote de evidências

---

🛡️ Módulo 7 – Segurança e Compliance

• PTFs de segurança

• Backlog e risco

• Auditorias regulatórias (SOX, PCI, LGPD)

📌 Discussão guiada

---

🔄 Módulo 8 – Continuidade e Recuperação

• Backup do CSI

• RESTORE na prática

• Testes documentados

📌 Laboratório:

• Simulação de rollback

---

📋 Módulo 9 – Auditoria passo a passo

• Como o auditor conduz a sessão

• Como responder perguntas difíceis

• O que nunca dizer

📌 Simulação completa de auditoria

---

🧠 Estudos de Caso Bellacosa

• USERMOD esquecido

• CSI sem backup

• ALTER irrestrito

• PTF de segurança atrasado

---

📜 Avaliação e Certificação

• Checklist executável preenchido

• Estudo de caso resolvido

• Avaliação prática

🎓 Certificado: Auditoria Técnica z/OS – Nível Profissional

---

🧰 Material complementar

• Checklist executável

• Modelos de evidência

• JCLs de laboratório

• Guia rápido para auditores

---

🏁 Encerramento

"No mainframe, auditoria não é medo. É maturidade operacional."

📘💾🛡️

📘 Treinamento Completo De Auditoria Z/os 

💾 Resumo para ir mais longe

A auditoria em ambientes z/OS é uma atividade fundamental para garantir a segurança, a conformidade regulatória e a integridade operacional dos sistemas mainframe. Considerado um dos ambientes computacionais mais seguros do mundo, o z/OS oferece recursos avançados de controle, monitoramento e rastreabilidade que auxiliam auditores e administradores na proteção das informações corporativas.

Um treinamento completo de auditoria z/OS normalmente aborda conceitos de governança, gestão de riscos, controle de acessos e análise de eventos de segurança. Entre os principais tópicos estudados estão o RACF (Resource Access Control Facility), gerenciamento de usuários, grupos, perfis de acesso, privilégios especiais e segregação de funções.

Outro tema essencial envolve a interpretação de registros SMF (System Management Facility), que armazenam informações detalhadas sobre atividades do sistema, acessos, execuções de jobs e eventos administrativos. Esses registros permitem rastrear ações realizadas por usuários e aplicações, auxiliando investigações e verificações de conformidade.

O treinamento também costuma abordar requisitos de auditoria relacionados a normas como SOX, LGPD, ISO 27001 e outras estruturas de governança corporativa. Ferramentas de monitoramento, geração de relatórios e análise de vulnerabilidades complementam o conteúdo.

Dominar auditoria em z/OS significa compreender não apenas aspectos técnicos, mas também processos, controles internos e práticas que garantem a confiabilidade de ambientes responsáveis por processar algumas das informações mais críticas do mundo corporativo.

 

Bellacosa Mainframe o que é RACF

O que é RACF?

RACF significa:

Resource Access Control Facility

É o principal sistema de segurança do ambiente IBM Mainframe desenvolvido pela IBM.

O RACF controla:

• usuários;

• senhas;

• grupos;

• datasets;

• transações CICS;

• recursos do sistema;

• comandos operacionais;

• aplicações.

Em resumo:

RACF é o "porteiro" do Mainframe.

---

Definição Simples

Sempre que alguém tenta acessar:

TSO
CICS
IMS
DB2
Dataset
JES2
Console

o RACF verifica:

Quem é você?
O que pode fazer?
Você tem autorização?

Se a resposta for não:

ACESSO NEGADO

---

Analogia Simples

Imagine um prédio corporativo.

O RACF seria:

• recepção;

• crachá;

• catraca;

• segurança.

Sem autorização ninguém entra.

---

Arquitetura Simplificada

Usuário
    ↓
Login
    ↓
RACF
    ↓
Validação
    ↓
Sistema

---

O que o RACF protege?

Usuários

USERID

---

Datasets

BANCO.CLIENTES

---

Transações CICS

SALD
PAGT
PIX1

---

Planos DB2

PLAN
PACKAGE

---

Comandos Operacionais

CANCEL
START
STOP

---

Conceitos Fundamentais

USER

Usuário do sistema.

Exemplo:

VBELLA01

---

GROUP

Grupo de usuários.

Exemplo:

DESENV
OPERACAO
SEGURANCA

---

RESOURCE

Recurso protegido.

Exemplo:

DATASET
CICS
DB2
JES

---

Estrutura RACF

GROUP
   ↓
USER
   ↓
PERMISSÕES

---

Exemplo

GRUPO: DESENV

USUÁRIO:
JOAO
MARIA
CARLOS

---

Classe de Recursos

O RACF organiza recursos em classes.

---

DATASET

Protege arquivos.

DATASET

---

CICS

Protege transações.

TCICSTRN

---

JES

Protege Jobs.

JESSPOOL

---

OPERCMDS

Protege comandos.

OPERCMDS

---

Como Funciona?

Usuário tenta acessar:

BANCO.CLIENTES

RACF verifica:

Existe usuário?
      ↓
Possui permissão?
      ↓
Liberar ou negar

---

Níveis de Permissão

NONE

Sem acesso.

---

READ

Somente leitura.

---

UPDATE

Alteração.

---

CONTROL

Controle avançado.

---

ALTER

Controle total.

---

Exemplo

DATASET

BANCO.CLIENTES

READ

Pode apenas consultar.

---

Comandos RACF Mais Conhecidos

ADDUSER

Criar usuário.

ADDUSER JOAO

---

ALTUSER

Alterar usuário.

ALTUSER JOAO

---

DELUSER

Excluir usuário.

DELUSER JOAO

---

ADDGROUP

Criar grupo.

ADDGROUP DESENV

---

CONNECT

Associar usuário ao grupo.

CONNECT JOAO
GROUP(DESENV)

---

LISTUSER

Consultar usuário.

LISTUSER JOAO

---

Perfil de Dataset

Exemplo:

BANCO.**

Protege todos os datasets:

BANCO.CLIENTES
BANCO.CONTAS
BANCO.EXTRATOS

---

Máscaras RACF

*

Um nível.

BANCO.*

---

**

Todos os níveis.

BANCO.**

---

Exemplo

BANCO.CLIENTES
BANCO.CLIENTES.TESTE
BANCO.CLIENTES.HIST

---

RACF e TSO

Ao entrar no TSO:

LOGON

o RACF valida:

• usuário;

• senha;

• grupo;

• privilégios.

---

RACF e CICS

Quando uma transação é executada:

SALD

RACF verifica:

Usuário autorizado?

---

RACF e DB2

Controla:

• tabelas;

• packages;

• plans;

• comandos administrativos.

---

RACF e JES2

Controla:

• SUBMIT;

• CANCEL;

• HOLD;

• OUTPUT.

---

Auditoria

O RACF registra eventos.

---

Exemplos

Login
Logoff
Falha senha
Tentativa acesso
Alteração perfil

---

SMF

As auditorias normalmente são gravadas em:

SMF

(System Management Facility)

---

Multifactor Authentication

Versões modernas suportam:

• Token

• Certificado Digital

• MFA

• OTP

---

Comandos de Consulta

LISTUSER

LISTUSER JOAO

---

SEARCH

SEARCH CLASS(DATASET)

---

RLIST

RLIST DATASET

---

Curiosidades

1. O RACF existe desde 1976

2. É um dos sistemas de segurança mais confiáveis do mundo

3. Protege bilhões de transações diariamente

4. Continua evoluindo com suporte a MFA e certificados digitais

5. É amplamente utilizado por bancos e governos

---

RACF x ACF2 x Top Secret

Produto	Fabricante
RACF	IBM
ACF2	Broadcom
Top Secret	Broadcom

Todos possuem funções semelhantes.

---

Resumo Rápido

Conceito	Função
RACF	Segurança Mainframe
USER	Usuário
GROUP	Grupo
RESOURCE	Recurso protegido
DATASET	Arquivo
READ	Leitura
UPDATE	Alteração
ALTER	Controle total
ADDUSER	Cria usuário
LISTUSER	Consulta usuário
SMF	Auditoria
MFA	Autenticação forte

---

Conclusão

O RACF (Resource Access Control Facility) é o principal sistema de segurança do Mainframe IBM Z. Ele controla autenticação, autorização e auditoria de usuários, protegendo datasets, aplicações CICS, bancos DB2, jobs JES2 e recursos críticos do sistema, garantindo que apenas pessoas autorizadas tenham acesso aos dados corporativos.