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 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 il doppio controllo

Quando si attiva la funzione, vengono selezionati amministratori come Authorizer. Questo ruolo può rendere visibili le identità anonimizzate dopo una nuova autenticazione. Sophos consiglia almeno due authorizer. Se l’amministratore connesso è registrato anche come authorizer, è richiesta l’approvazione di almeno un altro authorizer.

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.

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 amministratore funzionante o se il secondo authorizer non ha ancora superato un test positivo.

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, fornire con il secondo authorizer l’approvazione richiesta da Sophos.
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

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 informazioni non possano essere visualizzate.

Un test riuscito dell’authorizer dimostra solo questo specifico percorso WebAdmin. Non dimostra ancora che PDF, CSV, Central, 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.

Convalidare HA e i percorsi dati esterni

In un cluster HA, Data Anonymization viene controllato di nuovo dopo un failover controllato. Sul nodo ora attivo viene generata una nuova sessione di test e viene ripetuta la procedura di Log viewer. Una sessione WebAdmin esistente o un test eseguito solo sul precedente Primary non costituiscono una prova sufficiente.

Remote Syslog, Central 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.

Delimitare gli errori in modo sistematico

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 e che vengano utilizzate le proprie credenziali di autenticazione correnti. Se l’amministratore connesso è a sua volta un authorizer, viene pianificata l’approvazione necessaria di un altro authorizer.

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 Central, 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

Le impostazioni precedenti vengono documentate prima del test pilota. Se la nuova configurazione non soddisfa i requisiti operativi concordati, lo stato precedente viene ripristinato in System services > Data anonymization mediante una modifica autorizzata. Si controllano quindi un nuovo evento di log, la vista dell’authorizer, un export CSV e, se necessario, un PDF.

Le eccezioni vengono prima rimosse o riportate al loro ambito precedente. I file già esportati continuano a esistere separatamente e devono essere gestiti in base alle regole applicabili di conservazione ed eliminazione. Il rollback dell’impostazione del firewall 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, Central, CTR e log di shell valutati separatamente
• failover HA convalidato con un nuovo evento
• 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 Central 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 Central, 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, è necessario almeno un altro authorizer per l’approvazione. Per un funzionamento sicuro contro il lockout vengono quindi utilizzati due account personali e verificati.