Konfigurera Data Anonymization på Sophos Firewall

Data anonymization krypterar identifierande information i loggar och rapporter på Sophos Firewall. Det omfattar framför allt användarnamn, IP-adresser, MAC-adresser och e-postadresser. En behörig administratör kan visa informationen igen för en legitim analys.

Det säkra förfarandet är kort:

1. Dokumentera syfte, berörda utdata och godkännandeprocess.
2. Förbered två personliga administratörskonton som authorizers.
3. Aktivera funktionen under System services > Data anonymization och välj båda authorizers.
4. Verifiera med en kontrollerad testhändelse att Log viewer och sökningen fortfarande fungerar.
5. Visa avsiktligt identiteten med en authorizer och genomför ett negativt test av obehörig åtkomst.
6. Lägg endast till undantag för motiverade enskilda fall.
7. Kontrollera CSV-exporter och faktiskt genererade PDF-rapporter separat.

⚠️ Data Anonymization raderar inte data och garanterar inte skydd för alla externa datavägar. Remote Syslog, Sophos Fusion (tidigare Sophos Central), CTR, Advanced Shell-filer och backuper kontrolleras separat. En export delas först efter att den konkreta filen har kontrollerats för känsliga identiteter.

Vad Data Anonymization skyddar

Sophos beskriver funktionen som kryptering av identiteter i loggar och rapporter. Följande nämns uttryckligen:

• användarnamn;
• IP-adresser;
• MAC-adresser;
• e-postadresser.

Det minskar onödig exponering vid daglig analys och rapportering. Ett NOC kan exempelvis undersöka ett problem utifrån tid, regel och åtgärd utan att omedelbart se alla användar- eller klientidentiteter. Kontrollerad visning är fortfarande möjlig i ett legitimt säkerhets- eller dataskyddsärende.

Funktionen ersätter ändå inte åtkomsträttigheter, lagringsregler eller skyddad överföring. En anonymiserad rapport kan fortfarande innehålla brandväggsnamn, URL:er, regelnamn, tidsstämplar och säkerhetshändelser. Även den informationen kan vara konfidentiell.

Vad som inte förutsätts generellt

Den aktuella Sophos-hjälpen bekräftar effekten för loggar och rapporter samt möjligheten att visa information i Log viewer. Den beskriver däremot inte alla möjliga utdatavägar lika detaljerat. On-box-inställningen tillämpas därför inte automatiskt på följande datavägar:

• Remote Syslog eller SIEM;
• Sophos Central Firewall Reporting;
• Consolidated Troubleshooting Reports och enskilda supportloggar;
• filer under /log i Advanced Shell;
• backuper och konfigurationsexporter;
• redan skickade e-postmeddelanden eller sparade PDF- och CSV-filer.

Remote Syslog kräver fortfarande den separata skydds- och acceptansprocess som beskrivs i Skicka Sophos Firewall Syslog säkert till ett SIEM. Centrala rapporter kontrolleras separat enligt Sophos Central Firewall Reporting.

Förbered authorizers och fastställ godkännandegränsen

När funktionen aktiveras väljs en eller flera administratörer som Authorizer. Tilldelningen ger rätt att avanonymisera; i Log viewer måste en authorizer ange sina autentiseringsuppgifter. Sophos rekommenderar minst två authorizers. Om den inloggade administratören själv är registrerad som authorizer kräver Sophos godkännande från minst en annan authorizer.

Här finns en viktig gräns: detta visar inte tekniskt framtvingad tvåpersonskontroll vid varje visning. SFOS 22.0-hjälpen bekräftar i Log viewer bara behörighet och ny autentisering. Om den egna policyn kräver två personer för varje analys ska den organisatoriska processen också upprätthållas och valideras separat från produktens autentisering.

Därför förbereds två personliga konton före aktiveringen, exempelvis:

• privacy.authorizer1
• privacy.authorizer2

Namnen är exempel och ersätts med två administratörskonton som tydligt är tilldelade personer. Ett delat teamkonto är olämpligt eftersom visning, godkännande och efterföljande kontroll då inte längre kan knytas till en person. Konfigurera administratörer och Device Access-profiler säkert beskriver hur personliga konton och begränsade profiler skapas.

Authorizer är inte en separat Device Access-profil. Profiler ger rollbaserad åtkomst till WebAdmin och API med None, Read-only eller Read-write; en lokal användare skapas under Authentication > Users med typen Administrator och en profil. Sophos anger ingen minimiprofil för Data Anonymization. Kontrollera därför före ändringen att båda avsedda kontona faktiskt når den nödvändiga sidan och Log viewer, utan att tillskriva dem en odokumenterad profil.

Följande punkter fastställs också i förväg:

• i vilka support-, säkerhets- eller dataskyddsärenden visning är tillåten;
• vem som begär och godkänner analysen;
• hur ärende, syfte, period och berörda identiteter dokumenteras;
• när ett undantag löper ut och granskas på nytt;
• vilken lokal återställningsadministratör som finns kvar om en authorizer inte fungerar.

Aktiveringen stoppas om endast ett fungerande administratörskonto är tillgängligt eller om den normala WebAdmin-inloggningen för den andra avsedda authorizern inte har testats framgångsrikt. Authorizerfunktionen kan testas först efter tilldelningen.

Aktivera Data Anonymization

1. Logga in i WebAdmin med ett personligt administratörskonto.
2. Öppna System services > Data anonymization.
3. Välj Enable data anonymization.
4. Välj minst de två förberedda authorizers.
5. Välj Apply.
6. Om den inloggade administratören är vald som authorizer ska godkännande från minst en annan authorizer hämtas när gränssnittet begär det.
7. Läs in sidan på nytt och kontrollera att den aktiverade inställningen fortfarande visas.

Ändringen kombineras inte med ändringar av administratörsprofiler, MFA eller loggmål. En enskild ändring är enklare att kontrollera och återställa.

Skapa en kontrollerad testhändelse

Acceptanstestet använder en känd pilotklient, exempelvis 10.20.30.25, och en tydligt tilldelad testanvändare som privacy.test. Den privata IP-adressen är ett exempel. Den ersätts med en verklig pilotklient från management- eller testnätet så att den skapade händelsen entydigt kan identifieras i den lokala Log viewer.

Tid, Source, Destination, tjänst och förväntat Firewall Rule ID dokumenteras för testet. Pilotklienten skapar därefter en kort tillåten anslutning vars regel har Log firewall traffic aktiverat. På så sätt går det att skilja en fungerande anonymisering från att en matchande händelse helt enkelt saknas.

Om händelsen saknas helt kontrolleras först den normala loggningsvägen. Koppla Sophos Firewall-tjänster till rätt loggfiler hjälper med detta. Data Anonymization reparerar inte inaktiverad regelloggning eller en Log viewer som har stannat.

Genomför positiva och negativa tester i Log viewer

1. Öppna Log viewer och välj relevant modul.
2. Begränsa period och filter till den dokumenterade testhändelsen.
3. Kontrollera att användar- och adressfält visas anonymiserade.
4. Genomför en fritextsökning med den synliga anonymiserade informationen. Sophos bekräftar att sökningen även fungerar med anonymiserad information.
5. Som registrerad authorizer använder man knappen Data anonymization och anger kontots egna aktuella autentiseringsuppgifter.
6. Kontrollera att den förväntade identiteten blir synlig för analysen.
7. Stäng den behöriga vyn och använd en testadministratör som inte är registrerad som authorizer för att kontrollera att identiteter inte lämnas ut. Det exakta felet kan variera med behörigheten; testet lyckas endast om testadministratören inte får någon identitet i klartext.

Ett godkänt authorizertest bevisar endast denna specifika WebAdmin-väg. Det bevisar ännu inte att PDF, CSV, Sophos Fusion, Syslog eller supportarkiv använder samma visning.

Lägg endast till undantag med motivering

Ett undantag förhindrar att den valda identiteten krypteras i loggar och rapporter. Det kan definieras för användare, IP-adresser, MAC-adresser eller e-postadresser. Det är inte en bekvämare sökfunktion utan en avsiktlig exponering.

Ett försvarbart fall kan vara en teknisk tjänsteidentitet som en automatiserad driftsprocess måste kunna skilja ut i klartext. Även då behöver undantaget:

• ett dokumenterat syfte;
• minsta möjliga identitetsomfattning;
• en owner;
• ett utgångs- eller granskningsdatum;
• ett positivt test av undantaget och ett negativt test av en identitet som förblir anonymiserad.

Den dokumenterade proceduren är:

1. Lägg till det specifika undantaget under System services > Data anonymization.
2. Välj Apply.
3. Ange användarnamn och lösenord för en authorizer.
4. Välj Save.
5. Skapa en ny testhändelse och kontrollera den faktiska visningen.

Efter lyckad autentisering krypteras inte de valda identiteterna. Ett brett nätverksintervall, en hel användargrupp utan individuell motivering eller ett permanent öppet undantag används inte som standard.

Kontrollera PDF- och CSV-filer i praktiken

WebAdmin-vyn är bara en del av acceptanstestet. Utdata kan senare lagras utanför brandväggen, skickas via e-post eller kopieras till ett ärendesystem.

Kontrollera en schemalagd PDF-rapport

För lokala e-postrapporter väntar man inte till nästa ordinarie körning efter aktiveringen. Schemat körs med Generate now och den PDF som faktiskt tas emot granskas. Schemalägg Sophos Firewall-rapporter och skicka dem via e-post beskriver hela leverans- och valideringsprocessen.

Minst följande punkter kontrolleras:

• användar-, IP-, MAC- och e-postfält;
• avsedda undantag;
• URL:er, regelnamn och annat känsligt innehåll;
• mottagare, e-posttransport och lagring i brevlådan.

En PDF som skapats tidigare blir inte ett nytt acceptansbevis efter en senare inställningsändring. En ny fil skapas för testet.

Kontrollera en CSV-export från Log viewer

Log viewer kan exportera den aktuella vyn som CSV. Den aktuella Sophos-hjälpen bekräftar exporten men beskriver inte filens anonymiseringsomfattning separat. Därför öppnas en liten export av den kontrollerade testhändelsen och granskas fält för fält.

Denna exportväg används inte i produktion förrän både anonymiserade identiteter och avsedda undantag visas korrekt. Filen lagras därefter säkert eller raderas. Ett filnamn utan identitet hindrar inte att innehållet innehåller känsliga data.

Avgränsa HA, backuper och externa datavägar

SFOS 22.0-sidan om Data Anonymization innehåller inget funktionsspecifikt påstående om HA-synkronisering eller backupinnehåll. Därför framställs ingetdera som garanterat. I ett befintligt HA-kluster är en ny testhändelse efter en planerad failover ett användbart operationellt acceptanstest, men Sophos dokumenterar det inte som ett krav för funktionen.

Sophos bekräftar generellt att en backup innehåller hela brandväggskonfigurationen och är krypterad. En återställning ersätter den aktuella konfigurationen, raderar den backup som lagrats på brandväggen och startar om brandväggen; när ett äldre tillstånd återställs går senare ändringar förlorade. Utan ytterligare bevis fastställer detta inte hur historiska anonymiserade identiteter hanteras. Kontrollera därför inställning, authorizers, undantag och en ny logghändelse igen efter återställning.

Vid HA-återställning återställs backupen på aktuell Primary och synkroniseras sedan till Auxiliary; omstarten sker utan failover och orsakar downtime. En backup utan HA-konfiguration inaktiverar HA. En backupåterställning är därför inte en lätt rollback för enbart Data Anonymization.

Remote Syslog, Sophos Central Firewall Reporting, CTR och Advanced Shell-loggar behandlas som separata datavägar:

1. Fastställ mål och ansvar.
2. Skapa en kontrollerad testhändelse.
3. Kontrollera den utdata som faktiskt har tagits emot eller hämtats.
4. Dokumentera åtkomst, lagring och säker radering.

Om en extern dataväg fortfarande innehåller klartext döljs detta inte med ett brett undantag eller genom att stänga av lokal loggning. I stället förstärks åtkomst och transport för det berörda systemet, eller så stoppas exporten tills dataskyddskravet har klargjorts.

Felsök systematiskt

Identiteter visas fortfarande i klartext

Kontrollera först att Enable data anonymization fortfarande är aktivt och att den synliga händelsen skapades efter den senaste ändringen. Kontrollera därefter undantag för användare, IP-adresser, MAC-adresser och e-postadresser. En händelse kan innehålla flera identiteter; ett undantag för Source IP förklarar inte automatiskt ett synligt användarnamn.

Återställ därefter Log viewer, skapa en ny testhändelse och kontrollera vyn igen. Gamla PDF-filer, webbläsarhämtningar eller skärmbilder är inte tillförlitliga bevis för den aktuella inställningen.

En authorizer kan inte visa en identitet

Kontrollera att det personliga kontot faktiskt är valt som authorizer, att Device Access-profilen tillåter den nödvändiga åtkomsten och att kontots egna aktuella autentiseringsuppgifter används. Om den inloggade administratören själv är authorizer ska godkännandet från en annan authorizer som Sophos beskriver beaktas; förutsätt inte ytterligare ett andra godkännande för varje Log viewer-åtgärd om gränssnittet inte begär det.

Administratörsprofiler, MFA och inloggningskälla ändras inte samtidigt. Om visningen fortfarande misslyckas trots korrekt val och en lyckad normal inloggning dokumenteras tid, webbläsare, konto och synligt meddelande. Authorizers tas inte bort förrän en andra testad åtkomstväg och en återställningsväg finns tillgängliga.

En PDF- eller CSV-fil skiljer sig från Log viewer

Vägarna bedöms separat. För PDF dokumenteras rapporttyp, genereringstid och Generate now. För CSV registreras modul, filter och exporttid. För Sophos Fusion, Syslog eller supportarkiv utlovas inte lokal anonymisering; den faktiska målfilen eller plattformen kontrolleras.

Reporting- eller loggningstjänster startas inte om och rapportdata raderas inte enbart för att utdata visas annorlunda. Skapa först ett reproducerbart test med en ny fil.

Återställ säkert

Dokumentera tre tillstånd under System services > Data anonymization före piloten: Enable data anonymization, listan med authorizers och varje undantag. Om ändringen inte uppfyller kraven återställs exakt dessa värden till det dokumenterade tillståndet genom en behörig ändring och Apply väljs. En backupåterställning är oproportionerlig eftersom den ersätter konfigurationen, startar om brandväggen och kan avbryta HA.

Sophos dokumenterar ingen separat Reset-funktion och anger inte om inaktivering ändrar visningen av redan lagrade identiteter retroaktivt. Validera därför återgången med en ny logghändelse, authorizervyn, en CSV-export och vid behov en nygenererad PDF; gör inget påstående om historiska poster utan att granska dem.

Återställ undantag till sin tidigare omfattning. Redan exporterade filer fortsätter att finnas separat och måste hanteras enligt gällande regler. Återställning av inställningen tar inte bort kopior från brevlådor, SIEM, ärenden eller supportfall.

Checklista för drift

• syfte, owner och godkännandeprocess dokumenterade
• två personliga authorizers har klarat ett positivt test
• lokal återställningsadministratör tillgänglig
• Enable data anonymization aktivt och bekräftat efter omladdning
• kontrollerad logghändelse synlig i anonymiserad form
• visning med authorizer lyckades och obehörig åtkomst nekades
• undantag begränsade, motiverade och försedda med granskningsdatum
• ny PDF och CSV från Log viewer kontrollerade
• Syslog, Sophos Fusion, CTR och shell-loggar bedömda separat
• HA-beteende kontrollerat med en ny händelse när ett kluster finns
• authorizers och undantag dokumenterade före återställning; återställning inte använd som standardrollback
• redan exporterade filer skyddade och hanterade enligt lagringsreglerna

Vanliga frågor

Raderar Data Anonymization personuppgifter?

Nej. Sophos beskriver funktionen som kryptering av identiteter i loggar och rapporter. En behörig administratör kan göra informationen synlig igen efter autentisering. Det är inte samma sak som radering eller oåterkallelig anonymisering.

Anonymiseras Remote Syslog och Sophos Fusion automatiskt?

Den aktuella funktionsbeskrivningen bekräftar inte detta uttryckligen för dessa datavägar. Därför används en kontrollerad händelse för att kontrollera vad som är synligt på den faktiska Syslog-destinationen, i Sophos Fusion, i CTR eller i en hämtad fil.

Räcker en enda authorizer?

Gränssnittet tillåter en eller flera authorizers, men Sophos rekommenderar minst två. Om den inloggade administratören också är authorizer krävs godkännande från minst en annan authorizer. Hjälpen visar dock inte att ett andra godkännande är obligatoriskt för varje visning i Log viewer. Två personliga och testade konton används ändå för robust drift.