☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Grafos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Grafos. Mostrar todas as mensagens

quinta-feira, 22 de maio de 2025

O Scheduler da Curiosidade: IA, Backlogs e o Dia em que Tínhamos 30 Assuntos em Paralelo e Nenhum Queria Dar $HASP395

Bellacosa Mainframe e o scheduler da curiosidade 

☕ Um Café no Bellacosa Mainframe

O Scheduler da Curiosidade: IA, Backlogs e o Dia em que Tínhamos 30 Assuntos em Paralelo e Nenhum Queria Dar $HASP395

Por Vagner Bellacosa

Existe um problema novo acontecendo na minha mesa.

Não é falta de documentação.

Não é falta de livros.

Não é falta de cursos.

Não é falta de acesso à informação.

Também não é exatamente falta de tempo — embora os boletos continuem insistindo que o dia tenha apenas 24 horas.

O problema é quase o contrário.

Há conhecimento demais ao alcance das mãos.

E então chegou a Inteligência Artificial.

Agora existe uma criatura disponível praticamente a qualquer momento que aceita perguntas sobre COBOL, filosofia, economia, anime, história, mainframe, arqueologia, inteligência artificial, acidentes aéreos, linguística, segurança, psicologia, grafos, bancos, YAML, XML, Atari e aquela dúvida completamente absurda que apareceu às duas da manhã e que você jamais perguntaria numa reunião de trabalho.

Você pergunta.

Ela responde.

A resposta produz outra pergunta.

Essa produz três.

Uma delas parece muito mais interessante do que a pergunta original.

Você segue por ali.

Duas horas depois está lendo sobre uma tabuinha de argila babilônica de milhares de anos atrás e já não consegue explicar exatamente como uma conversa sobre COBOL terminou na Mesopotâmia.

Bem-vindo ao problema.

Ou talvez...

bem-vindo à solução.

Coloque café na xícara.

Hoje não vamos falar exatamente sobre COBOL.

Vamos falar sobre o programa mais complexo que provavelmente executaremos durante toda a nossa vida:

a nossa própria curiosidade.

E aparentemente o scheduler está tendo problemas.


$HASP100: JOB CURIOSIDADE ON READER

Outro dia olhei para minha lista de conversas fixadas no ChatGPT.

Ali estavam coisas como:

Anime Another Resumo
Memórias Vagnerianas
JSON no COBOL Mainframe
Manias Econômicas Históricas
Curso Lógica Programação
YAML para Programadores
Inuyasha Anime e Legado
Impacto de Conan no Anime
Análise de Erros XML
Homenagem ao Atari

Olhei aquilo e comecei a rir.

Não porque fossem assuntos ruins.

Justamente o contrário.

Todos eram interessantes.

Esse era o problema.

Cada conversa havia começado por alguma razão perfeitamente legítima. Algumas estavam virando artigos. Outras eram investigações técnicas. Algumas eram memórias. Outras tinham começado simplesmente porque alguma coisa despertara curiosidade.

Nenhuma havia realmente terminado.

E então percebi algo.

Minha lista de conversas estava começando a parecer:

SDSF STATUS DISPLAY

Só que em vez de JOBs havia ideias.

JOBNAME     STATUS
COBOLJSON   ACTIVE
YAML001     HELD
ATARI001    WAITING
INUYASHA    ACTIVE
MEMORIA     ACTIVE
ECONHIST    HELD
XMLERROR    ACTIVE
CONAN001    WAITING
LOGICA15    ACTIVE

E em algum lugar do sistema:

30 JOBS ACTIVE
47 JOBS WAITING
123 JOBS DISCOVERED

Nenhum querendo emitir:

$HASP395 JOB ENDED

Foi quando percebi que talvez tivéssemos inventado acidentalmente uma espécie de JES2 da curiosidade intelectual.

E o ChatGPT estava funcionando como uma mistura perigosa de READER, CONVERTER, EXECUTOR e operador da console.


A escola ensinou conhecimento como uma fila

Durante muito tempo fomos educados segundo uma estrutura predominantemente linear.

Capítulo 1.

Depois capítulo 2.

Depois capítulo 3.

Prova.

Próxima matéria.

A própria estrutura física dos livros reforçava isso.

Página 1 → página 2 → página 3.

Claro que sempre existiram notas de rodapé, referências e bibliografias. Mas havia um custo para abandonar a estrada principal.

Imagine estudar alguma coisa em 1985.

Você encontra uma referência interessante:

"Esse conceito deriva dos trabalhos de Fulano publicados em 1967."

Interessante.

Mas você não possui o livro de Fulano.

Talvez exista na biblioteca.

Talvez precise pedir emprestado.

Talvez nem esteja traduzido.

Então você faz uma anotação:

Pesquisar Fulano depois.

E continua lendo.

A escassez de informação produzia involuntariamente uma coisa extremamente valiosa:

foco.

Não porque as pessoas fossem necessariamente mais disciplinadas.

Mas porque perseguir cada ramificação era caro.

Hoje o custo marginal de abrir outra porta intelectual aproxima-se perigosamente de zero.

Estou lendo sobre COBOL.

Encontro "JSON GENERATE".

Pesquiso.

Descubro JSON PARSE.

Pergunto ao ChatGPT.

Aparece uma discussão sobre interoperabilidade.

Interoperabilidade lembra APIs.

APIs levam ao z/OS Connect.

z/OS Connect leva a REST.

REST leva a OpenAPI.

OpenAPI leva a YAML.

YAML lembra pipelines.

Pipelines levam a Jenkins.

Jenkins leva a DevOps.

DevOps leva a agentes de IA.

Agentes levam a sistemas autônomos.

Sistemas autônomos levam a governança.

Governança leva a acidentes.

Acidentes levam à aviação.

Aviação leva a Crew Resource Management.

CRM leva a psicologia organizacional.

Psicologia leva a vieses cognitivos.

E de repente...

onde está o JSON?

Ele continua lá.

Cinco níveis acima no stack trace da curiosidade.


Talvez estejamos pensando errado sobre conhecimento

Aqui aparece algo fascinante.

Talvez o problema seja esperar que conhecimento verdadeiro tenha estrutura linear.

Porque ele não tem.

Conhecimento parece muito mais um grafo.

Para quem passou recentemente pelo Neo4j, a analogia é irresistível.

Imagine:

(:Pessoa)-[:ESTUDA]->(:COBOL)

(:COBOL)-[:EXECUTA_EM]->(:Mainframe)

(:Mainframe)-[:UTILIZA]->(:zOS)

(:zOS)-[:POSSUI]->(:JES2)

(:JES2)-[:GERENCIA]->(:Jobs)

(:Jobs)-[:PODEM_FALHAR_COM]->(:ABEND)

(:ABEND)-[:EXIGE]->(:Diagnostico)

(:Diagnostico)-[:USA]->(:Raciocinio)

(:Raciocinio)-[:SOFRE_COM]->(:ViesCognitivo)

(:ViesCognitivo)-[:APARECE_EM]->(:Aviacao)

(:ViesCognitivo)-[:APARECE_EM]->(:Medicina)

(:ViesCognitivo)-[:APARECE_EM]->(:MercadoFinanceiro)

Agora faça uma pergunta aparentemente inocente:

"Como diagnosticar melhor um problema em produção?"

Podemos começar no COBOL e terminar estudando Sherlock Holmes, House, Patrick Jane, Kahneman, acidentes aéreos e medicina diagnóstica.

E isso não é necessariamente desvio.

Pode ser travessia do grafo.


O ChatGPT virou uma máquina de criar arestas

Essa talvez seja uma das transformações intelectuais mais interessantes provocadas pelos grandes modelos de linguagem.

Google tradicionalmente é extraordinário para encontrar nós.

Você pergunta:

IBM COBOL JSON GENERATE

e recebe documentos relacionados ao assunto.

Mas numa conversa podemos fazer algo diferente:

"Isso me lembrou o problema de comunicação entre pilotos em acidentes aéreos. Existe alguma relação conceitual?"

Agora estamos procurando uma aresta.

COBOL → operação → incidente → comunicação → aviação

Ou:

"Essa arquitetura de agentes lembra CICS?"

Outra aresta.

"O problema de memória de agentes lembra checkpoint/restart?"

Outra.

"Essa ideia econômica existia na Roma antiga?"

Outra.

"Esse comportamento de IA lembra alguma coisa da psicologia cognitiva?"

Outra.

É como se tivéssemos colocado diante do grafo uma máquina especializada em sugerir:

MATCH (ideia)-[r:?]->(outra_ideia)
RETURN outra_ideia

Só existe um pequeno problema.

O MATCH não termina.


O Rabbit Hole virou feature

Existe uma expressão inglesa maravilhosa:

rabbit hole.

A toca do coelho.

Alice vê o coelho, entra atrás dele e descobre que aquilo era apenas a entrada para um universo inteiro.

A Internet já havia industrializado rabbit holes.

A IA generativa colocou elevadores dentro deles.

Você pergunta:

"Por que isso acontece?"

Recebe resposta.

Pergunta:

"Mas de onde veio?"

Resposta.

"Existe precedente histórico?"

Resposta.

"Quem discordava?"

Resposta.

"Isso ainda é válido?"

Resposta.

"E se aplicarmos ao mainframe?"

Resposta.

"E ao mercado financeiro?"

Resposta.

"E aos agentes de IA?"

Resposta.

Às 03:17 da manhã:

"Então precisamos voltar aos babilônios."

Parabéns.

Você começou querendo entender um parâmetro do JCL.


A diferença entre distração e exploração

Mas precisamos tomar cuidado para não diagnosticar toda ramificação como déficit de atenção.

Há uma diferença enorme entre:

COBOL
 ↓
Instagram
 ↓
meme
 ↓
vídeo
 ↓
notícia
 ↓
WhatsApp
 ↓
esqueci o COBOL

e:

COBOL
 ↓
Mainframe
 ↓
Sistemas críticos
 ↓
Resiliência
 ↓
Falhas
 ↓
Fator humano
 ↓
Psicologia cognitiva
 ↓
Gestão de incidentes

O primeiro fluxo provavelmente representa distração.

O segundo pode representar exploração intelectual.

Existe coerência semântica.

O problema é que ambos consomem o mesmo recurso físico:

tempo.

Seu cérebro pode ter descoberto a conexão intelectual mais extraordinária da semana.

O relógio continuará dizendo:

03:42.


O verdadeiro recurso escasso mudou

Durante séculos o recurso escasso foi informação.

Hoje, para grande parte de nós, não é mais.

Temos Wikipedia.

Livros digitais.

Papers.

Vídeos.

Cursos.

Podcasts.

Blogs.

GitHub.

Documentação.

Fóruns.

Reddit.

Stack Overflow.

ChatGPT.

Outras IAs.

E bilhões de páginas indexadas.

O recurso escasso passou a ser:

atenção.

E logo atrás:

capacidade de seleção.

A pergunta intelectual moderna não é apenas:

"O que devo aprender?"

É também:

"O que deliberadamente não vou aprender agora?"

Essa segunda pergunta é muito mais cruel.

Porque dizer "não" para algo desinteressante é fácil.

O verdadeiro problema é dizer:

"Isso é fascinante. Mas ficará para depois."


Surge o backlog intelectual

É exatamente aí que nasce nossa lista.

JSON no COBOL
YAML
XML
Atari
Anime
Economia
Memórias
IA
Segurança
História

Ela não é necessariamente um cemitério de projetos abandonados.

Talvez seja algo mais interessante:

um buffer intelectual.

Uma área de spool.

A ideia chegou.

Foi registrada.

Ainda não existem recursos disponíveis para executá-la.

Então:

JOB STATUS = HELD

Isso é infinitamente melhor do que perder a ideia.

O problema começa quando confundimos:

HELD

com:

FAILED

Uma investigação estacionada não fracassou.

Ela apenas perdeu prioridade para outra.


Precisamos de WLM para a cabeça

Quem trabalha com mainframe imediatamente perceberá o próximo problema.

Se existem dezenas de workloads competindo pelos mesmos recursos, alguém precisa estabelecer prioridades.

No z/OS temos Workload Manager.

Na cabeça temos...

Bem...

Café.

Talvez seja justamente aí que precisamos melhorar.

Imagine um WLM intelectual:

SERVICE CLASS: PRODUCAO
-----------------------
Curso atual
Trabalho
Artigo com prazo
Aula da semana

SERVICE CLASS: ALTA
-------------------
Pesquisa diretamente relacionada
Projeto em andamento

SERVICE CLASS: DISCRETIONARY
----------------------------
Anime obscuro de 1987
História do Atari
Origem de palavra suméria
Tecnologia soviética esquecida

SERVICE CLASS: SYSOTHER
-----------------------
"Por que os romanos não inventaram..."

😂

O objetivo não seria matar SYSOTHER.

Aliás, algumas das descobertas mais deliciosas provavelmente estão lá.

O objetivo seria impedir SYSOTHER de consumir toda a capacidade enquanto PRODUCAO está atrasada.


A IA não eliminou a necessidade de disciplina

Esse é um ponto importante.

Existe uma fantasia contemporânea segundo a qual IA permitirá aprender tudo.

Não permitirá.

Pode reduzir brutalmente o custo de explicação.

Pode resumir.

Pode traduzir.

Pode comparar.

Pode produzir exemplos.

Pode adaptar a linguagem.

Pode ajudar a encontrar relações.

Pode responder perguntas imediatamente.

Mas existe uma coisa que ela ainda não consegue aumentar:

24 horas = 24 horas

Podemos aumentar nossa eficiência.

Não podemos aumentar indefinidamente nosso throughput humano.

E pior:

compreender continua custando tempo.

Ler uma explicação não significa incorporá-la.

Reconhecer um conceito não significa dominá-lo.

Assistir a uma demonstração não significa conseguir reproduzi-la.

Receber código funcionando não significa compreender sua arquitetura.

Esse talvez seja um dos perigos da aprendizagem com IA:

confundir velocidade de obtenção da resposta com velocidade de aquisição do conhecimento.

São coisas diferentes.

Muito diferentes.


Conhecimento não é download

Se conhecimento fosse simplesmente transferência de bytes, poderíamos fazer:

//LEARN EXEC PGM=UPLOAD
//SYSIN DD *
  COBOL
  NEO4J
  PYTHON
  QUANTUM
  JAPANESE
/*

Resultado:

IEC999I KNOWLEDGE SUCCESSFULLY INSTALLED

Infelizmente não funciona.

Aprendizagem exige reconstrução interna.

Você precisa errar.

Relacionar.

Esquecer.

Relembrar.

Aplicar.

Comparar.

Explicar para outra pessoa.

Encontrar contradições.

Reformular.

Voltar meses depois e perceber que aquilo que parecia óbvio não era.

A IA pode acompanhar todo esse processo.

Mas não pode simplesmente substituir o processo.


Talvez nossa aparente desorganização esconda alguma coisa valiosa

Aqui entra uma hipótese que me fascina.

E se parte dessas ramificações não for desperdício?

E se estivermos construindo uma espécie de Knowledge Graph pessoal?

Durante décadas de trabalho uma pessoa acumula experiências.

Banco.

Mainframe.

Incidentes.

Programação.

Gestão.

Pessoas.

Viagens.

Livros.

Filmes.

Histórias.

Tecnologias.

Fracassos.

Acertos.

Essas coisas ficam armazenadas como nós aparentemente desconectados.

Então surge uma conversa.

Um assunto ativa outro.

Uma memória conecta-se a um conceito novo.

Uma história profissional antiga encontra uma teoria publicada décadas depois.

De repente:

(:Experiencia1989)
      |
      | [:EXPLICA]
      v
(:Conceito2026)

A experiência sempre esteve lá.

Faltava a aresta.

Talvez uma das funções mais poderosas da IA para alguém que acumulou décadas de experiência não seja simplesmente ensinar fatos novos.

Talvez seja ajudar a indexar intelectualmente a própria vida.

Isso é enorme.


Curiosidade como algoritmo de busca

Uma pessoa curiosa executa continuamente algo parecido com:

while alive:
    observe()
    question()
    connect()
    investigate()
    update_model()

Só existe um pequeno bug:

while alive:

não possui END-IF.

E aparentemente tampouco possui MAX-DEPTH.

😂

Por isso precisamos talvez acrescentar:

IF DEPTH > ACCEPTABLE-LIMIT
   MOVE CURRENT-TOPIC TO BACKLOG
   PERFORM RETURN-TO-MAIN-QUEST
END-IF

Esse talvez seja o algoritmo intelectual necessário para a era da IA.

Não bloquear rabbit holes.

Controlar profundidade.


O conceito de estacionamento intelectual

Imagine que estamos estudando agentes de IA.

Durante a conversa surgem:

[ ] memória vetorial
[ ] MCP
[ ] sistemas multiagentes
[ ] segurança
[ ] prompt injection
[ ] teoria de jogos
[ ] swarm intelligence
[ ] governança
[ ] custos de inferência
[ ] mainframe integration

Não precisamos abrir dez frentes.

Podemos dizer:

CURRENT:
Agentes e memória

PARKED:
MCP
Segurança
Swarm
Governança
Mainframe integration

A curiosidade continua viva.

Mas o scheduler recupera o controle.

Essa simples mudança psicológica é poderosa porque reduz aquela sensação:

"Estou deixando algo importante para trás."

Não.

Você colocou no spool.


O perigo oposto: nunca terminar nada

Agora precisamos tomar a red pill.

Existe uma versão romântica da curiosidade que pode virar desculpa.

"Sou explorador."

"Tenho muitos interesses."

"Estou conectando conhecimentos."

Tudo verdadeiro.

Mas existe um teste brutal:

o que foi concluído?

Porque conhecimento também precisa produzir $HASP395.

Artigo publicado.

Programa funcionando.

Curso concluído.

Experimento documentado.

Livro lido.

Hipótese descartada.

Aula preparada.

Problema resolvido.

Sem isso podemos passar anos em:

$HASP373 JOB STARTED

sem jamais chegar a:

$HASP395 JOB ENDED

E então o backlog não é biblioteca.

É dívida.


Talvez terminar seja uma tecnologia

Essa é outra ideia que merece reflexão.

Somos treinados para começar.

Cursos vendem começos.

Tutoriais ensinam começos.

Plataformas recomendam novos começos.

Algoritmos apresentam novidades.

IA responde imediatamente à próxima curiosidade.

Pouquíssimos sistemas são economicamente incentivados a dizer:

"Não abra nada novo. Termine aquilo."

Porque novidade gera clique.

Descoberta gera dopamina.

Conclusão frequentemente exige a parte menos glamourosa:

revisar.

corrigir.

testar.

reescrever.

organizar.

publicar.

documentar.

É muito mais divertido descobrir outro rabbit hole.

Talvez finalização tenha se tornado uma competência intelectual própria.


O Scheduler da Curiosidade

Chegamos então ao nosso pequeno sistema operacional mental.

Eu o imaginaria assim:

                 ┌───────────────┐
                 │ CURIOSIDADE   │
                 └───────┬───────┘
                         │
                         ▼
                  NOVA PERGUNTA
                         │
               ┌─────────┴─────────┐
               │                   │
         RELEVANTE AGORA?          NÃO
               │                   │
              SIM                  ▼
               │               BACKLOG
               ▼
           EXECUTAR
               │
         ┌─────┴─────┐
         │           │
   NOVO RAMO?       NÃO
         │           │
        SIM          ▼
         │       CONCLUIR
         ▼           │
    REGISTRAR        ▼
         │       $HASP395
         │
         └──────► VOLTAR

Parece trivial.

Mas pense na diferença.

Não estamos dizendo:

"Pare de ser curioso."

Estamos dizendo:

"Faça scheduling da curiosidade."


E onde vamos parar?

Essa talvez seja a pergunta mais divertida.

Provavelmente em lugar nenhum.

E isso não é necessariamente ruim.

Porque conhecimento não possui tela final.

Não existe:

CONGRATULATIONS
YOU HAVE COMPLETED KNOWLEDGE
100%

Quanto mais aprendemos, maior parece o mapa.

É quase cruel.

Quando sabemos pouco, o mundo parece relativamente simples.

Quando aprendemos mais, começamos a enxergar as dependências.

Depois enxergamos as exceções.

Depois as controvérsias.

Depois a história.

Depois as escolas rivais.

Depois descobrimos que algumas certezas eram aproximações.

O mapa aumenta justamente porque aprendemos a enxergá-lo.

Talvez seja esse o paradoxo definitivo da curiosidade:

cada resposta aumenta o território das perguntas.


A IA tornou o universo intelectual navegável — não finito

Esse ponto é fundamental.

ChatGPT e outras ferramentas não transformaram conhecimento em algo que podemos terminar.

Transformaram conhecimento em algo que podemos percorrer com muito menos atrito.

Antes havia oceanos entre os continentes intelectuais.

Agora construímos pontes.

Isso muda completamente a viagem.

Mas não reduz o tamanho do planeta.

Talvez até faça o contrário.

Quando percebemos que COBOL pode conversar com IA, que mainframe pode conversar com cloud, que psicologia pode conversar com segurança, que história pode explicar tecnologia e que experiências de décadas atrás podem iluminar problemas atuais...

o mundo fica intelectualmente maior.

Não menor.


O profissional em T

Durante muito tempo falou-se no profissional em T.

Conhecimento amplo horizontalmente.

Especialização profunda verticalmente.

Talvez a IA esteja favorecendo outro formato.

Algo parecido com um grafo.

Você possui alguns nós extremamente profundos.

Mainframe.

COBOL.

Sistemas financeiros.

E centenas de conexões menos profundas:

        História
           |
Economia--Mainframe--IA
           |
      Segurança
       /      \
 Psicologia  Aviação
      |
  Gestão

O valor não está necessariamente em dominar todos esses campos.

Está também em conseguir perceber:

"Eu já vi esse padrão em outro lugar."

Essa capacidade é extraordinariamente poderosa.

Porque inovação muitas vezes nasce justamente da transferência de modelos entre domínios.


Easter egg: talvez o cérebro seja um mainframe ruim

Antes que algum neurocientista jogue café em mim:

é uma metáfora.

Mas divertida.

Temos memória.

Temos processamento.

Temos prioridades.

Temos interrupções.

Temos cache.

Temos processos esquecidos.

Temos informações que sabemos que estão armazenadas em algum lugar, mas cujo endereço aparentemente foi perdido.

Temos:

"Eu conheço essa pessoa..."

seguido de:

SEARCHING...
SEARCHING...
SEARCHING...

Três horas depois, tomando banho:

HIT!

😂

Temos também algo equivalente a storage leak:

uma música ruim de 1987 permanece perfeitamente armazenada enquanto esquecemos por que entramos na cozinha.

O hardware humano definitivamente possui algumas decisões arquitetônicas curiosas.


O grande desafio não será saber mais

Será governar o que queremos saber.

Isso talvez seja uma das grandes competências da próxima década.

Não apenas prompt engineering.

Não apenas saber perguntar.

Mas saber decidir:

qual pergunta merece continuação?

qual merece estacionamento?

qual merece profundidade?

qual merece abandono?

qual precisa virar projeto?

qual deve permanecer apenas como curiosidade?

Porque podemos perguntar praticamente indefinidamente.

Mas não podemos viver indefinidamente.

Existe aí uma dimensão profundamente humana que nenhuma otimização elimina.

Escolher aprender alguma coisa significa escolher não aprender outras naquele momento.

Escolher escrever um artigo significa deixar três esperando.

Escolher terminar um curso significa ignorar temporariamente cinco tecnologias novas.

Escolher profundidade significa renunciar momentaneamente à novidade.

Esse é o verdadeiro scheduler.


Blue Pill ou Red Pill?

A Blue Pill é confortável:

"Com IA finalmente conseguirei aprender tudo."

Não.

Provavelmente acontecerá exatamente o contrário.

A IA mostrará quanto existe para aprender.

A Red Pill é mais interessante:

"Nunca aprenderei tudo. Então preciso escolher melhor minhas viagens."

Isso muda completamente nossa relação com conhecimento.

Não precisamos conquistar todo o mapa.

Podemos explorá-lo.

Construir caminhos.

Registrar descobertas.

Voltar.

Conectar regiões.

E ocasionalmente colocar uma placa:

TODO:
RETORNAR AQUI

$HASP395: ou talvez não

Chegamos ao fim deste artigo falando sobre...

Deixe-me conferir.

Começamos com conversas abertas no ChatGPT.

Passamos por JES2.

Grafos.

Neo4j.

Rabbit holes.

Psicologia.

WLM.

Aprendizagem.

Gestão de atenção.

IA.

Knowledge Graph.

E terminamos discutindo finitude humana.

Nada mal para uma conversa que começou olhando uma barra lateral cheia de chats inacabados.

Talvez seja exatamente esse o ponto.

A curiosidade intelectual não é uma estrada.

É uma rede.

Cada pergunta é um nó.

Cada associação cria uma aresta.

Cada experiência antiga pode ganhar significado novo quando conectada a alguma coisa aprendida hoje.

ChatGPT não inventou esse comportamento.

Nós sempre fizemos isso.

A diferença é que agora existe uma ferramenta capaz de acompanhar nossa corrida pelo grafo quase na velocidade em que surgem as perguntas.

E isso é maravilhoso.

Também é perigoso.

Porque sempre haverá outra aresta.

Sempre haverá outro nó.

Sempre haverá:

"Só mais uma pergunta..."

O verdadeiro desafio intelectual da era da IA talvez não seja descobrir como começar uma investigação.

Isso ficou absurdamente fácil.

Será aprender quando continuar, quando estacionar e quando terminar.

Precisamos ser simultaneamente exploradores e operadores.

Curiosos e schedulers.

Alice e JES2.

Precisamos permitir:

$HASP373 CURIOSITY STARTED

Mas de vez em quando precisamos olhar para o backlog, escolher alguma coisa e exigir:

$HASP395 CURIOSITY ENDED

Mesmo sabendo que aquilo nunca terminou completamente.

Porque uma boa resposta deixa uma pergunta.

Uma boa pergunta encontra outra área.

Uma experiência encontra uma teoria.

Uma memória encontra significado.

Um artigo encontra outro artigo.

E talvez seja justamente por isso que continuamos estudando depois de décadas.

Não porque estejamos chegando ao fim.

Mas porque finalmente começamos a enxergar o tamanho do grafo.

Então onde vamos parar?

Não faço a menor ideia.

Provavelmente começaremos falando sobre o scheduler da curiosidade, alguém mencionará teoria dos grafos, daí surgirá a história dos sete graus de separação, que levará a redes sociais, que levará a algoritmos de recomendação, que levará a manipulação comportamental, que levará a Skinner, que levará a psicologia, que lembrará inteligência artificial...

...e daqui a pouco estaremos novamente discutindo COBOL.

Talvez exista uma explicação técnica para isso.

Ou talvez seja simplesmente:

//CURIOS EXEC PGM=LIFE
//PARM DD *
   MAXDEPTH=UNLIMITED
   CURIOSITY=YES
   COFFEE=STRONG
   RETURN=OPTIONAL
/*

IEFBR14 provavelmente não resolverá.

☕ Café terminado.

Artigo terminado.

JOB terminado.

Finalmente:

$HASP395 CURIOSITY ENDED

...

Espera.

Se conhecimento funciona como grafo, será que nosso backlog de conversas poderia ser automaticamente transformado em um grafo visual de interesses, mostrando quais assuntos deram origem a quais outros?

Droga.

$HASP100 NEWJOB ON READER

E lá vamos nós outra vez. ☕🖥️

quinta-feira, 5 de maio de 2022

DSA para Programadores COBOL Padawan

 

Bellacosa Mainframe apresenta DSA para programadores

☕ Um Café no Bellacosa Mainframe

DSA para Programadores COBOL Padawan

Você Não Precisa Decorar 500 Problemas do LeetCode. Precisa Aprender a Reconhecer Padrões.

"Todo programador iniciante acredita que grandes desenvolvedores conhecem milhares de algoritmos. Depois de alguns anos de experiência, descobre que eles conhecem apenas algumas dezenas de padrões... e sabem exatamente quando utilizá-los."


Existe uma pergunta que aparece frequentemente entre jovens programadores COBOL que desejam migrar para o universo moderno da Engenharia de Software:

"Preciso aprender LeetCode para conseguir boas oportunidades?"

Minha resposta normalmente surpreende.

Não.

Você precisa aprender como pensar.

LeetCode é uma academia.

DSA (Data Structures and Algorithms) é aprender anatomia.

Um fisiculturista pode decorar todos os exercícios da academia.

Um médico entende músculos, ossos, tendões e articulações.

Quem entende anatomia consegue criar novos exercícios.

Quem entende DSA consegue resolver problemas que nunca viu antes.

Essa é exatamente a diferença entre decorar soluções e compreender padrões.

E essa diferença vale tanto para um desenvolvedor Java quanto para um veterano de COBOL com trinta anos de experiência em sistemas bancários.


O Programador COBOL Já Conhece DSA (Mesmo Sem Saber)

Essa talvez seja a maior surpresa.

Muitos profissionais de Mainframe acreditam que DSA é uma invenção recente.

Não é.

Na verdade, você trabalha com isso há décadas.

Veja alguns exemplos.

Quando você faz uma leitura sequencial de um arquivo VSAM...

...está explorando uma estrutura de dados.

Quando faz um SEARCH ALL...

...está utilizando Binary Search.

Quando usa tabelas OCCURS...

...está manipulando Arrays.

Quando organiza registros por chave...

...está trabalhando com algoritmos de ordenação.

Quando utiliza um índice alternativo no VSAM...

...está explorando conceitos semelhantes às árvores de busca.

O que mudou foi apenas a nomenclatura.


O Grande Erro de Quem Estuda LeetCode

Imagine que alguém queira aprender COBOL.

Então começa resolvendo programas aleatórios.

Um dia faz folha de pagamento.

No outro faz cálculo de imposto.

Depois processamento de boletos.

Na semana seguinte faz conciliação bancária.

Será que ele aprenderá COBOL?

Provavelmente não.

Porque cada programa utiliza conceitos diferentes.

Com DSA acontece exatamente o mesmo.

Resolver problemas aleatórios é uma forma extremamente lenta de aprender.

Muito melhor é dominar um padrão de cada vez.

Quando você aprende Sliding Window...

...de repente resolve cinquenta problemas diferentes.

Quando entende HashMap...

...mais cinquenta deixam de parecer difíceis.

É um efeito multiplicador.


Pensando Como um Analista de Sistemas

Um analista experiente nunca começa programando.

Ele começa fazendo perguntas.

Da mesma forma, um bom solucionador de problemas faz um diagnóstico antes de escrever uma linha de código.

Seu raciocínio deveria seguir algo parecido com isto:

Que tipo de dado eu possuo?

↓

Qual estrutura representa melhor esses dados?

↓

Existe um padrão conhecido?

↓

Qual algoritmo resolve isso?

↓

Quanto custa em tempo?

↓

Quanto custa em memória?

Perceba que programação é apenas o último passo.

O verdadeiro trabalho acontece antes.


Arrays: O Arquivo Sequencial da Programação

Se existe uma estrutura que todo programador COBOL domina intuitivamente, é o Array.

Em COBOL:

01 CLIENTES.
   05 CLIENTE OCCURS 1000 TIMES.
      10 NOME PIC X(30).

Isso é um Array.

Na maioria das linguagens modernas:

clientes[1000]

É exatamente o mesmo conceito.

O interessante é que vários algoritmos famosos trabalham exclusivamente sobre Arrays.

Entre eles:

  • Prefix Sum

  • Sliding Window

  • Kadane

  • Binary Search

Cada um resolve um tipo específico de problema.


Prefix Sum: Quando Somar Milhões de Registros Precisa Ser Rápido

Imagine um banco.

Existe um histórico diário de saldo.

O gerente pergunta:

"Qual foi a movimentação entre os dias 500 e 1800?"

A solução ingênua seria somar tudo novamente.

Mas isso custa:

O(n)

Prefix Sum cria uma tabela acumulada.

Depois disso qualquer consulta vira praticamente instantânea.

Essa ideia aparece em:

  • Data Warehouses

  • BI

  • Analytics

  • Processamento Financeiro

  • Mainframe Batch

Embora muitos profissionais não percebam, diversas rotinas históricas de fechamento utilizam exatamente esse princípio.


Sliding Window: Não Recalcule o Que Você Já Sabe

Imagine um programa que precisa descobrir os três maiores dias consecutivos de vendas.

Um iniciante faz isto:

Soma dia 1

Soma dia 2

Soma dia 3

Depois recomeça tudo.

Um desenvolvedor experiente pensa diferente.

"Já conheço dois dos três valores."

Então remove apenas o elemento que saiu da janela e adiciona o próximo.

É como acompanhar uma esteira rolante.

Você não desmonta a esteira inteira para observar o próximo objeto.

Apenas acompanha seu movimento.

Esse padrão reduz muitos problemas de O(n²) para O(n).


Binary Search: Muito Além de Procurar

Todo mundo conhece Binary Search como uma busca em listas ordenadas.

Mas existe um detalhe interessante.

Hoje ele é muito mais utilizado para responder perguntas como:

"Qual é o menor valor possível?"

"Qual é a menor capacidade de armazenamento?"

"Qual é a menor velocidade aceitável?"

Sempre que existe uma resposta monotônica, Binary Search pode aparecer.

É por isso que ele continua sendo um dos algoritmos preferidos em entrevistas.


Strings: O Mundo dos Textos

Mainframes trabalham intensamente com texto.

CPF.

Nome.

Código de Agência.

Número da Conta.

Mensagens.

Arquivos CNAB.

Tudo isso são Strings.

Existem alguns padrões clássicos.

Two Pointers

Muito útil para:

  • remover espaços

  • comparar extremos

  • detectar palíndromos

É simples.

Dois ponteiros caminham em velocidades diferentes ou em sentidos opostos.


KMP

Imagine procurar uma palavra dentro de um documento de centenas de megabytes.

Sem estratégia...

...você volta inúmeras vezes ao início.

KMP evita repetir trabalho.

Ele aprende durante a própria busca.

É um excelente exemplo de algoritmo inteligente.


HashMap: A Memória Instantânea

HashMap talvez seja a estrutura que mais transforma problemas difíceis em problemas simples.

Imagine a pergunta:

"Este CPF já apareceu?"

Sem HashMap:

Procure tudo novamente.

Com HashMap:

Consulte diretamente.

É praticamente um índice em memória.

Quem trabalhou com índices DB2 entende rapidamente essa ideia.

Não percorremos a tabela inteira.

Consultamos uma estrutura otimizada.


Pilhas (Stacks): A Forma Natural de Resolver Alguns Problemas

Uma Stack segue a regra:

Last In

First Out

Ou seja:

O último que entra é o primeiro que sai.

Pense numa pilha de JCLs impressos.

O último colocado em cima será retirado primeiro.

Stacks aparecem em:

  • compiladores

  • interpretadores

  • validação de parênteses

  • chamadas de funções

  • expressões matemáticas

Sempre que existir necessidade de "voltar" ao estado anterior, existe uma boa chance de uma Stack resolver o problema.


Filas: O Modelo Natural do Batch

Se existe uma estrutura familiar ao mundo Mainframe é a Queue.

Os Jobs entram.

Esperam.

São executados.

Saem.

JES2 e JES3 vivem exatamente desse conceito.

Fila.

Primeiro que entra.

Primeiro que sai.

O mesmo vale para sistemas de mensagens como IBM MQ.


Linked Lists: Quando a Ordem Importa Mais que a Posição

Em um Array sabemos exatamente onde cada elemento está.

Em uma Linked List sabemos apenas quem é o próximo.

Isso muda completamente a forma de navegar pelos dados.

Um algoritmo famoso utiliza dois ponteiros.

Um anda normalmente.

Outro corre duas posições.

É o famoso algoritmo da Tartaruga e da Lebre.

Ele consegue descobrir ciclos sem utilizar memória adicional.

Uma verdadeira obra de elegância.


Árvores: Muito Mais Presentes do Que Você Imagina

Quando pensamos em árvores normalmente lembramos da faculdade.

Mas elas aparecem diariamente.

Diretórios.

Menus.

JSON.

XML.

LDAP.

Catálogos.

Organogramas.

Até um Plano de Contas contábil é uma árvore.

Quando aprendemos percursos como:

  • Preorder

  • Inorder

  • Postorder

  • Level Order

Estamos aprendendo maneiras diferentes de visitar essa hierarquia.


Grafos: O Modelo Universal

Existe uma frase famosa na Ciência da Computação:

"Tudo pode ser modelado como um grafo."

Internet.

Rotas.

Redes sociais.

Dependências.

Fluxos.

Microserviços.

Tudo isso pode ser representado por nós ligados entre si.

Os principais algoritmos são:

  • BFS

  • DFS

  • Dijkstra

  • Topological Sort

Se você entende esses quatro...

...já resolve uma enorme quantidade de problemas reais.


Programação Dinâmica: A Arte de Não Fazer o Mesmo Trabalho Duas Vezes

Esse talvez seja o assunto que mais assusta iniciantes.

Mas a ideia é incrivelmente simples.

Imagine calcular Fibonacci.

Sem memória:

Fib(40)

↓

Fib(39)

↓

Fib(38)

↓

...

Os mesmos cálculos aparecem centenas de milhares de vezes.

Programação Dinâmica guarda os resultados.

Quando precisar novamente...

...apenas consulta.

No Mainframe fazemos isso frequentemente.

Tabelas em memória.

Caches.

Arquivos temporários.

Tudo isso segue exatamente essa filosofia.


Greedy: A Melhor Decisão Agora

Alguns problemas permitem escolher sempre a melhor opção local.

Quando isso acontece...

...Greedy produz soluções extremamente rápidas.

Mas cuidado.

Nem todo problema aceita essa abordagem.

Saber reconhecer quando Greedy funciona é tão importante quanto conhecer o algoritmo.


Manipulação de Bits: O Poder Escondido do Hardware

Bits ainda são fundamentais.

Operações como:

AND

OR

XOR

SHIFT

São extremamente rápidas.

Mainframes utilizam instruções de hardware especializadas justamente para explorar esse tipo de operação.

Muitos algoritmos de criptografia, compressão e otimização dependem delas.


Estruturas Avançadas

Quando os problemas ficam maiores surgem novas ferramentas.

Segment Trees.

Fenwick Trees.

Sweep Line.

Meet in the Middle.

Essas técnicas aparecem menos no dia a dia, mas são muito comuns em competições de programação e entrevistas de empresas de tecnologia.

Elas demonstram que um mesmo problema pode ser atacado por diferentes estratégias, cada uma adequada a um cenário específico.


O Que Realmente Avaliam em uma Entrevista Técnica?

Muitos imaginam que a empresa quer saber se você decorou o algoritmo de Dijkstra.

Na realidade ela observa outra coisa.

Seu raciocínio.

Ela quer entender se você consegue:

  • Identificar a estrutura de dados correta.

  • Escolher o algoritmo adequado.

  • Explicar por que essa escolha é eficiente.

  • Comparar alternativas.

  • Analisar complexidade de tempo e memória.

  • Escrever um código claro e correto.

A implementação é importante, mas a capacidade de justificar as decisões costuma pesar ainda mais.


O Caminho de Estudos para um COBOL Padawan

Se eu estivesse orientando um jovem programador COBOL hoje, seguiria esta ordem:

  1. Arrays e Strings.

  2. Hash Maps.

  3. Stacks e Queues.

  4. Linked Lists.

  5. Árvores.

  6. Grafos.

  7. Recursão.

  8. Heaps.

  9. Programação Dinâmica.

  10. Técnicas avançadas.

Depois disso, sim, começaria a resolver problemas no LeetCode, HackerRank ou plataformas semelhantes.

Porque, nesse momento, cada exercício deixaria de ser um enigma e passaria a ser um reconhecimento de padrões.


Conclusão: O Verdadeiro Poder Está na Forma de Pensar

Existe um mito de que grandes programadores possuem uma memória extraordinária e conhecem milhares de algoritmos. A realidade é bem diferente. Eles desenvolveram um repertório de padrões e sabem identificar rapidamente qual deles se aplica a um problema.

O programador COBOL possui uma vantagem importante nessa jornada. Décadas trabalhando com arquivos sequenciais, VSAM, DB2, índices, tabelas OCCURS, processamento batch e transações CICS desenvolveram uma disciplina de raciocínio que continua extremamente valiosa. O desafio não é abandonar esse conhecimento, mas traduzi-lo para a linguagem moderna das Estruturas de Dados e Algoritmos.

Quando você perceber que um SEARCH ALL é uma busca binária, que uma tabela OCCURS é um array, que uma fila JES2 segue o princípio de uma queue, ou que um índice DB2 representa uma estrutura otimizada para acesso eficiente, verá que DSA não é um universo distante do Mainframe. É a formalização de conceitos que sempre estiveram presentes.

No fim das contas, programar bem nunca foi sobre decorar centenas de soluções. Sempre foi sobre observar, modelar e resolver problemas da forma mais elegante possível. É essa mentalidade que transforma um Padawan COBOL em um verdadeiro Arquiteto de Software, capaz de navegar tanto pelos sistemas legados que movem bancos e governos quanto pelas tecnologias modernas que definem o futuro da computação.


segunda-feira, 6 de julho de 2020

🧬 MYNE E A BIBLIOTECA DOS LOGS ESQUECIDOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE UMA IA PODE INVESTIGAR UM ATAQUE DE CINCO ANOS ATRÁS

 
Bellacosa Mainframe e o controle dos logs

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🧬 MYNE E A BIBLIOTECA DOS LOGS ESQUECIDOS — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE UMA IA PODE INVESTIGAR UM ATAQUE DE CINCO ANOS ATRÁS

SMF, RACF, CICS, Db2, MQ, Threat Intelligence, Historical Threat Hunting, IOC, TTP, embeddings, grafos temporais, Inteligência Artificial, COBOL, arqueologia digital — e o dia em que Myne descobriu que alguns livros só podem ser compreendidos depois de escritos.



🎬 PRÓLOGO — MYNE ENCONTROU UMA BIBLIOTECA QUE NINGUÉM LIA

Myne entrou no CPD carregando três livros.

Isso por si só não deveria surpreender ninguém que conhecesse Honzuki no Gekokujou: Shisho ni Naru Tame ni wa Shudan wo Erandeiraremasen.

Se existisse uma biblioteca dentro de um IBM z17, provavelmente ela tentaria conseguir um cartão de acesso antes mesmo de perguntar onde ficava a saída de emergência.

O programador COBOL olhou para ela.

— Myne, aqui não temos livros.

Ela apontou para as fitas, discos, datasets e arquivos históricos.

— Claro que têm.

— Isso são logs.

— Então vocês têm livros que as máquinas escrevem.

O programador ficou alguns segundos olhando para o terminal 3270.

Droga.

A menina tinha razão.

Porque existe uma maneira curiosa de entender o System Management Facilities — SMF.

O SMF é uma espécie de cronista do z/OS.

Jobs começam.

Jobs terminam.

Usuários entram.

Programas executam.

Recursos são acessados.

Subsistemas trabalham.

Eventos acontecem.

E o mainframe escreve.

E escreve.

E escreve.

Durante anos.

O problema é que frequentemente fazemos algo bastante humano:

guardamos livros que nunca mais lemos.

Myne abriu um deles.

Na capa estava escrito:

SMF — 2021

— O que aconteceu aqui?

— Nada.

— Você leu?

— Na época.

— E o que vocês sabiam naquela época?

Silêncio.

Myne sorriu.

Ali começava nosso problema.

Porque:

O passado não muda. Nosso conhecimento sobre o passado muda.



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

Antes de colocar inteligência artificial, embeddings, grafos e outros nomes bonitos na história, precisamos começar pelo básico.

Um computador executa operações.

Algumas dessas operações produzem registros.

Chamamos genericamente esses registros de logs, embora no mainframe existam estruturas muito mais específicas.

Imagine:

10:01 USER01 LOGIN
10:03 USER01 SUBMIT JOB
10:04 JOB01 START
10:06 JOB01 READ DATASET
10:07 JOB01 END RC=0000
10:09 USER01 LOGOFF

Isso é uma narrativa extremamente simplificada daquilo que aconteceu.

Perceba uma coisa importante.

O log normalmente não escreve:

10:03 HACKER COMEÇOU ATAQUE

Ele registra um evento.

Quem precisa interpretar o significado daquele evento somos nós.

No universo z/OS temos uma fonte particularmente importante:

SMF — System Management Facilities.

O SMF registra inúmeros tipos de atividades do sistema.

Existem diferentes record types, cada um representando determinadas categorias de informação.

Um exemplo muito conhecido é o SMF Type 30, relacionado ao ciclo de vida de jobs, started tasks, sessões TSO e outras atividades.

No mundo da segurança RACF encontramos registros como o SMF Type 80, capazes de registrar eventos relacionados à segurança.

Nosso programador COBOL pode imaginar algo conceitualmente semelhante a:

01 SECURITY-EVENT.
   05 EVENT-DATE       PIC X(10).
   05 EVENT-TIME       PIC X(08).
   05 USER-ID          PIC X(08).
   05 RESOURCE-NAME    PIC X(44).
   05 ACCESS-TYPE      PIC X(08).
   05 RESULT-CODE      PIC X(04).

Não é a estrutura real do SMF.

É apenas nosso copybook didático.

Agora imagine:

USER-ID       = JOAO
RESOURCE-NAME = FINANCE.PAYROLL
ACCESS-TYPE   = READ
RESULT-CODE   = 0000

Tudo certo.

João estava autorizado.

RACF respondeu:

ACCESS ALLOWED

O erro começa quando transformamos isso mentalmente em:

ACCESS ALLOWED = ATIVIDADE LEGÍTIMA

Não.

RACF respondeu uma pergunta:

Essa identidade possui autorização para realizar essa operação?

Mas existe outra pergunta:

Essa operação faz sentido dentro do comportamento esperado dessa identidade?

E outra:

Por que essa identidade acessou esse recurso às 02:17?

E outra:

O que aconteceu cinco minutos antes?

E outra:

O que aconteceu depois?

E finalmente:

Outras identidades fizeram exatamente a mesma sequência?

Agora nossa investigação começa a ficar interessante.



📚 CAPÍTULO 2 — MYNE DESCOBRE QUE O MAINFRAME ESCREVE LIVROS HÁ DÉCADAS

Myne observou as pilhas de registros históricos.

— Quanto tempo vocês guardam isso?

O operador respondeu:

— Depende.

Essa talvez seja uma das respostas mais importantes de toda nossa história.

Porque nenhuma IA pode analisar aquilo que deixou de existir.

Imagine:

2021 → LOGS → RETENÇÃO → DELETE

Chegamos a 2026.

Descobrimos uma nova técnica de ataque.

Queremos investigar 2021.

Mas:

DATA NOT FOUND

Fim da investigação.

IA não é necromante de storage.

Se o dado foi destruído, não existe prompt capaz de ressuscitá-lo fielmente.

Por isso retenção é uma decisão de segurança.

Uma organização pode preservar diferentes tipos de telemetria:

SMF
RACF
CICS
Db2
IMS
MQ
Syslog
Firewall
Proxy
DNS
EDR
IAM
APIs
Aplicações
OpenTelemetry

E isso cria algo extraordinário:

uma memória operacional da organização.

Myne entendeu imediatamente.

— Então vocês possuem livros contando o que o computador fez?

— Sim.

— E podem relê-los?

— Sim.

— Então por que não fazem isso quando aprendem algo novo?

O programador COBOL congelou.

Boa pergunta.



🕰️ CAPÍTULO 3 — A MÁQUINA DO TEMPO NÃO É A IA

Existe uma distinção importante.

Quando dizemos:

"Uma IA poderia descobrir em 2026 um ataque ocorrido em 2021?"

parece que a IA está viajando no tempo.

Não está.

A verdadeira máquina do tempo é:

telemetria preservada.

Imagine:

2021
 │
 ├── SMF
 ├── RACF
 ├── CICS
 ├── Db2
 └── MQ
      │
      ↓
 HISTORICAL STORAGE
      │
      ↓
     2026

Agora podemos fazer perguntas novas sobre informações antigas.

Essa diferença é fundamental.

A equação não é:

IA = MÁQUINA DO TEMPO

É:

RETENÇÃO
   +
NOVO CONHECIMENTO
   +
NOVAS FERRAMENTAS
   =
REANÁLISE DO PASSADO

E isso nos leva à ideia central deste artigo:

Dados antigos podem produzir descobertas novas.



🔬 CAPÍTULO 4 — O ATAQUE QUE NÃO EXISTIA EM 2021

Calma.

O ataque existia.

O que talvez não existisse era nosso conhecimento sobre ele.

Imagine que encontramos isto em 2021:

REMOTE-IP = 198.51.100.77

Consultamos nossas fontes.

Resultado:

UNKNOWN

Nada especialmente interessante.

Cinco anos passam.

Outras organizações são atacadas.

Pesquisadores investigam.

Infraestruturas são relacionadas.

Malwares são analisados.

Técnicas são documentadas.

Surge nova threat intelligence.

Agora descobrimos:

198.51.100.77
      ↓
Infrastructure associated with Campaign X

Imediatamente surge uma pergunta:

Esse endereço apareceu alguma vez em nossa infraestrutura?

Consultamos os registros históricos.

SELECT *
FROM HISTORICAL_EVENTS
WHERE REMOTE_IP = '198.51.100.77';

E encontramos:

17/04/2021
24/04/2021
02/05/2021
09/05/2021

O endereço que parecia irrelevante ganhou significado.

O passado mudou?

Não.

Mudou nosso conhecimento.


🧬 CAPÍTULO 5 — IOC: AS PEGADAS MAIS ÓBVIAS

Aqui nosso programador COBOL precisa conhecer uma sigla:

IOC — Indicator of Compromise.

Pode envolver coisas como:

IP
domínio
hash
arquivo
URL
certificado

Imagine que conhecemos o hash de um malware.

Podemos pesquisar registros históricos procurando aquele valor.

Isso é útil.

Mas existe um problema.

Atacantes podem trocar infraestrutura.

Mudam IP.

Mudam domínio.

Recompilam malware.

Alteram hashes.

Então:

HASH-A

vira:

HASH-B

Uma detecção baseada exclusivamente em igualdade pode falhar.

IF HASH = KNOWN-BAD-HASH
    PERFORM SECURITY-ALERT
END-IF.

Se mudou um byte:

NO MATCH

Por isso precisamos subir um degrau.


🥷 CAPÍTULO 6 — TTP: NÃO PROCURE APENAS O SAPATO, PROCURE O JEITO DE ANDAR

Agora encontramos:

TTP — Tactics, Techniques and Procedures.

Em vez de perguntar apenas:

Qual IP o atacante utilizou?

podemos perguntar:

Como ele trabalha?

Talvez uma campanha costume realizar algo parecido com:

obter credencial
      ↓
autenticar
      ↓
enumerar recursos
      ↓
executar programa legítimo
      ↓
acessar dados
      ↓
movimentar informações

IPs podem mudar.

Usuários podem mudar.

Hosts podem mudar.

Mas certas características comportamentais podem permanecer.

É como reconhecer alguém não pelo sapato, mas pelo jeito de andar.

E agora nosso histórico fica muito mais valioso.

Porque podemos perguntar:

Existe no passado alguma sequência parecida com esse comportamento?

Essa pergunta seria extremamente difícil usando apenas pesquisas exatas.

É aqui que entram técnicas mais modernas.


🕸️ CAPÍTULO 7 — MYNE DESENHA UM GRAFO NA MESA DO CPD

Myne pegou uma folha.

Escreveu:

USER01

Depois:

JOB17

Ligou os dois:

USER01 ──SUBMITTED──> JOB17

Acrescentou:

JOB17 ──EXECUTED──> PROG01

Depois:

PROG01 ──READ──> PAYROLL.DATA

Finalmente:

PROG01 ──PUT──> MQ.EXTERNAL

O programador COBOL olhou.

— Você fez um grafo.

— Fiz uma história.

Exatamente.

Grafos são extraordinariamente úteis porque permitem representar:

entidades

como:

USER
JOB
PROGRAM
DATASET
TRANSACTION
IP
DATABASE
QUEUE
CERTIFICATE
HOST
API

e:

relações

como:

submitted
executed
read
connected
authenticated
called
sent
received

Assim:

USER01
   │
submitted
   ↓
 JOB17
   │
executed
   ↓
 PROG01
   │
  read
   ↓
CUSTOMER.DATA

O que antes eram quatro linhas espalhadas em bilhões de registros torna-se uma relação visual e computável.


⏱️ CAPÍTULO 8 — O GRAFO PRECISA DE UM RELÓGIO

Segurança possui uma característica essencial:

tempo.

Não basta saber:

USER01 → DATASET

Precisamos saber quando.

Imagine:

02:01 LOGIN
02:04 SUBMIT JOB
02:06 READ DATASET
02:08 DB2 QUERY
02:10 MQ PUT
02:12 LOGOFF

Agora encontramos outra identidade:

03:01 LOGIN
03:04 SUBMIT JOB
03:06 READ DATASET
03:08 DB2 QUERY
03:10 MQ PUT
03:12 LOGOFF

E outra:

01:31 LOGIN
01:34 SUBMIT JOB
01:36 READ DATASET
01:38 DB2 QUERY
01:40 MQ PUT
01:42 LOGOFF

Individualmente:

NORMAL
NORMAL
NORMAL

Mas a sequência diz:

🤨

Por que três usuários diferentes executaram praticamente a mesma cadeia?

Criamos então um:

grafo temporal.

Não queremos apenas relações.

Queremos relações ordenadas no tempo.


🧠 CAPÍTULO 9 — ENTRAM OS EMBEDDINGS

Aqui precisamos evitar transformar IA em magia.

Um embedding é uma representação numérica de alguma informação.

De maneira extremamente simplificada:

evento/sequência
       ↓
representação
       ↓
embedding
       ↓
[0.18, -0.42, 0.71, 0.09 ...]

Dependendo de como o sistema foi construído, podemos comparar representações buscando similaridade.

Isso muda nossa pesquisa.

O velho modelo perguntava:

IS A = B?

Agora podemos perguntar:

HOW SIMILAR IS A TO B?

Imagine um ataque conhecido:

LOGIN
 ↓
PRIVILEGE CHANGE
 ↓
JOB SUBMISSION
 ↓
UNUSUAL READ
 ↓
TRANSFER

No passado encontramos:

LOGIN
 ↓
PRIVILEGE CHANGE
 ↓
JOB SUBMISSION
 ↓
DB2 READ
 ↓
TRANSFER

Não é idêntico.

Mas estruturalmente talvez seja interessante.

O mecanismo pode dizer:

HIGH SIMILARITY

Isso não significa:

ATTACK CONFIRMED

Significa:

INVESTIGATE THIS

Essa diferença é gigantesca.


🔗 CAPÍTULO 10 — CINCO EVENTOS INOCENTES PODEM FORMAR UM ATAQUE

Agora chegamos ao coração da investigação.

Imagine:

RACF

USER01 accessed DATASET.X
SUCCESS

Normal.

JES/SMF

USER01 submitted JOB77
SUCCESS

Normal.

Db2

APP17 queried CUSTOMER
SUCCESS

Normal.

MQ

APP17 PUT QUEUE.EXTERNAL
SUCCESS

Normal.

Rede

HOST17 contacted external destination
SUCCESS

Normal.

Separadamente:

NORMAL
NORMAL
NORMAL
NORMAL
NORMAL

Agora ligamos tudo:

USER01
   ↓
JOB77
   ↓
APP17
   ↓
CUSTOMER
   ↓
MQ.EXTERNAL
   ↓
HOST17
   ↓
EXTERNAL DESTINATION

Oops.

Esse é um princípio extraordinariamente importante:

um ataque pode ser construído inteiramente com operações que, isoladamente, são legítimas.

O atacante não precisa necessariamente quebrar a porta.

Talvez possua uma chave válida.


👻 CAPÍTULO 11 — O FANTASMA QUE NUNCA RECEBEU ACCESS DENIED

Nosso invasor hipotético é cuidadoso.

Durante meses:

ACCESS ALLOWED
RC=0000
SUCCESS
SUCCESS
SUCCESS

Nenhuma senha inválida.

Nenhum acesso negado.

Nenhum programa obviamente malicioso.

Nenhum:

HACKER.EXE

Ele utiliza:

credencial válida
programa válido
job válido
dataset permitido
transação legítima

Uma defesa baseada exclusivamente em:

IF ACCESS-DENIED
    PERFORM ALERT
END-IF

pode não perceber nada.

Precisamos perguntar também:

É comum?

É esperado?

Esse horário é normal?

Esse usuário costuma acessar esse dataset?

Esse job normalmente executa esse programa?

Por que isso aconteceu depois daquele outro evento?

Quem mais apresentou a mesma sequência?

Saímos de:

EVENT SECURITY

para:

BEHAVIOR SECURITY

🧮 CAPÍTULO 12 — O PERFORM UNTIL DA SEGURANÇA

Nosso COBOLzeiro finalmente percebe algo familiar.

Antigamente ele poderia imaginar:

IF RESULT-CODE NOT = ZERO
    PERFORM WRITE-ALERT
END-IF.

Agora nosso sistema conceitualmente executa:

PERFORM ANALYZE-RELATIONSHIP
   UNTIL NO-MORE-RELATIONSHIPS.

Pergunta:

quem chamou isso?

Depois:

o que essa entidade chamou?

Depois:

quem mais fez isso?

Depois:

o que aconteceu antes?

Depois:

o que aconteceu depois?

Depois:

isso aconteceu em outro LPAR?

Depois:

há comportamento semelhante em 2021?

É quase um gigantesco PERFORM UNTIL investigativo.

E, sim, nosso velho COBOL acabou de encontrar graph analytics.


🦴 CAPÍTULO 13 — LOGS SÃO FÓSSEIS DIGITAIS

Myne fechou o livro de 2021.

— Então vocês são arqueólogos.

— Analistas de segurança.

— Arqueólogos.

Pensando bem...

Ela novamente tinha razão.

Um fóssil não muda quando descobrimos uma nova teoria.

Uma amostra biológica antiga não muda quando inventamos um novo sequenciador.

Uma fotografia antiga não muda quando desenvolvemos melhor processamento de imagem.

O que muda é nossa capacidade de extrair conhecimento do artefato.

Logs podem funcionar da mesma maneira.

São:

fósseis digitais.

Em 2021:

DATA2021
+
KNOWLEDGE2021
=
INTERPRETATION2021

Em 2026:

DATA2021
+
KNOWLEDGE2026
=
INTERPRETATION2026

O primeiro termo permanece.

O segundo mudou.

Consequentemente, o terceiro também pode mudar.


🕳️ CAPÍTULO 14 — O EVENTO QUE NÃO EXISTE

Existe uma possibilidade ainda mais fascinante.

Imagine:

02:01 EVENT
02:02 EVENT
02:03 EVENT

      ...

02:17 EVENT
02:18 EVENT

Existe um buraco.

Na época alguém escreveu:

Collector failure.

Cinco anos depois aprendemos que determinada técnica pode provocar justamente perda ou degradação da telemetria.

Agora:

NO EVENT

torna-se potencialmente:

EVENT OF INTEREST

Isso parece paradoxal.

Mas segurança frequentemente trabalha com expectativas.

Se sabemos que determinado sistema deveria produzir:

A
B
C
D
E

e encontramos:

A
B
C

E

a ausência de D merece explicação.

Em lógica:

EXPECTED(EVENT-D)
AND
NOT(EVENT-D)

pode ser informação.

Myne sorriu.

— Até páginas arrancadas contam uma história.

Exatamente.


🔎 CAPÍTULO 15 — ENCONTRANDO O "PACIENTE ZERO"

Suponhamos que detectamos uma intrusão em 2026.

Começamos a reconstruir o grafo para trás.

2026
 ↑
2025
 ↑
2024
 ↑
2023
 ↑
2022
 ↑
2021

Finalmente encontramos:

17/03/2021
USERX
JOBY
HOSTZ

Antes disso, nada relacionado aparece.

Podemos chamar isso de primeiro evento observado relacionado à investigação.

Mas cuidado.

Não devemos automaticamente afirmar:

"O ataque começou exatamente aqui."

Talvez registros anteriores tenham sido destruídos.

Talvez o atacante estivesse em uma área sem telemetria.

Talvez nossa correlação esteja incompleta.

A formulação tecnicamente responsável é:

Esse é o ponto mais antigo que conseguimos associar à atividade usando a telemetria atualmente disponível.

Segurança também é saber onde termina nossa evidência.


⚠️ CAPÍTULO 16 — IA TAMBÉM ENXERGA FANTASMAS

Agora precisamos destruir uma ilusão.

Se pesquisarmos:

10.000.000.000 eventos

vamos encontrar coincidências.

Muitas.

Algumas parecerão assustadoras.

Isso não significa que sejam ataques.

Portanto:

ANOMALIA ≠ ATAQUE

CORRELAÇÃO ≠ CAUSALIDADE

SIMILARIDADE ≠ IDENTIDADE

EMBEDDING PRÓXIMO ≠ MESMO ATACANTE

MESMO IP ≠ MESMA PESSOA

Um modelo pode encontrar uma sequência extremamente semelhante à de uma campanha conhecida.

Excelente.

Mas o próximo passo deveria ser:

HYPOTHESIS
     ↓
RAW EVIDENCE
     ↓
TIMELINE
     ↓
CORROBORATION
     ↓
ANALYST
     ↓
CONCLUSION

Não:

AI
 ↓
GUILTY

A IA é extraordinária para reduzir um oceano de eventos a um conjunto investigável.

A conclusão continua dependendo das evidências.


🏗️ CAPÍTULO 17 — CONSTRUINDO A BIBLIOTECA DE MYNE

Se quiséssemos construir nosso Bellacosa Historical Threat Hunting Lab, poderíamos imaginar:

          HISTORICAL TELEMETRY
                  │
      ┌───────────┼───────────┐
      ↓           ↓           ↓
     SMF         RACF       CICS
      │           │           │
      ├───────────┼───────────┤
      ↓           ↓           ↓
     Db2          MQ        NETWORK
      └───────────┼───────────┘
                  ↓
            NORMALIZATION
                  ↓
             ENTITY MODEL
                  ↓
            TEMPORAL GRAPH
                  ↓
       ┌──────────┴──────────┐
       ↓                     ↓
   EMBEDDINGS          THREAT INTEL
       └──────────┬──────────┘
                  ↓
            AI ANALYSIS
                  ↓
             HYPOTHESES
                  ↓
          HUMAN INVESTIGATION

Observe algo importante.

IA está perto do final.

Porque antes dela existe muito trabalho pouco glamouroso:

coleta
qualidade
retenção
normalização
identidade
timestamp
integridade
contextualização

Garbage in, garbage out continua valendo em 2026.


🧹 CAPÍTULO 18 — NORMALIZAÇÃO: O TRABALHO QUE NINGUÉM COLOCA NA DEMO

SMF fala sua língua.

CICS possui seus eventos.

Db2 possui os seus.

MQ possui os seus.

Linux possui outros.

Cloud tem outros.

Aplicações têm outros.

Precisamos transformar:

SMF EVENT
CICS EVENT
DB2 EVENT
MQ EVENT
LINUX EVENT
CLOUD EVENT

em alguma representação comparável:

CANONICAL SECURITY EVENT

Conceitualmente:

{
  "timestamp": "...",
  "identity": "...",
  "source": "...",
  "action": "...",
  "resource": "...",
  "result": "...",
  "system": "..."
}

Agora podemos perguntar:

WHO
DID WHAT
TO WHAT
FROM WHERE
WHEN
WITH WHAT RESULT

Parece simples.

Na prática, essa pode ser uma das partes mais difíceis do projeto.


🔄 CAPÍTULO 19 — O PULO DO GATO: REPROCESSAR AUTOMATICAMENTE O PASSADO

Agora chegamos à ideia que Myne realmente gostou.

Um novo livro chega à biblioteca:

NEW THREAT INTELLIGENCE

Em vez de utilizá-lo apenas para detectar ataques futuros, o sistema pergunta:

Isso aconteceu conosco antes?

Automaticamente:

NEW IOC
   ↓
SEARCH HISTORY

ou:

NEW TTP
   ↓
SEARCH HISTORY

ou:

NEW BEHAVIORAL MODEL
   ↓
SEARCH HISTORY

Resultado:

2026 → NO MATCH
2025 → WEAK
2024 → WEAK
2023 → STRONG
2022 → STRONG
2021 → POSSIBLE FIRST OBSERVATION

Acabamos de criar algo fascinante:

Threat Intelligence Time Machine.

Não estamos somente protegendo o futuro.

Estamos continuamente reinterpretando o passado.


💾 CAPÍTULO 20 — ENTÃO GUARDEMOS TUDO PARA SEMPRE!

O programador COBOL levantou a mão.

— Resolvido. Guardamos tudo.

Do fundo do CPD vieram quatro vozes.

Storage:

— Quem paga?

Jurídico:

— Precisamos conversar.

Privacidade:

— Nem pense nisso.

Segurança:

— E quem protege esse gigantesco arquivo?

Excelente.

Retenção infinita não é automaticamente uma boa estratégia.

Logs podem conter informações sensíveis.

Um repositório histórico gigantesco também pode virar alvo.

Então precisamos pensar em:

retenção
criptografia
controle de acesso
imutabilidade
integridade
minimização
tokenização
compressão
classificação
requisitos legais
chain of custody

Talvez:

HOT  → meses
WARM → anos
COLD → período maior

Dependendo do valor e das obrigações associadas aos dados.


🧪 CAPÍTULO 21 — UM EXPERIMENTO PARA O PROGRAMADOR COBOL

Quer entender isso praticamente?

Crie um pequeno laboratório conceitual.

PASSO 1 — Crie eventos históricos

2021 USER01 LOGIN
2021 USER01 JOB01
2021 JOB01 READ CUSTOMER
2021 JOB01 MQPUT EXTERNAL

2021 USER02 LOGIN
2021 USER02 JOB09
2021 JOB09 READ INVENTORY

PASSO 2 — Finja que você está em 2021

Nenhum indicador conhecido.

Classifique tudo:

NORMAL

PASSO 3 — Avance para 2026

Agora surge inteligência:

Known suspicious sequence:

LOGIN
→ JOB
→ CUSTOMER READ
→ EXTERNAL MQ PUT

PASSO 4 — Reprocesse 2021

Resultado:

USER01
  ↓
JOB01
  ↓
CUSTOMER
  ↓
EXTERNAL

MATCH

PASSO 5 — Investigue

Não declare ataque automaticamente.

Pergunte:

USER01 deveria fazer isso?

JOB01 era legítimo?

Esse fluxo era documentado?

Qual volume foi transferido?

Existem outros eventos relacionados?

Quem criou JOB01?

Isso aconteceu novamente?

Pronto.

Você acabou de construir uma versão minúscula de historical threat hunting.


🧬 CAPÍTULO 22 — O QUE DEVEMOS PRESERVAR HOJE PARA DESCOBRIR AMANHÃ?

Essa talvez seja a pergunta mais profunda de todo o artigo.

Não é:

Quanto storage precisamos?

Nem:

Quantos anos de SMF devemos guardar?

A pergunta arquitetural é:

Quais evidências do presente precisamos preservar para permitir investigações que ainda não sabemos que serão necessárias?

Porque talvez em 2031 exista uma técnica analítica que hoje nem imaginamos.

E ela possa olhar para:

SMF de 2026

e descobrir algo que passou despercebido.

Isso transforma retenção.

De:

BACKUP

para:

INVESTIGATIVE MEMORY

📖 CAPÍTULO 23 — MYNE FINALMENTE ENTENDE O SMF

Myne colocou o último volume na estante.

Na lombada:

SMF — SEPTEMBER 2026

O programador perguntou:

— Então você acha que deveríamos guardar tudo?

— Não.

— Achei que você adorasse livros.

— Justamente por isso. Uma biblioteca não é um depósito de papel.

Silêncio novamente.

— Precisamos saber o que preservar, como catalogar e como encontrar.

Ela apontou para as estantes.

— Um livro impossível de encontrar quase não existe.

O programador olhou para seus bilhões de registros SMF sem normalização adequada.

Aquilo doeu.


🥚 EASTER EGG — O JOB QUE ESPEROU CINCO ANOS PARA SER LIDO

Em 2021:

//MYNE01  JOB ...
//STEP01  EXEC PGM=BOOKWORM

Executou.

RC=0000

Ninguém ligou.

O SMF registrou.

O dataset foi arquivado.

Os anos passaram.

Em 2026 chegou nova threat intelligence.

O sistema começou a reprocessar o passado.

2026...
2025...
2024...
2023...
2022...
2021...

Então:

MATCH FOUND

O analista abriu o registro.

Data:

17/03/2021 02:17:43

Ele chamou Myne.

— Encontramos o ataque.

Ela corrigiu:

— Não.

— Como não?

— O ataque já estava lá.

Myne apontou para o registro.

— Vocês encontraram a capacidade de lê-lo.


☕ EPÍLOGO — A BIBLIOTECA DO FUTURO JÁ ESTÁ SENDO ESCRITA

Existe uma tentação enorme quando falamos de inteligência artificial em cybersecurity de imaginar máquinas mágicas detectando hackers instantaneamente.

Mas talvez uma das aplicações mais fascinantes da IA seja muito menos cinematográfica.

Ela pode ajudar a reler.

Reinterpretar.

Correlacionar.

Comparar.

Encontrar relações.

Transformar bilhões de eventos isolados em histórias investigáveis.

O mainframe registrou:

USER
JOB
PROGRAM
DATASET
TRANSACTION
MESSAGE
DATABASE
TIMESTAMP

O RACF registrou.

O CICS registrou.

O Db2 registrou.

O MQ registrou.

A rede registrou.

Talvez ninguém tenha entendido a história naquele momento.

Cinco anos depois temos:

novos IOCs
+
novas TTPs
+
threat intelligence
+
grafos temporais
+
embeddings
+
modelos comportamentais
+
IA

e fazemos novamente a pergunta.

De repente:

EVENT
+
EVENT
+
EVENT
+
EVENT

deixa de parecer ruído.

Transforma-se em:

STORY

Essa talvez seja uma das grandes mudanças que IA, graph analytics e threat intelligence podem trazer para investigação digital.

Não apenas perguntar:

O que está acontecendo agora?

Mas:

O que aconteceu conosco quando ainda não sabíamos reconhecer aquilo que estava acontecendo?

E isso nos leva à frase que Myne deixou escrita em uma pequena etiqueta na entrada da biblioteca:

O passado não muda. O conhecimento capaz de interrogá-lo muda.

Em mainframe, isso significa que um SMF aparentemente insignificante produzido hoje pode ser a peça fundamental de uma investigação em 2031.

Por isso logs não são simplesmente lixo operacional.

Nem apenas instrumentos de troubleshooting.

Nem apenas accounting.

Nem apenas auditoria.

Quando preservados com propósito, integridade, contexto e governança, tornam-se:

MEMÓRIA INVESTIGATIVA.

E talvez o SOC do futuro tenha uma função que hoje ainda tratamos como excepcional:

NEW KNOWLEDGE
      ↓
REPROCESS HISTORY
      ↓
DISCOVER RELATIONSHIPS
      ↓
GENERATE HYPOTHESIS
      ↓
HUMAN INVESTIGATION

Uma espécie de:

PERFORM INVESTIGATE-PAST
   UNTIL NO-MORE-QUESTIONS.

Só existe um pequeno problema.

Como qualquer COBOLzeiro experiente percebeu imediatamente:

NO-MORE-QUESTIONS

provavelmente nunca será TRUE.

Myne abriu outro volume.

O programador colocou café na caneca.

E em algum dataset esquecido do mainframe havia um registro de cinco anos atrás esperando pacientemente que alguém inventasse a pergunta certa.

Porque algumas histórias são registradas muito antes de existir alguém capaz de entendê-las.

☕ Bellacosa Mainframe — onde até o SMF antigo merece uma segunda leitura.

quarta-feira, 12 de fevereiro de 2020

👑 KAZUYA SOUMA ASSUME O RACF — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE GOVERNAR PRIVILÉGIOS ERA MAIS DIFÍCIL QUE CONCEDÊ-LOS

 
Bellacosa Mainframe e o perigo dos privilégios


☕ UM CAFÉ NO BELLACOSA MAINFRAME

👑 KAZUYA SOUMA ASSUME O RACF — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE GOVERNAR PRIVILÉGIOS ERA MAIS DIFÍCIL QUE CONCEDÊ-LOS

RACF, COBOL, privilege paths, grafos, grupos, JCL, SURROGAT, started tasks, CICS, Db2, MQ, least privilege, confused deputy, blast radius, graph analytics, segurança — e o dia em que Kazuya Souma descobriu que o problema não era saber quem tinha a chave do castelo, mas descobrir todas as estradas que chegavam ao tesouro.



🎬 PRÓLOGO — SUA MAJESTADE, O USUÁRIO NÃO TEM ACESSO

A reunião começara havia poucos minutos.

Na enorme tela verde estava escrito:

USER: BELL01
RESOURCE: PROD.PAYROLL.MASTER
ACCESS: NONE

O administrador RACF cruzou os braços.

— Resolvido.

Kazuya Souma permaneceu olhando para a tela.

— O que está resolvido?

— O usuário não possui acesso ao arquivo.

— Eu consigo ver isso.

Souma apontou para ACCESS: NONE.

— Minha pergunta é outra.

A sala ficou silenciosa.

— Ele consegue chegar ao arquivo?

O administrador RACF olhou novamente para a tela.

— Acabei de dizer. Não possui acesso.

Souma suspirou.

Chamou o programador COBOL.

Chamou o administrador CICS.

Chamou o DBA Db2.

Chamou a equipe MQ.

Chamou o responsável pelo batch.

Chamou o pessoal de segurança.

Depois desenhou no quadro:

BELL01
   |
   v
APPDEV
   |
   v
JCL
   |
   v
SURROGAT
   |
   v
STARTED TASK
   |
   v
CICS
   |
   v
COBOL
   |
   +------> DB2
   |
   +------> MQ

— Agora — perguntou Souma — alguém consegue me garantir que não existe nenhum caminho daqui até o dado?

Ninguém respondeu.

Souma sorriu.

— Excelente.

O programador COBOL iniciante quase caiu da cadeira.

Excelente?

Foi naquele momento que ele descobriu a primeira regra do novo rei do CPD:

Não confunda ausência de permissão direta com ausência de capacidade.

E nossa história começa exatamente aí.



🏰 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É RACF?

Antes de falar sobre grafos, privilege paths, CICS ou Db2, precisamos construir nosso reino.

No IBM z/OS, o RACF — Resource Access Control Facility participa do controle de acesso a recursos.

Simplificando bastante para quem está começando, podemos imaginar três perguntas fundamentais:

QUEM É VOCÊ?

Depois:

VOCÊ CONSEGUE PROVAR QUE É VOCÊ?

E finalmente:

VOCÊ PODE FAZER ISSO?

Imagine um userid:

BELL01

e um dataset:

PROD.CLIENTES.MASTER

Dependendo das regras configuradas, a identidade pode possuir níveis de acesso apropriados ao recurso.

Conceitualmente:

BELL01 ---- READ ----> PROD.CLIENTES.MASTER

Ou talvez:

BELL01 ----- X ------> PROD.CLIENTES.MASTER

Nada de acesso.

Para quem acabou de chegar ao mainframe, isso parece suficiente.

Usuário de um lado.

Recurso do outro.

Permissão no meio.

Souma escreveu:

USER ---- ACCESS ----> RESOURCE

— Esse — explicou — é o mapa mais simples do reino.

O COBOLzeiro perguntou:

— E está errado?

— Não.

Souma completou:

— Está incompleto.



🗺️ CAPÍTULO 2 — O MAPA NÃO É O TERRITÓRIO

Imagine uma cidade medieval.

O tesouro real está dentro do castelo.

Você não possui a chave da porta principal.

Portanto:

VOCÊ ---- X ----> TESOURO

Seguro?

Talvez.

Mas existe uma cozinha?

Existe entrada de funcionários?

Existe túnel?

Existe esgoto?

Existe alguém autorizado que recebe ordens suas?

Existe uma carroça que entra diariamente?

Existe uma porta interna ligando outro prédio ao castelo?

A segurança muda quando percebemos que chegar a alguma coisa não exige necessariamente acesso direto a ela.

No mainframe ocorre algo conceitualmente semelhante.

Um usuário talvez não tenha:

READ PROD.PAYROLL.MASTER

mas possa executar uma transação CICS.

A transação executa um programa COBOL.

O programa acessa Db2.

Ou coloca uma mensagem em MQ.

Outro programa consome a mensagem.

Esse consumidor executa sob uma identidade técnica.

E essa identidade possui acesso aos dados.

Nosso desenho deixa de ser:

USER → DATA

e passa a ser:

USER
 ↓
TRANSACTION
 ↓
PROGRAM
 ↓
SERVICE
 ↓
DATABASE
 ↓
DATA

Nenhuma dessas relações é automaticamente uma vulnerabilidade.

Muito pelo contrário.

É assim que sistemas corporativos são construídos.

O desafio está em descobrir se a composição dessas relações produz capacidades que não deveriam existir.



🕸️ CAPÍTULO 3 — SOUMA DESCOBRE A TEORIA DOS GRAFOS

Souma apagou o quadro.

Desenhou vários círculos:

(USER)

(GROUP)

(JCL)

(STC)

(CICS)

(PROGRAM)

(DB2)

(MQ)

— Cada círculo será um nó.

Depois começou a ligá-los.

USER ──member_of──> GROUP
USER ──execute──> TRANSACTION
TRANSACTION ──invokes──> PROGRAM
PROGRAM ──uses──> DB2
PROGRAM ──puts──> MQ QUEUE

Isso é a base de um grafo.

Temos:

nós, representando entidades;

e:

arestas, representando relacionamentos.

Nosso ambiente pode ser transformado conceitualmente em:

USER:BELL01
     |
     | MEMBER_OF
     v
GROUP:APPDEV
     |
     | EXECUTE
     v
CICS:PAYR
     |
     | INVOKES
     v
PROGRAM:PAY001
     |
     | USES
     v
DB2:PAYROLL

Agora temos algo novo.

Um caminho.

Em nosso contexto, um privilege path.

A pergunta deixa de ser somente:

BELL01 tem acesso a PAYROLL?

e passa a incluir:

Existe um caminho entre BELL01 e PAYROLL?

Parece uma diferença pequena.

Não é.

É uma mudança brutal na forma de pensar segurança.



👥 CAPÍTULO 4 — O PODER DOS GRUPOS

Souma chamou seu Ministro dos Grupos.

— Quantos usuários existem?

— Milhares.

— E vocês concedem autorização individualmente para todos?

O homem empalideceu.

Felizmente, não.

Grupos existem justamente porque administrar milhares de usuários individualmente seria uma insanidade.

Podemos ter:

APPDEV
OPERATIONS
DBA
SUPPORT
PAYROLL

e relacionar usuários a eles.

Por exemplo:

BELL01
   ↓
APPDEV

Se APPDEV possuir determinadas capacidades, Bell pode obtê-las através da associação.

Isso introduz o primeiro conceito importante:

Uma capacidade nem sempre aparece diretamente ligada ao usuário.

Ela pode ser transitiva.

Imagine:

BELL01
   ↓
APPDEV
   ↓
RESOURCE

Mas a história pode atravessar subsistemas.

No universo Db2, grupos RACF podem participar da construção dos chamados secondary authorization IDs, dependendo da configuração.

Portanto, conceitualmente:

RACF USER
   ↓
RACF GROUP
   ↓
DB2 SECONDARY AUTHID
   ↓
DB2 PRIVILEGE

Agora perceba a armadilha mental.

Você pergunta:

Existe GRANT diretamente para BELL01?

Não.

E conclui:

BELL01 não possui capacidade.

Conclusão potencialmente precipitada.

Souma escreveu:

DIRECT != TRANSITIVE

Primeiro easter egg do reino.

Quem conhece banco de dados já começou a desconfiar que esse rei pensa em WITH RECURSIVE.


📜 CAPÍTULO 5 — JCL: O PERGAMINHO QUE MANDA O EXÉRCITO TRABALHAR

Para o iniciante COBOL, JCL pode parecer uma linguagem criada por um mago particularmente mal-humorado:

//PAYJOB   JOB ...
//STEP01   EXEC PGM=PAY001
//INPUT    DD DSN=PROD.PAY.INPUT,DISP=SHR
//OUTPUT   DD DSN=PROD.PAY.OUTPUT,DISP=OLD

Mas existe uma separação importante.

O programa COBOL contém lógica.

Algo como:

READ ARQUIVO-CLIENTES

Mas em ambiente batch, o JCL ajuda a definir como aquele trabalho será executado e quais recursos serão associados à execução.

Pense nisso como logística militar.

COBOL diz:

ataque o objetivo.

JCL ajuda a dizer:

use este batalhão, esta estrada, estes suprimentos e este destino.

Agora surge uma pergunta de segurança:

Quem consegue alterar o JCL?

E outra:

Quem consegue alterar uma procedure utilizada por uma execução privilegiada?

Imagine:

USER
 ↓
UPDATE JCL
 ↓
JOB
 ↓
PRIVILEGED EXECUTION
 ↓
RESOURCE

O usuário talvez não possa tocar diretamente no recurso final.

Mas controlar uma parte da execução pode ser extremamente relevante.

Aqui aparece outra lição:

Controlar código, configuração ou fluxo de execução também pode constituir uma forma de poder.


🎭 CAPÍTULO 6 — SURROGAT: O MINISTRO QUE ASSINA EM NOME DE OUTRO

Souma encontrou um mecanismo interessante no reino:

SURROGAT

Em determinados cenários, RACF permite que um usuário devidamente autorizado submeta trabalho para execução sob outra identidade sem precisar conhecer a senha dessa identidade.

Imagine:

BELL01

não possui acesso a:

PAYROLL

Mas existe:

PAYBATCH

que precisa acessar payroll para executar seu trabalho.

Temos:

PAYBATCH
   ↓
PAYROLL

Se Bell possuir legitimamente a capacidade necessária para submeter trabalho como PAYBATCH, nosso grafo pode conter:

BELL01
   ↓
SURROGAT
   ↓
PAYBATCH
   ↓
PAYROLL

Pergunta 1:

BELL01 possui READ diretamente?

Resposta:

NO

Pergunta 2:

Existe um caminho de execução autorizado
que termina em uma identidade com capacidade?

Talvez:

YES

São perguntas diferentes.

Essa distinção precisa entrar na cabeça de quem trabalha com segurança.


🚂 CAPÍTULO 7 — STARTED TASK: O REI NÃO PRECISA EMPURRAR TODA CARROÇA

Agora entramos no universo das started tasks.

No z/OS existem workloads e serviços que precisam executar continuamente ou ser iniciados pelo sistema ou por operadores.

CICS, MQ e muitos outros componentes podem envolver started tasks.

Conceitualmente podemos ter:

PAYSTC
   ↓
STARTED PROFILE
   ↓
PAYUSER

Aqui aparece uma distinção essencial:

Quem solicitou alguma coisa não é necessariamente a mesma identidade sob a qual o trabalho subsequente será executado.

Imagine:

HUMAN USER
   ↓
REQUEST
   ↓
SERVICE
   ↓
SERVICE USER

O service user pode possuir capacidades diferentes das do usuário humano.

Isso é proposital.

Serviços precisam trabalhar.

O problema aparece quando esquecemos de incluir essa transformação de identidade em nosso mapa.

Souma mandou escrever na parede do CPD:

ALWAYS ASK:

WHO REQUESTED?

WHO EXECUTED?

UNDER WHICH AUTHORITY?

🏦 CAPÍTULO 8 — CICS: A CAPITAL DO REINO

Chegamos ao CICS.

Para quem está começando, pense no CICS — Customer Information Control System como uma plataforma fundamental para processamento transacional no universo mainframe.

Imagine uma transação:

SALO

que chama:

SALDO01

Então:

USER
 ↓
CICS:SALO
 ↓
COBOL:SALDO01

O programa pode consultar Db2:

EXEC SQL
    SELECT SALDO
      INTO :WS-SALDO
      FROM CONTA
     WHERE CONTA_ID = :WS-CONTA
END-EXEC.

O usuário não precisa necessariamente possuir acesso direto à tabela CONTA.

Na verdade, isso frequentemente seria indesejável.

Queremos:

USER
 ↓
APPLICATION
 ↓
CONTROLLED OPERATION
 ↓
DATABASE

e não:

USER
 ↓
EVERYTHING IN DATABASE

A aplicação atua como uma barreira.

Ou deveria.


🧙 CAPÍTULO 9 — O COBOLZEIRO DESCOBRE QUE TAMBÉM É GUARDA

Souma chamou o programador.

— Quem preenche WS-CONTA?

— A transação.

— E de onde vem o valor?

Silêncio.

Souma continuou:

— O usuário consegue alterá-lo?

Mais silêncio.

— E vocês verificam se a conta solicitada pertence ao usuário autenticado?

Agora o COBOLzeiro entendeu.

Segurança não termina no RACF.

Imagine que o programa deveria permitir:

CONSULTAR MINHA CONTA

mas aceite sem validação adequada:

CONSULTAR CONTA 8472

e depois:

CONSULTAR CONTA 8473

e:

CONSULTAR CONTA 8474

A infraestrutura pode estar funcionando exatamente como projetada.

RACF funcionando.

CICS funcionando.

Db2 funcionando.

O defeito está na autorização de negócio dentro da aplicação.

Isso significa que o programador COBOL também participa do modelo de segurança.

Não precisa ser administrador RACF.

Mas precisa entender:

IDENTITY
AUTHENTICATION
AUTHORIZATION
INPUT
BUSINESS RULE
EXECUTION CONTEXT

Seu IF também pode ser uma muralha.


🤵 CAPÍTULO 10 — O CONFUSED DEPUTY DO REINO

Souma contou uma história.

Um ministro possuía autorização para entrar no tesouro.

Os cidadãos não.

Então os cidadãos entregavam solicitações ao ministro.

O ministro verificava a solicitação e buscava o item correspondente.

Perfeito.

Até aparecer uma solicitação:

TRAGA TUDO.

E o ministro respondeu:

— Certamente.

Temos aí a essência do clássico confused deputy problem.

O intermediário possui autoridade legítima.

Uma entidade menos privilegiada consegue induzi-lo a usar essa autoridade de maneira que não deveria.

No nosso mainframe:

USER
 ↓
CICS
 ↓
COBOL PROGRAM
 ↓
SERVICE AUTHORITY
 ↓
DB2

O programa pode legitimamente possuir capacidade para consultar milhares de clientes.

Mas determinado usuário talvez devesse consultar apenas:

CLIENTE 8472

Se a aplicação não limitar corretamente essa operação, temos um problema.

Observe a sutileza.

O usuário não ganhou:

SYSADM

Não recebeu:

SELECT *

Não alterou RACF.

Ele simplesmente conseguiu fazer uma entidade mais poderosa trabalhar inadequadamente em seu benefício.

Essa é uma classe de problema que uma simples análise:

WHO HAS READ?

pode não revelar.


📦 CAPÍTULO 11 — MQ: O MENSAGEIRO DO REINO

Então chegou um mensageiro.

Chamava-se IBM MQ.

Imagine:

CICS
 ↓
PUT
 ↓
PAY.REQUEST

A aplicação não processa imediatamente o trabalho.

Coloca uma mensagem numa queue.

Outro serviço consome:

PAY.REQUEST
 ↓
PAYCONSUMER

O consumidor pode executar como uma started task:

PAYCONSUMER
 ↓
PAYSTC
 ↓
PAYUSER

e acessar Db2:

PAYUSER
 ↓
DB2
 ↓
PAYROLL

Agora conecte tudo:

BELL01
   ↓
CICS TRANSACTION
   ↓
COBOL PROGRAM
   ↓
MQ PUT
   ↓
PAY.REQUEST
   ↓
CONSUMER
   ↓
STARTED TASK
   ↓
SERVICE USER
   ↓
DB2
   ↓
PAYROLL

Souma perguntou:

— Bell possui acesso direto ao payroll?

Todos responderam:

— Não.

— Bell consegue provocar uma cadeia de processamento que termina no payroll?

Silêncio novamente.

Essa é exatamente a diferença entre:

PERMISSION

e:

REACHABILITY

💥 CAPÍTULO 12 — BLAST RADIUS: QUANTO DO REINO CAI SE UMA IDENTIDADE FOR COMPROMETIDA?

Agora Souma fez uma pergunta diferente.

— Se BELL01 fosse comprometido, até onde alguém conseguiria chegar?

Não queremos somente:

LISTUSER BELL01

Queremos conceitualmente descobrir:

REACHABLE(BELL01)

Talvez apareça:

BELL01
├── APPDEV
│   ├── DEV.DATA
│   └── DB2 privileges
│
├── CICS
│   ├── SALO
│   ├── EXTR
│   └── PAYR
│
├── MQ
│   └── APP.REQUEST
│
└── SURROGAT
    └── APPBATCH

Cada ramo pode abrir novos ramos.

Temos então uma maneira interessante de pensar no blast radius de uma identidade.

Não apenas:

O que ela possui diretamente?

Mas:

Que capacidades podem ser alcançadas a partir dela?

Isso muda a priorização defensiva.

Dois usuários podem possuir dez permissões cada.

Mas um deles alcança apenas desenvolvimento.

O outro consegue atravessar cinco relações e atingir serviços críticos.

Contar permissões não revela necessariamente essa diferença.

O grafo revela.


⚖️ CAPÍTULO 13 — LEAST PRIVILEGE NÃO É APENAS REMOVER ACL

Souma reuniu o conselho.

— Precisamos implementar least privilege.

Alguém imediatamente sugeriu:

— Vamos remover permissões!

Souma respondeu:

— Quais?

Silêncio.

O Principle of Least Privilege diz, em essência, que identidades devem possuir somente as capacidades necessárias para desempenhar suas funções.

Mas nosso grafo permite aprofundar isso.

Não basta minimizar:

DIRECT PERMISSIONS

Também queremos minimizar:

UNNECESSARY PRIVILEGE PATHS

Imagine remover:

BELL01 → PAYROLL

Excelente.

Mas continuar com:

BELL01
 ↓
APPDEV
 ↓
PAYR
 ↓
PAY001
 ↓
PAYDB2
 ↓
PAYROLL

Talvez isso seja necessário para a aplicação.

Talvez não.

A questão é saber que o caminho existe e verificar se cada etapa possui justificativa.

Least privilege deixa de ser somente uma propriedade de ACL.

Passa a ser uma propriedade da arquitetura.


🕷️ CAPÍTULO 14 — O NÓ QUE TODO MUNDO IGNORAVA

Souma então pediu:

— Mostrem todos os caminhos críticos.

Centenas apareceram.

Mas havia algo curioso.

Muitos passavam por:

PROD.CICS.LOADLIB

Outros convergiam para:

PROD.APP.PROCLIB

E muitos dependiam do grupo:

PROD_SUPPORT

Em teoria dos grafos existem medidas de centralidade.

Uma delas, chamada betweenness centrality, ajuda a identificar nós que aparecem em muitos caminhos entre outros nós.

Traduzindo para nosso reino:

Existe alguma ponte pela qual metade do exército precisa passar?

Se existe, proteja muito bem aquela ponte.

Em segurança, esses pontos podem funcionar como choke points.

Talvez um recurso aparentemente banal seja estruturalmente crítico porque centenas de privilege paths passam por ele.

Essa é uma descoberta que listas tradicionais dificilmente tornam intuitiva.


🧮 CAPÍTULO 15 — ALGORITMOS ENTRAM NO CPD

O programador COBOL olhou para o desenho.

— Precisamos verificar isso manualmente?

Souma quase derrubou o café.

Claro que não.

Grafos possuem décadas de algoritmos.

Temos conceitos como:

Breadth-First Search
Depth-First Search
Shortest Path
Dijkstra
Connected Components
Centrality
Community Detection

Imagine uma consulta:

SOURCE = USER:BELL01
TARGET = DB2:PAYROLL

Queremos:

FIND PATH

Resultado:

BELL01
 ↓
APPDEV
 ↓
CICS:PAYR
 ↓
PAY001
 ↓
PAYDB2
 ↓
PAYROLL

Podemos ainda atribuir pesos às relações.

Exemplo puramente conceitual:

GROUP MEMBERSHIP        COST 1
EXECUTE TRANSACTION     COST 1
MQ PUT                  COST 2
SURROGATE               COST 3
MODIFY JCL              COST 4
MODIFY LOADLIB          COST 5

Agora podemos procurar não apenas o caminho com menos saltos, mas caminhos segundo critérios de risco ou relevância definidos pela organização.

A matemática começou a governar o reino.

Souma parecia satisfeito.


🔎 CAPÍTULO 16 — O GOOGLE MAPS DOS PRIVILÉGIOS

Souma teve uma ideia.

— Quero um mapa.

— Já temos relatórios RACF.

— Não quero relatório.

Ele escreveu:

FROM USER:BELL01
TO RESOURCE:PAYROLL

E queria receber:

DIRECT ACCESS: NO

INDIRECT PATHS: 3

ROTA 1

BELL01
 ↓
APPDEV
 ↓
CICS PAYR
 ↓
PAY001
 ↓
PAYDB2
 ↓
PAYROLL

ROTA 2

BELL01
 ↓
MQ
 ↓
PAY.REQUEST
 ↓
PAYSTC
 ↓
PAYUSER
 ↓
PAYROLL

ROTA 3

BELL01
 ↓
SURROGAT
 ↓
PAYBATCH
 ↓
PAYROLL

E então:

REMOVE EDGE:
BELL01 → PAY.REQUEST

RESULT:
ROUTE 2 ELIMINATED

Isso seria praticamente um:

GOOGLE MAPS DOS PRIVILÉGIOS

Você pergunta:

BELL01 → PAYROLL

e recebe:

3 rotas encontradas.

Rota mais curta:
5 saltos.

Existe uma rota alternativa via MQ.

SURROGAT apresenta tráfego intenso.

O administrador RACF não achou graça.

O programador COBOL achou maravilhoso.

Souma aprovou o orçamento.


🤖 CAPÍTULO 17 — ONDE ENTRA INTELIGÊNCIA ARTIFICIAL?

Aqui existe uma tentação perigosa:

jogar todos os logs num LLM e perguntar:

Quem é o vilão?

Não precisamos fazer isso.

Primeiro podemos construir deterministicamente um:

ENTERPRISE PRIVILEGE GRAPH

usando informações de:

RACF
JES
JCL
SURROGAT
STARTED
CICS
DB2
MQ
USS
SMF
APPLICATIONS

Algoritmos de grafos encontram relações e caminhos.

Depois uma IA pode ajudar a transformar:

NODE 481
EDGE 92
NODE 773
EDGE 144
NODE 112

em algo compreensível:

BELL01 não possui acesso direto ao recurso. Entretanto, pertence ao grupo APPDEV, que permite utilizar determinada transação CICS. Essa transação executa PAY001, que utiliza um contexto Db2 autorizado a executar PAYPKG, que acessa PAYROLL.

O algoritmo encontra.

A IA explica.

O humano decide.

Essa divisão de responsabilidades é muito mais interessante que transformar IA em oráculo.


⏰ CAPÍTULO 18 — SOUMA DESCOBRE QUE O MAPA SE MOVE

Na manhã seguinte:

08:00

BELL01 → APPDEV

Às 10:12 alguém realizou uma mudança:

APPDEV → PROD_SUPPORT

Às 10:12:01 nasceram dezenas de novas rotas.

O administrador disse:

— Mas foi apenas uma alteração.

Souma respondeu:

— Uma aresta.

E uma única aresta pode conectar dois enormes conjuntos do grafo.

Imagine dois continentes separados.

Adicione uma ponte.

A ponte é apenas uma estrutura.

Mas milhões de novas rotas passam a existir.

No nosso ambiente:

GRAPH(t0)

antes da mudança.

Depois:

GRAPH(t1)

Calculamos:

DIFF GRAPH(t0,t1)

Resultado hipotético:

DIRECT PERMISSIONS ADDED: 1

NEW TRANSITIVE PATHS: 317

NEW PATHS TO CRITICAL RESOURCES: 12

Agora temos uma aplicação extraordinária para Change Management.

Antes de aprovar uma alteração, poderíamos perguntar:

Qual será o impacto desta mudança no grafo de privilégios?

Não apenas:

WHAT ARE WE ADDING?

Mas:

WHAT WILL BECOME REACHABLE?

Isso é muito mais poderoso.


🧪 CAPÍTULO 19 — LABORATÓRIO DO COBOLZEIRO

Você não precisa construir um Neo4j corporativo amanhã.

Comece com papel.

Escolha uma transação CICS conhecida.

Por exemplo:

SALO

Faça o seguinte.

PASSO 1 — IDENTIDADE

Pergunte:

Quem pode iniciar SALO?

PASSO 2 — TRANSAÇÃO

Descubra:

SALO
 ↓
qual programa?

Talvez:

SALDO01

PASSO 3 — PROGRAMA COBOL

Descubra os recursos usados:

SALDO01
 ├── DB2
 ├── VSAM
 └── MQ

PASSO 4 — DB2

Pergunte:

Qual contexto de autorização?
Qual package?
Quais objetos?

PASSO 5 — MQ

Se existir:

PUT PAY.REQUEST

não pare.

Pergunte:

Quem consome PAY.REQUEST?

PASSO 6 — CONSUMIDOR

Descubra:

QUEUE
 ↓
CONSUMER
 ↓
STC
 ↓
USERID

PASSO 7 — CONTINUE

Pergunte quais recursos esse userid consegue utilizar.

Ao terminar, talvez você tenha:

USER
 ↓
CICS
 ↓
COBOL
 ↓
MQ
 ↓
STC
 ↓
COBOL
 ↓
DB2

Você acabou de construir manualmente um pequeno privilege graph.


🧰 CAPÍTULO 20 — DEZ DICAS DE SOUMA PARA O COBOLZEIRO

1. Não pergunte apenas “quem tem acesso?”

Pergunte:

quem consegue chegar?

2. Aprenda RACF mesmo sem querer ser administrador RACF.

Entenda pelo menos:

USER
GROUP
PROFILE
ACCESS
SURROGAT
STARTED

3. Aprenda JCL.

Seu COBOL não vive sozinho.

4. Quando encontrar CICS, siga a transação.

TRANSACTION → PROGRAM → RESOURCE

5. Quando encontrar MQ, siga a mensagem.

A fila não é necessariamente o destino.

Pode ser apenas uma estrada.

6. Quando encontrar Db2, pense além da tabela.

Considere contextos de autorização, packages, roles e outros mecanismos envolvidos.

7. Pergunte sempre sob qual identidade algo executa.

Essa pergunta vale ouro.

8. Diferencie autenticação de autorização.

Saber quem alguém é não responde automaticamente o que essa pessoa pode fazer.

9. Desenhe.

Cinco caixas e quatro setas podem revelar algo que cinquenta páginas de relatório esconderam.

10. Procure composição.

O problema mais interessante talvez não esteja em nenhum componente isoladamente.

Pode estar na combinação:

RACF + CICS + COBOL + MQ + STC + DB2

🥚 CAPÍTULO 21 — PROJECT REALIST HERO

Às 03:17 da madrugada, o console mostrou:

ICH408I ...

O operador acordou Souma.

— Sua Majestade! Temos um problema!

Souma olhou para a mensagem.

— Qual o impacto?

— Ainda não sabemos.

— Qual identidade?

— BELL01.

— Quais caminhos ela possui?

Silêncio.

— Quais serviços ela consegue acionar?

Silêncio.

— Quais recursos críticos são alcançáveis?

Silêncio.

Souma voltou para a cama.

— Então vocês não têm um incidente.

O operador ficou aliviado.

Souma terminou:

— Vocês têm três perguntas sem resposta. Descubram primeiro.

Na saída havia uma placa:

HOW A REALIST HERO REBUILT THE KINGDOM

SEASON 3:
RACF EDITION

Nenhum produtor confirmou essa temporada.

Principalmente porque provavelmente teríamos três episódios inteiros discutindo LISTGRP.

Eu assistiria.


👑 EPÍLOGO — GOVERNAR NÃO É POSSUIR TODAS AS CHAVES

Meses depois, o reino possuía um enorme mapa.

Nele estavam:

USERS
GROUPS
JCL
PROCEDURES
STARTED TASKS
CICS REGIONS
TRANSACTIONS
COBOL PROGRAMS
DB2 AUTHORIZATION
PACKAGES
TABLES
MQ QUEUES
CONSUMERS
SERVICE IDs

Milhares de nós.

Milhões de relações possíveis.

Souma voltou à pergunta que iniciou tudo.

Na tela:

USER: BELL01

RESOURCE: PROD.PAYROLL.MASTER

DIRECT ACCESS: NONE

O antigo administrador sorriu.

— Então eu estava certo.

Souma concordou.

— Estava.

O homem pareceu surpreso.

Souma continuou:

— Só estava respondendo à pergunta errada.

Na tela apareceu:

INDIRECT PATHS FOUND: 3

Agora todos entenderam.

Segurança não é somente descobrir:

WHO HAS THE KEY?

É descobrir:

WHO CAN REACH THE CASTLE?

Depois:

BY WHICH ROAD?

Depois:

WHO CONTROLS THE ROAD?

E finalmente:

WHAT HAPPENS
IF THAT ROAD CHANGES?

Essa é a transformação fundamental.

RACF continua sendo fundamental.

CICS continua fazendo seu trabalho.

Db2 continua protegendo seus objetos.

MQ continua transportando mensagens.

JES continua executando jobs.

COBOL continua processando negócios.

Cada componente pode estar funcionando perfeitamente.

Mas sistemas empresariais não são componentes isolados.

São relações.

Uma identidade chama uma transação.

A transação chama COBOL.

COBOL chama Db2.

Outro programa publica em MQ.

Uma started task consome a mensagem.

Outra identidade entra em cena.

Um package acessa dados.

E o caminho termina num recurso que estava seis saltos distante do usuário original.

Por isso o próximo nível de segurança não consiste simplesmente em produzir listas maiores de ACLs.

Consiste em compreender a topologia do poder.

Quem possui autoridade?

Quem pode delegá-la?

Quem consegue provocar sua utilização?

Quem controla programas executados por identidades privilegiadas?

Quais caminhos são necessários?

Quais são acidentais?

Quais recursos funcionam como pontes?

Quais alterações criam novas rotas?

E qual é o blast radius se um único nó for comprometido?

Souma levantou-se.

O jovem COBOLzeiro perguntou:

— Então qual é a diferença entre administrar permissões e governar privilégios?

O rei escreveu duas linhas no quadro:

PERMISSION = CAN I OPEN THIS DOOR?

e:

REACHABILITY = IS THERE ANY ROUTE
               THAT TAKES ME INSIDE?

Guardou o marcador.

— Administrar permissões é cuidar das portas.

Apontou para o gigantesco grafo.

— Governar privilégios é conhecer o reino.

No fundo do CPD, JES2 imprimiu a última mensagem da madrugada:

$HASP395 SOUMAJOB ENDED

******************************** TOP OF DATA ********************************

DIRECT ACCESS........ NONE
INDIRECT PATHS....... 0003
CRITICAL PATHS....... 0001

SECURITY RESULT:

DO NOT PANIC.
INVESTIGATE THE GRAPH.

******************************** BOTTOM OF DATA *****************************

O programador COBOL sorriu.

Finalmente tinha entendido por que Kazuya Souma fora convocado.

Ele não derrotava monstros ficando mais poderoso.

Ele olhava para sistemas complicados, descobria como as coisas estavam conectadas e reorganizava o reino.

O que, pensando bem, talvez seja uma descrição surpreendentemente boa do trabalho de um programador mainframe.

E também explica por que, quarenta anos depois, alguém ainda encontra um JCL em produção e pergunta:

QUEM DIABOS DEPENDE DISSO?

A resposta, naturalmente, é:

MUITO MAIS GENTE
DO QUE VOCÊ IMAGINA.

☕ Bellacosa Mainframe

Porque no mainframe a porta pode estar perfeitamente trancada — e ainda assim o verdadeiro trabalho do segurança é descobrir todas as estradas que chegam do outro lado.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...