Sophos Mobile: bezpieczne sprawdzanie certyfikatów SCEP i ścieżek komunikacji

SCEP umożliwia instalowanie i odnawianie certyfikatów w Sophos Mobile (MDM). Ta procedura dotyczy konfiguracji SCEP po stronie tenantu i różnych ścieżek komunikacji, które trzeba w niej rozróżnić — nie obejmuje pełnej konfiguracji urzędu certyfikacji Windows, infrastruktury Wi-Fi/VPN ani wszystkich ładunków zasad dla Androida, urządzeń Apple i Windows. Instalowanie i odnawianie certyfikatów przez SCEP według tej procedury nie jest obsługiwane na Chromebookach.

Przed zmianą w środowisku produkcyjnym: osoby odpowiedzialne za CA/PKI, sieć i MDM, a w razie potrzeby również za usługę uwierzytelniania Wi-Fi/VPN, wspólnie ustalają, których urządzeń i trybów rejestracji dotyczy zmiana, czy i w jaki sposób konkretna usługa może używać certyfikatu SCEP oraz jak zachować dostęp do urządzeń po utracie łączności z siecią. Ani Save, ani rozesłana zasada nie dowodzą, że certyfikat klienta został wystawiony, odnowiony lub przypisany do profilu Wi-Fi/VPN.

Trzy ścieżki komunikacji zamiast ogólnej reguły otwarcia portów

Sophos Fusion łączy się z własnym urzędem CA obsługującym SCEP, a zarządzane urządzenie komunikuje się osobno z Sophos Mobile. Późniejsze uwierzytelnienie w usłudze Wi-Fi/VPN przy użyciu tego właśnie certyfikatu SCEP nie następuje automatycznie i wymaga potwierdzenia dla danej platformy i profilu. Tenant oznacza tu własne środowisko Sophos Mobile, a MDM — system zarządzania jego urządzeniami.

Ustal region tenantu: W Sophos Fusion, w My Products > Mobile, sprawdź adres URL w pasku adresu przeglądarki. Region znajduje się w pierwszym członie nazwy hosta, przed pierwszą kropką, bezpośrednio po smc-user-if-cloudstation-. W przykładzie smc-user-if-cloudstation-eu-west-1 regionem jest eu-west-1. Do reguł dostępu użyj regionu z własnego adresu URL w przeglądarce, a nie wartości przykładowej ani takiego samego tekstu w ścieżce URL czy parametrach zapytania. Region hostingu wybiera się podczas tworzenia konta Sophos Fusion; dla istniejących kont ustala się go tutaj na podstawie rzeczywistego adresu URL w przeglądarce. Ten host administracyjny nie jest ani punktem końcowym urządzeń, ani serwerem SCEP. Ta metoda ustalania regionu dotyczy również Mobile Threat Defense, ale nie potwierdza odrębnej funkcji SCEP w MTD.
Sophos Fusion do własnych serwerów (ruch przychodzący): Aktualna regionalna lista źródłowych adresów IP do ustalenia konkretnej reguły zezwalającej na ruch przychodzący podaje dla SCEP TCP 443, a dla osobnego połączenia LDAP/AD — TCP 636. Zezwól na dostęp do właściwego własnego serwera SCEP lub AD wyłącznie z adresów źródłowych Mobile aktualnie opublikowanych tam dla rzeczywistego regionu tenantu. Nie przyjmuj regionu przykładowego i nie twórz globalnej ani nieograniczonej reguły ruchu przychodzącego. Połączenie LDAP/AD służy do uwierzytelniania użytkownika przy użyciu danych logowania AD podczas rejestracji urządzenia przez Apple Business (dawniej Apple Business Manager), Google Zero-touch lub Samsung KME. To uwierzytelnienie nie jest ani pierwszym wystawieniem certyfikatu klienta przez SCEP na zarządzanym urządzeniu, ani jego późniejszym odnowieniem.
Urządzenie do Sophos Mobile (ruch wychodzący): Zarządzane urządzenia potrzebują połączenia HTTPS na porcie 443 z regionalnym hostem smc-device-if-cloudstation-. Pełne adresy docelowe dla urządzeń to smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com dla eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com dla eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com dla us-west-2 i smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com dla us-east-2, w każdym przypadku przez HTTPS 443. Użyj wyłącznie adresu docelowego dla wcześniej ustalonego rzeczywistego regionu tenantu; te adresy dla urządzeń nie są hostem administracyjnym ani własnymi adresami docelowymi SCEP. Dodatkowo wymagane są połączenia dla powiadomień push, rejestracji i innych funkcji platformowych. Poniższe oddzielne ścieżki weryfikacji i wewnętrzne poradniki platformowe porządkują je według typu urządzenia i faktycznie używanej funkcji; cztery regionalne hosty urządzeń nie stanowią pełnej listy adresów docelowych ruchu wychodzącego. Te dodatkowe adresy docelowe nie są ani źródłowymi adresami IP ruchu przychodzącego SCEP, ani uniwersalną listą portów SCEP.

Rozpatruj osobno pozostałe zależności ruchu wychodzącego urządzeń:

Powiadomienia push Windows: Dla komputerów Windows udokumentowano dla Windows Notification Service (WNS) i Microsoft Push Notification Service (MPNS) adresy docelowe *.notify.windows.com, *.wns.windows.com i *.notify.live.net, w każdym przypadku przez HTTPS 443. Są to połączenia push Windows, a nie porty ruchu przychodzącego SCEP.
Rejestracja i przygotowanie urządzeń Android: Dla Androida skorzystaj z poradnika Android Enterprise, a dla wymagań QR/Zero-touch/KME — z poradnika przygotowania urządzeń; nadal trzeba w nich sprawdzić zezwolenie na połączenia dla konkretnego urządzenia i trybu.
Powiadomienia push zarządzania Apple: Dla zarządzania iPhone’ami, iPadami i komputerami Mac osobno sprawdź ścieżkę powiadomień push Apple; tożsamość certyfikatu, odnowienie i kontrolę dostępności dostępną na iPhonie/iPadzie opisuje poradnik APNs.
Informacje o aktualizacjach Apple i zgodność: Niezależnie od tego Sophos Mobile potrzebuje informacji o dostępnych aktualizacjach Apple: jeśli odpowiednia usługa Apple jest niedostępna, brakuje tych informacji, a reguły zgodności wymagające aktualizacji nie mają skutku. Sprawdź własną ścieżkę sieciową oraz ograniczenia platformy, systemu operacyjnego i trybu rejestracji w poradniku zasad zgodności. Powiadomienia push zarządzania Apple i informacje o aktualizacjach to wymagania ruchu wychodzącego urządzeń, nie punkty końcowe ruchu przychodzącego SCEP ani wystawiania certyfikatów.
Ruch aplikacji IXM: Dla iPhone’ów/iPadów z Sophos Intercept X for Mobile (IXM) sprawdź osobne połączenia aplikacji w poradniku sieciowym IXM; opisano tam przyporządkowanie usług i portów oraz ograniczenia zależne od wersji aplikacji, edycji, sposobu zarządzania i faktycznie używanej funkcji. Nie są to połączenia przychodzące SCEP; nagłówek Apple na liście połączeń sieciowych nie oznacza, że IXM ma zastosowanie do komputerów Mac.

Udokumentowany adres docelowy nie jest jeszcze dowodem jego dostępności we własnej sieci.

Podczas diagnozowania awarii osobno odnotuj, czy (a) Sophos Fusion dociera do własnego punktu końcowego SCEP, (b) urządzenie dociera do Sophos Mobile i otrzymuje zasadę oraz (c) usługa Wi-Fi/VPN akceptuje wystawiony certyfikat. Powodzenie na jednej ścieżce nie zastępuje sprawdzenia pozostałych dwóch.

Wcześniej ustal zaufanie i odpowiedzialność

Pojęcia potrzebne do podjęcia decyzji: PKI to infrastruktura klucza publicznego, a CA — urząd wystawiający certyfikaty. SCEP służy do żądania certyfikatu klienta; Subject i SAN (Subject Alternative Name), a w stosownych przypadkach UPN (identyfikator użytkownika), określają tożsamość podlegającą sprawdzeniu. EAP jest metodą uwierzytelniania w usłudze Wi-Fi. Import PKCS-#12 (.pfx) to inny sposób dostarczenia certyfikatu niż SCEP; certyfikat zaimportowany tą metodą nie jest automatycznie odnawiany zgodnie z interwałem odnowienia SCEP.

Rozstrzygnij osobno trzy kwestie zaufania, nawet jeśli ten sam urząd CA pełni kilka ról we własnej PKI:

Połączenie z serwerem SCEP: Przed dodaniem SCEP zespół MDM dostarcza do odpowiedniej zasady konfigurację Root certificate z certyfikatem CA serwera SCEP. W zasadach urządzeń Android Enterprise trzeba dodatkowo wybrać ten certyfikat w polu Root certificate konfiguracji SCEP spośród certyfikatów tej samej zasady. Nie jest to wystawiony certyfikat klienta i nie potwierdza tożsamości klienta.
Wystawiona tożsamość klienta: W Android Enterprise i iOS pole Subject po zastąpieniu wszystkich symboli zastępczych musi zawierać poprawną nazwę X.500 przewidzianej osoby lub urządzenia. Typ i wartość SAN ustal osobno; AD user logon name w polach SCEP dla urządzeń oznacza AD UPN użytkownika, a nie dowolny identyfikator urządzenia. Pole CA name w iOS jest nazwą rozpoznawaną przez CA, na przykład służącą do rozróżniania jego instancji — nie stanowi dowodu tożsamości wystawcy ani kotwicy zaufania. Dlatego zespół PKI/CA sprawdza na faktycznie wystawionym certyfikacie wystawcę certyfikatu i łańcuch certyfikacji, dopuszczone wartości Subject/SAN/UPN, zastosowanie klucza oraz dostęp do klucza prywatnego. Zespół MDM i zespół odpowiedzialny za usługę uzgadniają rzeczywisty sposób porównywania tożsamości przez usługę; nie należy przejmować przykładowych wartości zastępczych.
Zaufanie po stronie usługi: Jeśli Wi-Fi/VPN ma korzystać z certyfikatu klienta, usługa musi ufać łańcuchowi jego CA. W przypadku EAP trzeba dodatkowo sprawdzić, czy urządzenie ufa certyfikatowi serwera Wi-Fi. Żaden z tych warunków nie wynika z samego zaufania do serwera SCEP.

Zakres odpowiedzialności przed zatwierdzeniem zmiany:

Zespół PKI/CA: Sprawdza urząd CA Windows obsługujący SCEP, dostępność /CertSrv/MSCEP_ADMIN i /CertSrv/MSCEP oraz uprawnienia do tworzenia kodów challenge i rejestracji certyfikatów. Haseł challenge, danych dostępu do usługi i kluczy prywatnych nie należy umieszczać w zgłoszeniach ani na zrzutach ekranu. Historyczna wzmianka o Windows 2003 w pomocy Sophos nie oznacza aktualnej deklaracji obsługi tej wersji serwera.
Zespół sieciowy: Sprawdza docelową nazwę FQDN, trasę przez serwer proxy TLS/HTTP oraz ściśle ograniczony dostęp z regionalnych adresów źródłowych w odniesieniu do rzeczywistej topologii; osobno weryfikuje ruch wychodzący urządzeń, powiadomienia push oraz niezależną ścieżkę zarządzania lub dostępu do sieci na wypadek awarii. Nie zastępuje tych testów ogólnym wyłączeniem filtrowania.
Zespół MDM i zespół odpowiedzialny za usługę: Przed konfiguracją ustalają platformę, typ zasady dla urządzenia lub użytkownika oraz tryb rejestracji. Dla opisanej tutaj ścieżki urządzeń Android Enterprise należy użyć Android Enterprise device policy; zasada Work Profile obejmuje inny obszar zarządzania. Poradnik Android Enterprise wyjaśnia wybór tego trybu. Ładunek SCEP dla urządzeń iOS należy rozpatrywać osobno i nie traktować go jako potwierdzenia obsługi w zasadach użytkowników iOS. Wspólne i specyficzne dla platform pola SCEP są sprawdzane oddzielnie w opisanym poniżej pilotażu. Bez potwierdzonego typu zasady i obsługiwanego trybu rejestracji należy wstrzymać proces.

Wstrzymaj zmianę, jeśli planowana tożsamość lub łańcuch zaufania CA nie zostały wyjaśnione, typ albo tryb urządzenia nie odpowiada sprawdzonej zasadzie bądź urządzeniem da się zarządzać tylko przez tę samą sieć Wi-Fi/VPN, która ma zostać zmieniona, i nie ma niezależnej drogi powrotu.

Wystawienie certyfikatu nie oznacza jeszcze przypisania go do Wi-Fi/VPN

Konfiguracja SCEP żąda certyfikatu od urzędu CA. Przed zmianą Wi-Fi/VPN sprawdź osobno:

Pole wyboru certyfikatu w Wi-Fi: W zasadach urządzeń Android Enterprise i zasadach urządzeń iOS pole Identity certificate pozwala wybrać certyfikat z konfiguracji Client certificate w tej samej zasadzie. Ta konfiguracja importuje plik PKCS-#12 (.pfx); jest to inny sposób dostarczenia certyfikatu niż SCEP. Nie potwierdza to możliwości wybrania certyfikatu wystawionego przez SCEP w polu wyboru certyfikatu w Wi-Fi. Sieć Wi-Fi z EAP na Android Enterprise nie może być ukryta: identyfikator SSID musi być rozgłaszany.
Odnowienie i zaufanie do serwera: Import, okres ważności i wymianę certyfikatów PKCS-#12 zaplanuj osobno; SCEP renewal interval nie odnawia ich automatycznie. Nie należy bez sprawdzenia utożsamiać certyfikatu głównego CA serwera EAP w zasadzie Wi-Fi z zaufaniem do serwera SCEP.

VPN również nie ma jednego uniwersalnego sposobu powiązania z SCEP: w przypadku Android Enterprise zasada wybiera już zainstalowaną zarządzaną aplikację VPN z Google Play, a parametry połączenia znajdują się w jej konfiguracji zarządzanej. W iOS uwierzytelnianie certyfikatem i wybór certyfikatu zależą od typu połączenia. Sam ten wybór nie potwierdza możliwości użycia certyfikatu SCEP. Przed pilotażem Wi-Fi/VPN potwierdź obsługiwane przypisanie certyfikatu i zachowanie po odnowieniu dla danej platformy, typu zasady, metody uwierzytelniania i ewentualnego klienta VPN na podstawie właściwej dokumentacji producenta lub w ograniczonym pilotażu. Jeśli brak takiego potwierdzenia, ogranicz pilotaż do wystawienia i odnowienia certyfikatów SCEP; nie rozpoczynaj migracji Wi-Fi/VPN ani nie usuwaj dotychczasowego łańcucha zaufania.

Skonfiguruj SCEP wyłącznie w ograniczonym pilotażu

W Setup > Sophos setup > SCEP uzgodnij z zespołem PKI adres URL serwera SCEP https://<server>/CertSrv/MSCEP i adres challenge https://<server>/CertSrv/MSCEP_ADMIN. Użyj konta z odpowiednimi uprawnieniami w formacie username@domain oraz jego hasła; z PKI sprawdź dozwolone typy znaków w challenge i uprawnienia. Uzgodnione typy znaków wybierz w polu Challenge characters dla hasła challenge przed wykonaniem Save; domyślną długość challenge ustawioną przez Sophos pozostaw bez zmian. Odstępstwo wymagane przez PKI wprowadzaj jedynie jako osobno udokumentowany, zatwierdzony i przetestowany wyjątek. Jeśli aktywny jest serwer proxy HTTP, opcja Use HTTP proxy początkowo obejmuje to połączenie; wyłącz ją tylko wtedy, gdy Sophos Mobile ma świadomie docierać do serwera SCEP z pominięciem proxy.
Wybierz Save i udokumentuj test połączenia z serwerem SCEP. W razie błędu sprawdź z odpowiedzialnymi osobami adres URL, zaufanie do certyfikatu, proxy, uprawnienia i dozwolone źródłowe adresy IP — nie zmieniaj od razu zasad dla wielu urządzeń.
Najpierw utwórz zasadę odpowiednią dla trybu pilotażu lub edytuj istniejącą zasadę. Przy tworzeniu, edycji konfiguracji, zapisywaniu i późniejszym przypisywaniu do grupy pilotażowej skorzystaj z poradnika zasad; wcześniej sprawdź platformę i obsługiwany typ zasady. W tej zasadzie skonfiguruj najpierw Root certificate z certyfikatem CA serwera SCEP, następnie SCEP i SCEP renewal interval. W polach SCEP URL i Challenge instrukcje zasad dla urządzeń Android Enterprise i iOS opisują odpowiednio symbole zastępcze %_SCEPPROXYURL_% i %_CACHALLENGE_%, które odwołują się do skonfigurowanych wcześniej adresów URL serwera SCEP i challenge. Wartości Subject, SAN/UPN, rozmiar klucza oraz jego przeznaczenie uzgodnij z PKI i usługą docelową dla konkretnej platformy. Przypisz zasadę wyłącznie ograniczonej grupie pilotażowej. PKI i MDM wcześniej ustalają, gdzie dla tej właśnie platformy i trybu zasady można obserwować dostarczenie zasady, certyfikat na urządzeniu oraz wystawienie/odnowienie w PKI; jeśli przypisanie do Wi-Fi/VPN również zostało potwierdzone, określają także dziennik usługi. Nie zakładaj jednakowych pól stanu czy nazw dzienników dla wszystkich urządzeń. SCEP renewal interval określa moment wysłania żądania przez urządzenie, nie potwierdza jego powodzenia.
Pola SCEP specyficzne dla platformy: W zasadach urządzeń Android Enterprise ustaw rozpoznawalny Alias name na potrzeby okien wyboru, a w polu Root certificate wybierz certyfikat CA serwera SCEP z tej samej zasady. W zasadach urządzeń iOS uzgodnij CA name z urzędem CA; Retries określa liczbę ponowień po odpowiedzi serwera pending, a Retry delay — odstęp w sekundach. Nie przedstawiaj tych pól iOS jako pól Androida. Key size musi odpowiadać konfiguracji serwera SCEP. W polu Certificate usage uzgodnij z PKI i usługą zamierzone zastosowanie, rozpatrując osobno Use as digital signature lub Use for encryption; nie zakładaj żadnego domyślnego rozmiaru ani domyślnego wyboru.
Dla Type of Subject Alternative Name i Value of Subject Alternative Name osobno zweryfikuj udokumentowany typ i wartość: RFC 822 name dla poprawnego adresu e-mail, DNS name dla nazwy DNS serwera CA lub Uniform resource identifier dla jego pełnego adresu URL. AD user logon name nadal oznacza AD UPN użytkownika. Opis pól nie zastępuje weryfikacji tożsamości na faktycznie wystawionym certyfikacie.
Pierwsze wystawienie po dostarczeniu zasady: Na urządzeniu pilotażowym porównaj wystawcę i łańcuch, Subject oraz SAN/UPN, numer seryjny, początek i koniec ważności oraz zastosowanie klucza z zatwierdzonymi wymaganiami PKI. Rejestracja urządzenia w AD nie liczy się jako wystawienie certyfikatu klienta przez SCEP. Bez zaobserwowanego wystawienia: wstrzymaj proces, nie zatwierdzaj rotacji.
Późniejsze odnowienie: PKI i MDM ustalają okres obserwacji na podstawie interwału oraz ważności certyfikatu. W tym okresie sprawdź na urządzeniu nowy, ważny certyfikat z nowym numerem seryjnym i właściwymi wartościami tożsamości oraz wystawcy, a także potwierdź odpowiednią operację w PKI. Jeśli odnowienia nie można zaobserwować lub nie nastąpiło ono w czasie pilotażu, nie uznawaj rotacji za zweryfikowaną.
Tylko jeśli w pilotażu potwierdzono przypisanie do Wi-Fi/VPN: W dzienniku używanej usługi powiąż skuteczne uwierzytelnienie przed odnowieniem i po nim z tym konkretnym urządzeniem pilotażowym oraz certyfikatem. Bez dziennika usługi lub potwierdzonego przypisania: nie zmieniaj Wi-Fi/VPN.

Rotacja i droga powrotu

Przed zmianą adresu URL SCEP, dostępu do challenge albo CA, a także przed osobno potwierdzoną zmianą profilu Wi-Fi/VPN, zapisz w protokole pilotażu poprzednie i nowe przypisania zasad, kotwice zaufania oraz grupy urządzeń dla każdej klasy urządzeń. PKI, zespół sieciowy i MDM ustalają rzeczywiście dostępną ścieżkę zarządzania niezależną od sieci opartej na zmienianym certyfikacie, osobę odpowiedzialną za lokalne odzyskanie dostępu oraz kryterium zatrzymania. Konkretny sposób ponownego przypisania lub usunięcia zasady i jego skutki dla urządzeń muszą zostać sprawdzone w pilotażu dla danej platformy i trybu rejestracji; nie zakłada się tu uniwersalnej metody przywracania. Według Sophos opcja Uninstall policy jest dostępna tylko dla zasad urządzeń Android, kontenerów Knox i urządzeń iOS; w przypadku innych typów, w tym zasad urządzeń Android Enterprise, należy zamiast tego zaktualizować zasadę lub przypisać inną. Nie dowodzi to jednak, że zainstalowany wcześniej certyfikat CA lub certyfikat klienta zostanie usunięty bądź przywrócony.

Decyzja przed wdrożeniem: Najpierw dostarcz nowy łańcuch zaufania w pilotażu tylko wtedy, gdy dany tryb pozwala na równoległą dystrybucję. Sprawdź nowe wystawienie i rzeczywiste późniejsze odnowienie. Przy planowanej zmianie Wi-Fi/VPN sprawdź dodatkowo potwierdzone przypisanie do profilu i uwierzytelnienie w usłudze przed odnowieniem i po nim. Stare profile i kotwice zaufania usuwaj dopiero po kontrolowanym odbiorze i zaplanowanym wdrożeniu. Nie wycofuj zbyt wcześnie starego CA, jeśli nadal jest potrzebny do istniejących połączeń.

W razie niepowodzenia wybierz działanie w zależności od dostępności urządzenia:

Wstrzymaj wszystkie dalsze przypisania i usunięcia. Zachowaj dotychczasowy CA, profile i kotwice zaufania; włącz osoby odpowiedzialne za PKI, sieć i MDM, korzystając z protokołu pilotażu.
Urządzenie dostępne przez sprawdzoną niezależną ścieżkę: Zespół MDM przywraca udokumentowane wcześniejsze przypisanie zasady, sieci i CA metodą przypisywania/usuwania uprzednio sprawdzoną dla tego trybu; PKI i zespół sieciowy sprawdzają swoje obszary. Jeśli zmieniono Wi-Fi/VPN, ponownie przetestuj uwierzytelnienie w dzienniku usługi.
Urządzenie offline lub bez niezależnej ścieżki: Wcześniej wyznaczona osoba odpowiedzialna za lokalne odzyskanie dostępu korzysta wyłącznie z wcześniej zaplanowanej i przetestowanej lokalnej procedury przywracania; następnie ponownie sprawdza dostępność urządzenia i, jeśli dotyczy, uwierzytelnienie w usłudze. Samo cofnięcie ustawienia w chmurze nie jest potwierdzonym sposobem wycofania zmiany na urządzeniach, które utraciły łączność. Jeśli lokalna procedura nie została sprawdzona, nie twierdź, że możliwe jest bezpieczne zdalne odzyskanie dostępu, ani nie rozszerzaj zakresu zmiany.

Bez zaobserwowanego pierwszego wystawienia, odnowienia i sprawdzonej drogi powrotu produkcyjna zmiana SCEP pozostaje wstrzymana; zmiana Wi-Fi/VPN wymaga dodatkowo potwierdzonego przypisania certyfikatu i skutecznego użycia go przed odnowieniem i po nim.

Granice potwierdzenia: To wersja robocza oparta na źródłach, nieprzetestowana w tenancie ani na urządzeniach. Obsługiwane wersje systemów operacyjnych i serwerów, zachowanie klientów przy odnawianiu bez połączenia z siecią oraz konkretny sposób dopasowywania tożsamości w EAP/VPN trzeba osobno potwierdzić we własnym środowisku.