Bezpieczne planowanie i weryfikacja zasad zgodności w Sophos Mobile

Zasada zgodności nie jest certyfikatem ani profilem urządzenia. Ocenia wybrane reguły na zarejestrowanych urządzeniach i może uruchamiać działania w razie naruszeń. Decydujące znaczenie mają faktycznie używana edycja produktu (Sophos Mobile lub Sophos Mobile Threat Defense), platforma i wersja systemu, własność firmowa lub prywatna, tryb rejestracji i zarządzania, ewentualnie aplikacja Intercept X for Mobile (IXM) zarządzana przez Sophos Mobile, a także przypisana grupa urządzeń. Widoczna reguła lub szablon PCI/HIPAA nie dowodzą ani jej zastosowania do każdego urządzenia, ani certyfikacji.

Przed każdą ingerencją w środowisku produkcyjnym: Check now sprawdza wszystkie zarejestrowane urządzenia i wykonuje skonfigurowane działania. Utworzenie lub zmiana zasady oraz przypisanie jej do grupy również nie są czynnościami tylko do odczytu. Najpierw ustal pełny zakres urządzeń i sposób przywrócenia poprzedniego stanu; nie eksperymentuj na flocie produkcyjnej.

Co właściwie podlega ocenie?

Najpierw wybierz edycję produktu, a następnie sprawdź platformę, system i tryb rejestracji: w trybie Android Enterprise fully managed MDM zarządza całym urządzeniem; Apple User Enrollment obejmuje prywatne urządzenia Apple z ograniczonym zakresem zarządzania; supervised oznacza nadzorowane iPhone’y/iPady. Sama aplikacja IXM zarządzana przez Sophos Mobile nie potwierdza pełnego zarządzania urządzeniem przez Mobile Device Management (MDM). W swojej instancji sprawdź reguły dostępne dla rzeczywiście wdrożonej edycji i trybu; nie mieszaj zakresów reguł i działań Sophos Mobile oraz Sophos Mobile Threat Defense.

Reguły określają, które funkcje lub stany urządzenia są dozwolone, zabronione lub wymagane. Reakcję na naruszenie wybiera się osobno; samo kryterium zgodności nie dowodzi, że ustawienie urządzenia jest aktywnie zmieniane lub wymuszane.

Aby utworzyć zasadę w Sophos Mobile lub w odrębnej edycji Sophos Mobile Threat Defense, otwórz menu Compliance policies, kliknij Create compliance policy i wybierz szablon Default, PCI lub HIPAA. Wprowadź nazwę i opcjonalnie opis; wybór szablonu nie ogranicza późniejszych ustawień. Tylko szablon Default nie ma wstępnie ustawionych działań; szablony PCI/HIPAA mogą już je zawierać. Sophos opisuje reguły i działania szablonów PCI/HIPAA jako oparte na HIPAA i PCI DSS. Kolejność szablonów i standardów w dokumentacji jest jednak niejednoznaczna; nie należy na tej podstawie przypisywać pojedynczego szablonu do konkretnego standardu. Kartę platformy trzeba aktywować przez Enable platform: bez zaznaczenia nie są przeprowadzane kontrole zgodności urządzeń tej platformy. Poziomy ważności high, medium, low są przypisane do reguł na stałe; nie należy ich utożsamiać z dowolnie wybieranym działaniem w odpowiedzi. Podczas planowania zasad pomagają ocenić znaczenie każdej reguły i wybrać odpowiednią reakcję na naruszenie. Nie stanowi to zgody na wykonanie działania podczas incydentu. Highlight rules w pełnej edycji pomaga wyróżnić typ zarządzania, ale nie dowodzi, że reguła działa na każdym urządzeniu tego typu.

Dopiero po skonfigurowaniu i sprawdzeniu reguł oraz odpowiadających im reakcji dla wszystkich potrzebnych platform kliknij Save. Zasada zostanie zapisana pod wprowadzoną nazwą; późniejsze przypisanie do grupy odbywa się osobno, po kontrolach opisanych poniżej.

Sophos Mobile (pełna edycja/MDM): Oprócz reguł dotyczących zarządzania i systemu, zależnych od platformy, możliwe są sygnały IXM, jeśli Sophos Mobile zarządza tą aplikacją. Dla każdej reguły można wybrać działanie Deny email, Lock container, Set health, Create alert lub Transfer task bundle; nadal obowiązują ograniczenia platformowe i warunki wstępne danego działania.
Sophos Mobile Threat Defense (odrębna edycja produktu): Jej osobny zestaw reguł obejmuje między innymi uprawnienia Android IXM i wykrywanie złośliwego oprogramowania/aplikacji, iOS Web Filtering oraz reguły bezpieczeństwa Chromebooków. Dla tej edycji jako działanie opisano Create alert, a nie działania MDM dotyczące poczty, kontenera, Health czy pakietów zadań.

W odrębnej edycji reguły Installed apps i Mandatory apps dotyczą wyłącznie Chromebooków. Dla Installed apps najpierw wybierz Allowed apps lub Forbidden apps, a następnie grupę dozwolonych lub zabronionych aplikacji albo rozszerzeń. Dla Mandatory apps wybierz grupę aplikacji lub rozszerzeń, które muszą być zainstalowane. Opisane poniżej przyporządkowania do Androida, iOS i komputerów Mac oraz uwagi o aplikacjach systemowych i aktualizacjach aplikacji Androida należą do ogólnego katalogu pełnej edycji Sophos Mobile, a nie do tych dwóch reguł odrębnej edycji Threat Defense.

Osobny katalog Mobile Threat Defense compliance rules w pomocy Sophos Mobile opisuje podzbiór reguł dla urządzeń Android/iOS, których aplikacją IXM zarządza Sophos Mobile: na przykład root/jailbreak, limity wersji systemu, synchronizację IXM i skanowanie aplikacji Android. Sama zarządzana aplikacja nie dowodzi pełnego zarządzania urządzeniem przez MDM; ten podzbiór nie jest też katalogiem reguł odrębnej edycji Sophos Mobile Threat Defense. Reguła Intercept X for Mobile permissions can be denied określa na Androidzie, czy odmowa uprawnień aplikacji IXM powoduje niezgodność urządzenia. Może wykazać naruszenie związane z niedziałającym Web Filtering, jeśli odmówiono dostępu do Accessibility Service; przy korzystaniu z Web Filtering Sophos zaleca wartość No. Reguła iOS Web Filtering turned on znajduje się w ogólnym katalogu reguł Sophos Mobile oraz w katalogu odrębnej edycji Threat Defense, nie w wymienionym podzbiorze IXM. Na iPhone’ach i iPadach wymaga ona włączenia funkcji Web Filtering w aplikacji Intercept X for Mobile; jest to osobne kryterium, a nie reguła uprawnień Androida. Reguły Chromebooków nie stają się automatycznie regułami Android/iOS.

Podzbiór reguł dla zarządzanej aplikacji IXM jest opisany w obu wersjach pomocy, dla Sophos Mobile i Sophos Mobile Threat Defense. Dla urządzeń, których aplikacją IXM zarządza Sophos Mobile, wskazuje następujące zastosowania:

Managed required dotyczy Androida i iOS. Reguła określa reakcję, gdy urządzenie przestaje być zarządzane. Nie jest tożsama z Device administrator management allowed i nie dowodzi pełnego zarządzania MDM.
Minimum OS version i Maximum OS version dotyczą w tym podzbiorze Androida i iOS. Określają odpowiednio najstarszą wymaganą i najnowszą dozwoloną wersję systemu. Brak listy platform w ogólnym katalogu opisanym poniżej nie zmienia tego przyporządkowania.
Malware apps allowed dotyczy tutaj tylko Androida. Reguła określa, czy dozwolone są złośliwe aplikacje wykryte przez IXM.
PUAs allowed dotyczy tutaj tylko Androida. Reguła określa, czy dozwolone są potencjalnie niepożądane aplikacje wykryte przez IXM.

Te dwie reguły dotyczące aplikacji oceniają zgodność. Nie są ustawieniami skanowania ani zezwoleniem na odblokowanie wykrytych aplikacji czy wyłączenie ich z przyszłych skanowań. Skutki wykrycia i wyjątki sprawdza się osobno w instrukcji reakcji na incydent zgodności, do której odsyła link poniżej.

Reguła Maximum interval between … synchronizations jest konfigurowalną regułą zgodności dla odpowiedniego źródła synchronizacji: natywnego oprogramowania MDM systemu operacyjnego, Sophos Mobile Control, IXM lub Sophos Chrome Security. W ogólnym katalogu obowiązuje następujący podział:

Native MDM: iPhone’y/iPady bez Sophos Mobile Control lub IXM oraz komputery Mac i Windows.
SMC (Sophos Mobile Control): urządzenia z Androidem oraz iPhone’y/iPady.
Intercept X for Mobile: urządzenia z Androidem oraz iPhone’y/iPady.
Sophos Chrome Security: Chromebooki.

Każda z tych reguł ogranicza maksymalny dozwolony odstęp między synchronizacjami danego agenta z Sophos Fusion; nie traktuj agentów ani wartości czasu jako zamiennych. Natomiast Maximum interval between Intercept X for Mobile scans ogranicza na Androidzie odstęp między skanowaniami IXM w poszukiwaniu złośliwego oprogramowania, a nie między synchronizacjami. Przekroczenie limitu można oceniać wyłącznie na podstawie reguły, która faktycznie jest włączona i została naruszona, oraz odpowiedniego czasu synchronizacji lub skanowania. Niezależnie od tego opóźniona lub nieudana synchronizacja może sprawić, że wyświetlany stan zgodności nie jest już aktualny; sama w sobie nie dowodzi ani naruszenia reguły, ani zgodności. Status nieznany EAS Proxy to jeszcze inny przypadek w osobno skonfigurowanym procesie kwarantanny Exchange, a nie automatyczne naruszenie reguły maksymalnego odstępu między synchronizacjami.

Dobieraj reguły do celu kontroli

Poniższe grupy porządkują ogólny katalog reguł pełnej edycji Sophos Mobile na potrzeby planowania. Nie są listą zalecanych wartości domyślnych. Najpierw sprawdź edycję i tryb zarządzania, następnie wybierz tylko odpowiednie kryteria i osobno sprawdź reakcję dla każdej reguły.

Stan zarządzania, wersje i aktualizacje

Managed required / Device administrator management allowed: Pierwsza reguła dotyczy urządzeń, które przestały być zarządzane; druga określa działania dla urządzeń z Androidem, na których sam Sophos Mobile działa jako Device Administrator. Ten tryb zarządzania jest w Sophos Mobile przestarzały i dostępny tylko na Androidzie 9 lub starszym; nie można go używać na Androidzie 10 lub nowszym. Sophos zaleca migrację urządzeń korzystających z tego trybu do Android Enterprise. To ograniczenie opisanego tu trybu zarządzania Sophos Mobile, a nie stwierdzenie, że interfejsy API Android Device Administrator zostały ogólnie usunięte, ani instrukcja ponownego rejestrowania takich urządzeń.
Minimum SMC version: Najstarsza dozwolona wersja aplikacji Sophos Mobile Control, dla Androida i iPhone’ów/iPadów. Nie myl jej z wersją IXM ani systemu operacyjnego.
Minimum OS version / Maximum OS version: Odpowiednio najstarsza i najnowsza dozwolona wersja systemu operacyjnego. Przy tych dwóch pozycjach katalog nie podaje osobnej listy platform; sprawdź dostępność na karcie danej platformy.
Mandatory OS updates: Dotyczy nadzorowanych iPhone’ów/iPadów, nie Apple User Enrollment. Latest available update wymaga najnowszej dostępnej aktualizacji, a Latest critical update — najnowszej aktualizacji uznanej przez Apple za krytyczną. Najnowsza dostępna aktualizacja może być nowsza od najnowszej aktualizacji krytycznej. Latest critical update nie jest dostępna od iOS/iPadOS 27. Do zarządzania aktualizacjami tych urządzeń Sophos wskazuje zasadę deklaratywną z Software update settings lub Enforced software update; nie wyciągaj z tego wniosku, że dotychczasowy wybór w regule zgodności nadal działa tak samo. Software update settings wymaga iOS/iPadOS 26 lub nowszego, trybu zarządzania Apple Device Enrollment i nadzorowanego urządzenia. Dla Enforced software update Sophos wymienia jako wymagania iOS/iPadOS 26 lub nowszy oraz Apple Device Enrollment, ale nie podaje dodatkowego wymogu nadzoru. Tę minimalną wersję 26 należy odróżnić od granicy 27 dla dotychczasowej opcji Latest critical update.

Informacje o aktualizacjach Apple wymagają osobnej ścieżki sieciowej: Aby uzyskać informacje o dostępnych aktualizacjach na iPhone’ach, iPadach i komputerach Mac, adres mesu.apple.com musi być dostępny przez HTTPS 443. Jeśli ten adres docelowy jest niedostępny, Sophos Mobile nie ma informacji o aktualizacjach; reguły zgodności dotyczące obowiązkowych aktualizacji nie mają wtedy skutku. Sprawdź rzeczywistą ścieżkę wspólnie z administratorami sieci, zanim uznasz status takiej reguły za wiarygodny. Nie rozszerza to wymienionych wyżej ograniczeń platformy, systemu ani rejestracji dla Mandatory OS updates i nie oznacza twierdzenia, że wszystkie instalacje aktualizacji Apple kończą się niepowodzeniem.

Ochrona urządzenia i oddzielenie danych służbowych

Root access allowed (Android): Określ, czy dozwolone są urządzenia z uprawnieniami root. Udokumentowane zezwolenie obejmuje również uznawane przez system za niebezpieczne urządzenia Sony z Enterprise API Level 4 lub nowszym oraz urządzenia Samsung z Knox Standard SDK 5.5 (API Level 17) lub starszym. Są to historyczne zastrzeżenia z pomocy dotyczącej reguły, a nie zalecenie używania tych urządzeń obecnie.
Android Debug Bridge (ADB) allowed (Android): Określ, czy interfejs debugowania ADB jest dozwolony, czy zabroniony.
Allow jailbreak (iPhone/iPad): Osobno określ, czy dozwolone są urządzenia z jailbreakiem; nie przenoś na nie reguły dotyczącej roota na Androidzie.
Screen lock required (Android, iPhone/iPad, Windows): Określ, czy wymagane jest hasło urządzenia lub inny mechanizm blokady. Na Androidzie uwzględniane są Pattern, PIN i Password, ale nie Swipe. Przy Apple User Enrollment reguła jest spełniona, jeśli przypisana zasada zawiera konfigurację Password policies.
Encryption required (Android, Mac, Windows): Wymagaj szyfrowania; w macOS reguła dotyczy pełnego szyfrowania FileVault. Według pomocy dotyczącej reguły iPhone’y i iPady są zawsze szyfrowane i nie znajdują się na liście platform, do których ta reguła ma zastosowanie.
Container configured (Android): Kontener musi być skonfigurowany i aktywowany, na przykład profil służbowy Android lub kontener Samsung Knox. Jest to kryterium stanu, a nie reakcja Lock container.
Data roaming allowed: Zezwól na roaming danych lub go zabroń, dla Androida oraz iPhone’ów/iPadów bez Apple User Enrollment.

Nie stosuj ogólnej naprawy szyfrowania Androida: Aktualna pomoc do reguły Encryption required dla Androida nadal wspomina o Require PIN to start device lub Require Password to start device podczas konfiguracji blokady ekranu. Nie dowodzi to, że opcje startowego PIN-u lub hasła są dostępne w obecnych wersjach Androida albo w każdym trybie Android Enterprise. Osobny artykuł KBA-000004067 opisuje przypadek błędu z wyświetlanym domyślnym kluczem szyfrowania i wskazuje startowy PIN oraz ręczną synchronizację jako sposób rozwiązania, bez określenia wersji systemu ani trybu rejestracji; nie jest to uniwersalna metoda naprawy dla obecnych wersji Androida lub trybów Android Enterprise. Przed każdą ingerencją w urządzenie ustal faktycznie zaobserwowany błąd, obsługiwaną wersję systemu i tryb rejestracji; nie zalecaj ogólnej zmiany PIN-u ani Synchronize now.

Aplikacje, profile i uprawnienia

Installed apps: Najpierw wybierz Allowed apps lub Forbidden apps, a następnie grupę aplikacji dozwolonych lub zabronionych. Dotyczy Androida, iPhone’ów/iPadów bez Apple User Enrollment, komputerów Mac i Chromebooków. Aplikacje systemowe Androida są zawsze dozwolone; grupy aplikacji Chrome OS mogą zawierać aplikacje i rozszerzenia.
Mandatory apps: Wybierz z listy grupę aplikacji, które muszą być zainstalowane. Grupy Chrome OS mogą również zawierać rozszerzenia. W przypadku Mandatory apps na iOS nie dodawaj aplikacji systemowych jako obowiązkowych: Sophos Mobile nie potrafi wykryć ich instalacji i według pomocy dotyczącej reguły uzna wszystkie objęte nią urządzenia za niezgodne. Dla Androida Sophos opisuje w SMCAND-3159, że równoległe aktualizacje aplikacji podczas synchronizacji aplikacji Control z backendem Mobile mogą na krótko zmienić stan na niezgodny, a następnie znów na zgodny, zwłaszcza na starszych urządzeniach. Aby ocenić sytuację wyłącznie na podstawie odczytu, porównaj faktycznie naruszoną regułę, czas aktualizacji i synchronizacji oraz stan zaobserwowany później. Nie jest to powód do złagodzenia reguły wymagającej instalacji aplikacji. Późniejszy stan zgodności nie dowodzi ani braku skutków dla działania urządzenia, ani przywrócenia dostępu do aplikacji, poczty czy sieci bezprzewodowej; udokumentowany automatyczny powrót do zgodności nie jest wynikiem zaobserwowanym w ramach tego artykułu i nie ma gwarantowanego terminu.
Suspicious apps allowed (Android): Określ, czy dozwolone są podejrzane aplikacje wykryte przez IXM. Jest to osobny wybór w regułach zgodności, a nie automatycznie odpowiednik ustawień skanowania aplikacji o niskiej reputacji.
Third-party profiles allowed (iPhone/iPad, bez Apple User Enrollment): Określ, czy dozwolone są profile konfiguracji, którymi nie zarządza Sophos Mobile.
Unmanaged apps from unknown sources allowed (iPhone/iPad): Określ, czy dozwolone są samodzielnie opracowane aplikacje, instalowane ręcznie z pliku IPA i podpisane przy użyciu profilu aprowizacji ad hoc. Nie utożsamiaj tego z regułą Chromebooków dotyczącą aplikacji spoza Chrome Web Store.
SMC permissions can be denied (Android): Aplikacja Control potrzebuje do działania uprawnień, które należy nadać podczas instalacji. Reguła określa, czy odmowa ich nadania powoduje naruszenie zgodności. Dotyczy innej aplikacji niż opisana wyżej reguła Intercept X for Mobile permissions can be denied.
Locate permission required (Android): Określ dla funkcji Locate, czy zgodność wymaga nadanego podczas instalacji uprawnienia aplikacji Control do pobierania danych lokalizacji.
App is able to locate (iPhone/iPad): Usługi lokalizacji muszą być włączone, a aplikacja Control musi mieć uprawnienie do korzystania z nich. Ta kombinacja jest odrębna od kryterium dotyczącego instalacji na Androidzie. Żadna z reguł lokalizacji nie stanowi organizacyjnej ani prawnej zgody na zbieranie danych lokalizacji.

Sprawdzaj osobno Chromebooki, komputery Mac i Windows

Chromebooki: Poniższe reguły dotyczą Sophos Chrome Security, a nie aplikacji Control na Androidzie:

Tamper protection turned off: Wybierz reakcje na przypadek, gdy zasada Chrome Security policy została zmodyfikowana w sposób nieuprawniony.
Minimum Sophos Chrome Security version: Określ najstarszą dozwoloną wersję rozszerzenia Chrome Security.
Apps from unknown sources allowed: Określ, czy dozwolone są aplikacje i rozszerzenia spoza Chrome Web Store.

Komputery Mac: Kryteria dotyczą włączenia danego mechanizmu ochrony, a nie dowodu, że sama reguła zgodności go włącza:

Firewall required: Zapora macOS musi być włączona.
System Integrity Protection required: SIP musi być włączona. Ta funkcja ochrony macOS ogranicza działania użytkownika root; można ją skonfigurować po uruchomieniu urządzenia w macOS Recovery. Nie oznacza to zgody na zmianę SIP podczas bieżącej pracy.
Security updates required: Automatyczna instalacja aktualizacji zabezpieczeń macOS musi być włączona. Pomoc dotycząca reguły ogranicza jej zastosowanie do macOS 26 (Tahoe) lub starszego; nie jest to granica iOS/iPadOS 27 z reguły aktualizacji urządzeń mobilnych.

Komputery Windows: Wybierz trzy odrębne kryteria Defendera i nie wnioskuj o nich na podstawie jednego statusu:

Windows Defender must be turned on: Ochrona w czasie rzeczywistym programu Windows Defender musi być włączona. To zamierzone kryterium nadal obowiązuje. Jednak dla Windows 10 Sophos opisuje w SMCSRV-13801 ograniczenie kontroli: reguła sprawdza tylko, czy usługa Defendera działa, a nie czy ochrona w czasie rzeczywistym jest włączona. Urządzenie może więc być oznaczone jako zgodne mimo wyłączonej ochrony. Zanim polegasz na tej ochronie, sprawdź osobno jej rzeczywisty stan na danym urządzeniu z Windows 10, wyłącznie przez odczyt, bez zmiany przełączników ochrony ani zasad. Działająca usługa i stan zgodności nie zastępują tej kontroli na urządzeniu.
Clean status from Windows Defender required: Urządzenie jest niezgodne, jeśli Windows Defender wyświetla ostrzeżenia.
Up-to-date Windows Defender definitions required: Windows Defender musi używać najnowszych definicji oprogramowania szpiegującego.

Nie myl reakcji z regułą

Create alert tworzy w pełnej edycji zdarzenie widoczne w szczegółach urządzenia oraz alert; Threat Defense opisuje alerty w Sophos Fusion. Alert nie jest skonfigurowaną blokadą poczty ani kontenera. Jednak wybranie tylko Create alert nie gwarantuje ani niezmienionego stanu Health urządzenia, ani niezmienionego dostępu do sieci bezprzewodowej; możliwe są także inne skutki niezgodności.
Deny email to skonfigurowana reakcja na naruszenie reguły zasady w pełnej edycji; wymaga skonfigurowanego połączenia z Sophos Mobile EAS Proxy i jest przewidziana dla Androida, iPhone’a/iPada oraz Windows. Sama obecność EAS Proxy nie dowodzi ani sposobu uwierzytelniania danej usługi pocztowej, ani faktycznego przerwania lub przywrócenia dostarczania poczty. Osobno Sophos opisuje kwarantannę Exchange dla niezarejestrowanych urządzeń tylko przy EAS Proxy w trybie PowerShell i odpowiednio skonfigurowanej domyślnej regule dostępu Exchange. Mogą tam trafić także zarejestrowane urządzenia, jeśli proxy nie zna ich stanu zgodności z powodu zbyt długiego czasu od synchronizacji lub braku połączenia z Sophos Mobile. Powiadomienie o rejestracji wysyłane przez Exchange w procesie kwarantanny nie jest ani Create alert, ani dowodem uruchomienia Deny email. Nie wyciągaj wniosku o ogólnej kwarantannie czy automatycznym przywróceniu poczty z naruszenia reguły albo z alertu; analiza takiego przypadku należy do obsługi incydentu, nie do tego planu zasad.
Lock container w obecnej pełnej edycji jest przewidziane dla Android Enterprise, a nie jako potwierdzona blokada kontenera iOS. Ogólna tabela działań związanych ze zgodnością w pełnej edycji opisuje to skonfigurowane działanie jako blokadę wszystkich aplikacji z wyjątkiem Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages i Phone. Ten ogólny opis nie rozstrzyga o skutkach dla aplikacji w prywatnym profilu BYOD; ani sześć wyjątków, ani poniższy przykład profilu służbowego nie dowodzą, że prywatne aplikacje pozostaną dostępne. Dla obsługiwanego profilu służbowego Android Sophos dokumentuje osobną kontrolę dostępu: Auto (domyślnie, bez ręcznego nadania dostępu: profil służbowy zostaje zablokowany, jeśli naruszona reguła zgodności zawiera Lock container), Deny (profil służbowy zablokowany) i Allow (profil służbowy odblokowany). Przy blokadzie aplikacje i dane profilu służbowego są niedostępne; ustawienie jest stosowane dopiero po synchronizacji urządzenia. Ta kontrola dostępu do profilu służbowego różni się od polecenia blokady całego urządzenia; nie dowodzi ani skutku skonfigurowanego działania zgodności dla prywatnych aplikacji, ani jego dostępności w każdym scenariuszu BYOD/rejestracji, ani przetestowanego sposobu przywrócenia dostępu. Przed zatwierdzeniem sprawdź zakres i skutek na autoryzowanym urządzeniu.
Odróżniaj Set health od obliczanego stanu Health: Set health to działanie wybierane osobno dla każdej reguły w pełnej edycji: po naruszeniu reguły przypisywana jest wybrana wartość czerwona/żółta/zielona; gdy naruszono kilka reguł, obowiązuje najgorsza z przypisanych wartości Health. Na Androidzie, iPhonie i iPadzie działanie wymaga włączonej Synchronized Security; aby uzyskać zamierzony efekt w sieci bezprzewodowej, trzeba ponadto skonfigurować w zasadzie wartość Health dla niezgodności oraz reguły sieci bezprzewodowej. Osobno Fusion wyświetla stan Health urządzenia wynikający z naruszeń reguł zgodności; przy włączonej Synchronized Security można go ręcznie nadpisać, a Auto przywraca obliczanie na podstawie stanu zgodności. Nie ustalono, jaka wartość powstaje bez działania Set health w każdej edycji i każdym trybie ani jak ustalany jest priorytet między ręcznym nadpisaniem a równoczesnym działaniem reguły; nie zakładaj automatycznego przypisania czerwonej/żółtej wartości ani niezmienionego stanu Health na podstawie Create alert. Oddzielnie sprawdź naruszoną regułę/niezgodność, zapisane działanie Set health, wyświetlany stan Health wraz z ustawieniem ręcznym/Auto, wartość zgłoszoną do sieci bezprzewodowej i rzeczywisty dostęp. Sophos Wireless może ograniczać dostęp do sieci zależnie od konfiguracji; sam widok konsoli nie dowodzi konkretnego skutku w sieci bezprzewodowej.
Transfer task bundle może spowodować błędną konfigurację urządzeń, a nawet ich wymazanie. Nie ustawiaj zadań wymazywania/resetowania ani automatycznych pakietów zadań jako domyślnej reakcji; None oznacza tu wyłącznie, że żaden pakiet zadań nie zostanie przesłany, a nie że niezgodność pozostanie bez skutków.

Przypadek szczególny: Na niezgodnym urządzeniu Android Enterprise fully managed w pełnej edycji wszystkie aplikacje są automatycznie wyłączane, niezależnie od reakcji wybranej dla danej reguły. Nie należy tego utożsamiać z konfigurowalnym działaniem Lock container ani uznawać za potwierdzony skutek dla urządzeń Android BYOD/z profilem służbowym, urządzeń tylko z MTD lub innych trybów Androida. W Android BYOD działanie Lock container zależy od faktycznie obsługiwanego trybu zarządzania i konfiguracji; nie wyciągaj wniosku o blokadzie całego urządzenia z możliwej blokady obszaru służbowego. Przed każdym zatwierdzeniem sprawdź na autoryzowanym urządzeniu testowym dostępność telefonu, obszaru służbowego, mechanizmów odzyskiwania i krytycznych aplikacji.

Synchronized Security nie jest dostępna dla wszystkich urządzeń: Sophos wyklucza Chromebooki, Apple User Enrollment i urządzenia z adresem MAC specyficznym dla sieci, prywatnym lub losowym, ponieważ nie przekazują one swojego adresu MAC do Sophos Mobile. Osobna możliwość przekazania adresu MAC przez konfigurację aplikacji IXM przy zewnętrznym EMM nie dowodzi wyjątku dla prywatnych/losowych adresów MAC. Planuj pilotaż sieci bezprzewodowej tylko dla faktycznie obsługiwanego trybu urządzenia/rejestracji, po sprawdzeniu konfiguracji MAC i Synchronized Security; sam wyświetlany stan Health nie zastępuje testu dostępu.

Przypisuj etapami zamiast testować globalnie

Zbierz informacje o urządzeniach i wymaganiach: Zanotuj instancję, licencję/edycję, tryb zarządzania, platformę/system, własność urządzenia, stan zarządzania IXM, ostatnią synchronizację, dotychczasowe reguły i aktywne zależności od EAS Proxy oraz Sophos Wireless. Udokumentuj możliwość korzystania z Synchronized Security i ograniczenia adresów MAC, wyświetlany stan Health urządzenia wraz z trybem ręcznym/Auto, istniejące reguły sieci bezprzewodowej oraz zasady i ich przypisania.
Oceń każdą regułę i działanie osobno: Otwórz aktualny katalog reguł właściwej edycji produktu; dla każdej włączonej platformy zinwentaryzuj każdą regułę przejętą z szablonu lub ustawioną ręcznie wraz z reakcją. Przed Save i przed przypisaniem sprawdź sygnał, tryb i warunki wstępne działania; nie zakładaj, że szablony PCI/HIPAA są pasywne. Na zatwierdzony pilotaż zaplanuj nową, odizolowaną zasadę bez działań blokujących lub destrukcyjnych i ponownie sprawdź jej faktycznie zapisane działania. Brak Set health nie dowodzi, że obliczany lub ręcznie ustawiony stan Health bądź dostęp do sieci bezprzewodowej pozostaną bez zmian. Ważne: Nawet samo Create alert albo None przy pakiecie zadań nie zapobiega udokumentowanemu automatycznemu wyłączeniu aplikacji na niezgodnym urządzeniu Android Enterprise fully managed. Wyklucz takie urządzenia z tego pilotażu, dopóki nie zostanie zatwierdzony i przygotowany test dostępności aplikacji oraz przywrócenia działania dla konkretnego urządzenia, wersji i trybu.
Wybierz ograniczoną grupę pilotażową: Rozpatruj planowane urządzenia firmowe i prywatne oddzielnie. Jeśli zatwierdzony pilotaż wymaga nowej grupy, najpierw przygotuj grupę urządzeń i sprawdź jej zakres. Jeśli zarządzasz urządzeniami obu rodzajów własności, Sophos zaleca odrębne zasady zgodności dla urządzeń firmowych i prywatnych; same dwa osobne pola przypisania nie oznaczają jeszcze używania różnych zasad. W Device groups > [nazwa grupy] > Compliance policies przypisuje się osobno corporate i personal. Przed Save sprawdź dla każdego urządzenia docelowego jego dokładnie jedną bieżącą grupę urządzeń (również istniejącą grupę Default, jeśli jest do niej przypisane), rodzaj własności (corporate/personal) i przypisaną tej grupie zasadę pod kątem niezamierzonego zasięgu. Po wybraniu zasad dla corporate i personal oraz sprawdzeniu zasięgu kliknij Save, aby zapisać przypisanie do grupy. Następnie na stronie Device groups porównaj obie kolumny Compliance policy (corporate) i Compliance policy (personal) dla wybranej grupy z planowanym przypisaniem. Przed zmianą istniejącej, współdzielonej zasady sprawdź wszystkie grupy, którym przypisano tę zasadę; zmiana może objąć kolejne grupy, ale nie dlatego, że urządzenie należy do wielu grup. Nowy, odizolowany pilotaż nie może po cichu zmieniać współdzielonej zasady.
Sprawdź skutki w autoryzowanym pilotażu: Przed celowym wywołaniem naruszenia ponownie upewnij się, że w pilotażu ograniczonym do alertów/bez działań nie ma urządzenia Android Enterprise fully managed; Create alert ani None nie chronią jego aplikacji. Najpierw porównaj przypisanie do grupy i konkretne urządzenie, w tym nową wartość zgodności, naruszoną regułę, czas synchronizacji oraz ewentualny alert/zdarzenie. Na obsługiwanym urządzeniu testowym, przed naruszeniem i po nim, obserwuj osobno faktycznie zapisane działanie Set health, wyświetlany stan Health i tryb ręczny/Auto, a przy aktywnej Synchronized Security także zgłoszoną wartość Health, regułę sieci bezprzewodowej i rzeczywisty dostęp do tej sieci; przy odpowiedniej konfiguracji sprawdź również przepływ poczty i dostępność aplikacji. Nawet bez działania Set health nie zakładaj niezmienionego dostępu do sieci; opóźnionej lub brakującej synchronizacji nie traktuj jako potwierdzenia zgodności. Celowe naruszenie testuj tylko wtedy, gdy potwierdzono sposób przywrócenia stanu i nie ma zagrożenia dla danych produkcyjnych. Przed rozszerzeniem pilotażu na w pełni zarządzane urządzenia Android Enterprise sprawdź najpierw na autoryzowanym urządzeniu, czy udokumentowany automatyczny skutek występuje w danej wersji i trybie oraz czy działa sposób przywrócenia stanu.
Rozszerzaj dopiero po zatwierdzeniu: Porównaj objęte urządzenia i nieoczekiwane naruszenia ze stanem wyjściowym. W razie rozbieżności wstrzymaj rozszerzanie, po uzyskaniu zgody przywróć udokumentowane poprzednie przypisanie do grupy oraz konfigurację reguł i działań, a następnie ponownie sprawdź przywrócenie stanu na urządzeniu i w usługach zewnętrznych. Usunięcie reguły nie cofa automatycznie już wykonanych pakietów zadań, wymazań ani blokad dostępu w usługach zewnętrznych.

Nie używaj jako testu: Compliance policies > Check now dotyczy wszystkich zarejestrowanych urządzeń i wykonuje skonfigurowane tam działania – nawet jeśli zamierzano objąć tylko małą grupę. Przed planowaną kontrolą globalną należy sprawdzić wszystkie grupy i reakcje oraz zatwierdzić zmianę; ten artykuł nie upoważnia do naciśnięcia tego przycisku w instancji produkcyjnej.

Wyłącznie przykład planowania, nieprzetestowany: Specjalnie zatwierdzona grupa z jednym firmowym iPhonem (bez Apple User Enrollment i bez Android Enterprise fully managed), z wcześniej sprawdzoną jako odpowiednia niedestrukcyjną regułą oraz Create alert, mogłaby posłużyć jako ograniczony pilotaż. Przed przypisaniem zbierz wszystkie pary reguł i działań, informacje o przynależności do grup oraz, jeśli częścią testu jest sieć bezprzewodowa, dane o możliwości korzystania z Synchronized Security i konfiguracji MAC oraz sieci bezprzewodowej. Przy autoryzowanym, odwracalnym naruszeniu testowym w pełnej edycji sprawdź naruszenie/niezgodność i zdarzenie w szczegółach urządzenia w konsoli oraz alert w konsoli; w odrębnej edycji Sophos Mobile Threat Defense sprawdź alert na stronie Alerts w Sophos Fusion. Niezależnie sprawdź wyświetlany stan Health (ręczny/Auto), a na urządzeniu docelowym dostęp do poczty, dostępność aplikacji i rzeczywisty dostęp do sieci bezprzewodowej przed synchronizacją i po niej. Nie oczekuj wyświetlenia alertu na fizycznym urządzeniu docelowym. Nie zakładaj niezmienionego stanu Health ani dostępu do sieci na podstawie samego Create alert. Przerwij test, jeśli obejmie inne urządzenia, synchronizacja nie nastąpi lub stan Health/dostęp nieoczekiwanie się zmienią; nie rozszerzaj zakresu, po uzyskaniu zgody przywróć wcześniejsze przypisanie i ponownie sprawdź jego skutek. Jest to plan weryfikacji, a nie zaobserwowany wynik testu.

Zakres i warunki zastosowania

Analiza urządzenia, na którym już wykryto problem lub które zostało zablokowane, wstępna ocena alertów, obsługa fałszywych alarmów oraz przywracanie dostępu do poczty lub sieci bezprzewodowej nie należą do tej instrukcji planowania zasad. Nie zastępuje ona instrukcji obsługi incydentów ani resetowania. Zastosowanie startowego PIN-u w Androidzie lub ręcznej synchronizacji z KBA-000004067 nie jest uniwersalną naprawą bez sprawdzenia konkretnego błędu i obsługiwanej kombinacji urządzenia oraz trybu rejestracji. Wstępną ocenę opartą wyłącznie na odczycie oraz sprawdzenie dostępu do Wi-Fi opisuje instrukcja reakcji na incydent zgodności; ona również nie daje zgody na działania operacyjne.

Opisanych procedur nie zweryfikowano na urządzeniach ani w instancji. Ten artykuł nie daje zgody na działania operacyjne. Zależność między wybranym działaniem Set health, automatycznie obliczanym/ręcznie nadpisanym stanem Health i skutkami w sieci bezprzewodowej nie została tu rozstrzygnięta dla każdego trybu. Przed zastosowaniem operacyjnym należy zatwierdzić i sprawdzić na konkretnych urządzeniach kombinacje reguł i działań dla poszczególnych edycji produktu, systemów i trybów oraz sposoby przywrócenia dostępu przez EAS/Wireless i do aplikacji Androida.