☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

quinta-feira, 5 de janeiro de 2023

Goblin Slayer — Parte I Quando um Programador COBOL Descobre que o Verdadeiro Herói Nunca Salvou o Mundo... Apenas Impediu que Ele Desmoronasse Todos os Dias

 

Bellacosa Mainframe apresenta Goblin Slayer parte I

☕ Um Café no Bellacosa Mainframe

Goblin Slayer sem Mistérios — Parte I

Quando um Programador COBOL Descobre que o Verdadeiro Herói Nunca Salvou o Mundo... Apenas Impediu que Ele Desmoronasse Todos os Dias

"Os grandes bardos cantam sobre quem derrotou o Rei Demônio. Poucos escrevem uma única linha sobre o homem que impediu milhares de aldeias de desaparecerem antes mesmo que o Rei Demônio soubesse da existência delas."




Introdução — A Fantasia que Recusou Ser Fantástica

Existe um momento curioso na vida de praticamente todo fã de fantasia.

Você começa assistindo histórias onde os heróis recebem espadas mágicas.

Depois aparecem armaduras lendárias.

Magias proibidas.

Dragões ancestrais.

Profecias.

Reencarnações.

Escolhidos pelos deuses.

Reis demônios.

E então, depois de centenas de obras, você percebe que todas contam praticamente a mesma história.

Foi exatamente nesse cenário que surgiu uma pequena obra escrita por um autor praticamente desconhecido.

Sem protagonistas overpower.

Sem harém.

Sem protagonista reencarnado.

Sem sistema de níveis absurdos.

Sem "eu derrotei um deus no episódio 12".

Apenas um homem.

Uma espada.

Uma armadura velha.

Um escudo.

Um capacete que nunca revela seu rosto.

E uma única missão.

Matar goblins.

A maioria das pessoas olhou para isso e pensou:

"É só isso?"

A resposta era:

Não. Era exatamente o contrário.

Goblin Slayer nunca foi uma história sobre goblins.

Era uma história sobre pessoas.

Sobre trauma.

Sobre responsabilidade.

Sobre trabalho invisível.

Sobre o preço de continuar vivendo.

E talvez seja justamente por isso que tantos profissionais experientes — médicos, bombeiros, militares, policiais, engenheiros, administradores de sistemas e até programadores COBOL — enxergam muito mais nessa obra do que simples batalhas medievais.

Porque eles sabem uma verdade incômoda.

O mundo não continua funcionando graças aos heróis.

Continua funcionando graças às pessoas que fazem, silenciosamente, o trabalho que ninguém quer fazer.


Bellacosa Mainframe apresenta GOBLIN SLAYER

Um Café no Bellacosa Mainframe

Imagine a cena.

Você acabou de terminar um batch gigantesco às três da manhã.

O processamento fechou.

Nenhum ABEND.

Nenhum S0C7.

Nenhum banco ficou indisponível.

O jornal do dia seguinte não falará de você.

O presidente do banco jamais saberá seu nome.

Os clientes jamais imaginarão que centenas de milhões de transações dependeram do seu trabalho.

Porque tudo funcionou.

Agora imagine outro profissional.

Ele entra numa caverna.

Mata vinte goblins.

Salva uma aldeia inteira.

Ninguém escreve uma música sobre isso.

Ninguém ergue uma estátua.

A Guilda apenas responde:

— "Obrigado. Próxima missão."

Essa é exatamente a vida de Goblin Slayer.

E talvez por isso tantos profissionais adultos tenham se identificado imediatamente com ele.


Bellacosa Mainframe apresenta o matador de goblins GOBLIN SLAYER

Antes de Goblin Slayer

Para compreender o impacto dessa obra precisamos voltar algumas décadas.

Muito antes de isekais.

Muito antes de MMORPGs.

Muito antes de Sword Art Online.

Muito antes de Overlord.

Muito antes de Mushoku Tensei.

Na década de 1970 acontecia algo revolucionário.

Nos Estados Unidos, Gary Gygax e Dave Arneson criavam um jogo chamado:

Dungeons & Dragons (1974).

Pela primeira vez, fantasia deixava de ser apenas literatura.

Ela passava a ser vivida.

Os jogadores criavam:

  • guerreiros

  • magos

  • sacerdotes

  • ladrões

  • elfos

  • anões

Entravam em masmorras.

Recebiam missões.

Exploravam cavernas.

Rolavam dados.

Morriam.

Criavam novos personagens.

Esse conceito atravessaria o oceano.


A chegada ao Japão

Nos anos 1980, o Japão apaixonou-se por RPG de mesa.

Surgiram adaptações locais.

Entre elas:

  • Sword World RPG (1989)

  • Lodoss

  • RuneQuest traduzido

  • Advanced Dungeons & Dragons

Foi nesse ambiente que cresceu uma geração inteira de escritores.

Eles aprenderam algo interessante.

Nas campanhas de RPG, os personagens raramente eram chamados pelo nome.

Eram chamados por suas classes.

"O Guerreiro."

"A Sacerdotisa."

"O Anão."

"O Mago."

Anos depois...

Goblin Slayer faria exatamente isso.

Observe.

Quase ninguém possui nome verdadeiro.

Temos:

  • Goblin Slayer

  • Priestess

  • High Elf Archer

  • Dwarf Shaman

  • Lizard Priest

  • Guild Girl

  • Cow Girl

  • Sword Maiden

Isso não é coincidência.

É uma homenagem direta às mesas de RPG.


Quem é Kumo Kagyu?

Curiosamente...

Sabemos muito pouco sobre ele.

Kumo Kagyu prefere permanecer longe dos holofotes.

Não existe uma biografia gigantesca.

Não há entrevistas semanais.

Não há exposição constante.

Isso acabou aumentando ainda mais o mistério em torno do autor.

Sabe-se, entretanto, que ele sempre foi apaixonado por RPGs de mesa.

E isso aparece em praticamente todas as páginas da obra.

Os deuses lançando dados.

As classes.

As missões.

As guildas.

As recompensas.

As aventuras.

As dungeons.

Tudo parece uma campanha conduzida por um excelente Mestre de Jogo.


A origem da obra

A cronologia da franquia é fascinante.

Tudo começou de maneira extremamente modesta.

2013–2015

Kumo Kagyu publica Goblin Slayer como Web Novel.

Na época, dezenas de autores japoneses utilizavam plataformas online para testar histórias antes de buscar uma editora.

Foi exatamente assim que nasceram também obras como:

  • Overlord

  • Mushoku Tensei

  • Re:Zero

  • The Rising of the Shield Hero

O mercado editorial japonês começava a perceber algo importante.

A internet havia se tornado o novo laboratório para descobrir talentos.


15 de fevereiro de 2016

Surge oficialmente a primeira Light Novel de Goblin Slayer.

Ilustrada por Noboru Kannatsuki, a obra chega às livrarias japonesas.

Ninguém imaginava que aquele pequeno livro se transformaria em uma das franquias mais debatidas da década.


Maio de 2016

O sucesso inicial leva rapidamente ao mangá.

Em 25 de maio de 2016, começa a serialização da adaptação ilustrada por Kōsuke Kurose.

Era o passo natural.

Mas havia um detalhe curioso.

Muitos leitores que não tinham lido a novel ficaram chocados.

O mangá era muito mais pesado do que imaginavam.

A violência não era gratuita.

Ela tinha função narrativa.


O crescimento silencioso

Enquanto outros títulos explodiam em vendas graças ao humor ou ao fan service, Goblin Slayer crescia de maneira diferente.

Cada novo leitor indicava para outro.

As discussões apareciam em fóruns.

Os vídeos no YouTube aumentavam.

As análises multiplicavam-se.

Era um sucesso construído quase artesanalmente.

Sem campanhas milionárias.

Sem marketing agressivo.

Apenas pelo boca a boca.


2017 — O Passado do Caçador

Em 15 de setembro de 2017, surge Goblin Slayer: Year One.

Para muitos fãs, trata-se da melhor obra paralela de toda a franquia.

Ali descobrimos algo que o anime apenas sugere.

Goblin Slayer não nasceu um especialista.

Ele errou.

Fracassou.

Foi derrotado.

Aprendeu.

Improvisou.

Sobreviveu.

Cada cicatriz possui uma história.

Cada equipamento possui um motivo.

Cada decisão foi construída lentamente.

É quase como assistir ao treinamento de Bruce Wayne antes de se tornar Batman.


A explosão de 2018

O ano de 2018 muda completamente a história da franquia.

Primeiro surge Year One em formato de Light Novel.

Depois aparece Brand New Day, mostrando aventuras paralelas e momentos cotidianos da Guilda.

E então chega outubro.


7 de outubro de 2018

Estreia o anime produzido pelo estúdio White Fox.

Doze episódios.

Uma abertura memorável.

Uma trilha sonora excelente.

Uma direção extremamente competente.

Mas ninguém imaginava o que aconteceria nas primeiras horas após sua exibição.


O episódio que abalou a internet

O primeiro episódio tornou-se imediatamente um dos mais comentados da história recente dos animes.

Redes sociais explodiram.

Fóruns entraram em guerra.

Críticos dividiram-se completamente.

Uns afirmavam:

"Isso passou dos limites."

Outros respondiam:

"Finalmente alguém mostrou que monstros realmente são monstros."

Independentemente da opinião, uma coisa tornou-se inegável.

Todo mundo passou a falar sobre Goblin Slayer.

O anime havia conseguido algo raríssimo.

Ser impossível de ignorar.


A desconstrução do goblin

Durante décadas, os goblins ocuparam um papel quase cômico na fantasia.

Em muitos jogos eles eram o equivalente ao "inimigo de tutorial".

Criaturas pequenas.

Desorganizadas.

Fracas.

Quase descartáveis.

Goblin Slayer destrói completamente essa ideia.

Aqui, goblins não são apenas monstros.

São uma ameaça biológica, militar e psicológica.

Eles observam.

Aprendem.

Adaptam-se.

Criam armadilhas.

Atacam onde há menos defesa.

Exploram o medo.

Usam táticas de guerrilha.

Jamais enfrentam um exército quando podem eliminar uma aldeia isolada.

A pergunta muda completamente.

Não é mais:

"Quantos goblins existem?"

Mas sim:

"Quantos sobreviveram para aprender com a última batalha?"


O mundo além do Rei Demônio

Outro aspecto brilhante da obra é aquilo que ela escolhe não mostrar.

Existe um Rei Demônio.

Existem heróis lendários.

Existem batalhas épicas acontecendo em algum lugar.

Mas Goblin Slayer quase nunca participa delas.

Por quê?

Porque Kumo Kagyu inverteu a câmera.

Enquanto quase toda fantasia acompanha o general, Goblin Slayer acompanha o soldado.

Enquanto todos observam a guerra, ele observa a patrulha.

Enquanto os bardos cantam a vitória dos grandes heróis, ele entra em uma caverna escura para impedir que uma pequena tragédia aconteça.

Essa mudança de foco transforma completamente a experiência do leitor.


O primeiro grande ensinamento

Talvez a maior lição da primeira fase de Goblin Slayer seja incrivelmente simples.

Nunca despreze um problema apenas porque ele parece pequeno.

Goblin Slayer sabe que uma única tribo ignorada hoje pode transformar-se em centenas de goblins amanhã.

Esse princípio vale para quase tudo.

Na segurança da informação, uma senha esquecida.

Na medicina, um sintoma aparentemente banal.

Na engenharia, uma pequena fissura.

No mundo do mainframe, um warning ignorado durante semanas.

Os grandes desastres raramente começam grandes.

Eles começam pequenos.

Muito pequenos.

Pequenos o suficiente para que alguém diga:

"Depois eu vejo isso."

Goblin Slayer jamais diria essa frase.

E talvez seja exatamente essa mentalidade que o aproxima tanto de um bom administrador de sistemas ou de um programador COBOL experiente: ambos entendem que a estabilidade do mundo depende de resolver problemas aparentemente insignificantes antes que eles se transformem em catástrofes.


Continuação...

Na Parte II, entraremos no coração da obra: analisaremos Goblin Slayer como personagem, seu trauma, a psicologia por trás de sua obsessão, a construção dos companheiros de aventura, a filosofia do dever, a moral da história e por que esse "caçador de goblins" acabou se tornando um dos protagonistas mais humanos e memoráveis da fantasia japonesa contemporânea.

Um Café no Bellacosa Mainframe

ARQUIVOS DA GUILDA • CLASSIFICAÇÃO: DARK FANTASY

Goblin Slayer sem Mistérios

O Guia Definitivo da Série Completa

Uma jornada por cronologia, psicologia, biologia, estratégia, engenharia militar, referências culturais, simbolismos e os segredos escondidos de Goblin Slayer.

“Quando um Programador COBOL Descobre que Grandes Obras Também Precisam de um Mapa para Não se Perder na Dungeon.”
Explorar a série
RELATÓRIO DE MISSÃO

Uma série construída como uma campanha de RPG

Goblin Slayer sem Mistérios é uma coleção especial do Bellacosa Mainframe dedicada à análise profunda da obra criada por Kumo Kagyu. Cada capítulo investiga uma camada diferente da franquia, relacionando fantasia sombria, RPG de mesa, estratégia, trauma, sobrevivência, engenharia militar e arquitetura de sistemas.

A coleção foi organizada em ordem cronológica para facilitar a leitura. Você pode começar pela Parte I, seguir capítulo após capítulo ou utilizar os filtros para selecionar assuntos como psicologia, goblins, táticas, história da franquia e cultura otaku.

Todos os títulos abaixo são links HTML reais e permanecem acessíveis mesmo quando o JavaScript estiver desativado. Isso facilita a navegação dos leitores e a descoberta das páginas por mecanismos de busca.

Progresso da campanha 0 de 14 missões visitadas
14 capítulos encontrados
I
Introdução

Goblin Slayer sem Mistérios — Parte I

O ponto de entrada da campanha. Uma análise sobre o herói invisível que não salva o mundo em uma única batalha, mas impede silenciosamente que ele desmorone todos os dias.

Heroísmo Disciplina Mainframe
II
Disciplina

Goblin Slayer sem Mistérios — Parte II

O verdadeiro poder não está na espada, mas na constância de levantar, preparar os equipamentos e executar diariamente o trabalho que quase ninguém deseja assumir.

Rotina Dever Persistência
III
Missão crítica

Goblin Slayer sem Mistérios — Parte III

Nem todo herói enfrenta o Rei Demônio. Alguns garantem que na segunda-feira existirão sistema, salários, luz e uma aldeia inteira ainda de pé.

Disponibilidade Proteção Responsabilidade
IV
Arquitetura

Parte IV — O Arquiteto Invisível de Goblin Slayer

Uma reflexão sobre profissionais que projetam soluções, previnem desastres e permanecem atrás do terminal enquanto o restante do mundo apenas percebe que tudo continua funcionando.

Arquitetura COBOL Prevenção
V
Cronologia

Parte V — A Evolução Cronológica Completa da Franquia

Da publicação original às light novels, mangás, adaptações, spin-offs, filme e temporadas do anime: a evolução de uma história que cresceu release após release.

Web Novel Light Novel Anime
VI
Biologia

Parte VI — A Biologia dos Goblins

Anatomia, comportamento, adaptação, hierarquia e ecologia dos goblins analisados como uma espécie invasora capaz de explorar brechas e evoluir rapidamente.

Ecologia Adaptação Worldbuilding
VII
Referências

Parte VII — As Referências Escondidas de Goblin Slayer

Conan, Berserk, Tolkien, Dungeons & Dragons, Sword World RPG, literatura fantástica, mitologia e cultura pop escondidos entre as linhas da obra de Kumo Kagyu.

RPG Literatura Cultura pop
VIII
Psicologia

Parte VIII — A Psicologia Profunda de Goblin Slayer

Trauma, hipervigilância, isolamento, necessidade de controle, resiliência e reconstrução emocional por meio das relações que lentamente devolvem humanidade ao protagonista.

Trauma Memória Resiliência
IX
Engenharia militar

Parte IX — A Engenharia Militar de Goblin Slayer

Reconhecimento, suprimentos, redundância, controle do terreno, fortificação, retirada e arquitetura operacional transformam batalhas perigosas em vitórias planejadas.

Logística Terreno Contingência
X
Estratégia

Parte X — A Estratégia de Goblin Slayer

Uma análise sobre informação, iniciativa, especialização, probabilidades, redundância e a capacidade de pensar diversos movimentos à frente do adversário.

Planejamento Inteligência Antecipação
XI
100 segredos

Parte XI — Os 100 Segredos de Goblin Slayer

Cem detalhes sobre personagens, mundo, goblins, equipamentos, narrativa, simbolismos, RPG, produção, psicologia e estratégia que podem passar despercebidos até pelos fãs.

Easter eggs Simbolismos Curiosidades
XII
Guia completo

Parte XII — Goblin Slayer sem Mistérios

O mapa da campanha: introdução, sequência recomendada, resumo dos capítulos e orientação para explorar todas as camadas da coleção sem se perder na dungeon.

Índice Mapa Ordem de leitura
FINAL
Síntese definitiva

Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy

A conclusão da jornada, reunindo cronologia, psicologia, estratégia, engenharia militar, simbolismos, referências culturais, construção de mundo e impacto na cultura otaku.

Dark Fantasy Síntese Conclusão
BÔNUS
Dossiê militar

A Composição do Exército Goblin em The Fate of an Adventurer

Rei Goblin, estado-maior, Champions, Shamans, arqueiros, infantaria, Riders, logística e cadeia de comando analisados como componentes de uma força militar organizada.

Exército Goblin Hierarquia Ordem de batalha
ROTA RECOMENDADA

Como percorrer esta dungeon

Comece pelas três primeiras partes para compreender a proposta da série. Depois visite o Arquiteto Invisível, conheça a evolução da franquia e aprofunde-se em biologia, referências, psicologia, engenharia militar e estratégia.

  1. 01 Fundamentos do herói invisível
  2. 02 História e evolução da franquia
  3. 03 Biologia e organização dos goblins
  4. 04 Psicologia e simbolismos
  5. 05 Engenharia militar e estratégia
  6. 06 Segredos, guia completo e síntese final
Bellacosa Mainframe Dark Fantasy • Anime • RPG • COBOL • Estratégia

“A vitória não é improviso. É arquitetura.”

quarta-feira, 4 de janeiro de 2023

Capítulo I — Vocabulário e Fundamentos da Cibersegurança

 


☕ Um Café no Bellacosa Mainframe

Capítulo I — Vocabulário e Fundamentos da Cibersegurança

Ou: o Agente 86 recebeu a missão de proteger o datacenter, entrou pela porta blindada usando o telefone-sapato — e descobriu que Igor havia publicado a senha do RACF em Base64 porque “agora ninguém consegue ler”



Prólogo — A porta secreta que não era tão secreta

— 86, temos uma emergência — disse o Chefe, fechando cuidadosamente as persianas do escritório.

— A KAOS invadiu o datacenter?

— Pior. Igor fez um curso de quinze páginas sobre cibersegurança e declarou o ambiente completamente protegido.

— Isso parece ótimo, Chefe.

— Ele instalou um firewall, colocou a senha em Base64 e desativou os logs para que os atacantes não soubessem o que estávamos fazendo.

— Ah. Nesse caso, estamos mortos.

Para quem começa em COBOL, cibersegurança às vezes parece um continente descoberto recentemente: cheio de siglas, especialistas vestidos de preto e diagramas onde uma caveira atravessa uma nuvem até alcançar um servidor. Mas o programador mainframe já vive dentro desse assunto há décadas, mesmo quando ninguém usava os nomes atuais.

Quando você protege um dataset com RACF, verifica um return code, impede que um programa atualize uma conta sem autorização, registra uma operação no SMF, faz COMMIT ou ROLLBACK, separa desenvolvimento de produção e limita o acesso de uma transação CICS, você está praticando segurança.

O problema começa quando confundimos ferramentas com segurança. Firewall não é segurança completa. Criptografia não é segurança completa. MFA não é segurança completa. Antivírus, WAF, SIEM, RACF e auditoria são componentes de um sistema maior.

Segurança é a capacidade de conhecer o que precisa ser protegido, reduzir a possibilidade de dano, detectar quando algo saiu do esperado, responder com disciplina e restaurar o serviço sem transformar o incidente num festival de improvisos.

Pegue seu café. O Agente 86 já está descendo para a sala de controle — infelizmente pelo elevador errado.



1. Cibersegurança não é apenas impedir hackers

Uma definição introdutória diz que cibersegurança é a prática de proteger sistemas, redes, programas e dados contra ataques, danos ou acessos não autorizados. Está correta, mas descreve apenas a fachada do prédio.

Na vida real, cibersegurança envolve pessoas, processos, tecnologia e decisões de negócio. Inclui:

  • descobrir quais ativos existem;

  • compreender quais deles são críticos;

  • identificar ameaças e vulnerabilidades;

  • administrar identidades e privilégios;

  • desenvolver software seguro;

  • monitorar o ambiente;

  • responder a incidentes;

  • recuperar dados e serviços;

  • atender leis e contratos;

  • preservar evidências;

  • aprender com cada falha.

O NIST Cybersecurity Framework 2.0 organiza essa jornada em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar.

Repare no verbo “Governar”. Antes de comprar uma ferramenta, alguém precisa definir responsabilidades, apetite de risco, prioridades, recursos e critérios de decisão. Se um scanner encontra vinte mil vulnerabilidades e ninguém sabe quais sistemas processam folha de pagamento, cartão ou PIX, temos dados, mas não temos governo.

No IBM Z, isso pode ser traduzido assim:

  • Governar: definir proprietários, políticas, segregação de funções e risco aceitável.

  • Identificar: inventariar LPARs, aplicações, started tasks, usuários, datasets, filas MQ, APIs, certificados e dependências.

  • Proteger: usar RACF, criptografia, hardening, MFA, menor privilégio e programação segura.

  • Detectar: coletar SMF, logs de CICS, Db2, z/OSMF, USS, rede e ferramentas de segurança.

  • Responder: bloquear credenciais, conter o incidente, preservar evidências e comunicar responsáveis.

  • Recuperar: restaurar dados confiáveis, validar integridade e retomar os serviços na ordem correta.

As funções não formam uma fila de batch na qual uma só começa quando a anterior termina. Governar, identificar, proteger e detectar são atividades contínuas; resposta e recuperação precisam estar prontas antes do incidente.

Curiosidade de corredor: o melhor plano de resposta não é aquele que está num PDF de 180 páginas. É aquele que a equipe consegue encontrar e executar enquanto o telefone toca, o diretor pergunta quando o sistema volta e o Agente 86 está preso dentro da cabine telefônica.




2. A tríade CIA — o triângulo que sustenta o castelo

O primeiro mapa mental da segurança é a tríade CIA:

  • Confidentiality — Confidencialidade;

  • Integrity — Integridade;

  • Availability — Disponibilidade.

Não confunda CIA com a agência americana. O Agente 86 já confundiu e passou quarenta minutos tentando apresentar credenciais ao triângulo.

2.1 Confidencialidade

Confidencialidade significa que a informação só pode ser acessada por pessoas, sistemas ou processos autorizados.

Exemplos:

  • um cliente vê apenas suas próprias contas;

  • um operador acessa os comandos necessários, mas não toda a administração do sistema;

  • uma aplicação CICS lê somente os recursos indispensáveis;

  • uma cópia de produção usada em testes tem dados mascarados;

  • backups, dumps e logs recebem proteção equivalente à informação original.

Criptografia ajuda a preservar confidencialidade, mas não resolve tudo. Um banco de dados perfeitamente criptografado pode ser exposto por uma aplicação autenticada que execute SELECT * FROM CLIENTES e entregue o resultado ao usuário errado.

Confidencialidade depende também de autorização, classificação, minimização, mascaramento, segregação, descarte seguro e proteção das chaves.

2.2 Integridade

Integridade significa preservar correção, completude, consistência e origem confiável.

É comum imaginar um invasor alterando saldos, mas a integridade também pode ser perdida por:

  • erro de programação;

  • campo truncado;

  • processamento duplicado;

  • mensagem MQ consumida duas vezes;

  • restauração de backup antigo;

  • atualização parcial;

  • regra de negócio incorreta;

  • falha de sincronização.

Considere este trecho didático:

COMPUTE WS-NOVO-SALDO =
        WS-SALDO-ATUAL - WS-VALOR-TRANSFERENCIA

Se WS-VALOR-TRANSFERENCIA aceitar valor negativo, subtrair -100 adicionará 100 ao saldo. O programa compilou. O RACF autorizou. O banco estava disponível. Mesmo assim, a integridade foi destruída porque a regra de domínio não foi validada.

Integridade não significa apenas “o arquivo não mudou”. Significa que as mudanças foram corretas, completas, autorizadas e rastreáveis.

2.3 Disponibilidade

Disponibilidade é a capacidade de acessar informação e serviços quando a missão exige.

Não basta a tela responder ao PING. Se uma autorização de cartão leva três minutos, o serviço está tecnicamente vivo e operacionalmente morto.

Disponibilidade envolve:

  • redundância;

  • capacidade;

  • proteção contra DDoS;

  • manutenção;

  • monitoração;

  • backup;

  • recuperação de desastre;

  • tolerância a falhas;

  • operação degradada segura.

Duas siglas são fundamentais:

  • RTO: tempo máximo aceitável para restaurar o serviço;

  • RPO: quantidade máxima aceitável de dados perdidos, normalmente expressa em tempo.

Se o RTO é duas horas, não adianta descobrir durante o desastre que restaurar o ambiente exige nove. Se o RPO é zero, a arquitetura precisa tratar replicação e consistência de forma muito diferente daquela que admite perder uma hora.

2.4 O que existe além da CIA?

A tríade é a fundação, não o edifício inteiro. Também precisamos considerar:

  • autenticidade;

  • responsabilização;

  • rastreabilidade;

  • privacidade;

  • não repúdio;

  • resiliência;

  • segurança física;

  • segurança humana.

Uma assinatura digital pode ajudar a demonstrar origem e integridade, mas o não repúdio depende também de identidade verificada, custódia da chave, timestamp, auditoria e processo jurídico. Igor assinar um arquivo com uma chave privada encontrada num diretório público não cria prova celestial de autoria.



3. Ativo, ameaça, vulnerabilidade, exposição e risco

Essas palavras são frequentemente misturadas até virarem uma sopa de siglas. Vamos separá-las.

Ativo

É algo que possui valor: dinheiro, informação, sistema, reputação, credencial, certificado, serviço, conhecimento ou capacidade operacional.

Um job crítico, uma chave criptográfica e a confiança do cliente são ativos, embora não tenham a mesma forma.

Ameaça

É uma circunstância capaz de causar dano.

Pode ser:

  • criminoso;

  • funcionário mal-intencionado;

  • usuário enganado;

  • incêndio;

  • falha elétrica;

  • erro humano;

  • fornecedor comprometido;

  • ransomware;

  • bug destrutivo.

Ameaça não é sinônimo de hacker. Uma enchente não possui endereço IP e ainda assim pode derrubar o datacenter.

Vulnerabilidade

É uma fraqueza que pode ser explorada ou acionada:

  • SQL construído por concatenação;

  • senha reutilizada;

  • software desatualizado;

  • conta órfã;

  • porta administrativa exposta;

  • excesso de privilégios;

  • ausência de segregação de funções;

  • procedimento de recuperação nunca testado.

Exposição

É a condição que coloca o ativo ao alcance da ameaça. Um servidor vulnerável desligado e isolado possui vulnerabilidade, mas exposição pequena. O mesmo servidor publicado na Internet possui outro nível de risco.

Controle

É uma medida que reduz probabilidade ou impacto:

  • MFA;

  • firewall;

  • validação;

  • revisão de código;

  • limite transacional;

  • segmentação;

  • monitoração;

  • backup imutável.

Risco

Uma fórmula didática é:

Risco ≈ Probabilidade × Impacto

Mas risco não é uma multiplicação divina capaz de produzir a verdade com duas casas decimais. Precisamos avaliar valor do ativo, exposição, capacidade do adversário, controles existentes, detectabilidade, impacto operacional, jurídico e reputacional.

Uma vulnerabilidade CVSS 9.8 numa biblioteca não é automaticamente o maior risco da empresa. Pergunte:

  1. O componente vulnerável é realmente utilizado?

  2. Está exposto?

  3. Existe exploração conhecida?

  4. A exploração exige autenticação?

  5. Com qual privilégio o processo roda?

  6. Que dados podem ser alcançados?

  7. Existem controles compensatórios?

  8. Qual seria o impacto para o negócio?

Dica do Agente 86: nunca permita que um número substitua a investigação. O placar mostra onde olhar; não conta sozinho toda a história.



4. Malware — o zoológico dentro do telefone-sapato

Malware é software criado ou utilizado para executar ações maliciosas. As categorias ajudam a estudar, mas uma única amostra pode possuir várias capacidades.

Vírus

Anexa-se a arquivo ou programa e normalmente depende da execução para se espalhar. É o passageiro clandestino.

Worm

Propaga-se automaticamente por redes ou serviços. Se o vírus pede carona, o worm possui pernas e conhece os horários dos trens.

Trojan

Parece legítimo, mas carrega função maliciosa. “Trojan” descreve principalmente o disfarce ou forma de entrada, não todas as ações posteriores.

Ransomware

Bloqueia, criptografa ou destrói acesso e exige pagamento. Operações modernas podem combinar roubo de dados, ameaça de publicação, destruição de backup e pressão sobre clientes.

Restaurar o backup pode recuperar a disponibilidade, mas não devolve a confidencialidade dos dados já roubados.

Spyware e keylogger

Monitoram comportamento e coletam dados. Um keylogger pode capturar senhas, códigos, conversas e dados financeiros.

Rootkit

Oculta presença e ajuda a preservar acesso privilegiado. Atua na persistência e evasão.

Botnet

Botnet não é exatamente uma espécie isolada de malware; é uma rede de dispositivos comprometidos sob comando. Pode ser usada para DDoS, spam, fraude, mineração ou distribuição de novas cargas.

Insider threat

Também não é malware. Pode ser o funcionário malicioso, negligente, coagido, enganado, o ex-funcionário ainda habilitado ou uma conta legítima tomada por criminosos.

No mainframe, o invasor mais perigoso pode não precisar quebrar o RACF. Ele pode utilizar uma identidade autorizada para executar uma finalidade não autorizada.


5. Engenharia social — a vulnerabilidade usa crachá

Phishing não explora apenas ignorância. Explora características humanas normais:

  • autoridade;

  • urgência;

  • medo;

  • curiosidade;

  • escassez;

  • desejo de ajudar;

  • fadiga;

  • hábito.

As principais formas incluem phishing genérico, spear phishing direcionado, whaling contra executivos, smishing por SMS, vishing por voz, pretexting com história falsa, baiting por isca e quid pro quo por troca de favores.

Exemplo:

“Aqui é o suporte antifraude. Recebemos uma tentativa suspeita. Informe o código que acabou de chegar para bloquearmos a operação.”

O código é verdadeiro. O contexto é falso.

Treinamento é necessário, mas não pode ser a única barreira. O sistema deve supor que alguém eventualmente clicará. Use:

  • MFA resistente a phishing;

  • aprovação dupla;

  • limites transacionais;

  • filtragem de mensagens;

  • privilégio mínimo;

  • detecção comportamental;

  • confirmação fora de banda;

  • canal simples para denúncia.

Quando a organização culpa exclusivamente o usuário, ela transforma “defesa em profundidade” em “culpa em profundidade”.


6. O ataque não segue um fluxograma obediente

O modelo introdutório apresenta reconhecimento, varredura, exploração, manutenção de acesso e impacto. É útil, mas ataques reais voltam etapas, mudam de rota e frequentemente usam credenciais legítimas.

Uma campanha pode incluir:

  1. pesquisa sobre funcionários e fornecedores;

  2. criação de domínio parecido;

  3. phishing direcionado;

  4. roubo de sessão;

  5. acesso inicial;

  6. descoberta do ambiente;

  7. roubo de credenciais;

  8. escalada de privilégio;

  9. persistência;

  10. movimento lateral;

  11. coleta;

  12. exfiltração;

  13. impacto.

O ransomware que aparece no final pode ser apenas a sirene. O roubo silencioso aconteceu semanas antes.

Easter egg para os antigos: no Agente 86, as portas automáticas fechavam atrás do herói criando a ilusão de segurança perfeita. Na cibersegurança, isso se chama perímetro. O problema é descobrir quem já estava dentro antes de a última porta fechar.


7. Segurança de rede — a DMZ não é uma zona mágica

O desenho clássico é:

Internet → firewall → DMZ → firewall interno → aplicação → banco

É uma boa introdução à defesa em profundidade, mas uma arquitetura moderna pode conter CDN, proteção DDoS, WAF, API gateway, balanceador, serviços, filas, identidade, armazenamento, SIEM e serviços em nuvem.

Firewall

Controla fluxos conforme regras, mas não entende necessariamente fraude ou regra de negócio. Uma porta 443 permitida pode transportar um ataque perfeitamente protegido por TLS.

O cadeado garante que a conversa foi criptografada; não garante que um dos participantes seja honesto.

IDS e IPS

  • IDS detecta e alerta.

  • IPS pode intervir e bloquear.

Na prática, ferramentas podem combinar funções. Mais importante: alerta sem investigação é apenas uma mensagem de socorro guardada para auditoria.

Proxy, reverse proxy, WAF e gateway

“Proxy” é uma família:

  • forward proxy representa clientes;

  • reverse proxy representa servidores;

  • WAF analisa tráfego de aplicação web;

  • API gateway autentica, limita e roteia chamadas.

Nenhum deles corrige automaticamente código inseguro.

VPN

VPN protege o canal, não purifica o endpoint. Um notebook comprometido pode transformar a VPN numa ponte criptografada para o invasor.

Segmentação

Segmentação reduz movimento lateral e raio de explosão. VLAN sem política aplicada e monitorada é apenas organização de rede.

Pergunte a cada fluxo:

  • quem chama?

  • usando qual identidade?

  • por qual protocolo?

  • para qual finalidade?

  • com qual privilégio?

  • como será auditado?

  • o que acontece quando falha?


8. Identificação, autenticação, autorização e auditoria

Essas quatro etapas precisam ser separadas.

Identificação

“Sou o usuário MAXWELL86.”

Autenticação

“Consigo provar que sou MAXWELL86.”

Autorização

“MAXWELL86 pode executar esta ação neste recurso?”

Accountability

“Conseguimos reconstruir quem fez o quê, quando, de onde e com qual resultado?”

No RACF:

  • o USERID declara a identidade;

  • senha, certificado, PassTicket ou MFA ajudam a autenticar;

  • perfis, grupos e níveis de acesso determinam autorização;

  • SMF e outros registros fornecem evidências.

MFA

Os fatores clássicos são:

  • algo que você sabe;

  • algo que você possui;

  • algo que você é.

Senha mais PIN não é MFA verdadeiro: ambos são conhecimento. Senha mais pergunta secreta também não.

Códigos digitáveis acrescentam proteção, mas podem ser capturados por phishing. Para acessos sensíveis, mecanismos criptográficos resistentes a phishing são preferíveis.

Senhas

A velha receita “oito caracteres, maiúscula, número, símbolo e troca a cada 30 dias” produziu monstruosidades previsíveis como Agosto@2026!.

As diretrizes modernas favorecem:

  • comprimento;

  • blocklist de senhas comuns ou vazadas;

  • gerenciador de senhas;

  • ausência de trocas periódicas sem suspeita de comprometimento;

  • MFA;

  • proteção contra tentativas automatizadas.

Senhas não devem ser armazenadas em texto puro nem em SHA-256 simples. Aplicações usam funções próprias para derivação de senha, como Argon2id, com salt e parâmetros adequados.

Menor privilégio

Cada identidade recebe somente o necessário, durante o período necessário.

“Funciona com SPECIAL” não é solução; é confissão.


9. Criptografia, hashing e encoding — três ferramentas diferentes

Igor colocou a senha em Base64 e declarou:

— Pronto. Está criptografada.

O Chefe olhou para o Agente 86.

— Você quer contar ou eu conto?

Encoding

Encoding muda a representação para armazenamento ou transmissão. Base64, ASCII e UTF-8 não oferecem sigilo.

senha123 → c2VuaGExMjM=

Qualquer pessoa pode reverter essa representação.

Hashing

Hash transforma uma entrada em saída de tamanho definido e não utiliza chave. Serve para verificações de integridade, identificação de conteúdo e construções criptográficas.

Não existe operação de “descriptografar o hash”, mas entradas fracas podem ser descobertas por tentativa e comparação. Por isso, senha não deve ser guardada com hash rápido simples.

MD5 e SHA-1 não são escolhas adequadas para novas proteções criptográficas. SHA-256 e SHA-3 pertencem a famílias modernas, mas o algoritmo correto depende do uso.

Criptografia simétrica

Usa segredo compartilhado e é eficiente para grandes volumes. AES é a referência moderna, normalmente dentro de um modo autenticado adequado.

Criptografia assimétrica

Usa par de chaves pública e privada. É aplicada em assinatura, autenticação e estabelecimento de chaves.

Sistemas reais geralmente são híbridos:

  1. mecanismo assimétrico estabelece um segredo de sessão;

  2. mecanismo simétrico protege o volume de dados.

DES, 3DES e Blowfish aparecem em materiais antigos ao lado de AES, como se fossem opções equivalentes. Não são. DES está quebrado, 3DES é legado e Blowfish possui limitações para novos projetos.

Gestão de chaves

A criptografia é tão forte quanto a administração das chaves:

  • geração;

  • armazenamento;

  • distribuição;

  • rotação;

  • segregação;

  • revogação;

  • destruição;

  • recuperação controlada.

Uma chave AES gravada no fonte COBOL é apenas uma senha com autoestima elevada.

Assinatura digital

Ajuda a verificar origem e integridade, mas não fornece confidencialidade automaticamente. E não deve ser reduzida à frase “criptografar com a chave privada”; esquemas de assinatura possuem construções específicas.

Curiosidade: a migração pós-quântica já começou. Padrões como ML-KEM, ML-DSA e SLH-DSA existem para enfrentar futuros adversários com capacidade quântica. O trabalho atual não é apertar um botão, mas inventariar algoritmos, certificados, protocolos e dependências para construir agilidade criptográfica.


10. Segurança web — o navegador também executa o inimigo

Uma aplicação web pode ser atacada em qualquer camada: navegador, web server, aplicação, API, identidade, dependência, banco, pipeline ou configuração.

SQL Injection

O erro clássico é misturar código e dados:

String sql = "SELECT * FROM USERS WHERE USERNAME = '" + user + "'";

Uma entrada maliciosa altera a estrutura do comando. A defesa principal é consulta parametrizada.

Em COBOL com Db2, SQL estático com host variables separa naturalmente valores do comando:

EXEC SQL
   SELECT NOME
     INTO :WS-NOME
     FROM CLIENTES
    WHERE CPF = :WS-CPF
END-EXEC

Ainda precisamos validar tamanho, formato, domínio, autorização e tratamento de erro. E SQL dinâmico concatenado pode recriar a vulnerabilidade.

XSS

Cross-Site Scripting ocorre quando dados do atacante são interpretados como código no navegador.

A proteção principal é encoding contextual da saída. O tratamento muda conforme o destino: HTML, atributo, JavaScript, CSS ou URL. Content Security Policy é uma segunda camada, não cura universal.

CSRF

Cross-Site Request Forgery força o navegador de um usuário autenticado a enviar uma ação não desejada.

Defesas incluem:

  • token anti-CSRF;

  • cookies SameSite;

  • verificação de origem;

  • reautenticação em operações críticas;

  • não usar GET para alterar estado.

Controle de acesso quebrado

Se o cliente altera /conta/12345 para /conta/12346 e vê a conta alheia, a autenticação funcionou. A autorização falhou.

Esconder o botão na tela não protege o endpoint. O servidor precisa autorizar cada operação e cada objeto.


11. OWASP — mapa de conscientização, não certificado de invencibilidade

Materiais baseados em 2021 já estão historicamente úteis, mas a lista vigente do OWASP Top 10 é a de 2025:

  1. Controle de acesso quebrado;

  2. Configuração insegura;

  3. Falhas na cadeia de suprimentos de software;

  4. Falhas criptográficas;

  5. Injeção;

  6. Design inseguro;

  7. Falhas de autenticação;

  8. Falhas de integridade de software ou dados;

  9. Falhas de logging e alertas;

  10. Tratamento incorreto de condições excepcionais.

As mudanças contam uma história. Configuração subiu de importância. Supply chain ganhou destaque. Logging passou a enfatizar alertas. Tratamento incorreto de condições excepcionais entrou na lista.

Isso é música para ouvidos COBOL. Mainframeiro sabe que exceção ignorada, return code não verificado e transação parcialmente atualizada podem produzir desastres sem uma única linha de malware.

OWASP Top 10 serve para conscientização. Não é uma lista completa de requisitos. Para verificação estruturada, o OWASP ASVS é mais apropriado.


12. Programação segura — não cole segurança depois do compilador

Programação segura inclui:

  • validação de entrada;

  • consultas parametrizadas;

  • encoding de saída;

  • autenticação forte;

  • autorização em cada operação;

  • menor privilégio;

  • tratamento seguro de erro;

  • logging útil;

  • proteção de segredos;

  • atualização de dependências;

  • revisão de código;

  • testes de segurança.

Validação de domínio

Não pergunte apenas se o dado é numérico. Pergunte se faz sentido.

Uma idade de -900 pode caber num PIC S9(4), mas não cabe na realidade. Uma transferência pode possuir sintaxe perfeita e violar limite, estado da conta ou segregação de funções.

Falhar de forma segura

Quando o serviço de autorização não responde, a aplicação libera ou nega? Quando ocorre timeout após débito, a repetição duplica a transferência? Quando o log falha, a operação privilegiada continua?

Falhar de forma segura exige:

  • estado consistente;

  • rollback;

  • idempotência;

  • mensagens externas discretas;

  • evidência interna suficiente;

  • negação por padrão quando apropriada.

Logs

Registre quem, o quê, quando, onde, resultado e identificador de correlação. Não registre senha, chave, token completo ou dado pessoal sem necessidade.

Log sem alerta é arqueologia. Alerta sem responsável é decoração natalina do SOC.

Cadeia de suprimentos

Atualizar biblioteca é só o início. Precisamos saber:

  • quais componentes existem;

  • de onde vieram;

  • quem alterou o pipeline;

  • quais artefatos foram assinados;

  • onde estão os segredos;

  • como revogar uma versão comprometida;

  • como reconstruir o software de forma confiável.

Segurança entra no desenho, no código, no build, no teste, na implantação e na operação.


13. Passo a passo — uma transferência bancária atravessa o castelo

Vamos acompanhar uma transferência.

Passo 1 — O cliente se conecta

TLS protege o canal. Mas o cadeado não garante que a aplicação esteja livre de fraude ou falha lógica.

Passo 2 — O cliente se identifica e autentica

O sistema verifica senha, passkey, dispositivo ou MFA, aplica rate limiting e detecta credential stuffing.

Passo 3 — O sistema autoriza

Verifica se o cliente possui a conta, se pode usar aquele canal, se o valor está dentro do limite e se a sessão possui nível suficiente.

Passo 4 — A regra de negócio valida

Confere valor positivo, moeda, saldo, favorecido, bloqueios, limite, horário, duplicidade e estado da conta.

Passo 5 — A transação é executada

Débito e crédito precisam formar uma unidade atômica. Em caso de falha, ROLLBACK; no sucesso, COMMIT.

Passo 6 — A operação é registrada

Logs e trilhas registram identidade, conta, canal, horário, resultado e correlação, sem expor segredos desnecessários.

Passo 7 — A fraude é analisada

O sistema considera novo dispositivo, valor atípico, velocidade, localização e histórico.

Passo 8 — O ambiente monitora

SIEM, regras, analistas e automações observam sinais técnicos e de negócio.

Passo 9 — Se algo der errado

A organização contém, investiga, preserva evidências, comunica, recupera e aprende.

Perceba: firewall, criptografia e MFA são três parafusos. A transferência segura depende da máquina inteira.


14. Checklist do programador COBOL que começou ontem — e quer chegar vivo à produção

Antes de entregar um programa, pergunte:

  1. Todos os campos externos têm tamanho, tipo e domínio validados?

  2. Valores negativos, zeros, limites e overflow foram tratados?

  3. Cada operação verifica autorização, não apenas autenticação?

  4. O programa usa apenas os privilégios necessários?

  5. SQL dinâmico e comandos externos separam código de dados?

  6. Return codes e condições excepcionais são tratados?

  7. Atualizações relacionadas usam unidade transacional adequada?

  8. Reprocessamento é idempotente ou pode duplicar operações?

  9. Logs possuem correlação e não vazam segredos?

  10. Mensagens ao usuário evitam detalhes internos?

  11. Senhas, tokens e chaves estão fora do fonte e do JCL?

  12. Há testes de sucesso, negação, limite, falha e recuperação?

  13. Alguém revisou o código com olhar de abuso, não só de funcionalidade?

  14. Existe plano para detectar e corrigir o comportamento em produção?

Se alguma resposta for “não sei”, você encontrou trabalho útil antes que a KAOS encontre trabalho divertido.


Epílogo — Desculpe por isso, Chefe

O Agente 86 voltou à sala de controle carregando um relatório.

— Chefe, tenho boas e más notícias.

— Comece pelas boas.

— O firewall está funcionando, o RACF está ativo e a senha não está mais em Base64.

— E as más?

— Igor substituiu a senha por AGOSTO@2026!, concedeu ALTER para todos e desligou o SIEM porque as luzes vermelhas estavam deixando o laboratório nervoso.

— 86...

— Eu sei, Chefe. Errei por isso aqui.

Esta é a grande lição do Capítulo I: segurança não é um produto instalado, um cadeado no navegador ou uma certificação pendurada na parede. É uma disciplina contínua de conhecimento, prevenção, observação, reação e aprendizado.

A tríade CIA ensina o que preservar. A análise de risco ensina onde concentrar esforço. A defesa em profundidade assume que algum controle falhará. A programação segura reduz fraquezas antes da produção. O monitoramento reconhece o que escapou. A resposta limita o dano. A recuperação devolve a missão ao ar.

O iniciante não precisa decorar todas as siglas de uma vez. Precisa aprender a fazer as perguntas certas:

  • O que estou protegendo?

  • De quem ou de quê?

  • Como isso pode falhar?

  • Quem realmente precisa de acesso?

  • Como saberei que algo aconteceu?

  • O que farei quando acontecer?

  • Como provarei o que ocorreu?

  • Como voltarei a operar com segurança?

Quando essas perguntas entram no código, no JCL, no RACF, no CICS, no Db2, na arquitetura e na reunião de mudança, o programador deixa de enxergar segurança como uma equipe que diz “não” no final do projeto. Ele passa a enxergá-la como parte da qualidade do sistema.

E qualidade, no Bellacosa Mainframe, significa algo muito simples: o programa faz o que deve, somente para quem pode, preserva o que importa, conta o que aconteceu e sabe voltar para casa depois que o telefone-sapato explode.


Referências para continuar a missão

☕ Um Café no Bellacosa Mainframe

Cibersegurança: dos fundamentos à recuperação

Uma jornada em dois capítulos para entender a linguagem da segurança, reconhecer riscos e organizar a operação antes, durante e depois de um incidente.

Vocabulário e Fundamentos da Cibersegurança

Tríade CIA, ativos, ameaças, vulnerabilidades, risco, malware, autenticação, criptografia, redes, aplicações web e codificação segura.

Ler o Capítulo I no artigo original →

Operação, Detecção, Resposta e Recuperação

Inventário, vulnerabilidades, eventos, alertas, incidentes, crise, monitoramento, contenção, evidências, continuidade e recuperação.

Ler o Capítulo II no artigo original →

Mapa da missão: o primeiro capítulo explica o que precisa ser protegido e por quê; o segundo mostra como observar, decidir, responder e restaurar a operação quando a prevenção não for suficiente.

Capítulo I — Vocabulário e Fundamentos da Cibersegurança

Abrir fora do quadro ↗

Capítulo II — Operação, Detecção, Resposta e Recuperação

Abrir fora do quadro ↗
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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
GitHub LinkedIn
Inicializando conteúdo...