✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Service Accounts. Mostrar todas as mensagens

segunda-feira, 2 de março de 2020

👻 TOUKA MIMORI E O FUNCIONÁRIO FANTASMA — QUANDO O OFFBOARDING TERMINOU NO RH, MAS O USUÁRIO CONTINUOU RODANDO NO MAINFRAME

Bellacosa Mainframe e o risco do offboarding

☕ UM CAFÉ NO BELLACOSA MAINFRAME

👻 TOUKA MIMORI E O FUNCIONÁRIO FANTASMA — QUANDO O OFFBOARDING TERMINOU NO RH, MAS O USUÁRIO CONTINUOU RODANDO NO MAINFRAME

RACF, IAM, contas órfãs, service accounts, certificados, tokens, SSH keys, jobs agendados, started tasks, datasets, ownership, privilege creep, SIEM, offboarding — e o dia em que Touka Mimori descobriu que excluir uma pessoa do cadastro não significa necessariamente matá-la no mundo digital.

🎬 PRÓLOGO — O FUNCIONÁRIO QUE JÁ NÃO EXISTIA

Às 17:03 de uma sexta-feira, o RH atualizou o cadastro:

EMPLOYEE: BELLACOSA
STATUS: TERMINATED

Às 17:08, alguém do suporte recebeu o chamado.

Disable account BELL001

No RACF:

ALTUSER BELL001 REVOKE

No Active Directory, conta desabilitada.

VPN bloqueada.

Notebook devolvido.

Crachá recolhido.

Às 17:30, o ticket recebeu a palavra mágica:

RESOLVED

Todo mundo foi embora.

Caso encerrado.

Ou deveria estar.

Às 02:00 da madrugada:

PAYROLL01   EXECUTED   RC=0000

Às 02:15:

EXPORT01    SUCCESS

Às 02:43:

API PAYMENT-GATEWAY
HTTP 200

Às 03:17:

USER=BELL001
RESOURCE=FINANCE.PAYROLL
ACCESS=READ

Bellacosa já não trabalhava na empresa.

Seu crachá estava numa gaveta do RH.

Seu notebook estava desligado.

Seu usuário estava revogado.

Mas alguma coisa ainda estava andando pelos corredores digitais.

Touka Mimori olhou para o console.

— Então vocês jogaram o funcionário na dungeon e imaginaram que ele estivesse morto?

O programador COBOL iniciante respondeu:

— Mas nós desabilitamos a conta!

Touka sorriu.

— Esse foi exatamente o erro que cometeram comigo.

E assim começamos nossa investigação.

🧠 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UMA IDENTIDADE?

Antes de falar de RACF, certificados ou service accounts, precisamos entender algo fundamental.

Uma pessoa não é uma conta.

Parece óbvio, mas boa parte dos processos corporativos de segurança ainda se comporta como se fossem a mesma coisa.

Imagine:

PESSOA
  |
  +-- Employee ID
  +-- RACF userid
  +-- Active Directory
  +-- e-mail
  +-- VPN
  +-- Git
  +-- Db2
  +-- Unix
  +-- cloud
  +-- aplicações

Temos uma pessoa física:

Vagner Bellacosa

Mas dentro da infraestrutura ela pode ser representada por dezenas de identidades digitais:

BELL001
vagner.bellacosa
vagner@empresa
AD\VBELLACOSA
VBELL
47291

Isso já deveria acender uma lâmpada.

Quando RH informa:

VAGNER = DESLIGADO

quem garante que todas essas representações também foram tratadas?

Esse é o primeiro princípio desta história:

PESSOA != CONTA

Mas Touka ainda não estava satisfeito.

— Continue.

Porque existe outra diferença.

IDENTIDADE != CREDENCIAL

Uma identidade responde aproximadamente:

Quem é você?

Uma credencial permite provar alguma coisa sobre essa identidade.

Pode ser:

senha
certificado
token
SSH key
API key
smartcard
MFA
OAuth refresh token

Portanto:

PESSOA
   ↓
IDENTIDADE
   ↓
CREDENCIAL
   ↓
AUTENTICAÇÃO
   ↓
AUTORIZAÇÃO
   ↓
RECURSO

Começamos a enxergar o verdadeiro tamanho do problema.

👻 CAPÍTULO 2 — O FUNCIONÁRIO FANTASMA

Vamos imaginar um programador chamado BELL001.

Durante dez anos ele trabalhou no ambiente.

Criou programas COBOL.

Criou JCL.

Cadastrou jobs no scheduler.

Recebeu acesso ao Db2.

Criou uma SSH key.

Configurou uma integração.

Gerou certificados.

Criou pipelines.

Recebeu permissões no MQ.

Criou datasets.

Depois de dez anos temos algo assim:

                    BELL001
                       |
       +---------------+---------------+
       |               |               |
      RACF            Git            Cloud
       |               |               |
    Dataset           PAT            Token
       |                               |
      JCL                             API
       |
   Scheduler
       |
 Service Account
       |
 Certificate
       |
      MQ
       |
     CICS
       |
     Db2

Agora remova BELL001.

O que desaparece?

Talvez apenas:

BELL001

O restante do grafo pode continuar perfeitamente vivo.

Esse é o funcionário fantasma.

Não estamos necessariamente falando de atividade maliciosa.

Na maioria das vezes é algo mais mundano e, justamente por isso, interessante:

dependências esquecidas.

🦖 CAPÍTULO 3 — TOUKA ENTRA NO RACF

Para quem está começando no mainframe, precisamos apresentar nosso velho conhecido.

RACF significa:

Resource Access Control Facility.

É uma das principais tecnologias de segurança do z/OS.

Simplificando bastante, RACF ajuda a responder perguntas como:

Quem é você?

Você conseguiu provar quem é?

Você pode acessar este recurso?

Imagine:

USER = BELL001

RESOURCE =
FINANCE.PAYROLL.MASTER

BELL001 tenta abrir o dataset.

O ambiente precisa determinar se existe autoridade suficiente para aquela operação.

Até aqui tudo bem.

Nosso funcionário vai embora.

O administrador executa:

ALTUSER BELL001 REVOKE

Excelente medida.

Mas aqui encontramos uma das primeiras armadilhas conceituais.

REVOKE não significa “apague qualquer vestígio desse ser humano da infraestrutura”.

Ele afeta o uso daquela identidade conforme as regras do RACF.

Isso não transforma automaticamente cada sistema conectado ao funcionário em cinzas.

Touka escreveria na parede:

REVOKE != EXORCISM

⚠️ CAPÍTULO 4 — AUTENTICAÇÃO FUTURA E EXECUÇÃO PRESENTE NÃO SÃO A MESMA COISA

Imagine um restaurante.

Às 20:00 você proíbe alguém de entrar.

Isso impede novas entradas.

Mas existe uma pergunta diferente:

A pessoa já estava dentro?

Em computação encontramos situações semelhantes.

Uma credencial pode ter sido utilizada anteriormente.

Uma sessão pode existir.

Um processo pode estar rodando.

Um job pode estar executando.

Um token pode ter sido emitido.

Um serviço pode estar autenticado.

Por isso precisamos separar:

NEW AUTHENTICATION

de:

EXISTING EXECUTION

e também de:

PREVIOUSLY ISSUED CREDENTIAL

Essa distinção é importantíssima durante incidentes de segurança.

Se suspeitamos de comprometimento, simplesmente impedir um novo login pode não ser suficiente.

🤖 CAPÍTULO 5 — IDENTIDADE HUMANA E IDENTIDADE TÉCNICA

Touka encontrou outra porta na dungeon.

Nela estava escrito:

PAYROLL_BATCH

— Quem é esse funcionário?

— Não é funcionário.

— Então o que é?

Era uma service account.

Sistemas precisam executar coisas sem existir uma pessoa sentada diante de um terminal.

Um processamento batch não deveria precisar esperar Bellacosa acordar às duas da manhã e digitar uma senha.

Por isso existem identidades técnicas.

Exemplo:

PAYROLL_BATCH
DB2LOAD
MQBRIDGE
CICSAPI
BACKUP01

A ideia é perfeitamente legítima.

O problema começa quando uma identidade técnica nasce de maneira informal.

Por exemplo:

ACCOUNT: PAYROLL_BATCH
CREATED BY: BELL001
OWNER: BELL001
PASSWORD KNOWN BY: BELL001
DOCUMENTATION: ???

Bellacosa sai.

A conta continua.

Agora ninguém sabe:

quem responde por ela?
quem troca a senha?
quem pode desligá-la?
quais aplicações dependem dela?
por que ela possui aquelas permissões?

Criamos uma conta órfã.

🧟 CAPÍTULO 6 — A CONTA QUE NINGUÉM TEM CORAGEM DE MATAR

Esse é um clássico da arqueologia de TI.

Auditor:

— O que é APPUSER7?

Administrador:

— Não sei.

— Quem é o owner?

— João.

— Quem é João?

— Saiu em 2021.

— Podemos desligar?

Silêncio.

Finalmente alguém diz:

Melhor não mexer.

Pronto.

Nasceu uma entidade imortal.

Observe o ciclo:

ninguém conhece
      ↓
ninguém mexe
      ↓
continua funcionando
      ↓
fica mais antiga
      ↓
documentação desaparece
      ↓
menos gente conhece
      ↓
ninguém mexe

Programador COBOL, você reconheceu isso?

É praticamente:

PERFORM UNTIL DOCUMENTATION-EXISTS
    CONTINUE
END-PERFORM.

Só existe um pequeno problema.

Ninguém inicializou:

DOCUMENTATION-EXISTS

E temos um loop eterno.

⏰ CAPÍTULO 7 — O JOB AGENDADO É UMA MÁQUINA DO TEMPO

Agora entramos em terreno delicioso para quem trabalha com mainframe.

Imagine que Bellacosa escreveu em 2018:

//PAYROLL JOB ...
//STEP01  EXEC PGM=PAYCALC
//INPUT   DD DSN=CORP.PAYROLL.INPUT,DISP=SHR
//OUTPUT  DD DSN=CORP.PAYROLL.OUTPUT,...

O JCL foi colocado em produção.

Depois cadastrado no scheduler.

Pode ser Control-M, IBM Workload Scheduler ou outra solução.

Configuraram:

RUN DAILY
TIME 02:00

Bellacosa não precisa mais tocar no processo.

Todo dia:

01:59 ...
02:00 PAYROLL SUBMITTED
02:04 STEP01 RC=0000
02:07 PAYROLL COMPLETED

Cinco anos depois Bellacosa sai da empresa.

O job continua.

Isso não é necessariamente errado.

Na realidade, é exatamente o que queremos de automação corporativa.

O problema é outro.

Precisamos saber:

qual identidade executa?
quem é owner?
quem mantém?
quem pode alterar?
quem recebe alerta?
quais datasets acessa?
quais secrets utiliza?
qual aplicação depende dele?

O código deve sobreviver ao programador.

A dependência administrativa pessoal não deveria.

Essa diferença é gigantesca.

🦾 CAPÍTULO 8 — STARTED TASKS E A IDENTIDADE DA APLICAÇÃO

No z/OS existem ainda as started tasks.

Pense em processos ou serviços que podem ser iniciados e executar sob identidades próprias.

Conceitualmente:

STC PAYROLL
     |
     +--- PAYSTC

Isso é muito melhor do que:

STC PAYROLL
     |
     +--- BELL001

Porque:

BELL001 = pessoa

enquanto:

PAYSTC = workload

Pessoas entram.

Pessoas saem.

Aplicações permanecem.

Essa separação parece apenas organização, mas é também segurança.

Ela permite criar um ciclo de vida diferente:

HUMAN IDENTITY LIFECYCLE

WORKLOAD IDENTITY LIFECYCLE

São objetos relacionados, mas não iguais.

🔑 CAPÍTULO 9 — MATAMOS O USUÁRIO, MAS ESQUECEMOS AS CHAVES

Touka encontrou uma caixa.

Dentro dela:

SSH PRIVATE KEY

Depois outra:

API KEY

Depois:

PERSONAL ACCESS TOKEN

Depois:

OAUTH REFRESH TOKEN

E finalmente:

CERTIFICATE

Nosso iniciante perguntou:

— Mas não desabilitamos o usuário?

Touka respondeu:

— Você continua confundindo identidade com credencial.

Uma pessoa pode gerar durante sua vida corporativa diversos autenticadores.

Exemplos:

password
SSH key
API key
certificate
PAT
OAuth token
application password
session
cloud credential

Portanto um processo sério de offboarding precisa descobrir não apenas:

ACCOUNT(BELL001)

mas também algo conceitualmente parecido com:

CREDENTIALS WHERE
OWNER = BELL001
OR
CREATOR = BELL001
OR
CUSTODIAN = BELL001

Isso nos leva a uma conclusão importante:

Inventário de identidade sem inventário de credenciais é uma fotografia incompleta.

📜 CAPÍTULO 10 — CERTIFICADOS: O FANTASMA COM DATA DE VALIDADE

Certificados digitais tornam essa história ainda mais interessante.

Eles podem participar da autenticação entre sistemas, TLS, assinatura e diversas outras operações.

No ecossistema RACF encontramos certificados e key rings.

Um key ring pode ser entendido, simplificando bastante, como uma estrutura utilizada para organizar certificados relacionados a determinada identidade ou utilização.

Agora imagine:

CERTIFICATE:
CN=PAYROLL-API

EXPIRES:
2028

CREATED/ADMINISTERED BY:
BELL001

Bellacosa sai em 2026.

O certificado não pensa:

Nossa! O RH desligou meu criador!

Ele continua sujeito ao seu próprio ciclo de vida.

Daí nasce outra necessidade:

employee lifecycle
        !=
certificate lifecycle

O offboarding deve transferir responsabilidades administrativas e verificar dependências, em vez de presumir que tudo deveria simplesmente desaparecer.

🗃️ CAPÍTULO 11 — QUEM É DONO DO DATASET?

Agora Touka encontrou:

FINANCE.PAYROLL.HISTORY

O dataset existe há quinze anos.

Pergunta:

— Quem responde por isso?

Resposta:

OWNER=BELL001

Houston, temos um problema.

Um princípio saudável é tentar separar:

CREATOR

de:

OWNER

Uma pessoa pode criar determinado recurso.

Mas recursos corporativos duradouros frequentemente deveriam possuir responsabilidade associada a algo igualmente duradouro:

grupo
role
team
application
business function

Em vez de:

OWNER=BELL001

um desenho melhor pode ser:

OWNER=GRPFIN

dependendo do modelo de segurança adotado.

Assim:

Bellacosa entra
Bellacosa trabalha
Bellacosa sai

mas:

GRPFIN continua

Esse princípio vale muito além do mainframe:

Git repositories
cloud resources
dashboards
databases
schemas
queues
topics
pipelines
applications
certificates
datasets

A empresa deveria possuir o recurso.

A pessoa deveria possuir uma responsabilidade temporária sobre ele.

🕸️ CAPÍTULO 12 — TOUKA DESCOBRE QUE IAM É UM GRAFO

Aqui nossa investigação muda completamente.

A forma tradicional de pensar seria:

Does BELL001 exist?

Mas vamos transformar a infraestrutura em grafo.

Temos nós:

User
Group
Dataset
Job
Certificate
Service Account
Application
Database
Queue
API
Repository
Token

E relações:

MEMBER_OF
OWNS
EXECUTES
READS
WRITES
AUTHENTICATES_AS
CREATED
MAINTAINS
USES
CAN_ASSUME

Agora:

BELL001
   |
 MEMBER_OF
   ↓
FINANCE
   |
 ACCESS
   ↓
PAYROLL

Ou:

BELL001
   |
 CREATED
   ↓
PIPELINE01
   |
 USES
   ↓
SERVICE01
   |
 AUTHENTICATES
   ↓
DATABASE

De repente a pergunta deixa de ser:

BELL001 ainda existe?

Passa a ser:

Existe algum caminho residual relacionado à identidade, autoridade ou dependência operacional de BELL001?

Isso é muito mais poderoso.

Estamos fazendo análise de privilege paths e dependências.

🧹 CAPÍTULO 13 — OFFBOARDING COMO GARBAGE COLLECTION

Aqui temos uma analogia maravilhosa.

Imagine memória de computador.

Um objeto não deveria simplesmente permanecer eternamente porque algum ponteiro antigo ainda aponta para ele.

Processos de garbage collection tentam identificar aquilo que continua alcançável e aquilo que deixou de ser necessário.

Agora transforme isso em IAM.

Funcionário:

EMPLOYEE=BELLACOSA
STATUS=TERMINATED

Mas encontramos:

JOB.OWNER        -> BELLACOSA
CERT.ADMIN       -> BELLACOSA
DATASET.OWNER    -> BELLACOSA
TOKEN.CREATOR    -> BELLACOSA
PIPELINE.OWNER   -> BELLACOSA
SERVICE.CUSTODIAN-> BELLACOSA

O RH removeu o objeto humano.

Mas sobraram referências.

Offboarding maduro deveria funcionar como uma espécie de:

GARBAGE COLLECTION DE IDENTIDADE

Não é apenas eliminar.

É encontrar referências.

Transferir responsabilidades.

Revogar o que precisa ser revogado.

Rotacionar segredos.

Preservar aquilo que pertence à organização.

Eliminar aquilo que perdeu finalidade.

🔎 CAPÍTULO 14 — PASSO A PASSO DE UMA CAÇA AO FUNCIONÁRIO FANTASMA

Vamos montar um exercício conceitual.

Temos:

Nome: JOHN SMITH
Employee ID: 47291
RACF: JSMITH
AD: john.smith
Git: jsmith
Unix: johns
Email: john.smith@empresa

John saiu há seis meses.

PASSO 1 — INVENTARIAR IDENTIDADES

Procure todas as representações conhecidas.

JSMITH
john.smith
jsmith
johns
47291

PASSO 2 — INVENTARIAR CREDENCIAIS

Procure:

certificates
SSH keys
PATs
API keys
OAuth clients
tokens
application passwords

PASSO 3 — PROCURAR OWNERSHIP

Pesquise:

OWNER=JSMITH
CREATED_BY=JSMITH
MAINTAINER=JSMITH
ADMIN=JSMITH

PASSO 4 — PROCURAR EXECUÇÃO

Investigue:

JCL
scheduler
cron
started tasks
pipelines
automation
RPA
batch

PASSO 5 — PROCURAR AUTORIZAÇÃO

Analise:

RACF ACLs
groups
Db2 GRANTs
CICS permissions
MQ permissions
Unix groups
cloud IAM
Git permissions

PASSO 6 — OBSERVAR LOGS

Agora procure atividade posterior à data de desligamento.

Conceitualmente:

EVENT.TIME > TERMINATION_DATE
AND
EVENT.IDENTITY = FORMER_EMPLOYEE

Encontrou atividade?

Não grite imediatamente:

HACKER!

Investigue.

Pode ser:

scheduled workload
cached credential
forgotten service
automation
stale token
misattributed ownership
compromise

O importante é descobrir por que um identificador relacionado a alguém desligado continua produzindo eventos.

🚨 CAPÍTULO 15 — HR + IAM + SIEM: QUANDO AS PEÇAS SE ENCONTRAM

Agora fazemos uma conexão menos óbvia.

O RH sabe:

TERMINATION_DATE

O IAM sabe:

IDENTITIES
ENTITLEMENTS

A CMDB sabe, idealmente:

APPLICATIONS
OWNERS
DEPENDENCIES

O scheduler sabe:

JOBS
EXECUTION IDENTITIES

O SIEM observa:

EVENTS

Separados, cada sistema conhece apenas parte da história.

Juntos podemos formular uma regra poderosíssima:

IF
   IDENTITY_ACTIVITY > TERMINATION_DATE
THEN
   INVESTIGATE

Não necessariamente bloquear.

Investigar.

Isso pode funcionar como um canário comportamental.

Uma identidade supostamente morta fez barulho.

Por quê?

🧛 CAPÍTULO 16 — O FUNCIONÁRIO NEM PRECISA SAIR PARA VIRAR FANTASMA

Agora Touka encontrou um funcionário perfeitamente ativo.

Ele começou em Financeiro:

FINANCE

Depois mudou para Marketing:

FINANCE
+
MARKETING

Depois foi para TI:

FINANCE
+
MARKETING
+
IT

Parabéns.

Criamos outro problema:

Privilege creep

O usuário vai acumulando privilégios conforme muda de função.

Isso transforma o ciclo de identidade em:

JOINER
MOVER
LEAVER

O MOVER é frequentemente subestimado.

Quando alguém muda de função, não devemos perguntar apenas:

O que ele precisa ganhar?

Também:

O que deixou de precisar?

Caso contrário:

ACCESS(TODAY)
=
ACCESS(JOB1)
+
ACCESS(JOB2)
+
ACCESS(JOB3)
+
...

Depois de quinze anos temos um funcionário comum com uma mochila cheia de permissões arqueológicas.

⚖️ CAPÍTULO 17 — LEAST PRIVILEGE NÃO É UMA CONFIGURAÇÃO

Aqui aparece outra conclusão.

Muita gente pensa em least privilege assim:

Configure permissions correctly.
DONE.

Não.

Least privilege é um processo temporal.

Hoje alguém precisa:

READ PAYROLL

Amanhã muda de projeto.

A necessidade desaparece.

Se a permissão continuar:

AUTHORIZED

ela pode ser tecnicamente válida no RACF e organizacionalmente inválida.

Portanto:

AUTHORIZED != REQUIRED

Essa distinção é maravilhosa.

Segurança madura não pergunta apenas:

Ele pode?

Pergunta:

Ele ainda precisa poder?

☢️ CAPÍTULO 18 — NÃO DELETE TUDO CEGAMENTE

Touka levantou a mão.

Aqui existe uma exceção importantíssima.

Imagine que encontramos:

SERVICE_ACCOUNT=PAYROLL01

Criada originalmente por um funcionário desligado.

A reação não deveria ser:

DELETE PAYROLL01

Porque às 02:00 podemos descobrir que ela executava a folha de pagamento da empresa inteira.

O objetivo da investigação não é destruir fantasmas com uma bazuca.

É separar:

LEGITIMATE ORGANIZATIONAL RESOURCE

de:

UNNECESSARY RESIDUAL ACCESS

Uma conta técnica necessária pode precisar:

novo owner
nova documentação
rotação de credenciais
revisão de privilégios
monitoramento
classificação

e não necessariamente exclusão.

Esse detalhe separa segurança profissional de:

rm -rf /fantasmas

🧪 CAPÍTULO 19 — O LABORATÓRIO BELLACOSA

Quer transformar isso em exercício?

Escolha — em ambiente autorizado e controlado — uma identidade fictícia desligada:

USER=GHOST01

Construa um mapa:

GHOST01
 |
 +-- GROUPA
 |
 +-- DATASET1
 |
 +-- JOB01
 |
 +-- CERT01
 |
 +-- TOKEN01
 |
 +-- SERVICE01

Agora simule o desligamento.

Pergunte:

O login foi bloqueado?
Sessões existentes foram tratadas?
Existem jobs associados?
Existem credenciais independentes?
Existem certificados?
Existem tokens?
Existem datasets cujo owner precisa mudar?
Existem grupos?
Existem service accounts relacionadas?
Existem processos executando?
Existe atividade posterior ao desligamento?
Existe documentação indicando novo responsável?

A última pergunta é fundamental.

Porque:

ACCESS REMOVED

não é necessariamente igual a:

OFFBOARDING COMPLETE

🕵️ CAPÍTULO 20 — O QUE O ATACANTE ENXERGA?

Agora olhe para tudo isso pelo ponto de vista defensivo.

Ambientes antigos acumulam:

legacy accounts
forgotten integrations
old certificates
stale tokens
shared accounts
undocumented jobs
unowned applications
excessive privileges

Cada elemento pode aumentar a superfície de ataque.

Uma conta esquecida é especialmente problemática porque talvez ninguém esteja observando seu comportamento cotidiano.

O usuário ativo recebe atenção.

O administrador privilegiado recebe atenção.

Mas:

APPUSR17
CREATED: 2013
OWNER: UNKNOWN

pode viver naquela zona cinzenta onde ninguém quer tocar.

Segurança precisa procurar justamente essas zonas.

Não porque toda conta antiga seja vulnerável.

Mas porque falta de conhecimento é, por si só, uma deficiência de governança.

🧠 CAPÍTULO 21 — AS QUATRO PERGUNTAS DE TOUKA

Depois de percorrer a dungeon inteira, Touka escreveu quatro perguntas no quadro.

1. QUEM CONSEGUE AUTENTICAR?

Who are you?
Can you prove it?

2. QUEM CONSEGUE AUTORIZAR?

What can this identity access?

3. O QUE CONTINUA EXECUTANDO?

Which workloads survive independently?

4. QUEM É RESPONSÁVEL PELO QUE SOBROU?

Who owns this resource now?

Essa quarta pergunta muda tudo.

Uma organização não é composta apenas por acessos.

É composta por responsabilidades.

👻 CAPÍTULO 22 — O VERDADEIRO SIGNIFICADO DE OFFBOARDING

Agora podemos abandonar aquela definição simplista:

OFFBOARDING =
DISABLE ACCOUNT

e construir algo melhor:

OFFBOARDING =
    REVOKE HUMAN ACCESS
  + HANDLE ACTIVE SESSIONS
  + DISCOVER CREDENTIALS
  + ROTATE SECRETS
  + REVIEW SERVICE ACCOUNTS
  + REVIEW JOBS
  + TRANSFER OWNERSHIP
  + REVIEW ENTITLEMENTS
  + DOCUMENT DEPENDENCIES
  + MONITOR RESIDUAL ACTIVITY
  + VERIFY

Observe a última palavra:

VERIFY

Essa é talvez a etapa mais importante.

Não basta executar o procedimento.

Precisamos verificar o resultado.

🦖 CAPÍTULO 23 — O COBOL DO EXORCISMO

Se transformássemos todo o artigo em COBOL, talvez tivéssemos:

       IF EMPLOYEE-STATUS = 'TERMINATED'

           PERFORM REVOKE-HUMAN-ACCESS

           PERFORM TERMINATE-SESSIONS

           PERFORM FIND-CREDENTIALS

           PERFORM ROTATE-SECRETS

           PERFORM REVIEW-SERVICE-ACCOUNTS

           PERFORM REVIEW-SCHEDULED-JOBS

           PERFORM TRANSFER-OWNERSHIP

           PERFORM REVIEW-PERMISSIONS

           PERFORM FIND-DEPENDENCIES

           PERFORM MONITOR-RESIDUAL-ACTIVITY

           PERFORM VERIFY-OFFBOARDING

       END-IF.

Mas muitas organizações ainda possuem algo parecido com:

       IF EMPLOYEE-STATUS = 'TERMINATED'
           PERFORM DISABLE-LOGIN
       END-IF.

Compila.

Executa.

Retorna:

RC=0000

Mas aqui está outro ensinamento importantíssimo para qualquer programador mainframe:

`RC=0000` NÃO SIGNIFICA QUE O PROCESSO DE NEGÓCIO ESTÁ CORRETO.

Significa que aquilo que você mandou executar terminou conforme esperado.

Se o requisito estava incompleto, o computador pode executar perfeitamente a coisa errada.

🥚 EASTER EGG — A DUNGEON DE FAILURE FRAME

Talvez agora você tenha percebido por que Touka Mimori foi escolhido para acompanhar esta história.

Em Failure Frame, Touka é tratado como alguém descartável.

O sistema o classifica.

Decide que não serve.

Remove-o do caminho esperado.

Problema resolvido.

Só existe um pequeno detalhe.

Touka continua existindo.

E aquilo que foi descartado pelo sistema começa a produzir consequências que o próprio sistema não havia considerado.

Nossa identidade corporativa fantasma funciona de maneira curiosamente semelhante:

RH:
BELL001 saiu.

IAM:
BELL001 revoked.

AUDITORIA:
check.

INFRAESTRUTURA:
...

02:00 JOB PAYROLL01
02:01 EXECUTING

A organização declarou:

OBJECT REMOVED

O ambiente respondeu:

ARE YOU SURE?

☕ EPÍLOGO — ÀS 03:17 O FANTASMA VOLTOU

Touka e o jovem programador COBOL estavam novamente diante do SDSF.

Na tela apareceu:

03:17:42
PAYROLL01
ACTIVE

O iniciante perguntou:

— Então falhamos no offboarding?

Touka respondeu:

— Ainda não sabemos.

Talvez aquele job devesse continuar.

Talvez aquela service account fosse legítima.

Talvez o certificado ainda fosse necessário.

Talvez aquele dataset precisasse existir durante cinquenta anos.

A falha não é necessariamente o recurso continuar existindo.

A falha é ninguém saber por que ele existe, quem responde por ele e de qual autoridade ele depende.

Esse é o ponto central.

O objetivo do offboarding não deveria ser apagar tudo que determinada pessoa tocou.

Se fosse assim, quando um programador COBOL se aposentasse precisaríamos desligar metade do sistema bancário.

O objetivo é muito mais elegante:

Retirar a pessoa sem retirar da organização aquilo que pertence à organização — e sem deixar para trás autoridade que deveria ter desaparecido com ela.

É por isso que offboarding é IAM.

É segurança.

É governança.

É observabilidade.

É inventário.

É gestão de certificados.

É scheduler.

É RACF.

É Db2.

É CICS.

É MQ.

É cloud.

É DevOps.

É CMDB.

E, acima de tudo, é gestão de dependências.

Quando alguém sai da empresa, portanto, não pergunte apenas:

ACCOUNT DISABLED?

Pergunte:

WHAT STILL POINTS TO THIS PERSON?

Depois:

WHAT STILL EXECUTES BECAUSE OF THIS PERSON?

Depois:

WHAT AUTHORITY SURVIVED THIS PERSON?

E finalmente:

WHO OWNS IT NOW?

Porque existe uma diferença gigantesca entre:

FUNCIONÁRIO SAIU

IDENTIDADE FOI COMPLETAMENTE DESVINCULADA

Naquela madrugada, o job terminou:

PAYROLL01 ENDED
RC=0000

O programador sorriu.

Touka não.

Ele apontou para uma linha logo abaixo:

OWNER=BELL001

Silêncio.

Touka pegou o café.

— Encontramos outro.

No fundo do CPD, alguma coisa executou.

04:00:00
JOB EXPORT02
SUBMITTED

👻

O funcionário estava morto havia seis meses.

O mainframe ainda não tinha recebido a notícia.

☕ UM CAFÉ NO BELLACOSA MAINFRAME

quinta-feira, 2 de novembro de 2017

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

Bellacosa Mainframe e o racf

☕ Um Café no Bellacosa Mainframe — Especial Red Team

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que `SPECIAL` Virou o Passe para Chicago

🦖 Como pensar Red Team em ambientes que não foram projetados com o atacante moderno como personagem principal

Imagine Ferris Bueller diante de um terminal 3270.

Tela preta.

Letras verdes.

TSO.

ISPF.

RACF.

JCL.

CICS.

Db2.

MQ.

USS.

z/OS Connect.

Zowe.

APIs.

Ferris olha.

O administrador olha para Ferris.

Ferris olha de volta.

E então vem aquela pergunta inevitável:

“Qual é o caminho mais fácil?”

Essa pergunta é essencial.

Porque quando alguém fala em “atacar mainframe”, muita gente imagina que o atacante precisa quebrar o z/OS frontalmente.

Como se a única possibilidade fosse:

Internet
   ↓
Hacker
   ↓
3270
   ↓
RACF
   ↓
z/OS

Bonito.

Cinematográfico.

Simples.

E frequentemente errado.

O mainframe moderno vive dentro de um ecossistema enorme.

Aplicações web.

APIs.

Gateways.

Pipelines.

Cloud.

Mensageria.

DevOps.

Identidades federadas.

Service accounts.

Contas técnicas.

Fornecedores.

Automação.

Integrações.

Ferris não olha apenas para a fortaleza.

Olha para as pontes.

E essa é exatamente a mentalidade de Red Team.

Bem-vindo ao décimo primeiro episódio de:

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

Hoje Ferris chegou ao mainframe.

Mas talvez nunca precise realmente “hackear o mainframe”.

Talvez seja suficiente atacar:

o caminho até ele.

🔴 O mainframe pode ser extraordinariamente seguro

Vamos começar pelo óbvio.

z/OS não é um sistema operacional improvisado ontem à noite.

Décadas de maturidade.

Segurança.

Controle de acesso.

Auditoria.

Isolamento.

Processamento transacional.

Governança.

RACF.

SAF.

ACEE.

APF.

Controle de datasets.

Recursos protegidos.

Perfis.

Autorizações.

Em ambientes bem administrados, a superfície interna pode ser extremamente robusta.

Então Ferris pergunta:

“Preciso mesmo lutar com isso?”

Esse é o ponto.

Atacante eficiente não escolhe a defesa mais forte.

Escolhe o caminho mais barato.

🧠 A fortaleza não importa se existe uma ponte aberta

Imagine um castelo medieval.

Muros.

Torres.

Guardas.

Portão.

Tudo magnífico.

Mas existe:

uma ponte de serviço;

um túnel;

um fornecedor;

uma porta lateral.

Ferris não vai escalar a muralha se o entregador entra pela cozinha.

Em mainframe moderno, a “cozinha” pode ser:

API;

pipeline;

conta técnica;

ferramenta DevOps;

integração;

proxy;

jump server;

gateway.

🔐 RACF: o porteiro que precisa de contexto certo

RACF é uma peça central.

Ele controla:

usuários;

grupos;

datasets;

recursos;

acesso.

E pode ser extremamente poderoso.

Mas RACF trabalha com identidade e autorização.

Ele não lê intenção.

Se uma identidade legítima chega com permissão válida, o sistema pode autorizar.

Então a pergunta do Red Team é:

como consigo chegar com uma identidade legítima?

Essa pergunta muda tudo.

🪪 O problema não é sempre quebrar autenticação

Às vezes é:

roubar credencial;

usar credencial técnica;

explorar conta compartilhada;

abusar de sessão;

enganar operador;

explorar integração.

Ou seja:

o atacante não precisa destruir RACF.

Pode tentar convencer o ecossistema a lhe entregar uma identidade que RACF aceite.

☕ RACF não precisa falhar para o ataque funcionar

Essa frase merece destaque.

Authentication = SUCCESS
Authorization = SUCCESS
Action = ALLOWED

Tudo correto.

Só que a identidade foi comprometida.

Tecnicamente, RACF fez o trabalho certo.

O sistema global falhou antes.

Isso é Red Team.

🧠 SAF: o mecanismo de confiança

SAF permite que componentes consultem mecanismos de segurança.

Uma ideia elegante.

Aplicação pergunta:

“Este usuário pode fazer isto?”

Controle responde.

Mas novamente:

qual usuário?

Como a identidade foi construída?

De onde veio?

Foi propagada?

Foi mapeada?

Foi compartilhada?

A política pode ser perfeita.

A identidade pode estar errada.

🧬 ACEE: o contexto de segurança em memória

ACEE representa contexto de segurança associado ao usuário.

Identidade.

Grupos.

Atributos.

Permissões.

Na prática, isso significa que várias decisões dependem de um contexto de segurança já estabelecido.

Então Red Team pergunta:

“Como esse contexto nasceu?”

Porque se origem foi comprometida, o resto pode continuar funcionando normalmente.

🧨 `SPECIAL`: quando Ferris ganha passe VIP

Agora chegamos à palavra divertida.

RACF SPECIAL.

Autoridade poderosa.

Muito poderosa.

Uma identidade com SPECIAL pode possuir capacidades administrativas amplas dentro do RACF.

Então imagine Ferris encontrando uma conta dessas.

Não precisa “virar root”.

O mainframe não pensa exatamente assim.

Mas ele ganhou o equivalente a um passe VIP para partes críticas do controle de segurança.

E é aí que governança de privilégio vira essencial.

🔴 `SPECIAL` não deveria ser souvenir

Perguntas obrigatórias:

quem possui?

por quê?

há quanto tempo?

é necessário permanentemente?

há MFA?

há conta separada?

há auditoria?

há revisão periódica?

Se ninguém sabe responder...

Ferris já está sorrindo.

🧠 Standing Privilege no mainframe

Privilégio permanente é risco permanente.

Se alguém precisa de SPECIAL uma vez por mês, por que carrega isso todos os dias?

Idealmente:

conta normal para trabalho normal;

conta privilegiada para administração;

uso controlado;

registro;

aprovação quando necessário.

A velha Ferrari novamente.

🔐 PAM encontra RACF

PAM pode ajudar a controlar credenciais privilegiadas.

Checkout.

Rotação.

Sessões.

Aprovação.

Auditoria.

Isso reduz risco de credencial “eterna”.

Porque senha administrativa esquecida em script é praticamente um convite.

🧾 Credenciais técnicas: a nova chave embaixo do tapete

Service accounts.

IDs técnicos.

Usuários de aplicações.

São extremamente comuns.

E muito perigosos quando possuem privilégio excessivo.

Especialmente se:

senha não expira;

ninguém sabe dono;

conta é compartilhada;

está em script;

configuração;

arquivo;

pipeline.

Ferris não precisa convencer uma pessoa se encontrar credencial técnica.

🧠 Service account não vai ligar reclamando

Esse é o problema.

Conta humana tem comportamento.

Conta técnica pode rodar 24x7.

Então atividade maliciosa pode parecer “serviço”.

Por isso identidade técnica precisa:

escopo;

owner;

rotatividade;

monitoramento.

🦖 TSO: a porta clássica

TSO/ISPF é uma interface clássica de interação humana.

Se Ferris chega ali com credencial legítima, começa a explorar ambiente.

Datasets.

JCL.

Utilitários.

Comandos.

Mas isso ainda depende de autoridade.

RACF continua impondo limites.

Por isso atacante procura escalada.

📜 JCL: o poder de pedir ao sistema para trabalhar por você

JCL não é “apenas arquivo de lote”.

Ele descreve trabalho.

Programs.

Datasets.

Parâmetros.

Execução.

Se atacante obtém capacidade de submeter jobs com contexto privilegiado, isso pode ser extremamente relevante.

Então o Red Team pergunta:

quem pode submeter?

com qual identidade?

quais procedures?

quais bibliotecas?

quais programas?

🧠 Job autorizado pode fazer coisa indevida

Mais uma vez:

ação permitida tecnicamente.

Contexto malicioso.

Essa série inteira gira em torno disso.

Ferris não destrói o sistema.

Explora o uso legítimo.

🔐 APF: cuidado com quem pode influenciar código privilegiado

APF — Authorized Program Facility — é peça sensível.

Bibliotecas e programas autorizados podem operar com capacidades elevadas.

Isso significa que qualquer caminho que permita alterar conteúdo crítico relacionado a bibliotecas autorizadas merece atenção extrema.

O problema não é só “quem executa”.

É:

quem pode alterar aquilo que será executado com confiança elevada?

🧠 Supply chain dentro do próprio z/OS

Pense:

programa privilegiado é seguro.

Mas biblioteca foi alterada.

Ou processo de build foi comprometido.

Ou pipeline implantou coisa errada.

Você não atacou diretamente o runtime.

Atacou a cadeia de software.

Ferris adora cadeia.

🧬 USS: o mundo Unix dentro do z/OS

Unix System Services amplia capacidades.

Shell.

Filesystem.

Ferramentas.

Processos.

Integrações.

Isso é excelente.

Também significa mais superfície.

Permissões.

Arquivos.

Scripts.

Sockets.

Ferramentas open source.

Quem vem de Linux pode se sentir mais confortável ali.

Ferris talvez goste.

🔴 O atacante moderno provavelmente entende Linux

Essa é uma diferença importante.

Muita gente imagina mainframe como ambiente completamente estranho.

Mas USS aproxima certos conceitos do Unix.

Então atacante que já domina shell pode encontrar pontos familiares.

Mais uma razão para tratar USS com o mesmo rigor.

🧾 Permissões no filesystem também importam

Quem pode alterar script?

Quem pode executar?

Quem é owner?

Group?

ACL?

Se script roda com contexto poderoso, alteração indevida é perigosa.

Mesma lógica de APF.

🧠 CICS: o coração transacional

CICS é outra joia.

Milhões de transações.

Aplicações críticas.

Programas COBOL.

BMS.

Recursos.

Segurança pode controlar transações.

Mas Ferris talvez nem tente acessar CICS diretamente.

Pode entrar por:

API;

web;

middleware;

aplicação.

📡 z/OS Connect: a ponte moderna

Agora chegamos a uma ponte particularmente interessante.

z/OS Connect permite expor e consumir APIs relacionadas a aplicações z/OS.

É transformação moderna.

Integração.

Mas toda ponte cria perguntas de identidade.

Mobile
 ↓
API Gateway
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL

Pergunte:

quem autentica?

quem autoriza?

qual identidade chega ao backend?

há mapeamento?

há conta técnica?

há log ponta a ponta?

Isso é ouro para Red Team.

🔐 Identity Propagation

Se usuário externo autentica no frontend, queremos saber como identidade chega ao mainframe.

Se tudo vira:

APIUSER

temos perda de contexto.

Backend vê aplicação, não humano.

Isso pode dificultar auditoria.

🧠 Conta técnica compartilhada apaga autoria

Depois do incidente:

— Quem fez a transação?

— APIUSER.

Obrigado.

Quem era o usuário original?

Se cadeia não preserva isso, investigação fica difícil.

🧾 End-to-end traceability

Idealmente, uma ação deveria poder ser rastreada:

usuário;

sessão;

gateway;

API;

z/OS Connect;

CICS;

Db2.

Essa linha do tempo é valiosa.

💾 Db2: a verdade continua morando em algum lugar

No final, muitos sistemas chegam ao dado.

Db2.

Dados críticos.

Financeiros.

Clientes.

Transações.

Ferris pode não querer acesso administrativo.

Talvez baste executar operação legítima que altera dado valioso.

Isso torna autorização de aplicação crucial.

🧠 SQL permitido pode ser malicioso

Se aplicação permite certa transação, o backend vai executá-la.

O ataque pode estar no contexto anterior.

Por isso proteção de dados não pode depender apenas do banco.

📬 MQ: confiança em mensagens

MQ é outro clássico.

Mensagens.

Filas.

Integrações.

Sistemas confiam em mensagens recebidas.

Então Red Team pergunta:

quem pode publicar?

quem pode consumir?

que identidade?

qual origem?

há autenticação?

há autorização?

há validação de conteúdo?

🧨 Mensagem legítima, intenção maliciosa

Se atacante consegue publicar numa fila autorizada, downstream pode processar normalmente.

De novo:

o sistema funciona.

O problema está em quem conseguiu alimentar.

🕸️ Mainframe moderno é grafo, não ilha

Imagine:

Internet
 ↓
WAF
 ↓
Web App
 ↓
IAM
 ↓
API Gateway
 ↓
z/OS Connect
 ↓
CICS
 ↓
Db2

Agora adicione:

Git
 ↓
Jenkins
 ↓
DBB
 ↓
Deploy
 ↓
z/OS

Cloud
 ↓
MQ
 ↓
z/OS

Zowe
 ↓
z/OSMF
 ↓
System Services

Ferris olha para tudo.

Não apenas para o quadrado “MAINFRAME”.

🔴 A superfície está nas integrações

Toda integração precisa responder:

quem chama?

como autentica?

o que pode fazer?

como é auditada?

qual blast radius?

Integração mal desenhada vira atalho.

🧠 Zowe: modernização também cria novos caminhos

Zowe aproxima mainframe de ferramentas modernas.

CLI.

APIs.

Explorers.

Isso é excelente para produtividade.

Mas qualquer interface nova precisa de security design.

Ferris ama conveniência sem governança.

🔐 API é porta com maçaneta bonita

API bem protegida é ótima.

API mal protegida é entrada elegante.

Authorization.

Rate limiting.

Scopes.

Token lifecycle.

Logging.

Tudo importa.

🧠 O token virou a nova senha

JWT.

OAuth.

Tokens.

Se roubados, podem fornecer acesso temporário.

Então:

expiração;

scope;

audience;

revogação;

proteção.

Ferris não precisa conhecer senha se tem token válido.

🧨 Long-lived token é Ferrari com tanque cheio

Quanto mais dura, maior janela.

Prefira tokens curtos.

Renovação controlada.

Menor exposição.

🔐 OAuth não elimina autorização backend

Outra armadilha.

“Tem OAuth.”

Ótimo.

Mas backend precisa continuar aplicar política.

Token autenticado não significa “pode tudo”.

Identity ≠ Authorization.

Abe Froman voltou.

🧠 Zowe CLI em pipeline

Agora imagine automação.

CI/CD usando CLI.

Credenciais.

Tokens.

Deploy.

Ferris olha para pipeline.

Porque quem controla pipeline pode alterar o que chega ao mainframe.

🔴 CI/CD é caminho privilegiado

DevOps moderno aproxima desenvolvimento e produção.

Isso melhora velocidade.

Mas pipeline vira infraestrutura crítica.

Pergunte:

quem altera pipeline?

quem aprova?

quem pode injetar segredo?

quem assina artefato?

quem faz deploy?

🧾 Source control também é segurança operacional

Comprometer repositório pode ser mais fácil que atacar runtime.

Se código malicioso entra “legitimamente” e é implantado por pipeline aprovado, Ferris venceu sem tocar RACF diretamente.

🧠 Supply Chain Attack mainframe edition

Developer
 ↓
Git
 ↓
Build
 ↓
Artifact
 ↓
Deploy
 ↓
z/OS

Ataque qualquer etapa.

Ferris procura elo mais fraco.

🔐 Code Signing

Assinatura.

Integridade.

Proveniência.

Ajudam a garantir que artefato não foi alterado.

Mas processo de assinatura também precisa proteção.

Quem controla chave?

Quem aprova?

🧠 Secrets em pipeline

Senha em Jenkins.

Token em variável.

Credential store.

Isso é alvo valioso.

Service account com deploy rights pode ser caminho direto para produção.

🔴 DevOps sem least privilege vira Red Team playground

Pipeline não precisa ter mais acesso do que tarefa exige.

Um job de build não deveria possuir poder administrativo amplo em z/OS.

Separe responsabilidades.

🧠 APIs tornam mainframe mais acessível

Isso é bom.

Mas também significa que atacante pode operar usando ferramentas familiares.

HTTP.

JSON.

OAuth.

Ferris não precisa dominar 3270 para causar efeito no backend.

☕ O atacante moderno pode nunca ver ISPF

Essa frase é importante.

Talvez execute transação crítica via REST.

Backend COBOL.

Db2.

Tudo mainframe.

Atacante só viu:

POST /payments

Isso muda percepção de superfície.

🧠 Modernização não remove mainframe

Ela esconde.

E cria interfaces.

Security precisa considerar cada camada.

🔐 Defense in Depth

WAF.

IAM.

API Gateway.

z/OS Connect.

RACF.

CICS Security.

Db2.

Logs.

Camadas.

Nenhuma perfeita.

Swiss Cheese.

🧀 Ferris quer alinhar os buracos

Exemplo:

token roubado;

scope amplo;

API sem validação adicional;

conta técnica compartilhada;

backend com privilégio excessivo.

Juntos:

exploit.

🧠 O mainframe pode não ter falha nenhuma

Esse é o ponto central.

Ele recebe chamada válida.

Executa transação autorizada.

Grava Db2.

Do ponto de vista local, tudo certo.

O ataque aconteceu na confiança distribuída.

🔴 Threat Modeling precisa incluir upstream

Não pergunte só:

“z/OS está seguro?”

Pergunte:

quem fala com ele?

quem fala com quem fala com ele?

E quem administra tudo isso?

Agora começamos a ver o sistema real.

🕸️ Attack Path

Imagine:

LinkedIn
 ↓
Developer
 ↓
Git credential
 ↓
Pipeline
 ↓
Service account
 ↓
z/OS

Outro:

Phishing
 ↓
VPN
 ↓
Jump Server
 ↓
TSO
 ↓
RACF

Outro:

API token
 ↓
Gateway
 ↓
z/OS Connect
 ↓
CICS

Red Team procura esses caminhos.

🧠 Graph Thinking

Ativos são nós.

Acessos são arestas.

Atacante quer caminho.

Se existe:

User → Group → Role → Service → Mainframe

temos rota.

Mapear relações é valioso.

🔐 Least Privilege reduz arestas

Cada permissão removida elimina caminho potencial.

É por isso que recertificação importa.

Ferris odeia grafo bem podado.

🧾 RACF Groups merecem atenção

Grupo pode conceder acessos amplos.

Usuário entra.

Herda.

Anos depois ninguém lembra.

Privilege creep.

Revise.

🧠 `OPERATIONS` também merece cuidado

Autoridades poderosas precisam justificativa.

Não importa nome.

Princípio é:

privilégio extraordinário deve ser raro, monitorado e revisado.

🔍 `AUDITOR` também é sensível

Visibilidade ampla pode revelar informações relevantes.

Controle de auditoria também precisa separação.

Quem audita não deveria necessariamente administrar.

🔐 Separation of Duties no z/OS

Admin.

Auditor.

Operator.

Developer.

Cada papel.

Evite superusuário universal.

Ferris ama concentração.

🧠 Break Glass

Contas emergenciais.

Precisam existir.

Mas:

uso raro;

alerta;

justificativa;

rotação;

revisão.

Não podem virar conta diária.

🧾 SMF: memória operacional

SMF registra enorme quantidade de informação.

Eventos.

Uso.

Segurança.

Performance.

Operação.

Para Blue Team, isso é ouro.

Mas exige:

coleta;

correlação;

retenção;

análise.

🔵 Mainframe não precisa ser ponto cego do SOC

Integre telemetria.

RACF events.

SMF.

CICS.

Db2.

Network.

API.

Se SOC vê apenas Windows e cloud, Ferris ganha uma zona escura.

🧠 Visibility Gap

Um incidente pode atravessar:

cloud → API → z/OS.

Se logs estão separados, ninguém enxerga história completa.

Correlacionar é essencial.

☕ “No mainframe está tudo normal”

Talvez.

Mas upstream não.

Uma sessão pode parecer normal localmente porque credencial é válida.

Contexto externo revela fraude.

🧠 Identity context precisa viajar

IP.

Device.

User.

Session.

Risk.

Quanto contexto chega?

Quanto se perde?

Esse detalhe pode ajudar detecção.

🔴 Technical account apaga contexto

Outra vez.

Se todas as transações chegam como conta técnica, comportamento humano desaparece.

Mantenha correlação externa.

🔐 MFA no caminho inteiro

MFA em login inicial ajuda.

Mas se sessão depois gera token longo e reutilizável, risco continua.

Security lifecycle completo.

🧠 Session Hijacking

Não precisa roubar senha.

Roubar sessão pode bastar.

Então proteção de cookies, tokens e endpoints importa.

Mesmo quando backend é mainframe.

🔴 Ferris ataca endpoints mais modernos

Por quê?

Porque ferramentas são conhecidas.

Stacks comuns.

Documentação pública.

Isso não significa mainframe inseguro.

Significa ecossistema amplo.

🧠 API Security é Mainframe Security agora

Se API termina em CICS ou Db2, ataque à API é ataque ao negócio mainframe.

Essa fronteira mental precisa desaparecer.

☕ O mainframe não termina na LPAR

Essa frase merece destaque.

Hoje mainframe termina onde o processo de negócio termina.

Cloud.

Mobile.

API.

Partner.

Tudo conectado.

🧨 Third Party Access

Fornecedores.

Consultores.

Suporte.

Acessos remotos.

Pergunte:

como autenticam?

por quanto tempo?

qual privilégio?

há monitoramento?

conta individual?

Third party pode ser Cameron.

🧠 Vendor account antiga

Projeto acabou.

Conta ficou.

Clássico.

Red Team agradece.

Offboarding precisa funcionar.

🔐 Identity Lifecycle

Joiner.

Mover.

Leaver.

Quando pessoa muda de função, acessos mudam?

Quando sai, revoga?

Isso afeta mainframe também.

🧠 Orphan Accounts

Conta sem dono é perigo.

Especialmente privilegiada.

Inventário ajuda.

☕ “Essa conta é de quem?”

Se resposta:

“acho que é do sistema antigo”,

hora de investigar.

🔴 USS + SSH

Dependendo do ambiente, SSH pode ser interface.

Chaves.

Users.

Config.

Se chave privada vaza, atacante pode tentar acesso.

Então SSH key management importa.

🔐 Key Rotation

Chaves antigas.

Sem passphrase.

Compartilhadas.

Problema.

Gerencie ciclo.

🧠 APF + writable library = pesadelo

De forma conceitual, qualquer combinação de confiança elevada com capacidade indevida de alteração merece atenção máxima.

O Red Team procura justamente relações assim.

Não precisa publicar passo a passo.

Precisa mostrar risco.

🧩 Privilege Path

User comum.

Permissão em dataset.

Dataset influencia job.

Job roda privilegiado.

Agora temos caminho.

Ferris ama indireção.

🔴 Indirect Privilege é tão importante quanto direto

Você pode não ter SPECIAL.

Mas consegue influenciar algo que roda com autoridade.

Isso é caminho de escalada.

🧠 Control Flow matters

Quem controla código?

Config?

JCL?

Proc?

Libraries?

Tudo pode alterar comportamento.

☕ Não proteja só usuário final

Proteja também:

artefatos;

configuração;

scripts;

pipelines;

bibliotecas;

jobs.

Porque execução confia neles.

🔐 Change Control

Mudanças críticas precisam revisão.

Especialmente em componentes privilegiados.

Quatro olhos.

Auditoria.

Versionamento.

Ferris odeia peer review.

🧠 Code Review não é só qualidade

Também é segurança.

Mudança maliciosa ou acidental pode ser detectada.

🧾 Immutable logs

Se admin consegue apagar evidência, investigação sofre.

Envie cópia para sistema externo.

Proteja.

🔵 SOC + Mainframe

Idealmente, eventos críticos do mainframe chegam ao SOC com contexto.

SPECIAL usado?

Alerta.

Mudança incomum?

Alerta.

Acesso a dataset sensível?

Contexto.

🧠 Behavior Analytics no mainframe

Usuário normalmente acessa 3 datasets.

Hoje acessou 300.

Talvez legítimo.

Talvez não.

Contexto ajuda.

🔴 Baseline é útil

Não como verdade absoluta.

Mas para detectar desvio.

Ferris tenta parecer normal.

Blue Team procura padrão.

🧠 Mas cuidado com Automation Bias

Se score diz normal, não significa seguro.

Lembramos do Rooney.

Ferramenta ajuda.

Não substitui julgamento.

☕ Ferris entra pelo caminho menos glamouroso

Talvez:

senha esquecida em script.

Conta antiga.

Token.

Fornecedor.

API.

Nada cinematográfico.

Ataques reais frequentemente são assim.

🔐 Hygiene ainda vence

MFA.

PAM.

Least privilege.

Recertificação.

Logging.

Patch.

Segmentation.

DevSecOps.

Controle de secrets.

O básico continua forte.

🧠 Red Team Mainframe precisa conhecer negócio

Esse é o diferencial.

Não basta saber z/OS.

Precisa entender:

fluxo financeiro;

transações;

identidade;

integrações;

processos.

Porque objetivo não é “entrar no TSO”.

É impactar negócio.

🎯 Crown Jewels

Quais datasets?

Quais transações?

Quais APIs?

Quais jobs?

Quais contas?

Proteja com prioridade.

🧠 O atacante busca efeito, não terminal bonito

Ele quer:

dados;

dinheiro;

controle;

disrupção;

persistência.

3270 é apenas um meio.

🔴 Ferris não precisa ver `READY`

Essa frase também merece moldura.

Se consegue objetivo via API, acabou.

Red Team moderno precisa pensar além da estética do mainframe.

🦖 z/OS Connect, MQ, Zowe: modernização com responsabilidade

Essas tecnologias não são “problema”.

São capacidade.

Integração.

Produtividade.

O risco aparece quando são implantadas sem threat model.

Ferris não odeia modernização.

Ele ama modernização mal governada.

🧠 Security by Design

Cada integração deveria nascer com:

identity;

authorization;

logging;

rate limit;

secret management;

segregation.

Não depois.

☕ Threat Model antes do Go Live

Pergunte:

quem chamará?

com qual credencial?

o que pode fazer?

o que acontece se comprometer?

como revoga?

como detecta?

Isso é muito mais barato antes.

🔐 Zero Trust aplicado ao ecossistema

Não confiar implicitamente.

Verificar.

Limitar.

Monitorar.

Mesmo tráfego interno.

Mesmo fornecedor.

Mesmo serviço.

🧠 East-West matters

Ataque pode entrar por cloud e mover internamente.

Segmentação limita blast radius.

🔴 Network segmentation ainda vale

Mainframe não deve estar acessível de qualquer lugar.

Limite caminho.

Jump hosts.

Gateways.

Firewalls.

Rules.

🧠 Mas network não substitui identity

IP permitido não prova usuário legítimo.

Camadas.

☕ Ferris quer uma exceção

Toda empresa tem.

“Temporário.”

“Legado.”

“Só até migração.”

Ferris caça essas palavras.

🧾 Temporary access precisa expirar

Automático.

Não por memória humana.

Porque temporário é uma das coisas mais permanentes de TI.

🧠 Exception Management

Registre.

Owner.

Data final.

Risco.

Compensating controls.

Sem isso, exceção vira arquitetura.

🔴 Red Team deveria atacar exceções

Porque são caminhos menos testados.

Mais humanos.

Mais frágeis.

🧠 Mainframe security é ecosystem security

Essa é talvez a maior mensagem.

Você não protege z/OS isoladamente.

Protege:

identidade;

rede;

API;

pipeline;

endpoint;

fornecedor;

cloud;

dados;

processo.

☕ O atacante talvez nunca saiba que existe mainframe

Isso é quase poético.

Ele explora API.

Executa transação.

Recebe resposta.

Nem sabe que atrás existe CICS + COBOL + Db2.

Mas o impacto está lá.

🧠 Legacy é invisível ao atacante moderno

E isso não torna seguro.

Torna backend.

A segurança precisa abranger frontend e backend.

🔐 Authorization end-to-end

Não confie só no gateway.

Backend também valida quando possível.

Evite “front-end said yes, so everything is allowed”.

Ferris explora implicit trust.

🧠 Confused Deputy

Um componente autorizado pode ser induzido a fazer algo em nome do atacante.

Esse conceito encaixa perfeitamente.

Aplicação tem acesso.

Atacante manipula aplicação.

Backend recebe pedido legítimo de componente legítimo.

Problema.

☕ Cameron virou middleware de novo

Ferris → Cameron → escola.

Agora:

Ferris → API → middleware → mainframe.

Mesma história.

🧨 Service-to-Service Trust

Mutual TLS.

Tokens.

Scopes.

Audience.

Tudo precisa ser correto.

Porque serviço legítimo pode ser comprometido.

🧠 Machine Identity é nova fronteira

Há mais identidades de máquina que humanas em muitos ambientes.

Bots.

Pipelines.

APIs.

Agentes.

Cada uma precisa governança.

🔐 Secrets sprawl

Quanto mais integrações, mais secrets.

Gerenciamento centralizado ajuda.

Ferris procura aquele .properties antigo.

☕ Não coloque senha no JCL

Parece conselho de avô.

Continua válido.

Secrets não pertencem a texto aberto.

🧠 Dataset protection

Datasets podem conter:

source;

config;

credentials;

dados.

Classifique.

Controle.

Monitore.

🔴 Sensitive Dataset Access

Quem lê?

Quem atualiza?

Quem altera ACL?

Audite.

🧠 Db2 Privileges

Privilégios de banco também precisam least privilege.

Não dê SYSADM para resolver SELECT.

Ferrari com canhão.

🔐 CICS Transaction Security

Transações críticas devem exigir autorização adequada.

Não apenas acesso à região.

Granularidade importa.

🧠 MQ Object Security

Filas também são recursos.

Quem PUT?

Quem GET?

Quem ALTER?

Controle.

☕ Cada subsistema tem sua Ferrari

RACF.

CICS.

Db2.

MQ.

Cada um possui privilégios poderosos.

Não concentre tudo na mesma identidade.

🔴 Separation of Duties de verdade

RACF admin não precisa ser Db2 SYSADM automaticamente.

Db2 DBA não precisa controlar pipeline.

Segmente poder.

🧠 Blast Radius

Se uma conta cair, quanto perde?

Essa é pergunta simples e brutal.

Ferris quer conta com blast radius máximo.

🔐 Tiering de privilégio

Contas de alto risco mais protegidas.

MFA forte.

PAM.

Workstation dedicada quando necessário.

Monitoramento.

🧠 Privileged Workstation

Separar ambiente administrativo reduz exposição.

Não administre sistema crítico da mesma máquina usada para e-mail e navegação.

Ferris adora anexos.

☕ O maior bug pode estar no laptop do admin

Mainframe impecável.

Laptop comprometido.

Credencial roubada.

Fim.

Endpoint security também é mainframe security.

🔵 EDR não termina no Windows

Contexto do endpoint importa.

Se admin acessa z/OS de host comprometido, risco atravessa fronteira.

Correlacione.

🧠 Phishing continua relevante

FerrisGPT não precisa atacar z/OS.

Ataca quem administra z/OS.

A velha engenharia social continua viva.

🔴 Quem sabe mais sobre RACF?

Provavelmente profissionais específicos.

OSINT pode identificá-los.

Isso conecta artigo 4 ao 11.

A série fecha círculo.

☕ LinkedIn → Admin → TSO

Não é ataque técnico direto.

É attack path humano.

🧠 Red Team não é pentest de porta

Essa é a diferença.

Pentest pode olhar vulnerabilidades.

Red Team busca objetivo e caminho.

Mainframe exige essa visão.

🔴 Objective-Based Testing

Exemplo:

“Conseguir alterar dado crítico sem detecção.”

Agora escolha caminho.

API.

CICS.

Credencial.

Pipeline.

Não importa.

Objetivo guia.

🧠 Detection matters

Se ataque foi possível, foi detectado?

Quanto tempo?

Qual alerta?

Quem reagiu?

Red Team mede defesa.

🔵 Purple Team

Depois:

Red mostra caminho.

Blue cria detecção.

Engineering corrige.

IAM reduz privilégio.

Isso é valor.

☕ “Conseguimos entrar” é menos útil que “aprendemos por quê”

O objetivo final é aprendizado.

Ferris não precisa provar que é gênio.

Precisa revelar suposição fraca.

🧠 A pergunta Bellacosa número 1

“Qual é o caminho mais curto entre uma credencial externa comprometida e um recurso crítico no z/OS?”

Mapeie.

🔴 Pergunta número 2

“Quais contas técnicas possuem privilégio que ninguém revisa há anos?”

🧠 Pergunta número 3

“Onde identidade humana vira conta compartilhada?”

🔐 Pergunta número 4

“Quem consegue alterar algo que roda com privilégio maior?”

📜 Pergunta número 5

“Conseguimos reconstruir uma ação da internet até o Db2?”

Se não, observabilidade fragmentada.

🧨 Pergunta número 6

“Qual integração mais nova conversa com nosso sistema mais antigo?”

Essa é maravilhosa.

Porque risco frequentemente nasce na junção de eras.

🧠 Pergunta número 7

“Se uma service account for roubada, quem percebe?”

🔴 Pergunta número 8

“Nosso SOC enxerga o mainframe ou ele ainda é planeta separado?”

☕ Pergunta número 9

“Quem possui `SPECIAL` e realmente precisa dele hoje?”

Essa pode render café longo.

🧠 Pergunta número 10

“Estamos protegendo o z/OS ou apenas o terminal 3270?”

Essa é a essência.

🎬 Ferris entra em Chicago pela porta de serviço

O ataque moderno ao mainframe talvez nunca pareça “ataque de mainframe”.

Pode parecer:

phishing;

token roubado;

pipeline comprometido;

API abuse;

service account;

fornecedor;

endpoint.

No final, o efeito chega ao z/OS.

Essa é a mudança.

☕ Epílogo: o caminho até a Ferrari

Ferris olha para o mainframe.

Gigante.

Robusto.

RACF.

SAF.

ACEE.

APF.

CICS.

Db2.

MQ.

Uma fortaleza.

Ele poderia tentar aprender cada detalhe e procurar uma fraqueza frontal.

Talvez consiga.

Talvez não.

Mas Ferris não é romântico.

Ele é pragmático.

Então olha ao redor.

Vê:

API.

Pipeline.

Conta técnica.

Fornecedor.

Token.

Laptop.

Usuário privilegiado.

Integração.

E pensa:

“Por que eu atacaria o mainframe se posso atacar aquilo em que o mainframe confia?”

Essa é a pergunta central.

Porque segurança moderna não termina na LPAR.

Ela atravessa:

pessoas;

cloud;

DevOps;

IAM;

APIs;

mensageria;

agentes;

endpoints.

O mainframe pode ser extraordinariamente seguro.

E ainda assim estar ligado a cinquenta sistemas menos seguros.

A cadeia inteira define o risco.

Ferris não precisa quebrar RACF.

Talvez precise apenas conseguir uma identidade que RACF aceite.

Não precisa atacar CICS.

Talvez consiga uma API legítima.

Não precisa tocar Db2.

Talvez uma aplicação autorizada faça isso por ele.

Não precisa conseguir SPECIAL.

Talvez consiga influenciar quem já possui.

E é por isso que Red Team em mainframe não pode ser tratado como nostalgia técnica.

É segurança de ecossistema.

Ataque de caminho.

Confiança distribuída.

Privilégio.

Identidade.

Observabilidade.

E integração.

Então, da próxima vez que alguém disser:

“Nosso mainframe é seguro.”

A resposta correta não é discordar.

Talvez seja mesmo.

A resposta correta é perguntar:

“E o caminho até ele?”

Porque talvez Ferris nunca precise ver um prompt READY.

Talvez nunca abra ISPF.

Talvez nunca aprenda JCL.

Pode simplesmente atravessar uma API, usar uma conta técnica, seguir uma cadeia de confiança...

e deixar o z/OS fazer exatamente aquilo para o qual foi projetado.

Com eficiência.

Confiabilidade.

E absoluta obediência.

☕ SAVE FERRIS.

No próximo e último artigo:

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

Porque depois de Ferris atravessar pessoas, dados, Ferrari, IA e mainframe...

resta responder a pergunta mais importante:

o que a organização aprendeu antes que o próximo Ferris apareça?

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Ferris Bueller’s Red Team

Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?

Red Team
OSINT
Engenharia Social
Blue Team
MFA
PAM
IA Generativa
RACF
z/OS
Mainframe

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.

Red Team • Recon • Threat Modeling • Criatividade Adversarial

Ler artigo completo

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.

Integridade • Db2 • Auditoria • Insider Threat • Dados

Ler artigo completo

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.

Engenharia Social • Pretexting • Identity • Authentication

Ler artigo completo

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.

OSINT • Recon • LinkedIn • GitHub • Attack Surface

Ler artigo completo

Cameron, Atenda o Telefone — Social Engineering as a Service

Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.

Social Engineering • Swiss Cheese Model • Human Risk

Ler artigo completo

O Diretor Rooney Está Procurando Malware no Lugar Errado

Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.

SOC • SIEM • EDR • Zero Trust • Engenharia Social

Ler artigo completo

A Ferrari do Cameron Não Tinha MFA

Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.

MFA • PAM • Least Privilege • Privileged Access

Ler artigo completo

Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup

Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.

Backup • Restore • Rollback • Db2 • VSAM • Recovery

Ler artigo completo

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.

Blue Team • SOC • Cognitive Bias • Incident Response

Ler artigo completo

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT

Ler artigo completo

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe

Ler artigo completo

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.

Red Teaming • Purple Team • Detection • Resilience • Learning

Ler artigo completo

🎬 Página principal da temporada

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.

☕ Acessar o especial completo SAVE FERRIS

Sobre a série SAVE FERRIS — Red Team

A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.

O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.

A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.

Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.

Translate

segunda-feira, 2 de março de 2020