☕ 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

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

domingo, 18 de agosto de 2024

Inteligência Artificial na Segurança Bancária sem Mistérios

Bellacosa Mainframe e a inteligencia artificial na seguranca bancaria


☕ Um Café no Bellacosa Mainframe

Inteligência Artificial na Segurança Bancária sem Mistérios

O Guia do Programador COBOL Padawan para Entender Biometria, Fraudes, Autenticação Contínua e os Escudos Digitais da Frota Estelar

Imagine, jovem programador COBOL Padawan, que você está sentado diante de um terminal 3270 em uma madrugada silenciosa.

Ao lado do teclado, uma caneca de café ainda quente. Na tela verde, um programa aparentemente simples processa uma transferência bancária. Ele recebe uma conta de origem, uma conta de destino, um valor e uma data. Depois de algumas validações, o sistema autoriza ou rejeita a operação.

Durante décadas, essa lógica pareceu suficiente.

O cliente informava a senha correta, o saldo era consultado, os limites eram verificados e a transação seguia seu caminho pelos corredores eletrônicos do banco.

Mas a galáxia financeira mudou.

Hoje, o usuário pode estar acessando o banco por um celular, conectado a uma rede pública, utilizando reconhecimento facial, fazendo um PIX para um novo destinatário e movimentando um valor muito diferente de seu padrão habitual.

Ao mesmo tempo, o criminoso pode possuir a senha verdadeira, o CPF, o número do telefone, documentos vazados, gravações da voz da vítima e até uma cópia artificial de seu rosto produzida por inteligência artificial.

A pergunta deixou de ser apenas:

“A senha está correta?”

Agora o banco precisa perguntar:

“Essa operação parece realmente estar sendo realizada pelo cliente?”

Essa mudança representa uma das maiores transformações na história da segurança bancária.

A segurança deixou de ser apenas um portão na entrada do sistema. Ela passou a acompanhar o cliente durante toda a jornada.

É como se os sistemas financeiros tivessem aprendido uma antiga lição da Frota Estelar:

Não basta identificar quem entrou na nave. É necessário observar o que essa pessoa faz depois de entrar.

Prepare o café, ajuste seu comunicador e abra uma nova sessão no TSO. Nossa missão será entender como inteligência artificial, biometria, autenticação multifator, análise comportamental, modelos de risco e mainframes trabalham juntos para proteger o sistema financeiro moderno.


1. O velho modelo: usuário, senha e confiança

Durante muito tempo, a segurança digital funcionou com uma lógica simples.

O usuário informava:

  • identificação;

  • senha;

  • eventualmente um código adicional.

Se tudo estivesse correto, o acesso era concedido.

Em pseudocódigo COBOL, poderíamos imaginar algo assim:

IF SENHA-INFORMADA = SENHA-CADASTRADA
    MOVE 'S' TO ACESSO-AUTORIZADO
ELSE
    MOVE 'N' TO ACESSO-AUTORIZADO
END-IF

A lógica é clara, objetiva e fácil de compreender.

O problema é que ela responde apenas a uma pergunta:

A credencial apresentada corresponde à credencial armazenada?

Ela não responde:

  • quem digitou a senha;

  • onde a senha foi digitada;

  • em qual dispositivo;

  • em qual horário;

  • em qual contexto;

  • com qual intenção;

  • se o comportamento é compatível com o histórico do cliente.

Se um criminoso roubar a senha verdadeira, o sistema tradicional poderá tratá-lo como usuário legítimo.

Esse é um dos princípios fundamentais para compreender a segurança moderna:

Uma credencial válida não significa necessariamente uma identidade legítima.

Senhas podem ser descobertas por phishing, engenharia social, vazamentos de dados, malware, observação física, reutilização em vários serviços ou manipulação psicológica.

Um cliente pode entregar voluntariamente um código de segurança acreditando estar falando com um funcionário do banco.

Nesse caso, tecnicamente, as informações estão corretas. Porém, a operação continua sendo fraudulenta.

A segurança bancária moderna precisou evoluir de uma validação estática para uma avaliação contínua de risco.


2. O criminoso não precisa arrombar a porta

Existe uma imagem clássica do invasor digital: alguém tentando quebrar uma senha, explorar uma falha ou invadir um servidor.

Esse tipo de ataque continua existindo.

Porém, muitos golpes atuais seguem um caminho mais silencioso.

O fraudador pode convencer a própria vítima a:

  • instalar um aplicativo;

  • compartilhar a tela;

  • fornecer um código;

  • transferir dinheiro;

  • cadastrar um novo dispositivo;

  • autorizar um pagamento;

  • entregar informações pessoais.

O criminoso não precisa destruir os escudos da nave.

Ele pode convencer o oficial de segurança a desativá-los.

Essa é a essência da engenharia social.

Os ataques modernos exploram não apenas sistemas, mas também emoções humanas:

  • medo;

  • urgência;

  • autoridade;

  • curiosidade;

  • ganância;

  • confiança;

  • pressão psicológica.

Uma mensagem pode dizer:

“Sua conta será bloqueada em dez minutos.”

Outra pode afirmar:

“Identificamos uma compra suspeita. Confirme seus dados agora.”

O cliente, preocupado, segue as instruções do próprio fraudador.

Por isso, proteger apenas a senha é insuficiente. O sistema precisa avaliar o contexto completo da operação.


3. A autenticação não termina no login

No modelo antigo, o login era considerado o grande momento da segurança.

A sequência era:

Identificação
      ↓
Senha
      ↓
Acesso autorizado

Depois do acesso, o sistema passava a confiar no usuário.

No modelo moderno, a sequência é muito mais ampla:

Identificação
      ↓
Senha ou credencial
      ↓
Biometria
      ↓
Dispositivo
      ↓
Localização
      ↓
Comportamento
      ↓
Análise de risco
      ↓
Monitoramento da sessão
      ↓
Reavaliação a cada operação

A autenticação tornou-se contínua.

Isso significa que uma sessão pode começar com baixo risco e, alguns minutos depois, apresentar sinais suspeitos.

Por exemplo:

  1. O cliente acessa o aplicativo em seu celular habitual.

  2. Consulta o saldo.

  3. Navega normalmente.

  4. Em seguida, cadastra um novo favorecido.

  5. Solicita um empréstimo.

  6. Transfere imediatamente todo o valor.

  7. O destino é uma conta nunca utilizada.

  8. O comportamento de digitação é diferente.

  9. O aparelho parece estar sendo controlado remotamente.

Cada ação, isoladamente, pode ser legítima.

Porém, o conjunto forma um padrão de alto risco.

A inteligência artificial consegue observar essa sequência em tempo real e recalcular a probabilidade de fraude.

Em outras palavras, o sistema deixa de perguntar apenas:

“Quem entrou?”

E passa a perguntar constantemente:

“O que está acontecendo agora?”


4. Zero Trust: nunca confiar automaticamente

Um dos conceitos mais importantes da segurança moderna é o chamado Zero Trust.

O nome pode parecer severo, mas sua lógica é bastante racional:

Nunca confie automaticamente. Sempre verifique.

Isso não significa tratar todos os clientes como criminosos.

Significa não depender de uma única prova de identidade.

Mesmo um usuário autenticado precisa continuar sendo avaliado.

Na Frota Estelar, possuir um uniforme não seria suficiente para acessar o núcleo de dobra. O sistema também verificaria:

  • identidade;

  • patente;

  • autorização;

  • localização;

  • horário;

  • missão;

  • contexto;

  • nível de risco.

No setor bancário, acontece algo semelhante.

Uma transferência pode exigir verificações adicionais conforme o risco.

Por exemplo:

EVALUATE NIVEL-RISCO
    WHEN 'BAIXO'
        PERFORM AUTORIZAR-TRANSACAO
    WHEN 'MEDIO'
        PERFORM SOLICITAR-SEGUNDO-FATOR
    WHEN 'ALTO'
        PERFORM BLOQUEAR-TRANSACAO
        PERFORM GERAR-ALERTA
    WHEN OTHER
        PERFORM ENCAMINHAR-ANALISE-MANUAL
END-EVALUATE

Esse exemplo mostra um ponto importante: segurança moderna não é apenas “permitir” ou “negar”.

Ela pode aplicar diferentes respostas:

  • liberar;

  • solicitar biometria;

  • solicitar token;

  • limitar valor;

  • atrasar a operação;

  • enviar alerta;

  • bloquear temporariamente;

  • encaminhar para análise humana.

O sistema adapta a proteção ao risco observado.


5. A IA não procura apenas criminosos

Muitas pessoas imaginam que a inteligência artificial possui uma lista de fraudadores conhecidos e compara cada usuário com essa lista.

Isso pode fazer parte do processo, mas é apenas uma pequena parte.

Na prática, a IA busca principalmente anomalias.

Uma anomalia é algo diferente do padrão esperado.

Considere um cliente que, durante vários anos:

  • acessa o aplicativo entre 7h e 22h;

  • utiliza sempre o mesmo celular;

  • mora no interior de São Paulo;

  • movimenta valores entre R$ 50 e R$ 1.000;

  • realiza pagamentos para poucos destinatários conhecidos.

Agora imagine a seguinte operação:

  • acesso às 3h17;

  • novo aparelho;

  • nova localização;

  • uso de VPN;

  • tentativa de empréstimo;

  • transferência de R$ 48.000;

  • destinatário recém-cadastrado.

Nenhum desses elementos, sozinho, prova uma fraude.

Um cliente pode viajar, trocar de celular ou realizar uma transferência elevada.

Mas o conjunto aumenta fortemente o risco.

A IA analisa dezenas ou centenas de sinais ao mesmo tempo.

Ela não pergunta simplesmente:

“Essa pessoa é criminosa?”

Ela pergunta:

“Esse comportamento é compatível com o histórico e o contexto esperado?”

Essa diferença é essencial.


6. Machine Learning: ensinando o sistema a reconhecer padrões

O aprendizado de máquina, ou Machine Learning, permite que sistemas identifiquem padrões a partir de grandes volumes de dados.

Um sistema antifraude pode aprender com:

  • transações legítimas;

  • fraudes confirmadas;

  • horários;

  • valores;

  • localização;

  • dispositivos;

  • destinatários;

  • canais utilizados;

  • comportamento de navegação;

  • velocidade das ações;

  • respostas a autenticações;

  • histórico de contestação.

Imagine milhões de transações sendo processadas diariamente.

Nenhum analista humano conseguiria revisar cada uma em tempo real.

A inteligência artificial consegue calcular rapidamente a probabilidade de uma operação ser legítima ou suspeita.

Um modelo simplificado poderia considerar:

Dispositivo conhecido: risco reduzido
Localização habitual: risco reduzido
Valor muito elevado: risco aumentado
Novo favorecido: risco aumentado
Horário incomum: risco aumentado
Biometria válida: risco reduzido
Aparelho comprometido: risco elevado

O resultado final pode ser transformado em um score.

Exemplo:

Score de risco: 12 de 100
Decisão: autorizar

Outro caso:

Score de risco: 87 de 100
Decisão: bloquear e solicitar validação

Para o programador COBOL iniciante, pense no score como um campo calculado a partir de várias condições.

MOVE ZERO TO SCORE-RISCO

IF DISPOSITIVO-NOVO = 'S'
    ADD 20 TO SCORE-RISCO
END-IF

IF LOCALIZACAO-INCOMUM = 'S'
    ADD 25 TO SCORE-RISCO
END-IF

IF VALOR-ACIMA-PADRAO = 'S'
    ADD 30 TO SCORE-RISCO
END-IF

IF BIOMETRIA-VALIDA = 'S'
    SUBTRACT 20 FROM SCORE-RISCO
END-IF

Os modelos reais são muito mais complexos, mas o princípio permanece semelhante: sinais são combinados para apoiar uma decisão.


7. Biometria: muito além da impressão digital

A biometria utiliza características humanas para validar a identidade.

As formas mais conhecidas incluem:

  • impressão digital;

  • reconhecimento facial;

  • voz;

  • íris;

  • geometria da mão.

A grande vantagem é que características biométricas são mais difíceis de compartilhar, esquecer ou digitar acidentalmente em um site falso.

Entretanto, biometria não deve ser tratada como solução mágica.

Uma fotografia pode ser roubada. Uma voz pode ser gravada. Um rosto pode ser reproduzido por deepfake.

Por isso, sistemas modernos utilizam mecanismos chamados de prova de vida, ou liveness detection.

A prova de vida tenta verificar se existe uma pessoa real diante do dispositivo.

Ela pode observar:

  • profundidade facial;

  • movimentos naturais;

  • reflexos;

  • textura da pele;

  • resposta a comandos;

  • movimentação dos olhos;

  • sincronização labial;

  • pequenas variações impossíveis em uma fotografia estática.

Um sistema pode pedir:

“Mova o rosto para a esquerda.”

Ou analisar silenciosamente características tridimensionais.

O objetivo é diferenciar uma pessoa real de:

  • fotografia;

  • vídeo;

  • máscara;

  • tela reproduzindo outro rosto;

  • conteúdo sintético.

Curiosidade de bordo: em histórias de ficção científica, scanners biométricos quase sempre reconhecem rostos instantaneamente. Na vida real, iluminação, câmera, ângulo, envelhecimento e qualidade do sensor tornam o problema muito mais complexo.


8. Biometria comportamental: a assinatura invisível

A biometria tradicional analisa características físicas.

A biometria comportamental analisa como uma pessoa interage com o sistema.

Ela pode observar:

  • ritmo de digitação;

  • tempo entre teclas;

  • força aplicada na tela;

  • velocidade do toque;

  • inclinação do aparelho;

  • forma de segurar o celular;

  • movimento do mouse;

  • padrão de rolagem;

  • tempo de leitura;

  • sequência de navegação.

Imagine duas pessoas digitando a mesma senha.

A primeira digita rapidamente, utilizando os dois polegares.

A segunda faz pausas, utiliza um dedo e pressiona determinadas teclas por mais tempo.

O texto é igual, mas o comportamento é diferente.

Essas diferenças formam uma espécie de assinatura invisível.

Outro exemplo:

O cliente legítimo normalmente abre o aplicativo, verifica o saldo, consulta o extrato e depois faz uma transferência.

O fraudador pode entrar diretamente na opção de empréstimo, contratar o valor máximo e transferir imediatamente.

O caminho percorrido dentro da aplicação também é um sinal.

A grande vantagem da biometria comportamental é que ela pode funcionar silenciosamente, sem exigir ações adicionais do usuário.

O cliente legítimo percebe menos fricção.

O fraudador encontra mais barreiras.


9. Autenticação contextual: onde, quando, como e com quê

A autenticação contextual analisa as circunstâncias da operação.

Entre os sinais avaliados estão:

  • localização;

  • endereço IP;

  • operadora;

  • rede Wi-Fi;

  • horário;

  • idioma;

  • fuso horário;

  • modelo do dispositivo;

  • versão do sistema;

  • navegador;

  • resolução da tela;

  • presença de VPN;

  • histórico do aparelho.

Imagine um cliente que mora em Campinas e acessa o banco às 14h.

Cinco minutos depois, ocorre outro acesso a partir de outro continente.

Fisicamente, isso seria impossível.

Esse tipo de evento pode ser classificado como viagem impossível.

O sistema pode bloquear a nova sessão ou solicitar validação adicional.

Outro exemplo:

Um cliente sempre utiliza o aplicativo em um aparelho Android específico. De repente, ocorre um acesso em um emulador, com sistema modificado e ferramentas de automação.

Esse contexto aumenta o risco, mesmo que a senha esteja correta.

A autenticação contextual não substitui a senha ou a biometria. Ela adiciona mais evidências.

É como uma investigação vulcana: nenhuma conclusão é baseada em uma única pista.


10. Token e autenticação multifator

A autenticação multifator combina diferentes tipos de prova.

Os fatores costumam ser divididos em três categorias:

Algo que você sabe

  • senha;

  • PIN;

  • resposta secreta.

Algo que você possui

  • celular;

  • cartão;

  • token físico;

  • aplicativo autenticador.

Algo que você é

  • rosto;

  • impressão digital;

  • voz;

  • íris.

Usar dois ou mais fatores reduz o risco de uma única credencial comprometida permitir acesso completo.

Porém, até a autenticação multifator pode ser atacada.

Códigos podem ser interceptados. Usuários podem ser convencidos a aprovar notificações. Chips podem ser clonados ou transferidos ilegalmente.

Por isso, o setor caminha para uma combinação mais ampla:

Senha
+
Dispositivo
+
Biometria
+
Contexto
+
Comportamento
+
Análise de risco

Quanto mais coerentes forem os sinais, maior a confiança.

Quanto mais contraditórios, maior a necessidade de verificação.


11. A luta contra falsos positivos

Bloquear fraudes é importante.

Mas bloquear clientes legítimos também causa problemas.

Imagine um cliente tentando pagar uma cirurgia, comprar uma passagem ou transferir dinheiro em uma emergência. Se o banco bloquear a operação sem necessidade, a experiência será péssima.

Isso é chamado de falso positivo.

Um falso positivo ocorre quando uma operação legítima é classificada como fraude.

Já um falso negativo ocorre quando uma fraude é classificada como legítima.

O grande desafio é equilibrar os dois.

Se o sistema for rígido demais, bloqueia clientes honestos.

Se for permissivo demais, deixa passar fraudes.

A inteligência artificial ajuda a encontrar um equilíbrio mais preciso.

Em vez de criar uma regra fixa como:

Toda transferência acima de R$ 10.000 deve ser bloqueada.

O sistema pode analisar:

  • renda do cliente;

  • histórico;

  • destinatário;

  • horário;

  • dispositivo;

  • localização;

  • motivo;

  • frequência;

  • comportamento.

Para um cliente, R$ 10.000 pode ser altamente incomum.

Para outro, pode ser uma operação diária.

A análise precisa ser contextual.


12. Aprendizado contínuo: o inimigo também evolui

Fraudadores testam constantemente novas técnicas.

Quando os bancos melhoram a autenticação, surgem novos golpes de engenharia social.

Quando os sistemas detectam determinados padrões, os criminosos tentam imitá-los.

Quando a biometria facial avança, aparecem deepfakes mais sofisticados.

É uma corrida permanente.

Por isso, modelos antifraude precisam ser atualizados continuamente.

O ciclo pode ser representado assim:

Fraude acontece
      ↓
Caso é investigado
      ↓
Padrão é identificado
      ↓
Modelo é ajustado
      ↓
Novas transações são protegidas
      ↓
Resultados são monitorados

Esse processo exige participação humana.

Analistas investigam alertas, confirmam fraudes, corrigem classificações e ajudam a melhorar os modelos.

A inteligência artificial não elimina o especialista.

Ela amplia sua capacidade.

Um analista que antes revisava cem casos pode concentrar-se nos casos mais críticos, enquanto o sistema automatiza a triagem inicial.


13. Inteligência artificial generativa na segurança bancária

Além dos modelos tradicionais de Machine Learning, a inteligência artificial generativa também pode apoiar equipes de segurança.

Ela pode:

  • resumir alertas;

  • explicar motivos de bloqueio;

  • organizar evidências;

  • gerar relatórios;

  • auxiliar investigações;

  • consultar políticas internas;

  • traduzir documentos;

  • correlacionar eventos;

  • apoiar equipes de atendimento.

Imagine um analista recebendo milhares de logs.

Uma IA pode produzir um resumo:

“A operação foi classificada como alto risco devido a novo dispositivo, localização incomum, valor 14 vezes superior à média e cadastramento recente do beneficiário.”

Isso reduz o tempo necessário para entender o caso.

Porém, decisões críticas não devem depender cegamente de uma resposta gerada.

Modelos generativos podem cometer erros, interpretar dados incorretamente ou produzir explicações convincentes, porém falsas.

Por isso, devem operar com:

  • dados confiáveis;

  • limites claros;

  • revisão humana;

  • rastreabilidade;

  • controle de acesso;

  • monitoramento.

Na ponte da nave, a IA pode ser um excelente oficial científico. Mas o comando final ainda exige responsabilidade.


14. LGPD, privacidade e governança

Quanto mais dados são analisados, maior a responsabilidade.

Sistemas antifraude podem processar:

  • identidade;

  • localização;

  • comportamento;

  • dispositivo;

  • histórico financeiro;

  • biometria;

  • dados de navegação.

Essas informações são extremamente sensíveis.

No Brasil, a LGPD estabelece princípios para o tratamento de dados pessoais.

Os bancos precisam considerar:

  • finalidade;

  • necessidade;

  • transparência;

  • segurança;

  • prevenção;

  • responsabilização;

  • direitos do titular.

Não basta dizer:

“Usamos muitos dados porque segurança é importante.”

A instituição precisa demonstrar:

  • por que os dados são necessários;

  • como são protegidos;

  • quem pode acessá-los;

  • por quanto tempo são mantidos;

  • como decisões são tomadas;

  • como incidentes são tratados.

Também existem exigências relacionadas a:

  • prevenção à lavagem de dinheiro;

  • conhecimento do cliente;

  • monitoramento de operações;

  • auditoria;

  • gestão de riscos;

  • identidade digital;

  • controles internos.

A segurança precisa proteger o cliente sem transformar o sistema em uma máquina de vigilância sem limites.

Esse equilíbrio é um dos maiores desafios éticos e regulatórios da era da IA.


15. IA explicável e responsabilidade

Imagine receber a seguinte mensagem:

“Sua transação foi bloqueada pela inteligência artificial.”

Isso não explica nada.

Em sistemas críticos, decisões precisam ser auditáveis.

O banco deve conseguir responder:

  • qual modelo tomou a decisão;

  • qual versão estava em uso;

  • quais dados foram considerados;

  • quais sinais aumentaram o risco;

  • quem revisou o caso;

  • qual política foi aplicada.

Esse campo é conhecido como Explainable AI, ou IA explicável.

Nem todo modelo complexo é fácil de explicar. Porém, instituições financeiras precisam buscar formas de tornar decisões compreensíveis e rastreáveis.

Um relatório pode mostrar:

Motivos principais do bloqueio:

1. Novo dispositivo.
2. Localização incompatível.
3. Transferência 20 vezes superior à média.
4. Beneficiário cadastrado há menos de cinco minutos.
5. Comportamento de navegação fora do padrão.

Isso ajuda:

  • analistas;

  • auditores;

  • reguladores;

  • atendimento;

  • clientes;

  • equipes jurídicas.

A responsabilidade não pode ser transferida para a máquina.

Dizer “o algoritmo decidiu” não encerra a discussão.


16. Onde entra o mainframe?

Agora chegamos ao território familiar do programador COBOL Padawan.

Muitos grandes bancos continuam utilizando mainframes para processar operações críticas.

O IBM Z pode participar de funções como:

  • manutenção de contas;

  • atualização de saldos;

  • processamento de cartões;

  • liquidação;

  • crédito;

  • cadastro;

  • movimentação financeira;

  • auditoria;

  • processamento em lote;

  • integração com redes externas.

A inteligência artificial não necessariamente substitui esses sistemas.

Ela pode atuar ao redor deles ou integrada a eles.

Uma arquitetura simplificada poderia ser:

Aplicativo móvel
      ↓
API de autenticação
      ↓
Biometria e análise de dispositivo
      ↓
Motor antifraude com IA
      ↓
Score de risco
      ↓
API bancária
      ↓
CICS / IMS / Db2 / COBOL
      ↓
Autorização ou rejeição

O programa COBOL pode receber um indicador de risco.

Exemplo:

01  DADOS-TRANSACAO.
    05 CONTA-ORIGEM        PIC 9(10).
    05 CONTA-DESTINO       PIC 9(10).
    05 VALOR-TRANSACAO     PIC 9(11)V99.
    05 SCORE-RISCO         PIC 9(03).
    05 STATUS-BIOMETRIA    PIC X.
    05 DISPOSITIVO-NOVO    PIC X.

IF SCORE-RISCO GREATER THAN 80
    MOVE 'B' TO STATUS-TRANSACAO
    PERFORM REGISTRAR-BLOQUEIO
ELSE
    PERFORM PROCESSAR-TRANSFERENCIA
END-IF

Esse é apenas um exemplo didático.

Em uma arquitetura real, a decisão pode envolver motores especializados, regras, APIs, filas, eventos, banco de dados, monitoração e aprovação humana.

O ponto principal é:

O mainframe não está separado da inteligência artificial. Ele pode ser parte central da cadeia de decisão.

A IA funciona como sensor e oficial de análise.

O core bancário funciona como motor transacional.

Ambos precisam conversar de maneira rápida, confiável e segura.


17. Passo a passo de uma transação moderna

Vamos acompanhar uma transferência do início ao fim.

Passo 1 — O cliente abre o aplicativo

O sistema identifica:

  • modelo do aparelho;

  • versão do sistema;

  • endereço IP;

  • localização aproximada;

  • integridade do dispositivo;

  • histórico de uso.

Passo 2 — O cliente autentica

Pode utilizar:

  • senha;

  • PIN;

  • impressão digital;

  • reconhecimento facial;

  • token.

Passo 3 — O comportamento é observado

O sistema analisa:

  • velocidade de navegação;

  • forma de digitação;

  • sequência de telas;

  • padrão de toque;

  • tempo de resposta.

Passo 4 — A transferência é criada

São coletados:

  • valor;

  • destinatário;

  • banco;

  • horário;

  • frequência;

  • histórico entre as contas.

Passo 5 — A IA calcula o risco

O modelo compara a operação com:

  • padrão do cliente;

  • padrões de fraude;

  • comportamento de contas semelhantes;

  • alertas recentes;

  • reputação do dispositivo;

  • sinais de comprometimento.

Passo 6 — O motor de decisão atua

A operação pode ser:

  • aprovada;

  • aprovada com limite;

  • submetida a biometria;

  • submetida a segundo fator;

  • colocada em espera;

  • bloqueada;

  • enviada para análise.

Passo 7 — O core bancário processa

O sistema transacional verifica:

  • saldo;

  • limite;

  • situação da conta;

  • regras financeiras;

  • disponibilidade;

  • consistência.

Passo 8 — Tudo é registrado

Logs e trilhas de auditoria armazenam:

  • decisão;

  • horário;

  • modelo;

  • score;

  • fatores utilizados;

  • resultado final.

Passo 9 — O sistema aprende

Se a operação for confirmada como fraude, o caso pode alimentar melhorias futuras.

Se o cliente confirmar que era legítima, o sistema também aprende.

Esse ciclo acontece milhões de vezes.


18. Dicas para o programador COBOL Padawan

Mesmo que você não trabalhe diretamente com IA, existem conhecimentos importantes para sua carreira.

Entenda a origem dos dados

Pergunte sempre:

  • quem gerou o score;

  • quando foi calculado;

  • qual o formato;

  • qual a validade;

  • o que fazer se estiver ausente.

Nunca confie cegamente em um campo externo

Um score recebido por API precisa ser validado.

IF SCORE-RISCO NOT NUMERIC
    PERFORM TRATAR-ERRO
END-IF

Registre decisões importantes

Operações críticas precisam de auditoria.

Não basta bloquear. É necessário registrar por quê.

Trate indisponibilidade

O que acontece se o motor de IA estiver fora do ar?

O sistema deve:

  • bloquear tudo;

  • liberar operações de baixo valor;

  • usar regras locais;

  • encaminhar para contingência?

Essa decisão precisa ser definida antecipadamente.

Evite decisões sem explicação

Um campo “RISCO-ALTO” pode ser insuficiente.

Sempre que possível, receba códigos de motivo.

01 — Dispositivo novo
02 — Valor anormal
03 — Localização suspeita
04 — Beneficiário recente

Proteja dados sensíveis

Logs não devem expor:

  • senha;

  • token;

  • biometria;

  • número completo de cartão;

  • informações pessoais desnecessárias.

Pense em performance

Uma análise antifraude não pode levar vários segundos durante uma compra.

Tempo de resposta é parte da experiência e da arquitetura.

Conheça o fluxo completo

O programador não deve enxergar apenas o programa COBOL.

Ele deve compreender:

  • canal digital;

  • API;

  • mensageria;

  • motor de risco;

  • CICS;

  • Db2;

  • logs;

  • monitoração;

  • atendimento;

  • auditoria.

É assim que um Padawan se transforma em arquiteto da Frota.


19. Curiosidades da galáxia antifraude

Curiosidade 1 — Seu jeito de usar o celular pode identificá-lo

A forma como você inclina o aparelho, toca a tela e digita pode compor um padrão comportamental.

Curiosidade 2 — Uma transação legítima pode parecer suspeita

Comprar uma passagem internacional, trocar de telefone e fazer uma transferência elevada no mesmo dia pode gerar alertas, mesmo sendo legítimo.

Curiosidade 3 — Fraude não é apenas invasão de conta

Também pode envolver:

  • abertura de conta falsa;

  • documentos adulterados;

  • crédito obtido ilegalmente;

  • lavagem de dinheiro;

  • uso de contas de terceiros;

  • identidades sintéticas.

Curiosidade 4 — O cliente pode estar autenticado e ainda assim ser vítima

Em golpes de falsa central, a própria vítima realiza a operação sob orientação do criminoso.

Nesse caso, senha, biometria e dispositivo podem estar corretos.

A análise comportamental e contextual torna-se ainda mais importante.

Curiosidade 5 — Regras antigas ainda têm valor

A IA não elimina regras tradicionais.

Muitas arquiteturas combinam:

  • regras fixas;

  • modelos estatísticos;

  • Machine Learning;

  • listas de bloqueio;

  • análise humana.

A melhor defesa costuma ser híbrida.


20. Easter egg para quem chegou até aqui

Em algum ponto desta missão, talvez você tenha percebido que o sistema antifraude se comporta como o computador da USS Enterprise.

Ele observa milhares de sensores, compara padrões, calcula probabilidades e alerta a tripulação quando algo foge do esperado.

Mas existe uma diferença importante.

Nos episódios clássicos, o computador frequentemente anunciava:

“Intruder alert.”

Nos bancos modernos, o alerta pode ser muito mais discreto.

Talvez o cliente apenas receba uma solicitação de biometria adicional.

Talvez a transferência seja atrasada por alguns segundos.

Talvez um analista receba uma notificação.

Talvez um programa COBOL execute um simples:

MOVE 'N' TO TRANSACAO-AUTORIZADA

Por trás desse único caractere podem existir:

  • milhões de registros;

  • dezenas de algoritmos;

  • centenas de sinais;

  • decisões regulatórias;

  • motores de risco;

  • APIs;

  • mainframes;

  • criptografia;

  • auditoria;

  • análise humana.

O humilde MOVE 'N' pode ser o último escudo antes de uma fraude milionária.

Essa é a beleza invisível dos sistemas corporativos.


Conclusão: os novos escudos da Frota Financeira

A segurança bancária não pode mais depender apenas de senhas.

O cenário moderno exige uma combinação de:

  • inteligência artificial;

  • biometria;

  • autenticação multifator;

  • análise comportamental;

  • contexto;

  • tokens;

  • monitoramento contínuo;

  • governança;

  • auditoria;

  • intervenção humana.

A IA permite analisar enormes volumes de transações em tempo real, identificar comportamentos anormais, calcular riscos e responder antes que o prejuízo aconteça.

A biometria ajuda a validar identidade.

A análise comportamental observa como o cliente interage.

A autenticação contextual avalia onde, quando e em qual dispositivo a operação ocorre.

O mainframe garante que a transação seja processada com consistência, disponibilidade e segurança.

Nenhuma dessas tecnologias funciona perfeitamente sozinha.

A verdadeira força está na integração.

Assim como uma nave da Frota Estelar depende de sensores, escudos, computadores, motores, oficiais e protocolos, um banco moderno depende de várias camadas trabalhando em conjunto.

Para o programador COBOL iniciante, a principal lição é clara:

O código que processa uma transação é apenas uma parte de uma missão muito maior.

Por trás de cada autorização existem decisões de segurança, dados, modelos, regras, APIs, auditoria e responsabilidade.

Aprender COBOL continua sendo importante.

Mas compreender o ecossistema ao redor do COBOL é o que transforma um simples programador em um profissional preparado para os sistemas financeiros do futuro.

Quando você encontrar no código um campo chamado SCORE-RISCO, STATUS-BIOMETRIA, IND-FRAUDE ou COD-MOTIVO-BLOQUEIO, não o veja apenas como mais uma variável.

Veja-o como uma mensagem enviada pelos sensores da nave.

Analise.

Valide.

Registre.

Proteja.

E nunca se esqueça da principal diretriz da segurança moderna:

Confiança não é um estado permanente. É uma conclusão que precisa ser reavaliada continuamente.

Vida longa ao COBOL.

Vida longa ao mainframe.

E que os escudos permaneçam ativos em todas as transações da galáxia financeira.


domingo, 14 de julho de 2024

Spy vs. Spy Entra no CPD — O Dia em que o Espião Preto Trouxe um Firewall e o Espião Branco Perguntou: “Ótimo… Mas Quem Protege a Senha?”

 

Bellacosa Mainframe e a segurança sob a otica do spy versus spý

☕ Um Café no Bellacosa Mainframe

Spy vs. Spy Entra no CPD — O Dia em que o Espião Preto Trouxe um Firewall e o Espião Branco Perguntou: “Ótimo… Mas Quem Protege a Senha?”

Ou: como firewall, RACF, MFA, FIDO2, AES, TLS, WAF, Zero Trust, supply chain, SIEM, agentes de IA e dois espiões incapazes de confiar um no outro explicam por que cibersegurança não é comprar uma caixa preta e colocar na porta do datacenter

Havia alguma coisa errada naquela manhã no CPD.

O operador percebeu primeiro.

Não porque uma luz vermelha tivesse acendido no console, nem porque o JES2 estivesse despejando mensagens assustadoras no log. O problema era bem mais simples: havia um sujeito vestido de preto, usando chapéu preto, sobretudo preto e óculos escuros, tentando instalar uma caixa enorme na entrada da sala.

Na caixa estava escrito:

FIREWALL
SUPER ULTRA MEGA SECURITY
100% HACKER PROOF

Do outro lado do corredor surgiu um sujeito praticamente idêntico, mas completamente vestido de branco.

O Espião Branco olhou para a caixa.

Olhou para o Espião Preto.

Olhou novamente para a caixa.

E perguntou:

— Firewall?

O Espião Preto sorriu.

— Firewall.

— Então estamos seguros?

O Espião Preto hesitou.

Cinco segundos depois, o Espião Branco já estava olhando para mim.

Eu estava segurando uma xícara de café e um manual de RACF que provavelmente pesava mais do que os dois juntos.

— Bellacosa — perguntou ele — firewall resolve segurança?

Eu respondi:

— Se resolvesse, metade deste artigo não existiria.

E foi assim que começou nossa aula improvisada de cybersecurity.

Porque uma das maiores armadilhas para quem começa a estudar segurança é imaginar que existem produtos mágicos: firewall, antivírus, MFA, criptografia, WAF, SIEM, RACF. Colocamos tudo numa lista, marcamos algumas caixinhas e declaramos:

SECURITY = TRUE

Infelizmente, segurança não funciona assim.

Segurança é uma arquitetura.

E, como os dois espiões da MAD Magazine descobririam ao longo daquela manhã, cada mecanismo responde a uma pergunta diferente.



1. Primeiro incidente: o firewall chegou ao CPD

O Espião Preto ligou sua caixa.

Na tela apareceu:

ALLOW TCP FROM 10.20.30.0/24
TO 10.40.50.10
PORT 443

Ele apontou orgulhosamente.

— Viu? Ninguém entra!

O Espião Branco aproximou-se.

— Exceto quem estiver usando HTTPS na porta 443.

Silêncio.

Esse é o primeiro conceito importante para qualquer programador COBOL iniciante entrando em segurança.

Um firewall não é uma entidade mágica capaz de decidir:

“este ser humano é bom”
“este programa é honesto”
“esta transação não está roubando dinheiro”

O firewall normalmente trabalha com características de comunicação.

Em sua forma mais simples, pode analisar:

Source IP
Destination IP
Source Port
Destination Port
Protocol

Esse é o princípio do packet filtering firewall.

Ele observa os pacotes como um segurança na entrada de um prédio que verifica:

— De onde veio?
— Para onde vai?
— Qual porta quer usar?
— Qual protocolo?

Mas ainda existe uma limitação.

Um pacote destinado à porta 443 pode carregar uma requisição HTTPS absolutamente legítima.

Ou uma tentativa de explorar uma vulnerabilidade de aplicação.

Para o firewall básico, os dois podem parecer inicialmente bastante semelhantes.

Esse detalhe é fundamental:

PORTA PERMITIDA

não significa:

CONTEÚDO SEGURO

O Espião Branco anotou isso num papel.

O Espião Preto imediatamente tentou roubar o papel.

Começávamos bem.



2. Stateful Firewall — quando o guarda ganhou memória

O próximo equipamento instalado foi um stateful inspection firewall.

Agora o firewall não observava apenas pacotes isolados.

Ele acompanhava o estado das conexões.

Imagine o estabelecimento de uma conexão TCP:

CLIENTE                    SERVIDOR

SYN ----------------------->

     <---------------- SYN/ACK

ACK ----------------------->

Um firewall stateful mantém informações sobre essa conversa.

Algo conceitualmente parecido com:

ORIGEM       DESTINO       PORTA       ESTADO

CLIENTE-A    SERVER-X      443         ESTABLISHED
CLIENTE-B    SERVER-Y      22          SYN_SENT

Isso muda bastante o jogo.

O equipamento deixa de perguntar apenas:

“Este pacote pode passar?”

e começa também a perguntar:

“Este pacote faz parte de uma conexão válida que eu já conheço?”

É como se o segurança do prédio deixasse de conferir apenas o crachá e passasse a manter uma lista:

VISITANTE 38
entrou 09:17
foi para sala 4
ainda está dentro

Isso reduz diversas situações anômalas e melhora significativamente o controle de rede.

Mas ainda não significa que o firewall compreenda perfeitamente o que a aplicação está fazendo.

O Espião Preto parecia desapontado.

Ele aparentemente queria um produto chamado:

STOP_ALL_EVIL.EXE

Infelizmente ainda não existe.



3. Proxy Firewall — “Você não vai falar diretamente com ele”

O Espião Branco trouxe então outro desenho:

CLIENTE ---- PROXY ---- SERVIDOR

Esse é um conceito extremamente interessante.

Em vez de cliente e servidor conversarem diretamente, um proxy atua como intermediário.

Na prática podemos pensar em duas conversas:

CLIENTE <----> PROXY

PROXY <----> SERVIDOR

O proxy pode controlar, registrar, inspecionar e decidir como intermediar o tráfego.

No universo Bellacosa Mainframe, imagine o seguinte diálogo:

— Quero falar com o servidor.

— Não.

— Por quê?

— Você fala comigo.

— E depois?

— Eu decido se falo com ele.

Esse isolamento pode ser muito útil.

E a ideia reaparece em diversos lugares da segurança moderna: proxies, gateways, API gateways, service meshes e intermediários especializados.

A lição é simples.

Quanto menos relações diretas desnecessárias existirem entre componentes críticos, melhor conseguimos controlar a superfície de ataque.


4. WAF — o segurança que aprendeu HTTP

Nesse momento o Espião Preto voltou correndo.

— Descobri! Vamos colocar outro firewall!

O Espião Branco respondeu:

— Qual?

— Um com a letra W.

Ele não estava completamente errado.

Um WAF — Web Application Firewall é especializado em proteger aplicações web.

A arquitetura pode ficar assim:

INTERNET
   |
   v
  WAF
   |
   v
WEB APPLICATION
   |
   v
BACKEND
   |
   v
DATABASE

Por que isso importa?

Porque um firewall de rede pode enxergar:

TCP/443

Enquanto o WAF consegue analisar mais profundamente elementos relacionados a HTTP e HTTPS.

Ele pode procurar comportamentos associados a ataques como:

SQL Injection
Cross-Site Scripting
Path Traversal
requisições malformadas
padrões maliciosos

Imagine:

GET /cliente?id=123

Isso parece normal.

Agora imagine uma entrada construída para tentar interferir numa consulta SQL.

O problema deixou de ser:

“Posso usar a porta 443?”

e passou a ser:

“O que exatamente você está pedindo para a aplicação fazer?”

Essa distinção é enorme.

Firewall e WAF não são sinônimos.

Um protege principalmente a comunicação e seus limites.

O outro compreende melhor o contexto da aplicação web.


5. O NGFW chega carregando a caixa de ferramentas inteira

Depois apareceu o Next-Generation Firewall, ou NGFW.

O Espião Preto abriu a caixa.

Dentro havia:

Firewall
Stateful Inspection
Application Awareness
IDS/IPS
Threat Intelligence
Identity Integration

Era praticamente o canivete suíço da segurança de rede.

Em vez de tomar decisões apenas com IP e porta, um NGFW pode considerar contexto adicional.

Por exemplo:

usuário
aplicação
protocolo
reputação
assinatura de ataque
comportamento da conexão

Isso permite políticas muito mais sofisticadas.

A velha regra:

ALLOW PORT 443

pode evoluir conceitualmente para:

Permitir acesso à aplicação X
somente a determinados grupos,
a partir de determinados contextos,
desde que o tráfego não apresente
comportamento classificado como malicioso.

Percebe a mudança?

Estamos saindo da segurança puramente baseada em endereço e porta e caminhando para uma segurança baseada em contexto.

E contexto seria uma palavra importantíssima durante toda a nossa aventura.


6. Mas quem é você?

O Espião Branco então fez a pergunta que destruiu a alegria do Espião Preto.

— Suponha que alguém tenha passado pelo firewall. Quem é essa pessoa?

Entramos em Authentication.

Autenticação responde:

Quem é você?

Autorização responde:

O que você pode fazer?

Jamais confunda as duas.

No mundo mainframe, isso fica maravilhosamente claro.

Você pode autenticar:

USERID
PASSWORD

E o sistema reconhecer:

USERID = BELLACO

Isso não significa automaticamente:

BELLACO PODE ALTERAR PAYROLL

Nem:

BELLACO PODE APAGAR PROD.DB2.CUSTOMER

Nem:

BELLACO PODE ALTERAR RACF

Autenticação estabeleceu identidade.

Autorização ainda precisa decidir privilégios.

Esse é um conceito indispensável.


7. Senha — o dinossauro que ainda trabalha em produção

A autenticação tradicional usa:

USER
PASSWORD

Funciona?

Sim.

É perfeita?

Longe disso.

Senhas sofrem ataques e problemas como:

phishing
credential stuffing
password reuse
keylogging
brute force
vazamento de banco de credenciais
engenharia social

E aqui encontramos uma verdade desconfortável sobre segurança moderna.

Muitas vezes é mais fácil roubar a senha de alguém do que quebrar criptografia sofisticada.

O Espião Preto havia passado vinte minutos tentando descobrir como quebrar AES.

O Espião Branco simplesmente deixou uma folha ao lado da cafeteira escrito:

URGENTE
Sua conta expirará.
Digite usuário e senha aqui.

O Espião Preto quase caiu.

Essa é a essência da engenharia social.

O atacante contorna a matemática atacando o ser humano.


8. OTP, 2FA e MFA — mais de uma porta

OTP significa One-Time Password.

Pode ser um código como:

381729

válido por um curto período.

Existem mecanismos baseados em tempo, tokens físicos e outras abordagens.

O objetivo é reduzir o valor de uma credencial roubada.

Agora entram dois conceitos muito confundidos:

2FA significa Two-Factor Authentication.

MFA significa Multi-Factor Authentication.

Tradicionalmente pensamos em fatores como:

algo que você sabe
algo que você possui
algo que você é

Senha:

algo que você sabe

Chave física:

algo que você possui

Biometria:

algo que você é

Uma sutileza importante:

senha + outra senha

não representa necessariamente dois fatores diferentes.

É:

KNOW + KNOW

Um desenho mais forte seria:

PASSWORD + SECURITY KEY

ou:

DEVICE + BIOMETRIC VERIFICATION

9. FIDO2: o espião finalmente ganhou uma chave que não entrega o segredo

O Espião Branco apareceu com uma pequena chave USB.

O Espião Preto riu.

— Isso é segurança?

— Dependendo da implementação, bastante.

Entramos no universo FIDO2/WebAuthn.

Aqui aparece uma mudança conceitual extraordinária.

Em vez de depender de um segredo reutilizável enviado e comparado, podemos trabalhar com criptografia de chave pública.

Conceitualmente:

PRIVATE KEY
permanece protegida no autenticador

PUBLIC KEY
fica registrada no serviço

O servidor envia um desafio.

O autenticador assina esse desafio.

O servidor verifica.

SERVER
   |
challenge
   v
AUTHENTICATOR
   |
signature
   v
SERVER

A chave privada não precisa viajar pela rede.

Além disso, mecanismos FIDO corretamente implementados oferecem forte resistência a phishing.

Isso é particularmente interessante porque ataca uma das maiores fraquezas da autenticação tradicional: convencer a vítima a entregar um segredo reutilizável.


10. Passwordless não significa “sem segurança”

Quando alguém diz:

Passwordless

algumas pessoas imaginam:

LOGIN
ENTER

Não.

Passwordless significa remover a senha tradicional como principal segredo de autenticação.

Isso pode envolver:

Passkeys
FIDO2
WebAuthn
certificados
smart cards

Na realidade, em algumas arquiteturas passwordless pode ser mais seguro que senha.

O nome engana o iniciante porque ele pensa:

“Se tirou senha, tirou proteção.”

É justamente o contrário.

Estamos tentando remover uma das peças mais frágeis do mecanismo.


11. Criptografia — agora vamos esconder o conteúdo da pasta secreta

O Espião Preto colocou uma pasta sobre a mesa.

Na capa:

TOP SECRET
DO NOT READ

O Espião Branco abriu.

— Você escreveu “não leia”, mas deixou tudo em texto puro.

Entramos em criptografia.

A primeira grande divisão é:

CRIPTOGRAFIA SIMÉTRICA

e

CRIPTOGRAFIA ASSIMÉTRICA

Na criptografia simétrica, usamos essencialmente a mesma chave para cifrar e decifrar.

PLAINTEXT
   |
   v
ENCRYPT + KEY
   |
   v
CIPHERTEXT
   |
   v
DECRYPT + KEY
   |
   v
PLAINTEXT

É extremamente eficiente.

E aqui encontramos um gigante:

AES.


12. AES — o caminhão de carga da criptografia moderna

AES significa Advanced Encryption Standard.

Possui bloco de 128 bits e pode usar chaves de:

128 bits
192 bits
256 bits

Curiosidade importante:

AES-256 não significa que o bloco seja de 256 bits.

O bloco continua com 128 bits.

Os 256 referem-se ao tamanho da chave.

AES aparece em inúmeros contextos:

disco
bancos de dados
backups
VPN
protocolos
armazenamento

É rápido e amplamente padronizado.

E aqui surge uma recomendação importante para o programador:

não invente criptografia própria.

Nunca faça algo como:

vou criar meu algoritmo secreto
porque ninguém conhece

Se ninguém conhece, provavelmente ninguém revisou.

Criptografia segura depende de algoritmos conhecidos, analisados, testados e de implementações confiáveis.


13. Assimétrica — duas chaves entram no CPD

Na criptografia assimétrica temos:

PUBLIC KEY
PRIVATE KEY

Ela permite construir mecanismos relacionados a:

assinaturas digitais
autenticação
troca/estabelecimento de chaves
PKI
certificados

Algoritmos e famílias conhecidos incluem RSA e ECC.

RSA é histórico e importantíssimo.

ECC, ou Elliptic Curve Cryptography, permite em muitos contextos níveis fortes de segurança utilizando chaves menores em comparação a RSA.

Isso pode trazer benefícios em desempenho, armazenamento e comunicação.

Mas existe um ponto pedagógico fundamental:

Criptografia assimétrica não substituiu a simétrica.

Elas trabalham juntas.


14. TLS — o casamento que deu certo

TLS é um excelente exemplo.

Simplificando bastante, mecanismos assimétricos podem participar da autenticação e do estabelecimento de segredos de sessão.

Depois utilizamos criptografia simétrica para trafegar grandes volumes de dados eficientemente.

Algo conceitualmente assim:

PUBLIC-KEY MECHANISMS
        |
        v
AUTHENTICATION / KEY ESTABLISHMENT
        |
        v
SESSION KEY
        |
        v
SYMMETRIC ENCRYPTION
        |
        v
DATA

Então perguntar:

“TLS usa RSA ou AES?”

é simplificar demais.

Protocolos modernos combinam várias primitivas criptográficas para diferentes funções.

Cada ferramenta tem seu trabalho.

Como num job bem escrito.

Não colocamos SORT, COBOL, Db2 e CICS fazendo exatamente a mesma coisa.


15. Hash não é criptografia

O Espião Preto apareceu segurando uma string Base64.

— Criptografei.

O Espião Branco:

— Não.

— Mas ninguém consegue ler.

— Eu consigo.

— Droga.

Esse é outro erro clássico.

Encoding não é encryption.

Base64 não é criptografia.

E hashing também não é encryption.

Uma função hash criptográfica produz um valor derivado do dado.

Conceitualmente:

PASSWORD
   |
   v
HASH FUNCTION
   |
   v
DIGEST

Não existe a ideia normal de:

digest
   |
decrypt
   |
password original

Hashing é unidirecional.

É utilizado, entre outras coisas, em mecanismos de integridade e em sistemas de armazenamento seguro de senhas, com técnicas apropriadas.

Nunca pense:

HASH = ENCRYPTION

São ferramentas diferentes.


16. A ameaça não está apenas do lado de fora

Agora chegamos ao painel de ameaças.

O Espião Preto apontou para fora do CPD.

— Hacker fica lá.

O Espião Branco apontou para dentro.

— Nem sempre.

Temos ameaças externas.

Mas também:

insider threat
human error
credential threat
supply chain
application threat
network threat
cloud threat
physical threat
IoT threat

E elas frequentemente se combinam.

Imagine:

ATACANTE EXTERNO
      |
      v
PHISHING
      |
      v
CREDENCIAL ROUBADA
      |
      v
LOGIN VÁLIDO

Agora aquele atacante externo parece um usuário interno legítimo.

Por isso a antiga divisão:

FORA = PERIGOSO
DENTRO = CONFIÁVEL

começou a morrer.


17. Insider Threat — quando o crachá não prova inocência

Insider pode significar várias coisas.

Pode ser funcionário malicioso.

Pode ser terceirizado.

Pode ser conta comprometida.

Pode ser funcionário cometendo erro.

Pode ser alguém com privilégios excessivos.

No universo mainframe isso conecta imediatamente com:

RACF
ACF2
Top Secret
least privilege
segregation of duties
SMF
auditing

O objetivo não é somente:

impedir pessoas desconhecidas de entrar.

É também:

impedir pessoas conhecidas de fazer aquilo que não deveriam.

Esse é um dos fundamentos de segurança.


18. Supply Chain — o Espião Preto entra vestido de fornecedor

Você protege sua empresa.

Firewall impecável.

MFA.

RACF.

SIEM.

Tudo bonito.

Mas instala um software de fornecedor comprometido.

Parabéns.

O atacante não derrubou sua porta.

Entrou dentro de uma caixa autorizada.

Supply Chain Security pergunta:

Em quem você confia?
De onde veio este software?
Quem produziu esta biblioteca?
Este pacote foi alterado?
Este pipeline é seguro?
As dependências são confiáveis?

No desenvolvimento moderno, isso inclui:

libraries
packages
containers
plugins
build pipelines
vendors
CI/CD
APIs

Uma organização é tão segura quanto parte de sua cadeia de confiança.


19. Human Error — o bug de carne e osso

Existe um atacante particularmente perigoso.

Às vezes ele não sabe que está atacando.

É o ser humano configurando algo errado.

Exemplos:

bucket público
senha em script
credencial no Git
arquivo enviado para pessoa errada
privilégio excessivo
patch esquecido
MFA desabilitado
backup nunca testado

Isso explica por que segurança não pode depender apenas de treinamento.

Treinamento ajuda.

Mas sistemas seguros também precisam ser construídos para reduzir a possibilidade de erro.

Se um clique errado pode destruir produção inteira, talvez o problema não seja somente o operador.

Talvez a arquitetura tenha permitido poder demais com pouca proteção.


20. White Hat, Black Hat e o desfile de chapéus

Os infográficos sobre tipos de hackers são divertidos, mas precisamos tratar as categorias com cuidado.

White Hat normalmente representa o profissional autorizado a testar segurança.

A palavra central é:

AUTORIZADO

Pentest sem autorização deixa de ser pentest muito rapidamente.

Black Hat normalmente se refere a atividades maliciosas e não autorizadas.

Gray Hat ocupa uma zona mais ambígua, frequentemente envolvendo testes sem autorização, mesmo quando a pessoa alega boas intenções.

E aqui existe uma regra preciosa:

boa intenção não substitui permissão.

Categorias como Red Hat, Blue Hat e outras variam bastante entre materiais populares.

No mundo profissional, é geralmente mais útil falar em funções como:

Red Team
Blue Team
Purple Team
Threat Hunter
Pentester
SOC Analyst
Incident Responder
Security Researcher

21. Spy vs. Spy vira Red Team vs. Blue Team

Foi inevitável.

O Espião Preto declarou:

— Eu sou Red Team.

O Branco respondeu:

— Você está vestido de preto.

— Não importa.

— Para o artigo importa.

Red Team simula o adversário.

Ele tenta alcançar determinados objetivos de maneira controlada e autorizada.

Por exemplo:

Reconnaissance
      |
      v
Initial Access
      |
      v
Privilege Escalation
      |
      v
Lateral Movement
      |
      v
Objective

O Blue Team defende.

Ele trabalha com:

monitoramento
detecção
SIEM
EDR
hardening
incident response
threat hunting
forensics

E quando Red e Blue trabalham juntos nasce o conceito de Purple Team.

O Red diz:

— Entrei por aqui.

O Blue:

— Não detectei.

A equipe cria detecção.

O Red repete.

Agora o SIEM dispara.

É um ciclo de melhoria.

Isso é muito mais valioso do que Red Team e Blue Team disputarem quem é mais inteligente.


22. O RACF entra no episódio

Finalmente chegamos ao IBM Z.

O Espião Preto mostrou o firewall novamente.

— Agora ninguém acessa o mainframe.

Eu perguntei:

— E se alguém chegar até ele?

Silêncio.

Entrou RACF.

Para um programador COBOL iniciante, esta é uma analogia poderosa.

Firewall pergunta:

Esta conexão pode chegar até aqui?

RACF pode participar da resposta a:

Quem é esse usuário?

e principalmente:

Este usuário pode acessar este recurso?

Imagine:

USER01

tentando acessar:

PROD.PAYROLL.MASTER

O controle pode considerar permissões como:

READ
UPDATE
CONTROL
ALTER
NONE

O fato de USER01 estar autenticado não significa que tenha autorização para alterar tudo.

Esse é o coração do least privilege.

Conceda apenas o necessário.

Nada além.


23. O COBOL também é parte da segurança

É muito tentador pensar:

“Segurança é trabalho do RACF.”

Não.

Um programa COBOL pode introduzir vulnerabilidades.

Imagine lógica conceitualmente assim:

IF USER-AUTHORIZED
    PERFORM UPDATE-CUSTOMER
END-IF

Quem definiu USER-AUTHORIZED?

Como esse valor é obtido?

Pode ser falsificado?

Existe uma checagem real?

O programa valida entrada?

Registra dados sensíveis?

Existem credenciais hardcoded?

Podemos encontrar problemas como:

authorization bypass
input validation inadequada
dados sensíveis em log
credenciais no código
exposição excessiva de informação
tratamento inseguro de erro

Segurança atravessa a aplicação inteira.


24. Da Internet até o COBOL

Agora imagine uma arquitetura moderna:

SMARTPHONE
    |
 INTERNET
    |
  NGFW
    |
   WAF
    |
API GATEWAY
    |
z/OS Connect
    |
  CICS
    |
 COBOL
    |
  Db2

O programador COBOL olha isso e talvez diga:

— Mas eu só alterei o programa CUSTOMER01.

Exatamente.

E uma chamada feita por um celular em qualquer lugar do mundo pode terminar executando esse programa.

O mainframe moderno não vive necessariamente isolado numa ilha.

Ele pode participar de APIs, mobile banking, marketplaces, cloud, OpenShift, mensageria e inúmeros ecossistemas distribuídos.

Isso significa que o desenvolvedor COBOL moderno precisa entender o contexto de segurança ao redor de seu programa.


25. Zero Trust — o Espião Branco finalmente encontra sua religião

Quando expliquei Zero Trust, os dois espiões sorriram.

Finalmente uma filosofia que entendiam naturalmente.

O modelo antigo parecia:

FORA DA REDE
NÃO CONFIE

DENTRO DA REDE
CONFIE

Zero Trust trabalha com uma filosofia muito mais próxima de:

não confie automaticamente
verifique identidade
verifique dispositivo
verifique contexto
aplique privilégio mínimo
assuma possível comprometimento

O fato de alguém estar “dentro” não lhe concede inocência.

Isso combina perfeitamente com Spy vs. Spy.

Um jamais confiava no outro.

A diferença é que Zero Trust recomenda paranoia disciplinada e baseada em política, não colocar bomba dentro da cafeteira.

Esse detalhe é importante.


26. Observabilidade — se ninguém viu, aconteceu?

Imagine possuir:

Firewall
WAF
MFA
RACF
TLS
AES

Excelente.

Mas alguém consegue passar.

O que acontece agora?

Precisamos detectar comportamento anormal.

Entram:

logs
SIEM
SOC
SMF
correlation
alerting
behavior analytics
threat hunting

Imagine um usuário que normalmente trabalha:

08:00 - 18:00
Brasil
20 transações/hora

E subitamente vemos:

03:17
milhares de consultas
download incomum
mudança de privilégios
acesso a datasets nunca consultados

Uma arquitetura madura precisa perceber.

Segurança não é somente prevenção.

Também é:

DETECT
RESPOND
RECOVER

27. Resiliência — quando o Espião Preto finalmente consegue explodir alguma coisa

Era questão de tempo.

Um alarme disparou.

Uma pequena nuvem de fumaça surgiu.

O Espião Preto parecia satisfeito.

— E agora?

Essa é a pergunta que diferencia segurança infantil de segurança madura.

Não basta perguntar:

“Como impedir o ataque?”

Pergunte também:

“E quando alguma defesa falhar?”

Entramos em:

backup
disaster recovery
cyber resilience
RTO
RPO
immutable copies
recovery testing
incident response

RTO responde aproximadamente:

Quanto tempo podemos levar para recuperar?

RPO:

Quanto dado podemos aceitar perder desde o último ponto recuperável?

Um backup que nunca foi restaurado em teste é mais uma esperança do que uma estratégia.

Uma empresa realmente resiliente não promete que nunca terá incidentes.

Ela prepara-se para:

detectar
conter
isolar
recuperar
continuar
investigar
aprender

28. Agora aparece o convidado mais novo: o agente de IA

Nesse momento uma janela apareceu no monitor:

AI AGENT REQUESTING ACCESS

O Espião Preto sorriu.

— Inteligência Artificial. Ela sabe o que está fazendo.

O Espião Branco olhou para mim.

Eu comecei a beber o café mais rápido.

Imagine um agente com acesso a:

Git
Db2
ServiceNow
Jenkins
z/OS
CICS
e-mail
APIs

Ele não é somente um chatbot.

Ele pode executar ações.

Então precisamos perguntar exatamente as mesmas coisas:

Quem é esse agente?

Como ele se autentica?

Quais ferramentas pode usar?

Quais dados pode acessar?

Pode alterar produção?

Precisa de aprovação humana?

Tudo fica auditado?

Por quanto tempo suas credenciais são válidas?

Em outras palavras:

agentes de IA precisam de identidade e autorização.

O fato de serem inteligentes não elimina controles.

Na realidade, aumenta a importância deles.


29. Prompt Injection — o bilhete explosivo da era da IA

Agora imagine que o agente lê documentos.

Dentro de um documento malicioso existe uma instrução construída para influenciá-lo.

O agente possui ferramentas.

Se a arquitetura for ruim, temos:

DOCUMENTO NÃO CONFIÁVEL
        |
        v
     MODELO
        |
        v
     AGENTE
        |
        v
     FERRAMENTA
        |
        v
    PRODUÇÃO

Esse é o equivalente moderno de deixar o Espião Preto escrever instruções diretamente no procedimento operacional do Espião Branco.

O controle não pode ser:

“o agente deve saber que não pode.”

Precisamos de barreiras externas.

Por exemplo:

AI AGENT
   |
   v
POLICY / AUTHORIZATION
   |
   +--> READ CUSTOMER       OK
   |
   +--> UPDATE CUSTOMER     APPROVAL
   |
   +--> DELETE DATABASE     DENY
   |
   +--> SUBMIT PROD JOB     DENY

Isso é segurança.

E parece assustadoramente parecido com conceitos que mainframe utiliza há décadas.


30. O “RACF imaginário” para agentes

Aqui está uma das analogias mais interessantes de toda a conversa.

Pense num agente de IA como um novo tipo de usuário.

Ele possui identidade.

Possui credenciais.

Possui privilégios.

Possui sessão.

Produz logs.

Tenta acessar recursos.

Portanto precisamos responder:

AGENT001
pode ler CUSTOMER?

AGENT001
pode atualizar CUSTOMER?

AGENT001
pode executar JOB?

AGENT001
pode fazer deploy?

AGENT001
pode alterar autorização?

Esse modelo mental é extremamente poderoso.

Não significa que RACF literalmente será responsável por toda ferramenta de IA.

Significa que a velha disciplina de:

IDENTITY
AUTHORIZATION
LEAST PRIVILEGE
AUDIT
SEPARATION OF DUTIES

continua perfeitamente válida.

A tecnologia mudou.

A pergunta fundamental não.


31. Um passo a passo para o Padawan COBOL começar a estudar segurança

Se você é iniciante em COBOL e tudo isso parece grande demais, siga uma sequência. Não tente tornar-se criptógrafo, pentester, analista SOC e especialista RACF na mesma terça-feira.

  1. Aprenda autenticação versus autorização. Entenda completamente a diferença entre provar quem é e receber permissão para fazer alguma coisa. Depois observe como isso aparece em TSO, CICS, datasets, Db2 e aplicações.

  2. Estude RACF conceitualmente. Não comece decorando comandos. Entenda usuário, grupo, recurso, perfil e permissão. Depois pratique operações controladas em ambiente de estudo.

  3. Aprenda TCP/IP básico. IP, porta, TCP, sessão, DNS, HTTP e TLS. Sem isso, firewall vira magia.

  4. Entenda firewall, proxy, NGFW e WAF. Não memorize dez definições. Pergunte em que camada cada controle trabalha e qual problema tenta resolver.

  5. Estude criptografia no nível de arquitetura. Saiba diferenciar AES, criptografia assimétrica, certificado, hash e TLS. Não precisa começar pela matemática.

  6. Aprenda MFA e FIDO2. Principalmente por que MFA reduz impacto de credenciais roubadas e por que autenticação resistente a phishing é tão importante.

  7. Olhe para seu COBOL como superfície de ataque. Entrada, saída, logging, autorização, tratamento de erro, SQL, credenciais, chamadas externas.

  8. Aprenda observabilidade. Descubra o que seu programa registra, como falhas são investigadas e como logs podem alimentar SOC/SIEM.

  9. Entenda recuperação. Descubra como sua aplicação volta depois de uma falha. Backup, restore, rollback e continuidade fazem parte de segurança.

  10. Finalmente, estude segurança de IA. Depois de dominar identidade, privilégios, rede e logging, agentes de IA deixam de parecer uma criatura alienígena. Eles tornam-se apenas outro ator que precisa receber poder cuidadosamente controlado.


32. Easter Egg: o ICH408I escondido atrás da cortina

Para quem chegou até aqui, eis nosso Easter Egg mainframe.

Imagine o Espião Preto tentando acessar um recurso para o qual não possui autorização.

Num universo z/OS poderíamos encontrar uma mensagem do tipo:

ICH408I

Para quem vive em RACF, ela é praticamente uma pequena sirene dizendo:

“Alguém tentou acessar algo e a segurança não gostou.”

O Espião Preto provavelmente tentaria apagar a mensagem.

O Espião Branco provavelmente teria ativado auditoria antes.

E o sysprog provavelmente estaria lendo SMF enquanto os dois discutiam.

Moral:

negado é bom. Negado e registrado é melhor. Negado, registrado e investigado é segurança operacional.


33. Curiosidade histórica: o mainframe não descobriu Zero Trust ontem

Existe algo divertido nessa história toda.

Muitas ideias apresentadas atualmente como modernas possuem ecos bastante antigos em ambientes mainframe:

privilégio mínimo
segregação de funções
auditoria
identidade forte
controle centralizado
logs
criptografia
proteção de recursos

Isso não significa que mainframe automaticamente implemente Zero Trust perfeito.

Nem que seja imune a ataques.

Mas existe uma cultura histórica de controle de acesso extremamente disciplinada.

Quando alguém pede:

— Dê ALTER para todo mundo, facilita.

O velho administrador RACF sente uma perturbação na Força.

Provavelmente derruba o café.


34. Outra curiosidade: criptografia perfeita pode perder para um Post-it

Você pode possuir:

AES-256
TLS
hardware criptográfico
certificados
MFA

e alguém escrever:

Senha: PROD1234

num Post-it grudado no monitor.

Esse contraste resume cibersegurança.

A segurança real é determinada pelo sistema completo.

Matemática forte não compensa processo fraco.

Tecnologia sofisticada não compensa privilégios excessivos.

Firewall caro não compensa credenciais roubadas.

MFA não compensa autorização irrestrita.

Backup não compensa nunca testar restauração.

É sempre o conjunto.


35. A arquitetura final no quadro branco

Antes de deixar o CPD, desenhei:

                 THREAT
                    |
                    v
                IDENTITY
                    |
                    v
             AUTHENTICATION
                    |
                    v
              AUTHORIZATION
                    |
                    v
                  NETWORK
                    |
                    v
               APPLICATION
                    |
                    v
                  DATA
                    |
                    v
               MONITORING
                    |
                    v
                 RESPONSE
                    |
                    v
                 RECOVERY

Do lado:

Firewall     protege caminhos de comunicação
WAF          protege aplicações web
MFA/FIDO2    fortalece identidade
RACF         controla acesso a recursos
TLS/AES      protegem dados
SIEM/SMF     ajudam a enxergar eventos
SOC          investiga
Backup/DR    ajuda a sobreviver
Zero Trust   muda a filosofia de confiança

Então acrescentei:

AI AGENT

O Espião Branco imediatamente escreveu:

LEAST PRIVILEGE

O Espião Preto tentou escrever:

SPECIAL

Nós apagamos.


Epílogo — os dois espiões finalmente concordaram em alguma coisa

No fim daquela manhã, o CPD continuava funcionando.

O firewall estava ativo.

O WAF observava o tráfego web.

TLS protegia comunicações.

RACF cuidava dos recursos.

Logs alimentavam monitoramento.

Backups permaneciam disponíveis.

E o agente de IA ainda não tinha recebido ALTER.

O Espião Preto olhou para o Branco.

O Branco olhou para o Preto.

Pela primeira vez em décadas, concordaram:

nenhuma defesa isolada basta.

Cibersegurança não é:

COMPRAR FIREWALL

É:

IDENTIFICAR
AUTENTICAR
AUTORIZAR
SEGMENTAR
CRIPTOGRAFAR
MONITORAR
DETECTAR
RESPONDER
RECUPERAR

E talvez essa seja a principal lição para o programador COBOL iniciante.

Seu programa pode ter sido escrito numa linguagem criada há mais de seis décadas.

Pode executar dentro de um IBM Z.

Pode manipular datasets, Db2, VSAM ou transações CICS.

Mas hoje ele pode estar a poucos saltos de rede de um smartphone, uma API, uma cloud, um microsserviço ou até um agente autônomo de Inteligência Artificial.

Por isso o programador COBOL moderno não precisa tornar-se um hacker.

Precisa tornar-se algo muito mais valioso:

um desenvolvedor que entende confiança.

Quem pode entrar?

Quem pode executar?

Quem pode alterar?

Quem pode ler?

O que precisa estar criptografado?

O que precisa ser registrado?

O que acontece se alguma defesa falhar?

E principalmente:

qual é o mínimo de poder necessário para aquela identidade cumprir sua função?

O Espião Preto levantou a mão.

— Posso ter acesso administrativo?

RACF respondeu:

ICH408I

O Espião Branco começou a rir.

Três segundos depois, uma pequena explosão saiu de dentro da cafeteira.

Algumas tradições, afinal, precisam ser preservadas.

domingo, 16 de abril de 2023

☕🔐 “A SENHA MORREU” — COMO O MAINFRAME DESCOBRIU QUE USERID + PASSWORD NÃO ERAM MAIS SUFICIENTES 💀🖥️📱

 

Bellacosa Mainframe e ibm mfa racf e tokens login seguro

☕🔐 “A SENHA MORREU” — COMO O MAINFRAME DESCOBRIU QUE USERID + PASSWORD NÃO ERAM MAIS SUFICIENTES 💀🖥️📱

Imagine a cena…

Um programador júnior abre o emulador 3270, digita:

LOGON ===> VBELLA
PASSWORD ===> MAIN123

E pensa:

“Pronto… estou seguro.”

Só que não.

Durante décadas, milhares de ambientes z/OS confiaram apenas em:

  • USERID

  • senha RACF

O problema?

Se alguém roubasse:

  • sua senha

  • dump de memória

  • print

  • phishing

  • keylogger

…o invasor entrava no mainframe como se fosse você.

Foi aí que nasceu o:

🔥 Dual Login / MFA no Mainframe

Agora o login exige:

Algo que você SABE
+
Algo que você POSSUI

Ou seja:

Senha RACF
+
Token do celular

O celular virou literalmente:

📱 A CHAVE FÍSICA DO MAINFRAME


☕ O QUE É O “DUAL LOGIN” NO z/OS?

É a autenticação em dois fatores.

No mundo IBM Z normalmente envolve:

  • RACF

  • IBM Z MFA

  • Microsoft Authenticator

  • Google Authenticator

  • RADIUS/TOTP

Fluxo:

TSO → RACF → IBM MFA → celular → validação

🔥 O QUE O PROGRAMADOR VÊ

Antes:

USERID + PASSWORD

Agora:

USERID + PASSWORD + TOKEN

Exemplo:

USERID ===> VBELLA
PASSWORD => MAIN123483921

Onde:

  • MAIN123 = senha RACF

  • 483921 = token do celular


🖥️ O QUE O RACF FAZ POR TRÁS

O RACF:

  1. valida usuário

  2. valida senha

  3. detecta MFA habilitado

  4. chama o IBM MFA

  5. valida o token

Se tudo bater:

ICH70001I LOGON ACCEPTED

Senão:

ICH70004I INVALID MFA TOKEN

📱 COMO O MICROSOFT AUTHENTICATOR ENTRA NA HISTÓRIA

O Microsoft Authenticator não “fala diretamente” com o TSO.

Ele apenas:

🔥 GERA CÓDIGOS TEMPORÁRIOS

Exemplo:

483921

30 segundos depois:

992184

Esses códigos são calculados matematicamente usando:

  • horário atual

  • chave secreta compartilhada


☕ O SEGREDO MAIS IMPORTANTE

Quando o MFA é configurado:

  • o servidor IBM MFA cria uma SECRET KEY

  • essa chave vai:

    • para o z/OS

    • para o celular

Os dois lados fazem o mesmo cálculo.

Por isso:

📱 O CELULAR E O MAINFRAME “PENSAM IGUAL”


🔥 PASSO A PASSO DO CADASTRO MFA

1. Administrador habilita MFA no RACF

Exemplo:

RDEFINE MFADEF FACTOR.AZFTOTP

Isso cria o fator TOTP.


2. Associar MFA ao usuário

Exemplo:

ALTUSER VBELLA MFA(FACTOR(AZFTOTP) ACTIVE)

Agora o usuário:

VBELLA

é obrigado a usar token.


3. IBM MFA gera QR Code

Algo parecido com:

otpauth://totp/MAINFRAME:VBELLA

4. Usuário abre o Microsoft Authenticator

No celular:

+
Other Account
Scan QR Code

5. O celular começa a gerar tokens

Exemplo:

483921

Mudando a cada 30 segundos.


🔥 COMO O LOGIN ACONTECE

O programador digita:

LOGON ===> VBELLA
PASSWORD ===> MAIN123483921

O RACF separa:

Senha = MAIN123
Token = 483921

IBM MFA calcula o token esperado

Internamente:

HASH(secret + current_time)

Resultado:

483921

Se bater:

ACCESS GRANTED

💀 O QUE MAIS DÁ PROBLEMA EM PRODUÇÃO

1. Token expirado

O usuário demora demais.

O token muda:

483921 → 992184

E o login falha.


2. Horário do celular errado

MFA depende do relógio.

Se o celular estiver dessincronizado:

  • token inválido

  • RACF rejeita


3. Usuário troca de celular

O MFA precisa ser reassociado.

Senão:

LOGIN BLOQUEADO

4. Print do QR Code

Isso é gravíssimo.

Quem tiver o QR:

  • consegue clonar o MFA


☕ ONDE ISSO É CONFIGURADO NO MAINFRAME?

RACF

Comandos:

  • ALTUSER

  • MFADEF

  • perfis MFA


IBM MFA STC

Started task típica:

AZFSTC

Ela:

  • conversa com RACF

  • valida tokens

  • integra com Authenticator


Arquivos de configuração

Dependendo da instalação:

AZFCONF
AZFEXEC
PARMLIB

🔥 COMO O TSO “ENXERGA” O MFA

O TSO puro não entende Authenticator.

Quem entende é:

RACF + IBM MFA

O TSO apenas:

  • recebe USERID

  • recebe PASSWORD field

O RACF interpreta o resto.


☕ A GRANDE SACADA DO MAINFRAME MODERNO

O mais impressionante é que:

💀 UM SISTEMA DOS ANOS 70 CONSEGUIU INTEGRAR MFA COM CELULAR MODERNO

Hoje é possível usar:

  • FaceID

  • push notification

  • Microsoft Authenticator

  • biometria

  • tokens cloud

…em cima de um:

3270 verde-preto

E isso é absurdamente fascinante.


🧠 RESUMO MENTAL PARA JÚNIOR

Pense assim:

TSO = tela de login
RACF = segurança principal
IBM MFA = motor MFA
Authenticator = gerador de token

Fluxo:

Usuário
   ↓
TSO
   ↓
RACF
   ↓
IBM MFA
   ↓
Microsoft Authenticator
   ↓
Token validado
   ↓
ISPF liberado

☕ FRASE FINAL

“No passado, invadir um mainframe exigia roubar uma senha.
Hoje, você precisa roubar também o bolso do programador.” 🔐📱💀

 

sexta-feira, 15 de julho de 2022

☕💥 A Jornada do Sysprog Padawan – ACEE : Anatomia do Crachá Mágico do Reino IBM Z - Parte II

 

Bellacosa Mainframe apresenta o ACEE Parte II

☕💥 A Jornada do Sysprog Padawan – Parte 2

ACEE – Anatomia do Crachá Mágico do Reino IBM Z

O que realmente existe dentro de um ACEE?

"Todo Sysprog olha para um dump. O Sysprog Jedi conversa com os control blocks."

Bellacosa Mainframe


Introdução

Na Parte 1 descobrimos que o ACEE é praticamente o crachá encantado do Reino IBM Z.

Mas afinal...

O que existe dentro dele?

Ele possui apenas o userid?

Possui senha?

Está criptografado?

Pode ser alterado?

Quem consegue enxergá-lo?

Quanto espaço ocupa?

É isso que vamos explorar.


Antes de tudo

O ACEE é um Control Block do RACF.

Ele é criado em memória.

Não é VSAM.

Não é DB2.

Não é Dataset.

Não é USS File.

Ele simplesmente nasce, vive durante a sessão e desaparece ao final dela.


Onde mora o ACEE?

Depende.

Pode estar associado a:

TCB

Task Control Block


ASCB

Address Space Control Block


SRB

Service Request Block


OMVS Process


DB2 Thread


CICS Task


IMS Region


Started Task


Anatomia simplificada

Podemos imaginar o ACEE como uma estrutura lógica.

+--------------------------------+
| ACEE HEADER                    |
+--------------------------------+
| USERID                         |
+--------------------------------+
| GROUPS                         |
+--------------------------------+
| SPECIAL FLAGS                  |
+--------------------------------+
| UID / GID                      |
+--------------------------------+
| CERTIFICATES                   |
+--------------------------------+
| MFA                            |
+--------------------------------+
| SECURITY LABELS                |
+--------------------------------+
| CUSTOM ATTRIBUTES              |
+--------------------------------+
| POINTERS                       |
+--------------------------------+

Naturalmente a IBM não documenta tudo detalhadamente para programação de aplicações comuns.

Mas Sysprogs adoram estudar essas estruturas.


Campo 1 — USERID

O mais conhecido.

Exemplo

VBELLACO

Pode possuir até oito caracteres.


Ele representa:

Quem você é.


Mas atenção.

Senha NÃO fica armazenada.


Passphrase também não.


Hash de senha também não.


Segurança agradece.


Campo 2 — Nome do Grupo

Exemplo

SYS1

ou

MQADMIN

Grupo primário.


Grupo conectado.


Grupo default.


Campo 3 — Connected Groups

Pode haver dezenas.

Exemplo

DBA

SYSOPER

MQADM

IMSADM

DEVOPS

SECURITY

Essas informações permitem decisões rápidas.


Sem voltar ao banco RACF.


Campo 4 — Special Attributes

Muito importante.


Flag SPECIAL

Administrador.


OPERATIONS

Super usuário RACF.


AUDITOR

Auditoria.


CLAUTH

Gerencia Classes.


ROAUDIT

Read-only.


Curiosidade Bellacosa ☕

SPECIAL é praticamente:

A chave mestra do castelo.


OPERATIONS

É o passe VIP.


AUDITOR

É o fiscal do reino.


Campo 5 — OMVS Segment

Chegamos ao USS.


UID

Exemplo

1000

GID

100

HOME

/u/vbellaco

PROGRAM

/bin/sh

Campo 6 — Certificados

Muito usado hoje.


Digital Certificate


PKI


TLS


SSH


MQ


zOS Connect


API Gateway


Open Banking


PIX


Pode existir referência ao certificado associado ao usuário.


Campo 7 — MFA

Nos ambientes modernos.


RSA


TOTP


Smartcard


Passkey


FIDO


Token Context


Campo 8 — Labels

Pouco utilizados.

Mas interessantes.


MLS

Mandatory Access Control


Exemplos

PUBLIC


CONFIDENTIAL


SECRET


TOPSECRET

Muito comum em:

Defesa

Governo

Militar


Campo 9 — ACEE Tokens

Pouco comentado.

Muito poderoso.


Permitem passar contexto.


CICS utiliza.


DB2 utiliza.


MQ utiliza.


Subsystems utilizam.


Cross-memory utiliza.


Campo 10 — Ponteiros

Sysprog gosta.


Ponteiro para:

TCB

ASCB

Groups

Security Labels

OMVS

Certificates


É um verdadeiro mini ecossistema.


Quanto memória consome?

Pergunta clássica.


Resposta curta.

Depende.


Usuário simples

Alguns KB.


Usuário com muitos grupos

Mais.


Certificados

Mais.


MFA

Mais.


Custom Attributes

Mais.


Na prática.

Centenas.

Milhares.

De ACEEs.

Não representam um problema.


O impacto em CPU

Muito pequeno.


Comparado ao custo de consultar RACF.


ACEE economiza:

CPU

I/O

Locks

ENQ

Contention


Em um banco.

100 mil sessões.

Economia enorme.


z/OS 3.1

Novidade interessante.


Custom Fields.


Permitem aplicações modernas.

Consultar contexto.


Sem voltar ao RACF.


Menos latência.


Menos I/O.


Mais escalabilidade.


O que NÃO existe no ACEE?

Senha.


Passphrase.


Hash.


Histórico.


Dataset profiles.


Banco RACF completo.


Quem pode enxergar um ACEE?

Usuário comum?

Não.


COBOL?

Normalmente não.


Sysprog?

Sim.


IPCS

Sim.


Dumps

Sim.


Ferramentas IBM

Sim.


IPCS

Nosso sabre de luz.


Dump

IPCS

VERBX

Interpretar ACEE


Ferramentas comerciais ajudam bastante.


zSecure


Security Server utilities


IBM Support Tools


Easter Egg Bellacosa ☕

Se você abrir um dump e encontrar:

TCB

ASCB

ACEE

UID

SPECIAL

CERT


Parabéns.

Você acabou de entrar no clube dos Sysprogs que começam a conversar com os control blocks.


Analogia Bellacosa

Imagine novamente o castelo.


No crachá mágico existem:

Nome

Guilda

Permissões

Passaporte

Cartão diplomático

Etiqueta de segurança

Passe do metrô USS

Certificado digital

Token MFA


Tudo em um único objeto.


E o melhor.

O guarda SAF apenas olha para ele.


Não precisa voltar ao cartório RACF.


Economizando tempo.

CPU.

E trabalho.


Resumo para guardar

CampoFunção
USERIDIdentidade
GROUPSGrupos
SPECIALAdministração
UIDUSS
GIDUSS
CERTTLS
MFAAutenticação
LABELMLS
TOKENContexto
POINTERSLigações internas

☕💥 Continua na Parte 3

O Nascimento do ACEE

Como ele é criado no TSO, CICS, IMS, Batch, Started Tasks, USS, MQ e DB2, incluindo RACROUTE VERIFY, SAF, FASTAUTH, diagramas passo a passo e exemplos reais de fluxo de autenticação.


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