 |
| Bellacosa Mainframe apresenta o ACEE Parte I |
☕💥 A Jornada do Sysprog Padawan – Parte 1
ACEE – O Crachá Mágico do Reino IBM Z
O Control Block que quase ninguém conhece, mas que todos utilizam diariamente
"No Mainframe, existem estruturas que todo mundo usa, poucas pessoas enxergam e quase ninguém compreende completamente. O ACEE é uma delas."
Bellacosa Mainframe
Introdução
Todo Sysprog iniciante aprende rapidamente algumas siglas que parecem fazer parte de uma língua secreta:
PSA
CVT
TCB
ASCB
RB
CSA
SQA
RACF
SAF
Mas existe um pequeno personagem que vive escondido dentro da memória do z/OS e que participa de praticamente todas as decisões de segurança do sistema:
O ACEE
Accessor Environment Element
E aqui está algo curioso:
Você provavelmente utilizou milhares de ACEEs durante sua carreira sem nunca perceber.
Toda vez que alguém faz logon no TSO.
Toda vez que uma transação CICS é executada.
Toda vez que um usuário acessa USS via SSH.
Toda vez que um JOB é submetido.
Toda vez que DB2 verifica uma autorização.
Toda vez que MQ abre uma fila.
Existe uma boa chance de um ACEE estar envolvido.
O Reino IBM Z
No estilo Bellacosa Mainframe, imagine o z/OS como um reino medieval gigantesco.
O reino possui:
O Cartório Real
RACF
O Guarda do Portão
SAF
O Livro de Ocorrências
SMF
A Oficina dos Magos
ICSF
O Distrito Unix
USS
O Rei
Sysprog
E existe um objeto extremamente importante:
O crachá do visitante
Esse crachá é o ACEE.
Quando um visitante entra no castelo, ele recebe um documento dizendo:
Quem ele é.
A quais guildas pertence.
Quais áreas pode visitar.
Se possui privilégios especiais.
Qual certificado utiliza.
Seu UID UNIX.
Seu MFA.
Suas etiquetas de segurança.
Enquanto estiver dentro do castelo, ninguém precisa voltar ao cartório para perguntar novamente quem ele é.
Basta olhar o crachá.
Este crachá é exatamente o papel do ACEE.
O que significa ACEE?
Accessor Environment Element
Nome curioso.
Mas faz sentido.
Accessor
Quem acessa.
Environment
Seu contexto operacional.
Element
Estrutura residente.
Podemos traduzir informalmente como:
Contexto de Segurança do Usuário em Execução
Ou
Cartão de identidade vivo do z/OS
Por que a IBM criou o ACEE?
Precisamos voltar algumas décadas.
Década de 70
MVS começava a crescer.
TSO expandia.
CICS ganhava força.
DB2 ainda nem existia.
Imagine:
500 usuários simultâneos.
Cada READ.
Cada OPEN.
Cada EXEC CICS.
Precisasse consultar RACF.
Seria um desastre.
O custo seria:
CPU
I/O
ENQ
Contenção
Latência
Então a IBM criou uma ideia brilhante.
Após autenticar.
Copiar informações relevantes.
Colocar tudo em memória.
Consultar apenas memória.
Nascia o ACEE.
A primeira geração
MVS
RACF 1.x
Conceito simples.
Userid
Grupo
Authority
Poucos campos.
Pequena estrutura.
Segunda geração
MVS/XA
MVS/ESA
Mais atributos.
Mais flags.
Suporte:
CICS
IMS
VTAM
OS/390
A internet chegou.
SSL.
Certificados.
ACEE cresceu.
Passou a armazenar:
Digital Certificates
UID
GID
z/OS
USS.
LDAP.
Kerberos.
MFA.
Passphrase.
Tokens.
JWT integration.
Custom attributes.
z/OS 3.1
Uma das novidades interessantes.
Campos customizados.
Melhor integração.
Menor I/O.
Maior escalabilidade.
O ACEE não é um Dataset
Esse é um erro comum.
O ACEE não está armazenado em:
SYS1
SYSUSER
VSAM
DB2
Ele vive em memória.
É um Control Block
Assim como:
TCB
ASCB
CVT
PSA
RB
Sysprogs adoram control blocks.
E o ACEE é um dos mais importantes.
Onde ele fica?
Depende.
TSO
Associado ao usuário.
Batch
Associado ao JOB.
CICS
Associado à região.
Ou à transação.
IMS
Associado ao BMP.
MPP.
Transaction.
USS
Associado ao processo POSIX.
MQ
Associado ao requester.
DB2
Associado ao thread.
O nascimento do ACEE
Vamos acompanhar.
Etapa 1
Usuário
Digita:
LOGON VBELLACO
Etapa 2
SAF recebe.
Etapa 3
RACF consulta banco.
Verifica:
Senha
Passphrase
MFA
Certificado
Etapa 4
RACF monta ACEE
Carrega:
Userid
Groups
UID
Authorities
Flags
Tokens
Labels
Etapa 5
Entrega para sistema.
Etapa 6
Sessão ativa.
Fluxo simplificado
USER
│
▼
TSO
│
▼
SAF
│
▼
RACF
│
▼
CREATE ACEE
│
▼
SESSION
O relacionamento com o RACF
Muitos acreditam:
RACF é consultado a todo instante.
Não exatamente.
Após criação do ACEE.
A maioria das verificações utiliza informações já carregadas.
Benefícios
Menos I/O
Menos CPU
Menos contenção
Melhor throughput
O relacionamento com SAF
SAF é o porteiro.
SAF recebe pergunta.
Consulta ACEE.
Caso necessário.
Consulta RACF.
Retorna resposta.
Exemplo
CICS
│
▼
SAF
│
▼
ACEE
│
▼
ALLOW
O relacionamento com SMF
SMF gosta de registrar tudo.
Usuário conecta.
SMF grava.
Usuário desconecta.
SMF grava.
Troca senha.
SMF grava.
Falha MFA.
SMF grava.
Tentativa inválida.
SMF grava.
Auditores adoram isso.
Sysprogs nem sempre.
O relacionamento com APF
Outro conceito interessante.
Programas APF.
Podem manipular ACEE.
Criar.
Clonar.
Substituir.
Passar contexto.
Ferramentas IBM fazem isso.
CICS faz.
DB2 faz.
IMS faz.
MQ faz.
Mas isso exige muito cuidado.
O segredo que poucos sabem
ACEE é praticamente invisível.
Usuário comum nunca vê.
Desenvolvedor COBOL raramente vê.
Administrador DB2 raramente pensa nele.
Mas sem ele.
Segurança moderna do z/OS seria extremamente lenta.
Curiosidade Bellacosa ☕
Se o RACF fosse o cartório do reino.
O SAF fosse o guarda.
E o SMF fosse o cronista.
O ACEE seria:
O crachá encantado entregue ao visitante quando ele atravessa os portões do castelo.
Enquanto o visitante estiver no reino, ninguém precisa perguntar novamente quem ele é.
O crachá responde por ele.
Para guardar na memória
O RACF sabe quem você é.
O SAF pergunta se você pode entrar.
O SMF anota tudo o que aconteceu.
Mas é o ACEE que acompanha você por todo o reino IBM Z.
☕💥 Continua na Parte 2
Anatomia do ACEE
Campos internos, flags, segmentos OMVS, certificados, MFA, UID/GID, ACEE Tokens, estruturas relacionadas e as novidades escondidas do z/OS 3.1.
Sem comentários:
Enviar um comentário