Cuca Fresca IT

A tecnologia avançou e a conta da segurança chegou junto. Há pouco mais de dez anos, o principal desafio operacional da TI era a exclusão acidental de diretórios por usuários por engano ou um script corromper uma tabela no banco de dados. Um backup salvo em um compartilhamento de rede comum resolvia o problema.

A dinâmica do ataque mudou. O objetivo deixou de ser apenas a corrupção de arquivos isolados e virou extorsão financeira através da indisponibilidade total da infraestrutura. O Ransomware escalou de um simples malware para uma indústria.

A execução do ataque ficou metódica. O invasor não entra criptografando a produção no primeiro minuto. Segundo relatórios de ameaças recentes, em 96% dos ataques de ransomware, o primeiro alvo é o repositório de backup. A progressão do invasor obedece a uma métrica clara: se a equipe de TI consegue restaurar o ambiente, a organização não paga o resgate. A primeira tarefa da ameaça após escalar privilégios é caçar o seu servidor de backup, mapear os volumes na rede e deletar os arquivos.

Por conta disso, desenhar um repositório imutável deixou de ser um diferencial e passou a ser o básico e imprescindível para garantir a continuidade do negócio. Se o seu disco de backup obedecer a um comando de exclusão disparado pela rede corporativa, na prática, você não tem backup. É exatamente aqui que a arquitetura do Linux Hardened Repository (LHR) entra na mesa. A proteção de acesso sai da camada da aplicação e desce para o nível do kernel do sistema operacional.

A Resposta da Veeam: Dois Caminhos para a Imutabilidade

Para resolver esse problema de proteção na camada de armazenamento, a Veeam não obriga a aquisição de um hardware proprietário. A estratégia da fabricante para entregar o Linux Hardened Repository (LHR) se adapta a diferentes modelos de operação, oferecendo duas rotas oficiais para atingir o mesmo nível de proteção:

1. A Rota Manual (Do It Yourself – DIY): A Veeam fornece a arquitetura de referência e os requisitos técnicos. A equipe de TI provisiona o servidor, instala uma distribuição Linux homologada (como Ubuntu ou Rocky Linux) e configura o ambiente seguindo as boas práticas de formatação e segurança. O controle absoluto do sistema operacional e do hardware permanece com a TI local.
2. A Rota Automatizada (A ISO / JeOS): A Veeam entrega uma mídia de instalação empacotada com o conceito de Just Enough Operating System (JeOS). O administrador faz o boot no servidor e o instalador automatiza o processo de particionamento, formatação e aplicação das políticas restritas de segurança de fábrica. O ciclo de vida do sistema operacional e a distribuição de patches passam a ser gerenciados pela própria Veeam.

Ambas as abordagens utilizam os recursos nativos do sistema de arquivos Linux para aplicar a trava nos dados. O resultado prático final é idêntico. Se um invasor comprometer a credencial administrativa da console do Veeam e enviar um comando de exclusão via rede, o kernel do servidor Linux vai negar a ação.

A diferença entre adotar o modelo DIY ou a ISO JeOS reside puramente na engenharia de implementação e no modelo de operação que a sua empresa prefere adotar para o longo prazo.

(Nota técnica: Este artigo foca especificamente no repositório imutável nativo baseado em Linux, o Veeam Hardened Repository. Sabemos que existem outras tecnologias robustas no mercado para garantir a imutabilidade dos backups, como Appliances de Desduplicação integrados via API e Object Storage nativo S3 com Object Lock. Nós vamos falar sobre essas arquiteturas de I/O e os trade-offs dessas outras topologias nos próximos artigos desta série).

Veeam Hardened Repository (VHR): DIY vs JeOS

A escolha de um Repositório Imutável exige analisar o fluxo de dados desde a controladora RAID física até o sistema de arquivos no Linux. A diferença entre montar o ambiente manualmente (DIY) e utilizar a mídia da Veeam (JeOS) reside na autonomia sobre o sistema operacional e no gerenciamento dos blocos de armazenamento.

A seguir, detalho o comportamento interno de cada abordagem e apresento os prós e contras operacionais na sustentação diária desses ambientes.

O Modelo Manual (DIY)

A adoção do modelo DIY transfere a responsabilidade da configuração do storage para a equipe de TI. O desenho da arquitetura separa o sistema operacional dos dados de backup logo no hardware. Na controladora, o administrador provisiona dois pools distintos. O primeiro é um array em RAID 1, utilizando dois discos de 500GB, dedicado exclusivamente para a instalação do SO. O segundo é um pool para o repositório, configurado em RAID 6 com 12 discos mecânicos, onde o administrador define o stripe size no padrão de mercado de 128KB.

No nível do sistema operacional, o disco lógico do RAID 1 recebe a instalação do Linux (como Rocky Linux ou Ubuntu) e suas partições nativas. O ajuste fino ocorre na formatação do array de dados. O objetivo é alinhar a estrutura do XFS com a topologia física do RAID 6. Com 12 discos no pool, a configuração resulta em 10 discos de dados e 2 de paridade. O administrador aplica os parâmetros exatos no utilitário mkfs.xfs, definindo o stripe unit (su) em 128k e o stripe width (sw) em 10, além de habilitar a flag de reflink. Esse alinhamento garante que as operações do Fast Clone ocorram de forma otimizada, prevenindo o problema de Read-Modify-Write na controladora durante as mesclagens de blocos.

Com o RAID e o XFS alinhados, a configuração avança para a camada de segurança do sistema operacional. O mecanismo que aplica a imutabilidade no arquivo de backup é o comando nativo chattr do Linux, que injeta a flag (+i) no dado. O ponto de atenção é que o chattr não garante a proteção sozinho. Se um invasor conseguir escalar privilégios no sistema (acessar o root), ele simplesmente remove a flag e apaga o repositório.

Para evitar esse cenário, o administrador precisa aplicar políticas de hardening no kernel e nos serviços do Linux. No modelo DIY, essa etapa começa no próprio assistente de instalação com a adoção de padrões como o FIPS e o DISA STIG. O FIPS (Federal Information Processing Standards) obriga o sistema a operar apenas com módulos de criptografia homologados, bloqueando o uso de algoritmos fracos nativos. O DISA STIG (Security Technical Implementation Guide) é o framework que dita as regras exatas de fechamento de portas, remoção de pacotes supérfluos, ajuste restrito de permissões e configuração de auditoria de logs.

A imutabilidade real do repositório é o resultado do chattr travando o bloco de dados no XFS somado às políticas STIG e FIPS protegendo o SO contra o escalonamento de privilégios. A principal característica do modelo DIY é o controle total sobre esse processo. Em distribuições como o Rocky Linux, o administrador consegue selecionar o profile STIG e ativar o modo FIPS direto na tela de setup inicial, antes do primeiro boot. Em outras distribuições, o processo de hardening é feito manualmente via terminal logo após a instalação.

Com o servidor instalado e o hardening inicial configurado, o repositório entra em produção. É na operação diária que a exigência do modelo DIY se mostra na prática. A responsabilidade contínua mais crítica herdada pela equipe de TI é a rotina de atualizações do Linux. Um kernel desatualizado ou uma biblioteca com vulnerabilidade exposta anula toda a arquitetura de segurança construída nos passos anteriores. 

Para otimizar essa rotina, o administrador possui ferramentas nativas para cada família de Linux. Em distribuições baseadas em Red Hat, utiliza-se o utilitário dnf-automatic. Em ambientes Debian ou Ubuntu, a função fica a cargo do pacote unattended-upgrades. O ajuste fino nos arquivos de configuração dessas ferramentas permite instruir o sistema a aplicar exclusivamente os patches classificados como de segurança de forma autônoma.

O risco técnico dessa automação precisa ser calculado. Habilitar qualquer nível de atualização automática em um cofre de backups carrega potencial de indisponibilidade. Mesmo um patch restrito de segurança pode conter uma regressão, gerar um kernel panic no próximo boot, quebrar a dependência de um serviço ou corromper a montagem do volume XFS. A automação reduz a exposição a ataques rapidamente, mas o administrador assume o risco de o servidor apresentar falhas no dia seguinte. Essa dinâmica confirma que a equipe de TI nunca fica isenta de monitorar a saúde do sistema de perto e planejar janelas de manutenção controladas.

A contrapartida de assumir essa carga administrativa é a flexibilidade de integração. Como o repositório DIY fornece acesso root, o servidor cumpre facilmente os requisitos de governança da empresa. A equipe de TI tem liberdade técnica para instalar os agentes exigidos pelas políticas de segurança. O administrador consegue embarcar soluções de resposta a incidentes, como agentes de XDR e EDR, além de ferramentas de telemetria, como o Zabbix, inserindo o repositório no stack de monitoramento padrão da organização.

O último ponto estrutural na análise do modelo DIY é a flexibilidade na expansão de armazenamento e o aproveitamento físico do servidor. Utilizando o nosso cenário base, o hardware consumiu 14 baias (2 para o SO e 12 para os dados). Se esse equipamento possuir um backplane para 24 discos, a operação tem 10 slots livres para o crescimento natural do ambiente.

Quando a volumetria de backup atingir o limite, a equipe adquire os 10 discos adicionais e os insere no servidor ligado. Na interface da controladora, o administrador cria um segundo array com os discos novos. A vantagem de possuir o controle do sistema operacional ocorre na camada do Logical Volume Manager (LVM). O novo disco virtual é mapeado no Linux, adicionado ao Volume Group (VG) de dados existente e o volume do repositório é estendido. Na sequência, o administrador redimensiona o sistema de arquivos XFS a quente. O repositório incorpora a nova capacidade de armazenamento sem a necessidade de reiniciar o sistema operacional ou interromper os jobs de backup em andamento, garantindo 100% de aproveitamento do hardware físico adquirido.

O Modelo Empacotado (JeOS)

A adoção da mídia JeOS transfere a configuração do repositório para o instalador da Veeam. A fundação de hardware exige uma atenção rigorosa de projeto: diferente do modelo DIY, onde o administrador tem liberdade para mapear LUNs via iSCSI ou Fibre Channel, a ISO do JeOS não suporta multipath ou conexões com storages externos. A arquitetura exige estritamente discos locais (“na barriga” do servidor) ou gavetas DAS conectadas direto na controladora. 

Seguindo o nosso cenário base, a equipe de infraestrutura provisiona no chassi local um array em RAID 1 com dois discos de 500GB para o sistema operacional e um RAID 6 com 12 discos mecânicos para os dados, mantendo o stripe size de 128KB.

O administrador inicia o servidor com a ISO da Veeam, construída sobre o Rocky Linux. O instalador assume a configuração da camada lógica. O sistema reconhece os discos virtuais apresentados pela controladora, monta a estrutura do LVM e formata o volume de dados em XFS com a flag de reflink ativada. O processo utiliza parâmetros homologados pela fabricante, abstraindo o cálculo manual de blocos exigido no modelo anterior.

O repositório funciona como um appliance fechado. A rotina executa o hardening automaticamente, aplicando as políticas do DISA STIG, ajustando as permissões do kernel e habilitando o suporte ao comando chattr. A principal característica desse modelo é o bloqueio do sistema operacional. Após a configuração inicial, a ISO desabilita a credencial de root e encerra o serviço SSH. 

Esse bloqueio altera a rotina de sustentação. A equipe de TI deixa de gerenciar as atualizações e correções de segurança do Linux de forma autônoma. A Veeam assume a homologação dos pacotes, e a aplicação das correções, ou seja, temos o cenário de “Responsabilidade Compartilhada”. Essa centralização elimina falhas causadas por atualizações genéricas do SO.

O isolamento do sistema vai além das rotinas de atualização e afeta diretamente a camada de monitoramento. O instalador da ISO sela o ambiente desativando o acesso remoto via SSH e bloqueando o uso da credencial de root. Essa configuração impede a implantação suportada de agentes corporativos, como soluções de EDR, XDR ou Zabbix. O impeditivo para o administrador não é a inexistência dessas funções no Linux, mas a regra de operação do appliance. Forçar o acesso para instalar qualquer pacote de terceiros quebra a integridade do sistema e invalida o suporte oficial da fabricante.

Essa dinâmica reflete a arquitetura de referência da Veeam para o Repositório Imutável, que exige uma instalação estritamente mínima para reduzir vetores de ataque. A diferença entre as abordagens reside na gestão do risco. No modelo DIY, a equipe detém a gerência do sistema operacional e decide se assume o risco de instalar os agentes para atender à auditoria interna. No modelo JeOS, a mídia de instalação impõe a diretriz da fabricante por design. O servidor opera com a segurança validada pela Veeam, mas exige que o departamento de TI aceite manter o equipamento isolado e fora das ferramentas de monitoramento padrão da organização.

Essa mesma diretriz de integridade que bloqueia softwares de terceiros define o método de expansão do armazenamento. No cenário base com um servidor de 24 baias e 14 discos ocupados, o hardware possui 10 slots físicos livres. A inviabilidade de utilizar esses discos não ocorre por uma simples restrição de permissão no terminal, mas por uma imposição de arquitetura. A manipulação manual do LVM e o redimensionamento do XFS fora do escopo do instalador inicial descaracterizam o appliance e quebram a matriz de suporte. Por design, inserir discos na controladora local para expandir o volume lógico existente torna-se uma operação descartada, subutilizando o chassi. Para acomodar o crescimento dos backups, a engenharia da Veeam exige estritamente a expansão horizontal. O administrador precisa configurar um Scale-Out Backup Repository (SOBR) e provisionar um servidor físico independente para atuar como um novo nó no cluster.

A decisão entre construir o repositório do zero ou adotar a mídia da fabricante não se resume a certo ou errado. A escolha depende da capacidade da equipe de TI em absorver a carga operacional e das políticas de governança da empresa. A seguir, o resumo técnico do comportamento de cada arquitetura na sustentação diária.

O Modelo Manual (DIY)

Prós:

• Expansão vertical a quente: O controle sobre o LVM e o XFS permite adicionar discos na controladora e crescer o volume lógico sem indisponibilidade, aproveitando o chassi existente.
• Integração de governança: O acesso administrativo possibilita a instalação de agentes de EDR, XDR e Zabbix, inserindo o servidor nas ferramentas de auditoria e segurança corporativa.
• Flexibilidade de hardware: Suporta o mapeamento de LUNs via iSCSI ou Fibre Channel com configuração de multipath, caso o uso de discos locais não seja uma opção viável.

Contras:

• Carga operacional contínua: A equipe de TI assume a manutenção integral do Linux, sendo responsável por gerenciar o ciclo de vida, aplicar patches de segurança e monitorar vulnerabilidades (CVEs).
• Risco de atualizações: Patches autônomos no kernel ou em bibliotecas do sistema carregam o risco técnico de gerar falhas no boot ou corromper a montagem do volume.
• Complexidade de storage: A preparação exige o cálculo manual do stripe unit e stripe width no comando mkfs.xfs para alinhar a formatação com a topologia do RAID físico.

O Modelo Empacotado (JeOS)

Prós:

• Implementação automatizada: O instalador configura o LVM, formata o volume com reflink e aplica as políticas de hardening do DISA STIG de forma nativa e sem intervenção manual.
• Gestão de atualizações controlada: A Veeam homologa os pacotes e a aplicação ocorre por uma interface própria, mitigando o risco de quebras geradas por atualizações genéricas do sistema operacional.
• Segurança por design: O bloqueio sistêmico de acesso remoto e a restrição rigorosa à instalação de softwares de terceiros reduzem drasticamente a superfície de ataque do repositório.

Contras:

• Expansão restrita: A impossibilidade de redimensionar o LVM localmente de forma suportada obriga o uso de expansão horizontal (SOBR), exigindo a aquisição de novos servidores físicos para crescer a volumetria.
• Isolamento de monitoramento: O bloqueio da instalação de agentes de telemetria e proteção corporativa gera um ponto cego para o SOC e para as políticas de auditoria interna da organização.
• Restrição de armazenamento externo: O instalador não suporta o mapeamento de LUNs via rede, removendo pacotes de protocolos como iSCSI e Fibre Channel. Essa arquitetura impede a conexão com storages externos, exigindo obrigatoriamente o uso de discos físicos locais ou gavetas DAS conectadas diretamente na controladora.

A Analogia: Bolo de Aniversário

Fazer o próprio bolo, que representa o modelo DIY, significa comprar os ingredientes e assumir a batedeira. O controle da receita é absoluto. Se você decidir adicionar mais uma camada de recheio no meio do processo (expandir o LVM e o XFS a quente), você tem liberdade para ajustar a estrutura. Se a festa exige um topo de bolo ou uma vela específica (instalar o agente de EDR ou Zabbix da empresa), você simplesmente espeta na cobertura. O preço dessa liberdade é a responsabilidade pela cozinha. Você assume integralmente o risco de errar a temperatura do forno ou o tempo de cozimento (aplicar um patch de kernel problemático). Se a massa solar, o problema é inteiramente seu e da sua equipe.

Comprar o bolo pronto, ilustrando o JeOS, é receber o produto na caixa, lacrado e com garantia de qualidade da confeitaria. O fabricante entrega à receita homologada e segura. Como a sua equipe não precisa operar o forno, o risco de a massa desabar simplesmente não existe. Para manter essa integridade, o produto chega com uma regra estrita de não alteração. O confeiteiro proíbe o cliente de espetar enfeites próprios na cobertura (instalar telemetria e agentes corporativos), pois isso fura a estrutura validada na cozinha. Somado a isso, se a volumetria da festa aumentar e o bolo ficar pequeno, não há como abrir a massa para injetar mais recheio. A única saída suportada é encomendar um segundo bolo inteiro e colocar na mesma mesa para os convidados (expansão horizontal criando um cluster SOBR).

Cenário: Ataque Ransomware

A validação de uma arquitetura de backup ocorre durante um incidente de ransomware. Na progressão de um ataque, após o movimento lateral e o comprometimento do Active Directory e dos hypervisors, o repositório de backups torna-se o alvo prioritário.

O atacante busca dominar o servidor de backup da organização. Com elevação de privilégio ou até com apoio de algum membro da sua equipe de TI, o invasor acessa a console de gerenciamento e executa a exclusão de todos os pontos de restauração.

Se o repositório de dados não tem imutabilidade, a exclusão é processada pelo sistema de arquivos. Sem os dados para restauração, a equipe de TI fica sem opções para restabelecer o ambiente, restando à organização a negociação financeira para tentar recuperar os sistemas.

Considere o mesmo nível de comprometimento em uma infraestrutura com Veeam + Hardened Repository. O invasor domina o servidor VBR, vamos levar em consideração o cenário mais crítico, onde o MFA e Four-Eyes Authorization foram desabilitados e credenciais de usuários com permissão Backup Administrator foram comprometidas. O invasor envia o comando de exclusão. O sistema operacional do repositório Linux rejeita a instrução. A flag de imutabilidade bloqueia a alteração dos blocos diretamente no XFS, ignorando os comandos originados pela aplicação comprometida.

Com a exclusão via console bloqueada, o atacante busca acesso direto ao servidor do repositório. A tentativa padrão é estabelecer conexão SSH para escalar privilégios e formatar o volume na linha de comando. Neste cenário, tanto o modelo JeOS quanto o modelo DIY entregam o mesmo nível de proteção, desde que a infraestrutura manual siga a arquitetura de referência da fabricante. A aplicação das políticas de hardening do DISA STIG, a conformidade com o FIPS e a desativação do serviço SSH eliminam os vetores de acesso remoto. O servidor rejeita qualquer autenticação com credenciais de domínio e opera isolado da rede de gerência comprometida. O invasor não consegue alcançar os discos lógicos para a destruição dos dados, pois o acesso administrativo é negado diretamente na camada do sistema operacional.

Com o ambiente de produção criptografado os dados no repositório permanecem íntegros. A equipe de TI restabelece a infraestrutura do VBR e reconecta o repositório imutável para acessar os dados que estão protegidos e prontos para restauração.

Neste estágio, há uma regra operacional estrita. A liberação do ambiente para restauração é responsabilidade exclusiva do time de SOC. Executar o restore sem mitigar e isolar o vetor de ataque original resultará em uma nova criptografia dos dados restaurados e retrabalho. Apenas após a validação da equipe de segurança, o administrador inicia a recuperação das máquinas virtuais, executando o procedimento padrão de recuperação de desastres.

Nota Técnica de Arquitetura

 A imutabilidade no sistema de arquivos e o hardening do sistema operacional formam uma proteção lógica robusta, mas dependem integralmente do isolamento físico e da rede de gerência do hardware subjacente. Se um atacante domina o ambiente e não consegue escalar privilégios no Linux (via SSH bloqueado), a progressão natural do ataque visa a interface de gerência Out-of-Band (iLO, iDRAC, XCC ou IPMI).

Se a porta de gerência do servidor físico estiver acessível na mesma VLAN da infraestrutura comprometida, ou se a autenticação depender do mesmo Active Directory dominado pelo atacante, a segurança do sistema operacional torna-se irrelevante. O invasor acessa a interface web da controladora base, reinicia o equipamento de forma abrupta e simplesmente destrói a configuração de RAID na controladora de discos. A integridade dos dados, o LVM, a formatação XFS e a flag de imutabilidade são apagados na camada de hardware, antes mesmo do boot do Linux. A arquitetura de referência exige que as interfaces Out-of-Band do repositório imutável operem em redes fisicamente segregadas (air-gapped) ou em VLANs estritamente isoladas, utilizando autenticação local forte e independente do domínio corporativo.

Conclusão

O modelo DIY direciona o custo para o OPEX, exigindo alocação de horas de engenharia para a sustentação e segurança do Linux, enquanto otimiza o CAPEX ao utilizar a capacidade integral do hardware local. O modelo JeOS segue a diretriz inversa: reduz o OPEX por meio da automação de rotinas e atualizações, mas demanda incremento de CAPEX para a expansão horizontal via adição de novos servidores físicos. O TCO (Custo Total de Propriedade) é estabelecido pela proporção entre a capacidade técnica da equipe em gerenciar sistemas abertos e a disponibilidade de capital para aquisição de infraestrutura.

Quando um ataque de ransomware escala e o invasor domina a rede de gerência, o repositório de backup torna-se o alvo principal. Sem a proteção de imutabilidade, a exclusão dos dados é processada e a organização perde sua capacidade de restauração. 

O invasor consegue destruir os hypervisors, comprometer o Active Directory e inutilizar o servidor VBR, mas os arquivos no repositório imutável permanecem intactos. Com a imutabilidade implementada corretamente, a organização mantém a viabilidade técnica de recuperação. O ROI (Retorno sobre o Investimento) dessa infraestrutura não é mensurado em economia de discos ou no tempo de deploy. O retorno financeiro é a capacidade de recusar a extorsão e iniciar o procedimento de recuperação de desastres. O VHR representa a diferença técnica entre restabelecer a operação a partir do cofre de dados ou assumir a paralisação prolongada do negócio.

Reflexão

1. Hoje, o seu repositório de backup principal opera com imutabilidade nativa no sistema de arquivos?
2. Se a sua infraestrutura sofrer um incidente de ransomware neste exato momento, existe a garantia técnica de que os dados armazenados no cofre estão isolados e protegidos contra a exclusão?
3. O sistema operacional que hospeda os seus backups atuais segue frameworks rigorosos de segurança e conformidade, como as diretrizes do DISA STIG e a certificação FIPS?

Neste artigo, detalhamos a configuração de um repositório imutável em um servidor físico padrão, com discos locais e gerenciamento direto do sistema operacional. No próximo artigo da série, o escopo técnico muda para os appliances de backup e deduplicação.

A análise abordará hardwares customizados, projetados para suportar o I/O de gravação e restauração, além de seus recursos nativos de segurança. Focaremos na mecânica de reidratação de blocos e no efeito prático sobre o tempo de recuperação (RTO), comparando o funcionamento de arquiteturas como ExaGrid e Dell Data Domain.

Fontes

Hardened Repository – Veeam Backup & Replication User Guide

Installing Veeam Infrastructure Appliance with ISO – Veeam Backup & Replication User Guide

Whitepapper: 2025 Ransomware Trends and Proactive Strategies