Het jy 'n VPN nodig vir Apple MDM? Drie toegangsbehoeftes, een antwoord
Apple MDM werk op APNs en HTTPS wat deur die toestel begin word, nie op 'n LAN-tonnel nie. Skei bestuur, skermdeling en toegang tot private programme voordat jy 'n VPN byvoeg.
Die vraag is selde of Apple-toestelbestuur enkripsie nodig het, want dit het dit nodig. Die werklike vraag is of jou vloot 'n algemene VPN nodig het voordat 'n Mac of iPad hoegenaamd bestuur kan word, en vir die meeste ontplooiings wat oor die internet bestuur word, is die antwoord nee. Apple laat die toestel 'n bestuursdiens volgens sy eie skedule bereik, en die verkeer wat saak maak is 'n ondertekende opdragkanaal eerder as 'n lessenaarsessie. Of dit vir jou werk, kom neer op drie voorwaardes, en hulle is maklik om te verwar want van buite lyk hulle almal soos afstandtoegang.
Noem die behoefte voordat jy 'n vervoerpad kies
Bestuursopdragte en konfigurasieprofiele is een behoefte, interaktiewe skermdeling is 'n tweede, en die bereik van 'n private interne program is 'n derde. Hulle het verskillende eienaars, verskillende verifikasie, en dikwels baie verskillende aanvaarbare blootstelling. Om hulle saam te gooi is hoe 'n vloot uiteindelik 'n publieke poortlys kry wat niemand kan verdedig nie.
Die drie behoeftes deel nie 'n vervoerpad nie:
| 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 |
Die verwarring begin gewoonlik by 'n ou bediener-kontrolelys. 'n Historiese OS X Server-dokument lys 'n lang stel poorte, en iemand stuur almal by die rand aan omdat die bestuursdiens iewers daar is. Dit is nie 'n bestuursargitektuur nie, en dit verbreed die blootgestelde oppervlak ver verby die beheervlak wat jy wou publiseer.
Wat die stootkennisgewing werklik doen
In Apple se gedokumenteerde vloei stuur die bestuursbediener 'n APNs-kennisgewing om die toestel te laat weet dat daar werk wag. Die toestel maak dan 'n verbinding met die bestuursbediener oop en vra vir sy opdragte. Die stoot is 'n deurklokkie, nie 'n tonnel nie: dit dra geen willekeurige vrag, geen afstand-lessenaarsessie en geen ander program se verkeer nie.
Die toestel moet dus by die beoogde diens ingeskryf wees, die verwagte eindpunte vertrou, en beide die bestuursdiens en die Apple-dienste waarvan die vloei afhang kan bereik. Apple se riglyne vir netwerkvoorbereiding lys daardie afhanklikhede, en hulle is nie onderhandelbare dele van die vloei nie. 'n Bestuursbediener wat net binne jou netwerk bestaan, het steeds 'n ondersteunde pad nodig wat die toestel werklik kan gebruik. Om dit MDM te noem, maak nie 'n onbereikbare eindpunt bereikbaar nie.
Hou die toegelate paaie eksplisiet, insluitend watter proxy- en TLS-inspeksiebeleid ook al in die middel sit. 'n Inspeksietoestel wat die verwagte sertifikaatketting breek, sal presies soos 'n gebreekte inskrywing lyk.
Wanneer die VPN die verkeerde antwoord is
As jou bestuursdiens op die internet gepubliseer is met 'n behoorlike sertifikaat en die toestel begin elke verbinding, voeg 'n VPN 'n sprong by sonder om 'n beheer by te voeg. Die toestel verifieer reeds met sy inskrywingsidentiteit, en die bediener besluit reeds watter opdragte hy sal aanvaar. 'n Tonnel daarvoor verander die netwerkpad, nie die vertrouensbesluit nie.
Dieselfde beheervlak kan ook die VPN-profiel self lewer. Daardie volgorde maak saak: 'n bestuurde VPN-konfigurasie kom as bloot nog 'n vrag, so die toestel het nie die tonnel nodig om te bestaan voordat dit die profiel kan ontvang wat dit skep nie.
Wanneer die VPN die regte antwoord is
Daar is vlote waar die bestuurs-eindpunt nooit oor die internet bereikbaar moet wees nie, en dit is 'n wettige ontwerp eerder as 'n gebrek aan durf. Gereguleerde omgewings, klein interne IT-spanne en bedieners wat ook ander administratiewe koppelvlakke huisves, beland dikwels daar. In daardie geval is 'n beskermde toegangspad voor die bestuursdiens doelbewuste argitektuur, nie 'n noodoplossing nie.
Skermdeling en toegang tot private programme hoort gewoonlik ook aan daardie kant van die lyn. Albei stel baie meer bloot as 'n opdragkanaal, en albei verdien hul eie verifikasie in plaas daarvan om op die inskrywingsidentiteit te ry.
Die selflaai-strik wat herstel breek
Hier is die faling waarteen ek sou ontwerp: die enigste pad na die bestuursdiens loop deur 'n VPN, en die VPN-profiel of geloofsbrief op die toestel het verval. Die toestel kan nie die bediener bereik om 'n vervangingsopdrag te haal nie, en die bediener kan niks deur 'n tonnel stoot wat nie opkom nie. Herstel hang nou af van 'n gebruiker wat honderde myle ver kan wees.
Hou 'n tweede, onafhanklike pad vir herstel, of dit nou 'n buitebandse bestuurskanaal, 'n plaaslike administrateur of 'n bestuursdiens is wat sonder die tonnel bereikbaar bly. Toets dit terwyl alles werk, want jy kry nie 'n skoon toets tydens 'n voorval nie.
Skryf dan neer watter van die drie behoeftes elke pad dien, en verwyder die poortaansture wat nie een van hulle dien nie. 'n Vloot wat sonder 'n algemene tonnel bestuur kan word, en steeds herstel kan word wanneer die tonnel die ding is wat gebreek het, is die uitkoms waarvoor dit die moeite werd is om te ontwerp.