 |
| Bellacosa Maifnra e a razao do uso do mfa |
☕ Um Café no Bellacosa Mainframe — Especial Red Team
A Ferrari do Cameron Não Tinha MFA
🚗 Privilégio, acesso físico e o perigo de acreditar que “ninguém jamais faria isso”
Existe um tipo de segurança muito comum.
Não está documentado.
Não possui política formal.
Não tem controle técnico.
Não aparece no RACF.
Não gera log.
Não possui ticket.
Não precisa de auditoria.
É aquela segurança maravilhosa baseada em uma frase:
“Ninguém vai fazer isso.”
O pai de Cameron conhecia esse modelo.
Ele tinha uma Ferrari.
Não uma Ferrari qualquer.
Uma joia.
Um objeto quase religioso.
Uma peça de coleção tratada como altar.
O carro era intocável.
Sagrado.
Proibido.
E justamente por isso parecia seguro.
Não porque existia controle.
Mas porque existia medo.
Medo do pai.
Medo da consequência.
Medo de tocar.
Medo de errar.
Durante anos, funcionou.
Até Ferris aparecer.
Bem-vindo ao sétimo episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje a Ferrari do Cameron não é apenas um carro.
Ela é nosso sistema crítico.
Nosso ambiente de produção.
Nosso banco de dados.
Nossa conta privilegiada.
Nosso SYS1.
Nosso usuário com SPECIAL.
Nosso segredo corporativo.
Nosso objeto mais protegido.
Ou, pelo menos, aquilo que acreditamos estar protegido.
🚨 Segurança por medo é segurança sem controle
Vamos começar pelo pai de Cameron.
Ele não precisava instalar:
MFA.
PAM.
Biometria.
Geofencing.
Dual control.
Segregação de funções.
O modelo era mais simples:
FERRARI
↓
NÃO TOQUE
↓
SE TOCAR, VOCÊ ESTÁ MORTO
Muito eficiente.
Até o momento em que alguém decide tocar.
Esse é o problema de controles baseados em comportamento esperado.
Eles funcionam enquanto todos obedecem.
Red Team existe justamente para perguntar:
“E se alguém não obedecer?”
🧠 O perigo da frase “ninguém jamais faria isso”
Essa frase aparece em tecnologia o tempo todo.
— Ninguém vai usar essa conta.
— Ninguém vai rodar esse job manualmente.
— Ninguém vai alterar esse dataset.
— Ninguém vai copiar esse arquivo.
— Ninguém vai entrar nesse servidor.
— Ninguém vai usar essa senha fora do horário.
— Ninguém vai modificar produção direto.
Maravilhoso.
E se fizer?
Silêncio.
A segurança madura começa exatamente onde termina a suposição.
🔴 Red Team odeia controles imaginários
Um controle real impede.
Um controle imaginário depende de cultura.
Exemplo:
“Não compartilhar senha.”
Isso é política.
Mas se tecnicamente duas pessoas conseguem usar a mesma credencial, o risco existe.
“Não acessar produção.”
Isso é orientação.
Mas se o usuário possui permissão, o acesso existe.
“Não alterar esse dataset.”
Isso é pedido.
Mas se RACF autoriza UPDATE, então o sistema não sabe que aquilo era apenas uma sugestão.
Ferris ama sugestões.
🚗 A Ferrari vira produção
Vamos transportar a metáfora.
Imagine a Ferrari como:
PROD
O pai de Cameron é o administrador.
Cameron possui acesso físico.
Ferris não possui autorização formal.
Mas conhece Cameron.
Agora temos:
Ferris
↓
Cameron
↓
Garagem
↓
Ferrari
O atacante não precisou quebrar a Ferrari.
Precisou chegar perto de quem tinha acesso.
Essa diferença é tudo.
🔐 Privilégio é poder, não título
Em segurança, privilégio é simples:
capacidade de fazer algo sensível.
Quem pode:
parar serviço;
alterar configuração;
ler dados críticos;
modificar contas;
conceder acesso;
executar comandos administrativos;
tem privilégio.
Não importa se a pessoa usa esse poder todos os dias.
O poder existe.
E Ferris procura exatamente isso.
🪜 Least Privilege: Cameron não deveria ter acesso amplo só porque mora ali
O princípio de menor privilégio diz:
cada pessoa deve possuir apenas o acesso necessário.
Cameron mora na casa.
Isso não significa que deveria poder pegar a Ferrari.
Mas fisicamente pode.
Em empresas acontece algo parecido.
Funcionário pertence à organização.
Isso não significa que deveria acessar tudo.
Administrador trabalha em infraestrutura.
Isso não significa que deveria ter acesso irrestrito a produção.
Desenvolvedor conhece a aplicação.
Isso não significa que deveria alterar dados diretamente.
Least privilege separa proximidade de necessidade.
☕ “Mas ele é confiável”
Outra frase perigosa.
Confiança não elimina necessidade de controle.
Pessoas confiáveis:
cometem erros;
podem ser coagidas;
podem ter credenciais comprometidas;
podem mudar de função;
podem sofrer engenharia social;
podem agir fora do padrão.
Segurança não deve depender de caráter.
Deve depender de arquitetura.
🧠 Confiança é contexto, não autorização infinita
Uma pessoa pode ser confiável para uma tarefa.
Isso não significa confiar em tudo.
Por isso sistemas maduros modelam privilégio.
O usuário recebe:
o que precisa;
pelo tempo necessário;
para o objetivo autorizado.
Depois, o acesso sai.
Isso é muito diferente de:
“Ele é do time, deixa.”
🔐 MFA: a Ferrari precisava perguntar “você realmente é você?”
MFA existe para reduzir risco de uma única credencial comprometida.
Algo que você sabe.
Algo que você tem.
Algo que você é.
A Ferrari tinha praticamente:
FACTOR 1:
estar na garagem
Nada mais.
Se você chegasse ao carro com acesso físico suficiente, o modelo de segurança já estava quase vencido.
Em sistemas modernos, isso seria equivalente a:
usuário e senha apenas.
📲 MFA não é bala de prata
Claro.
MFA não resolve tudo.
Pode ser atacado.
Pode ser mal configurado.
Pode sofrer engenharia social.
Pode haver fatigue attack.
Pode existir aprovação indevida.
Mas aumenta custo do atacante.
O objetivo não é perfeição.
É criar camadas.
🧱 Controle bom cria fricção adversarial
Segurança madura faz o atacante gastar.
Tempo.
Esforço.
Conhecimento.
Risco.
Cada controle adiciona custo.
Ferris quer caminho barato.
Se a Ferrari exigisse:
chave física;
PIN;
aprovação;
registro;
talvez o passeio acabasse antes de começar.
🧨 PAM: pare de deixar o volante administrativo em cima da mesa
Privileged Access Management existe para controlar acessos poderosos.
Contas privilegiadas não deveriam funcionar como chaves de casa penduradas perto da porta.
PAM pode ajudar com:
vault de credenciais;
checkout;
rotação;
gravação de sessão;
aprovação;
tempo limitado;
auditoria.
O objetivo é simples:
ninguém deveria andar com uma credencial administrativa permanente no bolso como se fosse chave da Ferrari.
🪪 Standing Privilege é Ferrari com chave na ignição
Esse é o problema.
Privilégio permanente significa:
a capacidade existe o tempo inteiro.
Mesmo quando não é necessária.
Isso amplia risco.
Modelo melhor:
Just-In-Time.
Acesso sob demanda.
Tempo limitado.
Expira.
Isso é muito mais saudável.
🕐 JIT: use a Ferrari só durante a janela autorizada
Imagine:
Cameron precisa usar o carro para uma tarefa.
Então ganha acesso das 14h às 15h.
Depois:
revogado.
Em tecnologia:
ACCESS GRANTED
14:00
ACCESS EXPIRES
15:00
Isso reduz janela de ataque.
🔵 JEA: Just Enough Administration
Outra ideia importante.
Não basta limitar tempo.
Limite capacidade.
Se o administrador precisa reiniciar serviço, não precisa necessariamente poder:
alterar usuários;
deletar logs;
modificar banco;
exportar dados.
Privilégio deve ser granular.
Ferrari não precisa entregar a chave do hangar inteiro.
🧠 Segregação de funções: Cameron não deveria ser dono, motorista e auditor
Segregation of Duties existe para impedir concentração excessiva.
Quem solicita não aprova.
Quem executa não audita.
Quem administra não revisa sozinho.
Se uma pessoa controla tudo, fraude e erro ficam mais fáceis.
Cameron possuía acesso físico.
Ferris influenciava.
Não existia terceira validação.
Resultado:
o sistema de proteção era emocional.
🚦 Dual Control
Em ambientes críticos, duas pessoas podem precisar aprovar.
Isso é dual control.
Exemplo:
ADMIN 1 requests
ADMIN 2 approves
SYSTEM executes
Agora um atacante precisa comprometer mais de uma camada.
Swiss Cheese novamente.
☕ O pai do Cameron apostou tudo num único controle
Qual era o controle?
Medo.
Um único controle.
Sem redundância.
Se o medo falha, tudo falha.
Defense in Depth existe justamente porque controles falham.
🧀 Ferrari Swiss Cheese Model
Imagine camadas:
Camada 1: Regra
Camada 2: Acesso físico
Camada 3: Chave
Camada 4: Monitoramento
Camada 5: Alerta
No filme, muitas dessas camadas são fracas ou inexistentes.
Então:
Ferris encontra Cameron.
Cameron conhece garagem.
Garagem contém carro.
Carro está acessível.
Pronto.
Os buracos alinham.
🛡️ Controles compensatórios
Nem sempre é possível implementar o controle ideal.
Aí entram controles compensatórios.
Exemplo:
não consegue remover determinado privilégio legado?
Então:
monitore;
limite horário;
exija aprovação;
gere alerta;
revise sessão.
Isso não é perfeito.
Mas reduz risco.
🦖 E no mainframe?
Agora entramos no terreno Bellacosa Mainframe.
No z/OS, privilégio pode assumir formas críticas.
RACF SPECIAL.
OPERATIONS.
AUDITOR.
Perfis poderosos.
Acesso a datasets sensíveis.
Autoridade em CICS.
Db2.
JES.
SDSF.
Contas com poder amplo.
Um ambiente pode ser extremamente seguro e ainda sofrer com privilégio excessivo.
🔐 RACF SPECIAL é Ferrari com nitro
Um usuário com SPECIAL possui enorme capacidade administrativa.
Então perguntas importantes:
quem possui?
por quê?
há revisão?
é permanente?
há MFA?
há logging?
há separação?
há uso diário?
há conta alternativa sem privilégio?
Contas privilegiadas devem ser tratadas como ativos críticos.
🧠 Use usuário normal para vida normal
Uma boa prática clássica:
usuário administrativo separado.
No dia a dia:
conta normal.
Quando precisa administrar:
conta privilegiada.
Isso reduz exposição.
Porque navegar, ler e-mail, abrir arquivos e executar tarefas normais com privilégio elevado aumenta risco.
🧪 Ferris não precisa roubar a Ferrari se consegue usar Cameron
Esse ponto retorna.
O atacante muitas vezes não rouba credencial diretamente.
Ele usa quem tem acesso.
Engenharia social pode transformar administrador em proxy.
— Pode executar esse comando pra mim?
— Pode liberar esse acesso?
— Pode aprovar essa solicitação?
Ferris não senta sozinho no carro.
Ele traz Cameron.
📞 Privilege Proxy
Esse conceito é importante.
Você pode não possuir privilégio.
Mas pode influenciar quem possui.
Então o caminho de ataque é:
ATTACKER
↓
PRIVILEGED USER
↓
SYSTEM
Esse caminho é tão importante quanto credencial roubada.
🤖 Em 2026, o Ferris ganha automação
Agora imagine:
OSINT identifica administradores.
IA ajuda a personalizar pretexto.
Ataque social visa quem possui privilégio.
O objetivo não é necessariamente roubar senha.
Pode ser induzir ação.
Isso muda a defesa.
Treinamento precisa incluir pedidos de execução.
🚨 “Execute esse script”
Esse é um clássico.
A pessoa recebe código.
Confia na origem.
Executa.
Se usuário privilegiado executar algo malicioso, o atacante herda contexto poderoso.
Então:
não basta proteger credencial.
É preciso proteger decisão.
🧠 Privilégio humano e privilégio técnico se encontram
Uma pessoa com autoridade social pode pressionar quem possui privilégio técnico.
CEO:
— Faça agora.
Admin:
— Procedimento exige aprovação.
CEO:
— Eu sou o CEO.
Admin:
— Excelente. O procedimento continua existindo.
Essa resposta deveria ser normal.
🔴 Cultura forte protege controle
Se organização pune quem segue processo quando há pressão executiva, matou a segurança.
Você treinou o funcionário para obedecer urgência.
Ferris agradece.
🧯 Break Glass não pode virar “porta da cozinha”
Contas de emergência existem.
Break glass.
Acesso excepcional.
Mas se o acesso excepcional vira rotina, acabou.
Deve existir:
uso raro;
alerta;
justificativa;
auditoria;
revisão pós-uso.
Ferrari de emergência não pode ficar ligada 24 horas.
🧾 Log: quem dirigiu?
Depois do incidente, primeira pergunta:
quem usou?
Em acesso privilegiado, isso precisa ser claro.
Não:
“foi a conta ADMIN.”
Quem era a pessoa?
Qual sessão?
Qual comando?
Qual horário?
Qual motivo?
Sem isso, auditoria vira ficção.
🔍 Session Recording
PAM moderno pode gravar sessão administrativa.
Isso ajuda a reconstruir:
comandos;
ações;
sequência.
Muito útil para investigação.
Principalmente em acesso crítico.
☕ O carro voltou para garagem, então está tudo bem?
Não.
Esse é outro erro.
No filme, existe tentativa de devolver a Ferrari.
Mas o fato de o ativo voltar não elimina o evento.
Em tecnologia:
credencial usada e devolvida;
arquivo copiado e apagado;
configuração alterada e revertida.
Ainda houve exposição.
🧠 Integridade e rastreabilidade continuam valendo
Um sistema crítico pode não sofrer dano visível.
Mas se privilégio foi usado indevidamente, precisamos saber.
Não basta verificar estado final.
Precisamos entender caminho.
🧨 Acesso físico continua importando
Em tempos de cloud, muita gente esquece segurança física.
Mas dispositivos existem.
Datacenters existem.
Estações existem.
Consoles existem.
Portas existem.
Quem consegue tocar hardware pode ganhar vantagens.
Ferrari lembra isso lindamente.
🚪 Physical Access ≠ Logical Authorization
Entrar na sala não deveria significar acessar sistema.
Sentar na estação não deveria significar sessão aberta.
Encontrar notebook não deveria significar acesso.
Camadas precisam existir.
🔒 Screen Lock é o cinto de segurança corporativo
Parece pequeno.
Mas estação desbloqueada com sessão privilegiada é perigo.
Ferris vê um terminal aberto.
Ferris não precisa hackear.
Ele senta.
Fim.
🧑💻 Shared Admin Account: a Ferrari com chave comunitária
Contas compartilhadas são ruins porque destroem accountability.
Se cinco admins usam:
ADMIN01
quem fez?
Boa sorte.
Identidade individual importa.
🪪 Named Accounts
Cada administrador deve possuir identidade própria.
Isso permite:
rastreio;
revogação;
revisão;
responsabilidade.
Sem isso, o sistema conhece apenas “alguém”.
🔁 Rotação de credenciais
Senhas privilegiadas não deveriam durar eternamente.
Credenciais antigas acumulam risco.
Rotação reduz janela de abuso.
PAM automatiza isso.
Ferrari com fechadura trocada periodicamente.
🧠 Secrets Management
Contas técnicas também precisam proteção.
Senha em script?
Credencial em JCL?
Token em arquivo?
Secret em pipeline?
Tudo isso é equivalente a esconder a chave embaixo do tapete.
🦖 Mainframe DevOps e privilégio
Ambientes modernos conectam:
Git;
pipeline;
DBB;
Jenkins;
UrbanCode;
Ansible;
Zowe;
z/OSMF.
Agora existem novas identidades técnicas.
Pergunte:
quem deploya?
qual token?
qual conta?
qual privilégio?
onde está armazenado?
A Ferrari agora tem API.
🧨 Service Account poderosa demais
Uma conta técnica pode possuir:
deploy;
update;
start;
stop;
dataset access.
Se comprometida, o atacante ganha capacidade silenciosa.
Least privilege vale para máquina também.
🤖 Machine Identity também precisa de controle
Não são só humanos.
APIs.
Agentes.
Bots.
Pipelines.
Serviços.
Todos possuem identidade.
E podem possuir privilégio.
Ferris de 2026 pode atacar credenciais não humanas.
🔐 MFA para máquina não funciona igual, mas controle existe
Certificados.
Tokens de curta duração.
Workload identity.
Rotação.
Vault.
Mutual TLS.
O princípio permanece:
não confie só porque alguém tem uma string secreta eterna.
🚨 “Nunca aconteceu”
Outra frase clássica.
— Sempre fizemos assim.
— Nunca deu problema.
Ferrari também ficou anos segura.
Até o dia em que não ficou.
Ausência de incidente não prova eficácia de controle.
Talvez ninguém tenha tentado.
🧪 Red Team testa justamente isso
Red Team pode perguntar:
consigo alcançar conta privilegiada?
consigo induzir uso?
consigo contornar MFA?
consigo encontrar credencial técnica?
consigo abusar de processo de emergência?
E, mais importante:
seria detectado?
🔵 Blue Team deveria observar privilégio como anomalia
Eventos privilegiados merecem contexto.
Horário.
Origem.
Comando.
Volume.
Mudança.
Conta.
Sistema.
Privilégio raro é sinal valioso.
🧠 Usuário admin às 03h17
Pode ser legítimo.
Mas merece pergunta.
Principalmente se:
novo dispositivo;
novo IP;
novo padrão;
ação incomum.
Detecção baseada em comportamento ajuda.
☕ O carro não precisa desaparecer para existir incidente
Essa ideia merece repetir.
Atacante não precisa destruir ativo.
Pode apenas usar.
Copiar.
Alterar.
Observar.
Isso vale para dados.
Ferrari pode voltar para garagem.
O risco já aconteceu.
🧨 Privilege Escalation: de Cameron para Ferris
Ferris inicialmente não tem acesso.
Mas usa relação com Cameron.
Em segurança:
usuário comum compromete admin;
credencial baixa encontra caminho;
permissão herdada permite escalada.
Esse movimento é central.
🪜 Attack Path
Imagine:
USER
↓
GROUP
↓
SHARED SERVER
↓
ADMIN TOKEN
↓
DOMAIN
Nenhum salto isolado parece absurdo.
A cadeia produz poder.
Ferrari novamente.
🧠 Graph Security
Ferramentas modernas analisam relações.
Quem pode acessar o quê?
Quem pode assumir qual role?
Qual caminho leva a privilégio?
Isso é poderoso porque atacante pensa em caminho.
🔴 O ativo crítico deve ser difícil de alcançar
Não basta proteger o final.
Reduza caminhos.
Remova privilégio.
Segmente.
Expire acessos.
Aumente validação.
Ferris precisa encontrar mais obstáculos.
🧱 Controles independentes
Se MFA depende do mesmo celular comprometido, cuidado.
Se aprovação depende da mesma pessoa, cuidado.
Se log está no mesmo sistema que admin controla, cuidado.
Camadas precisam ser independentes.
🧀 Swiss Cheese de privilégio
Exemplo:
Password
↓
MFA
↓
PAM
↓
Approval
↓
Session Recording
↓
Monitoring
Uma camada falha.
Outra segura.
Essa é a ideia.
🛡️ Compensação quando legado limita
Mainframe e sistemas legados possuem restrições.
Talvez determinada aplicação não suporte MFA diretamente.
Então use:
gateway;
jump server;
PAM;
controle de rede;
monitoramento;
segunda validação.
Segurança prática vive de composição.
🧠 Não romantize o controle perfeito
Não existe.
O objetivo é reduzir probabilidade e impacto.
Ferris pode tentar.
Queremos:
bloquear;
detectar;
conter;
explicar.
🚘 O pai de Cameron tinha um problema de governança
A Ferrari era um ativo crítico.
Mas não existia governança proporcional ao valor.
Muito valor.
Pouco controle.
Essa assimetria é perigosa.
📊 Crown Jewels
Empresas deveriam identificar joias da coroa.
Dados críticos.
Sistemas críticos.
Contas críticas.
Chaves críticas.
Depois aplicar controles proporcionais.
Nem tudo precisa de Ferrari security.
Mas Ferrari precisa.
💎 Classificação de ativo
Pergunte:
qual impacto se alguém:
ler?
alterar?
usar?
parar?
copiar?
Esse exercício ajuda a definir proteção.
☕ A pergunta Bellacosa
Eu colocaria esta numa War Room:
“Qual ativo nosso está protegido principalmente porque acreditamos que ninguém ousaria tocar?”
Se alguém responder rápido demais:
“nenhum”,
eu perguntaria de novo.
Porque quase toda empresa tem sua Ferrari.
🔴 Outra pergunta
“Quem possui acesso permanente que só deveria usar raramente?”
Aí começa a diversão.
🧠 E uma terceira
“Se essa pessoa for enganada, qual é o próximo controle?”
Se a resposta for:
“esperamos que ela não seja enganada”,
temos problema.
🎬 Ferris não quebrou a Ferrari
Ele quebrou o modelo mental ao redor dela.
Essa é a grande lição.
O carro era fisicamente robusto.
O sistema social não.
O pai de Cameron acreditava que proibição era equivalente a controle.
Não era.
☕ Epílogo: ninguém jamais faria isso
Ferrari na garagem.
Perfeita.
Polida.
Quase sagrada.
O pai de Cameron provavelmente dormia tranquilo porque acreditava numa certeza:
ninguém vai tocar.
Isso é confortável.
Mas segurança não vive de conforto.
Red Team existe para destruir certezas antes que um atacante real faça isso.
Não perguntamos:
“as pessoas deveriam fazer?”
Perguntamos:
“podem fazer?”
Não perguntamos:
“isso é proibido?”
Perguntamos:
“o sistema impede?”
Não perguntamos:
“ninguém faria?”
Perguntamos:
“O que acontece quando alguém fizer?”
Essa diferença separa política de controle.
Confiança de verificação.
Medo de segurança.
A Ferrari do Cameron não precisava de um discurso.
Precisava de camadas.
MFA.
PAM.
Least privilege.
Segregação.
Auditoria.
Monitoramento.
Controles compensatórios.
Porque objetos valiosos atraem comportamento adversarial.
E sistemas críticos também.
Se sua produção está protegida principalmente por:
“ninguém mexe nisso”,
Ferris já está sorrindo.
Cameron já está nervoso.
E a garagem acabou de virar sua nova superfície de ataque.
☕ SAVE FERRIS.
No próximo artigo:
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
Porque descobrir que alguém usou seu ativo crítico já é ruim.
Descobrir que você não consegue desfazer direito...
é muito pior.
