Konfiguracja Data Anonymization na Sophos Firewall

Funkcja Data anonymization szyfruje dane identyfikacyjne w logach i raportach Sophos Firewall. Obejmuje to w szczególności nazwy użytkowników oraz adresy IP, MAC i e-mail. Upoważniony administrator może ponownie wyświetlić te dane na potrzeby uzasadnionej analizy.

Bezpieczna procedura jest krótka:

1. Udokumentować cel, objęte nią dane wyjściowe i proces zatwierdzania.
2. Przygotować dwa indywidualne konta administratorów jako authorizerów.
3. Włączyć funkcję w System services > Data anonymization i wybrać obu authorizerów.
4. Za pomocą kontrolowanego zdarzenia testowego sprawdzić, czy Log viewer i wyszukiwanie nadal działają.
5. Celowo wyświetlić tożsamość za pomocą authorizera i przeprowadzić negatywny test nieautoryzowanego dostępu.
6. Dodawać wyjątki wyłącznie w uzasadnionych indywidualnych przypadkach.
7. Oddzielnie sprawdzić eksporty CSV i faktycznie wygenerowane raporty PDF.

⚠️ Data Anonymization nie usuwa danych i nie gwarantuje ochrony każdej zewnętrznej ścieżki danych. Remote Syslog, Sophos Central, CTR, pliki Advanced Shell i backupy są sprawdzane oddzielnie. Eksport można przekazać dopiero po skontrolowaniu konkretnego pliku pod kątem poufnych tożsamości.

Co chroni Data Anonymization

Sophos opisuje tę funkcję jako szyfrowanie tożsamości w logach i raportach. Wymienione są w szczególności:

• nazwy użytkowników;
• adresy IP;
• adresy MAC;
• adresy e-mail.

Ogranicza to niepotrzebne ujawnianie danych podczas codziennej analizy i raportowania. NOC może na przykład analizować problem według czasu, reguły i działania bez natychmiastowego wyświetlania każdej tożsamości użytkownika lub klienta. Kontrolowane ujawnienie pozostaje możliwe w uzasadnionym przypadku związanym z bezpieczeństwem lub ochroną danych.

Funkcja nie zastępuje jednak uprawnień dostępu, zasad retencji ani chronionego przesyłania. Zanonimizowany raport może nadal zawierać nazwy firewalli, adresy URL, nazwy reguł, znaczniki czasu i zdarzenia bezpieczeństwa. Te informacje również mogą być poufne.

Czego nie należy zakładać ogólnie

Aktualna pomoc Sophos potwierdza działanie w logach i raportach oraz możliwość wyświetlenia informacji w Log viewer. Nie opisuje jednak każdej możliwej ścieżki wyjściowej z taką samą szczegółowością. Dlatego ustawienie on-box nie jest automatycznie rozszerzane na następujące ścieżki danych:

• Remote Syslog lub SIEM;
• Sophos Central Firewall Reporting;
• Consolidated Troubleshooting Reports i pojedyncze logi pomocy technicznej;
• pliki w /log w Advanced Shell;
• backupy i eksporty konfiguracji;
• już wysłane wiadomości e-mail lub zapisane pliki PDF i CSV.

Remote Syslog nadal wymaga własnej procedury ochrony i odbioru opisanej w artykule Bezpieczne wysyłanie Syslog z Sophos Firewall do SIEM. Raporty centralne są sprawdzane oddzielnie zgodnie z opisem Sophos Central Firewall Reporting.

Przygotowanie authorizerów i zasady dwóch osób

Podczas włączania funkcji administratorzy są wybierani jako Authorizer. Ta rola może wyświetlać zanonimizowane tożsamości po ponownym uwierzytelnieniu. Sophos zaleca co najmniej dwóch authorizerów. Jeśli aktualnie zalogowany administrator jest również zarejestrowany jako authorizer, wymagana jest zgoda co najmniej jednego innego authorizera.

Dlatego przed aktywacją przygotowuje się dwa indywidualne konta, na przykład:

• privacy.authorizer1
• privacy.authorizer2

Te nazwy są przykładami i zastępuje się je dwoma kontami administratorów jednoznacznie przypisanymi do osób. Współdzielone konto zespołu byłoby nieodpowiednie, ponieważ ujawnienia, zatwierdzenia i późniejszej kontroli nie można byłoby przypisać do konkretnej osoby. Artykuł Bezpieczna konfiguracja administratorów i profili Device Access wyjaśnia tworzenie indywidualnych kont i ograniczonych profili.

Z wyprzedzeniem ustala się również:

• przypadki pomocy technicznej, bezpieczeństwa lub ochrony danych, w których ujawnienie jest dozwolone;
• kto zleca i zatwierdza analizę;
• jak dokumentowane są zgłoszenie, cel, okres i objęte analizą tożsamości;
• kiedy wyjątek wygasa i jest ponownie sprawdzany;
• który lokalny administrator odzyskiwania pozostaje dostępny, jeśli authorizer nie działa.

Aktywację należy przerwać, jeśli dostępny jest tylko jeden działający administrator albo drugi authorizer nie przeszedł jeszcze testu pozytywnego.

Włączanie Data Anonymization

1. Zalogować się do WebAdmin za pomocą indywidualnego konta administratora.
2. Otworzyć System services > Data anonymization.
3. Wybrać Enable data anonymization.
4. Wybrać co najmniej dwóch przygotowanych authorizerów.
5. Wybrać Apply.
6. Jeśli zalogowany administrator jest wybrany jako authorizer, udzielić z drugim authorizerem zgody wymaganej przez Sophos.
7. Ponownie załadować stronę i sprawdzić, czy aktywne ustawienie jest nadal widoczne.

Zmiany nie łączy się z modyfikacją profili administratorów, MFA ani miejsc docelowych logów. Pojedynczą zmianę łatwiej sprawdzić i wycofać.

Generowanie kontrolowanego zdarzenia testowego

W teście akceptacyjnym używa się znanego klienta pilotażowego, na przykład 10.20.30.25, oraz jednoznacznie przypisanego użytkownika testowego, takiego jak privacy.test. Prywatny adres IP jest przykładem. Należy zastąpić go rzeczywistym klientem pilotażowym z sieci zarządzającej lub testowej, aby wygenerowane zdarzenie można było jednoznacznie rozpoznać w lokalnym Log viewer.

Dla testu dokumentuje się czas, Source, Destination, usługę i oczekiwany Firewall Rule ID. Następnie klient pilotażowy generuje krótkie dozwolone połączenie, dla którego w regule jest włączone Log firewall traffic. Pozwala to odróżnić działającą anonimizację od braku pasującego zdarzenia.

Jeśli zdarzenie w ogóle się nie pojawia, najpierw należy sprawdzić normalną ścieżkę logowania. Pomaga w tym artykuł Prawidłowe przypisywanie usług i plików logów Sophos Firewall. Data Anonymization nie naprawia wyłączonego logowania reguł ani zatrzymanego Log viewer.

Testy pozytywne i negatywne w Log viewer

1. Otworzyć Log viewer i wybrać odpowiedni moduł.
2. Ograniczyć okres i filtry do udokumentowanego zdarzenia testowego.
3. Sprawdzić, czy pola użytkownika i adresu są wyświetlane w formie zanonimizowanej.
4. Przeprowadzić wyszukiwanie pełnotekstowe przy użyciu widocznych zanonimizowanych informacji. Sophos potwierdza, że wyszukiwanie działa również z zanonimizowanymi informacjami.
5. Jako zarejestrowany authorizer użyć przycisku Data anonymization i podać własne aktualne dane uwierzytelniające konta.
6. Sprawdzić, czy oczekiwana tożsamość staje się widoczna na potrzeby analizy.
7. Zamknąć autoryzowany widok i za pomocą testowego administratora, który nie jest authorizerem, sprawdzić, czy informacji nie można wyświetlić.

Pomyślny test authorizera potwierdza tylko tę konkretną ścieżkę WebAdmin. Nie dowodzi jeszcze, że PDF, CSV, Central, Syslog lub archiwa pomocy technicznej używają takiego samego sposobu prezentacji.

Dodawanie wyjątków tylko z uzasadnieniem

Wyjątek zapobiega szyfrowaniu wybranej tożsamości w logach i raportach. Można go zdefiniować dla użytkowników, adresów IP, adresów MAC lub adresów e-mail. Nie jest to wygodniejsza funkcja wyszukiwania, lecz świadome ujawnienie.

Uzasadnionym przypadkiem może być techniczna tożsamość usługi, którą zautomatyzowany proces operacyjny musi jednoznacznie rozróżniać w postaci jawnej. Nawet wtedy wyjątek wymaga:

• udokumentowanego celu;
• możliwie najmniejszego zakresu tożsamości;
• ownera;
• daty wygaśnięcia lub przeglądu;
• pozytywnego testu wyjątku i negatywnego testu tożsamości, która pozostaje zanonimizowana.

Udokumentowana procedura wygląda następująco:

1. Dodać konkretny wyjątek w System services > Data anonymization.
2. Wybrać Apply.
3. Wprowadzić nazwę użytkownika i hasło authorizera.
4. Wybrać Save.
5. Wygenerować nowe zdarzenie testowe i sprawdzić rzeczywisty sposób prezentacji.

Po pomyślnym uwierzytelnieniu wybrane tożsamości nie są szyfrowane. Szeroki zakres sieci, cała grupa użytkowników bez indywidualnego uzasadnienia ani stale otwarty wyjątek nie są używane jako ustawienie domyślne.

Rzeczywista kontrola plików PDF i CSV

Widok WebAdmin jest tylko częścią testu akceptacyjnego. Dane wyjściowe mogą być później przechowywane poza firewallem, wysyłane pocztą e-mail lub kopiowane do systemu zgłoszeń.

Kontrola zaplanowanego raportu PDF

W przypadku lokalnych raportów e-mail po aktywacji nie czeka się na kolejne regularne wykonanie. Harmonogram jest uruchamiany za pomocą Generate now, a faktycznie odebrany plik PDF zostaje sprawdzony. Artykuł Planowanie raportów Sophos Firewall i wysyłanie ich pocztą e-mail opisuje pełną procedurę wysyłki i weryfikacji.

Sprawdza się co najmniej następujące elementy:

• pola użytkownika, IP, MAC i e-mail;
• zamierzone wyjątki;
• adresy URL, nazwy reguł i inne poufne treści;
• odbiorców, transport poczty i retencję w skrzynce.

Plik PDF wygenerowany wcześniej nie staje się nowym dowodem akceptacyjnym po późniejszej zmianie ustawienia. Do testu generowany jest nowy plik.

Kontrola eksportu CSV z Log viewer

Log viewer może wyeksportować bieżący widok do pliku CSV. Aktualna pomoc Sophos potwierdza eksport, ale nie opisuje osobno zakresu anonimizacji pliku. Dlatego otwiera się niewielki eksport kontrolowanego zdarzenia testowego i sprawdza każde pole.

Ta ścieżka eksportu jest używana produkcyjnie dopiero wtedy, gdy zarówno zanonimizowane tożsamości, jak i zamierzone wyjątki są wyświetlane prawidłowo. Następnie plik jest bezpiecznie przechowywany lub usuwany. Nazwa pliku bez tożsamości nie wyklucza obecności poufnych danych w jego treści.

Weryfikacja HA i zewnętrznych ścieżek danych

W klastrze HA funkcja Data Anonymization jest sprawdzana ponownie po kontrolowanym failoverze. Na aktualnie aktywnym węźle generowana jest nowa sesja testowa i powtarzana jest procedura Log viewer. Istniejąca sesja WebAdmin lub test wykonany tylko na poprzednim Primary nie stanowią wystarczającego dowodu.

Remote Syslog, Central Reporting, CTR i logi Advanced Shell są traktowane jako oddzielne ścieżki danych:

1. Określić miejsce docelowe i odpowiedzialność.
2. Wygenerować kontrolowane zdarzenie testowe.
3. Sprawdzić faktycznie odebrane lub pobrane dane wyjściowe.
4. Udokumentować dostęp, retencję i bezpieczne usuwanie.

Jeśli zewnętrzna ścieżka danych nadal zawiera informacje jawne, nie ukrywa się tego szerokim wyjątkiem ani wyłączeniem lokalnego logowania. Zamiast tego wzmacnia się ochronę dostępu i transportu w danym systemie albo zatrzymuje eksport do czasu wyjaśnienia wymagań dotyczących ochrony danych.

Systematyczne zawężanie błędów

Tożsamości nadal są wyświetlane w postaci jawnej

Najpierw należy sprawdzić, czy Enable data anonymization jest nadal aktywne i czy widoczne zdarzenie zostało wygenerowane po ostatniej zmianie. Następnie kontroluje się wyjątki dla użytkowników oraz adresów IP, MAC i e-mail. Zdarzenie może zawierać kilka tożsamości; wyjątek dla Source IP nie wyjaśnia automatycznie widocznej nazwy użytkownika.

Następnie należy zresetować Log viewer, wygenerować nowe zdarzenie testowe i ponownie sprawdzić widok. Stare pliki PDF, pliki pobrane przez przeglądarkę lub zrzuty ekranu nie są wiarygodnym dowodem aktualnego ustawienia.

Authorizer nie może wyświetlić tożsamości

Należy sprawdzić, czy indywidualne konto jest rzeczywiście wybrane jako authorizer i czy używane są jego własne aktualne dane uwierzytelniające. Jeśli zalogowany administrator jest również authorizerem, trzeba zaplanować wymaganą zgodę innego authorizera.

Profili administratorów, MFA i źródła logowania nie zmienia się jednocześnie. Jeśli wyświetlenie nadal nie działa mimo prawidłowego wyboru i pomyślnego zwykłego logowania, należy udokumentować czas, przeglądarkę, konto i widoczny komunikat. Authorizerów nie usuwa się, dopóki nie będzie dostępna druga przetestowana ścieżka dostępu i droga odzyskiwania.

Plik PDF lub CSV różni się od Log viewer

Ścieżki są oceniane oddzielnie. Dla pliku PDF dokumentuje się typ raportu, czas generowania i Generate now. Dla pliku CSV zapisuje się moduł, filtry i czas eksportu. W przypadku Central, Syslog lub archiwów pomocy technicznej nie zakłada się lokalnej anonimizacji, lecz sprawdza rzeczywisty plik docelowy lub platformę.

Nie należy restartować usług raportowania lub logowania ani usuwać danych raportów tylko dlatego, że dane wyjściowe są przedstawiane inaczej. Najpierw tworzy się powtarzalny test z nowym plikiem.

Bezpieczne wycofanie zmiany

Poprzednie ustawienia są dokumentowane przed pilotażem. Jeśli nowa konfiguracja nie spełnia uzgodnionych wymagań operacyjnych, poprzedni stan zostaje przywrócony w System services > Data anonymization w ramach autoryzowanej zmiany. Następnie ponownie sprawdza się nowe zdarzenie logu, widok authorizera, eksport CSV i, w razie potrzeby, plik PDF.

Wyjątki są najpierw usuwane lub przywracane do wcześniejszego zakresu. Pliki już wyeksportowane nadal istnieją oddzielnie i muszą być obsługiwane zgodnie z obowiązującymi zasadami retencji i usuwania. Wycofanie ustawienia firewalla nie usuwa kopii ze skrzynek pocztowych, SIEM, zgłoszeń ani spraw pomocy technicznej.

Lista kontrolna eksploatacji

• udokumentowane cel, owner i proces zatwierdzania
• dwóch indywidualnych authorizerów przeszło test pozytywny
• lokalny administrator odzyskiwania jest dostępny
• Enable data anonymization jest aktywne i potwierdzone po ponownym załadowaniu
• kontrolowane zdarzenie logu jest widoczne w formie zanonimizowanej
• wyświetlenie przez authorizera powiodło się, a dostęp nieautoryzowany został odrzucony
• wyjątki są wąskie, uzasadnione i mają datę przeglądu
• sprawdzono nowy plik PDF i CSV z Log viewer
• Syslog, Central, CTR i logi shell oceniono oddzielnie
• failover HA zatwierdzono z nowym zdarzeniem
• już wyeksportowane pliki są chronione i obsługiwane zgodnie z retencją

Częste pytania

Czy Data Anonymization usuwa dane osobowe?

Nie. Sophos opisuje tę funkcję jako szyfrowanie tożsamości w logach i raportach. Upoważniony administrator może po uwierzytelnieniu ponownie wyświetlić te informacje. Nie jest to równoznaczne z usunięciem ani nieodwracalną anonimizacją.

Czy Remote Syslog i Sophos Central są automatycznie anonimizowane?

Aktualny opis funkcji nie potwierdza tego wprost dla tych ścieżek danych. Dlatego za pomocą kontrolowanego zdarzenia sprawdza się, co jest widoczne w rzeczywistym miejscu docelowym Syslog, w Central, w CTR lub w pobranym pliku.

Czy wystarczy jeden authorizer?

Interfejs umożliwia wskazanie jednego lub większej liczby authorizerów, ale Sophos zaleca co najmniej dwóch. Jeśli zalogowany administrator jest również authorizerem, do zatwierdzenia potrzebny jest co najmniej jeden inny authorizer. W celu ochrony przed blokadą stosuje się więc dwa indywidualne, przetestowane konta.