segunda-feira, 2 de novembro de 2009

📘 Guia de Auditoria z/OS Completo

 

Bellacosa Mainframe apresenta Guia de Auditoria Z/OS

📘 Guia de Auditoria z/OS Completo

Do RACF ao SMP/E: como provar que seu mainframe é confiável

“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”


🎯 Objetivo deste guia

Este guia serve para:

  • Preparar ambientes para auditoria

  • Responder auditores com evidência técnica

  • Evitar não conformidades

  • Padronizar governança em z/OS

👉 Não é teoria. É prática de campo.


🧠 Visão geral da auditoria em z/OS

Auditoria em z/OS gira em torno de 5 pilares:

1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional

Cada pilar tem ferramentas nativas do mainframe.


🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)

O auditor verifica:

  • IDs privilegiados

  • Perfis genéricos

  • UACC

  • Logging

  • Segregação de funções

Evidências:

  • LISTUSER

  • RLIST

  • Relatórios SMF

  • Revisão periódica de acessos

📌 Privilégio excessivo reprova auditoria.


🛡️ Pilar 2 – Integridade do Sistema

Ferramentas-chave:

  • SMP/E

  • CSI

  • DLIB

  • TARGET libraries

O auditor quer saber:

  • Quem muda o sistema

  • Como muda

  • Se há controle

📌 Aqui o SMP/E reina absoluto.


🔁 Pilar 3 – Gestão de Mudanças

Avaliação típica:

  • Processo RECEIVE/APPLY/ACCEPT

  • APPLY CHECK obrigatório

  • Análise de ++HOLD e ++ERROR

  • USERMOD documentado

Evidências:

  • Outputs SMP/E

  • Change records

  • APARs e PTFs


🧩 Pilar 4 – Rastreabilidade e Evidência

O auditor exige:

  • Histórico preservado

  • Logs acessíveis

  • Responsáveis identificados

Ferramentas:

  • CSI

  • SMF

  • Logs RACF

  • Versionamento de JCL

📌 Sem evidência, não existe controle.


🔄 Pilar 5 – Continuidade e Recuperação

Avaliação:

  • Backup de CSI

  • Capacidade de RESTORE

  • Planos de contingência

  • Testes documentados

📌 Auditoria não aceita “nunca testamos”.


📦 Auditoria por componente (check rápido)

🔹 SMP/E

✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado

🔹 RACF

✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica

🔹 JES / System

✔ Parâmetros controlados
✔ Alterações documentadas

🔹 SMF

✔ Coleta ativa
✔ Retenção definida


🚨 Red flags clássicos em auditoria z/OS

❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação

👉 Tudo isso vira finding.


🧠 Caso real (estilo Bellacosa)

Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez

📌 Conclusão:

Ambiente sem governança.


🎓 Como se preparar para auditoria

  • Trate auditoria como rotina

  • Use SMP/E como aliado

  • Automatize evidências

  • Documente decisões

  • Revise acessos

💡 Dica Bellacosa:

“Auditoria bem-sucedida começa meses antes.”


🧠 Curiosidades Bellacosa

  • Auditor confia mais no CSI do que em planilha

  • Mainframe já nasce auditável

  • Falha é quase sempre humana, não técnica


🧾 Encerramento – Guia de Auditoria z/OS

z/OS não é inseguro.
Inseguro é rodar sem controle.

Quem domina:

  • RACF

  • SMP/E

  • Processos

👉 passa em qualquer auditoria.

📘💾🛡️🔥


Sem comentários:

Enviar um comentário