1. O que é RACF e o modelo de segurança

O RACF funciona com três elementos centrais:

  • Sujeito — quem solicita o acesso: um usuário (USERID) ou um grupo de usuários (GROUP).
  • Objeto — o que está sendo acessado: um dataset, um programa, um terminal, um job class.
  • Perfil de segurança — a regra que define quem pode fazer o quê com aquele objeto.

Quando um programa tenta acessar um dataset protegido, o z/OS chama o RACF. O RACF consulta o seu banco de dados de perfis (o RACF database), identifica o perfil que cobre aquele dataset, verifica se o usuário tem permissão e autoriza ou rejeita o acesso — tudo em microssegundos.

🦕 Analogia — RACF como portaria de prédio corporativo

Imagine um prédio onde cada sala tem uma fechadura eletrônica. A portaria (RACF) tem a lista de quem pode entrar em cada sala. Quando você aproxima seu crachá (USERID) de uma porta (recurso), a portaria consulta a lista, verifica se você tem acesso e abre ou não. Você não negocia com a porta — a decisão é centralizada na portaria.

2. Tipos de perfil

O RACF organiza a segurança em quatro tipos de perfil:

TipoO que protegeComando principal
USER Identidade de um usuário — senha, atributos, grupos ADDUSER / LISTUSER
GROUP Conjunto de usuários com acesso similar ADDGROUP / LISTGRP
DATASET Datasets — sequenciais, PDS, VSAM ADDSD / LISTDSD
GENERAL RESOURCE Tudo mais — terminais, jobs, programas, facilities RDEFINE / RLIST

3. UACC — níveis de acesso

O UACC (Universal Access Authority) define o nível de acesso padrão para todos os usuários que não estão explicitamente listados no perfil. Os níveis são hierárquicos:

UACCO que permiteUso típico
NONENenhum acesso — precisa de permissão explícitaDatasets de produção sensíveis
READLeitura apenasDatasets de referência compartilhados
UPDATELeitura e escritaDatasets de trabalho da equipe
CONTROLUPDATE + controle de PDSsRaro — geralmente desnecessário
ALTERAcesso total — incluindo DELETE e RENAMEOwner do dataset

💡 UACC NONE é o padrão seguro

Em ambientes bem configurados, datasets de produção têm UACC(NONE) — ninguém acessa sem estar explicitamente na lista de permissões. Isso força que cada acesso seja intencional e auditável. Datasets com UACC(READ) ou maior são "abertos" para leitura por qualquer usuário do sistema — use com cuidado.

4. Como o RACF decide quem pode acessar

Quando um acesso é solicitado, o RACF segue uma hierarquia de decisão bem definida:

  1. O usuário tem atributo BYPASS? → acesso concedido incondicionalmente.
  2. O recurso está protegido por um perfil RACF? → se não, aplica-se o padrão da instalação (geralmente acesso livre ou negado).
  3. O usuário está na lista de acesso (access list) do perfil? → aplica a permissão específica dele.
  4. O grupo do usuário está na lista de acesso? → aplica a permissão do grupo.
  5. Nenhuma entrada específica? → aplica o UACC do perfil.
  6. UACC é NONE? → acesso negado.
Exemplo de decisão RACF: Dataset: PRODUCAO.CLIENTES.DADOS Perfil: PRODUCAO.CLIENTES.* UACC(NONE) Access list: MARIA READ GRPDESENV UPDATE GRPADMIN ALTER Usuário JOAO (membro de GRPDESENV) tenta UPDATE: → Não está na access list individualmente → Grupo GRPDESENV tem UPDATE → Acesso CONCEDIDO com UPDATE Usuário PEDRO (sem grupo específico) tenta READ: → Não está na access list → Grupo dele não está na access list → UACC = NONE → Acesso NEGADO

5. RACF, ACF2 e TopSecret

O z/OS suporta três sistemas de segurança externos (ESMs — External Security Managers). O RACF é o produto IBM, mas muitas instalações usam alternativas:

ESMFabricanteCaracterística principal
RACFIBMModelo baseado em perfis de recurso — proteção por objeto
ACF2Broadcom (CA)Modelo baseado em regras por usuário — proteção por sujeito
TopSecretBroadcom (CA)Modelo baseado em departamentos e divisões

Os conceitos de segurança (perfis, access lists, UACC) são similares entre os três. Se você aprender RACF, vai conseguir se orientar nos outros com alguma adaptação. Esta trilha foca exclusivamente no RACF.