 |
| 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.MASTERBell 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:
BELL01e um dataset:
PROD.CLIENTES.MASTERRACF pode determinar que Bell possui:
READou:
UPDATEou:
ALTERou simplesmente:
NONEPara quem está começando, é tentador imaginar segurança assim:
USER
|
|
v
RESOURCEPerguntamos:
BELL01 pode acessar PROD.CLIENTES.MASTER?Se a resposta for:
NOparece 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
|
PAYROLLBell não consegue acessar PAYROLL.
Mas imagine agora:
BELL
|
v
PROGRAMA
|
v
PAYROLLO programa possui autoridade para consultar os dados.
Bell possui autoridade para executar o programa.
Então temos uma situação perfeitamente normal:
BELL
↓
PROGRAMA
↓
PAYROLLIsso 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 SALDOA 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
MQO 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ÓSe:
ARESTASOs nós representam coisas.
Por exemplo:
USER:BELL
GROUP:APPDEV
CICS:PAYR
PROGRAM:PAY001
DB2:PAYROLLAs arestas representam relações entre essas coisas:
BELL ──member_of──> APPDEVBELL ──execute──> PAYRPAYR ──invokes──> PAY001PAY001 ──reads──> PAYROLLQuando conectamos tudo:
BELL
↓
APPDEV
↓
PAYR
↓
PAY001
↓
PAYROLLacabamos 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 APPDEVUsuá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:
APPDEVe conceder determinados acessos ao grupo.
Então:
BELL
↓
APPDEV
↓
RESOURCEMas 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 PRIVILEGETalvez Bell nunca tenha recebido diretamente:
GRANT SELECTMas 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=OLDMas 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 CLIENTESMas 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çãoPor 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
↓
RESOURCEBell 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:
SURROGATEm 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:
BELLnão possui acesso ao payroll.
Mas existe um userid técnico:
PAYBATCHque precisa processar folha de pagamento.
Naturalmente:
PAYBATCH
↓
PAYROLLSe houver uma relação surrogate devidamente autorizada:
BELL
↓
SURROGATE
↓
PAYBATCHtemos:
BELL
↓
SURROGATE
↓
PAYBATCH
↓
PAYROLLObserve a diferença.
Pergunta:
BELL possui READ diretamente em PAYROLL?Resposta:
NOPergunta:
Existe um caminho autorizado entre BELL e alguma execução capaz de alcançar PAYROLL?Possível resposta:
YESSão perguntas completamente diferentes.
🚂 CAPÍTULO 7 — STARTED TASK: QUANDO OUTRA IDENTIDADE ASSUME O TRABALHO
Bell continuou descendo.
Encontrou:
PAYSTCUma 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
↓
PAYUSERPortanto, 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:
TRUSTEDe:
PRIVILEGEDSã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:
SALOque executa:
SALDO01Podemos representar:
USER
↓
TRANSACTION
↓
COBOL PROGRAMO 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 CONTAMas pode possuir:
EXECUTE TRANSACTION SALOEntão:
BELL
↓
CICS:SALO
↓
SALDO01
↓
DB2
↓
CONTANovamente, 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
AUTHTYPEparticipam da determinação do contexto utilizado.
Portanto, podemos chegar a algo conceitualmente semelhante a:
BELL
↓
CICS
↓
TRANSACTION
↓
COBOL PROGRAM
↓
DB2ENTRY
↓
APPDB2
↓
PACKAGE
↓
TABLEPerceba 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 contamas não:
SELECT * FROM TODAS_AS_CONTASA 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
↓
DB2O service ID precisa acessar:
CUSTOMERS
ACCOUNTS
TRANSACTIONSIsso é legítimo.
Mas o usuário deveria enxergar somente:
CUSTOMER 8472Se 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.REQUESTIBM MQ introduz comunicação assíncrona e mensageria no cenário.
Imagine:
CICS
↓
PUT
↓
PAY.REQUESTUma aplicação consumidora recebe a mensagem:
PAY.REQUEST
↓
PAYCONSUMEREla executa sob uma started task:
PAYCONSUMER
↓
PAYSTC
↓
PAYUSERe acessa Db2:
PAYUSER
↓
DB2
↓
PAYROLLJunte tudo:
BELL
↓
CICS
↓
COBOL PROGRAM
↓
MQ PUT
↓
QUEUE
↓
CONSUMER
↓
STARTED TASK
↓
SERVICE ID
↓
DB2
↓
PAYROLLAgora 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
└── APPBATCHCada 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 diretasTambém precisamos pensar em:
minimizar caminhos desnecessáriosVocê pode remover:
BELL → PAYROLLe continuar possuindo:
BELL
↓
APPDEV
↓
CICS
↓
PROGRAM
↓
SERVICE
↓
PAYROLLA 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.LOADLIBIsso é 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 / VSAMTalvez essa load library seja muito mais importante para segurança do que sua aparência sugere.
O mesmo poderia acontecer com:
PROD.JCL.PROCLIBou:
APP_SUPPORTou:
REQUEST.QUEUEEsses 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 ComponentsEsses algoritmos podem ser aplicados conceitualmente ao problema.
Queremos descobrir:
SHORTEST PATH
FROM USER:BELL
TO DB2:PAYROLLTalvez o resultado seja:
BELL
↓
APPDEV
↓
CICS:PAYR
↓
PROGRAM:PAY001
↓
AUTHID:PAYDB2
↓
PAYROLLCinco 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 5Agora não procuramos apenas:
shortest pathPodemos procurar:
lowest-cost privilege pathou 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 GRAPHalimentado por informações de:
RACF
JES
JCL
STARTED
SURROGAT
CICS
Db2
MQ
USS
SMFAlgoritmos 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:
WHATmais:
HOWmais:
WHYEssa 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:00tínhamos:
BELL → APPDEVÀs:
10:12um administrador adicionou uma relação.
Agora:
APPDEV → PROD_SUPPORTInstantaneamente 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 diretamas, transitivamente:
37 novos caminhosou:
317 novos caminhosincluindo:
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:
12Nesse 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: SALOPergunte:
1. Quem pode executá-la?
Depois:
2. Qual programa ela chama?
SALO
↓
SALDO013. Esse programa acessa o quê?
SALDO01
├── DB2
├── VSAM
└── MQ4. 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
↓
DB2Parabé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
STARTEDQuarta:
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
privilegesSé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 = EXITBell 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:BELLe:
TARGET:
DB2:PAYROLLA ferramenta responde:
DIRECT ACCESS:
NOMas não termina aí.
Ela mostra:
3 INDIRECT PATHS FOUNDPATH 01
BELL
↓
APPDEV
↓
CICS PAYR
↓
PAY001
↓
PAYDB2
↓
PAYROLLPATH 02
BELL
↓
MQ PUT
↓
PAY.REQUEST
↓
PAYSTC
↓
PAYUSER
↓
PAYROLLPATH 03
BELL
↓
SURROGATE
↓
PAYBATCH
↓
PAYROLLE 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 RACFSó que, em vez de:
São Paulo → Campinasperguntamos:
USER01 → PAYROLLE 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.MASTERPassou seu userid novamente.
ACCESS DENIEDBell 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 LOGICTodos 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 PAYROLLEle 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=0000Porque algumas tradições são sagradas.
☕
