---
title: "Como fazer backup de várias zonas de segurança sem comprometer a segmentação da rede"
published_at: "2026-10-15T08:28:27+00:00"
modified_at: "2026-10-15T08:29:39+00:00"
url: "https://www.baculasystems.com/pt/pt-blog/backup-em-varias-zonas-de-seguranca/"
markdown_url: "https://www.baculasystems.com/pt/pt-blog/backup-em-varias-zonas-de-seguranca.md"
---

[Home](https://www.baculasystems.com/pt/)
 > [Blog de Apoio e Recuperação](https://www.baculasystems.com/pt/pt-blog/)
 > Como fazer backup de várias zonas de segurança sem comprometer a segmentação da rede

# Como fazer backup de várias zonas de segurança sem comprometer a segmentação da rede

Atualizado 15th outubro 2026, Rob Morrison

O backup entre múltiplas zonas de segurança deve preservar os limites de confiança impostos pela rede de produção. Utilize credenciais específicas para cada zona, fluxos de rede com escopo restrito, tráfego de controle e de dados separados e caminhos de recuperação independentes. Nos casos em que a conectividade persistente entre zonas for proibida, utilize replicação controlada, transferência unidirecional ou mídia offline, em vez de enfraquecer a segmentação da rede.

Esta nota destina-se a arquitetos de infraestrutura e segurança e a administradores sênior envolvidos na [arquitetura de backup corporativo](https://www.baculasystems.com/pt/pt-blog/backup-escalavel/)
 em ambientes deliberadamente segmentados, como defesa, aeroespacial, pesquisa, tecnologia operacional, infraestrutura crítica e empresas que operam redes em diferentes níveis de classificação ou domínios de confiança. Esses podem ser domínios de rede classificados e não classificados, tecnologia da informação corporativa versus tecnologia operacional no chão de fábrica e configurações semelhantes.

O foco está no conhecimento sobre backup e na resolução de um problema de projeto. Especificamente, esta nota trata da proteção de zonas sem a criação de novos caminhos entre elas.

**Pontos-chave**

- O backup multizona deve preservar os limites existentes das zonas de segurança.
- Utilize credenciais privilegiadas específicas para cada zona e regras de firewall com escopo restrito.
- Separe o tráfego de controle de backup do tráfego de dados de backup.
- Mantenha a capacidade de recuperação local onde as zonas precisem operar de forma independente.
- Teste a recuperação sem conectividade entre zonas, identidade centralizada e catálogos compartilhados indisponíveis.

## Por que o backup é difícil em múltiplas zonas de segurança?

Arquiteturas de backup centralizadas podem criar riscos estruturais de segurança em ambientes segmentados. Elas geralmente dependem de conectividade persistente e privilégios elevados além dos limites das zonas, o que pode transformar o sistema de backup em um caminho potencial para movimentação lateral.

Arquiteturas de backup centralizadas, como suítes de backup corporativo com console único e arquiteturas centralizadas de pull por dispositivos, pressupõem que o servidor de backup alcance todos os clientes, que os clientes retornem dados para o armazenamento compartilhado e que todos possam acessar o plano de gerenciamento.

Essa suposição funciona em uma rede plana. No entanto, ela não funciona em ambientes deliberadamente segmentados, como redes táticas militares e enclaves de pesquisa de defesa, bem como em ambientes industriais de tecnologia operacional e controle de supervisão e aquisição de dados.

O backup entre zonas de segurança deve preservar ambientes com segmentação de rede imposta. Quando o backup conecta a zona de tecnologia da informação corporativa a um ambiente de engenharia restrito, a segmentação passa a prejudicar o sistema de backup.

O tráfego de backup complica a situação. Especificamente, isso se refere a conexões grandes, regulares e autenticadas que atravessam os limites das zonas em um cronograma previsível. Além disso, refere-se a credenciais de contas de serviço com privilégios elevados em ambas as extremidades e a cópias armazenadas de tudo o que é acessado.

Quando um componente de backup é comprometido, ele permite o acesso a dados de zonas que não poderiam ser alcançadas pela rede de produção.

A partir de outubro de 2026, a norma NIST SP 1339 (junho de 2026) recomenda a criação regular de backups de OT, bem como testá-los e revisá-los durante exercícios de recuperação.

## Por que a infraestrutura de backup pode criar risco entre zonas?

Um servidor de backup com conexões autorizadas a várias zonas pode se comunicar entre essas zonas por meio de caminhos permitidos. Quando o servidor é comprometido, os canais autorizados existentes chegam a todas as zonas atendidas. E isso é causado pelo posicionamento, não por uma configuração incorreta.

## Por que você deve definir limites de confiança antes de escolher um software de backup?

Mapeie os limites de confiança, a direção permitida das conexões e os caminhos de comunicação proibidos antes de escolher ou configurar produtos de backup. Primeiro, projete a arquitetura; depois, o produto se encaixará nela.

A Arquitetura Zero Trust do NIST descreve a eliminação da confiança implícita baseada simplesmente na localização na rede. [Guia Rápido de Backup de Tecnologia Operacional (OT) do NIST (SP 1339)](https://www.nist.gov/publications/ot-backup-quick-start-guide)
 é o Guia Rápido de Backup de Tecnologia Operacional (OT) publicado pelo Instituto Nacional de Padrões e Tecnologia (NIST) e pelo Centro Nacional de Excelência em Cibersegurança (NCCoE). Esse guia identifica que as organizações devem estabelecer procedimentos claros para backup e recuperação contra ransomware.

[Arquitetura Zero Trust do NIST (SP 800-207)](https://www.nist.gov/publications/zero-trust-architecture)
 é uma publicação oficial do Instituto Nacional de Padrões e Tecnologia que define a Arquitetura Zero Trust (ZTA) e estabelece diretrizes para que a segurança cibernética possa se afastar das defesas de rede tradicionais, baseadas no perímetro.

Não há confiança implícita concedida com base exclusivamente na localização física ou na rede. Aqui está uma fonte governamental confiável que aborda [cópias de recuperação protegidas/offline/imutáveis](https://www.mydatapath.com/blog/backup-immutability-checklist-ransomware-resilient-it-environments/)
.

Um erro comum é primeiro construir relações de confiança e só depois escolher uma plataforma de backup.

Recursos do produto, como desduplicação e compactação globais em linha, snapshots em múltiplas nuvens e orquestração de matrizes de armazenamento, são menos essenciais do que compreender quais comunicações são permitidas entre zonas. Produtos de backup não podem anular uma regra de firewall aplicada corretamente.

1. Antes de qualquer configuração de backup, identifique as zonas de segurança e seu nível de classificação.
2. Em seguida, defina quais sistemas podem se conectar com outros.
3. Em seguida, separe o tráfego do plano de controle do tráfego do plano de dados durante as análises.
4. Além disso, identifique os locais onde as credenciais têm permissão para existir.
5. Por fim, mapeie os caminhos proibidos onde o projeto de backup pode operar.

A localização das credenciais é uma decisão relacionada ao limite de confiança. Uma conta de serviço de backup com acesso de leitura aos sistemas da Zona C não deve existir em um sistema com conectividade à Zona A.

O escopo e a localização das credenciais representam decisões relacionadas ao limite de confiança.

Referência de orientação revisada em outubro de 2026: NIST SP 800-207, publicada em agosto de 2020.

## Quais modelos de arquitetura de backup funcionam em múltiplas zonas de segurança?

Os modelos não são universalmente corretos. O padrão correto depende dos níveis de classificação, dos caminhos de comunicação permitidos, dos requisitos de recuperação e do custo operacional necessário para o isolamento de cada zona. O backup multizona não deve criar novos caminhos de acesso entre zonas.

Cinco padrões estabelecidos permitem o backup além dos limites das zonas, como a rede de tecnologia da informação corporativa em comparação com a tecnologia operacional industrial no chão de fábrica e os enclaves de produção geral na nuvem em comparação com os ambientes de processamento de pagamentos em conformidade com a Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI-DSS).

Cada um deles representa um equilíbrio entre simplicidade operacional e isolamento de segurança.

| Modelo | Descrição | Ideal para | Risco principal |
| --- | --- | --- | --- |
| Centralizado | Um único servidor de backup utiliza regras de firewall entre zonas para atender a todas as zonas | Zonas com níveis variáveis de sensibilidade, mas com o mesmo nível de confiança | Único ponto de comprometimento com acesso autorizado a todas as zonas |
| Totalmente distribuído | Cada zona possui seu próprio servidor de backup, armazenamento e catálogo. Os dados não ultrapassam os limites das zonas. | Ambientes em que os dados permanecem sempre dentro de sua zona. | Duplicação da infraestrutura; complica a recuperação entre zonas |
| Hierárquica | Infraestrutura de backup no nível da zona com replicação opcional para um repositório central por meio de um gateway controlado. A infraestrutura de backup não deve enfraquecer os limites de confiança existentes. | Ambientes que exigem recuperação local e retenção centralizada | O gateway se torna um alvo de alto valor entre zonas, sendo um gateway crítico para a segurança com acesso a várias zonas. |
| Replicação controlada | Backup local na zona; dados transferidos por meio de um gateway, diodo de dados ou abertura programada do firewall. Um diodo de dados é um dispositivo de segurança de rede baseado em hardware que permite a transmissão unidirecional de dados entre duas redes. | Ambientes com conexões persistentes de backup entre zonas proibidas | A janela de transferência funciona como uma superfície de ataque quando não há controle rigoroso. A superfície de ataque consiste nos sistemas, serviços e caminhos de rede que um invasor poderia potencialmente explorar. |
| Totalmente separado | Os componentes não são compartilhados em nenhuma camada. Apresenta servidores, armazenamento, catálogos, caminhos de administração e procedimentos de recuperação separados. | Requisitos de isolamento absoluto; separação entre informações classificadas e não classificadas | Custo operacional mais alto; capacidade de backup com duplicação completa |

## Qual lado deve iniciar a conexão de backup?

A direção preferencial da conexão depende do limite de confiança. Em zonas com o mesmo nível de confiança, pode ser apropriado usar conexões padrão do Bacula iniciadas pelo Director. Em zonas restritas, a conectividade de entrada reduzida pode resultar em uma superfície de ataque autorizada menor, e a configuração selecionada do Bacula deve ser compatível e testada.

Em uma implantação convencional do Bacula, o Director estabelece conexões tanto com o File Daemon (no cliente) quanto com o Storage Daemon (no destino de armazenamento). O fluxo de dados de backup circula entre o File Daemon e o Storage Daemon. O Director não está no caminho dos dados.

Em ambientes onde as zonas têm o mesmo nível de confiança e o Director pode estabelecer conexões de entrada com os clientes, o modelo padrão pode operar sem a necessidade de modificações.

Quando um limite de zona não permite conexões de entrada provenientes da rede de backup, a conexão padrão iniciada pelo Director com o File Daemon pode não ter permissão.

O Bacula suporta conectividade iniciada pelo File Daemon por meio de sua configuração `ConnectToDirector`. Confirme a disponibilidade e o comportamento em relação à versão do Bacula implantada em seu ambiente, reduzindo os requisitos de acesso de entrada na zona restrita. Isso requer planejamento e testes específicos, o que também se refere ao agendamento e ao comportamento do controle de tarefas.

## Como a direção da conexão de backup afeta o risco entre zonas?

O risco de pivô é o risco de usar uma conexão de backup autorizada para acessar outra zona. Qual lado deve iniciar a conexão de backup?

Se o Director estabelecer conexões com clientes da Zona C usando uma regra autorizada, um Director comprometido terá um caminho permitido já existente para a Zona C. Se os File Daemons da Zona C estabelecerem conexões de saída, essa superfície de entrada será reduzida. O firewall controla o que pode ser mantido sob controle, e a arquitetura determina o que é autorizado.

A conectividade bidirecional através de um limite de zona permite que o número de caminhos de conexão entre zonas permitidos aumente em ambas as direções. Requisitos operacionais específicos devem justificar regras bidirecionais de firewall associadas ao tráfego de backup através de um limite de alta sensibilidade, sem deixá-las como padrão.

## Como evitar que a infraestrutura de backup crie um caminho entre zonas?

Um servidor de backup conectado a várias zonas pode rotear o tráfego entre elas usando suas interfaces. Evite isso por meio de controles explícitos na camada de rede, interfaces separadas por zona, roteamento entre interfaces desativado e uma pegada mínima de serviços.

Um servidor de backup com conexões autorizadas a várias zonas atua como uma ponte entre elas. O servidor utiliza roteamento, não uma configuração incorreta. Se o tráfego da Zona B e da Zona C chegar em interfaces diferentes, o roteamento entre elas deve ser desativado ou regido por uma política específica.

Cada zona deve ter uma interface de rede separada. Minimize os serviços na infraestrutura de backup. Trate cada um deles como uma superfície de ataque adicional.

A administração deve contar com um caminho de gerenciamento dedicado, sem atravessar as redes das zonas de produção.

## Como o controle de backup e o tráfego de dados devem ser separados?

A arquitetura do Bacula foi projetada estruturalmente para separar os planos de controle e de dados. O plano de controle transporta o tráfego de gerenciamento e orquestração de tarefas. O plano de dados transporta os dados de backup e restauração.

O Director mantém o agendamento e a orquestração de tarefas sob controle sem transportar dados de backup. O File Daemon envia dados para o Storage Daemon. Não há Director no caminho dos dados.

O firewall tem implicações específicas: Director→Daemon de Arquivos ([Protocolo de Controle de Transmissão 9102](https://www.iana.org/assignments/service-names-port-numbers?&page=115)
) e Director→Daemon de Armazenamento ([Protocolo de Controle de Transmissão 9103](https://www.iana.org/assignments/service-names-port-numbers?&page=115)
) transportam o controle de tarefas. O caminho Daemon de Arquivos→Daemon de Armazenamento transporta o fluxo de backup.

É possível restringir o acesso do console de gerenciamento ao Director ([TCP 9101](https://www.iana.org/assignments/service-names-port-numbers?&page=115)
) a uma rede de gerenciamento dedicada, sem afetar os fluxos de dados de backup.

O Director pode permanecer na Zona de Backup utilizando regras restritas para zonas de produção (apenas orquestração de tarefas). As regras do Daemon de Armazenamento regem separadamente o caminho de dados de maior volume.

Quando uma única regra ampla é utilizada para ambos, o valor arquitetônico da separação é descartado. O tráfego de gerenciamento, incluindo acesso ao console e consultas ao catálogo, deve trafegar por um caminho dedicado. Ele não deve trafegar por interfaces compartilhadas com os dados de backup.

**Tabela de referência de fluxos do firewall**

| Origem | Destino | Porta padrão | Finalidade | Direção |
| --- | --- | --- | --- | --- |
| Console | Diretor | TCP 9101 | Gerenciamento | Console → Diretor |
| Diretor | Daemon de arquivos | TCP 9102 | Controle de tarefas | Diretor → FD |
| Diretor | Daemon de armazenamento | TCP 9103 | Controle de armazenamento | Diretor → SD |
| Daemon de arquivos | Daemon de armazenamento | TCP 9103 | Dados de backup | FD → SD |

## Como as credenciais de backup devem ser isoladas entre as zonas de segurança?

Utilize credenciais de backup privilegiadas distintas para cada zona de segurança. Certifique-se de que o comprometimento de credenciais em uma zona não conceda automaticamente acesso autenticado a outra.

As contas de serviço de backup na Zona C devem ser diferentes das da Zona B e da Zona A. Quando as credenciais são compartilhadas, um único comprometimento pode ampliar o alcance autenticado a todas as zonas que utilizam essas credenciais.

As dependências de recuperação em infraestruturas de identidade centralizadas, como o Active Directory, o Protocolo Leve de Acesso a Diretórios (LDAP) e provedores de identidade externos (IdPs), representam um ponto comum de falha arquitetônica. Os IdPs são sistemas centrais, como o Okta, o Microsoft Entra ID ou o Google Identity, que gerenciam contas de usuário, autenticações e permissões de acesso.

Se a Zona C for autenticada pelo provedor de identidade da Zona A, a Zona A poderá ajudar a Zona C na recuperação. Contas de serviço locais com credenciais gerenciadas de forma independente eliminam essa dependência.

Utilize uma programação específica para alternar as credenciais das contas de serviço de backup. Responda à pergunta “A Zona C pode ser restaurada com um provedor de identidade central offline?” antes que ocorra um incidente.

## Como os dados de backup devem ser transferidos entre zonas de segurança?

Escolha o mecanismo de transferência com base no nível de sensibilidade da zona. Uma zona restrita significa que o mecanismo de transferência deve minimizar sua superfície de rede persistente. Especificamente, isso se refere à transferência direta por meio de gateways e aberturas por tempo limitado, bem como a mídias físicas offline, nos casos em que um caminho de rede entre zonas é proibido ou inaceitável.

Quando os dados de backup precisam atravessar um limite de zona para retenção ou recuperação de desastres, o método de transferência faz parte da arquitetura de segurança.

**A transferência direta** usando uma regra de firewall autorizada é a opção mais simples. No entanto, ela cria um caminho persistente com regras que especificam endereços e portas exatos. Essas regras devem ser registradas.

**Um gateway controlado** pode limitar o efeito de um comprometimento quando seus destinos, protocolos e funções permitidos são rigidamente restritos.

**O armazenamento e encaminhamento com aberturas de firewall por tempo limitado** preserva a capacidade de recuperação local, independentemente de a janela de transferência estar aberta ou não.

**A transferência offline por mídia física** evita uma conexão de rede entre as zonas de origem e destino durante a transferência. Zonas altamente isoladas podem aceitar apenas essa opção. Zonas isoladas devem ter um caminho de recuperação definido quando os serviços compartilhados estiverem offline.

Os dados de backup devem ser criptografados antes de cruzarem um limite de zona. Ninguém deve ser capaz de acessar as chaves de descriptografia fora da zona de origem.

## Por que a recuperação entre zonas pode ser mais difícil do que o backup?

Mesmo que o projeto consiga gravar com sucesso os dados de backup entre zonas, ele pode falhar durante a recuperação de desastres. A recuperação depende de um ambiente de destino funcional, serviços de identidade, conectividade de rede e um catálogo operacional. Essas dependências podem impedir a recuperação, mesmo quando os dados de backup em si estão intactos. A recuperação deve ser testada com as dependências entre zonas indisponíveis.

A integridade da zona também está associada à recuperação. Especificamente, se os dados da Zona C forem restaurados na Zona A, a forma como os dados saíram de sua zona pode não atender aos requisitos da fronteira. A integridade da zona e a integridade dos dados não são as mesmas restrições.

Responda a estas perguntas antes de ocorrer um incidente:

- Se não houver conectividade entre zonas, cada zona poderá se recuperar de forma independente?
- Se o catálogo de backup estiver indisponível, a recuperação poderá prosseguir a partir de mídia offline?
- O backup local de credenciais está definido e testado para recuperação caso os serviços centrais de identidade estejam indisponíveis?
- O armazenamento local está atualizado o suficiente para permitir uma recuperação viável com um firewall entre zonas desativado?
- Os locais podem operar e se recuperar de forma independente sem uma rede de longa distância?

## Qual é a diferença entre disponibilidade de backup e capacidade de recuperação?

Gravar com sucesso no armazenamento é considerado disponibilidade. Quando os dados são recuperados corretamente para a zona certa, por meio de autenticação válida, dentro do tempo exigido, com o firewall entre zonas desativado e a identidade central offline, trata-se de capacidade de recuperação. É essencial se concentrar no projeto e no teste da capacidade de recuperação, não apenas na disponibilidade.

Um sistema que grava no armazenamento é considerado disponível. Um sistema é considerado recuperável quando utiliza autenticação válida para restaurar os dados corretos na zona correta, em um destino funcional, dentro do tempo exigido e com o firewall entre zonas desativado e a identidade central offline. Essas são propriedades diferentes. A segunda deve ser testada.

## Como é uma arquitetura de backup de três zonas?

Este cenário trata de um projeto multizona coerente, no qual a capacidade de recuperação das zonas corresponde ao seu nível de isolamento. Especificamente, a Zona A depende da Zona de Backup, e a Zona B se recupera localmente ou a partir da Zona de Backup. A Zona C se recupera a partir de componentes locais, sem depender de sistemas externos.

A arquitetura de referência a seguir demonstra um projeto multizona coerente. A Zona C está isolada, portanto não possui caminhos de rede de entrada ou saída para zonas externas. As funções do plano de controle e do plano de dados são locais à Zona C. Os dados saem por meio de transferência em fita física.

[https://www.baculasystems.com/wp-content/uploads/2026/10/Three-Zone-Backup-Architecture.png](https://www.baculasystems.com/wp-content/uploads/2026/10/Three-Zone-Backup-Architecture.png)
“Air-gapped” refere-se a mídias de backup fisicamente desconectadas, sem conexão ativa com a rede. Não se trata de um armazenamento isolado logicamente da rede.

Uma réplica de catálogo representa uma cópia sincronizada de alguns ou de todos os registros do catálogo primário, mantida em uma instância separada do banco de dados.

**Zona A: TI Corporativa**

Os daemons de arquivo transferem dados de saída para o daemon de armazenamento central. O Diretor utiliza um caminho autorizado no firewall para agendar tarefas. Não há armazenamento local de backup. Quando há conectividade, a Zona A pode se recuperar a partir da Zona de Backup.

**Zona B: Engenharia Restrita**

A Zona B protege clusters de computação de alto desempenho, cargas de trabalho de simulação, dados de projeto assistido por computador e conjuntos de dados de pesquisa. Ela hospeda um Diretor Bacula local, Daemons de Arquivo, Daemon de Armazenamento e catálogo, permitindo backup e recuperação sem conectividade com a Zona Central de Backup/Recuperação.

Os dados de backup são transferidos localmente dos Daemons de Arquivo para o Daemon de Armazenamento da zona, enquanto o Director local gerencia as tarefas de backup e restauração. As cópias de backup podem ser replicadas para a Zona Central de Backup/Recuperação por meio de um gateway controlado durante janelas de transferência autorizadas. Se a conectividade entre zonas não estiver disponível, a Zona B pode continuar as operações locais de backup e recuperação.

**Zona C: Altamente isolada**

Sem caminho de rede para zonas externas. A Zona C hospeda seu próprio Director, daemons de arquivo, daemon de armazenamento, catálogo e biblioteca de fitas. Um processo auditado transfere fisicamente as fitas para a Zona de Backup para importação no catálogo central. A Zona C realiza a recuperação a partir de seu daemon de armazenamento local, sem serviços de identidade externos ou conectividade de rede.

**Zona de Backup/Recuperação**

O Director central, o Daemon de Armazenamento, o catálogo e o console de gerenciamento residem aqui. Aceita conexões de backup das Zonas A e B. Não há roteamento entre zonas de produção. Retenção resistente a ransomware por meio de armazenamento de objetos imutáveis. A retenção resistente a ransomware é o armazenamento de backup projetado para resistir à exclusão ou modificação não autorizada.

A biblioteca de fitas permite a retenção de longo prazo e a importação para a Zona C. A administração conta com uma interface de gerenciamento dedicada, inacessível às redes das zonas de produção.

## Como escolher uma arquitetura de backup multizona?

Esta tabela ajuda a comparar opções nas principais dimensões de projeto. Cada linha representa uma decisão independente. As escolhas não precisam ser uniformes em todas as dimensões.

**Como projetar um backup multizona em 7 etapas**

| Questão de projeto | Opção A | Opção B | Opção C |
| --- | --- | --- | --- |
| Infraestrutura de backup | Centralizada: um servidor, todas as zonas | Específica por zona: dedicada por zona | Híbrida: Director central, armazenamento no nível da zona |
| Direção da conexão | Iniciada pelo servidor: o backup é obtido dos clientes | Iniciada pelo cliente: os clientes enviam os dados para o armazenamento | Mista: varia de acordo com a sensibilidade da zona |
| Armazenamento de backup | Central: todas as zonas gravam no armazenamento compartilhado | Por zona: cada zona mantém seus próprios dados | Em camadas: cópia local mais replicação central |
| Transferência entre zonas | Direta: regra de firewall persistente | Gateway: transferência com limite de tempo | Offline: mídia física, sem caminho de rede |
| Administração | Compartilhada: um console acessa todas as zonas | Segmentada: caminhos separados por zona | Totalmente isolado: sem infraestrutura administrativa compartilhada |
| Cópia final de recuperação | Disco imutável: online, protegido contra gravação | Armazenamento de objetos com bloqueio de objeto. O bloqueio de objeto trata do controle de retenção que impede que os dados de backup sejam modificados ou excluídos durante um período de proteção definido, independentemente do fornecedor. | Fita / offline: isolada fisicamente do mundo externo |
| Identidade para recuperação | Centralizada: depende do Active Directory e de um provedor de identidade externo | Contas locais: credenciais pré-configuradas | Mista: primária centralizada, alternativa local |

## A quais falhas uma arquitetura de backup multizona deve ser capaz de resistir?

Analise os cenários de falha em relação à arquitetura projetada antes de implantar o software. Cenários com respostas ambíguas ou negativas representam uma lacuna no projeto que você deve resolver antes que ocorra um incidente.

| Cenário de falha | Questão de projeto |
| --- | --- |
| Rede corporativa comprometida | As Zonas B e C podem continuar a realizar backup e recuperação de forma independente? O comprometimento da Zona A abre um caminho de acesso à Zona de Backup? |
| Servidor de backup comprometido | Um invasor consegue estabelecer conexões com as zonas de produção? As cópias de backup são imutáveis, de modo que não possam ser excluídas? |
| Uma zona fica inacessível | As zonas restantes conseguem continuar a fazer backup e recuperação? A indisponibilidade de uma zona afeta os catálogos das outras zonas? |
| Infraestrutura de identidade offline | As operações de backup e recuperação podem se autenticar sem o provedor central de identidade? |
| Firewall entre zonas fechado | Cada zona pode se recuperar de forma independente a partir do armazenamento local? O catálogo local está atualizado o suficiente? |
| Armazenamento primário destruído | Existe uma segunda cópia em uma mídia diferente, em outro local? Qual é o tempo de recuperação a partir da cópia secundária? |
| Catálogo de backup indisponível | A recuperação pode prosseguir a partir de mídia offline sem o auxílio do catálogo? O procedimento está documentado e testado? |

## O que você deve verificar antes de implantar um backup multizona?

Esta lista de verificação é essencial para a revisão do projeto. Os itens não marcados representam uma lacuna que você deve resolver antes que a arquitetura seja considerada concluída.

- Primeiro, os limites de confiança e as classificações de zona são documentados; em seguida, inicia-se o projeto da arquitetura de backup.
- Um componente comprometido na Zona B não pode acessar a Zona C por meio de canais de backup autorizados ou regras de firewall.
- As contas do serviço de backup são isoladas para cada zona. Nenhuma credencial privilegiada compartilhada atravessa os limites entre zonas.
- As regras de firewall relacionadas ao backup especificam exatamente a origem, o destino, as portas e a direção.
- As zonas podem fazer backup e recuperação localmente caso não haja conectividade entre zonas.
- Pelo menos uma cópia de recuperação fica fora da rede de produção: armazenamento online imutável ou mídia offline.
- Não é necessário dispor da infraestrutura ou dos serviços de identidade de outra zona para restaurar cada zona.
- Os procedimentos de recuperação são testados, incluindo cenários em que o catálogo não está disponível.
- São testados planos alternativos de credenciais locais para recuperação sem o provedor de identidade central. Credenciais locais são credenciais pré-configuradas, utilizáveis quando não há serviços de identidade centralizados.
- O tráfego de backup que atravessa os limites das zonas é registrado no firewall. Anomalias são monitoradas.

## Como o Bacula oferece suporte ao backup entre múltiplas zonas de segurança?

A separação entre o Director, o Storage Daemon e o File Daemon do Bacula é mais do que uma conveniência operacional. É uma propriedade arquitetônica que permite que diferentes componentes sejam colocados em zonas diferentes, com regras de firewall distintas. Dessa forma, eles podem oferecer suporte aos padrões de projeto multizona descritos ao longo desta nota.

[A arquitetura de backup do Bacula Enterprise](https://www.baculasystems.com/pt/bacula-enterprise-arquitetura/)
 oferece um modelo de componentes distribuídos que se adapta naturalmente a múltiplas zonas. Os usuários podem implantar o Director, o Storage Daemon e o File Daemon de forma independente. Componentes diferentes podem permanecer em zonas diferentes com regras de firewall distintas. Essa separação de componentes permite padrões de implantação que alinham serviços individuais do Bacula com diferentes zonas de segurança.

[A documentação de configuração do Bacula File Daemon](https://www.bacula.org/13.0.x-manuals/en/main/Client_File_daemon_Configur.html)
 fornece a comunicação entre o Director e o Storage Daemon para fazer o backup dos arquivos nos clientes.

Um Director na Zona de Backup pode gerenciar File Daemons em várias zonas. Os Storage Daemons locais atuam como o ponto final do caminho de dados nas zonas. Os dados fluem diretamente entre o File Daemon e o Storage Daemon sem passar pelo Director. É por isso que os requisitos de firewall do Director permanecem mais restritos. O posicionamento do Storage Daemon pode seguir a sensibilidade da zona sem depender da localização do Director.

Para zonas onde não há um caminho de rede aceitável para a Zona de Backup, o Bacula oferece suporte a [fitas](https://www.baculasystems.com/tape-backup-software/)
 e mídias offline como destinos locais da zona. Ou seja, um Daemon de Armazenamento grava localmente, e a fita é transferida fisicamente para importação na Zona de Backup, sem a necessidade de um caminho de rede entre as zonas.

As opções de armazenamento imutável do Bacula, incluindo bloqueio de objetos e fitas do tipo “grave uma vez, leia muitas vezes” (WORM), podem proteger cópias de backup devidamente configuradas contra exclusão ou modificação não autorizadas.

[Backup imutável e recuperação contra ransomware](https://www.baculasystems.com/pt/pt-blog/backup-imutavel/)
 são importantes ao lidar com uma zona de produção comprometida, da qual um invasor pode tentar excluir ou modificar cópias de recuperação acessíveis.

Para ambientes de HPC em zonas restritas, o Bacula oferece suporte ao Lustre, ao IBM General Parallel File System (GPFS) e a sistemas de arquivos paralelos de grande escala. Não são necessárias alterações para o isolamento da zona.

Os componentes são executados localmente, sem depender de infraestrutura externa de gerenciamento em nuvem. Verifique as dependências de licenciamento e de serviços externos em relação ao seu ambiente antes de usar o software.

O comportamento do produto Bacula e as opções de implantação suportadas devem ser verificados em relação à versão implantada. As referências técnicas nesta nota de arquitetura foram revisadas em outubro de 2026.

## Princípio-chave de arquitetura

O backup multizona deve preservar a segurança dos limites do ambiente de produção. A infraestrutura de backup não deve permitir acesso entre zonas proibido pela arquitetura de produção. Projete fluxos permitidos, credenciais e caminhos de recuperação independentes e, somente então, decida onde os componentes do Bacula serão implantados.

## Perguntas frequentes

### Um servidor de backup pode proteger com segurança várias zonas de segurança?

Potencialmente. Um servidor de backup centralizado pode ser apropriado quando as zonas compartilham requisitos de confiança compatíveis e suas conexões permitidas, credenciais e controles de roteamento não criam riscos inaceitáveis entre zonas.

### Os clientes de backup devem iniciar conexões?

Em zonas restritas, sim. Conexões de saída iniciadas pelo cliente reduzem a superfície de ataque de entrada por meio dos canais de backup para essa zona.

### O armazenamento imutável substitui o backup offline?

Não. A imutabilidade protege os dados de backup contra modificação ou exclusão sob controles de retenção definidos, mas, por si só, não fornece isolamento de rede. O backup offline remove a conexão de rede ativa enquanto o armazenamento permanece offline. Essas são proteções distintas que abordam riscos diferentes e podem ser usadas em conjunto.

### Uma zona isolada pode usar identidade centralizada?

Sim, se essa dependência for aceitável durante a recuperação. Se a recuperação depender desse provedor de identidade e não houver um plano alternativo de autenticação local, a perda do provedor pode impedir a recuperação.

### O Bacula pode fazer backup de uma zona sem conexão de rede persistente?

Sim. Um daemon de armazenamento local grava em fita dentro da zona. A fita é transferida fisicamente e importada para o catálogo central.

Sobre o autor

[https://www.linkedin.com/in/rob-morrison-3aa443/](https://www.linkedin.com/in/rob-morrison-3aa443/)

Rob Morrison é o diretor de marketing da Bacula Systems. Ele começou sua carreira de marketing de TI na Silicon Graphics, na Suíça, e desempenhou intensamente várias funções de administração de marketing por quase 10 anos. Nos 10 anos seguintes, Rob também ocupou vários cargos de administração de marketing na JBoss, Red Hat e Pentaho, assegurando o crescimento da participação no mercado dessas empresas reconhecidas. Ele é formado pela Universidade de Plymouth e tem um diploma de honras em mídia digital e comunicação, além de ter feito um programa de estudos no exterior.

*Posts Relacionados*

[https://www.baculasystems.com/pt/pt-blog/riscos-a-seguranca-cibernetica-na-area-da-saude-privacidade-dos-dados-dos-pacientes/](https://www.baculasystems.com/pt/pt-blog/riscos-a-seguranca-cibernetica-na-area-da-saude-privacidade-dos-dados-dos-pacientes/)
[Segurança de Big Data em organizações da área da saúde: riscos de segurança cibernética, proteção de dados e privacidade dos dados dos pacientes](https://www.baculasystems.com/pt/pt-blog/riscos-a-seguranca-cibernetica-na-area-da-saude-privacidade-dos-dados-dos-pacientes/)

julho 17, 2026

[https://www.baculasystems.com/pt/pt-blog/guia-de-seguranca-da-hpc-800-223-800-234/](https://www.baculasystems.com/pt/pt-blog/guia-de-seguranca-da-hpc-800-223-800-234/)
[Guia e padrões de segurança HPC: NIST SP 800-223 e SP 800-234](https://www.baculasystems.com/pt/pt-blog/guia-de-seguranca-da-hpc-800-223-800-234/)

outubro 6, 2025

[https://www.baculasystems.com/pt/pt-blog/seguranca-na-nuvem-no-setor-da-saude/](https://www.baculasystems.com/pt/pt-blog/seguranca-na-nuvem-no-setor-da-saude/)
[Por que a segurança na nuvem no setor da saúde não pode ser tratada da mesma forma que a segurança padrão na nuvem corporativa?](https://www.baculasystems.com/pt/pt-blog/seguranca-na-nuvem-no-setor-da-saude/)

junho 29, 2026

[https://www.baculasystems.com/pt/pt-blog/backup-imutavel/](https://www.baculasystems.com/pt/pt-blog/backup-imutavel/)
[O que é backup imutável? Backups imutáveis como medida de segurança de dados](https://www.baculasystems.com/pt/pt-blog/backup-imutavel/)

fevereiro 6, 2024

[https://www.baculasystems.com/pt/pt-blog/backup-em-nuvem-hibrida/](https://www.baculasystems.com/pt/pt-blog/backup-em-nuvem-hibrida/)
[Backup em nuvem híbrida: como as soluções de backup híbrido protegem os dados empresariais](https://www.baculasystems.com/pt/pt-blog/backup-em-nuvem-hibrida/)

setembro 8, 2026

[https://www.baculasystems.com/pt/pt-blog/backup-e-recuperacao-de-mainframe/](https://www.baculasystems.com/pt/pt-blog/backup-e-recuperacao-de-mainframe/)
[Backup e recuperação de mainframe: estratégias modernas para sistemas empresariais resilientes](https://www.baculasystems.com/pt/pt-blog/backup-e-recuperacao-de-mainframe/)

março 30, 2026