Har du brug for en VPN til Apple MDM? Tre adgangsbehov, ét svar
Apple MDM kører på APNs og HTTPS, som enheden selv starter, ikke på en LAN-tunnel. Adskil administration, skærmdeling og adgang til private apps, før du tilføjer en VPN.
Spørgsmålet er sjældent, om Apple-enhedsadministration har brug for kryptering, for det har den. Det egentlige spørgsmål er, om din flåde har brug for en generel VPN, før en Mac eller iPad overhovedet kan administreres, og for de fleste internetadministrerede installationer er svaret nej. Apple lader enheden nå en administrationstjeneste efter sin egen tidsplan, og den trafik, der betyder noget, er en signeret kommandokanal, ikke en skrivebordssession. Om det virker for dig afhænger af tre betingelser, og de er lette at forveksle, fordi de udefra alle ligner fjernadgang.
Navngiv behovet, før du vælger en transport
Administrationskommandoer og konfigurationsprofiler er ét behov, interaktiv skærmdeling er et andet, og adgang til en privat intern applikation er et tredje. De har forskellige ejere, forskellig godkendelse og ofte meget forskellig acceptabel eksponering. At slå dem sammen er måden, hvorpå en flåde ender med en offentlig portliste, som ingen kan forsvare.
De tre behov deler ikke én transport:
| 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 |
Forvirringen starter normalt med en gammel servertjekliste. Et historisk OS X Server-dokument lister et langt sæt porte, og nogen videresender dem alle ved kanten, fordi administrationstjenesten er derinde et sted. Det er ikke en administrationsarkitektur, og det udvider den eksponerede overflade langt ud over det kontrolplan, du forsøgte at udgive.
Hvad push-notifikationen faktisk gør
I Apples dokumenterede flow sender administrationsserveren en APNs-notifikation for at fortælle enheden, at der venter arbejde. Enheden åbner derefter en forbindelse til administrationsserveren og beder om sine kommandoer. Pushet er en dørklokke, ikke en tunnel: det bærer ingen vilkårlig nyttelast, ingen fjernskrivebordssession og ingen andre appers trafik.
Enheden skal altså være tilmeldt den tilsigtede tjeneste, stole på de forventede endepunkter og kunne nå både administrationstjenesten og de Apple-tjenester, som flowet afhænger af. Apples vejledning til netværksforberedelse lister disse afhængigheder, og de er ikke forhandlingsbare dele af flowet. En administrationsserver, der kun findes inde i dit netværk, har stadig brug for en understøttet vej, som enheden faktisk kan bruge. At kalde det MDM gør ikke et uopnåeligt endepunkt opnåeligt.
Hold de tilladte veje eksplicitte, inklusive enhver proxy- og TLS-inspektionspolitik i midten. Et inspektionsapparat, der bryder den forventede certifikatkæde, vil se præcis ud som en brudt tilmelding.
Når VPN'en er det forkerte svar
Hvis din administrationstjeneste er udgivet på internettet med et korrekt certifikat, og enheden starter hver forbindelse, tilføjer en VPN et hop uden at tilføje en kontrol. Enheden godkender allerede med sin tilmeldingsidentitet, og serveren beslutter allerede, hvilke kommandoer den vil acceptere. En tunnel foran det ændrer netværksvejen, ikke tillidsbeslutningen.
Det samme kontrolplan kan også levere selve VPN-profilen. Den rækkefølge betyder noget: en administreret VPN-konfiguration ankommer som blot endnu en nyttelast, så enheden behøver ikke tunnelen til at eksistere, før den kan modtage profilen, der opretter den.
Når VPN'en er det rigtige svar
Der er flåder, hvor administrationsendepunktet aldrig bør være tilgængeligt fra internettet, og det er et legitimt design snarere end mangel på mod. Regulerede miljøer, små interne IT-teams og servere, der også hoster andre administrative grænseflader, ender ofte der. I så fald er en beskyttet adgangsvej foran administrationstjenesten bevidst arkitektur, ikke en nødløsning.
Skærmdeling og adgang til private apps hører normalt også til på den side af linjen. Begge afslører langt mere end en kommandokanal, og begge fortjener deres egen godkendelse i stedet for at køre på tilmeldingsidentiteten.
Bootstrap-fælden, der ødelægger gendannelse
Her er den fejl, jeg ville designe imod: den eneste vej til administrationstjenesten går gennem en VPN, og VPN-profilen eller legitimationsoplysningen på enheden er udløbet. Enheden kan ikke nå serveren for at hente en erstatningskommando, og serveren kan ikke skubbe noget gennem en tunnel, der ikke kommer op. Gendannelse afhænger nu af en bruger, der måske er hundreder af kilometer væk.
Hold en anden, uafhængig vej til gendannelse, hvad enten det er en out-of-band-administrationskanal, en lokal administrator eller en administrationstjeneste, der forbliver tilgængelig uden tunnelen. Test den, mens alt virker, for du får ikke en ren test under en hændelse.
Skriv derefter ned, hvilke af de tre behov hver vej tjener, og fjern de portvideresendelser, der ikke tjener nogen af dem. En flåde, der kan administreres uden en generel tunnel og stadig kan repareres, når tunnelen er det, der gik i stykker, er det resultat, der er værd at designe for.