 |
| Bellacosa Mainframe e os guardioes do reino ibm z acee saf e apf |
☕💥 Um Café no Bellacosa Mainframe
Os Guardiões Invisíveis do Reino IBM Z
ACEE, SAF e APF – As Três Relíquias que Protegem Trilhões de Dólares Todos os Dias
Por Vagner Bellacosa – Bellacosa Mainframe
Existe algo curioso sobre segurança em Mainframe.
Quase todo mundo conhece RACF.
Muitos ouviram falar de SAF.
Poucos sabem explicar o que realmente é um ACEE.
E uma quantidade ainda menor entende por que o APF talvez seja um dos componentes mais importantes de toda a arquitetura do z/OS.
A verdade é que, por trás das telas verdes, dos CICS, dos IMS, dos DB2 e dos bilhões de transações financeiras processadas diariamente, existe um pequeno conjunto de tecnologias silenciosas que trabalha vinte e quatro horas por dia, sete dias por semana, há décadas, praticamente sem reconhecimento.
São os verdadeiros guardiões do Reino IBM Z.
E talvez seja hora de apresentar estes personagens aos novos Padawans do z/OS.
O Reino IBM Z
Gosto bastante de utilizar uma analogia medieval para explicar segurança no Mainframe.
Imagine um enorme castelo.
Existem bibliotecas.
Existe um tesouro.
Existem escribas.
Existem correios.
Existem soldados.
Existe um cartório.
E existe o Rei.
No Reino IBM Z, podemos imaginar algo semelhante.
CICS é a administração do castelo.
IMS é o departamento financeiro.
DB2 é a biblioteca.
MQ é o correio.
USS é o bairro moderno onde vivem os moradores Unix.
SMF é o historiador oficial.
RACF é o cartório real.
O Sysprog é o guardião das chaves.
Mas três personagens trabalham praticamente o tempo inteiro.
SAF.
ACEE.
APF.
Eles são pouco conhecidos pelos desenvolvedores COBOL.
Quase invisíveis para operadores.
E absolutamente fundamentais para os Sysprogs.
SAF – O Porteiro Invisível
Um dos maiores equívocos entre profissionais iniciantes é acreditar que CICS conversa diretamente com RACF.
Ou que DB2 consulta diretamente o RACF.
Ou ainda que MQ valida permissões diretamente no banco de dados de segurança.
Na realidade, quase todos os produtos do z/OS conversam primeiro com o SAF.
SAF significa System Authorization Facility.
Ele pode ser entendido como um grande barramento de segurança.
Ou melhor.
Um porteiro.
Imagine uma recepção sofisticada na entrada do castelo.
Toda pessoa que deseja entrar em uma sala precisa passar pela recepção.
A recepcionista não toma decisões.
Ela apenas consulta o cartório.
Recebe uma resposta.
E libera ou bloqueia a passagem.
SAF funciona exatamente assim.
Aplicação.
↓
SAF.
↓
RACF.
↓
Resposta.
Isso permite que produtos IBM e produtos terceiros utilizem um mecanismo único de autorização.
Foi uma ideia brilhante da IBM.
Caso contrário, CICS precisaria implementar seu próprio sistema de segurança.
IMS teria outro.
DB2 outro.
MQ outro.
USS outro.
Seria praticamente impossível administrar um ambiente corporativo de grande porte.
Hoje, bilhões de solicitações de segurança passam pelo SAF diariamente.
E a maioria das pessoas sequer percebe sua existência.
ACEE – O Crachá Mágico
Outro personagem pouco conhecido é o ACEE.
Access Control Environment Element.
Se o SAF é o porteiro, o ACEE é o crachá.
Imagine um funcionário chegando ao prédio.
No primeiro acesso ele apresenta documentos.
Passa por verificações.
Tem sua identidade validada.
Recebe um crachá.
A partir daquele momento não precisa mostrar documentos novamente.
Basta apresentar o crachá.
O ACEE funciona exatamente desta maneira.
Quando um usuário faz LOGON no TSO.
Ou acessa um CICS.
Ou estabelece uma sessão SSH.
O RACF executa um VERIFY.
Autentica o usuário.
Cria um ACEE.
E entrega esse contexto de segurança para a aplicação.
O ACEE contém informações extremamente importantes.
Userid.
Grupos.
UID Unix.
Certificados.
Labels.
Atributos especiais.
Contexto OMVS.
Permissões.
Flags.
Tudo armazenado em memória.
O objetivo é simples.
Evitar milhões de consultas desnecessárias ao RACF.
Imagine um banco processando cem mil transações por segundo.
Sem ACEE.
Cada autorização consultaria novamente o banco de segurança.
Seria inviável.
Com ACEE.
O sistema apenas consulta estruturas já residentes em memória.
Menos CPU.
Menos I/O.
Menos contenção.
Maior escalabilidade.
Talvez o ACEE seja um dos control blocks com melhor retorno sobre investimento da história da computação corporativa.
APF – O Selo Dourado do Reino
Mas existe algo ainda mais poderoso.
APF.
Authorized Program Facility.
Este é provavelmente o componente mais respeitado por um Sysprog experiente.
E também um dos mais perigosos.
No Reino IBM Z, podemos imaginar APF como um selo dourado concedido pelo Rei.
Nem todos recebem este selo.
Somente programas altamente confiáveis.
Programas autorizados podem executar serviços privilegiados.
Manipular armazenamento protegido.
Executar operações supervisor state.
Realizar chamadas especiais.
Interagir profundamente com o núcleo do sistema.
Mas isso possui um preço.
Um programa autorizado incorretamente pode comprometer toda a integridade do ambiente.
Por isso, APF é tratado com extremo cuidado.
Para que um módulo seja considerado autorizado normalmente dois requisitos precisam ser atendidos.
Primeiro.
O programa deve possuir AC(1).
Segundo.
A biblioteca onde reside deve estar presente na lista APF.
Caso contrário.
Nada feito.
O z/OS simplesmente não concede os privilégios especiais.
E é justamente isso que protege o sistema.
Quando Tudo Dá Errado
Todo Sysprog eventualmente recebe uma ligação de madrugada.
03:17.
Produção parada.
DB2 acusa segurança.
MQ acusa RACF.
USS apresenta Permission Denied.
CICS responde Not Authorized.
E alguém inevitavelmente diz:
"O problema é no RACF."
Talvez.
Mas talvez não.
O profissional experiente sabe que precisa investigar.
Verificar SMF80.
Consultar zSecure.
Analisar mensagens ICH408I.
Abrir IPCS.
Localizar o ACEE.
Examinar o contexto.
Conferir grupos.
Checar FASTAUTH.
Validar APF.
Verificar classes.
Observar RCs.
Interpretar RSNs.
Porque o dump raramente mente.
As pessoas podem se confundir.
Aplicações podem mascarar erros.
Logs podem induzir interpretações equivocadas.
Mas o dump normalmente conta exatamente a história que aconteceu.
O Segredo do IBM Z
A grande beleza do Mainframe não está apenas em processar milhões de transações.
Está em sua arquitetura.
IBM não criou simplesmente ferramentas.
Criou camadas.
Criou isolamento.
Criou mecanismos de desacoplamento.
Criou contexto.
Criou auditoria.
Criou proteção.
SAF desacopla aplicações do mecanismo de segurança.
ACEE desacopla autenticação das verificações constantes.
APF desacopla programas comuns de funções críticas do sistema operacional.
SMF registra tudo.
ICSF protege chaves.
RACF define regras.
E o Sysprog garante que todas essas peças continuem funcionando em perfeita harmonia.
A Lição Final do Padawan
Talvez a principal lição para um Sysprog iniciante seja entender que segurança no z/OS não é apenas RACF.
Segurança é um ecossistema.
Hardware criptográfico.
ICSF.
SAF.
RACF.
SMF.
APF.
ACEE.
Auditoria.
Processos.
Pessoas.
Boas práticas.
Governança.
Monitoramento.
E principalmente conhecimento.
Porque no fim das contas, o verdadeiro Guardião do Reino IBM Z não é aquele que apenas executa comandos.
É aquele que compreende por que cada tecnologia foi criada.
Como ela conversa com as demais.
Como diagnosticar seus problemas.
Como protegê-la.
Como evoluí-la.
E como garantir que, mesmo às três horas da manhã, quando o telefone tocar e alguém disser que o RACF está quebrado, ele consiga abrir um dump, seguir o caminho até o ACEE, verificar o contexto SAF, analisar APF e devolver ao Reino IBM Z aquilo que ele faz melhor há décadas:
Disponibilidade.
Integridade.
Confidencialidade.
E a tranquilidade de saber que trilhões de dólares continuam circulando silenciosamente pelo mundo, protegidos por tecnologias que quase ninguém vê, mas que todo Sysprog deveria conhecer profundamente.
"O RACF conhece as leis. O SAF atende as portas. O ACEE acompanha o viajante. O APF protege os segredos do castelo. E o Sysprog mantém o Reino IBM Z de pé, uma madrugada de cada vez."
Bellacosa Mainframe
