Zero Trust é frequentemente associado à verificação de identidade, ao acesso de menor privilégio e à autenticação contínua. Na Object First, partimos de uma mentalidade de Assumir Violação, reconhecendo que atacantes podem já estar dentro do ambiente. Por trás desses princípios existe outro requisito que recebe muito menos atenção: segmentação.
À medida que as organizações consolidam a infraestrutura para reduzir a complexidade operacional, entender o que deve permanecer separado se torna cada vez mais importante. Em uma arquitetura Zero Trust, a segmentação não se limita à separação física. Ela também pode ser definida por meio de zonas de segurança e resiliência, limites de confiança, controles administrativos e caminhos de comunicação cuidadosamente restritos. O objetivo é garantir que, mesmo que atacantes comprometam credenciais, contas privilegiadas ou outros segredos de segurança, eles não consigam usar esses comprometimentos para modificar ou destruir dados de backup protegidos.
Essa abordagem permite que o software de backup e os sistemas de armazenamento operem em conjunto sem violar os limites de segurança exigidos. Portanto, uma arquitetura de backup Zero Trust requer limites de confiança claros, caminhos de comunicação bem definidos e armazenamento que permaneça imutável e protegido mesmo quando outras camadas do ambiente tiverem sido comprometidas.
Segmentação, imutabilidade e air gap lógico atendem a propósitos diferentes
Segmentação, imutabilidade e air gap são frequentemente discutidos em conjunto, mas resolvem problemas diferentes. A segmentação estabelece limites de confiança. Seu propósito é conter o comprometimento e restringir o movimento lateral entre sistemas. A imutabilidade protege os dados de backup contra modificação ou exclusão. O air gap lógico cria separação entre ambientes para limitar a exposição.
Uma solução de armazenamento de backup pode ser imutável sem estar devidamente segmentada, e pode ser segmentada sem estar em air gap. Uma forte resiliência cibernética depende de entender o papel que cada controle desempenha.
Dentro de um framework Zero Trust, a segmentação responde a uma pergunta fundamental: se um componente for comprometido, o que permanece protegido? Para ambientes de backup, essa pergunta é especialmente importante porque a infraestrutura de backup está cada vez mais interconectada com os sistemas de produção.
O ambiente de backup contém múltiplas zonas de confiança
Muitas organizações tratam a infraestrutura de backup como um único sistema. Do ponto de vista de segurança, existem várias zonas de confiança distintas dentro de uma arquitetura moderna de backup.
As aplicações de produção ocupam uma camada. O software Backup ocupa outra. O armazenamento de backup imutável forma a camada mais interna, porque serve como a base da recuperação.
O modelo de cebola das zonas de confiança
Um modelo em camadas, como uma cebola, ajuda a ilustrar essas relações.
No centro estão os dados backup imutável. Ao redor ficam as aplicações de backup, as cargas de trabalho de produção, hipervisores, plataformas de armazenamento, ferramentas administrativas e sistemas de gerenciamento. Cada camada opera sob pressupostos de segurança diferentes.
Ambientes de produção exigem que administradores provisionem sistemas, excluam cargas de trabalho, modifiquem configurações e executem tarefas operacionais. Esses privilégios são necessários para as operações do dia a dia, mas também criam risco. O Zero Trust reconhece essa realidade e assume que credenciais acabarão sendo comprometidas.
Alguns modelos de segurança se concentram em evitar o comprometimento. Uma estratégia de recuperação Zero Trust assume que o comprometimento já ocorreu e faz uma pergunta diferente: o que sobrevive depois?
A resposta deve sempre incluir os dados de backup.
O software Backup requer acesso à produção, mas com um limite de confiança separado
Um dos conceitos mais importantes em segurança de backup é entender o papel do software de backup.
O software Backup é frequentemente visto como parte do ambiente de recuperação. Operacionalmente, porém, ele compartilha muitas das características dos sistemas de produção. Ele requer acesso privilegiado, interage com múltiplas plataformas e pode executar ações administrativas poderosas.
Se atacantes assumirem o controle do software de backup, eles podem desabilitar jobs, alterar políticas, remover configurações de retenção e interromper processos de recuperação.
Por esse motivo, o software de backup deve ser tratado como parte da camada mais ampla de produção sob a perspectiva de confiança.
Essa premissa influencia como arquiteturas Zero Trust são projetadas. A recuperação não pode depender de o software de backup permanecer não comprometido. A recuperação deve depender de o armazenamento de backup permanecer inalterado mesmo que o software de backup seja violado.
Quando se assume que toda credencial está exposta e que toda conta de administrador é vulnerável a phishing, o armazenamento imutável se torna a camada final protegendo a capacidade de recuperação.
Por que software e armazenamento devem permanecer separados
Um erro comum é tratar o software de backup e o armazenamento de backup como um único domínio de segurança.
Quando servidores de backup têm controle direto sobre o armazenamento, um atacante que comprometa a aplicação de backup pode ganhar um caminho até os próprios dados de backup. O mesmo risco surge quando identidades compartilhadas, planos de gerenciamento ou acesso administrativo irrestrito abrangem ambos os ambientes.
Uma segmentação forte cria um limite entre o software de backup e o armazenamento de backup. A comunicação deve ocorrer por meio de interfaces bem definidas, com permissões estritamente delimitadas.
Esse princípio se torna especialmente importante à medida que as organizações buscam modelos de infraestrutura mais integrados e consolidados.
A separação física é uma abordagem. A separação lógica é outra. O fator crítico é preservar limites de confiança independentes entre os componentes.
Também é importante distinguir entre domínios de rede e domínios de segurança. Os dois não são a mesma coisa. O software Backup frequentemente requer ampla conectividade de rede com o armazenamento de backup para gravar, ler e restaurar dados com eficiência. Essa conectividade necessária não significa que ambos os sistemas pertençam ao mesmo perímetro de segurança. Mesmo quando a infraestrutura de backup pode se comunicar diretamente com o armazenamento no nível de rede, seus limites de segurança devem permanecer separados.
Um sistema pode residir no mesmo appliance, cluster ou plataforma e ainda assim manter separação arquitetural. A comunicação por protocolos definidos e modelos de privilégio limitado ajuda a garantir que um comprometimento em um domínio não se propague automaticamente para outro.
Para clientes da Object First, o protocolo S3 serve como um limite-chave. O software Backup interage com o armazenamento por meio de uma interface controlada, em vez de acesso irrestrito ao sistema operacional. Essa separação ajuda a preservar a integridade dos dados backup imutável mesmo quando sistemas fora da camada de armazenamento são comprometidos.
O desafio de segurança por trás da consolidação de infraestrutura
Equipes de TI enfrentam pressão crescente para simplificar as operações. A consolidação reduz a sobrecarga administrativa, diminui a proliferação de fornecedores e simplifica o gerenciamento da infraestrutura.
A virtualização transformou a consolidação de servidores. Plataformas de armazenamento compartilhado consolidaram a infraestrutura de dados. Appliances integrados continuam essa tendência hoje.
Cada esforço de consolidação entrega benefícios operacionais, como infraestrutura compartilhada. Cada esforço de consolidação também pode remover camadas de separação. Por exemplo, se você executa um serviço de armazenamento virtualizado em um hipervisor, qualquer pessoa com privilégios no nível do hipervisor pode modificá-lo ou excluí-lo.
Portanto, equipes de segurança devem avaliar cuidadosamente as decisões de consolidação. Consolidar os componentes errados pode colapsar limites de confiança que antes protegiam ativos críticos.
O desafio é particularmente relevante para ambientes de backup porque a infraestrutura de recuperação precisa operar de forma diferente da infraestrutura de produção. Sistemas de produção são projetados para disponibilidade e eficiência operacional. O armazenamento Backup é projetado para sobreviver a comprometimentos.
Esses objetivos exigem pressupostos de segurança diferentes.
Arquiteturas bem-sucedidas equilibram eficiência com isolamento ao preservar os limites que protegem a recuperação.
Falhas comuns de segmentação
Muitas falhas de segmentação não são causadas por erros óbvios. Elas surgem de decisões que parecem operacionalmente eficientes.
Exemplos incluem:
-
Contas de administrador compartilhadas entre ambientes de produção, backup e armazenamento
-
Privilégios excessivos concedidos a servidores de backup
-
Acesso direto ao sistema operacional ou acesso em nível root ao armazenamento de backup
-
Sistemas de identidade consolidados sem controles de isolamento apropriados
-
Planos de gerenciamento compartilhados abrangendo múltiplas zonas de confiança
-
Interfaces de gerenciamento de hardware deixadas expostas ou protegidas de forma inadequada
Uma área frequentemente negligenciada envolve tecnologias de gerenciamento fora de banda, como IPMI, iDRAC e iLO.
Essas interfaces fornecem controle profundo, em nível de hardware, sobre a infraestrutura. Se atacantes obtiverem acesso a essa camada, as proteções acima dela podem se tornar irrelevantes. Sistemas de armazenamento, servidores e cargas de trabalho podem ser afetados por meio do plano de gerenciamento subjacente.
Os limites de segurança devem se estender além de aplicações e redes. Camadas de gerenciamento de hardware merecem o mesmo escrutínio que qualquer outro sistema privilegiado.
Verificando a segmentação na prática
As organizações devem validar regularmente que o armazenamento de backup permanece isolado de identidades, aplicações e camadas de infraestrutura comprometidas.
Perguntas-chave incluem:
-
Administradores de backup podem modificar os dados backup imutável?
-
O software de backup tem acesso ao sistema operacional do armazenamento?
-
Uma identidade comprometida pode abranger múltiplas zonas de confiança?
-
Os ambientes de armazenamento e backup são gerenciados por controles de segurança separados?
-
As interfaces de gerenciamento de hardware estão protegidas e monitoradas?
-
O comprometimento de um servidor de backup pode alterar diretamente o armazenamento de backup?
Se a resposta a qualquer uma dessas perguntas for sim, pode ser necessária segmentação adicional.
A Object First reforça essas proteções por meio de uma arquitetura construída para esse propósito, que elimina caminhos de ataque comuns. Sem exposição a um sistema operacional de uso geral, sem acesso root e sem acesso a shell disponível para clientes ou atacantes, funções críticas de armazenamento permanecem isoladas de muitos dos mecanismos comumente usados para comprometer plataformas tradicionais de armazenamento.
A segmentação protege a última linha de defesa
Em um modelo Zero Trust, cada camada de segurança deve ser avaliada pela ótica de violação assumida.
Administradores podem cair em phishing; ainda é o método de ataque cibernético mais comum. Credenciais podem ser roubadas. Aplicações podem ser comprometidas. A infraestrutura pode falhar.
A recuperação depende de garantir que a camada de armazenamento permaneça protegida quando esses eventos ocorrerem. A segmentação fornece os limites que tornam isso possível. Ela limita o movimento lateral, contém o comprometimento e preserva a integridade dos dados imutáveis. À medida que as organizações continuam a consolidar a infraestrutura, a pergunta mais importante permanece inalterada: quando tudo ao redor do ambiente de backup está sob ataque, o que ainda permanece de pé?
A resposta deve sempre ser, de forma absoluta, o armazenamento backup imutável. Essa é a base da resiliência e o propósito central da segmentação em uma arquitetura Zero Trust.

