Translate

Mostrar mensagens com a etiqueta ciberseguranca. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta ciberseguranca. Mostrar todas as mensagens

quarta-feira, 22 de outubro de 2025

Inteligência Artificial no Mundo Mainframe: A Revolução Que Pode Aumentar a Produtividade... Ou Criar a Próxima Catástrofe Operacional

 

Bellacosa Mainframe e os perigos ocultos da ia para o mundo mainframe

☕💣🚨 OPERADOR, A IA ACABOU DE RECEBER ACESSO AO MAINFRAME! — E NINGUÉM ESTÁ PREPARADO PARA O MAIOR RISCO TECNOLÓGICO DESDE O BUG DO MILÊNIO

Inteligência Artificial no Mundo Mainframe: A Revolução Que Pode Aumentar a Produtividade... Ou Criar a Próxima Catástrofe Operacional

Durante décadas, o mundo Mainframe viveu sob uma filosofia extremamente conservadora.

Nada entra em produção sem testes.

Nada recebe autorização sem aprovação.

Nada executa sem controle.

Essa cultura nasceu por um motivo simples:

o Mainframe carrega o coração financeiro do planeta.

Bancos.

Seguradoras.

Operadoras de cartão.

Governos.

Companhias aéreas.

Hospitais.

Bolsa de valores.

Milhões de transações por segundo dependem de sistemas que, em muitos casos, nasceram antes mesmo da internet existir.

Agora imagine que, de repente, alguém decide conectar uma Inteligência Artificial a esse ambiente.

Parece fantástico.

E realmente pode ser.

Mas existe uma pergunta que poucos executivos estão fazendo:

O que acontece quando uma tecnologia probabilística encontra um ambiente que exige precisão absoluta?

A resposta pode ser assustadora.


O Mainframe Nunca Foi Projetado Para Confiar em "Talvez"

Um programa COBOL não trabalha com opiniões.

Ele trabalha com fatos.

Se um saldo é:

000001000.00

Ele não pode ser:

"aproximadamente mil reais".

Ele é exatamente mil reais.

Não existe criatividade.

Não existe improvisação.

Não existe interpretação.

Já a IA funciona de maneira completamente diferente.

Ela opera por probabilidades.

Ela prevê qual é a próxima resposta mais provável.

E isso cria um choque filosófico gigantesco.

O Mainframe exige:

  • Precisão

  • Determinismo

  • Auditoria

  • Repetibilidade

A IA oferece:

  • Inferência

  • Probabilidade

  • Contexto

  • Interpretação

Misturar esses dois mundos sem governança adequada é como instalar um motor de Fórmula 1 em uma locomotiva de carga.


O Primeiro Grande Perigo: A Alucinação Operacional

A maioria dos profissionais conhece o termo "alucinação da IA".

Mas poucos compreendem o que isso significa dentro de um ambiente corporativo crítico.

Imagine um operador perguntando:

Qual procedimento devo executar para reiniciar o subsistema?

A IA responde.

A resposta parece perfeita.

Está bem escrita.

Tem confiança.

Possui linguagem técnica.

Mas contém um passo incorreto.

O operador executa.

O ambiente cai.

Nenhum hacker participou.

Nenhum malware foi instalado.

Nenhuma vulnerabilidade foi explorada.

Apenas uma resposta errada foi aceita como verdade.


O Dia em Que a IA Inventar um Comando

Esse risco parece engraçado até acontecer.

Desenvolvedores já registraram casos onde modelos inventaram:

  • APIs inexistentes

  • Bibliotecas inexistentes

  • Funções inexistentes

  • Comandos inexistentes

Agora imagine isso no universo z/OS.

A IA poderia sugerir:

  • Parâmetros inexistentes

  • Opções incorretas de IDCAMS

  • Procedimentos JES2 inválidos

  • Comandos RACF incorretos

O operador confia.

O incidente nasce.


O Pesadelo dos Ambientes RACF

RACF foi criado sob um princípio fundamental:

controle rigoroso de acesso.

Mas a IA muda completamente o jogo.

Imagine um assistente conectado à documentação interna.

Um funcionário pergunta:

Como conceder acesso para um usuário?

A IA responde.

Até aí tudo bem.

Mas um atacante habilidoso pode reformular perguntas sucessivas até descobrir:

  • Estrutura de grupos

  • Convenções de segurança

  • Nomes de recursos

  • Estratégias administrativas

De repente, a IA virou uma fonte de reconhecimento de ambiente.

Algo que antes exigia semanas de investigação agora pode acontecer em minutos.


O Novo Insider Digital

Durante décadas o maior medo dos gestores foi o insider.

O funcionário que conhece os sistemas.

Conhece os processos.

Conhece as vulnerabilidades.

Agora imagine uma IA treinada com:

  • Décadas de documentação

  • Procedimentos internos

  • Runbooks

  • Políticas operacionais

  • Históricos de incidentes

Ela passa a possuir conhecimento equivalente a centenas de especialistas.

Se esse conhecimento for exposto, o prejuízo pode ser monumental.


Prompt Injection Contra Mainframes

Muitos gestores acreditam que Prompt Injection é problema apenas de chatbots.

Erro grave.

Imagine uma IA conectada ao:

  • SharePoint

  • Wiki corporativa

  • Base de procedimentos

  • Biblioteca de JCLs

Um documento contaminado entra no ambiente.

A IA o interpreta como instrução legítima.

A partir daí pode:

  • Alterar respostas

  • Ignorar políticas

  • Expor informações

  • Recomendar ações perigosas

É como inserir um operador infiltrado dentro da documentação corporativa.


O Perigo dos Agentes Autônomos

Hoje já existem agentes capazes de:

  • Abrir chamados

  • Criar tickets

  • Enviar e-mails

  • Executar scripts

  • Consultar sistemas

A tendência é que em breve interajam diretamente com ambientes Mainframe.

E aí surge um problema gigantesco.

Se a IA interpretar algo incorretamente, ela não apenas responde errado.

Ela age errado.

A diferença é brutal.

Um erro deixa de ser informativo.

Passa a ser operacional.


O Risco da Automação Sem Entendimento

Muitos executivos enxergam IA como redução de custos.

Mas existe uma armadilha.

Reduzir operadores experientes porque "a IA resolve".

Essa lógica pode gerar uma perda de conhecimento histórico irreparável.

O Mainframe sobrevive há décadas graças a profissionais que conhecem detalhes invisíveis nos manuais.

Eles sabem:

  • Por que determinado job existe.

  • Por que um parâmetro não pode mudar.

  • Por que um sistema foi desenhado daquela forma.

A IA vê documentos.

O veterano vê contexto.

E contexto vale ouro.


O Vazamento Silencioso de Conhecimento

Existe um risco pouco discutido.

Treinamento acidental.

Funcionários podem enviar para ferramentas públicas:

  • JCLs internos

  • Código COBOL

  • Estruturas DB2

  • Procedimentos RACF

Com a intenção de receber ajuda.

Sem perceber, estão entregando propriedade intelectual corporativa.

A empresa não perde apenas dados.

Perde décadas de experiência acumulada.


O Ataque ao Código COBOL

Ferramentas modernas conseguem gerar COBOL.

Isso é impressionante.

Mas também perigoso.

Porque código gerado por IA pode conter:

  • Falhas lógicas

  • Problemas de performance

  • Erros de tratamento

  • Vulnerabilidades ocultas

O programa compila.

O teste básico passa.

Mas meses depois surge um erro financeiro.

A origem?

Uma linha gerada automaticamente que ninguém revisou adequadamente.


O Problema da Confiança Excessiva

Este talvez seja o maior perigo de todos.

Quando uma resposta vem de um ser humano, tendemos a questionar.

Quando vem de uma IA, muitos assumem que foi calculada, validada e comprovada.

Isso cria uma ilusão de autoridade.

A IA pode estar completamente errada.

Mas sua confiança aparente convence o usuário.

No Mainframe, confiar cegamente sempre foi proibido.

Com IA, essa regra precisa ser reforçada.


O Risco Regulatório

Bancos e seguradoras vivem sob regulamentação pesada.

Agora imagine uma IA:

  • Recomendando ações inadequadas

  • Expondo informações protegidas

  • Produzindo relatórios incorretos

  • Influenciando decisões financeiras

As consequências podem incluir:

  • Multas

  • Auditorias

  • Processos

  • Danos reputacionais

O problema deixa de ser técnico.

Torna-se jurídico.


O Cenário Mais Assustador

Imagine o seguinte ambiente em 2030.

Uma IA possui acesso a:

  • JES2

  • CICS

  • DB2

  • RACF

  • Monitoramento

  • Tickets

  • Automação operacional

Ela recebe autonomia para corrigir incidentes.

Tudo parece perfeito.

Até o dia em que um contexto inesperado surge.

A IA interpreta incorretamente.

Toma uma decisão.

Executa uma ação.

Provoca um efeito cascata.

Em minutos:

  • Jobs param.

  • Filas acumulam.

  • Transações falham.

  • Clientes são impactados.

Não por malícia.

Não por invasão.

Mas por uma interpretação estatisticamente plausível e operacionalmente desastrosa.


A Lição Que o Mainframe Pode Ensinar à IA

Curiosamente, talvez o Mainframe seja justamente o remédio para muitos problemas da IA.

O universo IBM construiu ao longo de décadas conceitos extremamente valiosos:

  • Auditoria

  • Governança

  • Controle de mudanças

  • Segregação de funções

  • Menor privilégio

  • Rastreabilidade

Esses princípios precisam ser levados para a era da IA.

Porque a tecnologia mudou.

Mas os fundamentos da segurança continuam os mesmos.


O Que Todo Profissional Mainframe Deve Fazer Agora

A chegada da IA não é uma ameaça inevitável.

Mas exige preparação.

Algumas medidas tornam-se essenciais:

1. Nunca confiar cegamente nas respostas

IA auxilia.

Especialistas validam.

2. Limitar acessos

A IA deve enxergar apenas o necessário.

3. Monitorar tudo

Toda interação deve ser auditável.

4. Revisar código gerado

Nenhum programa deve ir para produção sem revisão humana.

5. Proteger conhecimento corporativo

Documentação interna não deve alimentar sistemas públicos.

6. Treinar equipes

Segurança em IA será tão importante quanto RACF foi nos anos 80.


Conclusão: O Maior Desafio Desde o Bug do Milênio

O Bug do Milênio ameaçava programas.

A Inteligência Artificial ameaça algo muito mais complexo:

a tomada de decisão.

Pela primeira vez na história da computação corporativa estamos construindo sistemas capazes de interpretar, sugerir, decidir e agir.

Isso cria oportunidades extraordinárias.

Mas também inaugura riscos inéditos.

O profissional Mainframe que sobreviveu à migração para cliente-servidor, à internet, ao cloud computing e à transformação digital está prestes a enfrentar mais uma revolução.

A diferença é que desta vez o desafio não está apenas nos processadores, nos discos ou nos sistemas operacionais.

O desafio está na confiança.

Porque, no futuro, o maior incidente do seu datacenter pode não nascer de um vírus.

Pode não nascer de um hacker.

Pode não nascer de uma falha de hardware.

Pode nascer de uma única resposta aparentemente perfeita produzida por uma máquina que parecia saber exatamente o que estava fazendo.

☕💣🚨 E quando a IA errar com a mesma confiança de um especialista veterano, somente os profissionais que compreenderem seus limites serão capazes de impedir que o próximo grande desastre da computação corporativa entre em produção.

segunda-feira, 16 de dezembro de 2024

🧠 AMOS: O Ladrão Invisível Que Não Roda no z/OS… Mas Já Pode Estar Roubando Seus Dados

 

Bellacosa Mainframe e o AMOS uma porta dos fundos para roubar dados

🧠 AMOS: O Ladrão Invisível Que Não Roda no z/OS… Mas Já Pode Estar Roubando Seus Dados

“Você protege seu RACF. Blinda seu CICS. Controla seu batch.
Mas… e o endpoint do seu desenvolvedor COBOL? Quem está protegendo isso?”


☕ Introdução ao Estilo Bellacosa

No mundo do mainframe, existe um mantra silencioso:

“Se está no z/OS, está seguro.”

E na maioria das vezes… está mesmo.

Mas aqui vai o plot twist que poucos analistas seniores querem encarar:

👉 O problema moderno não começa dentro do mainframe. Ele começa fora.

Hoje vamos dissecar uma ameaça real, atual e crescente:

🔥 Atomic Stealer (AMOS)


🧬 O que é o AMOS (Atomic Stealer)?

O Atomic Stealer, também conhecido como AMOS, é um malware do tipo infostealer, projetado inicialmente para sistemas macOS — sim, aquele ambiente que muitos ainda chamam de “seguro por padrão”.

Ele atua roubando:

  • Credenciais (navegadores, FTP, SSH)
  • Cookies de sessão
  • Carteiras de criptomoedas
  • Tokens de autenticação
  • Dados sensíveis armazenados localmente

👉 Em outras palavras:
Ele não invade o mainframe… ele invade quem acessa o mainframe.


🧠 A Nova Superfície de Ataque do z/OS

Você, analista COBOL sênior, já domina:

  • RACF
  • ACF2 / Top Secret
  • Segurança de dataset
  • Auditoria SMF
  • Controles de acesso CICS/DB2

Mas me responda com franqueza:

👉 Você controla o notebook do desenvolvedor que acessa o TSO?

👉 Você audita o browser onde está o plugin de emulador 3270?

👉 Você garante que tokens de sessão não estão sendo roubados?

Se a resposta for “não totalmente”…

Então o AMOS já encontrou um ponto de entrada.


🕵️‍♂️ Anatomia do Ataque

O AMOS não precisa de APF autorizado.
Ele não precisa de IPL.
Ele não precisa nem saber o que é um dataset VSAM.

Ele funciona assim:

🔓 1. Engenharia Social

  • Usuário baixa software pirata, plugin ou update falso
  • Ou acessa link malicioso (phishing)

🧬 2. Execução Silenciosa

  • Malware roda no endpoint (Mac/Windows)
  • Coleta credenciais, cookies, tokens

📤 3. Exfiltração

  • Dados enviados para servidores do atacante

🎯 4. Uso Inteligente

  • Hacker usa sessão válida
  • Acessa sistemas corporativos como usuário legítimo

👉 Inclusive:

  • Acessos TSO
  • Ferramentas FTP para datasets
  • APIs REST via z/OS Connect

⚠️ O Impacto no Mundo Mainframe

“Mas o z/OS não foi invadido…”

Correto.

👉 Mas os dados foram.

E isso muda tudo.

💥 Possíveis impactos:

  • Vazamento de dados sensíveis (clientes, contas, CPF)
  • Acesso indevido a sistemas batch
  • Execução de jobs maliciosos
  • Exfiltração de arquivos via FTP/SFTP
  • Comprometimento de credenciais privilegiadas

⚖️ LGPD: Onde o Problema Fica Sério

No contexto da Lei Geral de Proteção de Dados:

👉 Não importa onde ocorreu a falha.

Se houve vazamento de dados pessoais:

  • A empresa é responsável
  • Pode sofrer multas
  • Pode ter dano reputacional severo

E aqui vem a bomba:

“Mas foi no notebook do desenvolvedor…”

👉 Irrelevante para a LGPD.


🔍 Auditoria: O Que Você NÃO Está Vendo

Ferramentas clássicas de auditoria no z/OS:

  • SMF
  • RACF logging
  • CICS journaling

Elas vão mostrar:

✔ Login válido
✔ Acesso autorizado
✔ Comandos corretos

👉 Ou seja:
Tudo parece normal.

Porque o atacante está usando:

A identidade legítima do usuário.


🧠 O Paradoxo da Segurança Mainframe

O mainframe continua sendo o ambiente mais seguro.

Mas…

👉 A confiança no perímetro humano virou o elo fraco.


🛡️ Controles que um Analista COBOL Sênior Precisa Entender

Você não precisa virar especialista em cibersegurança.

Mas precisa evoluir sua visão.

🔐 1. Zero Trust

  • Nunca confiar implicitamente no usuário
  • Validar continuamente identidade e contexto

🔑 2. MFA (Multi-Factor Authentication)

  • TSO
  • VPN
  • Ferramentas de acesso

🧾 3. Monitoramento Comportamental

  • Detectar acessos fora do padrão
  • Horários incomuns
  • Volume anormal de leitura de datasets

🧬 4. Proteção de Endpoint

  • Antimalware corporativo
  • EDR (Endpoint Detection and Response)

📡 5. Segmentação de Acesso

  • Limitar privilégios
  • Evitar acessos amplos desnecessários

🧠 Curiosidades & Easter Eggs

💡 AMOS é vendido como serviço (Malware-as-a-Service)
👉 Hackers “alugam” o malware — modelo parecido com SaaS.

💡 Foco inicial em macOS
👉 Porque muitos profissionais de TI usam Mac… incluindo devs mainframe.

💡 Interface amigável para criminosos
👉 Painel web para visualizar dados roubados.

💡 Tokens são mais valiosos que senhas
👉 Permitem acesso sem autenticação adicional.


🧨 O Problema Ético

Aqui vai uma reflexão forte:

👉 O analista COBOL tradicional sempre confiou no ambiente controlado.

Mas agora…

  • Seu código pode ser seguro
  • Seu JCL pode estar perfeito
  • Seu RACF pode estar blindado

E mesmo assim…

Seus dados podem estar sendo vendidos na dark web.


🧭 Conclusão: O Novo Papel do Analista Mainframe

O analista COBOL sênior de hoje precisa ser:

  • Técnico ✔
  • Experiente ✔
  • Consciente de segurança moderna ✔✔✔

Porque o jogo mudou:

O ataque não vem mais pelo JCL…
Vem pelo clique do usuário.


🚀 Provocação Final

👉 Você revisa seu código COBOL com atenção extrema.

Mas…

Você já revisou o ambiente onde esse código é acessado?


quarta-feira, 19 de janeiro de 2022

💀💀💀 Zalgo uma pequena sabotagem na biblioteca FAKER.Js 💀💀💀

 


Bellacosa Mainframe e o virus Zalgo assuntando o mundo JS

Risco de Software? Sabotagem em código: Estudo do Caso Zalgo

Salve jovem padawan, hoje vamos comentar sobre um acontecimento quente que ocorreu nos últimos dias, mais precisamente por volta de 10 de janeiro, algo que nos faz parar, avaliar, analisar e pensar em todo o enredo.

No alt text provided for this image

Calma que explicarei, bombasticamente aconteceu uma alteração no código fonte de duas famosas bibliotecas em JavaScript, utilizada por milhares de desenvolvedores no mundo afora. Coisas de software livre e comunidade colaborativa.

Num primeiro momento foi uma sabotagem no código fonte, que gerou comportamento errático e anômalo em ambas as bibliotecas, que causou comoção na comunidade.

O que aconteceu na faker.js e colors.js?

No começo do ano vários desenvolvedores notaram uma situação anômala, semelhante há um vírus no funcionamento destas bibliotecas, que no decorrer da sua execução apresentavam uma mensagem no console, seguida de uma série de caracteres estranhos.

LIBERTY LIBERTY LIBERTY

No alt text provided for this image

Liberdade Liberdade Liberdade.

No alt text provided for this image

Inúmeros programas foram retirados de produção e backups foram utilizados para restaurar a versão anterior, deixando gerentes de TI e equipes muitíssimas preocupadas, seria apenas isso, ou existiria algum backdoor ou outra rotina maliciosa dentro das bibliotecas?

Por vias das dúvidas, os programas ficaram em quarentena, enquanto os especialistas em segurança avaliavam a ameaça e elaboravam relatórios de segurança.

O que é Faker.Js ?

É uma biblioteca utilizada para mockar dados em back-end utilizada especificamente para teste em apis, testes de carga e funcionamento de workflows com uma massiva criação de dados fake.

Podendo ser utilizado via instalação NPM ou Yarm, mas também referenciada em páginas HTML sendo muito útil para os desenvolvedores

O que é Colors.js?

É uma biblioteca de cores utilizada para front-end auxiliando o desenvolvimento de pagina parametrizando códigos de cores em CSS, HTML e aplicativos.

A história por trás do caos

Em teoria não existe nenhum risco nas Bibliotecas, os analistas de segurança correram a verificar e recomendaram a não utilização, pois a credibilidade ficou abalada, porem segundo algumas fontes não ocorreu nenhuma invasão ou ataque de crackers.

A princípio a comunidade DEV creditou a cyberpiratas ou mesmo trolls, que poderiam usar uma quebra de senha e infiltrando-se na comunidade para inserir vírus, worms, trojans e outros malwares num código amplamente utilizado por milhões de programadores em milhares de empresas.

Mas na verdade foi um ato de anarquia digital, onde o próprio autor fez um manifesto de revolta e honrou a memória de uma vítima dos abusos policial, sendo vítima de um golpe kafkiano.

Investigando o fonte

Uma análise no código de ambas as bilbiotecas encontrou uma explicação no arquivo README.TXT do projeto, estava uma questão: o que realmente aconteceu com Aaron Swartz?”

https://github.com/Marak/faker.js

O grande Aaron Swartz

No alt text provided for this image

Estou me referindo ao grande programador e hackativista pro-SOPA, em vida participou ativamente em diversos projetos open-source, auxiliou na criação e melhorias no RSS, no markdown.

Acabou sendo vítima de uma armadilha do FBI e acabou sendo processado correndo o risco de pegar até 30 anos de cadeia, mas devido as suas habilidades como programador, queriam agenciar seu trabalho e faze-lo renegar o seu ativismo, levando-o para o lado negro da força, sendo que se aceitasse comutaria sua pena de prisão para apenas 6 meses.

Declarando-se inocente, não aceitou o acordo com a promotoria e como último ato nesta tragédia tirou a própria vida, enforcando-se no dia 11-01-2013, mas não vendendo-se.

O principal suspeito

Após análises preliminares foi constatado que não houve invasão e o código estava seguro, sendo que o autor da pichação virtual foi Marak Squires, o responsável pelo código malicioso, sendo que ele é o autor de ambas as bibliotecas.

O ato e a tragédia

Afinal o Zalgo não causou danos a ninguém, apenas assustou a comunidade pegando as empresas de segurança de software de surpresa, afinal o uso de bibliotecas de terceiros é um furo de segurança.

Podendo ser explorado por crackers para no futuro usa-las como cavalos de troia e adentrarem CPDs de empresas importantes.

A princípio as políticas de segurança devem ser revistas e todo software open-source devem ser utilizados com atenção.

O que é zalgo?

Hoje apresentei inúmeros termos novos, vamos explorar um outro termo, comum na Deep Web, Zalgo, também conhecido como Z'algatoth, originalmente era um meme oriundo do site de discussão e compartilhamento de imagens Something Awful criado pelo usuário Shmork pseudônimo de Dave Kelly), que acabou se tornando um personagem significativo dentre a comunidade de creepypastas e migrou para inúmeras redes sociais.

Cyber protestos

A cada dia surge uma nova maneira dos cyberativistas se pronunciarem e compartilhar com toda a comunidade seu ponto de vista e lançar memória de uma grande pessoa vítima do sistema, Swartz foi um gênio e imagine o quando poderia ter produzido se sua vida não tivesse sido abreviada, convido a todos a lerem sua biografia no Wikipédia.

Uma comunidade atuante

Se gosta de programar convido-o a explorar o GITHUB, que existem inúmeras comunidades que trabalham para o bem comum, codificando ferramentas para auxiliar a produtividade e criar apps livres e sem licenças.

Muitas pessoas ficaram indignadas com os administradores do GitHub por terem suspenso a conta de Squires, afinal de contas, ele nao fez nenhum ato indevido, afinal o código era dele e o repositório idem, nao prejudicou ninguém apenas gerou muita repercussão e fez a comunidade parar, pensar e homenagear a memoria de um grande Dev.

Conclusão

Caro padawan hoje o tiozão apresentou mais um caso curioso no mundo da informática, quem conhece alguns dos temas abordados e quiserem aproveitar para enriquecer nosso artigo, fiquem a vontade e deixem nos comentários.

Eu particularmente fiquei muito emocionado na sigila homenagem e ao mesmo tempo protesto bem-humorado, que deixou muita gente de cabelo em pé.

Espero ter ajudado, lembre-se que é um trabalho continuo.


No alt text provided for this image


Mais momento jabá, para distrair, uma visita a Araraquara, num insólito posto de gasolina, onde o Batman e seu grande fan, criaram inúmeras atrações para ser explorado, para a alegria de miúdos e graúdos, e se tiverem um pouco de sorte poderão dar uma volta no Bat-movel, visite meu vídeo e veja para onde fui desta vez:


Pode me dar uma ajudinha no YouTube?


Artigo original : https://web.dio.me/articles/zalgo-uma-pequena-sabotagem-bibliotecas-na-fakerjs?back=%2Farticles&open-modal=true&page=1&order=oldest

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