Creare o ripristinare un backup di Sophos Firewall

Un backup di Sophos Firewall è più di un semplice file per le emergenze. È la base per aggiornamenti firmware, sostituzione hardware, migrazioni da XG a XGS, reimage, operazioni HA e processi di recupero puliti. Se il backup, il Secure Storage Master Key e la compatibilità di ripristino non sono preparati, un cambiamento pianificato può rapidamente trasformarsi in un’interruzione inutilmente lunga.

L’articolo spiega come creare e ripristinare backup di Sophos Firewall, quali informazioni aggiuntive dovrebbero essere documentate e quali verifiche sono importanti prima di un ripristino su altro hardware o piattaforme.

⚠️ Importante: Un backup è utile solo se è rintracciabile, decriptabile e compatibile con l’ambiente di destinazione. Prima di aggiornamenti firmware, reimage, modifiche HA o migrazioni, è necessario verificare consapevolmente file di backup, password del backup, Secure Storage Master Key, versione di destinazione, accesso management e processo di restore.

Video guida

Il video mostra backup e restore su Sophos Firewall e integra le indicazioni pratiche di recovery dell’articolo.

Qual è il percorso di recupero adatto?

Backup e ripristino sono spesso solo una parte del problema. A seconda della situazione, è più sensato un altro processo:

Pianificare un aggiornamento firmware: Aggiornamento firmware Sophos Firewall: preparazione e best practices.
Installare un’immagine firmware nel WebAdmin: Eseguire l’aggiornamento firmware di Sophos Firewall.
Aggiornamento Central o policy di gruppo bloccata: Verificare la coda delle attività di gestione firewall di Sophos Central.
Reinstallare completamente il sistema operativo del firewall: Reinstallare Sophos Firewall OS: reimage con chiavetta USB.
Guasto hardware, errore ripetuto o RMA: Aprire un ticket di supporto Sophos: preparazione e portale.
Ripristinare o modificare un cluster HA: Varianti di cluster HA di Sophos Firewall.

Nella pratica, questi processi si sovrappongono. Prima di un reimage è quasi sempre necessario un backup. Prima di un caso di supporto, sono importanti numero di serie, versione firmware, log e passaggi precedenti. Dopo un aggiornamento gestito da Central, la coda delle attività può spiegare perché una modifica non è ancora arrivata sul firewall.

Perché un backup da solo non basta

Un backup scaricato riduce il rischio, ma non risolve automaticamente ogni problema di recupero. Nella pratica, è necessario anche:

un luogo di archiviazione sicuro al di fuori del firewall
una chiara associazione a firewall, numero di serie, posizione e versione SFOS
il giusto Secure Storage Master Key (SSMK)
la password del backup, se il backup è stato crittografato
informazioni documentate su WAN, VLAN, HA, VPN e licenze
un piano di ripristino verificato per sostituzione hardware, reimage o migrazione

Soprattutto prima di un aggiornamento firmware, un reimage tramite chiavetta USB o un controllo di aggiornamento SFOS 22, il backup non dovrebbe solo essere creato, ma anche verificato tecnicamente.

Prima del primo backup: verificare il Secure Storage Master Key

Prima di utilizzare backup manuali o pianificati in produzione, il Secure Storage Master Key (SSMK) dovrebbe essere impostato e documentato in sicurezza. Senza questa chiave, un restore su un nuovo dispositivo o in determinati scenari di recupero può fallire.

Questo è particolarmente rilevante quando:

si prepara un firewall di ricambio
è pianificata una migrazione su un altro modello
le configurazioni vengono spostate tra hardware, appliance virtuali e cloud
i backup vengono archiviati al di fuori del firewall

L’SSMK dovrebbe essere conservato in un gestore di password o in un altro metodo di recupero sicuro. Non dovrebbe essere noto solo a una singola persona. Se la chiave viene cercata solo in caso di emergenza, si perde già tempo prezioso per il recupero.

Importante: i backup più vecchi restano legati all’SSMK con cui sono stati creati. Se la chiave viene modificata o reimpostata in seguito, la nuova chiave non basta per questi vecchi backup. Per questo anche le versioni SSMK precedenti dovrebbero essere documentate con data, periodo di validità e firewall interessato. Un cambio SSMK non è una pulizia occasionale, ma una modifica rilevante per il recovery.

Creare un backup: manuale e automatico

Il percorso WebAdmin è:

Backup & Firmware > Backup & Restore

Creare un backup della configurazione SFOS — Sophos Firewall Backup & Restore: creare un backup manuale e configurare backup pianificati

Backup manuale prima delle modifiche

Per un backup immediato, utilizzare Backup Now. Il backup non dovrebbe rimanere solo nella cartella di download del browser, ma essere archiviato consapevolmente.

Prima di queste operazioni, dovrebbe sempre essere creato un backup manuale:

Aggiornamento firmware o hotfix con rischio di riavvio o cambiamento di comportamento
Modifica di interfacce, VLAN, routing, SD-WAN o VPN
Configurazione HA, cambio di ruolo HA o manutenzione HA
Modifiche significative a NAT, WAF o regole firewall
Reimage, reset di fabbrica o sostituzione hardware
Migrazione da XG a XGS, da hardware a virtuale o da virtuale a cloud

Dopo il download, si dovrebbe documentare almeno la data, il nome del firewall, il numero di serie, la versione SFOS e lo scopo del backup. Per modifiche significative, un confronto successivo con Sophos Firewall Config Studio può aiutare a comprendere le differenze di configurazione prima e dopo il cambiamento.

Configurare backup automatici

Per evitare di dimenticare i backup, dovrebbe essere configurato un backup automatico. Sotto Frequency è possibile definire backup giornalieri, settimanali o mensili.

I backup generati automaticamente possono essere archiviati localmente sul firewall, su un server FTP o inviati via e-mail. La cosa importante non è tanto il luogo di archiviazione quanto il processo intorno:

Chi archivia i backup via e-mail o su un server esterno dovrebbe verificare crittografia e protezione dell’accesso.
I backup locali sul firewall non aiutano se l’appliance deve essere completamente sostituita o reinstallata.
Sul firewall stesso resta rilevante solo l’ultimo backup locale. Chi deve mantenere stati più vecchi dovrebbe scaricarli consapevolmente o salvarli esternamente.
Per backup FTP o via e-mail non basta verificare l’impostazione. Vanno testati anche consegna, recupero, autorizzazioni e reperibilità.
I backup Central sono pratici, ma non dovrebbero essere l’unico percorso di recupero noto.
I backup automatici non sostituiscono un backup manuale direttamente prima di modifiche rischiose.
I vecchi backup dovrebbero essere gestiti con un periodo di conservazione, accesso e processo di eliminazione.

Se il firewall è collegato a Sophos Central, anche l’archiviazione centralizzata dei backup di configurazione può essere utile. Il collegamento Central è descritto nell’articolo Collegare Sophos Firewall a Sophos Central.

Conservare il backup in sicurezza

I backup del firewall contengono informazioni sensibili sulla struttura della rete, oggetti, regole, servizi, VPN, certificati e, in parte, dati di account protetti. Pertanto, dovrebbero essere trattati come file di infrastruttura riservati.

Per l’operatività, queste regole sono sensate:

Non archiviare file di backup non crittografati in cartelle di team generali.
Limitare l’accesso ai backup del firewall agli amministratori e ai responsabili del recupero.
Documentare separatamente, ma in modo rintracciabile, la password del backup e l’SSMK.
Utilizzare una convenzione di denominazione chiara per ogni sede o firewall.
Dopo l’uscita di un amministratore, verificare se l’archiviazione dei backup e l’accesso al gestore di password sono ancora adeguati.
Documentare separatamente le informazioni rilevanti per il ripristino come dati di accesso WAN, PPPoE, dati statici del provider o assegnazione delle porte HA.

Un backup non sostituisce la documentazione operativa. Soprattutto in cluster HA, con più uplink WAN o ambienti VPN complessi, dovrebbe essere documentato anche quali interfacce, dati del provider e dipendenze devono essere verificate per prime dopo un ripristino.

Preparare un pacchetto di recupero per ogni firewall

In caso di emergenza, si perde la maggior parte del tempo non nel caricamento del file di backup, ma nella ricerca delle informazioni aggiuntive. Per i firewall produttivi, dovrebbe quindi esistere un piccolo pacchetto di recupero per ogni sede o cliente.

In questo pacchetto rientrano:

Ultimo backup verificato: base per restore, migrazione o reimage.
Password del backup e Secure Storage Master Key: necessari per backup crittografati e dati protetti.
Numero di serie, modello e versione SFOS: importanti per supporto, licenze e verifica di compatibilità.
Dati WAN e informazioni del provider: necessari se dopo il restore mancano accesso a Internet o collegamento Central.
Assegnazione interfacce e porte: cruciale per migrazioni da XG a XGS, Flexi-Ports, trunk VLAN e HA.
Accesso admin e break-glass: consente accesso locale se VPN, Central o SSO non funzionano ancora.
Licenze e assegnazione Central: evita confusioni con hardware di ricambio, firewall virtuali o istanze cloud.
Servizi critici e test di accettazione: mostra rapidamente dopo il restore se VPN, NAT, WAF, DNS, DHCP e logging funzionano di nuovo.

Questo pacchetto non dovrebbe essere una semplice file di testo non protetto accanto al backup. Meglio è una combinazione di gestore di password, documentazione operativa interna e chiara responsabilità. Almeno due persone autorizzate dovrebbero sapere dove si trovano queste informazioni e come accedervi in caso di emergenza.

Dopo un cambio di personale, una ristrutturazione della sede, un cambio di provider, una modifica HA o una grande migrazione, il pacchetto di recupero dovrebbe essere verificato. Un backup formalmente aggiornato è di poco aiuto se l’IP WAN documentato, l’assegnazione delle porte o l’assegnazione Central non sono più corretti.

Preparare il ripristino

Prima di un ripristino, dovrebbe essere chiarito quale obiettivo si intende raggiungere. Un ripristino sulla stessa appliance dopo una configurazione errata è diverso da un ripristino dopo reimage, sostituzione hardware o cambio di piattaforma.

Preparazione:

È disponibile un backup recente dello stato attuale?
Il file di backup è chiaramente associato al firewall corretto?
Sono disponibili la password del backup e l’SSMK?
La versione SFOS del sistema di destinazione è compatibile con il backup?
Il percorso di ripristino è approvato per versione sorgente, versione di destinazione e piattaforma di destinazione?
Si ripristina su hardware identico, altro modello, appliance virtuale o cloud?
Apparirà l’Assistant di ripristino del backup o avverrà una mappatura automatica delle interfacce?
È coinvolto HA o si ripristina un backup HA su un’appliance singola?
È disponibile un accesso di gestione locale se WAN, VPN o Central non funzionano immediatamente dopo il ripristino?
È noto quale IP WebAdmin sarà attivo dopo il restore?
Sono documentati fuso orario, server NTP ed eventuali impostazioni manuali di data/ora?

⚠️ Un ripristino sovrascrive la configurazione attuale. Su un firewall produttivo, si dovrebbe creare un nuovo backup dello stato attuale prima del ripristino, anche se la configurazione attuale è errata. In percorsi di migrazione non supportati, il firewall può avviarsi con configurazione di fabbrica dopo una conferma. Questo avviso non deve essere trattato come un normale messaggio di ripristino e confermato.

Cosa non risolve automaticamente un restore

Un restore ripristina la configurazione, ma non sostituisce un controllo operativo completo. Dopo il riavvio valgono di nuovo IP di management, configurazione interfacce, Device Access, certificati, rotte e servizi dalla configurazione ripristinata. Per questo WebAdmin può essere improvvisamente raggiungibile su un IP diverso rispetto alla prima configurazione del firewall sostitutivo.

Inoltre, questi punti vanno verificati consapevolmente:

Valori manuali di data e ora non vengono ripristinati completamente come stato operativo. Fuso orario, NTP e ora attuale dovrebbero essere controllati dopo il restore.
Log, report e dati di monitoraggio esterni non sostituiscono un backup di configurazione e dovrebbero essere salvati separatamente o centralmente.
Certificati, VPN, collegamento Central, destinazioni Syslog e notifiche possono esistere tecnicamente dopo un restore, ma non funzionare correttamente per motivi di ora, DNS, routing o piattaforma di destinazione modificata.
Un restore su altro hardware non risolve automaticamente differenze di porte e interfacce dal punto di vista operativo. Il mapping deve adattarsi al cablaggio e al modello di zone.

Pianificare un test di ripristino senza rischi per la produzione

Un test di ripristino è utile, ma non dovrebbe essere eseguito con leggerezza su un firewall produttivo. L’obiettivo non è sovrascrivere regolarmente le appliance produttive, ma verificare in modo dimostrabile se le principali condizioni di recupero funzionano.

Un test di ripristino sicuro può apparire così a seconda dell’ambiente:

Recuperare il file di backup dall’archiviazione pianificata.
Verificare nome file, data, nome firewall, numero di serie e versione SFOS.
Controllare la password del backup e l’SSMK nel gestore di password.
Eseguire il controllo di compatibilità del ripristino del backup per il modello di destinazione pianificato.
Documentare la mappatura delle interfacce e le deviazioni delle porte prima di una migrazione.
Verificare la versione di destinazione pianificata rispetto ai percorsi di aggiornamento e ripristino del backup supportati.
Testare su un firewall di laboratorio o di ricambio se il backup viene accettato in linea di massima.
Dopo un test di ripristino, non lasciare attivi in modo incontrollato VPN, accessi WAN o collegamenti Central produttivi.

Se non è disponibile un firewall di laboratorio o di ricambio, è possibile almeno un test organizzativo: trovare il backup, verificare l’accesso, confermare password/SSMK, valutare la piattaforma di destinazione con il controllo di compatibilità e simulare il processo nel manuale di recupero. Questo non sostituisce un vero ripristino, ma previene molti problemi classici di emergenza.

Per sedi critiche, dovrebbe essere chiaro anche come il firewall sarà nuovamente accessibile dopo un reimage o una sostituzione hardware: accesso locale, porta di gestione, dati WAN, stato delle licenze, assegnazione Sophos Central e contatti in loco. Queste informazioni non dovrebbero essere solo nel backup, ma in una documentazione operativa separata.

Ripristinare il backup

Il ripristino avviene anche sotto:

Backup & Firmware > Backup & Restore

Procedura di base:

Raggiungere il firewall di destinazione tramite WebAdmin.
Salvare lo stato attuale, se ancora possibile.
Selezionare il file di backup.
Avviare Upload and Restore.
Se necessario, inserire la password del backup o l’SSMK.
Attendere il riavvio e il ripristino.
Aprire WebAdmin tramite l’IP di management della configurazione ripristinata.
Controllare fuso orario, NTP e ora attuale.
Successivamente, verificare rete, servizi, VPN, HA e collegamento Central.

Quando viene distribuito un nuovo Sophos Firewall o uno sostituito, il backup può essere caricato dopo il primo accesso all’appliance. L’indirizzo IP iniziale e il primo accesso dipendono dal modello e dal tipo di distribuzione. Per le appliance hardware, l’accesso iniziale locale tramite l’IP di gestione standard o il wizard di configurazione è comune.

Una volta che il firewall è raggiungibile e il wizard di configurazione è completato, il ripristino può essere eseguito come descritto sopra.

Ripristino su altro hardware o altre piattaforme

Soprattutto nelle migrazioni tra XG e XGS o tra hardware, appliance virtuali e cloud, dovrebbe essere verificato prima del ripristino se il backup è compatibile. Sophos offre un controllo di compatibilità del ripristino del backup pubblico per questo.

Inoltre, la versione di destinazione deve essere adeguata. Sophos distingue tra percorsi di aggiornamento e ripristino del backup approvati e migrazioni non approvate. Se un firewall avverte prima del riavvio che la migrazione pianificata non è supportata, non si dovrebbe semplicemente confermare. Dopo una migrazione confermata e non approvata, il firewall può avviarsi con configurazione di fabbrica, perdendo così la configurazione attuale.

Per un ripristino produttivo, significa:

annotare prima versione sorgente, versione di destinazione, modello di destinazione e piattaforma
portare il firewall di destinazione su una versione SFOS supportata prima del ripristino
eseguire il controllo di compatibilità del ripristino del backup per la combinazione specifica
prendere sul serio e documentare gli avvisi nel dialogo di ripristino o aggiornamento
in caso di incertezza, testare prima su hardware di ricambio o in un ambiente di test

Assistant di ripristino del backup e mappatura automatica delle interfacce

Nei backup delle versioni SFOS più recenti, a seconda della piattaforma di destinazione, appare l’Assistant di ripristino del backup. Aiuta nell’assegnazione delle interfacce quando un backup viene ripristinato da XG, SG con SFOS o XGS su una serie XGS, appliance virtuale o firewall cloud. Questo è particolarmente importante se il firewall di destinazione ha meno porte, nomi di porte diversi, varianti wireless o moduli Flexi-Port.

Nei backup molto vecchi, l’assistente può mancare. In tal caso, il firewall assegna automaticamente le interfacce. Questo è più veloce, ma più rischioso, poiché l’assegnazione non viene confermata consapevolmente nell’assistente. Dopo un tale ripristino, le interfacce, le zone, i gateway, i VLAN, i collegamenti HA, le rotte SD-WAN, le regole NAT e le VPN devono essere verificate con particolare attenzione.

Inoltre, si dovrebbe prestare attenzione a:

Le porte disponibili e i tipi di zona corrispondono alla piattaforma di destinazione?
Le interfacce devono essere riassegnate dopo il ripristino?
Si ripristina un backup HA su un’appliance singola o viceversa?
Il sistema di destinazione è aggiornato a livello di firmware?
Un vecchio appliance XG o SG deve essere sostituito a causa del ciclo di vita o della compatibilità SFOS-22?
Lo stato delle licenze, il numero di serie e l’assegnazione Sophos Central sono chiariti dopo il ripristino?

Se l’assegnazione delle porte differisce, dopo il ripristino è spesso necessario verificare o rielaborare una mappatura delle interfacce. Prima delle migrazioni da XG a XGS, è rilevante anche l’articolo Qual è la differenza tra un firewall XG e XGS?.

Dopo lavori di ripristino o migrazione significativi, un confronto delle configurazioni può aiutare. Utilizzare Sophos Firewall Config Studio mostra come confrontare i backup prima e dopo un cambiamento e verificare differenze inaspettate.

Verificare dopo il ripristino

Dopo il ripristino, non si dovrebbe solo controllare se il WebAdmin è raggiungibile. Il firewall può essere raggiungibile e comunque elaborare in modo errato servizi importanti.

Verificare immediatamente dopo il ripristino:

IP WebAdmin, reti di management consentite e Device Access.
Interfacce, zone, VLAN, bridge, LAG e alias delle interfacce.
Uplink WAN, PPPoE, dati statici del provider e gateway predefinito.
Rotte SD-WAN, rotte statiche e routing dinamico.
Regole firewall, regole NAT, regole WAF e ordine delle regole.
IPsec, SSL VPN, Sophos Connect, RED e accesso remoto.
Certificati, certificati CA, certificato WebAdmin e ispezione TLS.
DNS, DHCP, NTP, fuso orario e server di autenticazione.
Stato HA, se viene utilizzato un cluster.
Stato delle licenze, aggiornamenti pattern, hotfix e sincronizzazione Sophos Central.
Logging, obiettivi Syslog, Central Firewall Reporting e report locali.

Per la verifica tecnica, a seconda del problema, aiutano Log Viewer, Policy Test e Packet Capture, Packet Capture nel WebAdmin e Servizi e log.

Test di accettazione dopo un ripristino

Un ripristino è completato solo quando le principali funzioni operative sono confermate con test reali. Un WebAdmin raggiungibile dimostra solo che il firewall è gestibile. Non dimostra che routing, NAT, VPN, WAF, autenticazione o logging funzionano di nuovo correttamente.

Per i firewall produttivi, dovrebbe quindi esserci una breve matrice di accettazione. Questa matrice non deve essere complicata, ma dovrebbe stabilire per ogni sede quale test deve essere eseguito obbligatoriamente dopo un ripristino e chi documenta il risultato.

Test obbligatori sensati sono:

Management: aprire WebAdmin dalla rete di management e testare un secondo accesso admin. Ci si aspetta che l’accesso funzioni solo da reti consentite.
Accesso a Internet: un client di test in LAN o Client-VLAN apre obiettivi esterni definiti. Devono matchare regola firewall, regola NAT e rotta WAN corrette.
DNS e DHCP: il client riceve un indirizzo e risolve nomi interni ed esterni. Range DHCP, server DNS e DNS Request Routes devono combaciare.
Site-to-Site VPN: un host definito per sede viene raggiunto in entrambe le direzioni. Tunnel, routing e regola firewall devono matchare.
Remote Access: un utente di test stabilisce SSL VPN, IPsec o Sophos Connect. Login, MFA, profilo, DNS e obiettivi interni devono funzionare.
WAF o DNAT: il servizio pubblicato viene testato dall’esterno. Certificato, regola, backend e logging devono combaciare.
Autenticazione: verificare AD, LDAP, RADIUS, STAS o Entra SSO con un utente di test. L’utente dovrebbe essere riconosciuto e incontrare la regola attesa.
Logging: controllare Log Viewer, Syslog, Central Reporting o SIEM. Restore e traffico di test dovrebbero essere visibili in modo tracciabile.
HA: verificare stato del cluster, ruoli e sincronizzazione. Primary e Auxiliary dovrebbero essere nello stato atteso.

È importante avere un punto di interruzione definito. Se dopo un ripristino test fondamentali come WAN, DNS, accesso remoto o HA non funzionano, non si dovrebbe correggere parallelamente in molti punti. Meglio è un caso di errore stretto con orario, fonte del test, obiettivo, regola interessata e estratto del log. In questo modo, rimane tracciabile se il problema deriva dal backup, dalla mappatura delle interfacce, dall’hardware di destinazione o da una modifica successiva.

Errori tipici

Il backup è solo localmente sul firewall: in caso di guasto hardware o reimage non è raggiungibile. I backup dovrebbero essere salvati esternamente e protetti.
SSMK non documentato: il restore di dati protetti può fallire o richiedere molto più tempo. L’SSMK appartiene al processo di recovery.
Vecchio SSMK dopo cambio chiave non più reperibile: i backup più vecchi non possono più essere decifrati. Le versioni SSMK precedenti dovrebbero restare documentate con periodo e riferimento al firewall.
Backup senza riferimento a versione o dispositivo: viene caricato il file sbagliato. Nome firewall, numero di serie, versione SFOS e data fanno parte della documentazione backup.
Nessun backup dello stato attuale prima del restore: manca il percorso di ritorno allo stato attuale. Prima di un restore produttivo dovrebbe essere creato un nuovo backup.
IP WebAdmin ripristinato non noto: dopo il restore il firewall sembra offline, anche se risponde su un altro IP. Pianificare prima IP di management dal backup e accesso locale.
Ora e NTP non controllati dopo il restore: VPN, certificati, autenticazione o collegamento Central possono comportarsi in modo errato. Controllare subito fuso orario, NTP e ora attuale.
Percorso di restore non approvato confermato: il firewall si avvia con configurazione di fabbrica o il restore fallisce in modo poco chiaro. Verificare versione target, versione sorgente e Compatibility Check prima del restore.
Port mapping non verificato: le interfacce finiscono su porte errate dopo la migrazione. Preparare Compatibility Check e mapping interfacce.
Mapping automatico delle interfacce accettato senza verifica: WAN, VLAN, VPN o HA-Link finiscono su porte sbagliate. Dopo il restore confrontare ogni interfaccia con cablaggio e modello di zone.
Contesto HA ignorato: il cluster non parte correttamente o diventa attivo il ruolo sbagliato. Pianificare ruoli HA, firmware e ordine di restore.
Solo WebAdmin verificato: problemi VPN, NAT, WAF o DNS restano nascosti. Dopo il restore servono veri test dei servizi.

Lista di controllo operativa

Regolarmente:

Attivare backup automatici o definire un processo di backup centralizzato.
Verificare archiviazione, accesso e conservazione dei backup.
Controllare SSMK e password del backup nel gestore di password.
Mantenere aggiornato il pacchetto di recupero per ogni sede o firewall.
Verificare almeno a campione se i backup sono rintracciabili e associabili.

Prima di modifiche significative:

Creare un backup manuale e archiviare esternamente.
Documentare nome firewall, numero di serie, versione SFOS e scopo del cambiamento.
Verificare SSMK, password del backup e accesso admin.
Stabilire un piano di rollback o ripristino.
In caso di migrazioni, verificare controllo di compatibilità e mappatura delle interfacce.
Non confermare avvisi su percorsi di ripristino o migrazione non supportati prima di avere un piano alternativo.

Dopo un ripristino:

Controllare IP WebAdmin, reti di management e Device Access.
Testare interfacce, routing, NAT, VPN, WAF, autenticazione e Central.
Verificare fuso orario, NTP e ora attuale.
Eseguire la matrice di accettazione con fonti di test reali, obiettivi di test e log attesi.
Controllare stato e ruoli HA.
Verificare log e monitoraggio.
Per versioni di destinazione da SFOS 22.0 MR1, verificare nuovamente se un ripristino o un import ha riportato configurazioni Legacy Remote Access IPsec vecchie.
Creare un nuovo backup dello stato di destinazione ripristinato.
Documentare le deviazioni e, se necessario, confrontarle con Config Studio.

FAQ

Con quale frequenza si dovrebbero creare backup di Sophos Firewall?

Per i firewall produttivi, un backup automatico è consigliabile. Inoltre, prima di ogni aggiornamento firmware, modifica di configurazione significativa, lavoro HA, migrazione o reimage, dovrebbe essere creato un backup manuale e archiviato esternamente.

Cos'è il Secure Storage Master Key?

Il Secure Storage Master Key protegge i dati sensibili memorizzati su Sophos Firewall ed è importante in determinati scenari di ripristino. Dovrebbe essere documentato in sicurezza, poiché un ripristino senza la chiave corretta può fallire o essere incompleto.

È possibile ripristinare un backup da XG a XGS?

Questo è possibile a seconda del modello, della versione SFOS e della situazione delle interfacce. Prima della migrazione, si dovrebbe utilizzare il controllo di compatibilità del ripristino del backup, scegliere la versione di destinazione appropriata e verificare attentamente la mappatura delle interfacce dopo il ripristino. Se il firewall avverte di un percorso di migrazione non supportato, non si dovrebbe semplicemente confermare.

Un backup Central è sufficiente come unico percorso di recupero?

I backup Central sono utili, ma non dovrebbero essere l’unico percorso di recupero pianificato. In caso di emergenza, deve essere chiaro come accedere al backup, chi è autorizzato e quali informazioni locali sono necessarie per il primo accesso al firewall.

È necessario creare un nuovo backup dopo un ripristino?

Sì, dopo un ripristino o una migrazione riuscita, dovrebbe essere creato un nuovo backup dello stato di destinazione. In questo modo, lo stato ripristinato e verificato è documentato correttamente.

Quali test sono più importanti dopo un ripristino di Sophos Firewall?

Per prima cosa, dovrebbero essere verificati accesso di gestione, WAN, DNS, DHCP, regole firewall centrali e i servizi VPN o WAF più importanti. Successivamente, seguono autenticazione, HA, logging, collegamento Central e monitoraggio. È fondamentale utilizzare fonti di test e obiettivi di test reali, non solo aprire il WebAdmin.