Cuca Fresca IT

No artigo anterior sobre Data Protection, falamos sobre o Veeam Hardened Repository. Abordamos como os modelos DIY e JeOS entregam imutabilidade na camada do kernel utilizando servidores físicos convencionais e a formatação XFS. Essa abordagem resolve a integridade e protege o dado contra comandos maliciosos de exclusão.

A infraestrutura de proteção de dados, no entanto, avança em degraus de especialização. A evolução direta a transição para um Appliance de Backup e Deduplicação. Diferente de um servidor “convencional” adaptado por meio de instalação de software, essas plataformas são projetadas desde o dia zero para um propósito único. A fabricante entrega uma solução onde o chassi, as controladoras de armazenamento e o sistema operacional totalmente customizado são compilados em conjunto para suportar exclusivamente o alto volume de I/O e o processamento de algoritmos de retenção. O hardware deixa de ser um hospedeiro passivo e torna-se um componente ativo no processamento do backup.

Dell Data Domain e a Deduplicação Inline

O padrão estabelecido no mercado corporativo para appliances de propósito específico é a tecnologia de deduplicação inline, fundamentada na arquitetura do Dell Data Domain. O resultado primário deste modelo é a alta eficiência de armazenamento. 

Para integrar a camada de armazenamento ao Veeam Backup & Replication, a arquitetura exige a alocação de um servidor intermediário para assumir a função de Gateway Server. Este componente atua como o motor de dados (Data Mover) responsável pela comunicação com o apliance, operando o protocolo DD Boost em conjunto com a funcionalidade Distributed Segment Processing (DSP). A mecânica do DSP desloca o custo computacional da deduplicação da controladora do Data Domain para a CPU do Gateway Server. Na operação diária, o servidor recebe o fluxo de dados do proxy, calcula a assinatura dos blocos na própria memória, valida essas assinaturas contra o índice do Data Domain e trafega pela rede estritamente os segmentos confirmados como novos.

Devido à forma como as bibliotecas proprietárias do DD Boost se integram ao motor da Veeam, a alocação dessa função precisa ser feita em cima do Windows, sejam elas provisionadas em hardware físico ou alocadas como máquinas virtuais (VMs) no ambiente. 

Além do provisionamento de recursos para o Gateway, a busca pela eficiência de compactação precisa de ajustes na configuração das rotinas de backup. Como por exemplo, ajustar o tamanho do data block size para 4MB e desativar a deduplicação nativa do Veeam, garantindo que não haja conflito de algoritmos. Como o protocolo DD Boost assume a responsabilidade primária de compactar os arquivos, a utilização da compressão nativa do Veeam no nível Optimal introduz uma redundância operacional. O uso de compressão na origem é tecnicamente justificável apenas em topologias que não possuem uma rede dedicada (composta por placas de rede e switches exclusivos para backup), onde a mitigação do tráfego na LAN de produção é mandatória. Nesses cenários, o proxy comprime a carga para otimizar o transporte. Entretanto, para garantir a eficiência dos algoritmos do Data Domain, a arquitetura exige a ativação da funcionalidade de descompressão prévia no repositório. O Gateway Server recebe os dados pela rede, descompacta os blocos na própria memória e depois os submete ao Data Domain. Em ambientes com redes de backup fisicamente isoladas, a recomendação é utilizar as opções None ou Dedup Friendly, delegando a carga de otimização integralmente para o appliance.

Somado a isso, devido à mecânica de ponteiros lógicos para a remontagem de arquivos, a arquitetura possui um limite estrito para o número de pontos de restauração incrementais consecutivos (120 pontos). A operação impõe o agendamento de backups Synthetic Full) ou Active Full periódicos para manter a integridade da cadeia lógica e da base de dados do storage.

O método de compactação também define o comportamento da plataforma durante a fase de leitura. Ao solicitar a recuperação integral de um servidor ou a execução de um Instant VM Recovery, o Data Domain inicia o processo de reidratação. O equipamento precisa localizar, extrair e remontar os blocos distribuídos em múltiplos discos físicos para reconstruir o arquivo original. Essa operação demanda ciclos de processamento do appliance em tempo real. A arquitetura prioriza a máxima otimização de espaço, resultando em um perfil de I/O de leitura específico que deve ser contabilizado durante a elaboração do RTO.

Imutabilidade e Conformidade

Na camada de proteção contra exclusões e ataques lógicos (ransomware), a plataforma opera com o Data Domain Retention Lock (DD RL), estabelecendo uma distinção em relação aos repositórios Linux imutáveis (VHR). Enquanto no VHR a imutabilidade reside em uma flag do sistema de arquivos que pode ser revertida ou destruída por um usuário com privilégios de root (permitindo a formatação do volume via sistema operacional ou a quebra do RAID). Uma vez que o dado é travado sob a flag de Compliance, o bloqueio torna-se irrevogável. A conta de administração máxima (sysadmin) perde a autoridade para excluir os arquivos, diminuir o tempo de retenção ou destruir a estrutura lógica (MTree) antes da expiração. A rigidez dessa arquitetura estende-se à formatação global do equipamento. O sistema bloqueia ativamente a execução do comando de destruição do sistema de arquivos (filesys destroy) enquanto houver blocos retidos.

Esse nível de bloqueio absoluto não é uma escolha arbitrária de design, mas uma exigência concebida para certificar o hardware em auditorias globais. O modo Compliance foi projetado para cumprir regulamentações federais e financeiras estritas, entregando conformidade técnica atestada com a SEC 17a-4(f) e CFTC Rule 1.31b para o mercado de capitais, FDA 21 CFR Part 11 para a indústria de saúde e farmacêutica, além do Sarbanes-Oxley Act (SOX), normativas da IRS (98025 e 97-22) e diretrizes internacionais como ISO 15489-1 e MoREQ2010.

É exatamente este lastro regulatório que proíbe legal e tecnicamente a existência de utilitários de evasão. A documentação do Data Domain estabelece que o suporte técnico da fabricante não detém ferramentas de baixo nível ou chaves mestras para contornar o estado de conformidade. O sistema utiliza um relógio interno isolado e auditado (Compliance Clock) para mitigar alterações de data, garantindo que a única via para a liberação dos dados armazenados no repositório seja o cumprimento integral do tempo estipulado na política de backup.

ExaGrid e a Arquitetura de Landing Zone

A ExaGrid implementou uma topologia dividida em duas camadas lógicas. O appliance reserva uma área frontal de discos, denominada Landing Zone, desenhada para receber a gravação na sua taxa de transferência máxima e no formato nativo do Veeam. A deduplicação e a compactação não ocorrem no momento da ingestão. Os arquivos VBK e VIB são gravados inteiros e apenas posteriormente são copiados para a camada interna de deduplicação, denominada Repository Tier. 

O appliance possui o Veeam Data Mover integrado nativamente ao seu próprio sistema operacional. O equipamento atua simultaneamente como alvo de armazenamento e motor de dados, comunicando-se de forma direta com os servidores proxy da infraestrutura. 

Ao contrário da exigência de desativação de recursos no modelo inline, a presença do Data Mover no appliance permite manter a compressão e a deduplicação nativas do Veeam ativadas nas rotinas de backup. Essa configuração otimiza o tráfego de rede durante a transferência entre o proxy e o appliance, reduzindo a saturação da LAN e acelerando a taxa de ingestão. O dado chega otimizado e é alocado na Landing Zone, sendo submetido ao algoritmo de compactação global do hardware apenas durante a movimentação assíncrona para o Repository Tier.

A sinergia entre o sistema operacional do ExaGrid e o motor da Veeam aprofunda-se na camada do sistema de arquivos. A Landing Zone opera nativamente sobre a formatação XFS. Isso com a integração entre  Data Movers, habilita o suporte integral à tecnologia Fast Clone (Block Cloning) da Veeam. O impacto operacional dessa integração é a aceleração na consolidação das cadeias de backup. A geração de um Synthetic Full deixa de ser uma operação física de leitura e gravação nos discos e passa a ser uma operação de metadados, baseada na criação de ponteiros lógicos. O processamento da cadeia ocorre em uma fração do tempo tradicional e extingue a necessidade técnica de agendar Active Full.

A principal implicação de manter os pontos de restauração mais recentes na área frontal ocorre durante a fase de leitura crítica. Ao acionar o Instant VM Recovery ou SureBackup, o Veeam monta os dados diretamente a partir da Landing Zone. Isso anula a necessidade de reidratação e não exige ciclos pesados de CPU para a remontagem de blocos fragmentados.

Air-Gap Lógico e Retention Time-Lock (RTL)

A engenharia de segurança dessa topologia fundamenta-se no isolamento estrito de comunicação. O Repository Tier não é roteável e não é exposto à rede do datacenter. Ele opera sob um modelo de air-gap lógico interno. A única via de comunicação com essa camada de retenção é o barramento interno do próprio hardware, que orquestra a movimentação dos blocos a partir da Landing Zone de forma “invisível” para o Repository Tier. Caso um atacante comprometa a rede primária, não existe um caminho de rede, protocolo de compartilhamento ou porta TCP/IP que permita o acesso direto ao histórico de longo prazo, limitando a superfície de ataque exclusivamente à área frontal do storage.

Na camada de proteção contra exclusões lógicas, o sistema operacional do appliance implementa o Retention Time-Lock (RTL). Essa funcionalidade operacionaliza o isolamento interno através de uma mecânica de exclusão atrasada (delayed delete), que se diferencia da imutabilidade. Se um invasor comprometer as credenciais do servidor Veeam e disparar um comando de exclusão em massa, a requisição atinge a interface do appliance e é processada com sucesso pela aplicação. Para o Veeam Backup & Replication, o dado foi efetivamente removido da console.

No entanto, o ExaGrid intercepta essa instrução e mantém os arquivos e blocos deduplicados intactos e protegidos na Landing Zone e no Repository Tier pelo período estipulado na política de proteção. Essa abordagem garante que, embora o backup desapareça da gerência lógica do Veeam, ele permaneça fisicamente disponível no appliance. Em um cenário de desastre, a equipe de TI pode reverter o estado do repositório através da interface de gerenciamento do appliance, tornando os dados visíveis novamente para o Veeam.

O appliance eleva essa defesa atuando de forma proativa através da detecção de anomalias (Auto Detect & Guard). O ExaGrid monitora continuamente o padrão diário de exclusões operacionais e o comportamento da gravação. Se o sistema detectar um volume de requisições de deleção que fuja da linha de base histórica, o que caracteriza o sintoma de um ataque destrutivo, a inteligência do appliance suspende a política de expiração padrão e estende automaticamente o bloqueio temporal. Isso impede que a limpeza física dos blocos ocorra até que a equipe de segurança valide a operação.

A garantia de que essa mecânica não seja sabotada pelo próprio atacante fundamenta-se na arquitetura de Controle de Acesso Baseado em Funções (RBAC). A plataforma anula o conceito de um usuário com privilégio absoluto. O perfil de Backup Administrator gerencia a operação diária, porém a interface bloqueia sumariamente qualquer tentativa desse usuário de diminuir os dias do RTL. Para modificar a postura de defesa, a arquitetura exige a aprovação de uma conta segregada com a função de Security Officer. Esse desenho força um modelo de aprovação de múltiplas camadas, exigindo que o invasor comprometa simultaneamente a conta de administração e a conta de segurança corporativa, ambas protegidas por Duplo Fator de Autenticação (2FA).

Ciclo de Vida, TCO e o Modelo de Suporte Operacional

O ciclo de vida do hardware representa o ponto de ruptura financeiro das infraestruturas baseadas no modelo scale-up. A dinâmica tradicional do mercado impõe o provisionamento excessivo de capacidade no dia zero para evitar gargalos futuros, ou exige que, após um ciclo de três a cinco anos, o equipamento atinja o limite computacional. Esse cenário obriga a empresa a realizar o forklift upgrade, uma operação que consiste em comprar um chassi inteiramente novo, migrar os dados e descartar o equipamento antigo, destruindo o investimento inicial.

A ExaGrid mitiga essa dor alterando a mecânica de expansão para um modelo de crescimento sob demanda. Em vez de imobilizar capital em uma única caixa de 300TB no dia zero, prevendo o esgotamento do espaço apenas no sexto ano, é possível fracionar o investimento. O projeto inicia com uma caixa de 100TB e, ao longo dos anos, novos appliances são acoplados ao ambiente conforme a volumetria da operação exige. A arquitetura da plataforma permite adicionar caixas de idades, gerações e capacidades diferentes operando na mesma infraestrutura. A fabricante não descontinua o firmware de appliances legados A caixa antiga continua recebendo atualizações e processando a carga lado a lado com os modelos recentes. Essa abordagem, aliada a uma política de proteção de preço, garante a previsibilidade do TCO. A capacidade de armazenamento e o processamento apenas se somam com o tempo.

A praxe no mercado é submeter a equipe de TI  a um funil de atendimento. O cliente abre o chamado e precisa explicar o cenário para um analista de nível 1 operando um script básico de triagem, perdendo horas até a escalada para a engenharia de nível 3. A ExaGrid elimina essa esteira alocando um engenheiro de suporte sênior dedicado exclusivamente à conta. A organização adquire um ponto de contato técnico fixo e familiarizado com a topologia específica do seu datacenter. Esse modelo anula a necessidade de reexplicar o desenho da rede, as políticas de retenção ou as peculiaridades do ambiente a cada incidente. Adicionalmente, o engenheiro alocado domina nativamente a mecânica do Veeam Backup & Replication. Quando ocorre uma falha na integração, não existe o jogo de empurra entre o suporte do hardware e o software. A comunicação flui de forma direta entre engenheiros seniores, o que comprime o tempo de diagnóstico e resolve gargalos operacionais antes que impactem a janela de proteção do negócio.

Resumo e a Dinâmica de Replicação

Antes de detalhar os prós e contras de cada plataforma, é necessário consolidar como elas operam e se comunicam em topologias multisite.

Na essência lógica, o Data Domain concentra sua engenharia na compactação do dado no exato momento da entrada, reduzindo o consumo de discos primários ao custo de exigir processamento na fase de leitura. O ExaGrid aloca o dado em formato nativo na entrada para acelerar a leitura e delega a compactação e deduplicação  para o segundo plano.

Em projetos que exigem contingência geográfica, ambos os equipamentos realizam a cópia dos backups para caixas secundárias de forma nativa. Essa transferência ocorre diretamente entre os appliances. O detalhe dessa arquitetura é que a replicação ocorre na camada do storage e não é gerenciada pelo Veeam Backup & Replication. Se um atacante assumir o controle do servidor de backup primário, ele enxergará apenas o repositório primário. Como o equipamento secundário não está mapeado na console, ele fica isolado contra comandos de exclusão em massa ou ações destrutivas originadas do ambiente comprometido, funcionando como uma camada silenciosa de proteção.

Dell Data Domain

Prós

• Densidade de Retenção Pura: A topologia baseada integralmente em deduplicação inline otimiza a ocupação bruta de rack no dia zero. Como não exige uma área de discos reservada para arquivos não compactados, 100% do volume físico de armazenamento é dedicado ao acervo deduplicado, minimizando o custo inicial com discos para ambientes que exigem retenção de longo prazo.
• Imutabilidade: A funcionalidade Retention Lock Compliance opera no nível do kernel do sistema operacional. O bloqueio WORM é absoluto e atende a regulamentações estritas de auditoria financeira e governamental (SEC 17a-4(f), CFTC Rule 1.31b, FDA 21 CFR Part 11 e SOX). A arquitetura anula o acesso irrestrito, garantindo que nem mesmo a conta de administração máxima consiga destruir a estrutura lógica ou apagar o volume antes do fim da retenção.
• Criptografia Proprietária: Embora a Veeam ofereça criptografia de rede nativa, o diferencial da integração com o Data Domain reside no encapsulamento proprietário do DD Boost. Essa característica cria uma segregação tecnológica na proteção do dado em movimento. O protocolo assume a blindagem do tráfego entre o Gateway Server e o appliance de forma autônoma e com protocolos privados. Em um cenário de ataque onde o invasor consiga mapear ou comprometer a camada de transporte padrão do software de backup, a interceptação física na rede esbarra em um túnel criptografado exclusivo do Data Domain.

Contras

• Incompatibilidade com Fast Clone e Carga na Origem: Por utilizar o sistema de arquivos DDFS, a plataforma não é compatível com o Fast Clone (Block Cloning) da Veeam. A criação de backups sintéticos ocorre via protocolo DD Boost através da manipulação de ponteiros lógicos. O efeito prático dessa mecânica é o aumento da fragmentação interna dos dados, o que reduz a velocidade de leitura do appliance com o passar do tempo. Para manter o desempenho estável, a recomendação do fabricante é agendar backups Active Fulls periodicamente. Essa prática transfere o peso da operação para o ambiente produtivo: os proxies da Veeam precisam ler todo o volume de dados e enviar novamente pela rede. O resultado é a extensão da janela de backup e o aumento da concorrência de I/O no armazenamento primário.
• Dependência do Gateway Server: Para o motor do Veeam processar o protocolo DD Boost, a arquitetura exige a alocação de servidores intermediários executando Microsoft Windows no caminho dos dados. O impacto dessa exigência vai além do provisionamento da máquina e atinge a esteira de manutenção do sistema operacional. Cada gateway adicionado embute custos de licenciamento e insere um novo ativo na rotina da equipe de infraestrutura. O servidor entra na janela de aplicação de patches, precisa ser integrado ao monitoramento e exige a implantação de agentes de segurança corporativa, como antivírus, EDR ou XDR. Um componente que atua apenas como repassador de blocos passa a demandar administração e proteção contínuas.
• Ciclo de Vida e Renovação de Hardware: A arquitetura scale up segue a política padrão do mercado de armazenamento de descontinuar o suporte ao equipamento após um ciclo pré-determinado de anos. Quando o appliance atinge o seu limite de processamento ou o fabricante decreta o fim da vida útil do chassi, a organização precisa realizar a substituição completa do hardware. Embora seja o modelo de negócio consolidado na indústria de TI, na prática isso exige a recompra de um equipamento inteiramente novo e a migração de todo o acervo de dados. Quando colocado em perspectiva com topologias que permitem a coexistência de caixas de gerações diferentes, esse formato impõe um custo de transição e um esforço de engenharia muito mais altos no longo prazo.

ExaGrid

Prós

• RTO Direto do Hardware: A arquitetura inverte a lógica tradicional ao não processar a deduplicação na entrada. Os backups mais recentes são gravados em formato nativo na área de Landing Zone. Essa mecânica elimina a necessidade de reidratação de blocos, entregando performance de leitura equivalente a um disco primário. Torna viável o uso constante de recursos como Instant VM Recovery e SureBackup para cargas pesadas sem estourar o tempo de recuperação (RTO).
• Integração Nativa e Fast Clone: O appliance roda o Veeam Data Mover de forma nativa no seu próprio sistema operacional. Isso extingue a necessidade de servidores Windows atuando como Gateway, removendo o custo de licenciamento e a carga administrativa de manter um sistema operacional extra na esteira. Além disso, a formatação interna suporta a tecnologia Fast Clone (XFS), permitindo a criação de backups sintéticos em frações do tempo, sem fragmentação excessiva e sem gerar I/O na rede de produção.
• Ciclo de Vida Estendido: A política da fabricante permite integrar caixas de diferentes gerações e capacidades no mesmo ambiente de forma contínua. Isso anula a necessidade de forklift upgrades e migrações de dados forçadas por obsolescência, preservando o investimento inicial da infraestrutura ao longo dos anos.
• Modelo de Suporte Fixo: A estrutura de atendimento aloca um engenheiro sênior dedicado de forma permanente à conta. O profissional possui domínio tanto do hardware quanto do motor da Veeam e conhece a topologia específica do ambiente. Isso elimina o funil de triagem de chamados de nível 1 e reduz o tempo de diagnóstico em incidentes complexos que envolvem a comunicação entre o software e o appliance.

Contras

• Ausência de granularidade na Landing Zone: A arquitetura não oferece opções para o administrador definir regras granulares de retenção na área de entrada. Não é possível configurar o appliance para priorizar ou fixar os pontos de restauração de um servidor crítico específico na Landing Zone em detrimento de outros. A disponibilidade dos dados recentes em formato não comprimido para operações de Instant VM Recovery é garantida de forma global pelo processo de dimensionamento (sizing) realizado pela fabricante na fase de projeto. Caso o ambiente de produção apresente um crescimento atípico de volumetria que fuja do escopo arquitetado, o rebaixamento dos blocos para o Repository Tier ocorrerá de forma sistêmica, visto que a equipe de TI não possui controles operacionais para proteger cargas de trabalho individuais desse nível.
• Recuperação Operacional em Duas Etapas: A funcionalidade de Retention Time-Lock (RTL) protege os dados ocultando os blocos contra exclusões, mas o comando de deleção disparado por um atacante é acatado e confirmado para o software de backup. Como resultado, os pontos de restauração desaparecem da console de gerência, pois o Veeam remove os registros do seu próprio banco de dados. Internamente, o ExaGrid identifica o volume atípico de deleção, emite um alerta de segurança e suspende o cronômetro de expiração padrão. Os dados ficam retidos e inacessíveis de forma indefinida até que a operação receba intervenção humana. Para restabelecer o ambiente, a equipe de TI precisa acessar o do Exagrid, validar o alerta, reverter o bloqueio dos arquivos e, obrigatoriamente, executar um processo manual de Rescan no repositório para forçar o Veeam a ler os metadados e importar o acervo de volta para a console.
• Incompatibilidade com WORM: O mecanismo de proteção do RTL opera sob um modelo de quórum. A exclusão de um dado protegido antes do fim da política pode ser forçada caso haja autorização dupla (como a aprovação conjunta do administrador de backup e do security officer). Ou seja, o bloqueio pode ser tecnicamente revogado por ação humana autorizada.

A Analogia: Construir a Aeronave vs. Comprar da Boeing ou Airbus

Vamos pensar na infraestrutura de proteção de dados como a operação de uma grande companhia aérea. A sua equipe de TI representa o corpo de profissionais capacitados da empresa, incluindo os mecânicos experientes, os estrategistas de rota e os pilotos de elite.

Optar pelo Veeam Hardened Repository é como decidir que esses mecânicos e engenheiros vão projetar e construir a própria aeronave do zero no hangar da empresa. O investimento financeiro inicial é menor e a equipe tem total liberdade para desenhar o avião como quiser. O grande desafio é que a responsabilidade pela integridade estrutural é inteiramente da casa. Se a equipe cometer um erro na solda da fuselagem, que no nosso mundo significa uma falha no hardware do Linux ou na aplicação de patches de segurança, o avião perde a pressurização e o desastre acontece. A organização economiza na aquisição, mas assume todo o fardo da engenharia de base.

Por outro lado, adotar appliances dedicados como Data Domain ou ExaGrid é o equivalente a assinar o cheque e comprar um modelo pronto de fabricantes consolidadas como Boeing ou Airbus. O custo de aquisição é muito mais alto e a equipe de TI precisa seguir estritamente o manual de manutenção e a matriz de compatibilidade da montadora. Em troca, a fabricante entrega uma máquina com engenharia validada, submetida a testes exaustivos e que já nasce em conformidade com os mais altos padrões de segurança mundiais. A responsabilidade por garantir que o sistema operacional de base não tenha vulnerabilidades estruturais é transferida da sua equipe para o fornecedor.

O ponto crucial dessa arquitetura é que comprar um Boeing ou Airbus não isenta a companhia aérea de ter regras de segurança rígidas e pilotos de excelência. O seu dado é o passageiro. A fabricante garante que o avião não vai cair por falha da turbina, mas se a equipe de TI configurar as permissões incorretamente, perder o controle das senhas ou deixar a porta da cabine de comando aberta para um atacante, o avião será sequestrado e a carga será perdida de qualquer forma. O appliance resolve o passivo do sistema operacional, mas a governança e isolamento lógico do acesso continuam sendo tarefas vitais e intransferíveis da sua operação.

O Cenário: Sobrevivendo à Escalada de Privilégios

Um grupo de ransomware infiltra a rede corporativa, escala privilégios e domina o servidor do Veeam Backup & Replication (VBR). O invasor desabilita o MFA, burla a autorização dupla (Four-Eyes Authorization) e, logado como Backup Administrator, dispara o comando de exclusão de todos os repositórios pela própria console da aplicação.

Até esse ponto, tanto o Hardened Repository em Linux quanto os appliances (Data Domain ou ExaGrid) respondem da mesma forma: a instrução de exclusão via software de backup é duramente rejeitada. A flag de imutabilidade segura o golpe inicial na camada da aplicação e o dado permanece intacto.

Com a porta da frente trancada, a progressão tática do atacante é contornar o Veeam e atacar o repositório diretamente pela rede corporativa, buscando acesso direto ao armazenamento. É exatamente nesta segunda fase do ataque que o servidor de propósito geral (Linux DIY) exibe a sua complexidade operacional e o appliance dedicado justifica o seu valor de projeto.

No cenário com o Veeam Hardened Repository, o invasor varre o IP do servidor em busca de vulnerabilidades no sistema operacional. Como o ambiente Linux permite a instalação de pacotes de terceiros, o atacante pode explorar uma falha crítica não corrigida em um agente de monitoramento (como um Zabbix ou um coletor de logs) ou tentar força bruta no serviço SSH, caso a equipe de TI não tenha executado o hardening com perfeição estrita. Se o invasor conseguir uma brecha para explorar um zero-day no kernel ou roubar uma credencial com permissão de sudo, o jogo acaba. Ele acessa o terminal, remove a proteção do sistema de arquivos com um simples comando nativo (chattr -i) e formata o volume XFS. O backup é destruído porque a camada base do sistema operacional era permeável.

Agora, projete a mesma movimentação lateral de ataque em um ambiente suportado por um ExaGrid ou Data Domain. O invasor realiza o escaneamento de portas no IP do equipamento. Ele não encontra um Linux genérico rodando agentes administrativos de terceiros, mas sim um sistema operacional proprietário e selado. Não existe acesso irrestrito ao shell aguardando uma conexão e não há como escalar privilégios para “root”, pois nem mesmo a equipe de TI da organização possui acesso à camada subjacente do kernel da máquina.

No caso do ExaGrid, a barreira é física e lógica. O atacante sequer consegue rotear pacotes para a camada onde o dado histórico está protegido. A zona de retenção (Repository Tier) não possui endereço IP acessível pela rede de produção. O invasor pode até enviar comandos de deleção utilizando as credenciais roubadas do Veeam, mas ele esbarra em um isolamento de rede quando tenta acessar o Retention Time-Lock. Para reverter o bloqueio dessa zona oculta, o sistema exige uma dupla aprovação (Quórum) envolvendo um papel de Segurança da Informação, ignorando os comandos do atacante.

No caso do Data Domain, operando com o Retention Lock em modo Compliance, a proteção atinge um nível regulatório inegociável. Se o atacante roubar a senha global do administrador do appliance e tentar formatar o equipamento, o próprio firmware do storage recusa o comando. A caixa é desenhada para ignorar privilégios administrativos caso o administrador tente remover a trava de tempo de um arquivo antes da data de vencimento.

Conclusão

Optar por um repositório desenhado dentro de casa prioriza a redução do CAPEX no dia zero. A economia na aquisição de hardware de mercado, no entanto, embute um OPEX contínuo e elevado. O Custo Total de Propriedade (TCO) cobra o seu preço na carga operacional contínua repassada para a equipe de TI e no risco assumido pela empresa ao manter a responsabilidade pelo isolamento de segurança do sistema operacional. Do outro lado, a adoção de appliances dedicados exige um CAPEX robusto, mas achata o OPEX operacional ao transferir a sustentação e a estabilidade da plataforma para o fabricante.

Dentro do ecossistema de soluções de prateleira, o Retorno sobre o Investimento (ROI) e o modelo de governança ditam a escolha. O Data Domain entrega extrema eficiência na redução de armazenamento, mas sua arquitetura de crescimento vertical pode forçar picos indesejados de CAPEX no futuro com a recompra de hardware obsoleto. No campo da segurança, sua proteção contra exclusões baseia-se em imutabilidade estrita. É um modelo desenhado para atender a rigorosos padrões de conformidade (compliance) e auditoria, entregando garantia absoluta contra alterações, mas impondo uma rigidez que impossibilita a liberação antecipada de espaço.

O ExaGrid, por sua vez, protege o ROI ao longo dos anos através da sua topologia de expansão modular, que dilui o CAPEX futuro e preserva o capital já investido. Sua filosofia de segurança foca em resiliência operacional. Em vez de um bloqueio inalterável, o appliance adota um modelo de retenção oculta e quórum de aprovação. Essa estratégia protege o acervo contra exclusões maliciosas e ataques cibernéticos, mas mantém a flexibilidade para que a gestão reverta o isolamento mediante a dupla autorização da liderança técnica e de segurança.

No fim do dia, a tecnologia escolhida precisa justificar a sua existência na planilha de custos corporativa. Contudo, é imperativo que a diretoria compreenda que o investimento no equipamento mitiga falhas estruturais, mas não compra isenção de responsabilidade. A governança, a segregação lógica de acessos e a auditoria rigorosa das credenciais continuam sendo necessários.

Reflexão

1. Se uma vulnerabilidade crítica for explorada hoje na camada do sistema operacional do seu repositório de backup, a sobrevivência dos dados depende da perfeição da sua equipe técnica em fechar essa brecha, ou essa superfície de ataque estrutural já foi eliminada pela adoção de um appliance com firmware proprietário e selado?
2. A arquitetura atual da sua proteção de dados força a empresa a realizar recompras integrais de hardware quando o limite vertical do chassi é atingido, ou o modelo adotado permite uma expansão modular que dilui o custo e preserva o investimento das gerações anteriores?
3. O hardware responsável pela proteção principal da empresa possui arquitetura nativa de isolamento lógico temporário (Retention Time-Lock) contra o vazamento de credenciais com privilégios de Backup Administrator?

No Próximo Artigo

No próximo artigo da série sobre Data Protection, vamos dissecar a engenharia do armazenamento de objetos e o protocolo S3. Abordaremos como a mecânica do Object Lock opera no nível da API para impedir a alteração de dados e como o desenho de repositórios baseados em nuvem ou provedores privados constrói a última linha de defesa para a retenção de longo prazo. Entenderemos como essa arquitetura garante a sobrevivência do acervo corporativo contra falhas catastróficas de site e corrupção profunda.

Fontes

Data Domain: Veeam Best Practices

Data Domain: Retention Lock

ExaGrid Tiered Backup Storage

Veeam Deduplication Appliance Best Practices