Configurare Data Anonymization su Sophos Firewall

Data anonymization cifra le informazioni identificative nei log e nei report di Sophos Firewall. In particolare, sono inclusi nomi utente, indirizzi IP, indirizzi MAC e indirizzi e-mail. Un amministratore autorizzato può rendere nuovamente visibili queste informazioni per un’analisi legittima.

La procedura sicura è breve:

1. Documentare lo scopo, gli output interessati e il processo di approvazione.
2. Preparare due account amministratore personali come authorizer.
3. Attivare la funzione in System services > Data anonymization e selezionare entrambi gli authorizer.
4. Verificare con un evento di test controllato che Log viewer e la ricerca continuino a funzionare.
5. Rendere intenzionalmente visibile l’identità con un authorizer ed eseguire un test negativo dell’accesso non autorizzato.
6. Aggiungere eccezioni solo per singoli casi giustificati.
7. Controllare separatamente gli export CSV e i report PDF effettivamente generati.

⚠️ Data Anonymization non elimina i dati e non garantisce la protezione di ogni percorso dati esterno. Remote Syslog, Sophos Fusion (in precedenza Sophos Central), CTR, i file di Advanced Shell e i backup vengono controllati separatamente. Un export viene condiviso solo dopo aver verificato il file concreto per individuare identità sensibili.

Cosa protegge Data Anonymization

Sophos descrive la funzione come cifratura delle identità nei log e nei report. Sono indicati in modo esplicito:

• nomi utente;
• indirizzi IP;
• indirizzi MAC;
• indirizzi e-mail.

In questo modo si riduce l’esposizione non necessaria durante l’analisi quotidiana e il reporting. Un NOC può, ad esempio, analizzare un problema in base a orario, regola e azione senza vedere immediatamente ogni identità utente o client. Per un caso legittimo di sicurezza o protezione dei dati resta possibile una visualizzazione controllata.

La funzione non sostituisce comunque i diritti di accesso, le regole di conservazione o il trasporto protetto. Un report anonimizzato può ancora contenere nomi di firewall, URL, nomi di regole, timestamp ed eventi di sicurezza. Anche queste informazioni possono essere riservate.

Cosa non viene presupposto in modo generale

La guida Sophos attuale conferma l’effetto su log e report e la possibilità di visualizzare le informazioni in Log viewer. Tuttavia, non descrive ogni possibile percorso di output con lo stesso livello di dettaglio. L’impostazione on-box non viene quindi estesa automaticamente ai seguenti percorsi dati:

• Remote Syslog o SIEM;
• Sophos Central Firewall Reporting;
• Consolidated Troubleshooting Reports e singoli log di supporto;
• file in /log nella Advanced Shell;
• backup ed export di configurazione;
• e-mail già inviate o file PDF e CSV archiviati.

Remote Syslog continua a richiedere la procedura specifica di protezione e accettazione descritta in Inviare in sicurezza i Syslog di Sophos Firewall a un SIEM. I report centrali vengono verificati separatamente come descritto in Sophos Central Firewall Reporting.

Preparare gli authorizer e definire il confine di approvazione

Quando si attiva la funzione, vengono selezionati uno o più amministratori come Authorizer. Questa assegnazione autorizza la de-anonimizzazione; in Log viewer un authorizer deve fornire le proprie credenziali di autenticazione. Sophos consiglia almeno due authorizer. Se l’amministratore connesso è registrato anche come authorizer, Sophos richiede l’approvazione di almeno un altro authorizer.

Ne deriva un limite importante: ciò non dimostra un doppio controllo tecnico per ogni visualizzazione. La guida di SFOS 22.0 conferma in Log viewer soltanto autorizzazione e nuova autenticazione. Se la policy interna richiede due persone per ogni analisi, bisogna applicare anche tale processo organizzativo e verificarlo separatamente dall’autenticazione del prodotto.

Prima dell’attivazione vengono quindi preparati due account personali, ad esempio:

• privacy.authorizer1
• privacy.authorizer2

Questi nomi sono esempi e vengono sostituiti con due account amministratore chiaramente assegnati a persone. Un account condiviso dal team non sarebbe adatto, perché visualizzazione, approvazione e controllo successivo non potrebbero più essere attribuiti a una persona. Configurare in sicurezza amministratori e profili Device Access spiega come creare account personali e profili limitati.

Authorizer non è un profilo Device Access separato. I profili forniscono accesso basato sui ruoli a WebAdmin e API tramite None, Read-only o Read-write; un utente locale viene creato in Authentication > Users con tipo Administrator e un profilo. Sophos non indica un profilo minimo per Data Anonymization. Prima della modifica si verifica quindi che entrambi gli account previsti possano raggiungere davvero la pagina richiesta e Log viewer, senza attribuire un profilo non documentato.

Vengono inoltre definiti in anticipo i seguenti punti:

• i casi di supporto, sicurezza o protezione dei dati in cui è consentita la visualizzazione;
• chi richiede e approva l’analisi;
• come vengono documentati ticket, scopo, periodo e identità interessate;
• quando un’eccezione scade e viene nuovamente verificata;
• quale amministratore di ripristino locale resta disponibile se un authorizer non funziona.

L’attivazione viene interrotta se è disponibile un solo account amministratore funzionante o se il normale accesso WebAdmin del secondo authorizer previsto non è stato verificato con successo. La sua funzione di authorizer può essere testata solo dopo l’assegnazione.

Attivare Data Anonymization

1. Accedere a WebAdmin con un account amministratore personale.
2. Aprire System services > Data anonymization.
3. Selezionare Enable data anonymization.
4. Selezionare almeno i due authorizer preparati.
5. Selezionare Apply.
6. Se l’amministratore connesso è selezionato come authorizer, ottenere l’approvazione di almeno un altro authorizer quando l’interfaccia la richiede.
7. Ricaricare la pagina e verificare che l’impostazione attiva sia ancora visualizzata.

La modifica non viene combinata con modifiche ai profili amministratore, all’MFA o alle destinazioni dei log. Una singola modifica è più facile da verificare e ripristinare.

Generare un evento di test controllato

Il test di accettazione utilizza un client pilota noto, ad esempio 10.20.30.25, e un utente di test assegnato in modo univoco, come privacy.test. L’indirizzo IP privato è un esempio. Viene sostituito con un client pilota reale della rete di gestione o di test, in modo che l’evento generato possa essere riconosciuto chiaramente nel Log viewer locale.

Per il test vengono documentati orario, Source, Destination, servizio e Firewall Rule ID previsto. Il client pilota genera quindi una breve connessione consentita la cui regola ha Log firewall traffic attivo. In questo modo è possibile distinguere una funzione di anonimizzazione operativa dalla semplice assenza di un evento corrispondente.

Se l’evento è completamente assente, viene prima controllato il normale percorso di logging. Associare correttamente servizi e file di log di Sophos Firewall aiuta in questa verifica. Data Anonymization non ripara il logging delle regole disattivato né un Log viewer bloccato.

Eseguire test positivi e negativi in Log viewer

In SFOS 22.0, la vista si apre tramite Log viewer nell’angolo superiore destro di WebAdmin. In SFOS 23.0, questa voce si chiama Logs and policy test. Le verifiche seguenti si eseguono in Log viewer.

1. Aprire Log viewer e selezionare il modulo pertinente.
2. Limitare periodo e filtri all’evento di test documentato.
3. Verificare che i campi utente e indirizzo siano visualizzati in forma anonimizzata.
4. Eseguire una ricerca a testo libero utilizzando le informazioni anonimizzate visibili. Sophos conferma che la ricerca funziona anche con informazioni anonimizzate.
5. Come authorizer registrato, utilizzare il pulsante Data anonymization e inserire le proprie credenziali di autenticazione dell’account.
6. Verificare che l’identità prevista diventi visibile per l’analisi.
7. Chiudere la vista autorizzata e utilizzare un amministratore di test non registrato come authorizer per verificare che le identità non vengano divulgate. L’errore esatto può variare con le autorizzazioni; il test riesce soltanto se l’amministratore di test non ottiene identità in chiaro.

Un test riuscito dell’authorizer dimostra solo questo specifico percorso WebAdmin. Non dimostra ancora che PDF, CSV, Sophos Fusion, Syslog o gli archivi di supporto utilizzino la stessa rappresentazione.

Aggiungere eccezioni solo con una giustificazione

Un’eccezione impedisce che l’identità selezionata venga cifrata nei log e nei report. Può essere definita per utenti, indirizzi IP, indirizzi MAC o indirizzi e-mail. Non è una funzione di ricerca più comoda, ma una divulgazione deliberata.

Un caso giustificabile può essere un’identità di servizio tecnica che un processo operativo automatizzato deve distinguere in testo non cifrato. Anche in questo caso, l’eccezione richiede:

• uno scopo documentato;
• l’ambito di identità più ridotto possibile;
• un owner;
• una data di scadenza o revisione;
• un test positivo dell’eccezione e un test negativo di un’identità che resta anonimizzata.

La procedura documentata è:

1. Aggiungere l’eccezione specifica in System services > Data anonymization.
2. Selezionare Apply.
3. Inserire nome utente e password di un authorizer.
4. Selezionare Save.
5. Generare un nuovo evento di test e controllare la rappresentazione effettiva.

Dopo un’autenticazione riuscita, le identità selezionate non vengono cifrate. Un ampio intervallo di rete, un intero gruppo di utenti senza una giustificazione individuale o un’eccezione permanentemente aperta non vengono utilizzati come impostazione predefinita.

Controllare concretamente i file PDF e CSV

La vista WebAdmin è solo una parte del test di accettazione. Gli output possono in seguito essere archiviati fuori dal firewall, inviati per e-mail o copiati in un sistema di ticketing.

Controllare un report PDF pianificato

Per i report locali inviati per e-mail non si attende la successiva esecuzione regolare dopo l’attivazione. La pianificazione viene eseguita con Generate now e viene controllato il PDF effettivamente ricevuto. Pianificare i report di Sophos Firewall e inviarli per e-mail descrive l’intera procedura di invio e verifica.

Vengono controllati almeno i seguenti punti:

• campi utente, IP, MAC ed e-mail;
• eccezioni previste;
• URL, nomi di regole e altri contenuti sensibili;
• destinatari, trasporto e-mail e conservazione nella casella di posta.

Un PDF generato in precedenza non diventa una nuova prova di accettazione dopo una modifica successiva delle impostazioni. Per il test viene generato un nuovo file.

Controllare un export CSV di Log viewer

Log viewer può esportare la vista corrente in formato CSV. La guida Sophos attuale conferma l’export, ma non descrive separatamente l’ambito di anonimizzazione del file. Per questo motivo viene aperto un piccolo export dell’evento di test controllato e verificato campo per campo.

Questo percorso di export viene utilizzato in produzione solo quando sia le identità anonimizzate sia le eccezioni previste vengono visualizzate correttamente. Il file viene quindi archiviato in modo sicuro o eliminato. Un nome file privo di identità non impedisce al contenuto di includere dati sensibili.

Delimitare HA, backup e percorsi dati esterni

La pagina Data Anonymization di SFOS 22.0 non contiene affermazioni specifiche sulla sincronizzazione HA o sul contenuto dei backup. Nessuno dei due aspetti viene quindi presentato come garantito. In un cluster HA esistente, un nuovo evento di test dopo un failover pianificato è una verifica operativa utile, ma Sophos non lo documenta come prerequisito della funzione.

Sophos conferma in generale che un backup contiene l’intera configurazione del firewall ed è cifrato. Il ripristino sostituisce la configurazione corrente, elimina il backup memorizzato sul firewall e riavvia il firewall; ripristinando uno stato precedente si perdono le modifiche successive. Senza ulteriori prove, ciò non stabilisce come siano trattate le identità anonimizzate storiche. Dopo un ripristino si controllano di nuovo impostazione, authorizer, eccezioni e un nuovo evento di log.

Per i ripristini HA, il backup viene ripristinato sul Primary corrente e poi sincronizzato con l’Auxiliary; il riavvio avviene senza failover e causa downtime. Un backup privo di configurazione HA disattiva HA. Il ripristino di un backup non è quindi un rollback leggero della sola Data Anonymization.

Remote Syslog, Sophos Central Firewall Reporting, CTR e i log di Advanced Shell vengono trattati come percorsi dati distinti:

1. Definire destinazione e responsabilità.
2. Generare un evento di test controllato.
3. Controllare l’output effettivamente ricevuto o scaricato.
4. Documentare accesso, conservazione ed eliminazione sicura.

Se un percorso dati esterno contiene ancora testo non cifrato, ciò non viene nascosto con un’eccezione ampia o disattivando il logging locale. Si rafforzano invece l’accesso e il trasporto del sistema interessato oppure si interrompe l’export finché il requisito di protezione dei dati non è chiarito.

Risolvere sistematicamente i problemi

Le identità continuano a comparire in testo non cifrato

Innanzitutto si verifica che Enable data anonymization sia ancora attivo e che l’evento visibile sia stato generato dopo l’ultima modifica. Successivamente si controllano le eccezioni per utenti, indirizzi IP, MAC o e-mail. Un evento può contenere più identità; un’eccezione per la Source IP non spiega automaticamente un nome utente visibile.

Si ripristina quindi Log viewer, si genera un nuovo evento di test e si controlla nuovamente la vista. Vecchi PDF, download del browser o screenshot non sono prove affidabili dell’impostazione attuale.

Un authorizer non riesce a visualizzare un’identità

Verificare che l’account personale sia effettivamente selezionato come authorizer, che il profilo Device Access consenta l’accesso necessario e che vengano usate le credenziali correnti dell’account. Se l’amministratore connesso è anche authorizer, considerare l’approvazione di un altro authorizer descritta da Sophos; non presumere una seconda approvazione per ogni azione in Log viewer se l’interfaccia non la richiede.

Profili amministratore, MFA e fonte di accesso non vengono modificati contemporaneamente. Se la visualizzazione continua a non riuscire nonostante la selezione corretta e un normale accesso riuscito, vengono documentati orario, browser, account e messaggio visibile. Gli authorizer non vengono rimossi prima che siano disponibili un secondo accesso verificato e un percorso di ripristino.

Un file PDF o CSV differisce da Log viewer

I percorsi vengono valutati separatamente. Per il PDF vengono documentati tipo di report, momento di generazione e Generate now. Per il CSV vengono registrati modulo, filtri e momento dell’export. Per Sophos Fusion, Syslog o gli archivi di supporto non viene promessa l’anonimizzazione locale; si controlla il file di destinazione o la piattaforma effettiva.

I servizi di reporting o logging non vengono riavviati e i dati dei report non vengono eliminati solo perché un output viene presentato in modo diverso. Viene prima creato un test riproducibile con un nuovo file.

Eseguire un rollback sicuro

Prima del test pilota si registrano tre stati in System services > Data anonymization: Enable data anonymization, l’elenco degli authorizer e ogni eccezione. Se la modifica non soddisfa i requisiti concordati, si riportano esattamente questi valori allo stato registrato con una modifica autorizzata e si seleziona Apply. Un ripristino da backup sarebbe sproporzionato perché sostituisce la configurazione, riavvia il firewall e può interrompere HA.

Sophos non documenta una funzione Reset separata e non specifica se la disattivazione modifichi retroattivamente la visualizzazione delle identità già memorizzate. Il ritorno viene quindi verificato con un nuovo evento di log, la vista dell’authorizer, un export CSV e, se necessario, un PDF appena generato; non si fanno affermazioni sugli eventi storici senza controllarli.

Le eccezioni vengono riportate al loro ambito precedente. I file già esportati continuano a esistere separatamente e devono essere gestiti secondo le regole applicabili. Il rollback non rimuove le copie da caselle di posta, SIEM, ticket o casi di supporto.

Checklist operativa

• scopo, owner e processo di approvazione documentati
• due authorizer personali hanno superato un test positivo
• amministratore di ripristino locale disponibile
• Enable data anonymization attivo e confermato dopo il ricaricamento
• evento di log controllato visibile in forma anonimizzata
• visualizzazione dell’authorizer riuscita e accesso non autorizzato respinto
• eccezioni limitate, giustificate e con data di revisione
• nuovo PDF e CSV di Log viewer controllati
• Syslog, Sophos Fusion, CTR e log di shell valutati separatamente
• comportamento HA controllato con un nuovo evento se esiste un cluster
• authorizer ed eccezioni registrati prima di un ripristino; ripristino non usato come rollback standard
• file già esportati protetti e gestiti secondo la conservazione

Domande frequenti

Data Anonymization elimina i dati personali?

No. Sophos descrive la funzione come cifratura delle identità nei log e nei report. Un amministratore autorizzato può rendere nuovamente visibili le informazioni dopo l’autenticazione. Ciò non equivale all’eliminazione o a un’anonimizzazione irreversibile.

Remote Syslog e Sophos Fusion vengono anonimizzati automaticamente?

La descrizione attuale della funzione non lo conferma espressamente per questi percorsi dati. Viene quindi utilizzato un evento controllato per verificare cosa è visibile nella destinazione Syslog effettiva, in Sophos Fusion, nel CTR o in un file scaricato.

È sufficiente un solo authorizer?

L’interfaccia consente uno o più authorizer, ma Sophos ne consiglia almeno due. Se l’amministratore connesso è anche un authorizer, è richiesta l’approvazione di almeno un altro authorizer. La guida non dimostra però una seconda approvazione obbligatoria per ogni visualizzazione in Log viewer. Per un funzionamento resiliente si usano comunque due account personali e verificati.