Segurança do z/OS com RACF: perfis de usuário, grupo e dataset, e por que agentes precisam de privilégio mínimo

O que é

O System Authorization Facility (SAF) é a interface que os componentes do z/OS chamam para perguntar "este usuário tem permissão para fazer isso?"; o RACF (Resource Access Control Facility, parte do z/OS Security Server) é o produto de segurança mais comumente conectado a essa interface para responder à pergunta, embora existam outros produtos compatíveis com o SAF. O RACF organiza o acesso em torno de perfis: um perfil de usuário para cada user ID, perfis de grupo para conjuntos de usuários e perfis de recurso — incluindo perfis de dataset — que indicam o que está protegido e quem pode acessar, com qual nível de acesso (leitura, atualização, alteração e assim por diante).

LISTUSER userid exibe os atributos de um perfil de usuário e os grupos aos quais ele está conectado; LISTDSD lista perfis de dataset, inclusive perfis genéricos que cobrem todo um padrão de nomes, e não apenas um nome exato de dataset. O acesso é concedido com PERMIT depois que o perfil existe (criado com ADDSD para datasets e RDEFINE para recursos gerais): por exemplo, PERMIT profile-name CLASS(CSFSERV) ID(groupID) ACCESS(READ) concede acesso de leitura a um recurso definido para um ID de grupo, o que normalmente é preferível a liberar user IDs individuais um a um. Em uma classe mantida em memória (RACLISTed, como costuma ser a CSFSERV), as alterações só entram em vigor depois de SETROPTS RACLIST(class) REFRESH; perfis genéricos de dataset alterados podem exigir SETROPTS GENERIC(DATASET) REFRESH para os trabalhos que já estão em execução.

A orientação da própria IBM é explícita: os comandos de listagem do RACF — LISTUSER, LISTDSD, LISTGROUP, RLIST — foram projetados para serem emitidos e lidos por uma pessoa; o formato da saída não é uma interface de programação suportada, não tem estabilidade garantida entre releases, e a IBM não oferece suporte à análise (parsing) dessa saída por programas. Os programas devem usar as interfaces documentadas que a IBM indica: o arquivo de saída do utilitário de descarga do banco de dados IRRDBU00, RACROUTE REQUEST=EXTRACT ou ICHEINTY.

Por que importa

Um agente de automação é exatamente o tipo de ator que a administração do RACF deve restringir com rigor: ele deve se autenticar com um user ID próprio, dedicado e de escopo restrito, com apenas o acesso que sua tarefa exige, sem reaproveitar um ID de administrador com amplos privilégios; e qualquer script que faça parsing do texto de LISTUSER/LISTDSD depende de uma interface que, segundo a IBM, não se destina a programas.

Como aplicar

• Provisione um user ID RACF distinto para cada tarefa automatizada ou agente, conectado ao mínimo de grupos, com o mínimo de acesso a recursos e sem os atributos de abrangência de sistema SPECIAL, OPERATIONS ou AUDITOR.
• Conceda acesso por meio de perfis de grupo e PERMIT, em vez de liberar IDs individuais, de modo que a revisão de acessos seja feita no nível do grupo.
• Prefira uma interface de relatório suportada a fazer parsing da saída de LISTUSER/LISTDSD quando um programa precisar desses dados.
• Revise periodicamente os perfis de dataset e de recursos gerais em busca de níveis de ACCESS mais amplos do que a tarefa exige (por exemplo, ALTER onde READ bastaria).

Armadilhas

• Executar a automação sob um ID TSO compartilhado ou altamente privilegiado "para evitar problemas de permissão", o que anula a auditabilidade e viola o privilégio mínimo.
• Tratar LISTUSER * ou listagens igualmente sem limite como uma chamada normal de automação; a IBM observa que essa saída pode esgotar a memória do address space e aponta o IRRDBU00 como alternativa.