| Bellacosa Mainframe e a engenharia militar parte v |
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo V — As Muralhas Invisíveis: Defesa em Profundidade e o Castelo Digital
Quando um Programador COBOL Descobre que a Melhor Segurança Não é Impedir um Ataque... É Fazer com que o Inimigo Nunca Alcance o Coração da Fortaleza
A primavera havia chegado.
As cerejeiras floresciam ao redor do castelo.
Mercadores atravessavam a ponte principal.
Crianças corriam pelas ruas.
Ferreiros trabalhavam em silêncio.
À primeira vista, parecia um lugar tranquilo.
O jovem samurai observava a enorme muralha de pedra e comentou com o velho engenheiro:
— Construíram um muro gigantesco.
Ninguém conseguirá entrar.
O engenheiro sorriu.
— Você realmente acredita que esta muralha é nossa defesa?
O rapaz respondeu sem hesitar.
— Claro.
O velho caminhou lentamente.
Mostrou o fosso.
Depois a ponte levadiça.
Depois as torres de arqueiros.
Depois os portões internos.
Depois os corredores estreitos.
Depois os depósitos subterrâneos.
Depois os poços de água.
Depois os celeiros.
Depois as passagens ocultas.
Por fim disse:
— Se um inimigo atravessar a primeira muralha...
...a guerra ainda estará apenas começando.
Séculos depois...
03h42 da madrugada.
Um alerta apareceu na central de segurança.
Uma credencial havia sido comprometida.
O analista novato entrou em pânico.
— Invadiram o sistema!
O especialista veterano respondeu calmamente.
— Ainda não.
Eles apenas chegaram ao primeiro portão.
Agora vamos descobrir quantas muralhas ainda existem.
Hoje nosso café será servido sobre pedras.
Porque castelos não sobrevivem por causa de um muro.
Sobrevivem porque transformam cada metro conquistado pelo inimigo em uma nova batalha.
1. O maior erro da segurança moderna
Existe uma ideia extremamente perigosa.
"Se meu firewall é bom...
estou protegido."
Ou.
"Se tenho antivírus...
estou seguro."
Ou ainda.
"Se existe login...
ninguém entrará."
A História mostra exatamente o contrário.
Toda fortaleza, por mais poderosa que fosse, eventualmente enfrentava:
espionagem
suborno
túneis
incêndios
catapultas
escadas
fome
infiltração
traição
Os construtores sabiam disso.
Por isso nunca confiavam em apenas uma defesa.
2. O conceito de Defesa em Profundidade
Na engenharia militar existe um princípio clássico.
Defense in Depth.
Em vez de depender de uma única barreira...
criam-se diversas camadas.
Imagine.
Primeira camada.
Floresta.
Depois.
Fossos.
Depois.
Muralhas externas.
Depois.
Portões reforçados.
Depois.
Pátios internos.
Depois.
Outra muralha.
Depois.
Torres.
Depois.
Guarda pessoal.
Cada camada reduz velocidade.
Aumenta custo.
Expõe o atacante.
Dá tempo para reagir.
No IBM Z acontece exatamente igual.
3. O Castelo chamado Mainframe
Imagine um ambiente bancário.
Antes que um programa COBOL execute uma única instrução...
várias camadas já trabalharam.
Hardware.
Firmware.
Microcódigo.
LPAR.
PR/SM.
z/OS.
RACF.
CICS.
Db2.
Aplicação.
Dados.
Cada camada possui responsabilidades específicas.
Mesmo que uma delas apresente problemas...
as demais continuam protegendo o ambiente.
Essa arquitetura explica parte da extraordinária reputação de confiabilidade do IBM Z.
4. A Primeira Muralha — O Hardware
Poucos programadores pensam no hardware.
Mas ele é a fundação do castelo.
Os processadores IBM Z incluem recursos voltados para:
detecção de erros
correção automática
redundância
verificação de integridade
criptografia acelerada por hardware
isolamento entre partições
É como construir muralhas utilizando pedras que avisam quando começam a apresentar rachaduras.
O objetivo não é apenas resistir.
É perceber rapidamente que algo precisa ser reparado.
5. Segunda Muralha — O Sistema Operacional
O z/OS controla quem utiliza recursos.
Quem recebe memória.
Quem acessa dispositivos.
Quem inicia tarefas.
Quem possui prioridade.
Ele funciona como o administrador da fortaleza.
Nenhum soldado simplesmente decide abrir um portão.
Existe protocolo.
Existe autorização.
Existe registro.
6. Terceira Muralha — O RACF
Se existe um nome que simboliza segurança em ambientes IBM Z...
é RACF.
Muitos iniciantes imaginam que o RACF seja apenas um cadastro de usuários.
Na realidade...
ele representa uma política completa.
Ele responde perguntas como:
Quem pode acessar?
Quando?
De qual terminal?
Qual dataset?
Qual transação?
Qual comando?
Quem alterou a autorização?
Quem tentou entrar?
Quem foi bloqueado?
No castelo medieval...
o guarda perguntava:
— Quem é você?
No RACF a pergunta torna-se muito mais sofisticada.
— Quem é você?
— O que deseja fazer?
— Você realmente possui autorização?
— Alguém registrou sua tentativa?
7. Quarta Muralha — O CICS
Imagine uma cidade movimentada.
Milhares de pessoas entram e saem.
Compram.
Vendem.
Transportam mercadorias.
Essa cidade é o CICS.
Cada transação representa um cidadão realizando uma atividade.
Se alguém causar confusão...
a cidade continua funcionando.
Uma transação não derruba todas as outras.
O isolamento operacional torna-se parte da defesa.
8. Quinta Muralha — O Db2
Toda fortaleza protege algo.
Tesouro.
Documentos.
Mapas.
Contratos.
No ambiente empresarial...
o Db2 frequentemente guarda justamente esse patrimônio.
Ele protege:
contas.
clientes.
contratos.
histórico.
auditoria.
movimentações.
Mas proteger dados não significa apenas impedir leitura.
Também significa preservar:
integridade.
consistência.
atomicidade.
durabilidade.
Quando uma transação termina...
ela precisa deixar o reino exatamente no estado esperado.
9. O Tesouro escondido
Os antigos castelos raramente mantinham o tesouro na primeira sala.
Normalmente ele ficava protegido por diversas portas.
Em tecnologia ocorre igual.
Os dados mais sensíveis costumam receber controles adicionais.
Por exemplo.
Criptografia.
Mas apenas criptografar não basta.
Também precisamos controlar:
quem descriptografa.
quando.
por quê.
onde.
quanto tempo.
Segurança nunca é apenas tecnologia.
É governança.
10. IBM FlashSystem — O Cofre do Reino
Imagine que uma fortaleza possua um enorme depósito subterrâneo.
Mesmo que parte da cidade seja incendiada...
esse depósito permanece protegido.
Os modernos IBM FlashSystem trabalham com conceitos semelhantes.
Snapshots.
Replicação.
Imutabilidade.
Recuperação rápida.
Detecção inteligente.
Quando ocorre um ataque de ransomware...
o objetivo deixa de ser apenas impedir.
Passa a ser:
recuperar rapidamente.
Na engenharia militar existe um princípio parecido.
Se uma muralha cair...
o castelo precisa continuar capaz de lutar.
11. Zero Trust — O Porteiro Desconfiado
Durante muito tempo as empresas seguiram uma lógica simples.
"Quem entrou no castelo é confiável."
Zero Trust muda completamente essa ideia.
Ele parte do princípio oposto.
"Nunca confie automaticamente."
Cada solicitação precisa ser validada.
Mesmo que venha de dentro.
Imagine um mensageiro atravessando cinco portões.
Em cada um deles recebe perguntas diferentes.
Parece exagerado.
Até o dia em que um inimigo veste exatamente o uniforme do mensageiro.
12. O Samurai Disfarçado
Em muitos filmes japoneses existe o guerreiro infiltrado.
Ele veste roupas comuns.
Mistura-se aos comerciantes.
Atravessa a cidade.
Chega próximo ao castelo.
O problema nunca foi a roupa.
Foi a identidade.
Hoje ataques digitais utilizam exatamente a mesma estratégia.
Não parecem ataques.
Parecem usuários legítimos.
Por isso autenticação, autorização, auditoria e monitoramento caminham juntos.
13. A Engenharia da Observação
Nenhuma fortaleza depende apenas de muralhas.
Ela depende de vigias.
Sentinelas.
Patrulhas.
Mensageiros.
Alarmes.
No mundo digital isso corresponde a:
logs.
SMF.
RMF.
auditoria.
SIEM.
monitoramento.
alertas.
Um ataque detectado rapidamente possui enorme chance de ser contido.
Um ataque invisível cresce silenciosamente.
14. O Castelo também precisa respirar
Um erro comum consiste em imaginar segurança como bloqueio absoluto.
Mas castelos existem para proteger pessoas.
Não para aprisioná-las.
Mercadores precisam entrar.
Mensageiros precisam sair.
Soldados precisam circular.
No IBM Z ocorre igual.
Segurança não pode impedir a operação.
Ela precisa permitir o funcionamento correto.
Encontrar esse equilíbrio é uma das tarefas mais difíceis da arquitetura.
15. Shogun e o poder dos portões
Em Shogun, controlar um portão significa muito mais que controlar uma passagem.
Significa controlar:
informação.
comércio.
tributação.
movimentação.
espionagem.
Pessoas não entram apenas carregando espadas.
Entram carregando ideias.
Rumores.
Moedas.
Influência.
No Data Center...
APIs.
MQ.
FTP.
REST.
TCP/IP.
São os portões da fortaleza.
Cada um precisa possuir regras claras.
16. Goblin Slayer e as múltiplas barreiras
Goblin Slayer nunca entra em uma caverna acreditando que apenas sua espada resolverá tudo.
Ele utiliza:
armadilhas.
fogo.
água.
cordas.
escudos.
venenos.
barreiras.
rotas alternativas.
Cada recurso cobre uma falha possível.
Essa mentalidade resume perfeitamente a defesa em profundidade.
Nunca depender de uma única solução.
17. O perigo da confiança excessiva
Durante nossa conversa anterior discutimos propaganda, disciplina e educação.
Existe um ponto interessante.
Castelos frequentemente caíam porque alguém dizia:
"Jamais conseguirão entrar."
Esse pensamento produz relaxamento.
Na segurança digital acontece igual.
Quando a organização acredita ser invulnerável...
normalmente deixa de revisar:
credenciais.
patches.
procedimentos.
backups.
testes.
treinamentos.
A arrogância abre mais portas que muitas catapultas.
18. Curiosidade Histórica
Os castelos japoneses do período Sengoku raramente eram protegidos por uma única muralha. Estruturas como Himeji, Matsumoto e Kumamoto utilizavam múltiplos portões, caminhos em zigue-zague, pátios sucessivos, torres de observação e corredores estreitos para atrasar invasores. O objetivo não era impedir totalmente a entrada, mas reduzir a velocidade do ataque, aumentar a exposição do inimigo e criar oportunidades para a defesa reagir.
Arquiteturas modernas de segurança seguem o mesmo princípio: autenticação, autorização, criptografia, monitoramento, segmentação, backups, recuperação e auditoria trabalham em conjunto para limitar impactos e preservar a continuidade operacional.
19. Easter Egg — O Portão que Nunca Era Fechado
Conta-se que existia um antigo castelo onde um pequeno portão lateral permanecia sempre aberto.
Não por descuido.
Mas porque todos acreditavam que era pequeno demais para representar perigo.
Décadas passaram.
Nenhum ataque ocorreu.
Até uma noite.
Não entrou um exército.
Entrou apenas um homem.
Abriu o portão principal.
E todo o castelo caiu.
Anos depois...
em um ambiente de produção...
descobriu-se uma antiga conta técnica.
Nunca utilizada.
Nunca removida.
Possuía privilégios administrativos.
Ninguém lembrava por que existia.
Ela permanecera ativa durante quinze anos.
Jamais fora explorada.
Até o dia em que foi.
O relatório de auditoria recebeu um comentário simples.
Não foi a grande muralha que falhou.
Foi a pequena porta esquecida.
Desde então, um veterano costumava repetir aos novos integrantes da equipe:
"Os invasores raramente escolhem o caminho mais difícil. Eles escolhem o menos observado."
20. Checklist do Guardião da Fortaleza
Antes de considerar um sistema protegido, pergunte:
✔ Existe autenticação forte?
✔ As autorizações seguem o menor privilégio?
✔ Há segregação de funções?
✔ Os acessos são revisados periodicamente?
✔ Logs são coletados e analisados?
✔ Existe criptografia em repouso e em trânsito?
✔ Os backups são testados?
✔ Há snapshots imutáveis?
✔ Existe plano de recuperação?
✔ O monitoramento detecta comportamentos anômalos?
✔ As equipes treinam incidentes periodicamente?
✔ A documentação acompanha as mudanças?
Segurança não é um produto.
É um processo contínuo.
Conclusão — A Fortaleza Nunca Dorme
O sol começava a nascer quando o jovem samurai voltou ao alto da muralha.
A cidade despertava lentamente.
Mercadores atravessavam a ponte.
Crianças brincavam.
Ferreiros acendiam suas forjas.
Tudo parecia exatamente igual ao dia anterior.
O velho engenheiro aproximou-se.
— O que você vê?
— Paz.
O mestre sorriu.
— Não.
Você está vendo o resultado de milhares de pequenas decisões tomadas durante anos.
As muralhas foram reparadas.
Os portões foram revisados.
Os poços limpos.
Os celeiros abastecidos.
Os guardas treinados.
As chaves conferidas.
A paz não era ausência de trabalho.
Era consequência dele.
Na central do Data Center, o painel mostrava dezenas de indicadores verdes.
Nenhum incidente.
Nenhum alerta crítico.
Nenhum usuário percebia o enorme esforço que mantinha aquele ambiente funcionando.
O jovem programador desligou o terminal.
Agora entendia que escrever um programa COBOL seguro não significava apenas validar um IF ou tratar um FILE STATUS.
Significava fazer parte de uma fortaleza construída por milhares de profissionais ao longo de décadas.
Uma fortaleza onde cada camada existia para proteger a próxima.
E onde a verdadeira vitória não era derrotar um invasor.
Era permitir que milhões de pessoas utilizassem seus bancos, recebessem seus salários, pagassem suas contas e confiassem em seus sistemas... sem jamais perceber que uma guerra silenciosa havia sido vencida durante a madrugada.
Porque os maiores castelos da História não ficaram famosos apenas por resistirem aos ataques.
Ficaram famosos porque, geração após geração, sempre havia alguém disposto a reconstruir a próxima muralha antes que ela fosse necessária.
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Uma campanha completa sobre estratégia, logística, inteligência, segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.
Um Data Center analisado como uma fortaleza em guerra
A série Engenharia Militar sem Mistérios para Programadores COBOL compara castelos, exércitos, muralhas, cadeias de comando, logística, inteligência e operações militares com os ambientes IBM Z responsáveis por bancos, governos, seguros, transportes e serviços essenciais.
Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL, Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF, monitoramento, contingência, liderança, documentação e continuidade operacional.
Índice da campanha
Links completos da série Engenharia Militar
Esta relação permanece disponível no HTML da página para mecanismos de busca, leitores de tela, navegadores sem JavaScript e ferramentas de arquivamento.
- Engenharia Militar sem Mistérios para Programadores COBOL
- Prólogo — O Chamado do Guardião
- Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar
- Capítulo II — Estratégia, Operação e Tática
- Capítulo III — A Cadeia de Comando
- Capítulo IV — Logística
- Capítulo V — As Muralhas Invisíveis
- Capítulo VI — Inteligência, Reconhecimento e Espionagem
- Capítulo VII — A Arte da Guerra Aplicada ao Mainframe
- Capítulo VIII — Liderança, Moral e Disciplina
- Capítulo IX — Inovação, Evolução e o Futuro
- Capítulo X — O Legado do Engenheiro
- Capítulo XI — O Guardião Invisível
- Capítulo XII — A Fortaleza Invisível
- Capítulo XIII — Os Sentinelas da Madrugada
- Capítulo XIV — A Civilização Invisível
- Capítulo XV — Engenharia de Cerco
- Glossário IBM Z + Engenharia Militar
- Apêndice A — Correspondências Históricas e Técnicas
- Os 10 Animes Mais Emblemáticos Sobre Engenharia Militar
- Os 10 Animes Mais Emblemáticos Sobre Logística Militar
- Os 10 Animes Mais Emblemáticos Sobre Tática Militar
- Os 10 Animes Mais Emblemáticos Sobre Estratégia Militar
- Especial — Guerrilha Urbana
- Especial — Guerrilha no Campo e na Floresta
Sem comentários:
Enviar um comentário