Bellacosa Mainframe e o perigo dos privilégios
☕ UM CAFÉ NO BELLACOSA MAINFRAME
|
| Bellacosa Mainframe e o perigo dos privilégios |
👑 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: NONEO 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:
BELL01e um dataset:
PROD.CLIENTES.MASTERDependendo das regras configuradas, a identidade pode possuir níveis de acesso apropriados ao recurso.
Conceitualmente:
BELL01 ---- READ ----> PROD.CLIENTES.MASTEROu talvez:
BELL01 ----- X ------> PROD.CLIENTES.MASTERNada 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 ----> TESOUROSeguro?
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.MASTERmas 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 → DATAe passa a ser:
USER
↓
TRANSACTION
↓
PROGRAM
↓
SERVICE
↓
DATABASE
↓
DATANenhuma 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──> GROUPUSER ──execute──> TRANSACTIONTRANSACTION ──invokes──> PROGRAMPROGRAM ──uses──> DB2PROGRAM ──puts──> MQ QUEUEIsso é 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:PAYROLLAgora 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
PAYROLLe relacionar usuários a eles.
Por exemplo:
BELL01
↓
APPDEVSe 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
↓
RESOURCEMas 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 PRIVILEGEAgora 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 != TRANSITIVEPrimeiro 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=OLDMas existe uma separação importante.
O programa COBOL contém lógica.
Algo como:
READ ARQUIVO-CLIENTESMas 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
↓
RESOURCEO 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:
SURROGATEm 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:
BELL01não possui acesso a:
PAYROLLMas existe:
PAYBATCHque precisa acessar payroll para executar seu trabalho.
Temos:
PAYBATCH
↓
PAYROLLSe Bell possuir legitimamente a capacidade necessária para submeter trabalho como PAYBATCH, nosso grafo pode conter:
BELL01
↓
SURROGAT
↓
PAYBATCH
↓
PAYROLLPergunta 1:
BELL01 possui READ diretamente?Resposta:
NOPergunta 2:
Existe um caminho de execução autorizado
que termina em uma identidade com capacidade?Talvez:
YESSã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
↓
PAYUSERAqui 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 USERO 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:
SALOque chama:
SALDO01Então:
USER
↓
CICS:SALO
↓
COBOL:SALDO01O 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
↓
DATABASEe não:
USER
↓
EVERYTHING IN DATABASEA 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 CONTAmas aceite sem validação adequada:
CONSULTAR CONTA 8472e depois:
CONSULTAR CONTA 8473e:
CONSULTAR CONTA 8474A 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 CONTEXTSeu 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
↓
DB2O programa pode legitimamente possuir capacidade para consultar milhares de clientes.
Mas determinado usuário talvez devesse consultar apenas:
CLIENTE 8472Se a aplicação não limitar corretamente essa operação, temos um problema.
Observe a sutileza.
O usuário não ganhou:
SYSADMNã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.REQUESTA aplicação não processa imediatamente o trabalho.
Coloca uma mensagem numa queue.
Outro serviço consome:
PAY.REQUEST
↓
PAYCONSUMERO consumidor pode executar como uma started task:
PAYCONSUMER
↓
PAYSTC
↓
PAYUSERe acessar Db2:
PAYUSER
↓
DB2
↓
PAYROLLAgora conecte tudo:
BELL01
↓
CICS TRANSACTION
↓
COBOL PROGRAM
↓
MQ PUT
↓
PAY.REQUEST
↓
CONSUMER
↓
STARTED TASK
↓
SERVICE USER
↓
DB2
↓
PAYROLLSouma 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:
PERMISSIONe:
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 BELL01Queremos conceitualmente descobrir:
REACHABLE(BELL01)Talvez apareça:
BELL01
├── APPDEV
│ ├── DEV.DATA
│ └── DB2 privileges
│
├── CICS
│ ├── SALO
│ ├── EXTR
│ └── PAYR
│
├── MQ
│ └── APP.REQUEST
│
└── SURROGAT
└── APPBATCHCada 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 PERMISSIONSTambém queremos minimizar:
UNNECESSARY PRIVILEGE PATHSImagine remover:
BELL01 → PAYROLLExcelente.
Mas continuar com:
BELL01
↓
APPDEV
↓
PAYR
↓
PAY001
↓
PAYDB2
↓
PAYROLLTalvez 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.LOADLIBOutros convergiam para:
PROD.APP.PROCLIBE muitos dependiam do grupo:
PROD_SUPPORTEm 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 DetectionImagine uma consulta:
SOURCE = USER:BELL01
TARGET = DB2:PAYROLLQueremos:
FIND PATHResultado:
BELL01
↓
APPDEV
↓
CICS:PAYR
↓
PAY001
↓
PAYDB2
↓
PAYROLLPodemos 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 5Agora 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:PAYROLLE queria receber:
DIRECT ACCESS: NO
INDIRECT PATHS: 3ROTA 1
BELL01
↓
APPDEV
↓
CICS PAYR
↓
PAY001
↓
PAYDB2
↓
PAYROLLROTA 2
BELL01
↓
MQ
↓
PAY.REQUEST
↓
PAYSTC
↓
PAYUSER
↓
PAYROLLROTA 3
BELL01
↓
SURROGAT
↓
PAYBATCH
↓
PAYROLLE então:
REMOVE EDGE:
BELL01 → PAY.REQUEST
RESULT:
ROUTE 2 ELIMINATEDIsso seria praticamente um:
GOOGLE MAPS DOS PRIVILÉGIOS
Você pergunta:
BELL01 → PAYROLLe 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 GRAPHusando informações de:
RACF
JES
JCL
SURROGAT
STARTED
CICS
DB2
MQ
USS
SMF
APPLICATIONSAlgoritmos de grafos encontram relações e caminhos.
Depois uma IA pode ajudar a transformar:
NODE 481
EDGE 92
NODE 773
EDGE 144
NODE 112em 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: 12Agora 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:
SALOFaça o seguinte.
PASSO 1 — IDENTIDADE
Pergunte:
Quem pode iniciar SALO?PASSO 2 — TRANSAÇÃO
Descubra:
SALO
↓
qual programa?Talvez:
SALDO01PASSO 3 — PROGRAMA COBOL
Descubra os recursos usados:
SALDO01
├── DB2
├── VSAM
└── MQPASSO 4 — DB2
Pergunte:
Qual contexto de autorização?
Qual package?
Quais objetos?PASSO 5 — MQ
Se existir:
PUT PAY.REQUESTnão pare.
Pergunte:
Quem consome PAY.REQUEST?PASSO 6 — CONSUMIDOR
Descubra:
QUEUE
↓
CONSUMER
↓
STC
↓
USERIDPASSO 7 — CONTINUE
Pergunte quais recursos esse userid consegue utilizar.
Ao terminar, talvez você tenha:
USER
↓
CICS
↓
COBOL
↓
MQ
↓
STC
↓
COBOL
↓
DB2Você 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
STARTED3. Aprenda JCL.
Seu COBOL não vive sozinho.
4. Quando encontrar CICS, siga a transação.
TRANSACTION → PROGRAM → RESOURCE5. 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 EDITIONNenhum 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 IDsMilhares 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: NONEO 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: 3Agora 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.
