Bellacosa Mainframe analisando logs

☕ UM CAFÉ NO BELLACOSA MAINFRAME

💀 ARC E O SMF DA EMPRESA INTEIRA — COMO CONSTRUIR A CAIXA-PRETA CORPORATIVA SEM CRIAR O BIG BROTHER

SMF, COBOL, RACF, CICS, Db2, IAM, APIs, Cloud, EDR, SIEM, OpenTelemetry, grafos, Zero Trust, fraude, privacidade — e o dia em que Arc descobriu que investigar um incidente não significa vigiar uma pessoa.

---

🎬 PRÓLOGO — ARC ENCONTROU UMA DUNGEON MUITO ESTRANHA

Arc já havia acordado em mundos piores.

Virar um cavaleiro esqueleto gigantesco usando uma armadura pesada definitivamente não estava entre as experiências mais comuns de um programador.

Mas aquilo era diferente.

Não havia goblins.

Não havia dragões.

Não havia necromantes.

Na frente dele existia apenas um terminal 3270.

Na tela:

SDSF PRIMARY OPTION MENU

COMMAND INPUT ===>

Arc aproximou-se.

— Bellacosa-san... que espécie de magia ancestral é essa?

— Isso, meu caro esqueleto, é um mainframe.

Arc colocou a mão sobre a espada.

— Parece perigoso.

— E é. Digite qualquer coisa errada em produção numa sexta-feira às 17:58 e você descobrirá.

Arc prudentemente afastou a mão do teclado.

Foi então que apareceu nossa missão.

Uma empresa havia identificado uma transferência financeira suspeita.

O dinheiro passara por vários sistemas:

Internet
   ↓
API Gateway
   ↓
Cloud
   ↓
MQ
   ↓
CICS
   ↓
COBOL
   ↓
Db2
   ↓
Pagamento

O problema era descobrir:

o que aconteceu antes da transferência?

Arc perguntou:

— Não existe algum registro dizendo isso?

Sorri.

— Existe uma coisa no mainframe chamada SMF.

— Então basta consultar o SMF?

— Não exatamente. Porque metade da história aconteceu fora do mainframe.

Arc olhou novamente para o terminal.

E então nasceu nossa pergunta:

🕵️ QUAL SERIA O “SMF” DE UMA EMPRESA INTEIRA?

---

🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É SMF?

Se você está começando em COBOL e z/OS, provavelmente encontrará cedo ou tarde estas três letras:

SMF — System Management Facilities.

Simplificando bastante, podemos imaginar o SMF como um enorme mecanismo de registro de eventos do z/OS.

O sistema operacional e diversos componentes podem produzir registros descrevendo acontecimentos importantes.

Por exemplo:

JOB iniciou
JOB terminou
STEP executou
recurso foi utilizado
atividade de segurança ocorreu
dataset foi acessado
subsistema executou determinada operação

Esses registros possuem estruturas conhecidas.

Existem diferentes tipos e subtipos de registros SMF.

O resultado é algo extraordinariamente importante para operação, capacidade, auditoria, segurança, accounting, performance e investigação.

Imagine:

14:03:11 USER01 submeteu JOB12345
14:03:12 JOB12345 iniciou
14:03:13 STEP01 executou PROG001
14:03:14 PROG001 acessou recursos
14:03:18 STEP01 terminou
14:03:19 JOB12345 terminou

Agora imagine que algo deu errado.

Você pode reconstruir parte da história.

Essa palavra será fundamental durante todo este artigo:

história.

Porque segurança moderna não deveria procurar apenas eventos isolados.

Ela deveria conseguir reconstruir sequências de acontecimentos.

---

🧙 CAPÍTULO 2 — ARC DESCOBRE QUE O MUNDO DISTRIBUÍDO É UMA BAGUNÇA

Arc achou aquilo simples.

— Então instalamos SMF em todos os computadores!

Infelizmente não funciona assim.

O ambiente corporativo moderno pode possuir:

Windows
Linux
macOS
Android
iOS
Azure
AWS
Google Cloud
Kubernetes
firewalls
VPN
ZTNA
Active Directory
Entra ID
API Gateways
Kafka
MQ
Oracle
Db2
PostgreSQL
CICS
IMS
z/OS
aplicações Java
aplicações COBOL
SaaS
e-mail
sistemas financeiros
controle de acesso físico

Cada plataforma produz seus próprios registros.

Pior:

cada uma fala seu próprio dialeto.

Uma pode registrar:

USER=JOAO

Outra:

principal=j.silva@empresa

Outra:

uid=83921

Outra:

RACFID=JSILVA

Talvez sejam todos a mesma pessoa.

Talvez não.

Bem-vindo à primeira dungeon.

---

🧩 CAPÍTULO 3 — O PROBLEMA NÃO É TER LOGS

Grandes empresas normalmente possuem uma quantidade monstruosa de logs.

A dificuldade é responder:

Como relacionar acontecimentos espalhados por dezenas de tecnologias?

Imagine nosso funcionário fictício USER042.

Às 08:01:

PHYSICAL ACCESS

identity=USER042
door=HQ-ENTRANCE
result=GRANTED

Às 08:07:

IAM

identity=USER042
device=NOTEBOOK221
action=LOGIN
result=SUCCESS

08:13:

EMAIL

identity=USER042
action=OPEN_ATTACHMENT
message=M882193

08:14:

EDR

device=NOTEBOOK221
parent=OUTLOOK.EXE
process=POWERSHELL.EXE

08:15:

IAM

identity=USER042
action=TOKEN_REQUEST
application=CLOUD

08:17:

API

identity=USER042
endpoint=/customer/export
status=200

08:18:

DB2

authid=APISRV1
table=CUSTOMER
operation=SELECT
rows=284931

Separadamente, temos sete registros.

Mas Arc colocou os registros sobre a mesa e enxergou outra coisa:

EMAIL
  ↓
ATTACHMENT
  ↓
ENDPOINT
  ↓
POWERSHELL
  ↓
TOKEN
  ↓
API
  ↓
DB2
  ↓
284.931 ROWS

Agora temos uma narrativa técnica.

E isso muda completamente a investigação.

---

🔗 CAPÍTULO 4 — CORRELAÇÃO É A VERDADEIRA MAGIA

Pense numa aplicação moderna chamando um programa COBOL.

O usuário abre o navegador:

Browser

que chama:

API Gateway

que chama:

Java Microservice

que publica:

IBM MQ

que aciona:

CICS

que executa:

PROGCOB1

que finalmente executa:

UPDATE CONTA
   SET SALDO = ...

no Db2.

Cada plataforma pode conhecer apenas seu pedaço.

O navegador conhece uma sessão.

A API conhece uma requisição.

MQ conhece uma mensagem.

CICS conhece uma transação.

COBOL conhece dados recebidos.

Db2 conhece determinado acesso.

Precisamos transportar identificadores que permitam correlacionar tudo isso.

Algo conceitualmente semelhante a:

event_id
timestamp
actor_id
device_id
session_id
trace_id
transaction_id
source
target
action
result

Imagine:

TRACE-ID=ABC99172

atravessando:

API
 ↓
Java
 ↓
MQ
 ↓
CICS
 ↓
COBOL
 ↓
Db2

Agora podemos reconstruir a jornada.

Essa ideia aproxima o velho universo transacional do mainframe das técnicas modernas de distributed tracing.

O OpenTelemetry trabalha justamente com conceitos de traces, métricas e logs e com convenções semânticas destinadas a tornar a telemetria mais consistente entre tecnologias.

O velho COBOLzeiro pode olhar isso e pensar:

— Rapaz... o mundo inventou um negócio sofisticado para descobrir por onde passou uma transação.

Sim.

Bem-vindo ao século XXI.

😎

---

💀 CAPÍTULO 5 — ARC DESCOBRE O CORPORATE SMF

Vamos dar um nome à nossa arquitetura:

CORPORATE EVENT FABRIC

Ela receberia eventos de diferentes domínios:

IAM ───────────────┐
Endpoint ──────────┤
E-mail ────────────┤
Network ───────────┤
Cloud ─────────────┤
API ───────────────┤
Applications ──────┤
Databases ─────────┼──► EVENT FABRIC
Payments ──────────┤
Physical Access ───┤
Kafka/MQ ──────────┤
RACF ──────────────┤
CICS ──────────────┤
Db2 ───────────────┤
SMF ───────────────┘

Mas atenção.

Isso não significa simplesmente:

“Jogue todos os logs num SIEM.”

O SIEM seria apenas um dos consumidores.

Outros poderiam ser:

SOC
Incident Response
Fraud Detection
Forensics
IAM
Zero Trust
Compliance
Observability
SOAR
AI Agents

O Corporate Event Fabric seria uma espécie de memória factual corporativa.

---

👁️ CAPÍTULO 6 — E NASCE O BIG BROTHER

Arc ficou animado.

— Então podemos registrar absolutamente tudo!

Silêncio na sala.

— Arc...

— Sim?

— Foi exatamente aí que você quase criou o vilão da história.

Porque tecnicamente poderíamos produzir:

08:01 funcionário entrou
08:07 ligou notebook
08:11 abriu e-mail
08:31 acessou sistema
09:17 imprimiu documento
09:31 saiu da sala
09:47 entrou em outra sala
10:02 retornou

Isso seria extraordinariamente poderoso para investigação.

Mas poderia facilmente virar:

FUNCIONÁRIO FICOU 47 MINUTOS INATIVO.

FUNCIONÁRIO CHEGOU 11 MINUTOS ATRASADO.

FUNCIONÁRIO FOI AO BANHEIRO 6 VEZES.

Acabamos de atravessar uma fronteira.

Saímos de:

observabilidade

para:

vigilância.

A diferença não é apenas tecnológica.

É arquitetural, organizacional, jurídica, ética e cultural.

---

🛡️ CAPÍTULO 7 — REGISTRE EVENTOS, NÃO VIDAS

Aqui surge uma regra fundamental.

O Corporate SMF não deveria perguntar constantemente:

Onde está João?

Ele deveria registrar acontecimentos necessários para finalidades claramente estabelecidas.

Por exemplo, talvez não seja necessário armazenar:

VAGNER entrou no DATACENTER.

Podemos registrar:

actor=ENTITY-A91F27
zone=DATACENTER
action=ENTRY
result=GRANTED
timestamp=02:14:31

A relação:

ENTITY-A91F27 = pessoa real

pode ficar protegida em outro domínio.

Somente uma investigação devidamente autorizada poderia solicitar a resolução da identidade.

Isso cria algo muito interessante:

pseudonimização operacional.

O sistema consegue correlacionar:

ENTITY-A91F27

através de vários eventos sem necessariamente revelar imediatamente quem está por trás daquele identificador.

---

🧅 CAPÍTULO 8 — AS TRÊS CAMADAS DA CEBOLA DE ARC

Arc sugeriu dividir a arquitetura.

Desta vez o esqueleto acertou.

Camada 1 — EVIDENCE

Aqui registramos fatos.

event_id=9917821
actor=ENTITY-A91F27
device=DEVICE-882
action=READ
resource=DB:CUSTOMER
result=SUCCESS
timestamp=...

Nada de:

USER_IS_EVIL=YES

ou:

EMPLOYEE_SUSPICIOUS=87%

O evento deve dizer:

o que aconteceu.

---

Camada 2 — DETECTION

Agora podemos correlacionar acontecimentos.

Exemplo:

NEW DEVICE
+
UNUSUAL HOUR
+
PRIVILEGE ELEVATION
+
MASSIVE EXPORT

Resultado:

RISK_EVENT=R991

Observe a diferença.

Não estamos dizendo:

USER=CRIMINAL

Estamos dizendo:

ESTA SEQUÊNCIA MERECE INVESTIGAÇÃO.

Isso é profundamente diferente.

---

Camada 3 — INVESTIGATION

Somente uma investigação autorizada acessaria uma timeline ampliada:

RISK_EVENT
     ↓
RELATED EVENTS
     ↓
DEVICES
     ↓
IDENTITIES
     ↓
RESOURCES
     ↓
FULL TIMELINE

Assim separamos:

registro factual → detecção → investigação.

---

🕸️ CAPÍTULO 9 — ARC ENTRA NA DUNGEON DOS GRAFOS

Agora vem uma das partes mais interessantes.

Não pense apenas em linhas de log.

Pense em nós e relacionamentos.

Temos:

USER
DEVICE
TOKEN
GROUP
API
APPLICATION
QUEUE
CICS TRANSACTION
COBOL PROGRAM
DATABASE
ACCOUNT
PAYMENT

E relações:

USER ─uses────────► DEVICE

USER ─member_of───► GROUP

USER ─owns────────► TOKEN

TOKEN ─calls──────► API

API ─publishes────► MQ

MQ ─triggers──────► CICS

CICS ─executes────► COBOL

COBOL ─accesses───► DB2

Isso cria um Event Graph.

Mas podemos ir mais longe.

Podemos combinar:

IDENTITY GRAPH
+
PRIVILEGE GRAPH
+
RESOURCE GRAPH
+
EVENT GRAPH
+
TEMPORAL GRAPH

Aí a investigação muda completamente.

Em vez de procurar:

USER042

em 38 ferramentas diferentes, perguntamos:

Quais caminhos relacionam USER042 ao pagamento PAY991 durante a janela de 30 minutos anterior ao evento?

Isso é praticamente investigação forense como graph traversal.

---

💰 CAPÍTULO 10 — FRAUDE DEIXA DE SER UMA TRANSAÇÃO

Sistemas antifraude tradicionalmente podem observar algo como:

PIX
valor=800000
destino=NOVO
horario=02:11

E calcular risco.

Mas nosso Corporate SMF permite perguntar:

O que aconteceu antes desse PIX?

Talvez encontremos:

01:51 phishing
       ↓
01:55 attachment opened
       ↓
01:56 PowerShell
       ↓
02:01 credential/token
       ↓
02:03 VPN
       ↓
02:07 privilege elevation
       ↓
02:09 API
       ↓
02:10 MQ
       ↓
02:10 CICS
       ↓
02:10 COBOL
       ↓
02:11 PAYMENT

Agora a pergunta deixou de ser:

“Esta transação é estranha?”

Passou a ser:

“Qual história produziu esta transação?”

Essa mudança é gigantesca.

---

🏢 CAPÍTULO 11 — QUANDO O MUNDO FÍSICO ENCONTRA O DIGITAL

Controle físico pode enriquecer investigações.

Imagine:

02:03 VPN LOGIN
country=BR

e simultaneamente:

02:04 BADGE ENTRY
location=LONDON

Não precisamos concluir automaticamente:

FRAUDE!

Talvez exista explicação.

Credencial compartilhada.

Erro de relógio.

Sistema de badge mal integrado.

VPN.

Conta técnica.

Evento duplicado.

Mas podemos produzir:

ANOMALY:
incompatible physical/digital presence

O sistema apresenta a inconsistência.

O investigador decide o significado.

Essa separação é fundamental.

---

🔐 CAPÍTULO 12 — ZERO TRUST ENCONTRA O CORPORATE SMF

Antigamente poderíamos pensar:

LOGIN SUCCESS
     ↓
TRUSTED

Zero Trust muda isso.

A autenticação é apenas uma evidência.

Podemos ter:

IDENTITY      OK
DEVICE        OK
MFA           OK
LOCATION      UNUSUAL
RESOURCE      CRITICAL
BEHAVIOR      UNUSUAL
TRANSACTION   HIGH VALUE

A política poderia responder:

STEP-UP AUTHENTICATION

ou:

ALLOW + MONITOR

ou:

DENY

O Corporate Event Fabric fornece contexto para decisões desse tipo.

---

📦 CAPÍTULO 13 — NÃO COPIE O UNIVERSO

Outro princípio fundamental:

metadado antes de conteúdo.

No e-mail talvez precisemos registrar:

sender_hash
recipient_hash
message_id
attachment_hash
attachment_type
timestamp
delivery_result

Não precisamos necessariamente guardar:

BODY COMPLETO DO EMAIL

Para banco de dados, talvez seja suficiente:

actor
database
table
operation
rows
query_fingerprint

em vez de copiar:

CPF
SALARIO
ENDERECO
DADOS PESSOAIS

O Corporate SMF deveria saber que uma interação ocorreu.

Não necessariamente possuir uma cópia de tudo que participou dela.

Isso reduz:

• exposição;

• armazenamento;

• impacto de vazamentos;

• risco de privacidade;

• complexidade regulatória.

---

🧊 CAPÍTULO 14 — HOT, WARM, COLD E ARCHIVE

Existe ainda um problema brutal:

volume.

Uma empresa grande pode gerar quantidades absurdas de eventos.

Portanto podemos trabalhar com camadas:

HOT
alta resolução
horas/dias

WARM
eventos normalizados
semanas/meses

COLD
eventos relevantes
meses/anos

ARCHIVE
retenção regulatória

E existe uma técnica particularmente interessante:

Progressive Evidence Preservation

Normalmente:

TELEMETRY=NORMAL

Surge um incidente:

RISK DETECTED

Então aumentamos temporariamente:

TELEMETRY=DETAILED

e preservamos evidências relacionadas.

É quase como colocar:

DISPLAY TRACE=ON

quando algo começa a cheirar estranho.

O velho operador de mainframe já conhece essa filosofia há décadas.

---

🧨 CAPÍTULO 15 — MAS E SE O ATACANTE APAGAR O LOG?

Arc levantou a mão.

— Mestre, se eu dominar o servidor, posso apagar meus rastros?

Muito bem observado.

Se o atacante controla:

SERVER01

não podemos depender exclusivamente de:

SERVER01.LOG

O ideal é transportar eventos rapidamente para outro domínio:

SERVER01
    │
    ▼
COLLECTOR
    │
    ▼
IMMUTABLE EVENT STORE

Podemos acrescentar mecanismos como:

append-only
WORM
hashing
signatures
restricted deletion
segregation of duties
independent credentials

E surge uma regra deliciosa:

O CORPORATE SMF PRECISA TER UM SMF DO CORPORATE SMF.

Sim.

Recursão.

😎

Se alguém alterar políticas de retenção:

registre.

Se alguém consultar uma investigação:

registre.

Se alguém exportar eventos:

registre.

Se alguém tentar apagar eventos:

registre.

---

🕵️ CAPÍTULO 16 — QUEM VIGIA O INVESTIGADOR?

Aqui mora um dos controles mais importantes.

Imagine:

SEARCH

employee=FULANO
period=365 days

Essa consulta é extremamente invasiva.

Portanto ela também deveria gerar evidência:

AUDIT_ACCESS

investigator=SECURITY17
case=INC82991
reason=FRAUD
scope=TIMELINE
timestamp=...

Para casos especialmente sensíveis poderíamos exigir:

SOC
 +
COMPLIANCE
 +
CASE-ID

antes de revelar identidade.

É o princípio das duas chaves.

Nenhum administrador deveria possuir sozinho o equivalente corporativo a:

SELECT *
FROM HUMANITY;

Arc tentou executar.

Resultado:

SQLCODE = -911

REASON:
DIVINE PRIVACY DEADLOCK

Eis nosso easter egg.

---

🧭 CAPÍTULO 17 — COMO COMEÇAR SEM CRIAR UM DATA LAKE DE LIXO

Erro clássico:

“Vamos coletar tudo!”

Seis meses depois:

PETABYTES DE LOG
+
FATURA DE CLOUD
+
NINGUÉM SABE O QUE PROCURAR

Comece com perguntas.

Passo 1 — Identidade

QUEM?

Passo 2 — Dispositivo

DE ONDE?

Passo 3 — Recurso

ACESSOU O QUÊ?

Passo 4 — Ação

FEZ O QUÊ?

Passo 5 — Resultado

FUNCIONOU?

Só depois acrescente contexto.

Uma implementação poderia evoluir assim:

FASE 1
IAM + Endpoint + VPN

FASE 2
Cloud + API + Network

FASE 3
Applications + Databases + MQ/Kafka

FASE 4
RACF + SMF + CICS + IMS + Db2

FASE 5
Payments + Email Metadata + Physical Access

Cada nova fonte precisa responder:

Qual pergunta de segurança, operação, auditoria ou investigação isso nos ajuda a responder?

Se a resposta for:

“Nenhuma, mas o log existe.”

Talvez não devamos ingeri-lo.

---

🪪 CAPÍTULO 18 — A DUNGEON MAIS DIFÍCIL: IDENTIDADE

João pode ser:

joao.silva
jsilva
JOSILVA
U883921
RACF=JSILVA
badge=192882
email=joao.silva@...

Tudo pode representar uma pessoa.

Mas:

APISRV1

pode representar uma aplicação.

E:

CERTIFICATE-X91

pode representar uma workload.

Precisamos distinguir:

HUMAN IDENTITY
SERVICE IDENTITY
DEVICE IDENTITY
WORKLOAD IDENTITY
APPLICATION IDENTITY

Daí surge o Identity Graph.

PERSON
 ├── RACF ID
 ├── CLOUD ID
 ├── EMAIL ID
 ├── BADGE ID
 └── DEVICE LOGIN

Enquanto:

APPLICATION
 ├── SERVICE ACCOUNT
 ├── CERTIFICATE
 ├── API KEY
 └── WORKLOAD ID

Sem essa resolução, correlação corporativa rapidamente vira caos.

---

⚠️ CAPÍTULO 19 — ANOMALIA NÃO É CULPA

Esse princípio merece letras garrafais:

UMA ANOMALIA É UMA PERGUNTA, NÃO UMA SENTENÇA.

Suponha:

login 03:00
+
new device
+
large export

Pode ser ataque.

Pode ser administrador trabalhando numa emergência.

Pode ser processo automatizado mal classificado.

Pode ser migração.

Pode ser teste.

Pode ser erro de relógio.

Pode ser falso positivo.

Portanto:

EVENT
   ↓
CORRELATION
   ↓
ANOMALY
   ↓
INVESTIGATION
   ↓
CONCLUSION

Nunca:

ANOMALY
   ↓
GUILTY

Essa distinção protege pessoas e melhora a própria segurança.

---

👁️ CAPÍTULO 20 — OBSERVABILIDADE NÃO É VIGILÂNCIA

Finalmente Arc compreendeu a diferença.

Observabilidade corporativa

Pergunta:

O que aconteceu com o sistema?

Características:

event-centric
resource-centric
purpose-limited
security-oriented
auditable

Vigilância corporativa

Pergunta:

O que esta pessoa está fazendo o tempo inteiro?

Características:

person-centric
continuous
open-ended
behavioral

Uma arquitetura saudável deveria possuir barreiras explícitas contra usos incompatíveis com sua finalidade.

O fato de ser tecnicamente possível inferir algo não significa que devamos fazê-lo.

Essa talvez seja a maior lição deste artigo.

---

💀 CAPÍTULO 21 — ARC FINALMENTE ENXERGA A DUNGEON INTEIRA

No final da investigação tínhamos:

              CORPORATE MEMORY

 IAM ───────────────┐
 Endpoint ──────────┤
 Network ───────────┤
 Cloud ─────────────┤
 API ───────────────┤
 Application ───────┤
 Database ──────────┼──► NORMALIZATION
 Payments ──────────┤          │
 Email Metadata ────┤          ▼
 Physical Access ───┤      EVENT GRAPH
 MQ/Kafka ──────────┤          │
 RACF/CICS/Db2 ─────┤          ▼
 SMF ───────────────┘     CORRELATION
                               │
                      ┌────────┴────────┐
                      ▼                 ▼
                  DETECTION       INVESTIGATION
                      │                 │
                      └────────┬────────┘
                               ▼
                            EVIDENCE

Mas poderíamos descrevê-lo ainda melhor:

CORPORATE SMF
      =
EVENT STORE
      +
IDENTITY GRAPH
      +
PRIVILEGE GRAPH
      +
RESOURCE GRAPH
      +
TEMPORAL GRAPH
      +
GOVERNANCE

E perceba a última palavra.

Governance.

Sem ela, construímos o Big Brother.

Com ela, podemos construir uma poderosa caixa-preta corporativa.

---

☕ EPÍLOGO — O QUE O MAINFRAME JÁ SABIA

Arc levantou-se diante do 3270.

Depois de atravessar IAM, endpoints, APIs, cloud, MQ, CICS, COBOL, Db2, pagamentos, controle físico, grafos e Zero Trust, finalmente compreendeu.

— Bellacosa-san, então o objetivo não é observar todo mundo?

— Não.

— Nem guardar tudo?

— Também não.

— Então qual é?

Olhei novamente para o SDSF.

A resposta estava ali desde o começo.

Quando alguma coisa importante acontecer, deixe evidência suficiente para reconstruir o que aconteceu.

Esse princípio atravessou décadas de computação.

No mainframe temos uma cultura fortíssima de registros operacionais.

No mundo distribuído estamos tentando recuperar essa visão através de logs estruturados, tracing, observabilidade, telemetria, SIEM, EDR, cloud audit, IAM e tantas outras tecnologias.

O desafio agora é conectá-las.

Não queremos perguntar:

O QUE O FUNCIONÁRIO FEZ DURANTE TODO O DIA?

Queremos conseguir perguntar:

O QUE EXPLICA ESTE INCIDENTE?

Então podemos reconstruir:

quem
 ↓
usou qual identidade
 ↓
em qual dispositivo
 ↓
obteve qual privilégio
 ↓
atravessou qual caminho
 ↓
chamou qual API
 ↓
publicou qual mensagem
 ↓
acionou qual transação CICS
 ↓
executou qual COBOL
 ↓
acessou qual registro Db2
 ↓
originou qual pagamento
 ↓
em qual instante

Esse é o verdadeiro poder do conceito.

O SMF corporativo não seria simplesmente outro SIEM.

Seria uma camada de memória e evidência capaz de conectar os mundos físico, distribuído, cloud e mainframe.

Uma espécie de gravador de voo da empresa.

Se o avião corporativo sofrer uma pane, queremos reconstruir os últimos acontecimentos.

Queremos saber quais controles funcionaram.

Quais falharam.

Qual identidade apareceu.

Qual privilégio foi utilizado.

Qual API foi chamada.

Qual mensagem entrou no MQ.

Qual transação chegou ao CICS.

Qual programa COBOL executou.

Qual registro mudou.

E qual pagamento saiu.

Mas não precisamos passar o voo inteiro espionando se o passageiro pediu café duas ou três vezes.

Arc colocou o elmo.

A dungeon estava encerrada.

Antes de sair, porém, digitou no terminal:

//ARCJOB   JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=BIGBROTHER

O JES respondeu:

IEF452I ARCJOB - JOB NOT RUN - JCL ERROR

Arc olhou para mim.

— Errei a JCL?

— Não.

— Então? 

— O sistema tem governança.

Arc permaneceu alguns segundos em silêncio.

Então começou a rir.

E em algum dataset perdido do z/OS apareceu mais um registro.

Porque no mainframe...

até o esqueleto deixa rastro.

☕💀🖥️

Bellacosa Mainframe — porque observabilidade sem contexto é apenas uma montanha de logs; contexto sem governança pode virar vigilância; e um bom COBOLzeiro sabe que, quando a produção explode às 03:17 da manhã, a primeira pergunta continua sendo a mesma: “onde está o log?”