Criar ou restaurar um backup de Sophos Firewall

Uma cópia de backup do Sophos Firewall é mais do que apenas um ficheiro de emergência. É a base para atualizações de firmware, substituição de hardware, migrações de XG para XGS, recriações, trabalhos HA e processos de recuperação limpos. Se o suporte de backup, Secure Storage Master Key e restauro não estiver em vigor, uma mudança planeada poderá rapidamente se tornar uma interrupção desnecessariamente longa.

O artigo explica como criar e restaurar backups de Sophos Firewall, quais informações adicionais devem ser documentadas e quais verificações são importantes antes de uma restauro para outro hardware ou plataformas.

⚠️ Importante: Um backup só será útil se for localizável, descriptografável e compatível com o ambiente de destino. Antes de atualizações de firmware, reimages, alterações ou migrações de HA, deve verificar conscientemente o ficheiro de backup, senha de backup, Secure Storage Master Key, versão de destino, acesso de gestão e processo de restauro.

Tutorial em vídeo

Qual caminho de recuperação é apropriado?

Backup e restauro geralmente são apenas parte do problema. Dependendo da situação, um procedimento diferente é mais apropriado:

• Planear atualização de firmware: Atualização de firmware Sophos Firewall: preparação e práticas recomendadas.
• Instalar imagem de firmware em WebAdmin: Executar atualização de firmware de Sophos Firewall.
• Atualização central ou política de grupo travada: Verifique a fila de tarefas de gestão de Sophos Firewall Central.
• Reinstale completamente o sistema operacional da firewall: Reinstale o sistema operacional Sophos Firewall: Reimage com USB.
• Defeito de hardware, erro repetido ou RMA: Abrir ticket de suporte Sophos: preparação e portal.
• Restaurar ou modificar cluster HA: variantes de cluster HA de Sophos Firewall.

Na prática, esses procedimentos se sobrepõem. Antes de uma nova imagem, quase sempre é necessário um backup. Antes de um caso de suporte, o número de série, a versão do firmware, os registos e as etapas anteriores são importantes. Após uma atualização controlada pela Central, a fila de tarefas pode explicar por que uma alteração ainda não atingiu a firewall.

Por que apenas um backup não é suficiente

Um backup transferido reduz o risco, mas não resolve automaticamente todos os problemas de recuperação. Na prática, também é necessário:

• um local de armazenamento seguro fora da firewall
• uma atribuição clara à firewall, número de série, localização e versão do SFOS
• o Secure Storage Master Key (SSMK) apropriado
• a senha do backup, se o backup foi criptografado
• informações documentadas sobre WAN, VLAN, HA, VPN e licenças
• um plano de restauro verificado para substituição de hardware, recriação de imagem ou migração

Especialmente antes de uma atualização de firmware, uma reimagem USB ou uma verificação de atualização SFOS 22, o backup não deve apenas ser criado, mas também verificado tecnicamente.

Antes do primeiro backup: verifique Secure Storage Master Key

Antes de usar backups manuais ou agendados de forma produtiva, Secure Storage Master Key (SSMK) deve ser estabelecido e documentado com segurança. Sem esta chave, uma restauro para um novo dispositivo ou em determinados cenários de recuperação poderá falhar.

Isto é especialmente relevante quando:

• um firewall substituto está a ser preparado
• está prevista uma migração para outro modelo
• as configurações são movidas entre hardware, dispositivo virtual e nuvem
• os backups são armazenados fora da firewall

O SSMK deve estar em um gerenciador de senhas ou outro procedimento de recuperação seguro. Não deve ser conhecido apenas por uma pessoa. Se a chave for procurada apenas em caso de emergência, já terá sido perdido um tempo valioso de recuperação.

Importante: Os backups antigos ainda estão vinculados ao SSMK com o qual foram criados. Se a chave for alterada ou redefinida posteriormente, a nova chave não será suficiente para as cópias antigas. Por esse motivo, as versões anteriores do SSMK também devem ser documentadas com data, prazo de validade e firewall afetado. A alteração do SSMK não é uma limpeza casual, mas sim uma alteração relevante para recuperação.

Criar backup: manual e automático

O caminho em WebAdmin é:

Backup & Firmware > Backup & Restore

Backup manual antes de alterações

Para um backup imediato, utilize Backup Now. O backup não deve ficar apenas na pasta de transferências do navegador, mas deve ser armazenado de forma consciente.

Antes destes trabalhos, sempre deve ser criado um backup manual:

• Atualização de firmware ou hotfix com risco de reinicialização ou alteração de comportamento
• Reestruturação de Interface, VLAN, Encaminhamento, SD-WAN ou VPN
• Configurando HA, alterando funções de HA ou mantendo HA
• Quebrando alterações em NAT, WAF ou regras de firewall
• Reimagem, redefinição de fábrica ou substituição de hardware
• Migração de XG para XGS, de hardware para virtual ou de virtual para nuvem

Após o download, pelo menos a data, nome da firewall, número de série, versão SFOS e finalidade do backup devem ser documentados. Para alterações importantes, uma comparação com o Sophos Firewall Config Studio posteriormente ajuda a rastrear diferenças de configuração antes e depois da alteração.

Configurar backups automáticos

Para garantir que os backups não sejam esquecidos, um backup automático deve ser configurado. No Frequency é possível definir backups diários, semanais ou mensais.

Os backups gerados automaticamente podem ser armazenados localmente na firewall, em um servidor FTP ou por e-mail. O importante não é tanto o local de armazenamento, mas o processo em torno dele:

• Qualquer pessoa que armazene backups via e-mail ou em um servidor externo deve verificar a criptografia e a proteção de acesso.
• Backups locais na firewall não ajudam se o dispositivo precisar ser substituído ou completamente reinstalado.
• Na própria firewall apenas a última cópia local ainda é relevante. Quem deve preservar os estados anteriores deve transferi-los conscientemente ou protegê-los externamente.
• Em backups de FTP ou e-mail, não basta verificar a configuração. A entrega, recuperação, licenças e rastreabilidade também devem ser comprovadas.
• Os backups centrais são convenientes, mas não devem ser o único caminho de recuperação conhecido.
• Os backups automáticos não substituem um backup manual logo antes de alterações arriscadas.
• Backups antigos devem ser gerenciados com período de retenção, processo de acesso e exclusão. Em backups FTP e Backup prefix, não se devem usar caracteres especiais complexos sem teste. A Sophos tem restrições para prefixo, nome de utilizador e palavra-passe. Depois da configuração, o que conta não é a definição gravada, mas um teste real de backup, download e restore.

Se a firewall estiver ligado ao Sophos Central, o armazenamento central de backup de configuração também pode ser útil. A ligação com a Central está descrita no artigo Conectar Sophos Firewall com Sophos Central.

Classificar corretamente Central Backups

Sophos Central pode planear backups de configuração da firewall, criá-los imediatamente, descarregá-los e disponibilizá-los para um restore posterior. O caminho em Central é:

My Products > Firewall Management > Backup

Os Central Backups são úteis porque não ficam na própria firewall e entram no Account Health Check. Ainda assim, este caminho de backup precisa de operação consciente:

• A frequência global de backup em Sophos Central começa como Never. Ao configurar manualmente por Schedule Backup, a UI pode mostrar outro valor sugerido. Quando uma firewall é adicionada automaticamente como a primeira ao agendamento de backup, Sophos Central define a frequência uma única vez para Monthly, com início no primeiro dia do mês. Se uma firewall não aparecer no agendamento apesar de Send configuration backup to Sophos Central estar ativo, use Schedule Backup > Add new firewall; em alternativa, remova a seleção, Apply, selecione novamente, Apply e depois execute accept-services em Sophos Central.
• Os Central Backups agendados correm às 08:00 no fuso horário da região Sophos Central. Esta hora não pode ser ajustada.
• Sophos Central tenta criar o backup até cinco vezes. Se continuar a falhar depois disso, é criado um alert e enviado um e-mail ao administrador de Central.
• Central mantém os cinco backups mais recentes. Um backup pode ainda ser guardado permanentemente até ser substituído ou eliminado.
• Ao descarregar a partir de Central, o backup é re-encrypted com uma nova palavra-passe. Esta palavra-passe também passa a fazer parte do procedimento de recovery.
• Se uma firewall for removida de Sophos Central Management, a Sophos também remove os ficheiros de Central Backup associados. Antes de mudar de conta, limpar tenants ou tratar um RMA, os backups necessários devem ser descarregados.
• Em clusters HA, Primary e Auxiliary são incluídos no agendamento de backup, mas o backup é criado pelo Primary.

Central Backup é assim um bom caminho adicional de recovery, mas não substitui restore local, SSMK, acesso admin e documentação do site.

Armazene backups com segurança

Os backups de firewall contêm informações confidenciais sobre estrutura de rede, objetos, regras, serviços, VPNs, certificados e, em alguns casos, dados de contas protegidas. Portanto, devem ser tratados como ficheiros de infraestrutura confidenciais.

Para operação, estas regras são úteis:

• Não armazene ficheiros de backup não criptografados em pastas gerais do computador.
• Limite o acesso aos backups da firewall para administradores e gerentes de recuperação.
• Documente a senha de backup e o SSMK separadamente, mas de maneira rastreável.
• Use uma convenção de nomenclatura clara por local ou firewall.
• Após a saída do administrador, verifique se o armazenamento de backup e o acesso ao gerenciador de senhas ainda são adequados.
• Documente separadamente informações relevantes para a restauro, como dados de acesso WAN, PPPoE, dados estáticos do provedor ou mapeamento de porta HA.

Uma cópia de segurança não substitui a documentação operacional. Especialmente em clusters HA, vários links WAN ou ambientes VPN complexos, também deve ser documentado quais interfaces, dados do provedor e dependências devem ser verificados primeiro após uma restauro.

Prepare um pacote de recuperação de firewall

Em caso de emergência, a maior parte do tempo não é desperdiçado carregando o ficheiro de backup, mas procurando informações adicionais. Portanto, para firewalls de produção, deve haver um pequeno pacote de recuperação por local ou cliente.

Este pacote deve incluir:

• Último backup verificado: base para restauro, migração ou recriação de imagem.
• Senha de backup e Secure Storage Master Key: Necessário para backups criptografados e dados protegidos.
• Número de série, modelo e versão do SFOS: importante para suporte, licenciamento e verificação de compatibilidade.
• Dados WAN e informações do provedor: necessário caso falte acesso à Internet ou ligação à Central após a restauro.
• Atribuição de interfaces e portas: decisivo nas migrações de XG para XGS, portas Flexi, troncos VLAN e HA.
• Administrador e Acesso Emergencial: Permite acesso local caso VPN, Central ou SSO ainda não esteja funcionando.
• Licenciamento e atribuição ao Central: evite confusão na substituição de hardware, firewalls virtuais ou instâncias de nuvem.
• Serviços críticos e testes de aceitação: Mostra rapidamente após a restauro se VPN, NAT, WAF, DNS, DHCP e o registo estão funcionando novamente.

Este pacote não deve ser um ficheiro de texto desprotegido junto com o backup. Uma combinação de gerenciador de senhas, documentação operacional interna e responsabilidade clara é melhor. Pelo menos duas pessoas autorizadas devem saber onde essas informações estão localizadas e como acessá-las em caso de emergência.

Após mudanças de pessoal, remodelação de local, mudança de fornecedor, mudança de HA ou grande migração, o pacote de recuperação deve ser revisto. Um backup formalmente atualizado ajuda pouco se o IP WAN documentado, mapeamento de porta ou mapeamento para Central não estiver mais correto.

Preparar a restauro

Antes de uma restauro, deve primeiro esclarecer qual é o objetivo. Uma restauro para o mesmo dispositivo após uma configuração incorreta é avaliada de forma diferente de uma restauro após uma nova imagem, substituição de hardware ou mudança de plataforma.

Preparação:

• Existe um backup recente do estado atual?
• O ficheiro de backup está claramente atribuído à firewall correto?
• A senha de backup e o SSMK estão disponíveis?
• A versão do SFOS no sistema de destino corresponde ao backup?
• O caminho de restauro foi aprovado para a versão de origem, versão de destino e plataforma de destino?
• Será restaurado em hardware idêntico, outro modelo, dispositivo virtual ou nuvem?
• O Assistente de Restauro de Backup aparecerá ou será realizada a atribuição automática de interface?
• O HA está envolvido ou um backup do HA será restaurado em um único dispositivo?
• Existe acesso de gestão local se WAN, VPN ou Central não funcionar imediatamente após a restauro?
• Já se sabe qual IP do WebAdmin permanecerá ativo após a restauro?
• Os fusos horários, os servidores NTP e as possíveis configurações manuais de data/hora estão documentados?

⚠️ Uma restauro substitui a configuração atual. Em um firewall de produção, um novo backup do estado atual deve ser criado antes da restauro, mesmo que a configuração atual esteja incorreta. Em caminhos de migração não suportados, a firewall poderá iniciar com as configuração de fábrica após uma confirmação. Este aviso não deve ser tratado como uma mensagem de restauro normal e confirmado.

O que uma restauro não resolve automaticamente

Uma restauro restaura a configuração, mas não substitui uma verificação operacional completa. Após a reinicialização, o IP de gestão, configuração da interface, Device Access, certificados, rotas e serviços da configuração restaurada são aplicados novamente. É por isso que WebAdmin pode estar disponível repentinamente em outro IP que não durante a primeira configuração da firewall substituto.

Além disso, estes pontos devem ser revistos conscientemente:

• Os valores manuais de data e hora não são totalmente restaurados ao estado operacional. O fuso horário, o NTP e a hora atual devem ser verificados após a restauro.
• Logs, relatórios e dados de monitorização externo não substituem um backup de configuração e devem ser salvos separadamente ou centralizados.
• Certificados, VPNs, ligação com a Central, destinos Syslog e notificações podem existir tecnicamente após uma restauro, mas falham devido ao tempo, DNS, encaminhamento ou plataforma de destino modificada.
• Uma restauro em outro hardware não resolve automaticamente as diferenças de porta e interface, técnica e operacionalmente. O mapeamento deve corresponder ao modelo de fiação e zona.
• O registo no Sophos Central só é mantido ao restaurar para a mesma firewall. Restaurar para outro hardware ou HA remove o registo da firewall no Sophos Central. Após a restauro, é necessário voltar a registá-la, e Security Heartbeat, Sophos ZTNA, Central Management, Central Backup, Central Reporting e a Task Queue devem ser verificados individualmente e reconfigurados se necessário. Em políticas de grupo, a pertença ao grupo também faz parte desta verificação.

Planeje teste de restauro sem risco de produção

Um teste de restauro é útil, mas não deve ser executado levianamente em um firewall de produção. O objetivo não é sobrescrever regularmente dispositivos de produção, mas sim verificar de forma verificável se os requisitos de recuperação mais importantes foram atendidos.

Um teste de restauro segura pode ter esta aparência dependendo do seu ambiente:

• Recupere o ficheiro de backup do armazenamento agendado.
• Verifique nome do ficheiro, data, nome da firewall, número de série e versão do SFOS.
• Controlo a senha de backup e SSMK no gerenciador de senhas.
• Execute a verificação de compatibilidade de restauro de backup para o modelo de destino planeado.
• Documente atribuição de interface e desvios de porta antes de uma migração.
• Verifique a versão de destino planeada em relação aos caminhos de atualização e restauro de backup suportados.
• Teste em um laboratório ou firewall substituto se o backup for aceito em princípio.
• Após uma restauro de teste, não deixe ligações produtivas VPN, acessos WAN ou ligações à Central ativas sem controlo.

Se não houver laboratório ou firewall substituto disponível, pelo menos um teste organizacional é possível: encontrar o backup, verificar o acesso, confirmar a senha/SSMK, avaliar a plataforma de destino com a Verificação de Compatibilidade e simular o processo no manual de recuperação. Isto não substitui uma restauro real, mas evita muitos problemas clássicos de emergência.

Para locais críticos, também deve ficar claro como a firewall será acedido novamente após uma nova imagem ou substituição de hardware: acesso local, porta de gestão, dados WAN, status da licença, mapeamento para Sophos Central e contacto no local. Esta informação pertence não apenas ao backup, mas também à documentação operacional separada.

Restaurar backup

A restauro também é realizada em:

Backup & Firmware > Backup & Restore

Procedimento básico:

1. Acesse a firewall de destino através de WebAdmin.
2. Salva o estado atual, se ainda for possível.
3. Em Restore configuration, selecione o ficheiro de backup com Choose file.
4. Se necessário, introduza Encryption password ou SSMK.
5. Inicie Upload and Restore.
6. Aguarde a reinicialização e restauro.
7. Abra WebAdmin usando o IP de gestão de configuração restaurado.
8. Verifique o fuso horário, NTP e hora atual.
9. Em seguida verifique rede, serviços, VPN, HA e ligação com Central.

Quando um Sophos Firewall novo ou de substituição é implantado, o backup pode ser aplicado após o primeiro acesso ao dispositivo. O endereço IP inicial e o primeiro acesso dependem do modelo e tipo de implantação. Em dispositivos de hardware, é comum o acesso local inicial por meio do IP de gestão padrão ou do assistente de configuração.

Assim que a firewall estiver acessível e o assistente de configuração for concluído, a restauro poderá ser realizada conforme descrito acima.

Restaurar para outro hardware ou plataformas

Principalmente em migrações entre XG e XGS ou entre hardware, dispositivo virtual e nuvem, deve-se verificar antes de restaurar se o backup é compatível. A Sophos oferece uma verificação pública de compatibilidade de restauro de backup para isso.

Além disso, a versão de destino deve ser apropriada. A Sophos distingue entre caminhos de atualização e restauro de backup aprovados e migrações não aprovadas. Se um firewall avisar antes de reiniciar que a migração planeada não é suportada, ela não deve simplesmente ser reconhecida. Após uma migração não aprovada confirmada, a firewall poderá iniciar com as configuração de fábrica, perdendo assim a configuração atual.

Para uma restauro produtiva, isso significa:

• primeira nota versão de origem, versão de destino, modelo de destino e plataforma
• traga a firewall de destino para uma versão suportada do SFOS antes da restauro
• execute a verificação de compatibilidade de restauro de backup para a combinação específica
• leve a sério e documente os avisos na caixa de diálogo de restauro ou atualização
• em caso de dúvida, teste primeiro em hardware substituto ou em um ambiente de teste

Assistente de restore de backup e mapeamento automático de interfaces

Se o Assistente de restore de backup aparece depende de condições concretas de versão e plataforma, não apenas de um backup “mais recente”:

• O backup vem de uma appliance (XG, SG com SFOS, XGS, virtual ou cloud) que executava SFOS 19.5 MR4 ou posterior.
• O restore é feito em SFOS 20.0 MR2 ou posterior.
• O restore é feito para uma série XGS, appliance virtual ou cloud.
• Num restore para série XG ou SG, o assistente não aparece.

O assistente ajuda a mapear interfaces quando um backup de XG, SG com SFOS ou XGS é restaurado para uma série XGS, appliance virtual ou firewall cloud. Isto é especialmente importante se a firewall de destino tiver menos portas, nomes de portas diferentes, variantes wireless ou módulos Flexi-Port.

Em backups de SFOS 19.5 MR3 ou anterior, bem como em qualquer restore para XG/SG, o assistente não está disponível. A firewall atribui então interfaces automaticamente. Isto é mais rápido, mas mais arriscado, porque a atribuição não é confirmada conscientemente no assistente. Após esse restore, interfaces, zonas, gateways, VLANs, HA-link, rotas SD-WAN, regras NAT e VPNs devem ser verificados com especial cuidado.

Os casos especiais mais importantes no mapeamento de interfaces:

Pseudo-portas indicam que ainda há uma decisão operacional de porta em aberto. Após o restore, devem ser verificadas, movidas para uma porta ativa ou removidas corretamente. Para remover uma, abra a pseudo-porta em Network > Interfaces, defina a zone como None e reinicie a firewall. Pseudo-portas não vinculadas com configuração VLAN não são eliminadas automaticamente e requerem limpeza adicional.

Outros pontos a esclarecer após o restore:

Se o mapeamento de porta for diferente, um mapeamento de interface geralmente precisará ser verificado ou ajustado após a restauro. Antes das migrações de XG para XGS, o artigo Qual a diferença entre um firewall XG e XGS? também é relevante.

Após grandes trabalhos de restauro ou migração, uma comparação de configuração pode ajudar. Usar Sophos Firewall Config Studio mostra como comparar backups antes e depois de uma alteração e verificar especificamente diferenças inesperadas.

Firewalls cloud e virtuais

Em firewalls virtuais e cloud, a restauro não resolve automaticamente todos os temas da plataforma. Interfaces virtuais, security groups, routing cloud, IPs públicos, NAT upstream, licenciamento, consola cloud e arranque do appliance continuam a depender do ambiente de destino.

Antes de uma restauro em cloud ou virtualização, deve-se verificar:

• plataforma de destino e versão SFOS suportadas
• atribuição de interfaces e ordem das NICs
• endereços IP públicos e privados
• security groups, route tables e NAT da plataforma
• acesso de emergência pela consola da plataforma

Um backup de firewall restaura a configuração da Sophos Firewall. Não restaura automaticamente a infraestrutura envolvente do hypervisor ou do cloud provider.

Verificação após restauro

Após a restauro, não se deve apenas verificar se WebAdmin está acessível. A firewall pode estar acessível e ainda assim processar serviços importantes incorretamente.

Verifique diretamente após a restauro:

• IP de WebAdmin, redes de gestão permitidas e Device Access.
• Interfaces, zonas, VLANs, bridges, LAGs e interfaces de alias.
• Links WAN, PPPoE, dados estáticos do provedor e gateway padrão.
• SD-WAN rotas, rotas estáticas e encaminhamento dinâmico.
• Regras de firewall, regras NAT, regras WAF e ordem de regras.
• IPsec, SSL VPN, Sophos Connect, RED e Remote Access.
• Certificados, certificados CA, certificado WebAdmin e inspeção TLS.
• DNS, DHCP, NTP, fuso horário e servidores de autenticação.
• Status de HA, caso seja utilizado cluster.
• Status da licença, atualizações de padrões, hotfixes e sincronização com Sophos Central.
• Logging, alvos Syslog, relatórios de firewall central e relatórios locais.

Para verificação técnica, Log Viewer, Policy Test e Packet Capture, Packet Capture em WebAdmin e Serviços e Registos ajudam dependendo do problema.

Teste de aceitação após uma restauro

Uma restauro só estará completa quando as funções operacionais mais importantes forem confirmadas com testes reais. Um WebAdmin acessível apenas demonstra que a firewall está funcionando. Não mostra que o encaminhamento, NAT, VPN, WAF, autenticação ou registo estão funcionando corretamente novamente.

Para firewalls de produção, deve haver uma breve matriz de aceitação. Esta matriz não precisa ser complicada, mas deve estabelecer por local qual teste deve ser realizado após uma restauro e quem documenta o resultado.

Testes obrigatórios úteis:

• Gestão: Abra WebAdmin na rede de gestão e tente um segundo acesso de administrador. Espera-se que o acesso funcione apenas em redes permitidas.
• Acesso à Internet: Um cliente de teste em LAN ou cliente VLAN acede alvos externos definidos. A regra de firewall correta, a regra NAT e a rota WAN devem ser aplicadas.
• DNS e DHCP: o cliente recebe endereço e resolve nomes internos e externos. Faixa DHCP, Servidor DNS e As rotas DNS de solicitação devem corresponder.
• Site-to-Site VPN: Um host definido pelo local é alcançado em ambas as direções. As regras de túnel, encaminhamento e firewall devem corresponder.
• Remote Access: Um utilizador de teste define SSL VPN, IPsec ou Sophos Connect. Login, MFA, perfil, DNS e alvos internos devem funcionar.
• WAF ou DNAT: O serviço publicado é testado externamente. Certificado, regra, backend e registo devem se encaixar.
• Autenticação: teste AD, LDAP, RADIUS, STAS ou Insira SSO com utilizador de teste. O utilizador deve ser reconhecido e corresponder à regra esperada.
• Registo: verifique Log Viewer, Syslog, Central Reporting ou SIEM. O tráfego de restauro e teste deve ser visível de maneira rastreável.
• HA: verifique o status, as funções e a sincronização do cluster. Primário e Auxiliar devem estar no estado esperado.

Um ponto de interrupção definido é importante. Se testes básicos como WAN, DNS, Remote Access ou HA não funcionarem após uma restauro, não se deve corrigir muitas áreas ao mesmo tempo. Um caso de bug restrito com tempo, origem de teste, destino, regra afetada e extração de log é o melhor. Isso o mantém rastreável, independentemente de o problema ser proveniente do backup, do mapeamento da interface, do hardware de destino ou de uma alteração posterior.

Erros típicos

• O backup é apenas local na firewall: em caso de defeito de hardware ou reimagem ele não fica acessível. Os backups devem ser armazenados externamente e de forma segura.
• SSMK não documentado: A restauro de dados protegidos pode falhar ou demorar muito mais. O SSMK pertence ao procedimento de recuperação.
• SSMK antigo após alteração de chave não está mais acessível: Cópias antigas não podem mais ser descriptografadas. Versões anteriores do SSMK devem ser mantidas documentadas com período e referência à firewall.
• Backup sem versão ou referência de dispositivo: O ficheiro errado foi aplicado. O nome da firewall, número de série, versão SFOS e data pertencem à documentação de backup.
• Nenhum backup do estado atual antes da restauro: falta caminho de volta ao estado atual. Antes de uma restauro produtiva, um novo backup deve ser criado.
• IP do WebAdmin restaurado desconhecido: após a restauro a firewall aparece offline, embora esteja em outro IP. Planeje com antecedência o gestão de backup IP e o acesso local.
• Tempo e NTP não verificados após restauro: VPN, certificados, autenticação ou ligação com Central podem se comportar incorretamente. Verifique o fuso horário, NTP e hora atual diretamente após a restauro.
• Caminho de restauro não aprovado confirmado: A firewall inicia com as configuração de fábrica ou a restauro falha de forma incerta. Versão de destino, versão de origem e verificação de compatibilidade devem ser verificadas antes.
• Mapeamento de portas não verificado: As interfaces terminam incorretamente após a migração. Prepare a verificação de compatibilidade e atribuição de interface.
• Atribuição automática de interface aceita sem verificação: WAN, VLAN, VPN ou link HA são deixados em portas incorretas. Após a restauro, compare cada interface com a fiação e o modelo de zona.
• Contexto HA ignorado: O cluster não inicia corretamente ou a função errada está ativada. Planeje funções HA, status de firmware e ordem de restauro.
• Apenas WebAdmin é verificado: Os problemas de VPN, NAT, WAF ou DNS permanecem não detectados. Após a restauro, é necessária uma comprovação real dos serviços.

Lista de verificação operacional

Regularmente:

• Habilite backups automáticos ou defina um processo de backup central.
• Verifique o armazenamento, acesso e retenção de backup.
• Controlo SSMK e backup de senha no gerenciador de senhas.
• Mantenha o pacote de recuperação atualizado por local ou firewall.
• Verifique pelo menos aleatoriamente se as cópias de backup são localizáveis e atribuíveis.

Antes de grandes mudanças:

• Crie backup manual e armazene externamente.
• Documente o nome da firewall, número de série, versão do SFOS e finalidade da alteração.
• Verifique SSMK, senha de backup e acesso de administrador.
• Estabelecer plano de reversão ou restauro.
• Nas migrações, verificar Verificação de Compatibilidade e atribuição de interface.
• Não reconheça avisos sobre caminhos de restauro ou migração não suportados antes de ter um plano alternativo.

Após uma restauro:

• IP de controlo de WebAdmin, redes de gestão e Device Access.
• Interfaces de teste, encaminhamento, NAT, VPN, WAF, autenticação e Central.
• Verifique o fuso horário, NTP e hora atual.
• Matriz de aceitação completa com fontes de teste reais, objetivos de teste e registos esperados.
• Verifique o status e as funções de HA.
• Verifique logs e monitorização.
• Nas versões de destino a partir de SFOS 22.0 MR1, verifique novamente para ver se uma restauro ou importação retornou configurações antigas de Legacy Remote Access IPsec.
• Crie um novo backup do estado de destino restaurado.
• Documente os desvios e, se necessário, compare com o Config Studio.

Perguntas frequentes