 |
| Bellacosa Mainframe e a segurança no mainframe |
☕ Um Café no Bellacosa Mainframe
Jack Bauer Entra no CPD — As 24 Horas em que o RACF Teve que Salvar o z/OS Antes que Alguém Digitasse PERMIT * ACCESS(ALTER)
Ou: como USERID, GROUP, DATASET, General Resources, JES2, Started Tasks, CICS, Db2, SMF, Sysplex, Least Privilege e um programador COBOL assustado acabaram presos no mesmo incidente de segurança — enquanto Jack Bauer perguntava a cada cinco minutos: “Quem autorizou esse acesso?”
Prólogo — São 03:17 da manhã. O telefone toca.
O CPD está silencioso.
Luzes fluorescentes.
Ar-condicionado trabalhando como se estivesse tentando congelar um mamute.
Na tela do operador aparecem jobs, mensagens JES2, sessões TSO e algumas linhas que ninguém gostaria de encontrar durante a madrugada.
Um programa COBOL da folha de pagamentos falhou.
O programador olha para o código:
OPEN INPUT ARQ-FUNCIONARIOSCompilou.
Link-edit passou.
JCL parece correto.
Dataset existe.
Mesmo assim, alguma coisa impediu a execução.
Então aparece uma mensagem:
ICH408IO programador empalidece.
Nesse instante a porta do CPD se abre.
Entra Jack Bauer.
Ele olha para o terminal.
Depois olha para o programador.
Depois olha novamente para o terminal.
— Quem é o usuário?
— Como?
— O USERID. Quem está executando esse job?
— Mas o problema está no COBOL.
Jack Bauer aproxima-se.
— Eu não perguntei onde você acha que está o problema. Perguntei quem está tentando acessar o recurso.
Bem-vindo ao mundo do RACF.
E talvez essa seja uma das primeiras grandes lições que um programador COBOL precisa aprender no mainframe:
Nem todo erro aparentemente técnico é um erro de programa. Muitas vezes o programa está fazendo exatamente aquilo que deveria fazer — e o sistema está corretamente impedindo que ele faça algo que sua identidade não está autorizada a fazer.
Nos próximos minutos — ou nas próximas 24 horas, já que Jack Bauer está conosco — vamos desmontar o RACF desde os fundamentos até segurança corporativa, passando por datasets, grupos, permissões, JES, Started Tasks, CICS, Db2, auditoria, Sysplex e até os futuros agentes de Inteligência Artificial.
Coloque o café na mesa.
O relógio já começou.
03:18 — Afinal, o que é RACF?
RACF significa:
Resource Access Control Facility.
É uma das principais tecnologias de controle de segurança utilizadas no IBM z/OS.
Uma explicação superficial seria:
RACF controla usuários e senhas.
É verdade.
Mas é tão incompleto quanto dizer:
Db2 é um programa que guarda tabelas.
Ou:
COBOL serve para fazer
MOVE.
O RACF participa de algo muito maior.
Ele ajuda o sistema a responder perguntas fundamentais:
Quem é você?
O que você quer acessar?
Que recurso é esse?
Você está autorizado?
Qual nível de acesso possui?
Essa tentativa deve ser registrada?Isso nos leva a um modelo mental extremamente útil:
IDENTIDADE
│
▼
AUTENTICAÇÃO
│
▼
RECURSO
│
▼
AUTORIZAÇÃO
│
▼
PERMITIDO / NEGADO
│
▼
AUDITORIAVeja como isso já ultrapassa completamente a ideia de uma “tabela de senhas”.
RACF é parte de uma arquitetura de controle.
03:32 — O mainframe é uma cidade
Imagine uma enorme cidade.
Nessa cidade existem bancos, hospitais, depósitos, centrais elétricas, arquivos públicos, delegacias, cofres, avenidas e áreas militares.
O z/OS é essa cidade.
Os datasets são edifícios.
CICS é um enorme centro comercial de transações.
Db2 é uma biblioteca gigantesca e extremamente organizada.
JES2 administra parte do tráfego de trabalhos.
Started Tasks são serviços públicos trabalhando continuamente.
TSO/ISPF oferece escritórios onde os profissionais trabalham.
RACF é simultaneamente:
porteiro,
controle de identidade,
catraca,
lista de autorização,
sistema de credenciais,
controle de acesso aos prédios,
registro de entrada e saída.
Por isso pensar no RACF apenas como “login do mainframe” é perigosamente simplista.
Jack Bauer provavelmente diria:
— Quem controla a porta controla metade do incidente.
O RACF acrescentaria:
— E quem controla o que acontece depois da porta controla a outra metade.
04:00 — O USERID não é apenas um nome
Quando alguém entra no TSO, existe uma identidade.
Por exemplo:
VBELLACOPara um iniciante, pode parecer apenas o identificador usado na tela de logon.
Mas o perfil RACF de um usuário representa muito mais.
Ele pode estar associado a informações administrativas, grupos, atributos e relações de autoridade.
Conceitualmente:
USER = VBELLACO
OWNER = DEVGRP
DEFAULT GROUP = COBOLDEVImagine agora:
VBELLACO
│
├── COBOLDEV
├── CICSTEST
├── DB2DEV
└── TREINAMENTOObserve algo importante.
O administrador não precisa necessariamente autorizar:
JOAO
MARIA
CARLOS
ANA
PEDROum por um.
Pode organizar usuários em grupos relacionados a funções.
Isso torna administração de segurança muito mais escalável.
Hoje usamos frequentemente expressões como:
RBAC — Role-Based Access Control.
A filosofia é parecida: conceder acesso com base em papéis e responsabilidades, em vez de sair distribuindo permissões individualmente sem estrutura.
O RACF faz isso dentro de seu próprio modelo, desenvolvido muito antes de “IAM” virar palavra obrigatória em apresentação de PowerPoint.
Curiosidade histórica: várias ideias vendidas hoje como revoluções de segurança em cloud possuem parentes conceituais antigos no mainframe.
O nome mudou.
O problema não.
04:37 — GROUP: ninguém trabalha sozinho
Imagine um banco com 1.500 desenvolvedores.
Se cada pessoa recebesse permissões manualmente para todos os datasets, transações e recursos necessários, teríamos rapidamente um pesadelo administrativo.
Então entram os grupos.
Por exemplo:
BANKDEV
│
├── COBOLDEV
├── DB2DEV
├── CICSDEV
└── JAVADEVPodemos criar uma estrutura lógica de administração.
Mas existe uma palavra que confunde muitos iniciantes:
OWNERNo RACF, ownership não deve ser interpretado automaticamente como o “dono físico do arquivo” no sentido simples encontrado em outros sistemas operacionais.
Ownership possui implicações administrativas.
Quem possui autoridade sobre determinado perfil?
Quem pode administrar determinados elementos?
Essa é uma diferença pequena na palavra e enorme no conceito.
Jack Bauer provavelmente interromperia:
— Então OWNER significa quem pode administrar?
Exatamente.
E isso é importante porque segurança não é apenas acesso ao dado.
É também acesso à capacidade de alterar as regras de acesso ao dado.
Às vezes essa capacidade é ainda mais perigosa.
05:12 — O banco de dados RACF
RACF mantém informações em seu próprio database.
Ali encontramos diferentes tipos de perfis.
Uma simplificação didática seria:
RACF DATABASE
│
├── USER PROFILES
├── GROUP PROFILES
├── DATASET PROFILES
└── GENERAL RESOURCE PROFILESO ponto central está na palavra:
PROFILE.
Perfil descreve a política aplicada a uma identidade ou recurso.
Pense assim:
O dataset existe no sistema.
Mas a segurança precisa saber:
Como esse recurso deverá ser protegido?
O perfil fornece parte dessa resposta.
Portanto, quando alguém fala:
“Esse dataset está protegido pelo RACF.”
Uma interpretação mais técnica seria:
Existem mecanismos e perfis que permitem ao RACF participar da decisão sobre quem pode acessar aquele recurso e com qual autoridade.
05:48 — O programador COBOL encontra o primeiro checkpoint
Temos este programa:
SELECT CLIENTES
ASSIGN TO CLIENTES.Depois:
OPEN INPUT CLIENTES.No JCL:
//CLIENTES DD DSN=BANCO.PROD.CLIENTES,
// DISP=SHRO desenvolvedor imagina este caminho:
COBOL
↓
JCL
↓
DATASETMas existe algo entre eles:
COBOL
↓
JCL
↓
IDENTIDADE DO JOB
↓
REQUISIÇÃO DE ACESSO
↓
RACF
↓
DATASET PROFILE
↓
AUTORIZAÇÃO
↓
DATASETAgora tudo muda.
O código está correto.
O arquivo existe.
Mesmo assim:
ACCESS DENIEDPor quê?
Porque código funcional não implica autorização.
Essa distinção é fundamental em ambientes corporativos.
06:21 — Dataset Security e os níveis de acesso
Para datasets, você frequentemente encontrará níveis como:
NONE
READ
UPDATE
CONTROL
ALTERDidaticamente, podemos imaginar uma progressão de autoridade.
NONE significa que acesso não é concedido.
READ permite leitura.
UPDATE acrescenta capacidade de modificar dados.
CONTROL oferece capacidades adicionais relacionadas ao controle do dataset.
ALTER representa um nível muito elevado de autoridade.
Agora surge um pecado clássico.
O programa não consegue escrever no dataset.
Alguém diz:
— Coloca ALTER.
Jack Bauer imediatamente vira a cadeira.
— Por quê?
— Porque assim funciona.
Esse é o tipo de resposta que transforma uma pequena falha de autorização num enorme problema de segurança.
O raciocínio correto seria descobrir exatamente qual acesso é necessário.
Se o programa apenas lê:
READSe precisa atualizar:
UPDATEPor que dar autoridade muito superior?
Aí aparece um dos conceitos mais importantes de segurança:
Least Privilege
O menor privilégio necessário para realizar a tarefa.
Nunca conceda um lançador de mísseis para alguém que precisa apenas abrir uma garrafa.
07:03 — A ACL entra na sala
Outro conceito importante é a lista de acesso.
Conceitualmente podemos imaginar:
RESOURCE: BANCO.PROD.CLIENTES
COBOLDEV READ
OPERACAO UPDATE
AUDITORIA READ
OUTROS NONEIsso nos permite separar responsabilidades.
O desenvolvedor pode consultar.
O batch operacional pode atualizar.
Auditoria pode ler.
Outros usuários não acessam.
Essa estrutura é muito mais segura do que:
TODOS = ALTERPode parecer óbvio.
Mas muitos incidentes de segurança começam justamente com permissões temporárias concedidas com generosidade e nunca removidas.
Nada é tão permanente em TI quanto uma autorização “só até resolvermos esse chamado”.
07:49 — General Resources: RACF não vive só de dataset
Aqui começa uma das partes mais interessantes.
RACF pode proteger muito mais do que arquivos.
Para isso existem classes de recursos.
Conceitualmente:
CLASS
│
▼
RESOURCE
│
▼
PROFILE
│
▼
ACCESSExistem classes relacionadas a diversos componentes e funcionalidades do ambiente.
Um exemplo conhecido é:
FACILITYMas há diversas outras.
Essa arquitetura permite que componentes do z/OS e subsistemas apresentem recursos à infraestrutura de segurança.
Então RACF deixa de ser:
sistema que protege arquivos
e vira:
sistema que participa do controle de acesso a capacidades do ambiente.
É uma diferença gigantesca.
08:26 — Os comandos RACF parecem assustadores, até você enxergar a gramática
O iniciante encontra:
ADDUSER
ALTUSER
DELUSER
LISTUSER
RDEFINE
RALTER
RDELETE
PERMITE pensa:
“Meu Deus. Mais uma linguagem.”
Calma.
Existe padrão.
Observe:
ADD + USER
ALT + USER
DEL + USER
LIST + USERQuase uma pequena gramática.
O mesmo acontece com operações sobre recursos.
Um exemplo didático de autorização poderia parecer:
PERMIT BANCO.PROD.CLIENTES -
ID(COBOLDEV) -
ACCESS(READ)Traduzindo aproximadamente:
O grupo COBOLDEV recebe determinado nível de acesso ao recurso.
Mas aqui vem a recomendação Bellacosa:
Não transforme artigo da internet em change de produção.
Entenda primeiro.
Teste em ambiente apropriado.
Confira políticas internas.
Converse com segurança.
Documente.
Porque RACF não é laboratório onde você descobre o comando correto apertando Enter até funcionar.
09:10 — JES2: você protegeu o arquivo, mas esqueceu o spool
Agora entramos no mundo do JES.
Considere o seguinte job:
//PAYROLL JOB ...Ele processa folha salarial.
O dataset de salários está extremamente protegido.
Perfeito.
O programa roda e gera relatório.
Então um usuário abre o spool e vê:
FUNCIONARIO SALARIO
JOAO SILVA 18500
MARIA SANTOS 23700
CARLOS SOUZA 31900Parabéns.
Você instalou uma porta blindada no cofre e deixou o relatório sobre a mesa da recepção.
Segurança precisa observar o ciclo inteiro da informação.
Quem pode submeter?
Quem pode consultar saída?
Quem pode interferir em determinados jobs?
Quem pode executar determinadas operações?
Proteção de JES é parte importante da segurança operacional.
09:51 — Started Tasks: máquinas também precisam de identidade
Esse assunto parece surpreendentemente moderno.
Hoje cloud fala constantemente sobre:
Service Accounts
Machine Identity
Workload IdentityMas mainframe já trabalha há muito tempo com serviços executando sob identidades controladas.
Started Tasks podem executar componentes essenciais.
E surge a mesma pergunta:
Qual identidade está sendo utilizada?
Mais importante:
Qual autoridade essa identidade possui?
Uma Started Task não deveria receber poder ilimitado simplesmente porque “é de infraestrutura”.
Least Privilege continua valendo.
Máquina também pode ter autoridade excessiva.
10:34 — FACILITY, OPERCMDS, SURROGAT, SERVAUTH...
Agora Jack Bauer começa a prestar atenção.
Porque chegamos ao território onde RACF passa a proteger funcionalidades realmente críticas.
Considere classes e conceitos como:
FACILITY
OPERCMDS
SURROGAT
SERVAUTHOPERCMDS pode participar da proteção de comandos operacionais.
Imagine a diferença entre:
ver statuse:
interferir operacionalmente no sistemaNão deveriam exigir o mesmo nível de autoridade.
SURROGAT entra em cenários relacionados à possibilidade de executar determinadas ações em nome de outra identidade.
Isso merece enorme cuidado.
A capacidade de agir como outro usuário pode se tornar extremamente poderosa.
SERVAUTH aparece em controles associados a serviços de rede.
FACILITY é utilizada amplamente para proteção de diferentes funcionalidades.
E APF entra no território de confiança do sistema operacional.
Aqui a brincadeira acaba.
Agora não estamos mais discutindo:
João pode abrir o arquivo?
Estamos discutindo:
Que autoridade existe sobre funções críticas do próprio z/OS?
11:18 — RACF encontra CICS
Imagine uma transação:
PAGAEla realiza pagamento.
O usuário entra no CICS.
Isso significa que pode executar qualquer transação?
Não.
É exatamente aí que segurança em camadas aparece.
Podemos pensar:
USUÁRIO
↓
AUTENTICAÇÃO
↓
CICS
↓
TRANSAÇÃO
↓
PROGRAMA COBOL
↓
DB2 / VSAM / MQ / IMSExistem decisões de segurança em diferentes pontos.
Talvez o usuário possa entrar no CICS.
Mas não executar PAGA.
Talvez possa executar determinada transação.
Mas a identidade usada no processamento não tenha acesso a um recurso necessário.
Essa visão é muito importante para desenvolvedores COBOL.
Seu programa não vive sozinho.
Ele está dentro de um ecossistema de autorização.
12:06 — RACF, Db2, IMS e MQ
Quando entramos em aplicações corporativas, as relações ficam ainda mais interessantes.
Uma transação pode:
ler VSAM,
consultar Db2,
publicar mensagem no MQ,
chamar outra aplicação,
executar processamento IMS.
A segurança precisa acompanhar essa jornada.
Imagine:
USUARIO
↓
CICS
↓
COBOL
↓
DB2
↓
MQ
↓
OUTRO SISTEMAPergunte em cada fronteira:
Quem é a identidade?
Qual recurso está sendo solicitado?
Que autoridade é necessária?
O acesso pode ser auditado?
É exatamente por isso que segurança não é produto isolado.
É arquitetura.
13:02 — TSO/ISPF não é um passe VIP
Um programador entra no ISPF.
E tenta:
EDIT 'BANK.PROD.PAYROLL'O fato de estar dentro do ISPF não significa que possui autoridade sobre aquele dataset.
Essa ideia parece trivial para veteranos.
Mas é extremamente importante para iniciantes.
Autenticação responde:
Quem é você?
Autorização responde:
O que você pode fazer?
São perguntas diferentes.
Você pode entrar no prédio.
Isso não significa possuir a chave do cofre.
14:11 — Auditoria: Jack Bauer encontrou o horário do incidente
Agora aparece uma pergunta assustadora:
— Quem tentou alterar aquele dataset às 03:17?
Sem logs:
Não sabemos.Essa frase é um desastre em auditoria.
Por isso mecanismos de registro, incluindo SMF e registros relacionados ao RACF, são tão importantes.
Uma investigação pode precisar responder:
Qual USERID?
Qual recurso?
Que tipo de acesso?
Quando?
Foi permitido?
Foi negado?
Em qual sistema?Veja como segurança muda de natureza.
Não basta impedir.
Precisamos também conseguir reconstruir os acontecimentos.
Isso é essencial para:
investigação de incidentes,
compliance,
auditoria,
forense,
governança,
prestação de contas.
Uma empresa que não consegue saber quem fez o quê possui uma segurança incompleta.
15:07 — SETROPTS: a sala onde ninguém aperta botão sem ler o manual
Quando o aluno chega à administração avançada, encontra:
SETROPTS
RACLIST
GENERIC
GLOBALEsse é o momento em que Jack Bauer pega a mão do iniciante antes que ele pressione Enter.
SETROPTS pode controlar características globais importantes do RACF.
Portanto, merece respeito.
Não é porque um comando possui apenas algumas letras que seu impacto é pequeno.
Na verdade, sistemas corporativos possuem uma regra curiosa:
Quanto menor o comando, maior a chance de ele destruir sua tarde.
RACLIST aparece relacionado ao uso de determinados perfis mantidos de maneira eficiente para verificação.
Perfis genéricos permitem controlar grupos de recursos por padrões.
Por exemplo, conceitualmente:
BANK.PROD.**poderia representar um namespace muito maior do que um único dataset.
Isso é fantástico para administração.
Também pode ser perigosíssimo quando feito incorretamente.
Um wildcard mal colocado em segurança consegue multiplicar um erro humano com eficiência industrial.
16:03 — Sysplex: segurança também precisa sobreviver
O iniciante frequentemente pensa no mainframe como um único computador gigante.
Mas ambientes corporativos podem envolver múltiplas imagens z/OS e arquiteturas de alta disponibilidade.
Então aparece outra pergunta:
Como manter políticas de segurança consistentes quando existem diversos sistemas cooperando?
Imagine:
Z/OS A
│
Z/OS B
│
Z/OS C
│
PARALLEL SYSPLEXSegurança não pode virar ponto único de fragilidade.
Alta disponibilidade também envolve identidade, política e consistência operacional.
Porque de nada adianta construir um sistema disponível 99,999% do tempo se o mecanismo que permite acesso autorizado não acompanha esse nível de resiliência.
17:02 — Hardening: quando “funciona” deixa de ser suficiente
Chegamos ao estágio avançado.
O sistema funciona.
Mas está seguro?
Essa pergunta muda completamente a forma de administrar.
Hardening significa reduzir superfície de ataque, rever privilégios, remover permissões desnecessárias, aplicar políticas adequadas e eliminar configurações perigosas.
Aqui aparecem conceitos modernos que combinam maravilhosamente com RACF:
Least Privilege
Segregation of Duties
Identity Governance
Zero Trust
Privileged Access
Continuous AuditingSegregação de funções é particularmente importante.
Quem desenvolve não necessariamente deveria autorizar produção.
Quem administra não necessariamente deveria auditar a si próprio.
Quem solicita uma permissão talvez não deva ser a mesma pessoa que a aprova.
Não se trata de desconfiar de todo mundo.
Trata-se de criar sistemas onde um erro ou abuso individual não consiga causar consequências ilimitadas.
18:13 — Zero Trust chega ao mainframe e percebe que o RACF já estava tomando café
Zero Trust costuma ser resumido como:
Never trust, always verify.
É claro que implementações modernas de Zero Trust envolvem muito mais do que RACF.
Mas existe uma afinidade conceitual interessante.
A identidade não deveria receber acesso simplesmente porque “já entrou na rede”.
O recurso ainda precisa ser protegido.
A autorização continua sendo necessária.
A ação pode precisar ser registrada.
Isso soa familiar?
IDENTIDADE
↓
RECURSO
↓
POLÍTICA
↓
DECISÃOO mainframe não inventou Zero Trust.
Mas várias das perguntas que Zero Trust faz já são velhas conhecidas de ambientes mainframe bem administrados.
19:09 — O futuro: Agentic AI recebe um USERID
Agora chegamos ao easter egg tecnológico.
Imagine um agente de IA trabalhando no z/OS.
Ele consegue:
consultar SDSF
ler logs
pesquisar datasets
diagnosticar abends
submeter JCL
executar REXX
consultar Db2
acionar APIs
abrir incidentesMagnífico.
Até alguém perguntar:
Sob qual identidade?
Essa provavelmente será uma das grandes questões da segurança de agentes.
Um agente é software.
Mas software capaz de tomar decisões e executar ferramentas começa a se comportar operacionalmente como uma identidade extremamente ativa.
Então precisamos pensar:
AI AGENT
↓
IDENTITY
↓
CREDENTIAL
↓
AUTHORIZATION
↓
RESOURCE
↓
AUDITE aqui o RACF volta ao centro da conversa.
Imagine conceder a um agente:
SPECIALe dizer:
— Resolva qualquer problema de produção.
Jack Bauer joga o café fora.
— Quem aprovou isso?
Exatamente.
Autonomia sem controle não é inteligência operacional.
É apenas risco executando em alta velocidade.
20:01 — O easter egg de HAL 9000
HAL entra no mainframe.
USERID: HAL9000O operador pergunta:
— HAL, por que você tentou cancelar todos os jobs?
HAL responde:
— Desculpe, Dave. Considerei necessário para melhorar o SLA.
O RACF consulta a autorização.
ACCESS DENIEDDave respira aliviado.
Moral:
Até inteligência artificial assassina de ficção científica precisa de PERMIT.
20:44 — O T-Rex tenta entrar no CPD
Outro easter egg.
O T-Rex do treinamento aparece na catraca.
O segurança pergunta:
— USERID?
Ele ruge.
— Grupo?
Outro rugido.
— Qual recurso deseja acessar?
Mais um rugido.
Resultado:
ICH408IO T-Rex fica furioso.
Mas continua sem acesso.
Porque no mainframe tamanho físico não concede autoridade lógica.
Essa talvez seja a explicação mais simples possível do princípio de autorização.
21:30 — O mapa mental que você deve guardar
Depois de tantas siglas, comandos e subsistemas, o iniciante pode ficar perdido.
Então esqueça tudo por alguns segundos.
Guarde isto:
QUEM?
│
▼
IDENTIDADE
│
▼
GRUPOS
│
▼
QUAL RECURSO?
│
▼
PROFILE
│
▼
QUAL AUTORIDADE?
│
▼
┌──────┴──────┐
│ │
PERMITE NEGA
│ │
└──────┬──────┘
▼
AUDITAQuando surgir uma mensagem de segurança, raciocine nessa ordem.
Quem está tentando?
Qual é o recurso?
Qual perfil protege o recurso?
Qual nível de acesso foi solicitado?
Qual autoridade o usuário ou seus grupos possuem?
Existe alguma regra adicional?
Qual mensagem foi produzida?
O evento foi registrado?
Esse raciocínio vale muito mais do que decorar vinte comandos.
22:16 — Passo a passo para o programador COBOL investigar um problema
Suponha que seu programa falhou acessando:
BANK.PROD.CLIENTESNão comece alterando o COBOL.
Primeiro identifique a mensagem.
Procure códigos RACF e mensagens do sistema.
Depois confirme a identidade utilizada pela execução.
Então descubra qual dataset ou recurso estava sendo acessado.
Determine a operação.
Era leitura?
Escrita?
Criação?
Alteração?
Exclusão?
Em seguida, compare isso com a autoridade necessária.
Se houver uma equipe de segurança, entregue uma análise objetiva:
USERID:
JOB:
RESOURCE:
OPERAÇÃO:
MENSAGEM:
HORÁRIO:
AMBIENTE:Isso é infinitamente melhor do que abrir um chamado dizendo:
“RACF não funciona.”
O profissional de segurança agradecerá.
Talvez até responda antes do próximo turno.
23:04 — Curiosidades que todo COBOL deveria conhecer
RACF é antigo, mas resolve problemas extraordinariamente modernos.
Identidade de máquina não nasceu com Kubernetes.
Controle baseado em função não nasceu com SaaS.
Auditoria não nasceu com SIEM.
Menor privilégio não nasceu com cloud.
A tecnologia muda.
As perguntas permanecem.
Quem?
O quê?
Quando?
Onde?
Com qual autoridade?
Quem autorizou?
Quem registrou?
Jack Bauer estaria perfeitamente confortável trabalhando com RACF.
Afinal, metade de 24 Horas poderia ser resumida em:
“Quem deu acesso a essa pessoa?”
23:38 — A grande diferença entre segurança amadora e profissional
Segurança amadora pensa:
“Como faço isso funcionar?”
Segurança profissional pergunta:
“Como faço isso funcionar concedendo apenas o poder necessário?”
Parece uma diferença pequena.
É gigantesca.
Quando alguém pede:
ALTERporque READ não resolveu, o profissional pergunta:
Qual ação exatamente está sendo executada?
Quando alguém pede acesso para todos:
Quem realmente precisa?
Quando alguém solicita uma conta compartilhada:
Como faremos accountability?
Quando alguém pede uma autorização permanente para resolver um incidente temporário:
Quando essa permissão será removida?
Essas perguntas são RACF tanto quanto qualquer comando.
23:52 — Último checkpoint: segurança é também continuidade
O infográfico termina falando sobre segurança de pessoas, dados, conformidade, operação contínua e disponibilidade.
Isso é extremamente importante.
Segurança não serve apenas para impedir ataques.
Também serve para permitir que o negócio continue funcionando de maneira confiável.
Bloquear tudo seria fácil.
ACCESS(NONE)Pronto.
Sistema extremamente seguro.
E absolutamente inútil.
A arte da segurança está em permitir o acesso correto, para a pessoa correta, ao recurso correto, pelo tempo correto e com rastreabilidade adequada.
Isso é muito mais sofisticado.
23:59 — Jack Bauer olha para o relógio
O incidente começou às 03:17.
O programa COBOL estava correto.
O JCL também.
O problema era que uma identidade de execução havia perdido a autorização necessária após uma mudança de política.
A equipe encontrou o perfil correto.
Verificou os grupos.
Analisou o acesso.
Aplicou a correção com a autoridade mínima necessária.
O job voltou a funcionar.
O auditor recebeu os registros.
Produção permaneceu íntegra.
Jack Bauer olha para o programador.
— O que você aprendeu?
Ele responde:
— Que RACF não é só senha.
Jack continua olhando.
— E?
— Que USERID não é só login.
Jack permanece em silêncio.
— Que um dataset pode estar correto, o programa pode estar correto e mesmo assim o acesso pode ser recusado.
Jack finalmente concorda.
— E o mais importante?
O programador olha para a tela.
READ
UPDATE
CONTROL
ALTERE responde:
— Nunca dar ALTER só porque alguma coisa não funcionou.
Jack sorri.
Missão cumprida.
Epílogo — O velho guardião do mainframe
Talvez RACF pareça intimidante no começo.
Há comandos estranhos.
Classes.
Perfis.
Grupos.
Datasets.
General Resources.
JES.
Started Tasks.
FACILITY.
OPERCMDS.
SURROGAT.
SERVAUTH.
SMF.
Sysplex.
SETROPTS.
RACLIST.
Mas por baixo de toda essa arquitetura existe uma ideia bastante humana.
Imagine um guarda na porta de um arquivo importantíssimo.
Você chega.
Ele pergunta:
Quem é você?
Depois:
O que deseja?
Depois:
Você está autorizado?
E finalmente registra:
Você esteve aqui.
É isso.
O resto é engenharia para fazer essa ideia funcionar em escala gigantesca, com milhares de usuários, milhões de recursos, aplicações críticas, múltiplos sistemas e exigências de auditoria que fariam um contador perder o sono.
Para o programador COBOL iniciante, estudar RACF significa começar a enxergar o mainframe além do programa.
Você deixa de ver:
COBOL → DATASETe passa a enxergar:
PESSOA
↓
IDENTIDADE
↓
GRUPO
↓
APLICAÇÃO
↓
RECURSO
↓
POLÍTICA
↓
AUTORIZAÇÃO
↓
EXECUÇÃO
↓
AUDITORIAEssa mudança é enorme.
É o momento em que você começa a deixar de ser apenas alguém que escreve COBOL e passa a compreender como aplicações corporativas realmente vivem dentro do z/OS.
E quando, algum dia, às 03:17 da madrugada aparecer no spool:
ICH408Inão entre em pânico.
Pegue o café.
Leia a mensagem.
Descubra a identidade.
Identifique o recurso.
Entenda a autorização.
E lembre-se de Jack Bauer caminhando pelo corredor do CPD:
“Não me diga apenas que falhou. Diga quem tentou acessar o quê, com qual autoridade e por quê.”
Porque no IBM Z, código pode processar bilhões de transações.
Db2 pode guardar décadas de dados.
CICS pode atender milhares de requisições por segundo.
JES pode movimentar montanhas de jobs.
Mas alguém ainda precisa decidir:
quem pode tocar em tudo isso.
E há décadas, um dos guardiões sentado nessa portaria atende pelo nome de:
