Serwery MDM warto audytować na macOS 26.4, a nie na 27

W wytycznych Apple dotyczących audytu zmian TLS w systemach 27 kryje się zdanie, które większość administratorów przeczyta pobieżnie: jeżeli urządzenia testowe pracują pod wersją 27 lub nowszą i pojawiają się błędy połączenia, należy powtórzyć test na urządzeniu z wersją 26.4 lub nowszą, ale wcześniejszą niż 27, ponieważ „połączenia niezgodne z wymaganiami są blokowane, a te nieudane połączenia mogą uniemożliwić przetestowanie kolejnych połączeń w danym przepływie pracy”.²

Test na nowym systemie wykrywa jeden wadliwy serwer i ukrywa całą resztę. Na 27 niezgodne połączenie kończy się niepowodzeniem, a zależny od niego przepływ pracy zatrzymuje się. Wszystko, co miało nastąpić dalej, nigdy się nie uruchamia — więc nigdy nie zostaje przetestowane. Na wersjach od 26.4 do 26.x te same problemy ujawniają się jako ostrzeżenia, co oznacza, że jedno przejście pokazuje wszystkie niezgodne serwery, jakie ma się w środowisku.

Dwie rzeczy Apple stwierdza wprost: w wersji 27 lub nowszej „połączenia niezgodne z wymaganiami są blokowane, a komunikaty w dzienniku pojawiają się jako błędy zamiast ostrzeżeń”, a testować należy na wersji 26.4 lub nowszej, ale wcześniejszej niż 27, „aby zidentyfikować wszystkie serwery, których to dotyczy”.² To, że na tych wcześniejszych wersjach połączenia faktycznie dochodzą do skutku, jest interpretacją, a nie cytatem — niemniej zalecenie ma sens wyłącznie przy takim założeniu. Zablokowane połączenie na 26.4 ucięłoby przepływ pracy dokładnie tak samo jak na 27.

Odruch podpowiada, by testować na tej wersji, która wprowadza zmianę. Tutaj ten odruch daje niepełną listę, a resztę odkrywa się pojedynczo, już na produkcji.

W skrócie

Od wersji 27.0 systemów iOS, iPadOS, macOS, watchOS, tvOS i visionOS wybrane procesy systemowe wymuszają ostrzejsze wymagania TLS wobec połączeń związanych z MDM, Declarative Device Management, Automated Device Enrollment, instalacją profili konfiguracyjnych, instalacją aplikacji (również w dystrybucji korporacyjnej) oraz aktualizacjami oprogramowania.¹ Serwery muszą obsługiwać TLS 1.2 lub nowszy, z zestawami szyfrów i certyfikatami zgodnymi z ATS.¹ Serwery SCEP oraz serwery pamięci podręcznej treści są zwolnione z tych wymagań.² Ruch sieciowy generowany przez własną aplikację nie jest objęty zmianą. Audyt warto przeprowadzić na wersjach od 26.4 do 26.x, gdzie naruszenia trafiają do dziennika jako ostrzeżenia zamiast blokować połączenie — z użyciem Network Diagnostics Logging Profile i pliku sysdiagnose.²

Czego faktycznie dotyczy zmiana

Zmiana obejmuje konkretną listę czynności systemowych, a nie ruch sieciowy w ogóle.¹

• Zarządzanie urządzeniami mobilnymi (MDM)
• Declarative Device Management (DDM)
• Automated Device Enrollment
• Instalacja profili konfiguracyjnych
• Instalacja aplikacji, w tym korporacyjna dystrybucja aplikacji
• Aktualizacje oprogramowania

Dwa wyłączenia mają realne znaczenie, bo w obu przypadkach chodzi o serwery, których diagnozowanie zabrałoby administratorowi cały dzień: połączenia z serwerem SCEP podczas instalacji profilu konfiguracyjnego lub rozwiązywania zasobu DDM oraz połączenia z serwerami pamięci podręcznej treści, nawet przy pobieraniu zasobów na potrzeby instalacji aplikacji czy aktualizacji oprogramowania.²

Dla deweloperów, którzy trafili tu z nagłówka, warto powiedzieć to wprost: ruch URLSession we własnej aplikacji nie jest tu tematem. Rzecz dotyczy infrastruktury zarządzania urządzeniami. App Transport Security reguluje warstwę sieciową aplikacji od czasu, gdy aplikacje zaczęły być linkowane z SDK dla iOS 9.0 i macOS 10.11.³ W 27 zmieniło się to, że zestaw procesów systemowych zaczął stosować porównywalne wymagania wobec ruchu zarządzającego.

Lista platform jest szersza, niż sugeruje hasło „firmowa flota Maców”. Apple wymienia iOS, iPadOS, macOS, watchOS, tvOS i visionOS.² Apple TV w sali konferencyjnej i Vision Pro w studiu projektowym rejestrują się przez tę samą infrastrukturę.

Wymagania — prosto ze źródła

Artykuł wsparcia Apple stwierdza, że serwery muszą obsługiwać TLS 1.2 lub nowszy, używać zestawów szyfrów zgodnych z ATS i przedstawiać ważne certyfikaty spełniające standardy ATS.² Szczegóły znajdują się w dokumentacji ATS i to od tej strony należy zaczynać pracę.³

Domyślna ocena zaufania do serwera musi wypaść pomyślnie: nienaruszony podpis, nieprzekroczona data ważności, nazwa zgodna z nazwą DNS serwera oraz łańcuch prowadzący do certyfikatu kotwiczącego wystawionego przez urząd certyfikacji będący częścią systemu klienckiego albo zainstalowany przez użytkownika lub administratora.³

Do tego ATS dokłada:³

• Certyfikat podpisany kluczem RSA o długości co najmniej 2048 bitów lub kluczem ECC o długości co najmniej 256 bitów
• Certyfikat wykorzystujący SHA-2 ze skrótem o długości co najmniej 256 bitów
• TLS 1.2 lub nowszy
• Wymianę danych z użyciem AES-128 lub AES-256
• Utajnianie z wyprzedzeniem (PFS) poprzez wymianę kluczy ECDHE

Dwa ostatnie punkty rzadko trafiają do streszczeń tej zmiany — nie ma ich również w tabeli naruszeń, którą Apple publikuje na potrzeby audytu. Administrator, który naprawi wyłącznie to, co wskazano w dzienniku, wciąż może pozostać niezgodny w zakresie doboru szyfrów.

Audyt, zanim zaboli

Procedura opisana przez Apple jest precyzyjna, a każdy jej krok ma swoje uzasadnienie.²

Urządzenia testowe muszą mieć wersję 26.4 lub nowszą, wcześniejszą niż 27. Na tym polega cała sztuczka. Naruszenia trafiają do dziennika jako ostrzeżenia, połączenia dochodzą do skutku, a przepływ pracy przechodzi do kolejnego serwera.

Należy zainstalować Network Diagnostics Logging Profile, a potem ponownie uruchomić urządzenie. Musi to nastąpić przed jakimkolwiek testem — inaczej zdarzenia w dzienniku nie będą zawierać szczegółów potrzebnych do zidentyfikowania niezgodnych połączeń.

W przypadku Automated Device Enrollment na iPhonie lub iPadzie warto użyć Apple Configuratora dla Maca, aby zainstalować profil, zanim urządzenie dotrze do panelu zarządzania urządzeniami w Asystencie ustawień. Ruch rejestracyjny odbywa się wcześnie, a profil zainstalowany później po prostu go nie obejmie.

Trzeba uruchomić swoje typowe przepływy pracy. Zarejestrować urządzenie, zainstalować aplikacje i profile, przećwiczyć wszystko, co komunikuje się z własnymi serwerami. Chodzi o wygenerowanie ruchu do każdego serwera, którego zmiana może dotyczyć.

Następnie należy zebrać plik sysdiagnose, przenieść go na Maca, rozpakować archiwum i z jego katalogu głównego przefiltrować dziennik:

log show --archive system_logs.logarchive --info \
  -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

Każde zdarzenie niesie ze sobą domenę (Domain), proces (Process), który nawiązał połączenie, oraz ostrzeżenie (Warning) nazywające naruszony warunek. Jedno połączenie może wygenerować kilka ostrzeżeń, jeżeli serwer nie spełnia kilku wymagań naraz.²

Audytem trzeba objąć konfiguracje, nie tylko urządzenia. Wymiary wskazane przez Apple warto przepisać wprost: środowisko (produkcyjne, staging, testowe), typ urządzenia, rola (grupa użytkowników, kiosk, urządzenie współdzielone) oraz typ rejestracji (Automated Device Enrollment, oparta na koncie, oparta na profilu, Shared iPad).² Różne konfiguracje sięgają do różnych serwerów, a czysty wynik audytu jednej z nich nic nie mówi o pozostałych.

Systemu watchOS nie da się audytować w ten sposób. Większość jego komunikacji sieciowej odbywa się poza procesem i polecenie log nie zadziała. Apple wskazuje, że testy na iOS prawdopodobnie zapewniają wystarczające pokrycie dla połączeń Apple Watch.²

Jak czytać naruszenia

Apple dzieli błędy na dwie klasy — i to w drugiej z nich przewracają się serwery wyglądające na całkowicie zgodne.

Ogólne naruszenia zasad ATS, zapisywane jako Warning [ATS violation]:²

W tej tabeli kryje się jedno użyteczne wyłączenie: jeżeli certyfikat, który nie przechodzi oceny zaufania, znajduje się wśród certyfikatów kotwiczących profilu automatycznej rejestracji, żadne działania naprawcze nie są konieczne.²

Naruszenia FCP v2.1, zapisywane jako Warning [ATS FCPv2.1 violation]:²

Ostatni wiersz zaskoczy najwięcej osób. Serwer może spełniać główne wymaganie — negocjować TLS 1.2 z nowoczesnym zestawem szyfrów i ważnym certyfikatem — i mimo to nie przejść kontroli, ponieważ Functional Package for TLS wymaga dodatkowo rozszerzenia extended master secret. Apple zaleca przejście na TLS 1.3 albo, jako minimum, skonfigurowanie TLS 1.2 tak, aby negocjował EMS.²

Jest tu jeszcze niuans, o którym warto pamiętać. Tryb zgodności FCP v2.1 w ATS jest dla aplikacji opcjonalny i włączany świadomie, poprzez NSRequiresNIAPTLSPackageVersion, i powstał z myślą o środowiskach regulowanych.³ To włączenie decyduje o zachowaniu klienckim własnej aplikacji. Nie ma natomiast żadnego wpływu na procesy systemowe w 27, które stosują kontrole FCP v2.1 wobec serwerów niezależnie od tego, czy którakolwiek aplikacja cokolwiek włączyła.

Co zmienia się w 27

W wersji 27 i nowszych niezgodne połączenia są blokowane, a komunikaty w dzienniku pojawiają się jako błędy, a nie ostrzeżenia.²

Apple zaznacza, że część ostrzeżeń nie ma bezpośredniego odpowiednika po stronie błędów, a w przypadku problemów z zestawem szyfrów, wersją TLS i algorytmem podpisu dokładny błąd po stronie klienta „może zależeć od tego, jak serwer obsługuje dany stan”.² Nie należy zatem oczekiwać czystego odwzorowania ostrzeżenie–błąd.

Jedyny konkretny błąd udokumentowany przez Apple dotyczy zablokowanego, nieszyfrowanego HTTP — w tym przekierowania kończącego się na adresie http://:²

Task . finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022
"The resource could not be loaded because the App Transport Security policy
requires the use of a secure connection."

Do sprawdzenia pojedynczego serwera po naprawie służy nscurl: łączy się z użyciem różnych kombinacji wyjątków ATS i zawęża wskazanie, które wymaganie nie jest spełniane — bez pełnego cyklu z sysdiagnose.³

Jak wygląda naprawa

Audyt daje listę domen i naruszeń. Przełożenie jej na zmiany po stronie serwerów rozpada się na trzy przypadki.

Tam, gdzie to możliwe, warto przejść na TLS 1.3. Rozwiązuje to kilka klas naruszeń naraz, zamiast po jednej. Każdy zestaw szyfrów TLS 1.3 zapewnia utajnianie z wyprzedzeniem, więc ostrzeżenie o braku PFS nie może się pojawić. Wymóg extended master secret dotyczy wyłącznie TLS 1.2, więc przestaje obowiązywać. Negocjacja algorytmu podpisu jest z założenia bardziej rygorystyczna. Sama kolumna z zaleceniami naprawczymi Apple mówi, by wszędzie tam, gdzie się da, zaktualizować serwery do negocjowania TLS 1.3, przy TLS 1.2 jako minimum.²

Gdy nie da się wyjść poza TLS 1.2, trzy ustawienia załatwiają większość sprawy. Włączyć rozszerzenie extended master secret — to naruszenie najczęściej zaskakuje skądinąd nowoczesne konfiguracje. Ograniczyć listę zestawów szyfrów do wymiany kluczy ECDHE z AES-128 lub AES-256, co za jednym razem spełnia zarówno wymóg PFS, jak i wymóg szyfru symetrycznego.³ Usunąć algorytm podpisu rsa_pkcs15_sha1 z listy preferencji serwera.

Takie ograniczenie zdarza się częściej, niż mogłoby się wydawać. Load balancer terminujący TLS, urządzenie sprzętowe objęte kontraktem serwisowym albo wbudowany kontroler zarządzający — każde z nich może być powodem, dla którego nowoczesne z pozoru środowisko negocjuje coś przestarzałego.

Problemy z certyfikatami wymagają własnego zapasu czasu. RSA poniżej 2048 bitów, ECDSA poniżej 256 oraz certyfikaty końcowe ze skrótem słabszym niż SHA-256 wymagają ponownego wystawienia, a nie przekonfigurowania. To oznacza wniosek do urzędu certyfikacji, okno serwisowe i uzgodnienia z właścicielem łańcucha. Warto sprawdzić też certyfikaty pośrednie, bo domyślna ocena zaufania przechodzi cały łańcuch aż do kotwicy.³

Jedno wyłączenie oszczędza pracy: jeżeli certyfikat, który nie przechodzi oceny zaufania, znajduje się wśród certyfikatów kotwiczących profilu automatycznej rejestracji, Apple stwierdza, że działania naprawcze nie są wymagane.² Warto to sprawdzić, zanim otworzy się zgłoszenie.

Każdą poprawkę lepiej weryfikować osobno, niż powtarzać cały audyt. nscurl łączy się z pojedynczym serwerem, używając różnych kombinacji wyjątków ATS, co dokładnie wskazuje, które wymaganie wciąż nie jest spełniane.³ Pełny cykl z sysdiagnose przy każdej iteracji to powolna pętla, gdy czeka się na ponowne wdrożenie po stronie dostawcy.

Dlaczego zapas czasu ma znaczenie

Apple mówi wprost, że aktualizacja konfiguracji serwerów „może wymagać znacznego czasu, zwłaszcza w przypadku serwerów utrzymywanych przez zewnętrznych dostawców”.²

To zdanie jest powodem, by przeprowadzić audyt teraz, a nie dopiero wtedy, gdy 27 trafi do szerokiej dystrybucji. Objęte zmianą serwery często nie należą do nas. Punkty końcowe dostawcy MDM, partner dystrybuujący oprogramowanie, dostawca tożsamości pośredniczący w rejestracji. Dowiedzieć się w październiku, że dostawca potrzebuje kwartału na włączenie EMS na swoich punktach końcowych TLS 1.2, to zupełnie inny problem niż dowiedzieć się tego w sierpniu.

Audyt daje listę domen i procesów, które się z nimi łączyły. Właśnie tę listę wysyła się dostawcom, a jej konkretność decyduje o tym, czy sprawa zostanie potraktowana priorytetowo. „Wasz serwer nie spełnia nowych wymagań Apple” łatwo odłożyć na później. „Wasz punkt końcowy pod tą domeną wynegocjował TLS 1.2 bez extended master secret, co systemy 27 blokują dla ruchu rejestracyjnego” — już nie.

Ma to ten sam kształt co inne zmiany w tym wydaniu. macOS 27 przestał pytać, zanim odmówi dostępu do kontenera innego zespołu, a obrazki w pozycjach menu zależą teraz od tego, z którym SDK aplikacja została zlinkowana. W każdym z tych przypadków platforma usunęła jakiś sygnał albo zacieśniła domyślne zachowanie, a awaria przychodzi pod postacią czegoś zupełnie innego. Tutaj tym „czymś innym” jest rejestracja, która się zawiesza.

Najważniejsze wnioski

Dla administratorów IT: - Audyt należy prowadzić na wersjach od 26.4 do 26.x. Test na 27 zatrzymuje się na pierwszym zablokowanym połączeniu i ukrywa wszystko, co następuje po nim w tym samym przepływie pracy. - Network Diagnostics Logging Profile trzeba zainstalować przed testami, a urządzenie ponownie uruchomić — inaczej dzienniki nie wskażą serwerów. - Objąć audytem konfiguracje, nie urządzenia: środowisko, typ urządzenia, rola i typ rejestracji — każde z nich sięga do innych serwerów. - Dostawcom wysyłać domenę, proces i konkretne naruszenie. Zapas czasu po stronie serwerów zewnętrznych jest tu ograniczeniem krytycznym.

Dla deweloperów MDM i systemów zarządzania urządzeniami: - Serwery SCEP i serwery pamięci podręcznej treści są zwolnione. Nie warto poświęcać im czasu w audycie. - Naruszenia ATS FCPv2.1 to kategoria osobna od ogólnych naruszeń zasad ATS, a TLS 1.2 bez EMS najłatwiej przeoczyć. - W watchOS polecenie log nie zadziała. Połączenia Watcha należy pokryć testami na iOS.

Dla wszystkich, którzy czytają o tym w nagłówkach: - Ruch URLSession we własnej aplikacji się nie zmienił. Rzecz dotyczy procesów systemowych obsługujących ruch zarządzający, rejestracyjny, instalacyjny i aktualizacyjny.

FAQ

Czy dotyczy to zapytań sieciowych w mojej aplikacji?

Nie. Zmiana obejmuje procesy systemowe związane z MDM, DDM, Automated Device Enrollment, instalacją profili konfiguracyjnych, instalacją aplikacji oraz aktualizacjami oprogramowania.¹ App Transport Security reguluje warstwę sieciową aplikacji osobno, od czasów SDK dla iOS 9.0 i macOS 10.11.³

Dlaczego audyt na starszej wersji systemu?

Ponieważ na 27 błędy blokują. Apple stwierdza, że niezgodne połączenia są blokowane, a „te nieudane połączenia mogą uniemożliwić przetestowanie kolejnych połączeń w danym przepływie pracy”, i zaleca testy na wersji 26.4 lub nowszej, ale wcześniejszej niż 27, aby zidentyfikować wszystkie serwery, których to dotyczy.² Na tamtych wersjach naruszenia trafiają do dziennika jako ostrzeżenia, a połączenia mimo to dochodzą do skutku.

Które serwery są zwolnione?

Serwery SCEP — podczas instalacji profilu konfiguracyjnego lub rozwiązywania zasobu DDM — oraz serwery pamięci podręcznej treści, nawet przy pobieraniu zasobów związanych z instalacją aplikacji lub aktualizacjami oprogramowania.²

Mój serwer obsługuje TLS 1.2 z ważnym certyfikatem. Czy mimo to może nie przejść kontroli?

Tak. Kontrole FCP v2.1 obejmują TLS 1.2 wynegocjowany bez rozszerzenia extended master secret, certyfikat podpisany algorytmem nieogłoszonym w ClientHello oraz algorytmy podpisu rsa_pkcs15_sha1.² ATS wymaga ponadto AES-128 lub AES-256 oraz utajniania z wyprzedzeniem poprzez ECDHE.³

Czy włączenie zgodności z NIAP w mojej aplikacji cokolwiek tu zmienia?

Nie, choć obie rzeczy łatwo pomylić. NSRequiresNIAPTLSPackageVersion przełącza zachowanie klienckie własnej aplikacji na ostrzejszy tryb FCP, z myślą o środowiskach regulowanych.³ Procesy systemowe w 27 stosują własne wymagania wobec ruchu zarządzającego, niezależnie od tego.

Źródła