Czy potrzebujesz VPN do Apple MDM? Trzy potrzeby dostępu, jedna odpowiedź
Apple MDM działa na APNs i HTTPS inicjowanym przez urządzenie, a nie na tunelu LAN. Oddziel zarządzanie, udostępnianie ekranu i dostęp do prywatnych aplikacji, zanim dodasz VPN.
Pytanie rzadko brzmi, czy zarządzanie urządzeniami Apple wymaga szyfrowania, bo wymaga. Prawdziwe pytanie brzmi, czy Twoja flota potrzebuje uniwersalnego VPN, zanim Maca lub iPada można w ogóle zarządzać, a w większości wdrożeń zarządzanych przez internet odpowiedź brzmi nie. Apple pozwala urządzeniu dotrzeć do usługi zarządzania według własnego harmonogramu, a ruch, który ma znaczenie, to podpisany kanał poleceń, a nie sesja pulpitu. Czy to zadziała u Ciebie, zależy od trzech warunków, i łatwo je pomylić, bo z zewnątrz wszystkie wyglądają jak dostęp zdalny.
Nazwij potrzebę, zanim wybierzesz transport
Polecenia zarządzania i profile konfiguracji to jedna potrzeba, interaktywne udostępnianie ekranu to druga, a dotarcie do prywatnej aplikacji wewnętrznej to trzecia. Mają różnych właścicieli, różne uwierzytelnianie i często bardzo różną akceptowalną ekspozycję. Wrzucanie ich do jednego worka to sposób, w jaki flota kończy z publiczną listą portów, której nikt nie potrafi obronić.
Te trzy potrzeby nie dzielą jednego transportu:
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
Zamieszanie zwykle zaczyna się od starej listy kontrolnej serwera. Historyczny dokument dotyczący OS X Server wymienia długi zestaw portów, a ktoś przekierowuje je wszystkie na brzegu, bo usługa zarządzania jest gdzieś w środku. To nie jest architektura zarządzania i rozszerza eksponowaną powierzchnię daleko poza płaszczyznę sterowania, którą próbowałeś opublikować.
Co faktycznie robi powiadomienie push
W udokumentowanym przepływie Apple serwer zarządzania wysyła powiadomienie APNs, aby powiedzieć urządzeniu, że czeka praca. Następnie urządzenie otwiera połączenie z serwerem zarządzania i prosi o swoje polecenia. Push to dzwonek do drzwi, a nie tunel: nie przenosi żadnego dowolnego ładunku, żadnej zdalnej sesji pulpitu ani ruchu innej aplikacji.
Urządzenie musi więc być zarejestrowane w zamierzonej usłudze, ufać oczekiwanym punktom końcowym i umieć dotrzeć zarówno do usługi zarządzania, jak i do usług Apple, od których zależy przepływ. Wskazówki Apple dotyczące przygotowania sieci wymieniają te zależności i nie są negocjowalnymi częściami przepływu. Serwer zarządzania istniejący tylko w Twojej sieci nadal potrzebuje obsługiwanej ścieżki, której urządzenie naprawdę może użyć. Nazwanie tego MDM nie czyni nieosiągalnego punktu końcowego osiągalnym.
Utrzymuj dozwolone ścieżki w sposób jawny, łącznie z polityką proxy i inspekcji TLS pośrodku. Urządzenie inspekcyjne, które łamie oczekiwany łańcuch certyfikatów, będzie wyglądać dokładnie jak zepsuta rejestracja.
Kiedy VPN jest złą odpowiedzią
Jeśli Twoja usługa zarządzania jest opublikowana w internecie z poprawnym certyfikatem, a każde połączenie inicjuje urządzenie, VPN dodaje przeskok, nie dodając kontroli. Urządzenie już uwierzytelnia się swoją tożsamością rejestracji, a serwer już decyduje, które polecenia przyjmie. Tunel przed tym zmienia ścieżkę sieciową, a nie decyzję o zaufaniu.
Ta sama płaszczyzna sterowania może też dostarczyć sam profil VPN. Ta kolejność ma znaczenie: zarządzana konfiguracja VPN przychodzi jako po prostu kolejny ładunek, więc urządzenie nie potrzebuje istniejącego tunelu, zanim otrzyma profil, który go tworzy.
Kiedy VPN jest właściwą odpowiedzią
Są floty, w których punkt końcowy zarządzania nigdy nie powinien być osiągalny z internetu, i to jest uzasadniony projekt, a nie brak odwagi. Środowiska regulowane, małe wewnętrzne zespoły IT i serwery hostujące także inne interfejsy administracyjne często tam trafiają. W takim przypadku chroniona ścieżka dostępu przed usługą zarządzania to świadoma architektura, a nie obejście.
Udostępnianie ekranu i dostęp do prywatnych aplikacji zwykle również należą do tej strony linii. Oba ujawniają znacznie więcej niż kanał poleceń i oba zasługują na własne uwierzytelnianie zamiast jazdy na tożsamości rejestracji.
Pułapka rozruchu, która psuje odzyskiwanie
Oto awaria, przeciw której bym projektował: jedyna ścieżka do usługi zarządzania prowadzi przez VPN, a profil VPN lub poświadczenia na urządzeniu wygasły. Urządzenie nie może dotrzeć do serwera, aby pobrać polecenie zastępcze, a serwer nie może nic przepchnąć przez tunel, który się nie podniesie. Odzyskiwanie zależy teraz od użytkownika, który może być setki kilometrów dalej.
Utrzymuj drugą, niezależną ścieżkę odzyskiwania, czy to kanał zarządzania poza pasmem, lokalny administrator, czy usługa zarządzania pozostająca osiągalna bez tunelu. Przetestuj ją, gdy wszystko działa, bo podczas incydentu nie dostaniesz czystego testu.
Następnie zapisz, której z trzech potrzeb służy każda ścieżka, i usuń przekierowania portów, które nie służą żadnej z nich. Flota, którą można zarządzać bez uniwersalnego tunelu i którą nadal można naprawić, gdy to tunel się zepsuł, jest wynikiem, dla którego warto projektować.