 |
| 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 PROOFDo 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 = TRUEInfelizmente, 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 443Ele 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
ProtocolEsse é 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 PERMITIDAnão significa:
CONTEÚDO SEGUROO 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_SENTIsso 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á dentroIsso 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.EXEInfelizmente 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 ---- SERVIDOREsse é 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 <----> SERVIDORO 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
DATABASEPor que isso importa?
Porque um firewall de rede pode enxergar:
TCP/443Enquanto 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 maliciososImagine:
GET /cliente?id=123Isso 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 IntegrationEra 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ãoIsso permite políticas muito mais sofisticadas.
A velha regra:
ALLOW PORT 443pode 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
PASSWORDE o sistema reconhecer:
USERID = BELLACOIsso não significa automaticamente:
BELLACO PODE ALTERAR PAYROLLNem:
BELLACO PODE APAGAR PROD.DB2.CUSTOMERNem:
BELLACO PODE ALTERAR RACFAutenticaçã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
PASSWORDFunciona?
Sim.
É perfeita?
Longe disso.
Senhas sofrem ataques e problemas como:
phishing
credential stuffing
password reuse
keylogging
brute force
vazamento de banco de credenciais
engenharia socialE 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:
381729vá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ê sabeChave física:
algo que você possuiBiometria:
algo que você éUma sutileza importante:
senha + outra senhanão representa necessariamente dois fatores diferentes.
É:
KNOW + KNOWUm desenho mais forte seria:
PASSWORD + SECURITY KEYou:
DEVICE + BIOMETRIC VERIFICATION9. 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çoO servidor envia um desafio.
O autenticador assina esse desafio.
O servidor verifica.
SERVER
|
challenge
v
AUTHENTICATOR
|
signature
v
SERVERA 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
ENTERNão.
Passwordless significa remover a senha tradicional como principal segredo de autenticação.
Isso pode envolver:
Passkeys
FIDO2
WebAuthn
certificados
smart cardsNa 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 READO 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ÉTRICAe
CRIPTOGRAFIA ASSIMÉTRICANa 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 bitsCuriosidade 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 conheceSe 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 KEYEla permite construir mecanismos relacionados a:
assinaturas digitais
autenticação
troca/estabelecimento de chaves
PKI
certificadosAlgoritmos 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
DATAEntã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
DIGESTNão existe a ideia normal de:
digest
|
decrypt
|
password originalHashing é unidirecional.
É utilizado, entre outras coisas, em mecanismos de integridade e em sistemas de armazenamento seguro de senhas, com técnicas apropriadas.
Nunca pense:
HASH = ENCRYPTIONSã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 threatE elas frequentemente se combinam.
Imagine:
ATACANTE EXTERNO
|
v
PHISHING
|
v
CREDENCIAL ROUBADA
|
v
LOGIN VÁLIDOAgora aquele atacante externo parece um usuário interno legítimo.
Por isso a antiga divisão:
FORA = PERIGOSO
DENTRO = CONFIÁVELcomeç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
auditingO 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
APIsUma 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 testadoIsso 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 é:
AUTORIZADOPentest 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 Researcher21. 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
ObjectiveO Blue Team defende.
Ele trabalha com:
monitoramento
detecção
SIEM
EDR
hardening
incident response
threat hunting
forensicsE 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:
USER01tentando acessar:
PROD.PAYROLL.MASTERO controle pode considerar permissões como:
READ
UPDATE
CONTROL
ALTER
NONEO 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-IFQuem 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 erroSeguranç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
|
Db2O 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
CONFIEZero 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 comprometimentoO 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
AESExcelente.
Mas alguém consegue passar.
O que acontece agora?
Precisamos detectar comportamento anormal.
Entram:
logs
SIEM
SOC
SMF
correlation
alerting
behavior analytics
threat huntingImagine um usuário que normalmente trabalha:
08:00 - 18:00
Brasil
20 transações/horaE subitamente vemos:
03:17
milhares de consultas
download incomum
mudança de privilégios
acesso a datasets nunca consultadosUma arquitetura madura precisa perceber.
Segurança não é somente prevenção.
Também é:
DETECT
RESPOND
RECOVER27. 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 responseRTO 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
aprender28. Agora aparece o convidado mais novo: o agente de IA
Nesse momento uma janela apareceu no monitor:
AI AGENT REQUESTING ACCESSO 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
APIsEle 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ÇÃOEsse é 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 DENYIsso é 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 DUTIEScontinua 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.
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.
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.
Aprenda TCP/IP básico. IP, porta, TCP, sessão, DNS, HTTP e TLS. Sem isso, firewall vira magia.
Entenda firewall, proxy, NGFW e WAF. Não memorize dez definições. Pergunte em que camada cada controle trabalha e qual problema tenta resolver.
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.
Aprenda MFA e FIDO2. Principalmente por que MFA reduz impacto de credenciais roubadas e por que autenticação resistente a phishing é tão importante.
Olhe para seu COBOL como superfície de ataque. Entrada, saída, logging, autorização, tratamento de erro, SQL, credenciais, chamadas externas.
Aprenda observabilidade. Descubra o que seu programa registra, como falhas são investigadas e como logs podem alimentar SOC/SIEM.
Entenda recuperação. Descubra como sua aplicação volta depois de uma falha. Backup, restore, rollback e continuidade fazem parte de segurança.
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:
ICH408IPara 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 recursosIsso 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
MFAe alguém escrever:
Senha: PROD1234num 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
RECOVERYDo 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çaEntão acrescentei:
AI AGENTO Espião Branco imediatamente escreveu:
LEAST PRIVILEGEO Espião Preto tentou escrever:
SPECIALNó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
RECUPERARE 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:
ICH408IO 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.
