Sophos Mobile: bezpieczne planowanie reguł haseł i zasad zabezpieczeń systemu Windows
Przy konfigurowaniu zasad Windows w Sophos Mobile najważniejszy nie jest wybór najbardziej rygorystycznych ustawień, lecz pilotaż z możliwością odzyskania dostępu: potwierdź edycję i stan zarządzania urządzeniem, sprawdź dostępność odzyskiwania BitLocker przed ewentualnym ponownym uruchomieniem, zinwentaryzuj konta lokalne i dopiero wtedy przypisz dokładnie jedną zmianę do urządzenia testowego. Zasady Windows nie są zasadami Device Encryption w Sophos Fusion i nie zastępują procedury odzyskiwania BitLocker. Informacje o zarządzaniu kluczami i odzyskiwaniu znajdziesz w artykule Zarządzanie BitLocker za pomocą Sophos Fusion.
Przed pierwszym przypisaniem
- Platforma i zakres: Urządzenie docelowe musi rzeczywiście być komputerem z Windows zarządzanym przez Sophos Mobile; samo Sophos Endpoint Protection nie oznacza rejestracji MDM. Lista wymagań Sophos Mobile wymienia Windows 10/11 Enterprise, Education i Pro, ale nie Home; nie gwarantuje to działania każdej konfiguracji zasad na każdej wymienionej edycji czy kompilacji. Według Sophos Restrictions nie dotyczy Pro, a Device Guard nie dotyczy ani Pro, ani Windows w trybie S. Sprawdź edycję, wersję Windows, wymagania sprzętowe i obowiązujące ustawienia GPO/MDM na konkretnym urządzeniu; stara strona pomocy nie stanowi potwierdzenia aktualnej zgodności.
- Cykl wsparcia: Standardowe wsparcie Microsoft dla zwykłych edycji Windows 10 zakończyło się 14 października 2025 r.; wydania LTSC/LTSB oraz urządzenia uprawnione do Extended Security Updates (ESU), z aktywną rejestracją, wymagają osobnej weryfikacji według edycji i wersji. ESU nie przedłuża cyklu życia produktu Microsoft ani standardowego wsparcia, lecz przez ograniczony czas udostępnia aktualizacje zabezpieczeń uprawnionym i prawidłowo zarejestrowanym urządzeniom. Lista wymagań Sophos Mobile (wydanie 2026.38 z 21 września 2026 r.) nadal wymienia Windows 10 Enterprise/Education/Pro od wersji 20H2 oraz Windows 11 Enterprise/Education/Pro. Jest to lista platform Sophos, a nie gwarancja wsparcia Microsoft dla starszych kompilacji Windows 10 ani dowód działania każdej zasady Windows. Także w Windows 11 wsparcie zależy od wersji i edycji: na przykład 23H2 Pro nie otrzymuje już aktualizacji w ramach wsparcia Microsoft, podczas gdy dla 23H2 Enterprise/Education obowiązują inne terminy. Przed pilotażem sprawdź konkretną wersję w dokumentacji cyklu wsparcia Microsoft Release Health i przetestuj wybrane ustawienie właśnie na tym urządzeniu.
- Dostęp i możliwość wycofania zmiany: Zapewnij autoryzowany lokalny dostęp awaryjny, pomoc dostępną przy urządzeniu i okno serwisowe. Przy BitLocker zadbaj o możliwość pobrania zatwierdzoną procedurą klucza odzyskiwania pasującego do danego urządzenia i bieżącego protektora oraz sprawdź jego dostępność przed zmianą; sam istniejący lub nieaktualny wpis nie oznacza przetestowanej możliwości odzyskania dostępu. Najpierw ustal faktycznego administratora i miejsce przechowywania aktualnego klucza odzyskiwania BitLocker dla tego urządzenia (na przykład Fusion Device Encryption lub inny autoryzowany system zarządzania kluczami). Samo zarządzanie MDM przez Sophos Mobile nie dowodzi, że klucz jest zapisany w Fusion. Nie ujawniaj klucza używanego w środowisku produkcyjnym za pomocą Show Key wyłącznie po to, by potwierdzić gotowość. Udokumentuj istniejące wymagania dotyczące haseł i zasady GPO. W przypadku Device Guard sprawdź dodatkowo obecny stan VBS/Credential Guard oraz obsługę Secure Boot i DMA.
- Mała grupa pilotażowa: Nie przypisuj zasad od razu dużej grupie urządzeń. Udokumentuj stan wyjściowy, użytkowników objętych zmianą i oczekiwany widoczny efekt. Według Sophos dla zasad Windows nie ma uniwersalnej opcji cofnięcia Uninstall policy; ustawienia koryguje się przez aktualizację lub przypisanie innych zasad. Urządzenie wyrejestrowane lub niesynchronizujące się nie otrzyma takiej korekty niezawodnie i natychmiast.
Reguły haseł: unikaj restartów i blokowania kont
Konfiguracja Password policies obejmuje Maximum number of failed attempts, Time in minutes until the device is locked, Password history i Maximum password age in days.
Time in minutes until the device is locked określa, po ilu minutach bezczynności urządzenie zostanie zablokowane. Użytkownik może je samodzielnie odblokować. Ta blokada po okresie bezczynności nie jest progiem nieudanych prób logowania, który może spowodować ponowne uruchomienie z żądaniem odzyskiwania BitLocker. Maximum password age in days określa, po ilu dniach użytkownicy muszą zmienić hasło.
Password history określa liczbę wcześniej użytych haseł przechowywanych przez Sophos Mobile na potrzeby blokowania ich ponownego wykorzystania; nowe hasło nie może być równe żadnemu z nich. Sophos dopuszcza wartość 0 oznaczającą brak odpowiedniego ograniczenia dla liczby nieudanych prób, czasu blokady i maksymalnego wieku hasła. Nie jest to zalecenie wyłączenia wszystkich zabezpieczeń: dobierz wartości do modelu kont i możliwości odzyskania dostępu, a następnie przetestuj każdą z nich osobno. Ta zasada Mobile nie pozwala ustawić złożoności hasła (np. długości czy klas znaków); określa ją Windows, między innymi zależnie od typu konta. Nie traktuj historycznie udokumentowanych konkretnych parametrów złożoności jako uniwersalnych, aktualnych ustawień domyślnych Windows.
Jeśli dla danego konta odpowiednia zasada złożoności haseł Windows jest włączona i faktycznie obowiązuje, podczas tworzenia lub zmiany hasła mogą być również wykonywane sprawdzenia względem nazwy konta oraz części pełnej nazwy użytkownika lub nazwy wyświetlanej. To, czy i w jaki sposób takie sprawdzenia nazw mają zastosowanie, zależy od obowiązującej zasady i typu konta; ustal to dla objętych kont przed pilotażem. Nie wynika z tego ani uniwersalna reguła dotycząca dowolnych kolejnych znaków nazwy, ani potwierdzenie aktualnych wymagań dla kont Microsoft.
Przed włączeniem „Maximum number of failed attempts”: Sophos opisuje, że osiągnięcie progu na komputerze z Windows powoduje ponowne uruchomienie i wyświetlenie żądania odzyskiwania BitLocker. Microsoft doprecyzowuje działanie odpowiedniej reguły Windows MDM: na komputerze stacjonarnym dane nie są usuwane, lecz uruchamiana jest procedura odzyskiwania BitLocker; bez włączonego BitLocker nie można wyegzekwować tej reguły. Ustawionego progu nie traktuj więc ani jako mechanizmu usuwania danych, ani jako skutecznej ochrony urządzenia bez szyfrowania. Przed przypisaniem sprawdź na konkretnym urządzeniu stan BitLocker i rzeczywiście dostępny klucz odzyskiwania; nie wywołuj celowo błędnych prób logowania na urządzeniach produkcyjnych. Jeżeli oprócz użytkownika zarejestrowanego w Sophos Mobile istnieją inni użytkownicy lokalni i przynajmniej jeden z nich nie może zmienić swojego hasła, według Sophos tych zasad Password nie można przypisać. Uprawnienia kont sprawdź i skoryguj dopiero w odrębnym, zatwierdzonym kroku; nie rozszerzaj bez analizy uprawnień użytkowników ani nie usuwaj kont tylko po to, by wymusić zasadę.
Na początku pilotażu zinwentaryzuj konta i istniejące zasady, dobierz czas bezczynności i maksymalny wiek hasła do sposobu pracy oraz potwierdź gotowość do odzyskania dostępu przed ustawieniem progu nieudanych prób. Po przypisaniu sprawdź w trybie tylko do odczytu, które zasady przypisano urządzeniu i czy wybrany czas bezczynności oraz maksymalny wiek hasła zaczynają obowiązywać. Test progu nieudanych prób przeprowadzaj wyłącznie w zatwierdzonym, odizolowanym środowisku testowym z dostępnym kluczem odzyskiwania. Jeśli niespodziewanie pojawi się żądanie odzyskiwania BitLocker, nie ponawiaj prób ani nie zgaduj innych kluczy: dopasuj identyfikatory urządzenia i klucza, a następnie zastosuj autoryzowaną procedurę odzyskiwania systemu, który faktycznie zarządza kluczami; tylko jeśli Sophos Device Encryption przechowuje aktualny klucz, właściwa jest procedura odzyskiwania w Fusion.
Restrictions: wcześniej ustal konsekwencje każdego pola wyboru
Restrictions nie służy do ogólnego utwardzania edycji Pro: Sophos wyraźnie ją wyklucza. Konfiguracja obejmuje między innymi Forbid resetting the computer (blokuje reset zarówno przez ustawienia, jak i Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level i Forbid manual MDM unenrollment. Zwłaszcza blokada resetowania lub ręcznego wyrejestrowania z MDM może uniemożliwić zaplanowaną obsługę techniczną albo wycofanie urządzenia. Wybieraj tylko jedno uzasadnione ustawienie na zmianę pilotażową i sprawdzaj jego działanie na urządzeniu przed przypisaniem oraz po nim.
Forbid manual configuration w sekcji Wi-Fi to szczególny przypadek ryzyka: podczas stosowania ustawienia usuwane są profile skonfigurowane wcześniej przez użytkownika oraz profile Wi-Fi Sense. Wyłączenie tego pola nie odtworzy automatycznie usuniętych profili. Przed zmianą zapewnij inny, przetestowany sposób dostępu do zarządzania i sieci oraz udokumentowaną procedurę odtworzenia potrzebnych profili WLAN. Profile WLAN, certyfikaty i SCEP należą do osobnej procedury sieciowej i certyfikatowej dla Windows; bez potwierdzenia jej gotowości nie włączaj tutaj blokady WLAN.
Telemetry level na liście Sophos obejmuje poziomy Full, Enhanced, Basic i Security. Ich faktyczne działanie w Windows i dostępność zależą od aktualnej edycji i zasad Microsoft; lista Sophos nie dowodzi, że każdy poziom zadziała na każdym urządzeniu pilotażowym. Podobnie historyczne nazwy elementów interfejsu, takie jak Cortana czy Wi-Fi Sense, nie stanowią dowodu działania ustawienia w aktualnych wersjach Windows.
Device Guard: najpierw wybierz odwracalną ścieżkę
Konfiguracja Device Guard w Sophos może włączyć zabezpieczenia oparte na wirtualizacji (VBS) i Credential Guard. Turn on virtualization-based security (VBS) to osobne pole służące do włączania VBS; wybór w Credential Guard configuration jest od niego niezależny. Według Sophos ustawienia zostają zastosowane przy pierwszym uruchomieniu komputera z Windows po przypisaniu zasad. Przed przypisaniem sprawdź sprzęt i istniejące zasady GPO/MDM oraz zaplanuj kontrolowane ponowne uruchomienie.
W Platform security level Sophos rozróżnia dwie opcje:
- Secure Boot korzysta z funkcji ochrony obsługiwanych przez urządzenie. Bez jednostek zarządzania pamięcią wejścia/wyjścia (IOMMU) VBS używa funkcji Secure Boot w UEFI; z IOMMU używa Secure Boot z ochroną przed bezpośrednim dostępem do pamięci (DMA).
- Secure Boot and DMA protection wymaga Secure Boot z ochroną DMA. Jeśli urządzenie nie obsługuje ochrony DMA, wybranie tej opcji nie włączy VBS.
Weryfikacja wstępna przed przypisaniem Credential Guard: Tylko jeśli planujesz włączyć Credential Guard na urządzeniu pilotażowym, zinwentaryzuj faktycznie używane w danym środowisku ścieżki logowania i dostępu: WLAN lub przewodowe 802.1X, VPN (zwłaszcza PEAP/EAP-MSCHAPv2), logowanie jednokrotne przez NTLMv1, RDP/zdalne wsparcie z zapisanymi poświadczeniami Windows lub CredSSP oraz aplikacje korzystające z nieograniczonej delegacji Kerberos. Microsoft opisuje skutki dla uwierzytelniania: w przypadku MS-CHAP i NTLMv1 logowanie jednokrotne może przestać działać i może być konieczne ponowne ręczne zalogowanie; nie oznacza to całkowitego zablokowania tych protokołów. Uwierzytelnianie WLAN/VPN za pomocą certyfikatów nie jest przez to blokowane. Klient pulpitu zdalnego nie może przekazywać zapisanych poświadczeń Windows do hosta docelowego; CredSSP nie może już korzystać z zapisanych poświadczeń ani z poświadczeń logowania jednokrotnego, lecz poświadczenia jawnie wprowadzone przez użytkownika nadal mogą działać. Nieograniczona delegacja Kerberos zostaje natomiast zablokowana. Dodatkowe zależności sprawdzaj tylko wtedy, gdy faktycznie występują w pilotażu: Ustal z osobami odpowiedzialnymi za tożsamość i aplikacje, czy potrzebne jest Kerberos PKINIT z RSA zamiast Diffie-Hellman lub Kerberos DES: Credential Guard blokuje PKINIT z RSA i DES; ponowne wpisanie hasła nie rozwiązuje tych problemów. Zinwentaryzuj również używane niestandardowe albo niepochodzące od Microsoft Security Support Providers/Authentication Packages (SSP/AP) oraz aplikacje odczytujące zapisane poświadczenia Windows: takie integracje mogą przestać działać, szczególnie jeśli wymagają skrótów haseł LSA lub nieobsługiwanych interfejsów. Dla ścieżek, których to faktycznie dotyczy, przed przypisaniem uzgodnij zgodne rozwiązanie alternatywne i reprezentatywny test funkcjonalny; jeśli krytyczna ścieżka pozostaje niewyjaśniona, nie przypisuj Credential Guard. Oceniaj tylko ścieżki rzeczywiście istotne dla wybranego urządzenia, wspólnie z odpowiedzialnymi za tożsamość i sieć; przed restartem zapewnij niezależnie przetestowany dostęp administracyjny lub do lokalnej konsoli oraz zatwierdzoną ścieżkę wycofania zmiany bez blokady UEFI. Jeśli zwykłe połączenie sieciowe albo zdalne wsparcie jest jedyną możliwością dostępu, nie przypisuj jeszcze Credential Guard.
Jeżeli pilotaż wymaga zdalnego wycofania ustawienia, odpowiednim wyborem jest Credential Guard configuration: Turn on without lock: Sophos wskazuje tu Turn off lub zasady grupy Windows jako sposób wycofania. Turn on with UEFI lock nie może być planowane jako odwracalny zdalnie przełącznik. Według Sophos wyłączenie wymaga fizycznej obecności przy komputerze; Microsoft opisuje osobną procedurę EFI/uruchamiania z potwierdzeniem przed startem systemu. Nie włączaj tego trybu bez przygotowanej wprost lokalnej procedury wycofania. Turn off nie usuwa już ustawionej blokady UEFI. Nawet bez blokady UEFI inne zasady zarządzania mogą nadpisać zmianę lub Windows może już domyślnie włączać Credential Guard.
Porównaj stan bieżący i docelowy na urządzeniu testowym w System Information (msinfo32.exe) pod Virtualization-based Security Services Running: jeśli celem pilotażu było włączenie Credential Guard, musi on być tam widoczny jako uruchomiony. Samo pomyślne wykonanie zadania przypisania zasad nie dowodzi działania tej funkcji. Po ponownym uruchomieniu na reprezentatywnym urządzeniu pilotażowym, przy użyciu autoryzowanego konta testowego, sprawdź wcześniej zinwentaryzowane i rzeczywiście używane sposoby logowania oraz połączenia (zwłaszcza 802.1X/WLAN, VPN, RDP/zdalne wsparcie i aplikacje korzystające z logowania jednokrotnego lub delegacji; jeśli występują, także integracje PKINIT-RSA/DES i SSP/AP oraz aplikacje odczytujące zapisane poświadczenia Windows), a także niezależną ścieżkę wycofania zmiany; samo działanie Credential Guard nie dowodzi, że sieć i zdalne wsparcie działają. W razie rozbieżności sprawdź najpierw edycję, Secure Boot/DMA, inne zasady i stan ponownego uruchomienia; nie eksperymentuj z przełączaniem blokady UEFI. Wycofanie wariantu without lock zaplanuj przez przygotowane zasady Windows lub właściwe GPO, zsynchronizuj urządzenie i po ponownym uruchomieniu ponownie sprawdź stan. W przypadku with UEFI lock przerwij działania i zastosuj zatwierdzoną lokalną procedurę odzyskiwania Microsoft z fizycznym dostępem.
Nie wdrażaj konfiguracji poczty e-mail bez weryfikacji
Pomoc Mobile wymienia Email account dla Exchange Online/Server oraz IMAP/POP jako konfiguracje Windows. Aby działały symbole zastępcze takie jak %_EMAILADDRESS_% i %_USERNAME_%, przypisany użytkownik musi mieć w Sophos Fusion uzupełnione pola Exchange Login i Email Address. Jeśli kilka kont Exchange ma różne zasady skrzynek pocztowych, według Sophos Windows może egzekwować tylko jedne zasady; użytkownik może ponadto odrzucić zmiany w konfiguracji Exchange. Pola haseł w projekcie zasad nie zastępują zatwierdzonej procedury zarządzania tożsamością i sekretami.
Ważna rozbieżność dotycząca aktualności: Sophos wyraźnie opisuje konfigurację poczty Exchange dla aplikacji Mail firmy Microsoft; Microsoft zakończył obsługę Windows Mail/Calendar/People 31 grudnia 2024 r. i informuje, że nie można już za ich pomocą wysyłać ani odbierać wiadomości i zdarzeń. Strona Sophos dotycząca IMAP/POP nie wskazuje obecnie wspieranego klienta docelowego; nie potwierdzono też przeniesienia tej konfiguracji do nowego Outlooka. Dlatego nie podajemy tu instrukcji wdrażania tej aplikacji Mail w środowisku produkcyjnym ani nie zakładamy automatycznej migracji do nowego Outlooka. Najpierw ustal klienta docelowego, metodę uwierzytelniania, zasady skrzynki pocztowej i bieżące wsparcie w danym środowisku, a następnie przetestuj je osobno.
Wdrożenie, kontrola i wycofanie
Po przeprowadzeniu kontroli wstępnych utwórz w Sophos Mobile pod Policies > Windows nowe zasady przeznaczone wyłącznie do pilotażu. Przed każdą edycją istniejących zasad sprawdź wszystkie przypisane urządzenia i grupy: zmiany już przypisanych zasad Windows synchronizują się automatycznie przy kolejnym połączeniu urządzeń i nie są testem na pojedynczym urządzeniu. Za pomocą Add configuration dodaj tylko sprawdzoną konfigurację, zapisz ją i przez Assign wybierz wyłącznie urządzenie pilotażowe. Opisana w oknie Sophos strona Schedule task jest dostępna przy zasadach Android, Knox i iOS, ale nie Windows; nie zakładaj więc możliwości opóźnionego przypisania zasad Windows w ten sposób. Rozpocznij test dopiero wtedy, gdy wyznaczona osoba zapewniająca wsparcie jest gotowa.
Po przypisaniu porównaj widok Policies danego urządzenia, stan zadań i jego faktyczne zachowanie. Zasady Windows synchronizują się automatycznie przy połączeniu urządzenia; sama informacja w interfejsie nie dowodzi lokalnego działania ustawień. W razie nieoczekiwanej zmiany nie włączaj kolejnego ustawienia wpływającego na bezpieczeństwo: utrzymaj dostęp do urządzenia, w kontrolowany sposób skoryguj tylko zasady przeznaczone dla tego urządzenia pilotażowego albo przypisz sprawdzone zasady zastępcze, zaczekaj na synchronizację i wymagany restart, a potem ponownie sprawdź działanie lokalnie. Przed zmianą dodatkowo przypisanych zasad współdzielonych sprawdź ich przypisania do urządzeń i grup. Nie przywróci to automatycznie usuniętych już profili WLAN, nie usunie blokady UEFI ani nie cofnie wywołanego żądania odzyskiwania BitLocker.
Zakres: Certyfikaty główne i klienta, SCEP oraz profile WLAN należą do osobnej procedury sieciowej i certyfikatowej dla Windows. Protektory BitLocker i zarządzanie kluczami odzyskiwania należą do Device Encryption. Tryb kioskowy i rejestracja Windows mają własne wymagania oraz procedury wycofania; żadnego z tych zadań nie realizują automatycznie omawiane tutaj zasady zabezpieczeń.