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 é?

e:

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

e:

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:

1. O login foi bloqueado?

2. Sessões existentes foram tratadas?

3. Existem jobs associados?

4. Existem credenciais independentes?

5. Existem certificados?

6. Existem tokens?

7. Existem datasets cujo owner precisa mudar?

8. Existem grupos?

9. Existem service accounts relacionadas?

10. Existem processos executando?

11. Existe atividade posterior ao desligamento?

12. 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

e:

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