✨ 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
Nossa viagem foi bem lenta, saímos de casa por volta das 6 horas da manhã, mas devido a serração e uma fina garoa que deixou a pista escorregadia, tivemos que vir em velocidade mais reduzida, e por isso levamos quase 3 horas dirigindo para chegar em São José dos Campos.
Nesta etapa de nossa viagem, fazemos o nosso pit stop no Frango Assado, que no carro estávamos brincando que deveria se chamar Pipi I, mas falando pelo serviço é ótimo ter um ponto de parada seguro, apesar dos preços proibitivos ali praticados, outra hora voltaremos a esse tema.
Entrando nesta estalagem para esticarmos nossas pernas e tomar nosso desejum, um bom café é realmente bem vindo, após tanto tempo de estrada, nossa atenção é presa quando avistamos algo fora do comum.
Bem próximo a saída do Frango Assado, bem ao lado do Posto de Gasolina vemos uma concentração de motos e o ponto alto é uma replica de moto da Segunda Guerra Mundial, claro que o formiguinha disse que era a moto do Capitão América e ficamos na maior farra para ir ver, num próximo vídeo veremos o que vimos..
Estamos rumo a Ubatuba e após sairmos da Rodovia Dom Pedro, paramos em São José dos Campos para um café da manhã no Frango Assado, e de volta a estrada agora estamos na Rodovia Carvalho Pinto.
Animados por vencer mais uma etapa de nossa viagem, estamos cada vez mais perto, apesar que ainda faltam uns 200 quilômetros, acordados após o café da manhã, vamos prestando atenção na paisagem, esta rodovia para ser mais reta, tem diversos tuneis em seu trajeto.
Entramos no primeiro e vieram as memorias de infância, quando meu pai descia a Rodovia Imigrantes e naquela época a maior diversão da garotada era fazer o buzinaço dentro do túnel, aquele eco, a barulheira era extremamente divertido.
Hoje as regras de transito são mais duras e rígidas, porém essas lembranças da direção automobilística do passado são divertidas comparativamente aos dias atuais, naquela época viajar era uma aventura cheia de percalços, nunca sabíamos o que iriamos ter pela frente, sem gps, sem telefones celulares, apenas um guia de estradas guardado no porta luvas e sempre consultado em caso de duvidas.
Ei amigo, você tem lembrança semelhante? Seus pais ou parentes também faziam buzinaços nos túneis?
Bellacosa Mainframe e o pedagio de igarata na sp 065
SP 065: Passando pelo pedágio em Igaratá
Viagem rumo ao final da Rodovia Dom Pedro.
Dirigindo pela SP 065 passamos por mais uma praça de pedágio, agora estamos em Igaratá, não sei dizer se é o bom ruim, por um lado temos uma estrada muito bem conservada em que podemos ter maiores velocidades rumo ao nosso destino, por outro lado, temos uma parcela da população impossibilitada de viajar devido aos custos.
Temos o repasse destas taxa de pedágio ao custo do frete, que por sua vez encarece o produto final, tirando do mercado os pequenos produtores que tem margens de lucro bem apertadas. Acredito que deveria ter um meio termo, afinal já pagamos o IPVA, que supostamente era para custear as estradas e ruas.
Bom pensem a respeito, agora voltemos a nossa viagem a Ubatuba, estamos na estrada desta vez na SP 065, saímos de Itatiba, passamos por Jarinu e Atibaia e estamos indo rumo a Jacareí, passamos pela 3ª praça de pedágio Igaratá, que acredito ser um absurdo paga tanto, no estado de São Paulo é muito caro dirigir pelas estradas, a cada 50 quilômetros mais ou menos, existem praças de pedágio, até o final desta viagem, serão mais 2, o que podemos fazer?
Saindo de Itatiba em direção a leste, pegamos a Rodovia Dom Pedro e seguimos rumo a Jacareí, neste trecho estamos próximos a Jarinu e Atibaia.
Estamos numa manha fria e a nevoa cobre toda a paisagem, nos deixando com uma visibilidade bem baixa, acompanhem um bocadinho deste trecho, onde com a pista molhada e escorregadia e baixa visibilidade coloca a prova todos os reflexos de um bom motorista.
Para quem não conhece a nossa região estamos situados na Serra da Mantigueira, somos as colinas que iniciam a elevação, neste trecho ultrapassamos os 650 metros de altitude e a tendencia e sempre a subir.
Iremos passar por diversos reservatórios de água pertencentes ao Sistema Cantareira.
Experiencias para motorista, neblina e a baixa visibilidade
Nossa viagem rumo a Ubatuba continua, a neblina começa perder força e os raios solares começam a surgir lá longe.
A viagem esta divertida com o Formiga perguntando sobre tudo, curiosidade tipica da idade, nosso pequeno amigo tagarela descobre sobre represas e lagos, vendo os viadutos sobre os grandes lagos que começam a se encherem, após o longo período de estiagem que nosso estado atravessou.
A seca foi tão grande que diversos municípios tiveram interrupção do fornecimento de água, sofrendo com rodízios e mesmo abastecimento por carro pipa. Por sorte 2016 e 2017 trouxeram chuvas e gradualmente o Sistema Cantareira vem repondo sua cota d´água e as diversas represas começam a encherem.
Depois desse bla bla bla, nossa viagem pela Rodovia Dom Pedro esta quase terminando e em breve chegaremos a Jacareí onde iremos pegar a Rodovia Dutra. Até la amigos.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
🚗 O glorioso momento em que alguém descobre que desfazer uma ação não significa desfazer suas consequências
Existe uma cena em Curtindo a Vida Adoidado que deveria ser exibida em todo curso de operações, recuperação, banco de dados, continuidade e resposta a incidentes.
A Ferrari foi usada.
A quilometragem aumentou.
O problema precisa desaparecer.
Surge então uma ideia absolutamente maravilhosa em sua simplicidade:
vamos colocar o carro em marcha a ré.
Se andar para frente aumentou a quilometragem...
andar para trás deveria diminuir.
Lógica cristalina.
Elegante.
Quase matemática.
E completamente incapaz de apagar tudo o que já aconteceu.
É neste momento que Ferris Bueller encontra uma das verdades mais dolorosas de produção:
desfazer estado não significa desfazer história.
Você pode voltar um valor.
Pode restaurar um arquivo.
Pode carregar um backup.
Pode executar ROLLBACK.
Pode recuperar uma tabela.
Pode restaurar um dataset.
Pode voltar configuração.
Mas talvez não consiga desfazer:
a mensagem enviada;
o pagamento processado;
o cliente que recebeu informação errada;
o arquivo copiado;
a fraude executada;
o log gerado;
o segredo exposto;
o processo disparado;
a decisão humana tomada.
Em outras palavras:
Produção não possui Ctrl+Z emocional.
Bem-vindo ao oitavo episódio de:
SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula
Hoje vamos falar da Ferrari.
Mas, na verdade, vamos falar de backup, restore, rollback, journaling, Db2, VSAM, recuperação de transações e daquela reunião pós-incidente em que alguém pergunta:
— Dá para voltar?
E toda a sala fica em silêncio.
🔴 Primeiro erro: acreditar que “voltar” é uma coisa só
Em tecnologia usamos várias palavras como se significassem a mesma coisa.
Backup.
Restore.
Rollback.
Recovery.
Undo.
Rebuild.
Reprocess.
Failback.
Mas não são a mesma coisa.
Cada uma atua em uma camada diferente.
Ferris descobriria isso rapidamente.
💾 Backup não é rollback
Backup é uma cópia de estado em algum momento.
Ele responde:
“Temos uma versão anterior?”
Isso é importante.
Mas não significa que você consegue voltar instantaneamente.
Exemplo:
00:00 BACKUP
02:00 INCIDENT
05:00 DETECTION
Se você restaurar o backup da meia-noite...
o que acontece com tudo que ocorreu entre 00:00 e 05:00?
Pedidos?
Pagamentos?
Cadastros?
Transações?
Logs?
Talvez você recupere consistência técnica destruindo realidade de negócio.
Ferrari voltou para garagem.
Mas a cidade inteira já viu o carro.
🔁 Rollback é outra coisa
Rollback normalmente significa desfazer uma transação ou conjunto de mudanças antes da confirmação definitiva.
Em banco de dados, isso é natural.
Você inicia uma unidade de trabalho.
Faz alterações.
Algo dá errado.
Executa rollback.
O banco volta ao estado anterior daquela transação.
Perfeito.
Mas perceba:
isso funciona porque o sistema ainda possui contexto suficiente para desfazer.
Depois que uma mudança é confirmada, propagada e consumida por outros sistemas, a história complica.
☕ COMMIT é quase um rito religioso
Quem trabalha com transação entende.
Antes do COMMIT, o universo ainda pode ser negociado.
Depois do COMMIT...
a conversa muda.
UPDATE...
UPDATE...
UPDATE...
COMMIT
Pronto.
A transação foi assumida como válida.
Agora talvez existam:
logs;
replicações;
mensagens;
processos downstream;
auditoria;
integrações.
A quilometragem já saiu da Ferrari e entrou no ecossistema.
🧠 O sistema pode voltar, o mundo não
Essa é a essência.
Imagine:
um operador envia uma transferência errada.
Depois percebe.
Você pode corrigir o registro.
Mas o dinheiro talvez já tenha saído.
Pode restaurar a tabela.
Mas outro sistema já consumiu o evento.
Pode reverter status.
Mas cliente já recebeu e-mail.
Pode apagar arquivo.
Mas alguém já copiou.
Recuperação técnica não garante recuperação operacional.
🚗 A Ferrari em marcha a ré é rollback sem modelo de consequência
Eles olharam apenas para o indicador:
quilometragem.
Queriam mudar um número.
Mas o evento foi maior.
O carro saiu.
Rodou.
Foi visto.
Foi usado.
Voltou.
A história existiu.
Esse é o erro clássico de sistemas:
confundir estado observável com totalidade do evento.
📜 Logs existem porque história importa
Um bom sistema não registra apenas o estado atual.
Registra também eventos.
Quem alterou.
Quando.
O que era antes.
O que ficou depois.
Isso é fundamental para auditoria e recuperação.
Se você só sabe o estado final, perde contexto.
🧾 Journaling: o diário do sistema
Journaling existe exatamente porque operações importam.
A beleza da cena é que o plano de marcha a ré não apenas falha conceitualmente.
A situação piora dramaticamente.
É quase uma alegoria perfeita de recovery improvisado.
Você tenta corrigir incidente.
Cria outro.
Quem nunca?
💥 “A correção causou indisponibilidade”
Clássico.
Script emergencial.
Configuração errada.
Restore incompleto.
Rollback impossível.
O remédio cria novo problema.
Isso é por que mudança durante incidente precisa de controle.
🧠 Change Management continua existindo em crise
Urgência não elimina risco.
Pode simplificar processo.
Mas não significa:
faça qualquer coisa.
Mudanças emergenciais também precisam de:
registro;
aprovação;
plano de retorno;
validação.
🔁 O plano de rollback precisa existir antes da mudança
Essa frase é fundamental.
Não depois.
Antes.
Toda mudança deveria perguntar:
se falhar, como voltamos?
Se resposta for:
“depois vemos”,
você acabou de criar dívida operacional.
🔵 Blue Team e Operations precisam conversar
Segurança detecta.
Operações recupera.
DBA restaura.
Aplicação valida.
Negócio confirma.
Incidente atravessa times.
Recovery é colaborativo.
🧠 Técnica e negócio precisam concordar sobre “recuperado”
Infra diz:
servidor está online.
DBA:
banco está consistente.
Aplicação:
serviço responde.
Negócio:
clientes ainda estão vendo saldo errado.
Então não recuperou.
📊 Recovery precisa de critérios
Não basta “verde no dashboard”.
Precisamos validar:
integridade;
completude;
reconciliação;
transações;
acessos;
segurança.
Ferrari dentro da garagem não basta.
Precisamos saber se o pai percebeu.
🧾 Reconciliação
Especialmente em sistemas financeiros.
Comparar:
origem;
destino;
totais;
contagens;
valores.
Isso encontra discrepâncias depois de recuperação.
🦖 Db2 + CICS + MQ: recovery coordenado
Em sistemas empresariais, vários componentes interagem.
Db2 atualiza.
CICS coordena.
MQ envia.
Recuperação precisa respeitar consistência entre componentes.
Não adianta um voltar para 10h e outro ficar em 10h30.
🕰️ Time consistency
Esse é um problema real.
Quando múltiplos sistemas têm backups em horários diferentes, restore pode criar mundos paralelos.
Sistema A pensa que evento aconteceu.
Sistema B não.
Agora nasce reconciliação dolorosa.
🔐 Cyber Recovery
Hoje fala-se muito em cyber recovery.
Não apenas recuperar hardware.
Recuperar de ataque.
Isso exige:
ambiente limpo;
cópias confiáveis;
validação;
isolamento;
credenciais novas;
forense.
É muito mais amplo.
🧪 Clean Room
Em certos cenários, você recupera num ambiente isolado.
Valida antes de reconectar.
Porque não quer restaurar malware junto.
Ferrari passa por inspeção antes de voltar para garagem.
🧠 Backup infectado também existe
Se comprometimento aconteceu semanas antes e você não percebeu, backup pode conter persistência.
Então:
qual ponto é realmente limpo?
Logs ajudam.
Forense ajuda.
Não é trivial.
🕵️ Detection latency afeta recovery
Quanto mais tempo atacante fica sem ser detectado, mais difícil saber onde voltar.
Incidente identificado em 5 minutos?
Ótimo.
Depois de 60 dias?
Boa sorte.
📉 MTTD encontra RPO
Mean Time To Detect interfere em recuperação.
Se você demora para detectar corrupção, pode ter backups já contaminados.
Detecção não é só segurança.
É recovery.
🚗 A Ferrari ensina observabilidade
Se Cameron tivesse registro claro de:
quem tirou;
quando;
quanto rodou;
onde;
talvez não tentasse resolver com marcha a ré.
Informação reduz pânico.
🧠 Pânico produz rollback ruim
Em incidente, a primeira vontade é voltar.
Mas recovery precipitado pode destruir evidência.
Antes de apagar:
preserve.
Colete.
Registre.
Depois recupere.
Forense e operação precisam equilibrar.
🔬 Preserve Evidence
Imagem de disco.
Logs.
Memória quando necessário.
Eventos.
Artefatos.
Porque depois do restore talvez você perca pistas.
Ferrari lavada demais perde impressão digital.
🧾 Cadeia de custódia
Em incidentes graves, evidência pode ter valor jurídico.
Quem coletou?
Quando?
Como preservou?
Integridade.
Mais uma vez: história importa.
☕ Produção não possui memória emocional, mas nós possuímos
Sistemas podem voltar.
Pessoas lembram.
Clientes lembram.
Auditores lembram.
Reguladores lembram.
Diretores lembram.
É por isso que incidentes têm efeitos duradouros.
🎬 Ferris tentou resolver um problema técnico que já era humano
A quilometragem era um indicador.
O verdadeiro problema era:
Cameron havia quebrado confiança com o pai.
Não existe rollback técnico para isso.
A cena é genial justamente porque mostra limite da reversibilidade.
🧠 Segurança também lida com confiança
Depois de vazamento:
usuários mudam comportamento.
Clientes questionam.
Parceiros exigem garantias.
Você pode restaurar sistema em duas horas.
Reputação pode levar anos.
Esse é o Ctrl+Z emocional que não existe.
🔴 O objetivo não é voltar no tempo
Essa é talvez a conclusão mais madura.
Recovery não é viagem temporal.
É construir um estado novo e confiável depois de algo ruim.
Você não apaga incidente.
Você aprende.
Corrige.
Recupera.
Monitora.
Segue.
🔁 Recovery como transição, não reversão
Pense:
NORMAL
↓
INCIDENT
↓
CONTAINMENT
↓
RECOVERY
↓
NEW TRUSTED STATE
Não voltamos exatamente ao começo.
Voltamos melhores.
Ou deveríamos.
☕ A pergunta final Bellacosa
Quando alguém disser:
— Dá para dar rollback?
Pergunte:
“Rollback de quê?”
Do banco?
Do arquivo?
Da aplicação?
Do pagamento?
Da mensagem?
Da confiança?
Do vazamento?
Essa pergunta salva reuniões.
🎬 Epílogo: marcha a ré não apaga estrada
A Ferrari anda para frente.
Depois anda para trás.
Mas a estrada continua existindo.
Esse é o ponto.
Sistemas guardam estado.
Negócios acumulam consequências.
Pessoas acumulam memória.
Red Team precisa pensar nisso porque ataque não termina no acesso inicial.
Importa também:
o que pode ser revertido;
o que pode ser restaurado;
o que pode ser compensado;
o que é irreversível.
Backup é essencial.
Restore é capacidade.
Rollback é mecanismo.
Journaling é memória.
Logs são história.
Recovery é processo.
E resposta a incidente é o momento em que tudo isso precisa funcionar junto.
Então, da próxima vez que alguém sugerir:
“É só voltar.”
Coloque a xícara na mesa.
Olhe para a equipe.
E responda:
“Produção não possui Ctrl+Z emocional.”
Porque às vezes você consegue colocar a Ferrari em marcha a ré.
Mas não consegue fazer o mundo esquecer que ela saiu da garagem.
☕ SAVE FERRIS.
No próximo artigo:
Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente
Porque depois de errar o rollback...
nada melhor do que deixar o defensor destruir o ambiente tentando provar que estava certo.
☕ 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
1
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
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
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
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.
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.
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.
“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
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.
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.
SP 065: Viajando sem visibilidade com muita nevoa na estrada
Neblina na região de Nazaré Paulista.
Nossa viagem iniciou-se antes do nascer do sol, estamos na rodovia Dom Pedro rumo a Ubatuba, uma longa viagem passaremos por diversas cidades em nossa viagem.
O tempo esta fechado com um pouco de chuva pelo caminho, até chegarmos em Nazaré Paulista onde fomos pegos por uma neblina que dificultava em muito a direção, o que torna nossa viagem mais emocionante e diferente do comum.
Diminuímos a nossa velocidade e seguimos rumo a Jacareí, onde iremos pegar mais estradas, o Formiga esta elétrico, tagarela e atento a viagem, vamos conversando e aproveitando os primeiros raios solares que lutam para passar por entre a nevoa.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
