☕ Um Café no Bellacosa Mainframe

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

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

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

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

— A KAOS invadiu o datacenter?

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

— Isso parece ótimo, Chefe.

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

— Ah. Nesse caso, estamos mortos.

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

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

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

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

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

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

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

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

descobrir quais ativos existem;
compreender quais deles são críticos;
identificar ameaças e vulnerabilidades;
administrar identidades e privilégios;
desenvolver software seguro;
monitorar o ambiente;
responder a incidentes;
recuperar dados e serviços;
atender leis e contratos;
preservar evidências;
aprender com cada falha.

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

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

No IBM Z, isso pode ser traduzido assim:

Governar: definir proprietários, políticas, segregação de funções e risco aceitável.
Identificar: inventariar LPARs, aplicações, started tasks, usuários, datasets, filas MQ, APIs, certificados e dependências.
Proteger: usar RACF, criptografia, hardening, MFA, menor privilégio e programação segura.
Detectar: coletar SMF, logs de CICS, Db2, z/OSMF, USS, rede e ferramentas de segurança.
Responder: bloquear credenciais, conter o incidente, preservar evidências e comunicar responsáveis.
Recuperar: restaurar dados confiáveis, validar integridade e retomar os serviços na ordem correta.

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

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

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

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

Confidentiality — Confidencialidade;
Integrity — Integridade;
Availability — Disponibilidade.

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

2.1 Confidencialidade

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

Exemplos:

um cliente vê apenas suas próprias contas;
um operador acessa os comandos necessários, mas não toda a administração do sistema;
uma aplicação CICS lê somente os recursos indispensáveis;
uma cópia de produção usada em testes tem dados mascarados;
backups, dumps e logs recebem proteção equivalente à informação original.

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

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

2.2 Integridade

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

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

erro de programação;
campo truncado;
processamento duplicado;
mensagem MQ consumida duas vezes;
restauração de backup antigo;
atualização parcial;
regra de negócio incorreta;
falha de sincronização.

Considere este trecho didático:

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

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

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

2.3 Disponibilidade

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

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

Disponibilidade envolve:

redundância;
capacidade;
proteção contra DDoS;
manutenção;
monitoração;
backup;
recuperação de desastre;
tolerância a falhas;
operação degradada segura.

Duas siglas são fundamentais:

RTO: tempo máximo aceitável para restaurar o serviço;
RPO: quantidade máxima aceitável de dados perdidos, normalmente expressa em tempo.

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

2.4 O que existe além da CIA?

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

autenticidade;
responsabilização;
rastreabilidade;
privacidade;
não repúdio;
resiliência;
segurança física;
segurança humana.

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

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

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

Ativo

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

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

Ameaça

É uma circunstância capaz de causar dano.

Pode ser:

criminoso;
funcionário mal-intencionado;
usuário enganado;
incêndio;
falha elétrica;
erro humano;
fornecedor comprometido;
ransomware;
bug destrutivo.

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

Vulnerabilidade

É uma fraqueza que pode ser explorada ou acionada:

SQL construído por concatenação;
senha reutilizada;
software desatualizado;
conta órfã;
porta administrativa exposta;
excesso de privilégios;
ausência de segregação de funções;
procedimento de recuperação nunca testado.

Exposição

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

Controle

É uma medida que reduz probabilidade ou impacto:

MFA;
firewall;
validação;
revisão de código;
limite transacional;
segmentação;
monitoração;
backup imutável.

Risco

Uma fórmula didática é:

Risco ≈ Probabilidade × Impacto

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

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

O componente vulnerável é realmente utilizado?
Está exposto?
Existe exploração conhecida?
A exploração exige autenticação?
Com qual privilégio o processo roda?
Que dados podem ser alcançados?
Existem controles compensatórios?
Qual seria o impacto para o negócio?

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

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

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

Vírus

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

Worm

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

Trojan

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

Ransomware

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

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

Spyware e keylogger

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

Rootkit

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

Botnet

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

Insider threat

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

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

5. Engenharia social — a vulnerabilidade usa crachá

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

autoridade;
urgência;
medo;
curiosidade;
escassez;
desejo de ajudar;
fadiga;
hábito.

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

Exemplo:

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

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

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

MFA resistente a phishing;
aprovação dupla;
limites transacionais;
filtragem de mensagens;
privilégio mínimo;
detecção comportamental;
confirmação fora de banda;
canal simples para denúncia.

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

6. O ataque não segue um fluxograma obediente

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

Uma campanha pode incluir:

pesquisa sobre funcionários e fornecedores;
criação de domínio parecido;
phishing direcionado;
roubo de sessão;
acesso inicial;
descoberta do ambiente;
roubo de credenciais;
escalada de privilégio;
persistência;
movimento lateral;
coleta;
exfiltração;
impacto.

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

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

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

O desenho clássico é:

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

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

Firewall

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

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

IDS e IPS

IDS detecta e alerta.
IPS pode intervir e bloquear.

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

Proxy, reverse proxy, WAF e gateway

“Proxy” é uma família:

forward proxy representa clientes;
reverse proxy representa servidores;
WAF analisa tráfego de aplicação web;
API gateway autentica, limita e roteia chamadas.

Nenhum deles corrige automaticamente código inseguro.

VPN

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

Segmentação

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

Pergunte a cada fluxo:

quem chama?
usando qual identidade?
por qual protocolo?
para qual finalidade?
com qual privilégio?
como será auditado?
o que acontece quando falha?

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

Essas quatro etapas precisam ser separadas.

Identificação

“Sou o usuário MAXWELL86.”

Autenticação

“Consigo provar que sou MAXWELL86.”

Autorização

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

Accountability

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

No RACF:

o USERID declara a identidade;
senha, certificado, PassTicket ou MFA ajudam a autenticar;
perfis, grupos e níveis de acesso determinam autorização;
SMF e outros registros fornecem evidências.

MFA

Os fatores clássicos são:

algo que você sabe;
algo que você possui;
algo que você é.

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

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

Senhas

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

As diretrizes modernas favorecem:

comprimento;
blocklist de senhas comuns ou vazadas;
gerenciador de senhas;
ausência de trocas periódicas sem suspeita de comprometimento;
MFA;
proteção contra tentativas automatizadas.

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

Menor privilégio

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

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

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

Igor colocou a senha em Base64 e declarou:

— Pronto. Está criptografada.

O Chefe olhou para o Agente 86.

— Você quer contar ou eu conto?

Encoding

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

senha123 → c2VuaGExMjM=

Qualquer pessoa pode reverter essa representação.

Hashing

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

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

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

Criptografia simétrica

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

Criptografia assimétrica

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

Sistemas reais geralmente são híbridos:

mecanismo assimétrico estabelece um segredo de sessão;
mecanismo simétrico protege o volume de dados.

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

Gestão de chaves

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

geração;
armazenamento;
distribuição;
rotação;
segregação;
revogação;
destruição;
recuperação controlada.

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

Assinatura digital

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

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

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

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

SQL Injection

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

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

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

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

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

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

XSS

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

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

CSRF

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

Defesas incluem:

token anti-CSRF;
cookies SameSite;
verificação de origem;
reautenticação em operações críticas;
não usar GET para alterar estado.

Controle de acesso quebrado

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

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

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

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

Controle de acesso quebrado;
Configuração insegura;
Falhas na cadeia de suprimentos de software;
Falhas criptográficas;
Injeção;
Design inseguro;
Falhas de autenticação;
Falhas de integridade de software ou dados;
Falhas de logging e alertas;
Tratamento incorreto de condições excepcionais.

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

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

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

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

Programação segura inclui:

validação de entrada;
consultas parametrizadas;
encoding de saída;
autenticação forte;
autorização em cada operação;
menor privilégio;
tratamento seguro de erro;
logging útil;
proteção de segredos;
atualização de dependências;
revisão de código;
testes de segurança.

Validação de domínio

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

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

Falhar de forma segura

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

Falhar de forma segura exige:

estado consistente;
rollback;
idempotência;
mensagens externas discretas;
evidência interna suficiente;
negação por padrão quando apropriada.

Logs

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

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

Cadeia de suprimentos

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

quais componentes existem;
de onde vieram;
quem alterou o pipeline;
quais artefatos foram assinados;
onde estão os segredos;
como revogar uma versão comprometida;
como reconstruir o software de forma confiável.

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

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

Vamos acompanhar uma transferência.

Passo 1 — O cliente se conecta

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

Passo 2 — O cliente se identifica e autentica

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

Passo 3 — O sistema autoriza

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

Passo 4 — A regra de negócio valida

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

Passo 5 — A transação é executada

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

Passo 6 — A operação é registrada

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

Passo 7 — A fraude é analisada

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

Passo 8 — O ambiente monitora

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

Passo 9 — Se algo der errado

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

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

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

Antes de entregar um programa, pergunte:

Todos os campos externos têm tamanho, tipo e domínio validados?
Valores negativos, zeros, limites e overflow foram tratados?
Cada operação verifica autorização, não apenas autenticação?
O programa usa apenas os privilégios necessários?
SQL dinâmico e comandos externos separam código de dados?
Return codes e condições excepcionais são tratados?
Atualizações relacionadas usam unidade transacional adequada?
Reprocessamento é idempotente ou pode duplicar operações?
Logs possuem correlação e não vazam segredos?
Mensagens ao usuário evitam detalhes internos?
Senhas, tokens e chaves estão fora do fonte e do JCL?
Há testes de sucesso, negação, limite, falha e recuperação?
Alguém revisou o código com olhar de abuso, não só de funcionalidade?
Existe plano para detectar e corrigir o comportamento em produção?

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

Epílogo — Desculpe por isso, Chefe

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

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

— Comece pelas boas.

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

— E as más?

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

— 86...

— Eu sei, Chefe. Errei por isso aqui.

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

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

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

O que estou protegendo?
De quem ou de quê?
Como isso pode falhar?
Quem realmente precisa de acesso?
Como saberei que algo aconteceu?
O que farei quando acontecer?
Como provarei o que ocorreu?
Como voltarei a operar com segurança?

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

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

Referências para continuar a missão

☕ Um Café no Bellacosa Mainframe

Cibersegurança: dos fundamentos à recuperação

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

Vocabulário e Fundamentos da Cibersegurança

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

Ler o Capítulo I no artigo original →

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

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

Ler o Capítulo II no artigo original →

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