Behöver du ett VPN för Apple MDM? Tre åtkomstbehov, ett svar

Frågan är sällan om administration av Apple-enheter behöver kryptering, för det behöver den. Den verkliga frågan är om din flotta behöver ett generellt VPN innan en Mac eller iPad ens kan administreras, och för de flesta internetadministrerade utrullningar är svaret nej. Apple låter enheten nå en administrationstjänst enligt sitt eget schema, och trafiken som spelar roll är en signerad kommandokanal, inte en skrivbordssession. Om det fungerar för dig beror på tre villkor, och de är lätta att blanda ihop eftersom de utifrån alla ser ut som fjärråtkomst.

Namnge behovet innan du väljer en transport

Administrationskommandon och konfigurationsprofiler är ett behov, interaktiv skärmdelning är ett andra, och att nå en privat intern applikation är ett tredje. De har olika ägare, olika autentisering och ofta mycket olika acceptabel exponering. Att slå ihop dem är hur en flotta till slut får en offentlig portlista som ingen kan försvara.

De tre behoven delar inte en transport:

Förvirringen börjar oftast med en gammal checklista för servern. Ett historiskt dokument om OS X Server listar en lång uppsättning portar, och någon vidarebefordrar alla vid kanten eftersom administrationstjänsten finns där inne någonstans. Det är inte en administrationsarkitektur, och det vidgar den exponerade ytan långt bortom det kontrollplan du försökte publicera.

Vad pushnotisen faktiskt gör

I Apples dokumenterade flöde skickar administrationsservern en APNs-notis för att tala om för enheten att arbete väntar. Enheten öppnar sedan en anslutning till administrationsservern och begär sina kommandon. Pushen är en dörrklocka, inte en tunnel: den bär ingen godtycklig nyttolast, ingen fjärrskrivbordssession och ingen annan apps trafik.

Enheten måste alltså vara registrerad hos den avsedda tjänsten, lita på de förväntade slutpunkterna och kunna nå både administrationstjänsten och de Apple-tjänster som flödet är beroende av. Apples vägledning för nätverksförberedelse listar dessa beroenden, och de är inte förhandlingsbara delar av flödet. En administrationsserver som bara finns inne i ditt nätverk behöver fortfarande en stödd väg som enheten faktiskt kan använda. Att kalla det MDM gör inte en ouppnåelig slutpunkt uppnåelig.

Håll de tillåtna vägarna explicit angivna, inklusive alla proxy- och TLS-inspektionspolicyer i mitten. En inspektionsapparat som bryter den förväntade certifikatkedjan kommer att se exakt ut som en trasig registrering.

När VPN är fel svar

Om din administrationstjänst är publicerad på internet med ett korrekt certifikat och enheten initierar varje anslutning, lägger ett VPN till ett hopp utan att lägga till en kontroll. Enheten autentiserar sig redan med sin registreringsidentitet, och servern avgör redan vilka kommandon den accepterar. En tunnel framför det ändrar nätverksvägen, inte förtroendebeslutet.

Samma kontrollplan kan också leverera själva VPN-profilen. Den ordningen spelar roll: en hanterad VPN-konfiguration anländer som bara ytterligare en nyttolast, så enheten behöver inte att tunneln finns innan den kan ta emot profilen som skapar den.

När VPN är rätt svar

Det finns flottor där administrationens slutpunkt aldrig borde vara nåbar från internet, och det är en legitim design, inte brist på mod. Reglerade miljöer, små interna IT-team och servrar som också är värdar för andra administrativa gränssnitt hamnar ofta där. I så fall är en skyddad åtkomstväg framför administrationstjänsten medveten arkitektur, inte en nödlösning.

Skärmdelning och åtkomst till privata appar hör vanligtvis också till den sidan av linjen. Båda exponerar mycket mer än en kommandokanal, och båda förtjänar sin egen autentisering i stället för att rida på registreringsidentiteten.

Bootstrap-fällan som bryter återställningen

Här är felet jag skulle designa mot: den enda vägen till administrationstjänsten går genom ett VPN, och VPN-profilen eller inloggningsuppgifterna på enheten har gått ut. Enheten kan inte nå servern för att hämta ett ersättningskommando, och servern kan inte skjuta något genom en tunnel som inte kommer upp. Återställningen beror nu på en användare som kan vara hundratals mil bort.

Håll en andra, oberoende väg för återställning, vare sig det är en administrationskanal utanför bandet, en lokal administratör eller en administrationstjänst som förblir nåbar utan tunneln. Testa den medan allt fungerar, för du får inget rent test under en incident.

Skriv sedan ner vilket av de tre behoven varje väg tjänar, och ta bort portvidarebefordringarna som inte tjänar något av dem. En flotta som kan administreras utan en generell tunnel och som fortfarande kan repareras när tunneln är det som gick sönder, är resultatet det är värt att designa för.