Hoppa till innehållet
Avanet

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 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 tvåpersonskontroll

När funktionen aktiveras väljs administratörer som Authorizer. Den rollen kan visa anonymiserade identiteter efter en ny autentisering. Sophos rekommenderar minst två authorizers. Om den inloggade administratören själv är registrerad som authorizer krävs godkännande från minst en annan authorizer.

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.

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 en fungerande administratör är tillgänglig eller om den andra authorizern ännu inte har klarat ett positivt test.

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 den andra authorizern ge det godkännande som Sophos kräver.
  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 informationen inte kan visas.

Ett godkänt authorizertest bevisar endast denna specifika WebAdmin-väg. Det bevisar ännu inte att PDF, CSV, Central, 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.

Validera HA och externa datavägar

I ett HA-kluster kontrolleras Data Anonymization igen efter en kontrollerad failover. En ny testsession skapas på den nod som nu är aktiv och Log viewer-processen upprepas. En befintlig WebAdmin-session eller ett test som endast genomförts på den tidigare Primary är inte tillräckligt bevis.

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

Avgränsa fel 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 och att kontots egna aktuella autentiseringsuppgifter används. Om den inloggade administratören själv är authorizer planeras det nödvändiga godkännandet från en annan authorizer.

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

De tidigare inställningarna dokumenteras före piloten. Om den nya konfigurationen inte uppfyller de överenskomna driftskraven återställs det tidigare läget under System services > Data anonymization genom en behörig ändring. Därefter kontrolleras en ny logghändelse, authorizervyn, en CSV-export och vid behov en PDF.

Undantag tas först bort eller återställs till sin tidigare omfattning. Redan exporterade filer fortsätter att finnas separat och måste hanteras enligt gällande regler för lagring och radering. En återställning av brandväggsinstä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, Central, CTR och shell-loggar bedömda separat
  • HA-failover validerad med en ny händelse
  • 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 Central 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 Central, 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 minst en annan authorizer för godkännande. För en lockoutsäker drift används därför två personliga och testade konton.