☕ 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

segunda-feira, 23 de setembro de 2024

O Dia em que Suzane e Cazuza Derrubaram o Barão Vermelho do Google

 

Bellacosa Mainframe e o fim inglorio do Barão Vermelho

☕ Um Café no Bellacosa Mainframe

O Dia em que Suzane e Cazuza Derrubaram o Barão Vermelho do Google

Ou: como o maior ás da Primeira Guerra Mundial sobreviveu a 80 combates aéreos, morreu em 1918 e, um século depois, perdeu uma guerra de SEO para uma banda de rock e um caso policial brasileiro

Pegue um café.

Hoje vamos realizar uma experiência científica de altíssima complexidade.

Não será necessário laboratório.

Não precisaremos de acelerador de partículas.

Nenhum chimpanzé será ferido — embora alguns estejam de ressaca.

Precisaremos apenas de um computador, um navegador e duas pesquisas.

Digite:

Barão Vermelho.

Agora digite:

Richthofen.

Se você estiver no Brasil, provavelmente acabará diante de uma das maiores ironias da história da memória digital.

Porque houve um homem chamado Manfred Albrecht Freiherr von Richthofen, piloto de caça alemão da Primeira Guerra Mundial, que se tornou uma das figuras mais conhecidas da história da aviação.

O sujeito derrubou dezenas de aeronaves inimigas.

Sobreviveu a combates em máquinas feitas essencialmente de madeira, tecido, arame, motor e uma quantidade industrial de coragem ou insanidade.

Tornou-se conhecido internacionalmente como:

O BARÃO VERMELHO.

Morreu em 1918.

E então aconteceu algo que nenhum estrategista militar poderia prever.

Cem anos depois, no Brasil, ele foi atacado simultaneamente por dois adversários formidáveis:

Cazuza pela esquerda.

Suzane von Richthofen pela direita.

Manfred olhou para o Google.

O Google olhou para Manfred.

E disse:

— Desculpe, senhor. O algoritmo encontrou resultados mais relevantes.


✈️ 1. Antes de tudo, havia um Barão Vermelho de verdade

Vamos devolver ao morto cinco minutos de dignidade histórica.

Manfred von Richthofen nasceu em 1892 e tornou-se piloto durante a Primeira Guerra Mundial.

Foi creditado com 80 vitórias aéreas, número extraordinário para aquele conflito, e transformou-se no ás mais famoso da guerra.

Sua imagem ficou associada especialmente às aeronaves vermelhas que pilotava e, no imaginário popular, ao famoso triplano Fokker Dr.I.

Daí:

Der Rote Baron.

The Red Baron.

Le Baron Rouge.

Il Barone Rosso.

O Barão Vermelho.

O homem virou arquétipo.

Décadas depois, Snoopy enfrentaria o Barão Vermelho imaginariamente em sua casinha.

Jogos usariam seu nome.

Filmes contariam sua história.

Modelistas montariam miniaturas de seus aviões.

Historiadores discutiriam suas batalhas.

Pilotos conheceriam seu nome.

Manfred havia conseguido aquilo que poucos seres humanos conseguem:

transformar o próprio sobrenome numa referência histórica internacional.

Richthofen era Richthofen.

Até chegar ao Brasil.


🎸 2. Então alguns brasileiros resolveram montar uma banda

Em 1981 nasceu uma banda brasileira de rock.

Precisava de nome.

E alguém teve uma excelente ideia:

Barão Vermelho.

Pronto.

O primeiro míssil SEO havia sido lançado décadas antes de SEO existir.

Depois apareceu um sujeito chamado Agenor de Miranda Araújo Neto.

Você talvez o conheça por um pequeno apelido:

Cazuza.

A banda cresceu.

Cazuza virou Cazuza.

Vieram músicas, discos, rádio, televisão, shows, revistas, entrevistas, fotografias, livros, documentários, biografias, homenagens.

Décadas de referências.

Para milhões de brasileiros nascidos depois da Primeira Guerra Mundial — o que, convenhamos, constitui parcela razoável da população — “Barão Vermelho” deixou de significar automaticamente:

piloto alemão, 1917.

Passou a significar:

banda brasileira de rock.

Não houve conspiração.

Cazuza jamais reuniu seus generais numa sala escura dizendo:

— Senhores, precisamos destruir a posição orgânica de Manfred von Richthofen.

Simplesmente aconteceu.

A cultura sobrescreveu a chave.

SEARCH_KEY = "Barão Vermelho"

1918:
RETURN Manfred_von_Richthofen

1985:
IF COUNTRY = BRAZIL
   RETURN Cazuza_and_friends
END-IF

O primeiro flanco estava perdido.

Mas Manfred ainda tinha seu sobrenome.

Richthofen.

Esse ninguém tomaria.

Certo?

Certo?

🐒


📰 3. Segure meu café, disse o Brasil

Em 2002 aconteceu um dos crimes mais conhecidos da história criminal brasileira recente.

Manfred Albert von Richthofen e Marísia von Richthofen foram assassinados.

A filha do casal, Suzane von Richthofen, Daniel Cravinhos e Cristian Cravinhos seriam posteriormente condenados pelo crime.

Não vamos transformar este Café numa reconstrução policial.

Existem livros, reportagens, documentários, processos, filmes e quilômetros de material sobre isso.

O que nos interessa aqui aconteceu depois.

O nome:

RICHTHOFEN

voltou com violência ao vocabulário brasileiro.

Só que não acompanhado de:

Fokker Dr.I.

Nem:

Primeira Guerra Mundial.

Nem:

80 vitórias.

Agora vinha acompanhado de:

Suzane.

Crime.

Julgamento.

Condenação.

Prisão.

Tremembé.

Progressão de regime.

Filmes.

Séries.

Documentários.

Entrevistas.

Notícias.

Mais notícias.

Mais notícias.

E mais notícias.

O segundo flanco de Manfred havia caído.


🔎 4. O Google não é professor de História

Aqui está o erro que cometemos quando pensamos em mecanismos de busca.

Imaginamos uma espécie de bibliotecário celestial.

Perguntamos:

Richthofen?

E esperamos que ele pense:

“Ah, naturalmente! Manfred von Richthofen, importante personagem histórico da Primeira Guerra Mundial.”

Mas mecanismo de busca não funciona como nosso professor de História.

Ele precisa descobrir o que provavelmente queremos encontrar.

E contexto importa.

Idioma importa.

Localização importa.

A consulta importa.

A Web disponível importa.

O interesse das pessoas muda.

Conteúdo novo aparece.

Conteúdo antigo perde ou ganha relevância.

O próprio Google reconhece oficialmente que seus resultados são dinâmicos porque a Web e o comportamento dos usuários estão constantemente mudando.

Ou seja:

Google não preserva uma tabela eterna de importância histórica.

Ele recalcula.

E aí nosso pobre Barão encontrou um adversário que nenhum Fokker poderia derrubar:

relevância contemporânea.


🧠 5. Biblioteca e buscador são criaturas diferentes

Entre numa biblioteca especializada em história militar.

Procure:

Richthofen.

Provavelmente Manfred aparecerá imediatamente.

Entre numa biblioteca de aviação.

Richthofen?

Manfred.

Primeira Guerra?

Manfred.

Ases?

Manfred.

Agora abra um mecanismo de busca brasileiro.

Digite apenas:

Richthofen.

A pergunta deixou de ser:

“Quem foi historicamente o Richthofen mais importante?”

A pergunta algorítmica se aproxima muito mais de:

“O que alguém digitando Richthofen aqui e agora provavelmente deseja encontrar?”

São perguntas completamente diferentes.

E isso produz uma conclusão fundamental:

importância histórica não é igual a relevância algorítmica.

Guarde essa frase.

Voltaremos a ela.


🕰️ 6. O morto tem um problema de marketing

Existe uma desvantagem terrível em morrer.

Além da óbvia.

Você para de produzir acontecimentos.

Manfred morreu em 21 de abril de 1918.

Desde então:

não casou.

não separou.

não mudou de emprego.

não abriu Instagram.

não participou de podcast.

não discutiu no Twitter.

não foi fotografado saindo de restaurante.

não lançou autobiografia.

não mudou de regime prisional.

não apareceu dirigindo Uber.

não respondeu seguidores.

não fez harmonização facial.

não entrou no BBB.

não deu entrevista.

não brigou com outro influenciador.

não lançou curso.

não vendeu mentoria.

Um desastre absoluto para SEO contemporâneo.

O cadáver simplesmente não colabora com o algoritmo.


📰 7. A celebridade criminal possui atualização contínua

Agora compare isso com uma pessoa ligada a um caso criminal extremamente famoso.

Depois que o nome alcança reconhecimento nacional, surge um fenômeno estranho.

Coisas absolutamente banais tornam-se notícia.

Pessoa desconhecida começa emprego novo:

silêncio.

Pessoa famosa por crime começa emprego novo:

MANCHETE.

Pessoa desconhecida casa:

parabéns da família.

Pessoa famosa casa:

MANCHETE.

Pessoa desconhecida separa:

problema dela.

Pessoa famosa separa:

MANCHETE.

Mudou o cabelo?

Notícia.

Mudou de cidade?

Notícia.

Abriu negócio?

Notícia.

Fechou negócio?

Notícia.

Aconteceu alguma coisa?

Notícia.

Não aconteceu nada?

Talvez também dê notícia.

🐒

Isso cria um loop extraordinário:

CRIME
  ↓
NOTORIEDADE
  ↓
COBERTURA
  ↓
MAIS NOTORIEDADE
  ↓
QUALQUER EVENTO TORNA-SE NOTÍCIA
  ↓
MAIS COBERTURA
  ↓
MAIS NOTORIEDADE
  ↺

O sistema passou a alimentar a si próprio.


💰 8. Quando o crime produz propriedade intelectual

E existe uma camada ainda mais desconfortável.

Crimes famosos produzem:

filmes.

livros.

podcasts.

documentários.

séries.

programas especiais.

canais de true crime.

entrevistas.

retrospectivas.

Cada nova produção ressuscita novamente o conjunto de palavras-chave.

É importante fazer uma distinção: existir filme ou livro sobre alguém não significa automaticamente que essa pessoa tenha vendido direitos ou recebido dinheiro. Direitos autorais, fatos públicos, direito de imagem e contratos são questões diferentes.

Mas, para nosso problema algorítmico, isso quase não importa.

Cada obra gera:

RICHTHOFEN

novamente.

Nova página.

Novo trailer.

Nova crítica.

Nova entrevista.

Nova busca.

Novo post.

Novo vídeo.

Novo comentário.

Novo crawler.

Manfred está morto há 108 anos.

Suzane continua produzindo eventos noticiáveis simplesmente por continuar vivendo.

Tente competir com isso.


🎸 9. Enquanto isso, Cazuza continua atacando pelo outro flanco

E Manfred ainda possui outro problema.

Mesmo que alguém tente escapar do sobrenome e pesquise pelo apelido:

BARÃO VERMELHO

surge a banda.

E Cazuza possui outra vantagem sobre Manfred.

Morreu em 1990, mas sua obra continua culturalmente ativa.

Músicas são reproduzidas.

Documentários aparecem.

Biografias são relançadas.

Artistas fazem homenagens.

Datas comemorativas produzem matérias.

Novas gerações descobrem as músicas.

Streaming mantém catálogo disponível.

A banda Barão Vermelho continuou sua própria história.

Portanto temos:

QUERY: "Barão Vermelho"

CANDIDATO A:
Manfred von Richthofen
1892–1918
piloto
Primeira Guerra Mundial

CANDIDATO B:
Barão Vermelho
banda brasileira
rock
Cazuza
Frejat
músicas
streaming
shows
cultura brasileira

O algoritmo brasileiro olha para aquilo.

Olha para você.

Olha novamente.

— Tenho quase certeza de que ele quer a banda.

MANFRED: ICH PROTESTIERE!

Tarde demais.


💥 10. O ataque perfeito

Agora conseguimos enxergar a beleza matemática da tragédia.

O pobre sujeito sofreu um ataque semântico pelos dois identificadores principais.

MANFRED VON RICHTHOFEN

IDENTIFICADOR 1:
"BARÃO VERMELHO"
       ↓
     CAZUZA
       🎸

IDENTIFICADOR 2:
"RICHTHOFEN"
       ↓
     SUZANE
       📰

É magnífico.

É terrível.

É brasileiro.

Um dos pilotos mais famosos da história militar perdeu simultaneamente:

o apelido para o rock brasileiro

e

o sobrenome para o true crime brasileiro.

Nem Clausewitz prepararia alguém para essa guerra.


🐕 11. Snoopy tentou ajudar

Existe ainda uma testemunha de defesa.

Snoopy.

Durante décadas, o cachorro de Charles Schulz subia em sua casinha, colocava capacete e óculos de aviador e imaginava enfrentar o Barão Vermelho.

Isso ajudou enormemente a manter o personagem no imaginário popular internacional.

Mas existe um pequeno problema.

Pergunte a muitos brasileiros jovens:

“Quem é o Barão Vermelho?”

A resposta provavelmente não será:

— O inimigo imaginário do Snoopy baseado em Manfred von Richthofen!

Será:

— A banda do Cazuza?

Game over.


🧹 12. Memória histórica não possui algoritmo de limpeza

Aqui nossa piada começa a ficar séria.

Nós costumávamos imaginar que digitalizar o mundo significaria:

preservar a memória.

E preservou.

Só que descobrimos outra coisa.

Preservar não significa priorizar.

A informação sobre Manfred continua disponível.

Não foi apagada.

Não houve censura.

Ninguém entrou na Wikipedia durante a madrugada e executou:

DELETE FROM HISTORY
WHERE NAME = 'MANFRED VON RICHTHOFEN';

Ele continua lá.

O problema é outro.

Há cada vez mais coisas na frente dele.

Isso é profundamente diferente de esquecimento tradicional.

No esquecimento tradicional:

a informação desaparece.

No esquecimento algorítmico:

a informação continua existindo, mas perde posição.

Essa diferença é gigantesca.


📚 13. A biblioteca guarda; o algoritmo reorganiza

Imagine uma biblioteca.

Um livro sobre a Primeira Guerra publicado em 1970 continua na estante de Primeira Guerra.

Pode ficar cinquenta anos sem ninguém tocá-lo.

Mas sua classificação permanece aproximadamente estável.

Agora imagine uma biblioteca em que, toda manhã, robôs retirassem todos os livros das prateleiras e reorganizassem tudo segundo:

o que as pessoas procuraram ontem.

Um assassinato famoso acontece?

Prateleira inteira muda.

Uma série estreia?

Muda novamente.

Uma celebridade morre?

Tudo muda.

Uma música viraliza no TikTok?

Corram com as estantes.

Isso se aproxima mais da experiência da memória algorítmica.

O passado continua presente.

Mas sua posição relativa muda constantemente.


🧟 14. O passado precisa competir com o presente

Essa talvez seja uma das grandes mudanças culturais da Internet.

Antigamente, história e notícia ocupavam ambientes relativamente separados.

O jornal dizia:

o que aconteceu ontem.

A enciclopédia dizia:

o que importa saber sobre o passado.

A biblioteca guardava:

o que foi publicado.

Agora tudo disputa a mesma caixa de pesquisa.

Manfred von Richthofen precisa competir com:

Suzane.

Cazuza.

filmes.

streaming.

podcasts.

notícias.

vídeos.

redes sociais.

memes.

E talvez este próprio artigo.

Olá, Googlebot.

🐒


🤖 15. E então chegaram as inteligências artificiais

Agora a coisa fica ainda mais interessante.

Durante vinte anos perguntávamos ao mecanismo de busca:

Richthofen

e recebíamos uma lista.

Agora perguntamos a uma IA:

“Quem é Richthofen?”

A máquina precisa decidir qual contexto provavelmente queremos.

História militar?

Crime brasileiro?

Genealogia?

Aviação?

Cinema?

True crime?

Brasil?

Alemanha?

1917?

2002?

2026?

Isso significa que a batalha pela associação semântica não acontece mais apenas na primeira página de resultados.

Ela acontece dentro da própria representação conceitual das palavras.

Quando milhões de documentos brasileiros associam:

Richthofen → Suzane

e milhões de referências culturais associam:

Barão Vermelho → banda

criamos uma vizinhança semântica.

O nome continua sendo o mesmo.

Mas o caminho mais curto até ele mudou.


🐒 16. Um milhão de chimpanzés encontram o Search Console

Neste momento os chimpanzés finalmente acordaram.

Um deles abre o Google.

Outro abre a Wikipedia.

Um terceiro pesquisa Cazuza.

Um quarto procura o Fokker Dr.I.

O quinto abre um vídeo sobre true crime.

O sexto procura Snoopy.

O sétimo pergunta:

— Quem diabos foi Manfred von Richthofen?

PAREM!

Você percebeu?

Acabamos de fazer novamente.

O leitor que não conhece Manfred agora quer pesquisar Manfred.

O leitor que não conhece o Fokker Dr.I quer pesquisar o avião.

O leitor que não conhece a relação de Snoopy com o Barão Vermelho quer procurar.

O leitor estrangeiro talvez queira descobrir por que diabos existe uma banda brasileira chamada Barão Vermelho.

E quem chegou procurando Suzane acabou lendo sobre a Primeira Guerra Mundial.

Senhoras e senhores:

EFEITO VEJA.

🐒🍌


🔎 17. O morto acaba de receber backlinks conceituais

Essa é a parte deliciosa.

Começamos este texto dizendo que Manfred perdeu a guerra de SEO.

Então escrevemos milhares de palavras contendo:

Manfred von Richthofen.

Barão Vermelho.

Primeira Guerra Mundial.

aviação.

Fokker Dr.I.

80 vitórias.

Cazuza.

Suzane von Richthofen.

E conectamos semanticamente tudo novamente.

Ou seja:

tentando explicar como a Internet esqueceu Manfred...

acabamos de produzir mais um documento lembrando Manfred.

O artigo contradiz sua própria tese ao executá-la.

Magnífico.

Um chimpanzé acaba de cair da cadeira.


⚖️ 18. E existe um lado profundamente humano nisso

Agora retire Cazuza.

Retire o Google.

Retire Manfred.

Retire SEO.

O que sobra?

Uma pergunta desconfortável:

quem controla aquilo pelo qual seremos lembrados?

Durante milhares de anos, a resposta era parcialmente:

família.

comunidade.

historiadores.

igreja.

Estado.

jornais.

livros.

Agora acrescentamos:

algoritmos.

E algoritmos não possuem necessariamente uma teoria moral da memória.

Eles não pensam:

“Este homem possui grande importância histórica e portanto merece permanecer acima desta celebridade contemporânea.”

Nem:

“Esta vítima deseja ser esquecida, então vamos reduzir sua exposição.”

Nem:

“Este criminoso já recebeu notoriedade suficiente.”

Eles processam sinais.

A sociedade produz os sinais.

E depois ficamos surpresos com o resultado.


👤 19. O irmão que gostaria de desaparecer

Essa discussão fica ainda mais incômoda quando pensamos nas pessoas que não escolheram participar de uma história.

Um crime famoso pode transformar familiares e sobreviventes em personagens públicos permanentes.

Enquanto criminosos podem tornar-se personagens de filmes, documentários e matérias, alguém associado ao caso apenas por parentesco pode desejar exatamente o contrário:

anonimato.

Essa pessoa pode querer trabalhar.

Comprar pão.

Ter relacionamentos.

Envelhecer.

Ser esquecida.

Mas existe um problema:

o sobrenome tornou-se uma query.

É uma espécie de herança algorítmica involuntária.

Você não herdou apenas genes, patrimônio ou fotografias de família.

Herdou uma palavra-chave.


♾️ 20. A Internet não esquece — mas isso não significa que ela lembre

Talvez essa seja a frase central deste Café.

Repetimos há décadas:

“A Internet não esquece.”

Não é exatamente verdade.

A Internet armazena.

Quem esquece somos nós.

E os algoritmos reorganizam aquilo que permanece armazenado.

Uma página pode continuar online durante quarenta anos e tornar-se praticamente invisível.

Outra pode possuir apenas três meses e dominar uma consulta.

Portanto:

persistência não é memória.

indexação não é relevância.

relevância não é importância.

E:

primeiro lugar no Google não é primeiro lugar na História.


🛩️ 21. Manfred ainda está voando

Então não, Cazuza não apagou Manfred.

Suzane não apagou Manfred.

Google não apagou Manfred.

O Barão Vermelho continua exatamente onde deveria estar:

nos livros de história da aviação.

nos museus.

nos arquivos da Primeira Guerra Mundial.

nos estudos sobre combate aéreo.

nas fotografias.

nas biografias.

nos modelos de Fokker.

nas histórias do Snoopy.

E agora...

neste Café.

Talvez o que tenha mudado seja simplesmente a porta pela qual chegamos até ele.

Antes:

BARÃO VERMELHO
      ↓
MANFRED

Hoje, no Brasil:

BARÃO VERMELHO
      ↓
CAZUZA
      ↓
"por que a banda chama Barão Vermelho?"
      ↓
MANFRED

E:

RICHTHOFEN
      ↓
SUZANE
      ↓
"de onde vem esse sobrenome?"
      ↓
MANFRED

Olhe só.

Talvez ele não tenha perdido completamente.

A rota ficou mais longa.


☕ Epílogo — O último combate do Barão Vermelho

Imagine Manfred acordando em 2026.

Entregamos um smartphone.

Explicamos a Internet.

Explicamos o Google.

Ele digita:

BARÃO VERMELHO.

Aparece Cazuza.

Manfred franze a testa.

— Wer ist das?

Explicamos.

Ele escuta uma música.

Talvez goste.

Então digita:

RICHTHOFEN.

Aparece Suzane.

Silêncio.

Manfred olha para nós.

Olha novamente para o telefone.

Olha para o milhão de chimpanzés.

Um chimpanzé lentamente empurra um copito de aguardente de Itatiba em sua direção.

Manfred bebe.

Respira fundo.

Pergunta:

— Então sobrevivi aos britânicos, franceses, aviões experimentais, metralhadoras sincronizadas e oitenta vitórias...

— Sim.

— ...para perder meu nome para uma banda e uma página policial brasileira?

O chimpanzé coloca a mão sobre o ombro dele.

— SEO, mein Freund.

Silêncio.

Ao longe, ouvimos um Fokker Dr.I.

Ou talvez seja Cazuza começando outra música.

Ninguém sabe mais.

O algoritmo também não.

E em algum datacenter, um crawler acaba de encontrar esta página e atualizar novamente a vizinhança semântica de:

MANFRED VON RICHTHOFEN.

Missão cumprida.

O Barão Vermelho acaba de ganhar mais uma pequena batalha.

Cento e oito anos depois.

☕🐒✈️🎸


✈️ P.S. — Mea culpa: esquecemos que o Barão Vermelho também virou anime

Antes que algum otaku especializado em história da aviação atravesse a janela do Bellacosa Mainframe empunhando uma miniatura de Fokker Dr.I:

sim, nós sabemos.

Passamos milhares de palavras reclamando que Google, Cazuza, true crime e a memória algorítmica empurraram Manfred von Richthofen para os fundos da estante...

...e conseguimos realizar a proeza de deixar de fora justamente uma das regiões da cultura pop onde o velho Barão e o arquétipo do ás da Primeira Guerra Mundial continuam voando alegremente:

anime e mangá.

Mea culpa.

Chamem os chimpanzés.

Devolvam o facão de Occam.

🐷 Primeiro pouso: Porco Rosso

Hayao Miyazaki possui uma conhecida paixão por aviação, e Porco Rosso (Kurenai no Buta, 1992) talvez seja uma das declarações de amor mais bonitas já animadas sobre máquinas voadoras e os homens absurdos que insistiam em pilotá-las.

Marco Pagot não é “o Barão Vermelho japonês”.

Seria forçar a barra até o parafuso espanar.

Mas o universo de Porco Rosso respira exatamente a mitologia que ajudou a transformar pilotos como Richthofen em personagens maiores que a própria biografia:

o ás individualista;

o piloto reconhecido pela máquina;

o duelo aéreo quase cavalheiresco;

a reputação construída nos céus;

a aeronave como extensão da personalidade;

e aquele romantismo de uma época em que o piloto ainda conseguia enxergar o rosto do homem tentando derrubá-lo.

Miyazaki pega esse imaginário, mistura Adriático, entreguerras, fascismo, hidroaviões e melancolia e produz algo completamente seu.

O resultado é curioso:

talvez alguém que jamais tenha lido uma única página sobre Manfred von Richthofen já conheça perfeitamente o arquétipo cultural que homens como ele ajudaram a construir.

🇯🇵 O Barão não desapareceu. Ele foi parar no Japão.

E Porco Rosso é apenas uma das portas.

Anime, mangá e jogos japoneses possuem uma longa paixão por ases, pilotos lendários, máquinas personalizadas, esquadrões de elite e rivais identificados por cores.

Às vezes Richthofen aparece diretamente.

Em outras, aparece apenas sua sombra cultural:

o piloto excepcional + a máquina característica + a cor distintiva + o apelido + a reputação quase mitológica.

Depois de um século copiando e remixando esse arquétipo, já nem sempre percebemos de onde ele veio.

O “Red Baron” deixou de ser apenas uma pessoa e tornou-se um trope.

E isso talvez seja uma forma de imortalidade ainda mais poderosa que aparecer em primeiro lugar numa busca.

🤖 O algoritmo pode esquecer o nome enquanto a cultura preserva o padrão

Aqui os chimpanzés acabaram de encontrar outro problema.

Nós argumentamos no artigo:

memória histórica ≠ relevância algorítmica.

Agora precisamos acrescentar:

memória cultural ≠ lembrança consciente da origem.

Uma cultura pode esquecer quem criou determinado arquétipo enquanto continua reproduzindo o arquétipo durante gerações.

O jovem assiste a um anime.

Aparece um piloto lendário.

A máquina possui uma cor característica.

Todos reconhecem seu nome.

Os inimigos temem encontrá-lo.

Ele possui uma aura quase aristocrática.

Nosso jovem pensa:

— Personagem maneiro.

Em algum lugar do além, Manfred olha para a tela:

Moment mal... eu conheço esse sujeito.

🐒

☕ Portanto, correção registrada

Cazuza não matou o Barão Vermelho.

Suzane não matou o Barão Vermelho.

Google não matou o Barão Vermelho.

E nós também não conseguiremos.

Porque talvez Manfred tenha conseguido uma façanha ainda maior do que dominar uma palavra-chave:

virou arquétipo.

O nome pode cair para a segunda página.

O apelido pode virar banda.

O sobrenome pode virar true crime.

Mas coloque novamente no céu um piloto extraordinário, uma máquina inconfundível, uma cor que todos reconhecem e uma reputação que chega antes do avião...

e alguma coisa daquele velho Barão estará voando junto.

Mesmo que ninguém perceba.

Mea culpa, Herr Richthofen.

Pode guardar o Fokker.

Os chimpanzés corrigiram o registro.

☕🐒✈️🐷

domingo, 22 de setembro de 2024

IBM Z Mainframe Security — 33 Anos de TCP/IP e o Dia em que Igor Instalou uma Porta para a Internet no Castelo

 
Bellacosa Mainframe e uma pequena historia sobre o tcp/ip sna e protocolos de rede no mundo mainframe e alem

☕ Um Café no Bellacosa Mainframe

IBM Z Mainframe Security — 33 Anos de TCP/IP e o Dia em que Igor Instalou uma Porta para a Internet no Castelo

Ou: o IBM Z continuou sendo um dos cofres mais sofisticados do planeta, mas alguém conectou Ethernet, TN3270, FTP, UNIX, APIs REST e pipelines DevOps — enquanto Igor jurava que UID(0) era apenas o número do crachá do laboratório



Prólogo — Igor, conecte o cabo. Qual cabo, doutor?

Imagine a seguinte cena.

Estamos em 1991. O datacenter está mergulhado naquela penumbra respeitável das grandes instalações. Há unidades de fita, controladoras, canais, terminais 3270, operadores carregando cartuchos 3480 e um mainframe processando a folha de pagamento de milhares de pessoas sem precisar reiniciar toda terça-feira.

No centro do laboratório, protegido por SNA, VTAM, controladoras, LUs e uma quantidade de siglas suficiente para assustar até um auditor, encontra-se o IBM Mainframe.

— Igor! — grita o doutor. — Precisamos conectar o RS/6000 ao mainframe!

— Excelente ideia, mestre! Trouxe um cabo Ethernet, um controlador 3172 e este livrinho sobre uma coisa chamada TCP/IP!

— Igor… de onde veio esse TCP/IP?

— Estava numa caixa marcada “Abby Normal Networking”.

O raio cai.

As luzes piscam.

O controlador 3172 desperta.

E, naquele instante simbólico, o mainframe deixa de conversar apenas dentro de seu universo proprietário e passa a participar de uma rede baseada nos mesmos protocolos usados por estações UNIX, servidores, computadores pessoais e, futuramente, pela Internet.

O monstro abre os olhos.

— Está vivo!

Sim, estava vivo. E agora tinha endereço IP.

Essa é a história dos aproximadamente 35 anos de convivência entre TCP/IP e IBM Z. Não é uma história sobre o TCP/IP ter destruído a segurança do mainframe. É a história de como um ambiente extremamente especializado ganhou os benefícios — e também os riscos — de participar de uma rede universal.

A grande conclusão pode ser colocada dentro da WORKING-STORAGE:

01  SEGURANCA-DO-MAINFRAME.
    05 PLATAFORMA-SECURAVEL PIC X(03) VALUE 'SIM'.
    05 AMBIENTE-SEGURO      PIC X(07) VALUE 'DEPENDE'.

O IBM Z é uma plataforma extraordinariamente securável.

Mas “securável” não é sinônimo de “segura”.


1. Securável não significa automaticamente segura

Quando alguém afirma que o IBM Z é uma das plataformas mais seguras do mundo, existe uma boa razão.

Ao longo de décadas, a arquitetura acumulou mecanismos como:

  • isolamento por LPAR;

  • proteção de memória;

  • níveis de autorização;

  • RACF, ACF2 ou Top Secret;

  • System Authorization Facility, o SAF;

  • registros SMF;

  • separação entre usuários, grupos e processos;

  • criptografia em hardware;

  • gerenciamento de certificados;

  • proteção de bibliotecas autorizadas;

  • controle de datasets;

  • controle de comandos;

  • auditoria de acessos;

  • segurança para CICS, IMS, Db2, MQ e USS;

  • IP filtering;

  • IPsec;

  • AT-TLS;

  • zERT;

  • controle de portas;

  • detecção de intrusão.

É um belo laboratório.

O problema começa quando Igor encontra uma configuração difícil e resolve aplicar o método científico conhecido como:

“Dê autoridade total, faça funcionar e depois a gente revisa.”

O “depois” geralmente ocorre quinze anos mais tarde, durante uma auditoria, quando ninguém mais se lembra por que uma started task precisa de UID(0), acesso ALTER a uma árvore inteira de datasets e permissão para usar uma porta que oficialmente foi desativada em 2007.

A diferença é simples:

Securável é aquilo que a plataforma permite fazer.

Seguro é aquilo que a organização realmente configurou, monitorou, testou e manteve.

Um cofre pode possuir aço reforçado, sensores, câmeras e fechadura biométrica. Se alguém deixar a porta aberta porque o fornecedor precisava entregar café, a resistência do aço deixa de ser a questão principal.


2. Antes do TCP/IP: o castelo protegido por SNA

Para o programador COBOL iniciante, SNA pode parecer uma criatura encontrada nos porões do museu da IBM.

SNA significa Systems Network Architecture. Durante muitos anos, foi o grande modelo de comunicação dos ambientes IBM.

Nele apareciam conceitos como:

  • VTAM;

  • unidades físicas;

  • unidades lógicas;

  • LUs;

  • sessões;

  • BIND;

  • controladores;

  • subáreas;

  • APPN;

  • LU 6.2;

  • terminais 3270.

Não era uma arquitetura simples para um desconhecido.

Para alcançar uma aplicação, não bastava perguntar:

Qual é o endereço IP?
Qual é a porta?

Era necessário conhecer uma topologia e um conjunto de protocolos muito específicos do universo IBM.

Isso criava uma barreira natural. Um invasor familiarizado apenas com PCs, DOS ou UNIX podia olhar para aquele ambiente como Igor olhando para uma JCL de cinquenta passos:

— Doutor, tenho certeza de que isto faz alguma coisa, mas não pretendo encostar.

Entretanto, não devemos romantizar essa barreira.

SNA não era segura apenas porque poucas pessoas a conheciam. Obscuridade pode aumentar o esforço necessário para um ataque, mas não substitui autenticação, autorização, criptografia, segmentação e monitoramento.

O castelo era difícil de compreender. Isso não significa que suas muralhas não precisassem ser inspecionadas.

Curiosidade de laboratório

Muitas transações bancárias e corporativas que o consumidor executava sem pensar — inclusive operações em terminais e caixas eletrônicos — passavam por uma infraestrutura baseada em tecnologias IBM, CICS, IMS, VTAM e SNA.

Contudo, seria exagerado dizer que SNA é simplesmente “o protocolo de transação do CICS e do IMS”. Esses subsistemas evoluíram e suportam diferentes formas de comunicação. Hoje podem conversar por TCP/IP, MQ, APIs, conectores e diversas outras interfaces.

O monstro recebeu novos braços. Ele não precisou arrancar os antigos.


3. O controlador 3172 e a nova avenida até o mainframe

No início da década de 1990, empresas começaram a integrar seus mainframes com estações RS/6000 executando AIX e outras máquinas presentes em redes locais.

Um dos equipamentos importantes nessa transição foi o IBM 3172 Interconnect Controller.

Pense nele como um tradutor instalado na entrada do castelo. De um lado, o universo dos canais e do mainframe. Do outro, Ethernet, Token Ring, FDDI e os protocolos que circulavam pela rede corporativa.

O benefício era gigantesco:

  • integração entre plataformas;

  • transferência de arquivos;

  • acesso remoto;

  • compartilhamento de recursos;

  • comunicação com UNIX;

  • substituição progressiva de terminais físicos por emuladores;

  • utilização de padrões abertos.

Mas a consequência arquitetônica era igualmente importante:

Do ponto de vista da rede, o mainframe agora era um nó IP.

Isso não significa que ele tenha perdido sua arquitetura interna. LPAR, SAF, RACF e proteção de memória continuavam existindo.

Significa que agora havia uma avenida padronizada chegando até ele.

Um endereço IP pode representar:

  • uma interface;

  • um serviço;

  • uma rota;

  • uma possibilidade de administração;

  • uma dependência;

  • uma entrada;

  • uma saída;

  • uma superfície de ataque.

O protocolo não é culpado. A questão é quem consegue alcançar o endereço, quais portas estão disponíveis, que serviços escutam nessas portas e como esses serviços foram protegidos.


4. TN3270: o terminal verde mudou de roupa

Antes, era comum encontrar terminais 3270 físicos ligados à infraestrutura IBM.

Com o TN3270, um computador pessoal passou a executar um emulador de terminal e estabelecer uma conexão sobre TCP/IP.

Para o usuário, o resultado parecia familiar: a velha tela verde.

Por baixo do capô, porém, o caminho havia mudado.

De maneira simplificada:

  1. O computador abre uma conexão TCP.

  2. O cliente e o servidor negociam TN3270 ou TN3270E.

  3. O servidor Telnet do z/OS recebe a sessão.

  4. Uma LU pode ser selecionada ou associada.

  5. O VTAM conduz a sessão até uma aplicação.

  6. O usuário encontra TSO, CICS ou outro destino.

  7. SAF e o gerenciador de segurança participam da autenticação e autorização.

Portanto, TN3270 não simplesmente matou SNA.

Em muitos cenários, TCP/IP passou a levar o usuário até uma fronteira na qual VTAM e os conceitos 3270 continuavam trabalhando.

É como substituir a estrada de terra até o castelo por uma rodovia asfaltada. O salão interno continua o mesmo, mas muito mais gente conhece o caminho até a portaria.

O perigo do terminal sem proteção

Considere um ambiente antigo:

  • TN3270 disponível numa rede extensa;

  • ausência de TLS;

  • tela de logon identificando claramente a organização;

  • mensagens diferentes para usuário válido e inválido;

  • IDs antigos ainda ativos;

  • pouca correlação entre tentativas de acesso;

  • emuladores sem controle;

  • credenciais reutilizadas.

Um atacante não precisa “quebrar o mainframe”. Ele pode capturar uma credencial antes de ela chegar ao RACF.

Depois, quando fizer logon, o sistema verá uma identidade aparentemente legítima.

O RACF terá feito seu trabalho corretamente. Quem falhou foi o caminho anterior à catraca.

Como proteger TN3270

Uma implementação moderna deve considerar:

  • TLS obrigatório;

  • protocolos e cifras atualizados;

  • certificados corretamente administrados;

  • limitação das redes de origem;

  • associação controlada de LUs;

  • restrição das aplicações disponíveis;

  • autenticação baseada em SAF;

  • certificados de cliente quando apropriado;

  • limitação de tentativas;

  • monitoramento dos registros;

  • mensagens que não facilitem enumeração de usuários;

  • MFA ou mecanismos equivalentes onde a arquitetura permitir.

Eis o primeiro princípio de Igor:

Uma tela verde não fica invisível apenas porque combina com a parede do laboratório.


5. OpenEdition, OMVS e o UNIX escondido no porão

A chegada do TCP/IP coincidiu com outra transformação importante: a introdução de um ambiente compatível com POSIX no sistema operacional.

Primeiro veio OpenEdition MVS. Depois, esse universo evoluiu para aquilo que hoje chamamos de z/OS UNIX System Services, ou USS.

O sysprog acostumado com:

  • datasets;

  • catálogos;

  • PDS e PDSE;

  • JCL;

  • TSO;

  • RACF;

  • comandos MVS;

passou a precisar entender:

  • diretórios;

  • arquivos;

  • proprietário;

  • grupo;

  • permissões;

  • UID;

  • GID;

  • processos;

  • shells;

  • daemons;

  • links simbólicos;

  • sockets;

  • sistemas de arquivos HFS e posteriormente zFS;

  • variáveis de ambiente.

Foi como encontrar uma escada atrás do painel do ISPF e descobrir que existia um UNIX inteiro morando no porão.

— Igor, por que há um diretório /etc dentro do mainframe?

— Não sei, doutor. Mas encontrei também /var, /tmp e uma criatura chamada inetd.

O problema não era apenas técnico. Era cultural.

Muitos profissionais dominavam profundamente MVS, JES2, VTAM, CICS e storage, mas não tinham sido formados em UNIX. Outros especialistas conheciam UNIX e TCP/IP, mas não compreendiam RACF, APF, SAF, subsistemas ou integridade do z/OS.

O risco crescia justamente no espaço entre as equipes.


6. A dupla identidade: RACF encontra UID e GID

No ambiente tradicional, um usuário possui uma identidade conhecida pelo gerenciador de segurança:

BELLACO

Quando esse usuário também precisa utilizar USS, seu perfil recebe um segmento OMVS contendo informações como:

UID
GID
HOME
PROGRAM

Assim, o mesmo indivíduo passa a existir nos dois mundos.

No universo z/OS tradicional, sua autoridade é controlada por perfis, classes, grupos e permissões do ESM.

No universo UNIX, entram também:

  • proprietário;

  • grupo;

  • bits de permissão;

  • ACLs;

  • UID;

  • GID;

  • perfis da classe UNIXPRIV;

  • recursos BPX;

  • controle de programas.

Isso não significa que USS seja um sistema separado abandonado no porão. A segurança UNIX é integrada ao SAF e ao gerenciador de segurança.

Mas essa integração só funciona adequadamente se for configurada e compreendida.

Exemplo para o COBOLzeiro

Imagine um programa COBOL que precisa ler um arquivo no USS.

Não basta considerar apenas:

O usuário tem acesso ao dataset?

Agora é necessário verificar:

  • quem é o proprietário do arquivo;

  • qual é o grupo;

  • quais permissões estão ativas;

  • se existe ACL;

  • qual UID executa o processo;

  • como a aplicação foi iniciada;

  • se há privilégios adicionais;

  • se o caminho inteiro até o arquivo permite acesso;

  • se um link simbólico pode redirecionar a operação.

É uma segunda árvore de decisões de segurança.


7. UID(0): a chave mestra encontrada no bolso de Igor

No UNIX, UID 0 representa o superusuário.

Ele possui uma capacidade extraordinária dentro do ambiente USS.

Não é tecnicamente idêntico a conceder SPECIAL no RACF, pois os domínios são diferentes. Entretanto, a comparação ajuda o iniciante a compreender o tamanho do risco.

Durante décadas, alguns procedimentos de instalação disseram:

“Defina a started task com UID(0).”

Em certos casos, isso podia ser tecnicamente necessário. Em outros, era apenas uma forma rápida de evitar o trabalho de descobrir quais privilégios específicos o produto realmente exigia.

O fluxo era conhecido:

  1. O software falhava durante a instalação.

  2. O fornecedor dizia que faltava autoridade.

  3. Alguém atribuía UID(0).

  4. O produto funcionava.

  5. A mudança entrava em produção.

  6. A revisão ficava para depois.

  7. Quinze anos mais tarde, ninguém sabia remover o privilégio.

É o famoso padrão PERFORM ATE-QUE-FUNCIONE.

O z/OS oferece mecanismos mais granulares, incluindo perfis como:

  • BPX.SUPERUSER;

  • BPX.DAEMON;

  • BPX.SERVER;

  • recursos da classe UNIXPRIV;

  • program control;

  • permissões específicas de filesystem.

A solução correta deve ser determinada conforme o produto e a função necessária.

O princípio é o menor privilégio:

Se o processo precisa abrir uma porta, não lhe dê autoridade para ressuscitar todos os mortos do cemitério.

Dica prática

Crie um inventário contendo:

  • todos os usuários com UID(0);

  • justificativa;

  • produto responsável;

  • proprietário técnico;

  • documentação do fornecedor;

  • alternativa granular disponível;

  • data da última revisão;

  • plano de remoção ou aceitação formal do risco.

Se ninguém souber explicar por que o privilégio existe, ele já merece investigação.


8. TCP/IP não enfraqueceu o mainframe: ampliou a superfície

É tentador dizer que a chegada do TCP/IP aumentou “exponencialmente” a probabilidade de ataque.

A ideia geral faz sentido, mas a palavra “exponencialmente” exigiria evidência matemática. O que podemos afirmar com segurança é que TCP/IP produziu três mudanças fundamentais.

8.1 Padronização

Atacantes e administradores conhecem:

  • TCP;

  • UDP;

  • portas;

  • DNS;

  • FTP;

  • Telnet;

  • SSH;

  • HTTP;

  • TLS;

  • APIs.

Já não é necessário dominar toda a arquitetura SNA para começar a reconhecer o ambiente.

8.2 Alcance

Um terminal físico tinha localização e conexão relativamente previsíveis.

Uma porta TCP pode ser alcançada por:

  • outra VLAN;

  • uma VPN;

  • um parceiro;

  • um servidor comprometido;

  • uma estação administrativa;

  • uma nuvem;

  • uma conexão de contingência;

  • ou, por erro de configuração, pela Internet.

8.3 Multiplicação de serviços

O assunto deixou de ser apenas TN3270.

Hoje o IBM Z pode oferecer ou consumir:

  • FTP e FTPS;

  • SSH e SFTP;

  • DNS;

  • SMTP;

  • SNMP;

  • NFS;

  • MQ;

  • APIs REST;

  • z/OSMF;

  • Zowe;

  • z/OS Connect;

  • servidores Java;

  • bancos de dados;

  • agentes de monitoramento;

  • serviços DevOps;

  • integrações com cloud e OpenShift.

Cada serviço traz:

  • uma porta;

  • uma identidade;

  • uma configuração;

  • certificados;

  • bibliotecas;

  • logs;

  • dependências;

  • vulnerabilidades;

  • um ciclo de atualização.


9. As sete portas do castelo

Para compreender segurança TCP/IP no z/OS, pense em sete camadas.

Porta 1 — Alcance de rede

Quem consegue chegar ao endereço?

Aqui entram:

  • firewalls;

  • VLANs;

  • roteamento;

  • VPN;

  • segmentação;

  • redes administrativas;

  • zonas de segurança;

  • controle de entrada e saída.

Se um serviço é usado apenas pela equipe interna, não deveria estar acessível a uma rede muito maior que a necessária.

Porta 2 — A pilha TCP/IP

O que a stack aceitará?

O z/OS Communications Server oferece controles como:

  • IP filtering;

  • IPsec;

  • múltiplas stacks;

  • políticas;

  • IDS;

  • restrições por interface;

  • controle de roteamento;

  • proteção de VIPAs.

Porta 3 — A porta propriamente dita

Qual processo pode abrir ou usar determinado número de porta?

As definições PORT e PORTRANGE, junto aos controles SAF, ajudam a reservar portas para aplicações e identidades específicas.

Imagine que a porta 5000 pertença à started task PAGADOR.

Sem reserva apropriada, outro processo poderia tentar ocupar a porta quando o serviço legítimo estivesse parado.

Com controle adequado, a stack sabe que aquela porta pertence ao serviço autorizado.

Porta 4 — O transporte

Os dados viajam protegidos?

Aqui entram:

  • TLS;

  • AT-TLS;

  • SSH;

  • IPsec;

  • certificados;

  • algoritmos;

  • key rings.

Uma conexão autenticada, mas transmitida em claro, ainda pode expor credenciais e informações.

Porta 5 — A identidade

Quem é o usuário ou processo?

Aqui trabalham:

  • SAF;

  • RACF;

  • ACF2;

  • Top Secret;

  • certificados;

  • IDs técnicos;

  • grupos;

  • perfis;

  • passphrases;

  • autenticação multifator.

Porta 6 — A aplicação

Mesmo autenticado, o que o usuário pode fazer?

É nesse ponto que entram:

  • transações CICS;

  • comandos;

  • recursos Db2;

  • filas MQ;

  • APIs;

  • datasets;

  • funções administrativas;

  • regras de negócio.

Autenticação responde “quem é você?”. Autorização responde “o que você pode fazer?”. A lógica de negócio ainda precisa responder “esta operação faz sentido?”.

Porta 7 — A evidência

Se algo acontecer, saberemos?

Aqui entram:

  • SMF;

  • logs de aplicação;

  • registros RACF;

  • SMF 119;

  • zERT;

  • SIEM;

  • alertas;

  • correlação;

  • retenção;

  • investigação.

Um log que ninguém lê é apenas o diário secreto do monstro.


10. SAF também protege a rede

O iniciante frequentemente associa SAF apenas à tentativa de abrir um dataset.

Mas o Communications Server também pode consultar SAF para decisões relacionadas à rede.

A classe SERVAUTH, por exemplo, pode participar de controles associados a:

  • acesso a redes;

  • utilização de portas;

  • serviços;

  • funções administrativas;

  • recursos Telnet;

  • comandos do Communications Server.

Isso permite sair de uma decisão simples:

A porta está aberta?

E chegar a uma decisão mais madura:

Esta identidade está autorizada a utilizar esta função de rede?

A porta não deve ser apenas um número escutando no escuro. Ela deve possuir proprietário, aplicação, identidade, justificativa e monitoramento.

Dica do Igor

Crie uma tabela para cada stack TCP/IP:

PortaServiçoStarted taskCriptografiaOrigem permitidaProprietário
992TN3270 seguroTN3270TLSRede corporativaInfraestrutura
22SSH/SFTPSSHDSSHRede administrativaSegurança
443APIZOSCONNTLSGateway autorizadoAplicações

Se aparecer uma porta que ninguém reconhece, não pergunte primeiro se pode fechá-la.

Pergunte por que uma porta desconhecida conseguiu permanecer aberta.


11. AT-TLS: colocando criptografia sem operar o coração do COBOL

AT-TLS significa Application Transparent Transport Layer Security.

Imagine uma aplicação antiga que utiliza sockets TCP, mas não sabe executar TLS. Alterar seu programa-fonte pode ser caro, arriscado ou demorado.

Com AT-TLS, o Communications Server pode aplicar TLS conforme políticas administradas pelo Policy Agent.

Para a aplicação, a comunicação ainda pode parecer um socket comum. A pilha realiza a negociação criptográfica.

É como se Igor colocasse um casaco blindado no pacote sem precisar modificar o cérebro da criatura.

Mas existe um detalhe importante: o AT-TLS não é magia.

É necessário definir:

  • qual tráfego será protegido;

  • origem e destino;

  • porta;

  • direção;

  • protocolos TLS permitidos;

  • certificados;

  • key rings;

  • autenticação do cliente;

  • comportamento em caso de falha;

  • registro e monitoramento.

Uma política configurada de maneira errada pode proteger o tráfego errado ou permitir comunicação sem TLS quando a intenção era bloqueá-la.

Por isso, não basta perguntar:

“Temos AT-TLS?”

A pergunta correta é:

“Quais conexões estão realmente protegidas, por qual política, usando qual versão de TLS e qual certificado?”


12. zERT: o inspetor que verifica se o casaco foi realmente vestido

zERT significa z/OS Encryption Readiness Technology.

Ele ajuda a descobrir e registrar atributos criptográficos das conexões.

Isso permite verificar:

  • se a conexão utilizou criptografia;

  • qual protocolo foi negociado;

  • qual versão;

  • quais algoritmos;

  • quais características de proteção;

  • quais fluxos permanecem sem criptografia.

Essa distinção é fundamental.

A documentação da aplicação pode dizer:

TODAS AS CONEXÕES DEVEM USAR TLS.

Mas a realidade pode ser:

97% usam TLS.
2% usam configuração antiga.
1% atravessa o laboratório sem calças.

O zERT ajuda a encontrar esse 1%.

A segurança madura não confia apenas na intenção da configuração. Ela observa o comportamento real.


13. SMF 119: a câmera da portaria

O Communications Server pode produzir registros SMF 119 relacionados a:

  • início e término de conexões;

  • estatísticas TCP/IP;

  • portas;

  • FTP;

  • túneis IPsec;

  • DVIPAs;

  • TN3270;

  • informações coletadas pelo zERT.

Com esses registros, a organização pode investigar:

  • quem se conectou;

  • quando;

  • de qual endereço;

  • em qual porta;

  • por quanto tempo;

  • usando qual proteção;

  • com qual comportamento;

  • em que volume.

Mas registrar não basta.

O processo ideal é:

  1. Coletar os registros.

  2. Preservá-los.

  3. Normalizá-los.

  4. Enviá-los ao SIEM.

  5. Correlacioná-los com RACF, CICS, Db2, USS e firewall.

  6. Criar alertas úteis.

  7. Investigar os desvios.

  8. Aprender com os incidentes.

Se o atacante fizer mil tentativas de conexão e o registro dormir numa fita até a auditoria anual, o sistema possui evidência, mas não possui defesa operacional.


14. Auditoria, STIG e pentest: os três médicos do monstro

Uma auditoria de segurança continua sendo importante.

Ela verifica políticas, segregação de funções, controles, evidências, conformidade e governança.

As STIGs ajudam a comparar configurações com baselines de endurecimento.

O IBM Health Checker pode examinar configurações ativas e compará-las com recomendações ou políticas definidas pela organização.

O pentest faz outra pergunta:

Um atacante autorizado consegue transformar essas fraquezas em impacto real?

Nenhuma dessas atividades substitui as demais.

Auditoria

Pergunta se o processo e os controles existem e são cumpridos.

Baseline ou STIG

Pergunta se a configuração está alinhada a um padrão seguro.

Vulnerability assessment

Procura vulnerabilidades conhecidas.

Pentest

Tenta explorar caminhos autorizados dentro de um escopo definido.

Purple team

Coloca atacantes e defensores colaborando para melhorar prevenção, detecção e resposta.

Monitoramento contínuo

Pergunta o que mudou depois da última fotografia.

Passar numa auditoria em março não prova que o ambiente continua seguro em agosto.

Segurança não é um JOB que termina com:

IEF142I SECURITY STEP WAS EXECUTED
MAXCC=0000

É uma started task permanente.


15. O atacante também ganhou um emulador

Em 1999, o projeto Hercules tornou possível emular arquiteturas mainframe em computadores comuns.

Seu valor educacional é imenso. Estudantes, pesquisadores e desenvolvedores passaram a experimentar sistemas históricos sem possuir um mainframe físico.

Documentação eletrônica, manuais, fóruns, ferramentas e ambientes de laboratório também reduziram a barreira de entrada.

Isso não significa que Hercules tenha “causado” invasões.

A ferramenta democratizou conhecimento. O mesmo conhecimento pode ser utilizado por:

  • estudantes;

  • desenvolvedores;

  • administradores;

  • pesquisadores;

  • pentesters;

  • atacantes.

O problema começa quando o invasor estuda o ambiente com mais profundidade que a equipe responsável por defendê-lo.

Hoje existem scanners e ferramentas capazes de reconhecer TN3270, identificar telas, testar configurações e auxiliar pesquisas de segurança.

O atacante já não está tateando no escuro.

Ele possui:

  • documentação;

  • scripts;

  • automação;

  • ambientes de teste;

  • mecanismos de busca;

  • inteligência artificial;

  • décadas de conhecimento acumulado.

Igor já não precisa roubar o manual do laboratório. Ele pode baixá-lo.


16. Três ataques que não precisam “quebrar o mainframe”

Primeiro ataque — roubar a credencial antes do RACF

  1. O usuário conecta-se por um protocolo sem criptografia.

  2. A rede utilizada está comprometida.

  3. A credencial é capturada.

  4. O atacante faz logon.

  5. O RACF reconhece uma identidade válida.

O RACF não foi derrotado. A credencial foi roubada antes da catraca.

Segundo ataque — explorar uma started task privilegiada

  1. Um produto executa com UID(0).

  2. O produto possui uma vulnerabilidade.

  3. O invasor compromete o processo.

  4. A autoridade excessiva amplia o impacto.

  5. A falha do produto torna-se uma falha do ambiente.

Por isso, menor privilégio limita o chamado raio da explosão.

Terceiro ataque — usar corretamente uma API mal protegida

  1. Uma credencial técnica de parceiro é comprometida.

  2. O atacante envia uma requisição formalmente válida.

  3. TLS funciona.

  4. O certificado funciona.

  5. RACF autoriza a conta.

  6. A aplicação não percebe que a transação é fraudulenta.

Tudo funcionou conforme configurado.

Esse é o terror elegante da segurança: controles técnicos corretos podem proteger uma operação de negócio mal concebida.


17. A arqueologia das configurações esquecidas

Os maiores riscos nem sempre foram instalados ontem.

Muitas vezes estão preservados como fósseis:

  • FTP ativo sem necessidade;

  • conta genérica sem proprietário;

  • UID(0) concedido em 1998;

  • diretório USS com permissão excessiva;

  • porta liberada para um parceiro que não existe mais;

  • segunda stack TCP/IP esquecida;

  • LPAR de contingência menos protegida;

  • certificado antigo;

  • started task com autoridade exagerada;

  • biblioteca APF contendo software desatualizado;

  • regra de firewall criada “temporariamente”;

  • usuário de emergência usado no cotidiano.

A longevidade é uma das maiores virtudes do mainframe.

Mas longevidade sem revisão transforma compatibilidade em dívida histórica de segurança.

Dica prática

Para cada exceção, registre:

  • o que é;

  • por que existe;

  • quem é o proprietário;

  • qual risco produz;

  • qual sistema depende dela;

  • quando foi revisada;

  • quando será removida;

  • qual controle compensatório existe.

Se a justificativa for “sempre foi assim”, Igor encontrou outro cérebro Abby Normal.


18. Passphrases: o parafuso estava invertido

O texto original afirma que passphrases seriam exponencialmente mais fáceis de quebrar que passwords.

Provavelmente houve uma inversão.

Uma passphrase longa, imprevisível e não reutilizada tende a ser muito mais resistente que uma senha curta.

Compare:

Senha curta:
V@gner12

Com uma frase longa e exclusiva:

Cafe-Lunar-Visita-7-Mainframes-Curiosos

Isso não significa copiar uma frase famosa, uma letra de música ou uma citação encontrada no LinkedIn. Comprimento sem imprevisibilidade pode criar apenas uma senha longa e óbvia.

Também não basta trocar senhas por passphrases e esquecer:

  • MFA;

  • bloqueio de credenciais comprometidas;

  • proteção contra phishing;

  • monitoração;

  • gerenciamento de contas;

  • autenticação por certificados;

  • passkeys onde aplicáveis.

E nunca devemos expor publicamente as senhas encontradas durante uma auditoria. A equipe pode apresentar padrões, categorias e estatísticas sem constranger usuários nem divulgar credenciais.

O objetivo é ensinar, não realizar um episódio de “Frau Blücher lê as senhas no auditório” — e todos os cavalos do datacenter relincham.


19. Computação quântica: o monstro ainda não comeu toda a criptografia

Existe uma ameaça real chamada harvest now, decrypt later.

Um adversário pode capturar dados criptografados hoje e guardá-los para tentar decifrá-los no futuro, quando computadores quânticos suficientemente poderosos estiverem disponíveis.

Mas isso não significa que toda criptografia desaparecerá de uma vez.

A preocupação principal envolve certos algoritmos de chave pública, como RSA e criptografia baseada em curvas elípticas.

O caminho correto é desenvolver criptoagilidade.

Passo a passo

  1. Inventarie certificados e algoritmos.

  2. Descubra onde RSA e ECC são utilizados.

  3. Identifique dados que precisam permanecer secretos por muitos anos.

  4. Localize protocolos e aplicações difíceis de atualizar.

  5. Avalie fornecedores e parceiros.

  6. Planeje a adoção de algoritmos pós-quânticos.

  7. Teste mecanismos híbridos.

  8. Defina renovação e substituição de certificados.

  9. Considere arquivos e backups conforme sua vida útil e sensibilidade.

  10. Repita o inventário periodicamente.

Não é necessário recriptografar, às cegas, cada cartucho produzido desde o Império Romano.

É necessário saber quais dados continuam sensíveis, quais algoritmos os protegem e quanto tempo essa proteção precisa durar.


20. O honeypot de Igor

A ideia de criar um ambiente isolado para observar tentativas de ataque pode ser útil.

Mas não devemos simplesmente abrir uma porta na Internet ligada à produção e anunciar:

— Igor, veja quem aparece!

Um laboratório, cyber range ou honeypot deve possuir:

  • autorização formal;

  • isolamento completo;

  • nenhuma informação verdadeira;

  • identidades artificiais;

  • controle de saída;

  • monitoramento detalhado;

  • limites de recursos;

  • plano de reconstrução;

  • ausência de rotas confiáveis para produção;

  • supervisão da equipe de segurança.

O objetivo é estudar o adversário.

Não é oferecer ao adversário um apartamento mobiliado no datacenter.


21. A nova fronteira: APIs, DevOps e nuvem

Em 1991, a discussão principal envolvia Ethernet, RS/6000, TN3270, FTP e UNIX.

Em 2024, a superfície inclui:

  • z/OSMF;

  • Zowe;

  • z/OS Connect;

  • APIs REST;

  • OpenSSH;

  • Git;

  • VS Code;

  • pipelines CI/CD;

  • Ansible;

  • Python;

  • Java;

  • containers;

  • zCX;

  • OpenShift;

  • observabilidade;

  • integração com cloud;

  • tokens;

  • secrets;

  • identidades de serviço;

  • cadeia de suprimentos de software.

Agora o risco pode surgir antes mesmo de o módulo chegar ao mainframe.

Uma credencial comprometida no pipeline pode modificar código. Uma extensão maliciosa pode capturar tokens. Um artefato adulterado pode entrar numa biblioteca. Uma API permissiva pode alcançar uma transação legítima por um caminho que os autores originais jamais imaginaram.

Por isso, modernização e segurança não são dois projetos executados em sequência.

Segurança deve estar dentro da modernização:

  • no desenho;

  • no código;

  • no build;

  • no deploy;

  • na identidade;

  • na rede;

  • nos testes;

  • nos logs;

  • na operação.


22. Plano de 90 dias para apertar os parafusos

Dias 1 a 30 — Descobrir

  1. Inventarie todas as stacks TCP/IP.

  2. Liste interfaces, VIPAs e rotas.

  3. Identifique portas abertas.

  4. Relacione cada porta a uma started task.

  5. Localize TN3270, FTP, SSH, APIs e z/OSMF.

  6. Identifique conexões sem criptografia.

  7. Liste usuários com UID(0).

  8. Examine permissões de arquivos críticos no USS.

  9. Localize IDs genéricos e contas sem proprietário.

  10. Verifique quais registros SMF são produzidos.

Dias 31 a 60 — Reduzir

  1. Feche serviços não utilizados.

  2. Restrinja redes de origem.

  3. Revise regras de firewall.

  4. Implemente ou fortaleça TLS e AT-TLS.

  5. Remova UID(0) quando houver alternativa segura.

  6. Corrija permissões USS.

  7. Desative contas órfãs.

  8. Reserve portas para as identidades corretas.

  9. Atualize produtos e correções.

  10. Documente exceções.

Dias 61 a 90 — Provar

  1. Execute uma avaliação de vulnerabilidades.

  2. Realize pentest autorizado.

  3. Teste controles SAF de rede.

  4. Integre SMF ao SIEM.

  5. Crie alertas para tentativas anormais.

  6. Simule credencial comprometida.

  7. Simule abuso de conta técnica.

  8. Teste resposta a incidente.

  9. Verifique se a equipe detectou o exercício.

  10. Registre riscos residuais e responsáveis.

Depois, execute novamente.

Segurança é um ciclo, não um projeto com festa de encerramento.


23. O encontro das gerações

Existe uma oportunidade maravilhosa nessa transformação.

De um lado, está o profissional veterano que conhece:

  • MVS;

  • RACF;

  • VTAM;

  • JES2;

  • CICS;

  • IMS;

  • canais;

  • integridade;

  • operação;

  • décadas de comportamento do ambiente.

Do outro, está o profissional mais novo que conhece:

  • Linux;

  • UNIX;

  • Python;

  • redes;

  • APIs;

  • VS Code;

  • containers;

  • pentest;

  • SIEM;

  • automação;

  • cloud.

Nenhum deles possui sozinho todo o mapa.

O veterano pode enxergar uma autoridade perigosa que o especialista em Linux não compreende.

O profissional moderno pode reconhecer uma exposição TCP/IP que o especialista tradicional nunca aprendeu a procurar.

Quando trabalham juntos, nasce uma equipe realmente poderosa.

O objetivo não é criar “eles contra nós”.

É colocar Gene Wilder, Igor, o COBOLzeiro, o hacker ético, o administrador RACF e o especialista em redes em volta da mesma mesa — preferencialmente antes da tempestade.


Epílogo — Puttin’ on the Ritz sobre TCP/IP

O IBM Z não perdeu sua segurança quando recebeu TCP/IP.

Ele ganhou conectividade.

E conectividade sempre cobra seu preço em superfície de ataque, complexidade, identidade, configuração e monitoramento.

A plataforma continua oferecendo alguns dos mecanismos defensivos mais sofisticados da indústria. Mas nenhum processador, HSM, ESM ou algoritmo consegue proteger sozinho um ambiente no qual:

  • ninguém revisa as portas;

  • contas antigas continuam ativas;

  • FTP transmite dados em claro;

  • processos executam com UID(0) sem necessidade;

  • certificados são esquecidos;

  • logs não são analisados;

  • exceções temporárias tornam-se permanentes;

  • a auditoria anual é confundida com segurança contínua.

O atacante não precisa derrotar simultaneamente RACF, SAF, LPAR, criptografia, CICS, Db2, VTAM e toda a arquitetura IBM Z.

Ele precisa encontrar apenas:

  • uma credencial;

  • uma porta;

  • uma configuração;

  • um produto vulnerável;

  • uma conta privilegiada;

  • um parceiro comprometido;

  • um diretório mal protegido;

  • um parafuso que Igor esqueceu de apertar.

Por isso, depois de aproximadamente 35 anos de TCP/IP, a pergunta não deve ser:

“O mainframe é seguro?”

A pergunta correta é:

“Nós conseguimos provar, hoje, que cada caminho até o mainframe está identificado, protegido, monitorado e testado?”

Se a resposta for sim, excelente.

Pode chamar a banda.

O mainframe coloca cartola e fraque. Igor sobe no palco. A criatura começa a dançar.

— Puttin’ on the Ritz!

Mas se ninguém souber quem abriu a porta 23, por que determinada started task possui UID(0) ou para onde aquela conexão FTP está enviando arquivos todas as madrugadas…

Bem, companheiro…

Talvez o cérebro instalado no laboratório fosse realmente Abby Normal.

sábado, 21 de setembro de 2024

A História da Integração Corporativa sem Mistérios

Bellacosa Mainframe e a historia da integracao corporativa sem misterios

 

☕ Um Café no Bellacosa Mainframe

A História da Integração Corporativa sem Mistérios

Do arquivo sequencial ao IBM App Connect Enterprise: o guia definitivo para o programador COBOL Padawan entender como os sistemas aprenderam a conversar

“A tecnologia muda, os protocolos ganham novos nomes, mas a missão permanece: conectar, transformar e entregar valor.”

Imagine a seguinte cena.

Você está sentado diante de uma tela verde, analisando um programa COBOL que lê um arquivo sequencial, consulta uma tabela Db2 e grava registros em um dataset de saída. Até aí, tudo parece familiar.

Então alguém da arquitetura chega e diz:

— Precisamos publicar esses dados em uma API, enviar eventos para o Kafka, integrar com o Salesforce, consumir um serviço REST e encaminhar mensagens para uma aplicação que está rodando no OpenShift.

O programador COBOL Padawan olha para o terminal, respira fundo e pensa:

— Em que momento meu arquivo FB de 80 posições virou parte de uma arquitetura intergaláctica?

Calma, jovem aprendiz.

Apesar dos nomes modernos, dos diagramas coloridos e das apresentações carregadas de expressões como cloud-native, event-driven, API-led e composable integration, o problema central continua sendo o mesmo enfrentado pelos profissionais de tecnologia há décadas:

como fazer sistemas diferentes trocarem informações com segurança, confiabilidade e significado?

Esta é a história da integração corporativa.

Uma história que começou com arquivos, passou por conexões ponto a ponto, middleware, barramentos de serviço, SOA, APIs, nuvem, eventos e inteligência artificial.

E, ao contrário do que alguns imaginam, o mainframe não ficou assistindo a essa evolução de longe. Ele participou de praticamente todas as fases.

Prepare sua caneca, ajuste o brilho do terminal 3270 e venha conhecer a longa jornada que transformou arquivos em APIs, transações em eventos e sistemas isolados em ecossistemas digitais.


1. O que é integração corporativa?

Integração corporativa é o conjunto de técnicas, padrões, programas e plataformas utilizados para permitir que diferentes sistemas compartilhem dados e coordenem processos.

Esses sistemas podem estar:

  • no mesmo computador;

  • em servidores diferentes;

  • em sistemas operacionais diferentes;

  • em empresas diferentes;

  • em nuvens diferentes;

  • em tecnologias criadas com décadas de distância.

Imagine um banco.

O banco pode possuir:

  • um sistema de contas correntes em COBOL e CICS;

  • um sistema de cartões em Java;

  • um aplicativo móvel;

  • um sistema antifraude;

  • um CRM;

  • uma plataforma de investimentos;

  • um ambiente de análise de dados;

  • serviços de Pix;

  • aplicações em nuvem;

  • parceiros externos.

Nenhum desses sistemas vive completamente sozinho.

Quando um cliente altera seu endereço, essa mudança pode precisar chegar ao sistema de contas, cartões, seguros, investimentos, correspondência, prevenção a fraudes e atendimento.

Integração é justamente o mecanismo que permite que essa informação viaje entre os sistemas.

Podemos resumir a missão em quatro verbos:

conectar, transformar, transportar e controlar.

Conectar significa permitir a comunicação.

Transformar significa converter dados entre formatos.

Transportar significa entregar a informação ao destino.

Controlar significa garantir segurança, monitoramento, rastreabilidade e tratamento de erros.


2. A integração existia antes das APIs

Hoje é comum alguém associar integração diretamente a APIs REST.

Mas a integração corporativa nasceu muito antes da Web.

Ela já existia quando os dados eram transportados em:

  • cartões perfurados;

  • fitas magnéticas;

  • discos;

  • arquivos sequenciais;

  • relatórios impressos;

  • terminais;

  • redes proprietárias.

Um programa COBOL que gera um arquivo para outro programa consumir já está realizando integração.

Um job que extrai registros do Db2 e os envia por FTP também é integração.

Uma transação CICS que coloca uma mensagem em uma fila IBM MQ é integração.

Uma aplicação que publica um evento em Kafka é integração.

Uma API que recebe JSON e chama uma transação IMS é integração.

A tecnologia muda, mas o princípio permanece.


3. Primeira era: batch e arquivos

A integração por arquivos

Durante as décadas de 1970 e 1980, grande parte da troca de dados corporativos era realizada por arquivos.

O fluxo era simples:

Sistema de origem
       |
       v
Gera arquivo
       |
       v
Transporte ou disponibilização
       |
       v
Sistema de destino lê o arquivo

No mainframe, isso poderia ser implementado com:

  • COBOL;

  • JCL;

  • QSAM;

  • VSAM;

  • GDG;

  • SORT;

  • IDCAMS;

  • FTP;

  • fitas magnéticas.

Um sistema de folha de pagamento, por exemplo, poderia gerar um arquivo contendo os créditos dos funcionários.

O sistema bancário receberia esse arquivo, validaria os registros e efetuaria os depósitos.

Um layout hipotético poderia ser:

01 REGISTRO-PAGAMENTO.
   05 NUMERO-CONTA       PIC 9(10).
   05 VALOR-PAGAMENTO    PIC 9(11)V99.
   05 DATA-PAGAMENTO     PIC 9(08).
   05 CODIGO-EMPRESA     PIC X(10).

Cada linha do arquivo representaria uma instrução de pagamento.

Esse modelo ainda é amplamente utilizado, especialmente em processos de grande volume.


Por que o batch funcionava tão bem?

O batch possui vantagens importantes.

Ele permite processar milhões de registros de forma previsível.

Ele é eficiente para operações que não precisam acontecer imediatamente.

Também oferece boa capacidade de reinício, auditoria e controle.

Imagine o fechamento diário de um banco.

Não é necessário atualizar todos os relatórios financeiros a cada milissegundo. Muitas tarefas podem ser agrupadas e processadas em uma janela noturna.

O batch é perfeito para isso.


O problema da latência

A principal limitação da integração por arquivos é o tempo.

Considere esta sequência:

22:00 - Sistema A gera arquivo
23:00 - Arquivo é transferido
00:00 - Sistema B inicia processamento
01:30 - Sistema C recebe o resultado

A informação pode levar horas para percorrer toda a cadeia.

Se o arquivo estiver incorreto, atrasado ou incompleto, dezenas de jobs posteriores podem falhar.

No mainframe, isso cria uma verdadeira constelação de dependências no JES2.

Um job espera o outro.

O segundo espera o terceiro.

O terceiro depende de um GDG.

O quarto aguarda o arquivo chegar.

Quando algo falha, o operador vê a fila crescer como uma frota inimiga aproximando-se da estação espacial.


Curiosidade do mainframe

Muitas empresas modernas ainda dependem fortemente de integração por arquivos.

O formato pode ter mudado de fita para SFTP, de arquivo fixo para CSV ou de dataset para objeto em nuvem, mas a ideia continua igual:

um sistema produz um pacote de dados e outro sistema o consome posteriormente.

Não devemos tratar batch como tecnologia ultrapassada.

Ele é apenas um modelo diferente de integração.

O erro acontece quando tentamos utilizar batch em situações que exigem resposta imediata.


4. Segunda era: integração ponto a ponto

Com a expansão dos computadores distribuídos nas décadas de 1980 e 1990, as empresas começaram a adotar diferentes plataformas.

Agora havia:

  • mainframes;

  • servidores Unix;

  • AS/400;

  • computadores Windows;

  • bancos Oracle;

  • aplicações SAP;

  • sistemas departamentais;

  • clientes e servidores.

Cada sistema precisava se conectar diretamente a outros sistemas.

Nascia a integração ponto a ponto.

Sistema A ------ Sistema B
    |                |
    |                |
Sistema C ------ Sistema D

No início, parecia uma solução simples.

Se o sistema de vendas precisava enviar informações ao estoque, criava-se uma interface.

Se o estoque precisava falar com o financeiro, criava-se outra.

Se o financeiro precisava comunicar-se com o mainframe, surgia mais uma conexão.

O problema aparecia com o crescimento.


O espaguete de interfaces

Considere quatro sistemas:

  • A;

  • B;

  • C;

  • D.

Se todos precisarem se conectar entre si, teremos diversas interfaces.

Com dez sistemas, o número potencial de conexões cresce dramaticamente.

A quantidade máxima de conexões diretas entre n sistemas pode ser calculada por:

n × (n - 1)
------------
     2

Para 10 sistemas:

10 × 9 / 2 = 45 conexões

Para 20 sistemas:

20 × 19 / 2 = 190 conexões

Para 100 sistemas:

100 × 99 / 2 = 4.950 conexões

Agora imagine manter 4.950 interfaces.

Cada uma possui:

  • formato próprio;

  • protocolo próprio;

  • lógica própria;

  • segurança própria;

  • tratamento de erros próprio;

  • documentação própria — quando existe documentação.

Esse cenário ficou conhecido como spaghetti integration.

Era uma arquitetura que parecia um prato de macarrão: fios cruzando em todas as direções.


O impacto no programador COBOL

O programador COBOL poderia receber pedidos como:

  • gerar um arquivo para o sistema Unix;

  • criar uma chamada CICS para uma aplicação externa;

  • acessar uma fila MQ;

  • receber dados via socket;

  • adaptar um copybook para um novo consumidor;

  • criar uma rotina específica para cada parceiro.

Com o tempo, o mesmo programa acumulava diversas condições:

EVALUATE CODIGO-CANAL
   WHEN 'WEB'
      PERFORM TRATA-WEB
   WHEN 'ATM'
      PERFORM TRATA-ATM
   WHEN 'MOBILE'
      PERFORM TRATA-MOBILE
   WHEN 'PARCEIRO-A'
      PERFORM TRATA-PARCEIRO-A
   WHEN 'PARCEIRO-B'
      PERFORM TRATA-PARCEIRO-B
END-EVALUATE

A aplicação de negócio começava a conhecer detalhes de todos os consumidores.

Isso criava forte acoplamento.

Uma mudança em um canal poderia exigir alteração no sistema central.


5. Terceira era: o surgimento do middleware

Para resolver o caos ponto a ponto, surgiu o middleware.

Middleware pode ser entendido como uma camada intermediária entre sistemas.

Em vez de cada aplicação conhecer todas as demais, elas passam a utilizar uma infraestrutura comum.

Aplicação A
     |
     v
Middleware
     |
     v
Aplicação B

O middleware pode executar várias funções:

  • transporte de mensagens;

  • transformação de formatos;

  • roteamento;

  • segurança;

  • controle transacional;

  • registro de eventos;

  • monitoramento;

  • tratamento de falhas.

Uma analogia simples é o sistema postal.

O remetente não precisa conhecer todo o caminho da entrega.

Ele coloca o endereço no envelope e entrega a correspondência ao serviço postal.

O middleware cuida do transporte.


6. Mensageria e IBM MQ

Uma das formas mais importantes de middleware é a mensageria.

No modelo de mensageria, a aplicação de origem não precisa conversar diretamente com o destino.

Ela coloca uma mensagem em uma fila.

Programa COBOL
      |
      v
   Fila MQ
      |
      v
Aplicação consumidora

A fila funciona como um intermediário confiável.

O produtor envia a mensagem.

O consumidor lê quando estiver disponível.

Essa separação gera desacoplamento.


Exemplo prático

Uma transação CICS recebe uma solicitação de pagamento.

Em vez de chamar diretamente o sistema antifraude, ela publica uma mensagem:

PAGAMENTO
CONTA=123456
VALOR=850.00
CANAL=MOBILE

O sistema antifraude consome a mensagem e realiza sua análise.

Se o antifraude estiver temporariamente indisponível, a mensagem pode permanecer na fila.

Isso é muito mais resiliente do que uma conexão direta que falha imediatamente.


Uma lição importante

IBM MQ não é apenas um “correio eletrônico para programas”.

Ele oferece recursos corporativos como:

  • entrega garantida;

  • persistência;

  • unidades de trabalho;

  • controle de filas;

  • segurança;

  • recuperação;

  • integração entre diferentes plataformas.

Para um programador COBOL, compreender MQ abre uma enorme porta para a integração moderna.

O programa pode:

  1. conectar-se a um queue manager;

  2. abrir uma fila;

  3. colocar ou obter uma mensagem;

  4. confirmar ou desfazer a transação;

  5. fechar os recursos.

Em termos conceituais:

MQCONN
MQOPEN
MQPUT ou MQGET
MQCMIT
MQCLOSE
MQDISC

Cada chamada deve ter seu código de retorno verificado.

Ignorar COMPCODE e REASON em MQ é equivalente a pilotar uma nave sem consultar os sensores.

Pode funcionar durante algum tempo, mas o asteroide chegará.


7. O Enterprise Service Bus

Com o amadurecimento do middleware surgiu o conceito de Enterprise Service Bus, ou ESB.

O ESB atua como um barramento central de integração.

           CRM
            |
SAP -----> ESB <----- Mainframe
            |
         Aplicativo
            |
          Parceiro

Todos os sistemas integram-se por meio do barramento.

O ESB pode receber uma mensagem, transformá-la e encaminhá-la ao destino correto.


O que o ESB faz?

Suponha que um sistema envie XML:

<cliente>
    <codigo>123</codigo>
    <nome>Leonard McCoy</nome>
</cliente>

Mas o destino espera JSON:

{
  "customerId": 123,
  "customerName": "Leonard McCoy"
}

O ESB pode realizar essa transformação.

Ele também pode decidir a rota:

Se país = BRASIL
    enviar ao sistema nacional
Se país = ARGENTINA
    enviar ao sistema regional
Caso contrário
    enviar ao processamento internacional

Além disso, pode enriquecer a mensagem.

Por exemplo:

  1. recebe o número do cliente;

  2. consulta o Db2;

  3. obtém a categoria;

  4. acrescenta a categoria à mensagem;

  5. encaminha o conteúdo ao destino.


8. A evolução dos produtos IBM de integração

A história dos produtos IBM de integração possui várias mudanças de nome e evolução tecnológica.

Entre os nomes que marcaram essa trajetória estão:

  • MQSeries Integrator;

  • WebSphere Message Broker;

  • IBM Integration Bus;

  • IBM App Connect Enterprise.

Esses nomes não representam simplesmente mudanças cosméticas.

Eles refletem a ampliação das capacidades da plataforma.

O produto deixou de ser apenas uma ferramenta de integração baseada em mensagens e evoluiu para uma plataforma capaz de trabalhar com:

  • IBM MQ;

  • arquivos;

  • bancos de dados;

  • XML;

  • JSON;

  • SOAP;

  • REST;

  • aplicações empresariais;

  • eventos;

  • ambientes em nuvem;

  • containers.

O IBM App Connect Enterprise, conhecido como ACE, é herdeiro direto dessa longa evolução.


9. Como funciona um fluxo de integração no ACE?

Um fluxo de integração pode ser visualizado como uma sequência de etapas.

Entrada
  |
Validação
  |
Transformação
  |
Roteamento
  |
Acesso a sistemas
  |
Saída

Imagine uma API que recebe um pedido.

O fluxo pode realizar:

  1. receber o JSON;

  2. validar os campos obrigatórios;

  3. converter o formato;

  4. consultar o cadastro do cliente;

  5. enviar uma mensagem para MQ;

  6. registrar a transação;

  7. responder ao solicitante.

Exemplo de entrada:

{
  "customerId": 1001,
  "productId": 502,
  "quantity": 3
}

O ACE pode transformar isso em uma estrutura utilizada por um programa COBOL:

000000100100000050200003

Naturalmente, uma aplicação real usaria um layout formal, provavelmente definido por copybook.

O ponto importante é que o sistema COBOL não precisa entender JSON.

O ACE pode realizar a tradução entre o mundo web e o formato tradicional do mainframe.

Esse é um dos maiores valores da integração: preservar o sistema central sem obrigá-lo a conhecer todas as tecnologias externas.


10. Quarta era: SOA e serviços

Na década de 2000, ganhou força a Arquitetura Orientada a Serviços, conhecida como SOA.

A ideia principal era organizar capacidades de negócio como serviços reutilizáveis.

Em vez de cada sistema acessar diretamente tabelas ou arquivos de outro sistema, ele chamaria um serviço.

Exemplos:

ConsultarCliente
CalcularLimite
RegistrarPagamento
EmitirApólice
CriarPedido

Um serviço não deveria representar apenas uma função técnica.

Ele deveria representar uma capacidade significativa do negócio.


Por que isso foi importante?

Imagine três aplicações que precisam consultar dados de clientes.

Sem um serviço, cada uma pode desenvolver sua própria lógica de acesso.

Uma consulta diretamente o Db2.

Outra lê um arquivo.

A terceira replica uma tabela.

Com o serviço ConsultarCliente, todas utilizam a mesma capacidade.

Isso reduz duplicação e aumenta a consistência.


11. SOAP, XML e WSDL

SOA foi fortemente associada a Web Services SOAP.

SOAP utiliza mensagens estruturadas, geralmente em XML.

Uma solicitação simplificada poderia ser:

<soapenv:Envelope>
   <soapenv:Body>
      <ConsultarCliente>
         <Codigo>123</Codigo>
      </ConsultarCliente>
   </soapenv:Body>
</soapenv:Envelope>

O serviço era descrito por um WSDL.

O WSDL funcionava como um contrato formal, informando:

  • operações disponíveis;

  • estruturas de entrada;

  • estruturas de saída;

  • tipos de dados;

  • endereços;

  • protocolos.

Para grandes empresas, isso era valioso porque contratos rígidos ajudam a controlar integrações complexas.


SOAP era ruim?

Não.

SOAP tornou-se alvo de críticas por sua verbosidade e complexidade, mas resolveu problemas importantes.

Ele oferece padrões robustos para:

  • contratos;

  • segurança;

  • confiabilidade;

  • transações;

  • interoperabilidade.

Muitos serviços corporativos ainda utilizam SOAP porque foram construídos para processos críticos e continuam atendendo bem às necessidades do negócio.

O erro é confundir “mais antigo” com “inútil”.

No mainframe aprendemos cedo que idade e irrelevância não são sinônimos.


12. Quinta era: APIs REST

Com o crescimento da Web, dos aplicativos móveis e das arquiteturas distribuídas, as APIs REST tornaram-se populares.

REST geralmente utiliza:

  • HTTP;

  • URLs;

  • métodos como GET, POST, PUT e DELETE;

  • JSON.

Exemplo:

GET /clientes/123

Resposta:

{
  "id": 123,
  "nome": "Hikaru Sulu",
  "categoria": "GOLD"
}

Comparado ao SOAP, REST costuma ser mais simples para aplicações web e móveis.


Métodos HTTP

Os métodos mais conhecidos são:

GET     Consultar
POST    Criar ou executar uma ação
PUT     Atualizar ou substituir
PATCH   Atualizar parcialmente
DELETE  Excluir

Porém, esses significados dependem do desenho da API.

Uma boa API não é apenas um conjunto de URLs.

Ela precisa possuir:

  • contrato claro;

  • autenticação;

  • autorização;

  • validação;

  • versionamento;

  • limites de consumo;

  • observabilidade;

  • tratamento de erros.


13. O programador COBOL e as APIs

Um programa COBOL não precisa ser substituído apenas porque a empresa deseja oferecer uma API.

A integração pode funcionar assim:

Aplicativo móvel
       |
       v
API Gateway
       |
       v
ACE ou z/OS Connect
       |
       v
CICS / IMS / Db2 / COBOL

A API recebe JSON.

A camada de integração converte a solicitação.

O programa COBOL executa a regra de negócio.

A resposta é transformada novamente em JSON.

Essa arquitetura permite preservar décadas de regras validadas enquanto se oferece uma interface moderna.


Dica importante

Não coloque regras de negócio importantes em todos os lugares.

Se a regra de cálculo de limite pertence ao sistema central, evite replicá-la no aplicativo, no ESB, na API e em um microsserviço.

A duplicação de regras produz divergência.

Depois de alguns meses, cada sistema calcula um resultado diferente.

A integração deve orquestrar e transformar, mas não deve tornar-se um depósito descontrolado de lógica.


14. API-led connectivity

Com o crescimento das APIs, surgiu o conceito de integração orientada por APIs.

Uma organização pode estruturar suas APIs em camadas.

APIs de sistema

Expõem sistemas internos.

Exemplo:

API do Db2
API do CICS
API do SAP

APIs de processo

Combinam várias fontes para executar uma função de negócio.

Exemplo:

API de análise de crédito

Essa API pode consultar cadastro, histórico, renda e risco.

APIs de experiência

São adaptadas a um canal.

Exemplo:

API para aplicativo móvel
API para portal
API para parceiros

Essa separação evita que cada canal acesse diretamente os sistemas centrais.


15. Sexta era: nuvem e integração híbrida

A maioria das grandes empresas não migrou tudo para uma única nuvem.

O cenário real costuma ser híbrido.

Há sistemas:

  • no mainframe;

  • em datacenters;

  • em nuvens públicas;

  • em SaaS;

  • em ambientes de parceiros;

  • em containers.

A integração híbrida conecta esses mundos.

IBM Z
  |
ACE
  |
OpenShift
  |
Cloud
  |
SaaS

O desafio não é apenas transportar dados.

Também é necessário lidar com:

  • redes;

  • identidade;

  • criptografia;

  • latência;

  • governança;

  • custos;

  • residência de dados;

  • disponibilidade.


16. Containers e OpenShift

As plataformas de integração passaram a ser executadas em containers.

Um container empacota a aplicação e suas dependências.

Kubernetes e OpenShift administram esses containers.

Isso permite:

  • implantação automatizada;

  • escalabilidade;

  • recuperação;

  • isolamento;

  • atualização controlada;

  • integração com pipelines de CI/CD.

O ACE pode participar desse modelo moderno.

Em vez de uma única instalação central contendo todos os fluxos da empresa, diferentes integrações podem ser empacotadas e implantadas conforme sua necessidade.

Porém, não confunda distribuição com ausência de controle.

Mil integrações em containers sem governança podem criar um novo espaguete — agora servido em pequenas tigelas de Kubernetes.

Esse é um dos easter eggs arquitetônicos da história: toda solução criada para eliminar complexidade pode produzir uma complexidade nova quando utilizada sem disciplina.


17. Sétima era: arquitetura orientada a eventos

Em sistemas tradicionais, uma aplicação pergunta repetidamente:

Existe pedido novo?
Existe pedido novo?
Existe pedido novo?

Isso é chamado de polling.

Na arquitetura orientada a eventos, o sistema publica um aviso quando algo acontece.

PedidoCriado
PagamentoAprovado
ClienteAtualizado
EstoqueReduzido

Os consumidores escutam os eventos relevantes.

                +--> Estoque
PedidoCriado ---+--> Financeiro
                +--> Logística
                +--> Analytics

O produtor não precisa conhecer todos os consumidores.

Esse desacoplamento é poderoso.


18. Eventos, mensagens e comandos

Esses conceitos parecem semelhantes, mas não são idênticos.

Comando

Solicita que algo seja feito.

EfetuePagamento

Evento

Informa que algo aconteceu.

PagamentoEfetuado

Mensagem

É o envelope transportado pelo sistema de mensageria. Pode conter um comando, um evento ou outro tipo de informação.

Essa distinção ajuda no desenho de integrações.

Um evento geralmente é descrito no passado porque representa um fato ocorrido.


19. Kafka e IBM Event Streams

Kafka popularizou plataformas distribuídas de eventos.

Os eventos são organizados em tópicos.

Exemplo:

TOPIC: pagamentos-aprovados

Vários consumidores podem ler o mesmo fluxo.

Um consumidor atualiza o sistema contábil.

Outro alimenta uma plataforma analítica.

Outro detecta fraude.

Outro dispara uma notificação.

No ecossistema IBM, o Event Streams oferece capacidades baseadas em Kafka.

O ACE pode produzir e consumir eventos, atuando como uma ponte entre aplicações tradicionais e arquiteturas orientadas a eventos.


20. MQ versus Kafka

Essa comparação aparece frequentemente.

Mas não é correto pensar apenas em “qual é melhor?”.

A pergunta adequada é:

qual modelo atende melhor ao problema?

IBM MQ é excelente para mensageria corporativa confiável, filas de trabalho e processamento transacional.

Kafka é muito forte em fluxos de eventos, retenção de registros e consumo por múltiplas aplicações.

Em várias arquiteturas, ambos convivem.

Exemplo:

CICS
 |
MQ
 |
ACE
 |
Kafka
 |
Analytics e aplicações digitais

O MQ garante a integração transacional com o sistema central.

O Kafka distribui o evento para vários consumidores.

Não é uma guerra entre tecnologias.

É uma composição de capacidades.

Como diria o Sr. Spock:

“Insistir que uma única ferramenta resolve todos os problemas é uma conclusão pouco lógica.”


21. A era da integração componível

Integração componível significa construir soluções a partir de blocos reutilizáveis.

Em vez de criar uma integração monolítica gigantesca, a empresa combina:

  • APIs;

  • eventos;

  • conectores;

  • serviços;

  • fluxos;

  • funções;

  • regras;

  • componentes de segurança.

É semelhante à montagem de uma nave modular.

Cada componente possui uma responsabilidade clara.

Um conector acessa o Salesforce.

Outro interage com o SAP.

Um fluxo transforma dados.

Uma API expõe o serviço.

Um evento comunica uma mudança.

A composição desses elementos forma um processo maior.


22. Inteligência artificial na integração

A inteligência artificial começa a assumir funções de apoio ao ciclo de integração.

Ela pode ajudar a:

  • sugerir mapeamentos;

  • gerar documentação;

  • analisar logs;

  • detectar anomalias;

  • explicar erros;

  • identificar gargalos;

  • recomendar rotas;

  • criar testes;

  • auxiliar no desenvolvimento de fluxos.

Imagine dois formatos de dados.

Origem:

{
  "cust_id": 123,
  "full_name": "Nyota Uhura"
}

Destino:

{
  "customerNumber": 123,
  "customerName": "Nyota Uhura"
}

Uma ferramenta com IA pode sugerir que:

cust_id   -> customerNumber
full_name -> customerName

Isso acelera o trabalho.

Mas a IA não conhece automaticamente todas as regras do negócio.

Ela pode não perceber que:

  • o código precisa ter zeros à esquerda;

  • nomes devem ser convertidos para EBCDIC;

  • determinados clientes exigem tratamento especial;

  • o valor monetário utiliza casas decimais implícitas;

  • campos precisam obedecer a regras regulatórias.

Por isso, a validação humana continua essencial.


23. O risco da integração “mágica”

Ferramentas low-code e no-code facilitam a criação de integrações.

Isso é positivo.

Mas existe um risco: criar fluxos sem arquitetura, governança ou documentação.

Uma integração criada rapidamente pode tornar-se crítica.

Depois de dois anos, ninguém sabe:

  • quem a criou;

  • qual sistema depende dela;

  • como reiniciá-la;

  • quais credenciais utiliza;

  • onde está documentada;

  • o que acontece quando falha.

A facilidade de construção não elimina a necessidade de engenharia.

Pelo contrário: quanto mais fácil criar, maior deve ser a disciplina de governança.


24. Passo a passo para analisar uma integração

Quando receber uma demanda de integração, não comece imediatamente escolhendo tecnologia.

Siga uma sequência lógica.

Passo 1: compreenda o processo de negócio

Pergunte:

  • qual evento inicia o processo?

  • quem envia os dados?

  • quem consome?

  • qual resultado o negócio espera?

  • qual é o impacto de uma falha?

A integração não existe por causa do JSON.

Ela existe por causa do negócio.

Passo 2: identifique a origem e o destino

Exemplo:

Origem: transação CICS
Destino: aplicação em nuvem

Descubra:

  • plataformas;

  • protocolos;

  • formatos;

  • volumes;

  • restrições.

Passo 3: determine a necessidade de tempo

A integração deve ser:

  • em tempo real?

  • quase em tempo real?

  • assíncrona?

  • batch?

  • orientada a eventos?

Não transforme tudo em API síncrona.

Um processamento com milhões de registros pode ser melhor em batch.

Passo 4: defina o contrato

Documente:

  • campos;

  • tipos;

  • obrigatoriedade;

  • tamanhos;

  • valores válidos;

  • regras;

  • versões.

Para COBOL, o copybook frequentemente representa parte do contrato.

Para APIs, pode existir OpenAPI.

Para eventos, pode haver JSON Schema ou Avro.

Passo 5: escolha o padrão

Algumas possibilidades:

Arquivo
Fila
API
Evento
Serviço SOAP
Acesso a banco

A escolha deve considerar a necessidade, não o modismo.

Passo 6: planeje falhas

Pergunte:

  • o que acontece se o destino estiver indisponível?

  • haverá retry?

  • haverá fila de erros?

  • a mensagem pode ser duplicada?

  • existe mecanismo de reconciliação?

  • como reiniciar o processo?

Passo 7: implemente observabilidade

Registre:

  • identificador da transação;

  • horário;

  • origem;

  • destino;

  • resultado;

  • código de erro;

  • tempo de processamento.

Passo 8: proteja os dados

Considere:

  • autenticação;

  • autorização;

  • criptografia;

  • mascaramento;

  • auditoria;

  • LGPD;

  • gestão de segredos.

Passo 9: teste cenários ruins

Não teste apenas o caminho feliz.

Teste:

  • campo ausente;

  • mensagem inválida;

  • destino indisponível;

  • timeout;

  • duplicidade;

  • volume alto;

  • resposta inesperada;

  • falha de rede.

Passo 10: documente a operação

A equipe de produção precisa saber:

  • como monitorar;

  • como reiniciar;

  • como identificar mensagens presas;

  • como tratar erros;

  • quem deve ser acionado.


25. Idempotência: a palavra estranha que evita duplicidade

Idempotência significa que repetir uma operação não produz efeitos indesejados adicionais.

Imagine uma solicitação de débito.

A aplicação envia a requisição, mas não recebe resposta por causa de um timeout.

Ela tenta novamente.

Sem proteção, o cliente pode ser debitado duas vezes.

Uma solução é utilizar um identificador único:

ID-TRANSACAO = ABC123456

Antes de efetuar o débito, o sistema verifica se aquele identificador já foi processado.

Esse conceito é fundamental em integrações distribuídas.

No batch, muitas equipes já aplicavam ideias semelhantes usando arquivos de controle, chaves de processamento e mecanismos de restart.

Mais uma vez, o mundo moderno reencontra princípios que os veteranos do mainframe conhecem há décadas.


26. Correlação de mensagens

Uma transação pode atravessar vários sistemas.

Aplicativo
  |
API Gateway
  |
ACE
  |
MQ
  |
CICS
  |
Db2

Como rastrear toda a jornada?

Utilizando um identificador de correlação.

Exemplo:

CORRELATION-ID: 7F9A-2026-000123

Esse valor deve acompanhar a solicitação em todos os componentes.

Assim, ao investigar um problema, a equipe procura o mesmo identificador nos logs.

Sem correlação, cada sistema possui uma parte da história, mas ninguém consegue montar o episódio completo.

É como investigar o desaparecimento de uma nave sem possuir o registro de sua rota.


27. Transformação de dados: o detalhe perigoso

Transformar XML em JSON parece simples.

Mas a verdadeira dificuldade está na semântica.

Considere:

DATA = 01022026

Isso significa:

  • 1º de fevereiro de 2026?

  • 2 de janeiro de 2026?

  • um código sem significado de data?

Agora pense em valores monetários.

COBOL:

05 WS-VALOR PIC S9(9)V99 COMP-3.

Em JSON:

{
  "valor": 1500.75
}

A camada de integração precisa compreender:

  • sinal;

  • escala decimal;

  • formato packed decimal;

  • codificação;

  • tamanho;

  • arredondamento.

Um mapeamento incorreto pode não gerar erro técnico.

Ele pode gerar um valor de negócio errado.

Esse é o tipo mais perigoso de falha: o sistema funciona, mas produz informação incorreta.


28. EBCDIC, ASCII e a ponte entre mundos

O mainframe utiliza frequentemente EBCDIC.

Sistemas distribuídos geralmente utilizam ASCII ou Unicode.

Ao trocar dados, pode ser necessário converter codificações.

Caracteres acentuados, símbolos e campos binários merecem atenção especial.

Um arquivo que parece perfeitamente legível em um ambiente pode tornar-se uma coleção de caracteres estranhos em outro.

Dica do café:

Nunca assuma que um campo PIC X contém apenas texto simples.

Ele pode conter:

  • caracteres;

  • números formatados;

  • flags;

  • bytes especiais;

  • dados binários tratados como área alfanumérica.

Analise o copybook e o processo que grava o campo.


29. O papel do IBM App Connect Enterprise

O ACE ocupa uma posição estratégica porque consegue ligar diferentes gerações de tecnologia.

Ele pode atuar entre:

  • aplicações COBOL;

  • CICS;

  • IMS;

  • Db2;

  • IBM MQ;

  • arquivos;

  • APIs;

  • sistemas SAP;

  • bancos distribuídos;

  • serviços em nuvem;

  • eventos Kafka;

  • aplicações SaaS.

O ACE não “substitui o mainframe”.

Ele permite que o mainframe converse com o restante do ecossistema.

Também não deve concentrar toda a inteligência da empresa.

Seu papel principal é conectar, transformar, rotear e orquestrar.


30. Um exemplo completo

Imagine um cliente solicitando um empréstimo pelo aplicativo.

Etapa 1: aplicativo

O aplicativo envia:

{
  "customerId": 10001,
  "amount": 20000,
  "installments": 24
}

Etapa 2: API Gateway

O gateway:

  • autentica o cliente;

  • valida o token;

  • controla o limite de chamadas;

  • encaminha a requisição.

Etapa 3: ACE

O ACE:

  • valida o JSON;

  • transforma os dados;

  • gera um identificador de correlação;

  • consulta dados complementares;

  • envia a solicitação ao mainframe.

Etapa 4: CICS e COBOL

O programa COBOL:

  • consulta o cliente;

  • verifica renda;

  • analisa restrições;

  • calcula juros;

  • define a aprovação.

Etapa 5: resposta

O resultado retorna:

{
  "status": "APPROVED",
  "approvedAmount": 20000,
  "interestRate": 1.45,
  "installmentValue": 987.31
}

Etapa 6: evento

Após a aprovação, um evento é publicado:

LoanApproved

Consumidores podem:

  • enviar notificação;

  • atualizar CRM;

  • gerar contrato;

  • alimentar analytics;

  • iniciar o processo contábil.

Observe como várias eras convivem:

  • COBOL;

  • CICS;

  • API REST;

  • ACE;

  • mensageria;

  • eventos;

  • aplicações móveis;

  • cloud.

Integração moderna não elimina o passado.

Ela organiza a convivência entre gerações.


31. Problemas comuns e soluções

Problema: tudo depende do ESB

Quando todas as regras e integrações são concentradas em um único barramento, ele pode tornar-se um gargalo.

Solução

Distribuir responsabilidades, modularizar fluxos e utilizar padrões adequados.


Problema: contrato muda sem aviso

Uma aplicação altera um campo e quebra consumidores.

Solução

Usar versionamento, testes de contrato e governança.


Problema: mensagens duplicadas

Uma aplicação repete o envio após um timeout.

Solução

Implementar idempotência e chaves únicas.


Problema: integração sem monitoramento

A mensagem desaparece e ninguém sabe onde.

Solução

Utilizar correlação, logs, métricas, tracing e alertas.


Problema: regra de negócio duplicada

Cada canal implementa sua própria versão.

Solução

Centralizar a regra no domínio correto e expô-la como serviço.


Problema: API para tudo

Processamentos massivos são transformados em milhares de chamadas síncronas.

Solução

Avaliar batch, mensageria ou eventos.


32. Curiosidades da longa jornada

Curiosidade 1: o arquivo nunca morreu

Mesmo em arquiteturas modernas, arquivos continuam sendo utilizados para grandes volumes, intercâmbio com parceiros e processamento analítico.

Curiosidade 2: o ESB não desapareceu

Muitos anunciaram a “morte do ESB”, mas suas funções continuam existindo, distribuídas entre plataformas de integração, gateways, brokers e serviços.

Curiosidade 3: APIs não eliminam mensageria

APIs e mensagens resolvem problemas diferentes.

Uma aplicação pode usar API para consulta e eventos para notificação.

Curiosidade 4: microserviços também precisam integrar

Dividir uma aplicação em dezenas de serviços não elimina a integração. Na verdade, pode aumentar sua necessidade.

Curiosidade 5: o mainframe sempre foi uma plataforma integrada

CICS, IMS, Db2, VSAM, MQ, JES2 e RACF formam há décadas um ecossistema de processamento, segurança e comunicação extremamente sofisticado.


33. Easter egg do Bellacosa Mainframe

Existe uma antiga lenda nos corredores do datacenter.

Dizem que, durante uma madrugada de processamento, um programador encontrou a seguinte mensagem gravada em um arquivo temporário:

INTEGRATION IS NOT ABOUT MOVING DATA.
IT IS ABOUT PRESERVING MEANING.

Ele procurou a origem da mensagem no programa COBOL, no JCL, na PROC, no SORT e no módulo de integração.

Nunca encontrou.

Alguns afirmam que era apenas um registro esquecido por um desenvolvedor.

Outros dizem que foi o fantasma de um arquiteto de sistemas tentando alertar as novas gerações.

A mensagem, porém, contém uma verdade.

Transportar bytes é fácil.

Garantir que o destino compreenda corretamente o significado desses bytes é o verdadeiro desafio.


34. O que o programador COBOL iniciante deve estudar?

Para entrar no mundo da integração, siga uma trilha progressiva.

Primeiro nível: fundamentos

Aprenda:

  • arquivos sequenciais;

  • copybooks;

  • JCL;

  • Db2;

  • CICS;

  • códigos de retorno;

  • tratamento de erros.

Segundo nível: comunicação

Estude:

  • IBM MQ;

  • filas;

  • mensagens;

  • sincronismo;

  • assincronismo;

  • commit;

  • rollback.

Terceiro nível: dados modernos

Conheça:

  • XML;

  • JSON;

  • UTF-8;

  • REST;

  • HTTP;

  • métodos e códigos de resposta.

Quarto nível: plataformas

Explore:

  • IBM App Connect Enterprise;

  • z/OS Connect;

  • API gateways;

  • Kafka;

  • IBM Event Streams.

Quinto nível: arquitetura

Compreenda:

  • SOA;

  • ESB;

  • APIs;

  • event-driven;

  • idempotência;

  • observabilidade;

  • segurança;

  • governança.

Não tente aprender tudo de uma vez.

Comece entendendo o fluxo completo de uma única transação.

Siga o dado desde a origem até o destino.

Depois repita o exercício com outro padrão.


Conclusão: a tecnologia muda, a missão permanece

A integração corporativa começou muito antes das APIs e da nuvem.

Ela começou quando um sistema precisou entregar dados a outro.

Primeiro utilizamos arquivos.

Depois criamos conexões diretas.

Quando as conexões viraram um espaguete, introduzimos middleware.

O middleware evoluiu para barramentos de serviço.

SOA organizou capacidades como serviços.

SOAP trouxe contratos formais.

REST simplificou o consumo por aplicações digitais.

A nuvem tornou o ambiente híbrido.

Kafka e plataformas de eventos popularizaram arquiteturas orientadas a acontecimentos.

Containers trouxeram novas formas de implantação.

A inteligência artificial agora começa a auxiliar na criação, operação e análise das integrações.

Porém, nenhum desses avanços alterou a missão fundamental:

Conectar sistemas
Transformar dados
Preservar significado
Controlar processos
Entregar valor

Para o programador COBOL Padawan, a maior lição é perceber que o mainframe não pertence a um universo separado.

Ele é uma peça central da arquitetura corporativa.

O arquivo gerado por um job pode chegar a uma plataforma analítica.

A mensagem publicada por uma transação CICS pode acionar um serviço em nuvem.

Uma regra COBOL pode ser exposta por uma API móvel.

Uma atualização no Db2 pode originar um evento consumido por dezenas de aplicações.

O código pode ter nascido em uma tela verde, mas seu impacto atravessa APIs, filas, eventos, containers, celulares e nuvens.

No fim, integração não é apenas fazer computadores conversarem.

É garantir que diferentes gerações de tecnologia cooperem sem perder a segurança, a consistência e o conhecimento acumulado pelo negócio.

E essa, jovem Padawan, é uma missão digna não apenas de um arquiteto de integração, mas de todo profissional que deseja compreender como uma empresa realmente funciona por trás das telas coloridas.

A próxima vez que alguém disser que “tudo agora é API”, tome um gole de café, olhe calmamente para o terminal e responda:

— Toda API possui uma história. E há uma boa chance de que, em algum ponto dessa história, exista um programa COBOL mantendo o universo em funcionamento.


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