 |
| Bellacosa Mainframe apresenta o IBM FlashSystem |
☕ Um Café no Bellacosa Mainframe
IBM FlashSystem sem Mistérios para Programadores COBOL
Quando o ransomware entrou no Data Center, apagou os snapshots e descobriu que o disco também sabia investigar
O sol se põe lentamente sobre Miami.
Uma câmera imaginária atravessa o estacionamento de um Data Center cercado por palmeiras, geradores a diesel e placas ameaçadoras dizendo:
ACESSO RESTRITO — AMBIENTE DE PRODUÇÃO
No interior do prédio, dezenas de servidores continuam trabalhando. Luzes verdes piscam. Ventiladores giram. Aplicações Java consomem memória como se não houvesse amanhã. Um CICS atende transações bancárias sem reclamar. Um programa COBOL, compilado quando muita gente ainda usava telefone com fio, calcula prestações, impostos e aposentadorias com a serenidade de um monge digital.
Tudo parece normal.
Até que um analista percebe algo estranho.
Milhares de arquivos estão sendo modificados.
A taxa de escrita disparou.
O nível de entropia dos dados aumentou.
Snapshots começaram a desaparecer.
E alguém, usando uma credencial administrativa legítima, acabou de executar comandos que nenhum administrador legítimo deveria executar às três e dezessete da manhã.
O telefone toca.
— Temos um incidente — diz o operador.
O chefe da equipe coloca lentamente os óculos escuros.
Olha para o rack.
Olha para o painel.
E responde:
— Parece que alguém tentou criptografar o caso inteiro.
Entra a música de abertura.
Bem-vindo ao CSI: Miami Data Center, onde os cadáveres são volumes lógicos, as impressões digitais estão nos blocos de I/O e o assassino quase sempre utiliza uma conta de administrador que “ninguém sabia que ainda existia”.
Neste café especial do Bellacosa Mainframe, vamos investigar o IBM FlashSystem, os FlashCore Modules de quinta geração, a detecção de ransomware no hardware, o Safeguarded Copy, o Cyber Vault, a inteligência artificial operacional e as diferenças entre os modelos FlashSystem 5600, 7600 e 9600.
Tudo explicado para o programador COBOL iniciante que talvez nunca tenha administrado uma storage, mas que certamente já gravou um arquivo, atualizou um registro ou descobriu — tarde demais — que o backup não estava tão atualizado quanto todos imaginavam.
Prepare o café.
Isole a cena.
Não toque nos snapshots.
 |
| Bellacosa Mainframe e o FlashSystem |
1. A vítima: o dado corporativo
Em uma investigação criminal tradicional, existe uma vítima.
No mundo da infraestrutura, a vítima geralmente é o dado.
Pode ser:
uma conta bancária;
uma folha de pagamento;
uma apólice de seguros;
um prontuário médico;
um cadastro de clientes;
um arquivo VSAM;
uma tabela Db2;
uma imagem de máquina virtual;
um volume de Kubernetes;
um conjunto de treinamento de inteligência artificial;
ou aquele arquivo chamado CLIENTE-FINAL-AGORA-VAI-VERSAO-23.dat.
Durante muito tempo, a missão do storage era relativamente simples:
armazenar o dado;
devolver o dado quando solicitado;
não perder o dado;
fazer isso rapidamente.
Porém, o crime digital evoluiu.
Hoje, o storage não pode ser apenas um armário eletrônico. Ele precisa participar da segurança.
O motivo é simples: ransomware não está interessado apenas em derrubar servidores.
Ele quer destruir a confiança na informação.
Um ataque moderno pode tentar:
criptografar os dados de produção;
apagar backups acessíveis;
remover snapshots;
desabilitar replicações;
comprometer contas administrativas;
modificar políticas de retenção;
contaminar cópias históricas;
impedir que a empresa saiba qual versão do dado ainda é confiável.
A grande pergunta deixou de ser:
“Temos backup?”
Agora é:
“Temos uma cópia limpa, protegida, identificável e recuperável?”
Essa diferença parece pequena, mas separa um incidente controlável de uma catástrofe operacional.
2. O storage não é apenas um monte de discos
Para o iniciante, uma storage pode parecer apenas um grande conjunto de SSDs.
Algo como:
SERVIDORES
|
v
STORAGE
|
v
MUITOS DISCOS
Na prática, uma storage corporativa possui controladores, cache, memória, processadores, interfaces de rede, software de virtualização, mecanismos de replicação, compressão, criptografia, monitoramento e gerenciamento de falhas.
Uma arquitetura simplificada pode ser imaginada assim:
APLICAÇÃO COBOL, JAVA, SAP OU BANCO DE DADOS
|
v
SISTEMA OPERACIONAL
|
v
DRIVER / MULTIPATH / SAN
|
v
CONTROLADORES DA STORAGE
|
v
MÓDULOS FLASH / SSDs
|
v
DADOS
Cada camada pode proteger, acelerar ou transformar a operação.
O IBM FlashSystem acrescenta uma característica importante: parte da inteligência de proteção é levada para muito perto do ponto em que o dado realmente é gravado.
É aí que entra o FlashCore Module.
3. A primeira evidência: o FlashCore Module não é um SSD comum
Chamar um FlashCore Module de simples SSD seria como chamar um mainframe de “computador grande”.
Tecnicamente, não está completamente errado.
Mas também não explica quase nada.
O FlashCore Module, ou FCM, combina memória flash com lógica especializada para executar determinadas funções diretamente no módulo.
Dependendo da geração e da configuração, isso pode incluir:
compressão acelerada;
criptografia;
correção de erros;
gerenciamento de desgaste;
telemetria;
análise de padrões de I/O;
detecção de comportamentos anômalos.
O objetivo é aliviar parte do trabalho que normalmente ficaria concentrado nos controladores ou em camadas superiores de software.
Para um programador COBOL, podemos fazer uma analogia.
Imagine que todas as validações de um arquivo só fossem realizadas muito depois da gravação:
WRITE REGISTRO-CLIENTE.
PERFORM VALIDAR-DADOS-MAIS-TARDE.
Isso cria uma janela perigosa.
O dado já foi alterado.
O erro já entrou.
O sistema só perceberá depois.
Agora imagine uma arquitetura em que o próprio caminho da gravação participa da inspeção:
PERFORM ANALISAR-PADRAO-DO-DADO
IF OPERACAO-SUSPEITA
PERFORM GERAR-ALERTA
END-IF
WRITE REGISTRO-CLIENTE.
Naturalmente, o hardware real não executa COBOL dessa forma. A comparação serve para mostrar o conceito: aproximar a análise do ponto de gravação.
É como colocar um perito na porta da sala de evidências, não apenas na central de monitoramento do outro lado da cidade.
4. FCM5: a quinta geração entra na cena
A quinta geração dos FlashCore Modules é apresentada pela IBM como uma evolução da análise e da proteção inline.
A palavra importante aqui é inline.
Em um modelo de análise posterior, a operação ocorre primeiro e a inspeção acontece depois:
DADO É GRAVADO
|
v
LOG É GERADO
|
v
SOFTWARE ANALISA
|
v
ALERTA APARECE
Em uma abordagem inline, parte da observação acontece durante o fluxo de I/O:
I/O CHEGA
|
v
PADRÃO É OBSERVADO
|
v
DADO É GRAVADO
|
v
ANOMALIA PODE GERAR ALERTA
Isso não significa que cada bloco recebe um carimbo dizendo “ransomware confirmado”.
Seria ótimo se o crime digital fosse tão educado.
O módulo procura alterações estatísticas e padrões anormais que, combinados, podem indicar atividade maliciosa.
Entre esses sinais estão:
mudanças abruptas na compressibilidade;
aumento da aleatoriedade dos dados;
alteração incomum do padrão de escrita;
crescimento repentino do volume de blocos modificados;
comportamento incompatível com a rotina histórica da carga.
É investigação por comportamento.
O suspeito não precisa deixar um bilhete dizendo:
“Olá, sou um ransomware. Favor não desligar a máquina.”
O sistema percebe que algo mudou.
5. Entropia: a impressão digital da criptografia
A palavra “entropia” parece pertencer a uma aula em que o professor escreve equações no quadro e metade da turma começa a planejar a fuga.
Mas a ideia básica é acessível.
Entropia, neste contexto, representa o grau de imprevisibilidade ou aleatoriedade dos dados.
Considere este conteúdo:
AAAAAAAAAAAAAAAAAAAAAAAAAAAA
É altamente previsível.
Comprime muito bem.
Agora veja:
7F9A2C81E4B6630D19AF82C7E520
É menos previsível.
Quando um arquivo é criptografado adequadamente, o resultado tende a parecer muito mais aleatório que o conteúdo original.
Um documento, uma planilha ou um banco de dados possuem estruturas reconhecíveis. Depois da criptografia, essas estruturas ficam escondidas.
Portanto, um aumento brusco na entropia de grandes volumes de dados pode ser um indicador de criptografia em massa.
Mas cuidado: alta entropia não prova, sozinha, a existência de ransomware.
Arquivos já comprimidos, vídeos, imagens, arquivos criptografados legitimamente e alguns bancos de dados também podem apresentar alta entropia.
A investigação precisa considerar o conjunto de evidências:
ALTA ENTROPIA
+
MUITOS BLOCOS ALTERADOS
+
PADRÃO INCOMUM DE ESCRITA
+
MUDANÇA ABRUPTA DE COMPORTAMENTO
=
POSSÍVEL INCIDENTE
Horatio retiraria os óculos e diria:
— Um bloco aleatório pode ser coincidência. Um milhão deles antes do amanhecer… já é um padrão.
6. Por que detectar rapidamente é tão importante?
Ransomware trabalha com velocidade.
Ele não envia um memorando dizendo:
“Informamos que iniciaremos a criptografia na próxima segunda-feira, às 9h, após o café.”
Quando consegue acesso, tenta causar o maior impacto possível antes que alguém perceba.
Imagine uma organização com centenas de terabytes e milhares de máquinas virtuais.
Se a detecção acontecer após muitas horas, o atacante pode ter:
Por isso, reduzir o tempo entre a atividade suspeita e o alerta é valioso.
Entretanto, existe uma distinção fundamental:
detecção não é o mesmo que contenção.
Um alerta rápido não paralisa automaticamente todo o ataque.
A organização ainda precisa de:
O hardware pode perceber o cheiro de fumaça.
Mas alguém ainda precisa saber onde está o extintor.
7. O erro clássico: acreditar que snapshot é sinônimo de proteção absoluta
Snapshot é uma tecnologia extremamente útil.
Ele registra um estado lógico dos dados em determinado momento, geralmente sem duplicar imediatamente toda a capacidade.
Em termos simples:
10:00 — ESTADO A
11:00 — ESTADO B
12:00 — ESTADO C
Se algo der errado às 12h15, talvez seja possível retornar ao estado das 12h.
Porém, existe um problema.
Snapshots convencionais são gerenciáveis.
Alguém autorizado pode criá-los.
E alguém autorizado pode removê-los.
O atacante moderno sabe disso.
Se ele comprometer uma credencial com privilégios elevados, pode tentar:
1. LOCALIZAR SNAPSHOTS
2. EXCLUIR SNAPSHOTS
3. DESABILITAR REPLICAÇÕES
4. CRIPTOGRAFAR PRODUÇÃO
5. EXIGIR RESGATE
O administrador, ao chegar pela manhã, encontra a produção criptografada e a prateleira de recuperação vazia.
É o equivalente digital ao criminoso que, antes de cometer o delito, desliga as câmeras e leva o gravador.
8. Safeguarded Copy: isolando a cena do crime
O Safeguarded Copy existe para criar cópias protegidas por políticas, com controles que dificultam sua alteração ou exclusão indevida.
A ideia central é separar a cópia protegida da administração operacional cotidiana.
Pense em três zonas:
[ PRODUÇÃO ]
|
v
[ CÓPIA PROTEGIDA ]
|
v
[ PROCESSO CONTROLADO DE RECUPERAÇÃO ]
O dado de produção continua atendendo aplicações.
A cópia protegida permanece sob regras específicas de retenção e acesso.
A recuperação não é simplesmente um clique impulsivo executado por qualquer usuário administrativo.
Isso reduz o risco de que uma credencial comprometida destrua simultaneamente a produção e todas as opções de retorno.
Mas precisamos evitar a linguagem mágica.
Nenhuma tecnologia deve ser interpretada como:
“Nem Deus, com senha de administrador, consegue apagar.”
A segurança depende de:
configuração correta;
políticas de retenção;
separação de funções;
proteção das credenciais;
autenticação forte;
controle de acesso;
procedimentos documentados;
integração com a estratégia de recuperação.
Uma ferramenta poderosa mal configurada pode virar apenas uma tela bonita no console.
No CSI, a evidência só é válida quando a cadeia de custódia foi preservada.
No Data Center, acontece a mesma coisa.
9. Cyber Vault: o laboratório onde os dados são interrogados
Ter uma cópia protegida é excelente.
Mas ainda falta responder:
“Essa cópia está limpa?”
Imagine que o atacante permaneceu silencioso na rede durante semanas.
Ele instalou ferramentas, modificou arquivos e criou persistência.
Depois, a empresa gerou cópias protegidas normalmente.
Agora existem várias cópias.
Algumas podem conter sinais da invasão.
Restaurar uma cópia contaminada pode reintroduzir o problema.
É aqui que entra o conceito de Cyber Vault.
O Cyber Vault é um ambiente controlado para recuperar, montar, examinar e validar dados antes de devolvê-los à produção.
Fluxo conceitual:
CÓPIA PROTEGIDA
|
v
AMBIENTE ISOLADO
|
v
ANÁLISE TÉCNICA
|
v
VALIDAÇÃO
|
v
RECUPERAÇÃO CONFIÁVEL
O vault pode participar de testes como:
verificação de consistência;
análise de malware;
inspeção de logs;
validação de bancos de dados;
teste de inicialização;
comparação com padrões históricos;
execução de aplicações em ambiente isolado.
É o equivalente ao laboratório forense.
A evidência não volta imediatamente para a rua.
Primeiro, é examinada sob luz fria por alguém usando luvas.
10. Backup, snapshot, cópia protegida e vault não são a mesma coisa
Essa confusão é frequente.
Vamos organizar.
Backup
É uma cópia dos dados criada para recuperação. Pode estar em disco, fita, nuvem ou outro meio.
Snapshot
É um ponto lógico no tempo, normalmente eficiente e rápido, muitas vezes dependente da mesma plataforma de storage.
Cópia protegida
É uma cópia com regras adicionais contra alteração ou exclusão, criada para resistir a ataques e erros administrativos.
Cyber Vault
É um processo ou ambiente isolado para validar e recuperar os dados com segurança.
A arquitetura madura usa camadas:
PRODUÇÃO
+
SNAPSHOTS OPERACIONAIS
+
CÓPIAS PROTEGIDAS
+
BACKUPS EXTERNOS
+
CÓPIAS OFFLINE OU ISOLADAS
+
CYBER VAULT
+
TESTES DE RECUPERAÇÃO
Segurança real raramente depende de uma única solução.
É como um programa COBOL crítico.
Você não confia apenas em um IF.
Você valida entrada, status de arquivo, SQLCODE, retorno de subprograma e condição final.
Ou pelo menos deveria.
11. FlashSystem.ai: o coadministrador que nunca pede férias
Uma storage moderna gera uma quantidade absurda de telemetria.
Ela observa:
latência;
IOPS;
throughput;
utilização de cache;
ocupação;
erros de portas;
caminhos;
filas;
temperatura;
compressão;
capacidade;
saúde dos módulos;
desempenho por volume;
tendências históricas.
Um administrador humano pode interpretar muitos desses dados.
Mas não consegue observar tudo, o tempo inteiro, em centenas de sistemas.
A proposta do FlashSystem.ai e das funções de IA operacional é transformar telemetria em orientação, recomendação e, em alguns casos, automação.
O fluxo é semelhante a:
COLETAR MÉTRICAS
|
v
CORRELACIONAR EVENTOS
|
v
IDENTIFICAR ANOMALIAS
|
v
SUGERIR OU EXECUTAR AÇÃO
|
v
REGISTRAR RESULTADO
Exemplos de valor operacional incluem:
identificar tendência de saturação;
perceber degradação gradual;
correlacionar falhas de caminho;
recomendar redistribuição;
destacar riscos de capacidade;
reduzir tempo gasto em diagnóstico básico.
Mas o termo “Agentic AI” precisa ser lido com maturidade.
Não significa necessariamente que a storage ganhou consciência, escolheu um nome e começou a enviar currículo para vagas de administrador sênior.
Significa que funções de automação podem utilizar contexto, telemetria, recomendações e fluxos orientados por objetivos.
A autonomia real varia conforme o produto, a função, a política e as permissões.
Sempre pergunte:
o que o agente apenas recomenda?
o que ele pode executar?
existe aprovação humana?
há auditoria?
é possível desfazer?
quais credenciais ele utiliza?
o que acontece quando o modelo erra?
IA sem governança é apenas um estagiário extremamente rápido com acesso administrativo.
12. Conhecendo os suspeitos: FlashSystem 5600, 7600 e 9600
A imagem apresentada mostra três integrantes da família FlashSystem.
Eles compartilham conceitos e recursos, mas atendem escalas diferentes.
IBM FlashSystem 5600
O FlashSystem 5600 ocupa um espaço compacto e pode ser adequado para:
Seu formato compacto não significa ausência de recursos empresariais.
É como aquele perito silencioso no canto da sala que parece discreto, mas encontra uma fibra de tecido capaz de resolver o caso inteiro.
Ele pode ser usado em projetos nos quais espaço, consumo e densidade importam.
Imagine uma indústria com várias unidades regionais.
Cada unidade executa sistemas locais, máquinas virtuais e coleta de dados de produção.
O 5600 pode cumprir o papel de plataforma compacta, mantendo recursos de proteção e integração corporativa.
IBM FlashSystem 7600
O 7600 ocupa uma posição intermediária, voltada a cargas corporativas amplas.
Pode atender:
É o investigador veterano.
Não precisa derrubar a porta.
Ele já sabe onde procurar.
Em muitas organizações, o modelo intermediário representa o equilíbrio entre capacidade, desempenho, expansão e custo.
Um banco regional, por exemplo, poderia consolidar:
Tudo isso mantendo políticas de proteção e recuperação.
IBM FlashSystem 9600
O FlashSystem 9600 é direcionado a grandes ambientes empresariais e cargas intensivas.
Entre os cenários possíveis:
É o chefe da unidade.
Entra na sala, observa seis petabytes, milhões de IOPS e uma equipe em pânico.
Depois pergunta:
— Quem alterou a política de retenção?
O 9600 é projetado para ambientes nos quais desempenho, escalabilidade e continuidade são requisitos centrais, não acessórios.
A presença de processadores potentes nos controladores ajuda a sustentar serviços como virtualização, compressão, replicação, gerenciamento e funções avançadas de dados.
13. IOPS: o número que todo vendedor adora e todo arquiteto deve interrogar
IOPS significa Input/Output Operations Per Second.
Ou operações de entrada e saída por segundo.
Quanto maior o número, mais operações o sistema pode realizar em determinada condição.
Mas IOPS isolado não conta a história inteira.
O resultado depende de:
Uma storage pode alcançar milhões de IOPS em um teste específico e entregar muito menos em uma carga real com blocos grandes, escrita intensa e replicação síncrona.
É como dizer:
“Este programa COBOL processa dez milhões de registros.”
Ótimo.
Mas em quanto tempo?
Com qual arquivo?
Usando qual índice?
Executando quais cálculos?
Com quantos acessos Db2?
Sob qual concorrência?
A pergunta correta não é:
“Quantos IOPS aparecem no folheto?”
A pergunta correta é:
“Qual desempenho teremos com a nossa carga, nossa latência, nossa proteção e nosso padrão de crescimento?”
CSI não condena alguém apenas porque ele estava no bairro.
Infraestrutura não deveria comprar storage apenas porque o gráfico do fornecedor tinha a barra mais comprida.
14. A provocação contra Pure, Dell, NetApp e VAST
O texto original utiliza uma estratégia comum em marketing competitivo: simplificar o rival e destacar o diferencial próprio.
Pure Storage, Dell, NetApp e VAST não são fabricantes amadores esperando o primeiro ransomware da história.
Todos possuem mecanismos de proteção, snapshots, replicação, análise, integração e recursos de resiliência.
A diferença está na arquitetura, implementação, profundidade, integração e operação.
Pure Storage
A Pure é conhecida por simplicidade operacional, desempenho e experiência de gerenciamento.
Seus mecanismos de proteção não podem ser resumidos como “um software lento que avisa tarde demais”.
Essa caricatura é boa para uma postagem provocativa, mas ruim para uma análise técnica.
A pergunta correta é:
Dell
A Dell possui uma ampla família de produtos, incluindo arquiteturas voltadas a diferentes níveis empresariais.
Também oferece tecnologias de cyber recovery, snapshots protegidos, replicação e integração com ecossistemas de backup.
Dizer que a Dell depende apenas de “sorte em software” seria injusto.
Porém, a IBM pode destacar como diferencial a inteligência embutida nos módulos FlashCore e a integração com sua plataforma.
NetApp
A NetApp possui longa experiência com snapshots, proteção de dados, replicação e políticas de imutabilidade.
O risco de um administrador comprometido é real em qualquer plataforma.
Por isso, a discussão deve envolver:
separação de funções;
autenticação multifator;
retenção;
WORM;
contas de emergência;
auditoria;
proteção de políticas;
isolamento.
O problema não é apenas “o snapshot da marca X pode ser apagado”.
O problema é:
“Quem pode apagar, em quais condições, com qual auditoria e com qual possibilidade de recuperação?”
VAST Data
A VAST ganhou espaço em grandes ambientes de dados, inteligência artificial e análise em escala.
A crítica sobre necessidade de administração manual deve ser verificada em cada cenário.
Cargas de IA realmente podem exigir planejamento cuidadoso de desempenho, rede, capacidade e recuperação.
Mas isso vale para praticamente qualquer infraestrutura de grande porte.
Não existe storage mágico.
Existe arquitetura bem dimensionada ou orçamento queimando lentamente diante de uma apresentação em PowerPoint.
15. Passo a passo: como pensar uma estratégia de cyber resilience
Agora vamos sair da cena do crime e montar uma defesa.
Passo 1 — Classifique os dados
Descubra o que é realmente crítico.
Pergunte:
quais sistemas não podem parar?
quais dados possuem obrigação regulatória?
quais aplicações precisam voltar primeiro?
qual perda de dados é aceitável?
quanto tempo de interrupção é tolerável?
Isso leva aos conceitos de RPO e RTO.
RPO
Quanto dado a empresa aceita perder.
Exemplo:
RPO = 15 minutos
Significa que, em uma recuperação, pode haver perda de até 15 minutos de alterações.
RTO
Quanto tempo a empresa aceita ficar indisponível.
Exemplo:
RTO = 2 horas
O sistema precisa retornar em até duas horas.
Passo 2 — Mapeie todas as cópias
Liste:
snapshots;
backups;
replicações;
fitas;
nuvem;
cópias externas;
cópias isoladas;
ambientes de vault.
Muitas empresas descobrem durante a crise que “backup” era apenas um snapshot no mesmo equipamento.
Isso não é diversidade.
É colocar a chave reserva dentro do carro trancado.
Passo 3 — Proteja as credenciais
Implemente:
A melhor cópia imutável do mundo pode ser enfraquecida por uma política administrativa desastrosa.
Passo 4 — Configure retenção protegida
Defina:
frequência;
duração;
quantidade de pontos;
políticas por aplicação;
responsáveis;
processo de restauração.
Um sistema financeiro pode exigir cópias mais frequentes que um repositório de documentos históricos.
Passo 5 — Crie um ambiente de validação
Não restaure dados desconhecidos diretamente em produção.
Utilize um ambiente isolado para:
montar volumes;
validar bancos;
executar antivírus;
inspecionar logs;
testar aplicações;
verificar integridade.
Passo 6 — Integre os alertas
Um alerta preso no console da storage não ajuda muito se ninguém olha o console.
Integre com:
SIEM;
central de operações;
sistemas de chamados;
e-mail corporativo;
mensageria;
automação de resposta.
Passo 7 — Teste a recuperação
Executar backup não prova capacidade de recuperação.
O único teste real é restaurar.
Crie exercícios periódicos:
SELECIONAR CÓPIA
|
v
RESTAURAR
|
v
VALIDAR BANCO
|
v
SUBIR APLICAÇÃO
|
v
MEDIR TEMPO
|
v
DOCUMENTAR PROBLEMAS
Backup não testado é fé.
E fé, embora respeitável em muitos contextos, não substitui evidência em uma sala de crise.
16. O que o programador COBOL precisa saber
Você talvez esteja pensando:
“Mas eu programo COBOL. Quem cuida da storage é outra equipe.”
Essa separação é perigosa.
O programador precisa entender pelo menos:
onde seus arquivos são armazenados;
qual aplicação depende de qual volume;
como funciona o backup;
se existe consistência transacional;
como Db2, CICS ou VSAM serão recuperados;
qual é a ordem correta de inicialização;
como validar os dados restaurados;
quais arquivos temporários não precisam ser protegidos;
quais logs são indispensáveis.
Recuperar bytes não é o mesmo que recuperar uma aplicação.
Imagine restaurar:
o VSAM das contas às 10h;
o log de transações às 11h;
a tabela Db2 às 9h;
o arquivo de controle às 12h.
Cada componente pode estar íntegro isoladamente.
Mas o sistema completo pode ficar inconsistente.
É como reunir quatro depoimentos verdadeiros sobre horários diferentes e tentar construir um único álibi.
Por isso, a recuperação deve considerar dependência e consistência.
17. Easter eggs forenses do Data Center
Toda investigação Bellacosa merece algumas curiosidades escondidas.
Easter egg 1 — O arquivo que nunca deveria ser apagado
Em muitos ambientes existe um arquivo chamado algo semelhante a:
NAO-APAGAR
Naturalmente, ele é o primeiro a ser apagado.
O nome do arquivo não é um mecanismo de segurança.
Easter egg 2 — A senha do storage
Se a senha administrativa contém o nome da empresa e o ano atual, o criminoso não precisará de inteligência artificial.
Precisará apenas de calendário.
Easter egg 3 — O backup bem-sucedido
Muitos relatórios mostram:
BACKUP COMPLETED SUCCESSFULLY
Isso significa apenas que o processo acredita ter copiado alguma coisa.
Não significa que:
Easter egg 4 — O volume TEMP
Algum desenvolvedor grava dados críticos em um volume chamado TEMP.
Isso é uma lei não documentada da computação.
Easter egg 5 — O administrador aposentado
A conta de um administrador que saiu da empresa em 2019 continua ativa.
Ela possui acesso total.
A senha nunca expirou.
Quando o incidente acontece, todos perguntam:
— Quem é Carlos?
Ninguém sabe.
Carlos, entretanto, ainda pode apagar a produção.
18. A verdade final sobre “segurança no silício”
Colocar inteligência no hardware é uma vantagem arquitetural relevante.
Permite observar operações em um ponto extremamente próximo dos dados.
Pode reduzir latência de detecção.
Pode fornecer telemetria difícil de obter em outras camadas.
Mas não substitui segurança completa.
O ataque pode começar em:
phishing;
Active Directory;
credenciais vazadas;
VPN;
aplicação;
hipervisor;
endpoint;
fornecedor terceirizado;
script administrativo;
pipeline DevOps.
O FlashCore Module não impedirá um usuário autorizado de enviar voluntariamente dados sigilosos para um criminoso.
Também não corrigirá:
ausência de MFA;
rede plana;
backup mal configurado;
falta de documentação;
equipe sem treinamento;
sistemas abandonados;
patches atrasados;
processos inexistentes.
Segurança em camadas continua indispensável:
USUÁRIO
|
IDENTIDADE
|
REDE
|
SERVIDOR
|
APLICAÇÃO
|
BANCO DE DADOS
|
STORAGE
|
BACKUP
|
CYBER VAULT
Cada camada ajuda a compensar a falha de outra.
Conclusão: a evidência estava nos blocos
Ao final do episódio, o ransomware foi detectado.
Os hosts comprometidos foram isolados.
As credenciais foram bloqueadas.
Uma cópia protegida foi levada ao Cyber Vault.
Os bancos de dados foram validados.
As aplicações retornaram.
A diretoria convocou uma reunião para descobrir por que uma conta genérica ainda possuía acesso administrativo.
A equipe de segurança apresentou um relatório de cento e oitenta páginas.
A gerência pediu um resumo em um slide.
O programador COBOL tomou o último gole de café e percebeu que o storage moderno deixou de ser apenas o lugar onde os dados dormem.
Ele agora observa.
Compara.
Registra.
Protege.
E, em alguns casos, ajuda a descobrir que o comportamento dos dados mudou antes que o restante da organização perceba a invasão.
O IBM FlashSystem combina controladores, FlashCore Modules, telemetria, recursos de proteção, Safeguarded Copy, Cyber Vault e automação operacional para construir uma estratégia de resiliência.
Os modelos 5600, 7600 e 9600 atendem escalas diferentes, desde ambientes compactos até grandes infraestruturas empresariais.
O diferencial mais interessante não está apenas nos milhões de IOPS, na capacidade ou no número de núcleos.
Está na ideia de colocar parte da investigação perto do próprio dado.
Porque, quando a casa digital pega fogo, não basta saber que existe fumaça.
É preciso descobrir:
onde começou;
quanto foi atingido;
quais evidências sobreviveram;
qual cópia ainda é confiável;
e quanto tempo a empresa levará para voltar à produção.
O chefe da perícia observa o rack pela última vez.
Coloca os óculos escuros.
E sentencia:
— O criminoso achou que estava apagando o passado…
Pausa dramática.
— Mas o passado estava salvaguardado.
Entra o grito da abertura.
E, em algum lugar do Data Center, um programa COBOL continua processando o fechamento noturno como se absolutamente nada tivesse acontecido.
