Bellacosa Mainframe atalhas na segurança que podem comprometer um sistema

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🕸️ BELL CRANEL ENTRA NA DUNGEON DO RACF — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE NÃO PRECISAVA TER ACESSO AO DADO PARA CHEGAR ATÉ ELE

RACF, privilege paths, grafos, grupos, JCL, SURROGAT, started tasks, CICS, Db2, MQ, COBOL, confused deputy, least privilege, blast radius, graph analytics — e o dia em que Bell Cranel descobriu que derrotar o monstro não exigia atravessar a porta da frente.

---

🎬 PRÓLOGO — BELL, VOCÊ NÃO TEM ACESSO

Bell Cranel estava parado diante de uma enorme porta de ferro.

No centro dela havia uma pequena placa:

PROD.PAYROLL.MASTER

Bell aproximou seu cartão de identificação.

Uma luz vermelha apareceu.

ICH408I USER(BELL)
DATASET(PROD.PAYROLL.MASTER)
ACCESS INTENT(READ)
ACCESS ALLOWED(NONE)

— Negado — disse Bell.

O veterano COBOLzeiro sentado alguns metros atrás tomou tranquilamente seu café.

— Excelente.

Bell olhou desconfiado.

— Excelente? Eu não consigo entrar.

— Você tentou a porta.

— Claro. Como mais eu entraria?

O velho apontou para a gigantesca construção atrás da porta.

Havia corredores, escadas, elevadores, passagens de manutenção, túneis, portas laterais, filas MQ, regiões CICS, jobs batch, started tasks e conexões Db2.

— Bell... isso aqui é um mainframe.

Ele tomou outro gole.

— Nunca presuma que existe apenas uma entrada.

Foi naquele momento que Bell Cranel descobriu que estava prestes a entrar em uma nova Dungeon.

Não uma Dungeon de monstros.

Uma Dungeon de privilégios.

---

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

Se você começou agora em COBOL e mainframe, precisamos começar do começo.

Em sistemas IBM z/OS existe um componente fundamental chamado RACF — Resource Access Control Facility.

Simplificando bastante, RACF ajuda a responder perguntas como:

Quem é você?

Você conseguiu provar que é você?

e:

Você pode fazer isso?

Imagine um usuário:

BELL01

e um dataset:

PROD.CLIENTES.MASTER

RACF pode determinar que Bell possui:

READ

ou:

UPDATE

ou:

ALTER

ou simplesmente:

NONE

Para quem está começando, é tentador imaginar segurança assim:

USER
 |
 |
 v
RESOURCE

Perguntamos:

BELL01 pode acessar PROD.CLIENTES.MASTER?

Se a resposta for:

NO

parece que terminamos.

Bell não pode acessar o arquivo.

Caso encerrado.

Mas não.

Na verdade, acabamos de começar.

---

🚪 CAPÍTULO 2 — NÃO TER A CHAVE NÃO SIGNIFICA NÃO CONSEGUIR ENTRAR

Bell voltou até a porta.

Tentou novamente.

ACCESS DENIED

— Eu definitivamente não tenho acesso.

O COBOLzeiro perguntou:

— Você consegue chamar alguém que tenha?

Bell parou.

Essa pequena pergunta muda completamente nosso modelo de segurança.

Considere:

BELL
  |
  X
  |
PAYROLL

Bell não consegue acessar PAYROLL.

Mas imagine agora:

BELL
  |
  v
PROGRAMA
  |
  v
PAYROLL

O programa possui autoridade para consultar os dados.

Bell possui autoridade para executar o programa.

Então temos uma situação perfeitamente normal:

BELL
   ↓
PROGRAMA
   ↓
PAYROLL

Isso não significa automaticamente que existe uma vulnerabilidade.

Na verdade, é exatamente assim que aplicações empresariais devem funcionar.

Um caixa eletrônico não deveria entregar ao cliente acesso direto ao banco de dados.

Você solicita:

CONSULTAR SALDO

A aplicação verifica quem você é, executa uma operação autorizada e devolve somente aquilo que deveria.

A aplicação funciona como intermediária.

E é aqui que aparece nossa primeira grande lição:

Acesso direto e capacidade de provocar uma operação são coisas diferentes.

---

🕸️ CAPÍTULO 3 — BEM-VINDO À DUNGEON DOS GRAFOS

Bell abriu o mapa.

Havia dezenas de salas.

USER
GROUP
DATASET
JCL
SURROGATE
STARTED TASK
CICS
PROGRAM
DB2
MQ

O veterano explicou:

— Pare de pensar nisso como uma lista.

— Como devo pensar?

— Como um grafo.

Um grafo é uma estrutura matemática formada basicamente por:

NÓS

e:

ARESTAS

Os nós representam coisas.

Por exemplo:

USER:BELL
GROUP:APPDEV
CICS:PAYR
PROGRAM:PAY001
DB2:PAYROLL

As arestas representam relações entre essas coisas:

BELL ──member_of──> APPDEV

BELL ──execute──> PAYR

PAYR ──invokes──> PAY001

PAY001 ──reads──> PAYROLL

Quando conectamos tudo:

BELL
  ↓
APPDEV
  ↓
PAYR
  ↓
PAY001
  ↓
PAYROLL

acabamos de encontrar um caminho.

Em segurança, podemos chamar esse tipo de relacionamento de privilege path.

---

🧙 CAPÍTULO 4 — O GRUPO QUE PARECIA INOCENTE

Bell encontrou a primeira bifurcação da Dungeon.

Na parede estava escrito:

GROUP APPDEV

Usuários RACF podem pertencer a grupos.

Isso facilita tremendamente a administração.

Imagine 300 programadores.

Em vez de concedermos individualmente:

PERMIT ...

para cada pessoa, podemos criar:

APPDEV

e conceder determinados acessos ao grupo.

Então:

BELL
 ↓
APPDEV
 ↓
RESOURCE

Mas grupos também podem participar de contextos de autorização em outros componentes.

No Db2 for z/OS, por exemplo, dependendo da configuração, grupos RACF podem aparecer como secondary authorization IDs.

Agora temos:

BELL
 ↓
RACF GROUP
 ↓
SECONDARY AUTHID
 ↓
DB2 PRIVILEGE

Talvez Bell nunca tenha recebido diretamente:

GRANT SELECT

Mas isso não significa necessariamente que seu contexto de execução não possa possuir determinada capacidade.

Esse detalhe ensina algo importante:

Permissões podem ser herdadas ou adquiridas através de relacionamentos.

Bell encontrou sua primeira passagem secreta.

---

📜 CAPÍTULO 5 — JCL NÃO É APENAS AQUELA COISA ESTRANHA COM DUAS BARRAS

Para o iniciante COBOL, JCL inicialmente parece uma coleção de encantamentos ancestrais:

//BELLJOB JOB ...
//STEP01  EXEC PGM=PAY001
//INFILE  DD DSN=PROD.INPUT,DISP=SHR
//OUTFILE DD DSN=PROD.OUTPUT,DISP=OLD

Mas JCL não é COBOL.

COBOL descreve a lógica do programa.

JCL descreve, entre outras coisas, como determinado trabalho será executado no ambiente batch.

Um programa COBOL pode dizer:

READ CLIENTES

Mas alguma coisa precisa dizer qual dataset corresponde a CLIENTES.

No ambiente batch, JCL frequentemente participa dessa associação.

Agora pense em segurança.

Se alguém pode modificar JCL usado por uma execução poderosa, talvez essa pessoa consiga alterar:

programas
datasets
parâmetros
procedures
fluxo de execução

Por isso bibliotecas de JCL e procedures precisam ser cuidadosamente protegidas.

Surge outra regra importante:

Quem controla aquilo que será executado pode adquirir influência sobre o contexto que executará aquilo.

No grafo:

USER
 ↓
MODIFY JCL
 ↓
EXECUTION
 ↓
SERVICE ID
 ↓
RESOURCE

Bell olhou para o mapa.

A Dungeon acabara de ganhar outro andar.

---

🎭 CAPÍTULO 6 — SURROGATE: “EU NÃO SOU ELE, MAS POSSO PEDIR QUE ELE EXECUTE”

Agora Bell encontrou uma habilidade peculiar.

Chamava-se:

SURROGAT

Em determinados cenários controlados pelo RACF, um usuário autorizado pode submeter trabalho para execução sob outro userid sem precisar conhecer a senha desse userid.

Imagine:

BELL

não possui acesso ao payroll.

Mas existe um userid técnico:

PAYBATCH

que precisa processar folha de pagamento.

Naturalmente:

PAYBATCH
 ↓
PAYROLL

Se houver uma relação surrogate devidamente autorizada:

BELL
 ↓
SURROGATE
 ↓
PAYBATCH

temos:

BELL
 ↓
SURROGATE
 ↓
PAYBATCH
 ↓
PAYROLL

Observe a diferença.

Pergunta:

BELL possui READ diretamente em PAYROLL?

Resposta:

NO

Pergunta:

Existe um caminho autorizado entre BELL e alguma execução capaz de alcançar PAYROLL?

Possível resposta:

YES

São perguntas completamente diferentes.

---

🚂 CAPÍTULO 7 — STARTED TASK: QUANDO OUTRA IDENTIDADE ASSUME O TRABALHO

Bell continuou descendo.

Encontrou:

PAYSTC

Uma started task é um workload iniciado no z/OS, frequentemente utilizado para serviços de longa duração e componentes do sistema ou middleware.

CICS pode executar como started task.

MQ pode executar como started task.

Diversos produtos e serviços utilizam esse mecanismo.

O RACF permite associar started procedures a identidades específicas.

Conceitualmente:

PAYSTC
 ↓
STARTED
 ↓
PAYUSER

Portanto, não basta perguntar:

Quem iniciou a operação?

Precisamos perguntar:

Sob qual identidade a operação efetivamente executará?

Essa distinção é fundamental.

Além disso, existem conceitos poderosos associados a started procedures, incluindo atributos como:

TRUSTED

e:

PRIVILEGED

São configurações que exigem enorme cuidado porque ampliam significativamente as capacidades daquele contexto de execução.

Bell encontrou uma sala onde estava escrito:

COM GRANDES PRIVILÉGIOS
VÊM GRANDES AUDITORIAS.

Ele jurava já ter ouvido algo parecido em outro universo.

Easter egg número 1 encontrado.

---

💳 CAPÍTULO 8 — CICS: BELL ENTRA NA CIDADE

Depois do mundo batch, Bell chegou ao CICS.

Para um iniciante:

CICS — Customer Information Control System é uma plataforma de processamento transacional extremamente importante no universo mainframe.

Imagine um sistema bancário.

Quando alguém consulta uma conta, talvez exista uma transação:

SALO

que executa:

SALDO01

Podemos representar:

USER
 ↓
TRANSACTION
 ↓
COBOL PROGRAM

O programa COBOL então acessa Db2, VSAM, MQ ou outros recursos.

Algo conceitualmente assim:

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

A questão de segurança agora fica interessantíssima.

Bell talvez não possua:

SELECT ON CONTA

Mas pode possuir:

EXECUTE TRANSACTION SALO

Então:

BELL
 ↓
CICS:SALO
 ↓
SALDO01
 ↓
DB2
 ↓
CONTA

Novamente, isso é normal.

Na verdade, desejável.

Bell não deveria receber acesso irrestrito à tabela inteira só porque precisa consultar uma conta.

---

🪪 CAPÍTULO 9 — QUEM CHEGA AO DB2?

Aqui encontramos outra transformação importante.

Uma aplicação CICS acessando Db2 possui regras específicas de conexão e autorização.

Dependendo da configuração, elementos como:

DB2CONN
DB2ENTRY
AUTHID
AUTHTYPE

participam da determinação do contexto utilizado.

Portanto, podemos chegar a algo conceitualmente semelhante a:

BELL
 ↓
CICS
 ↓
TRANSACTION
 ↓
COBOL PROGRAM
 ↓
DB2ENTRY
 ↓
APPDB2
 ↓
PACKAGE
 ↓
TABLE

Perceba quantos saltos apareceram.

A pergunta inicial era:

Bell pode ler a tabela?

Agora percebemos que a pergunta deveria ser:

Bell consegue iniciar alguma cadeia de execução
que termine em uma operação sobre a tabela?

E, principalmente:

QUAL operação?

Porque talvez Bell possa solicitar:

SELECT saldo da própria conta

mas não:

SELECT * FROM TODAS_AS_CONTAS

A diferença entre essas duas coisas não está necessariamente numa ACL.

Pode estar na lógica COBOL.

---

👮 CAPÍTULO 10 — O PROGRAMA COBOL TAMBÉM É UMA BARREIRA DE SEGURANÇA

Essa conclusão é importantíssima para quem está começando.

Você pode pensar:

Segurança é trabalho do RACF.

Não.

RACF é uma camada fundamental.

Mas segurança também pode depender da aplicação.

Imagine:

EXEC SQL
   SELECT NOME, SALDO
   FROM CONTA
   WHERE CLIENTE = :WS-CLIENTE
END-EXEC.

Quem controla WS-CLIENTE?

De onde veio esse valor?

Foi validado?

O usuário pode substituir o identificador?

Existe verificação de propriedade?

O programa garante que:

CLIENTE SOLICITADO = CLIENTE AUTENTICADO

?

Essas perguntas pertencem à segurança da aplicação.

O RACF pode estar perfeitamente configurado enquanto a lógica da aplicação permite operações indevidas.

---

🤵 CAPÍTULO 11 — O CONFUSED DEPUTY

Bell encontrou um NPC poderoso.

Ele possuía autorização para entrar na sala do tesouro.

Bell não.

Mas Bell podia entregar ordens ao NPC.

O veterano perguntou:

— O que acontece se o NPC não verificar corretamente o pedido?

Temos o clássico problema conhecido como confused deputy.

O intermediário possui privilégios legítimos.

O problema surge quando uma entidade menos privilegiada consegue induzi-lo a usar esses privilégios de forma não pretendida.

Imagine:

USER
 ↓
APPLICATION
 ↓
SERVICE ID
 ↓
DB2

O service ID precisa acessar:

CUSTOMERS
ACCOUNTS
TRANSACTIONS

Isso é legítimo.

Mas o usuário deveria enxergar somente:

CUSTOMER 8472

Se uma falha permitir solicitar:

CUSTOMER *

o usuário não ganhou:

DBADM
SYSADM
SELECT *

Ele conseguiu controlar uma aplicação que já possuía autoridade.

Essa diferença é crucial.

---

📬 CAPÍTULO 12 — E ENTÃO APARECE MQ

Bell ouviu um barulho.

Não era um Minotauro.

Era uma mensagem chegando.

PAY.REQUEST

IBM MQ introduz comunicação assíncrona e mensageria no cenário.

Imagine:

CICS
 ↓
PUT
 ↓
PAY.REQUEST

Uma aplicação consumidora recebe a mensagem:

PAY.REQUEST
 ↓
PAYCONSUMER

Ela executa sob uma started task:

PAYCONSUMER
 ↓
PAYSTC
 ↓
PAYUSER

e acessa Db2:

PAYUSER
 ↓
DB2
 ↓
PAYROLL

Junte tudo:

BELL
 ↓
CICS
 ↓
COBOL PROGRAM
 ↓
MQ PUT
 ↓
QUEUE
 ↓
CONSUMER
 ↓
STARTED TASK
 ↓
SERVICE ID
 ↓
DB2
 ↓
PAYROLL

Agora volte à primeira pergunta:

Bell possui READ em PAYROLL?

Não.

E isso praticamente deixou de ser a pergunta mais interessante.

---

💥 CAPÍTULO 13 — BLAST RADIUS

Bell agora recebeu outra missão:

Descubra tudo aquilo que BELL consegue alcançar.

Isso é muito mais interessante.

Podemos pensar no blast radius de uma identidade.

Imagine:

BELL
├── GROUP APPDEV
│   ├── DEV datasets
│   └── DB2 secondary authorization
│
├── CICS
│   ├── SALO
│   ├── EXTR
│   └── TRNF
│
├── MQ
│   └── APP.REQUEST
│
└── SURROGATE
    └── APPBATCH

Cada um desses nós abre outros caminhos.

Então o blast radius não é somente aquilo que aparece diretamente no userid.

É o conjunto de capacidades alcançáveis através das relações existentes.

---

🧠 CAPÍTULO 14 — LEAST PRIVILEGE GANHA OUTRO SIGNIFICADO

Você provavelmente já ouviu:

Principle of Least Privilege.

Ou:

conceda somente os privilégios necessários.

Perfeito.

Mas nosso grafo permite uma interpretação mais profunda.

Least privilege não deveria significar somente:

minimizar permissões diretas

Também precisamos pensar em:

minimizar caminhos desnecessários

Você pode remover:

BELL → PAYROLL

e continuar possuindo:

BELL
 ↓
APPDEV
 ↓
CICS
 ↓
PROGRAM
 ↓
SERVICE
 ↓
PAYROLL

A ACL ficou menor.

A capacidade talvez continue existindo.

---

🕷️ CAPÍTULO 15 — SECURITY CHOKE POINTS

Bell percebeu algo estranho no mapa.

Centenas de caminhos diferentes passavam pela mesma sala:

PROD.CICS.LOADLIB

Isso é interessante.

Em teoria dos grafos existe uma medida chamada betweenness centrality.

Simplificando brutalmente:

Quantos caminhos importantes passam por determinado nó?

Imagine:

400 USERS
   ↓
CICS
   ↓
PROD.CICS.LOADLIB
   ↓
72 PROGRAMS
   ↓
DB2 / MQ / VSAM

Talvez essa load library seja muito mais importante para segurança do que sua aparência sugere.

O mesmo poderia acontecer com:

PROD.JCL.PROCLIB

ou:

APP_SUPPORT

ou:

REQUEST.QUEUE

Esses elementos tornam-se choke points.

Se forem comprometidos ou excessivamente permissivos, muitos caminhos podem ser afetados.

---

🧮 CAPÍTULO 16 — Dijkstra ENTRA NO CPD

Agora Bell precisava encontrar a rota mais curta.

Quem já estudou estruturas de dados talvez reconheça nomes como:

Breadth-First Search
Depth-First Search
Dijkstra
Shortest Path
Connected Components

Esses algoritmos podem ser aplicados conceitualmente ao problema.

Queremos descobrir:

SHORTEST PATH
FROM USER:BELL
TO DB2:PAYROLL

Talvez o resultado seja:

BELL
 ↓
APPDEV
 ↓
CICS:PAYR
 ↓
PROGRAM:PAY001
 ↓
AUTHID:PAYDB2
 ↓
PAYROLL

Cinco saltos.

Mas podemos melhorar.

Nem toda aresta possui o mesmo significado.

Podemos atribuir pesos hipotéticos:

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

Agora não procuramos apenas:

shortest path

Podemos procurar:

lowest-cost privilege path

ou caminhos que atravessem relações consideradas particularmente sensíveis.

---

🤖 CAPÍTULO 17 — IA NÃO PRECISA SER O ORÁCULO

E aqui aparece uma aplicação muito interessante de inteligência artificial.

Não precisamos entregar os dados para um LLM e perguntar:

“Quem é perigoso?”

Isso seria uma péssima abstração.

Podemos primeiro usar mecanismos determinísticos para construir:

ENTERPRISE PRIVILEGE GRAPH

alimentado por informações de:

RACF
JES
JCL
STARTED
SURROGAT
CICS
Db2
MQ
USS
SMF

Algoritmos tradicionais encontram os caminhos.

Depois uma IA pode ajudar a explicar o resultado.

Por exemplo:

USER BELL não possui acesso direto a PAYROLL.

Entretanto:

BELL pertence a APPDEV.
APPDEV permite executar CICS transaction PAYR.
PAYR chama PAY001.
PAY001 utiliza determinado contexto Db2.
Esse contexto executa PAYPKG.
PAYPKG acessa PAYROLL.

Agora temos:

WHAT

mais:

HOW

mais:

WHY

Essa combinação é muito mais útil para um analista.

---

⏰ CAPÍTULO 18 — O GRAFO TEM TEMPO

Bell finalmente achou que havia entendido a Dungeon.

Então o mapa mudou.

Às:

08:00

tínhamos:

BELL → APPDEV

Às:

10:12

um administrador adicionou uma relação.

Agora:

APPDEV → PROD_SUPPORT

Instantaneamente apareceram novos caminhos.

Esse é um detalhe fantástico.

O grafo de privilégios não é estático.

Podemos pensar:

GRAPH(t0)

e:

GRAPH(t1)

Então perguntar:

DIFF GRAPH(t0,t1)

Talvez uma única mudança tenha criado:

1 nova permissão direta

mas, transitivamente:

37 novos caminhos

ou:

317 novos caminhos

incluindo:

12 caminhos até recursos críticos.

Agora imagine isso integrado ao Change Management.

Antes de aprovar:

PERMIT ...

o sistema calcula:

DIRECT CHANGE:

1 permission

TRANSITIVE EFFECT:

317 new reachable paths

CRITICAL RESOURCES AFFECTED:

12

Nesse momento alguém no Security Operations Center olha para a tela e pergunta:

— Quem diabos pediu essa mudança?

Bell discretamente esconde o formulário.

---

🔬 CAPÍTULO 19 — PASSO A PASSO PARA PENSAR COMO ANALISTA

Você é um programador COBOL iniciante.

Como aplicar tudo isso sem virar especialista RACF amanhã?

Comece simples.

Pegue uma transação qualquer.

Por exemplo:

CICS transaction: SALO

Pergunte:

1. Quem pode executá-la?

Depois:

2. Qual programa ela chama?

SALO
 ↓
SALDO01

3. Esse programa acessa o quê?

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

4. Sob qual contexto de autorização?

5. Existem packages Db2 envolvidos?

6. Existem filas MQ?

7. Quem consome essas filas?

8. O consumidor executa sob qual userid?

9. Existe uma started task?

10. Quais recursos essa identidade alcança?

De repente você construiu manualmente:

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

Parabéns.

Você acabou de fazer sua primeira análise de privilege path.

---

🧰 CAPÍTULO 20 — DICAS PARA O COBOLZEIRO

Primeira dica:

não olhe somente para o programa.

Descubra como ele é executado.

Segunda:

aprenda JCL.

O COBOL pode ser o motor, mas JCL frequentemente explica como aquele motor entra na estrada no mundo batch.

Terceira:

aprenda o básico de RACF.

Mesmo que você nunca seja administrador RACF.

Entenda pelo menos:

USER
GROUP
PROFILE
ACCESS
PERMIT
SURROGAT
STARTED

Quarta:

quando encontrar CICS, pergunte pelo contexto de segurança.

Quinta:

quando encontrar MQ, siga a mensagem.

Não pare na fila.

Pergunte:

Quem consome?

Depois:

Sob qual identidade?

Depois:

O consumidor faz o quê?

Sexta:

quando encontrar Db2, não pense somente em tabela.

Lembre-se de:

AUTHID
secondary IDs
roles
packages
plans
privileges

Sétima:

aprenda a desenhar.

Uma folha de papel com:

USER
 ↓
CICS
 ↓
PGM
 ↓
MQ
 ↓
STC
 ↓
DB2

às vezes explica mais que cinquenta páginas de relatório.

---

🥚 CAPÍTULO 21 — O EASTER EGG DO NÍVEL 37

Bell finalmente chegou ao nível 37 da Dungeon.

Encontrou uma porta.

Na placa estava escrito:

PF3 = EXIT

Bell apertou PF3.

Nada aconteceu.

Apareceu:

IKJ56700A ENTER USERID -

Bell olhou para o veterano.

— Isso não faz sentido.

O COBOLzeiro terminou seu café.

— Bem-vindo ao mainframe.

Bell tentou PF12.

Funcionou.

Ninguém jamais descobriu por quê.

Os arqueólogos de sistemas ainda investigam o incidente.

---

🗺️ CAPÍTULO 22 — O GOOGLE MAPS DOS PRIVILÉGIOS

Agora podemos imaginar uma ferramenta fascinante.

Você informa:

SOURCE:

USER:BELL

e:

TARGET:

DB2:PAYROLL

A ferramenta responde:

DIRECT ACCESS:

NO

Mas não termina aí.

Ela mostra:

3 INDIRECT PATHS FOUND

PATH 01

BELL
 ↓
APPDEV
 ↓
CICS PAYR
 ↓
PAY001
 ↓
PAYDB2
 ↓
PAYROLL

PATH 02

BELL
 ↓
MQ PUT
 ↓
PAY.REQUEST
 ↓
PAYSTC
 ↓
PAYUSER
 ↓
PAYROLL

PATH 03

BELL
 ↓
SURROGATE
 ↓
PAYBATCH
 ↓
PAYROLL

E ainda poderia dizer:

REMOVE EDGE:

BELL → PAY.REQUEST

RESULT:

PATH 02 eliminated.

Ou:

REMOVE EDGE:

APPDEV → PAYR

RESULT:

PATH 01 eliminated.

Isso transforma segurança em algo visual e explicável.

Quase um:

Google Maps do RACF

Só que, em vez de:

São Paulo → Campinas

perguntamos:

USER01 → PAYROLL

E o sistema responde:

Você chegará ao destino em 5 privilégios.

Existe uma rota alternativa via MQ.

Evite SURROGAT:
tráfego intenso.

Bell riu.

O auditor RACF não.

---

🏁 EPÍLOGO — A PORTA CONTINUAVA TRANCADA

Bell retornou ao começo da Dungeon.

A velha porta continuava lá:

PROD.PAYROLL.MASTER

Passou seu userid novamente.

ACCESS DENIED

Bell sorriu.

Agora entendia.

A mensagem estava correta.

Ele realmente não possuía acesso direto.

Mas essa informação, sozinha, não descrevia todo o sistema.

Atrás dela existiam:

GROUPS
JCL
SURROGATES
STARTED TASKS
CICS
COBOL
DB2
MQ
SERVICE IDs
PACKAGES
QUEUES
APPLICATION LOGIC

Todos conectados.

A segurança tradicional havia perguntado:

WHO HAS ACCESS?

Bell aprendera a fazer outra pergunta:

WHO CAN REACH IT?

E depois uma ainda melhor:

HOW?

Essa talvez seja uma das mudanças de perspectiva mais importantes para quem começa a estudar segurança em ambientes corporativos complexos.

Um privilégio não precisa ser uma linha dizendo:

USER01 READ PAYROLL

Ele pode estar espalhado por cinco sistemas diferentes.

Pode começar em um grupo RACF.

Passar por JCL.

Trocar de identidade numa started task.

Entrar em CICS.

Executar um programa COBOL.

Publicar uma mensagem MQ.

Ser consumido por outro serviço.

Terminar em um package Db2.

E somente então alcançar o dado.

Nenhum componente isolado necessariamente está errado.

O risco pode existir na composição.

Essa é a beleza — e também a dificuldade — dos sistemas grandes.

Bell guardou a adaga.

O COBOLzeiro fechou o SDSF.

E na última tela verde da Dungeon apareceu:

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

USER BELL01
DIRECT ACCESS TO PAYROLL: NONE

INDIRECT PRIVILEGE PATHS: 3

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

Bell ficou alguns segundos olhando.

Então perguntou:

— Então segurança não é descobrir quem tem a chave?

O velho levantou a xícara.

— Não, Bell.

Na tela apareceu o último ensinamento:

       PERMISSION != REACHABILITY

— Segurança também é descobrir quem conhece o caminho.

E, em algum lugar profundamente enterrado dentro do z/OS, um job terminou:

IEF404I BELLJOB - ENDED - TIME=03.17.42

MAXCC=0000

Porque algumas tradições são sagradas.

☕