Hebt u een VPN nodig voor Apple MDM? Drie toegangsbehoeften, één antwoord
Apple MDM draait op APNs en door het apparaat gestart HTTPS, niet op een LAN-tunnel. Scheid beheer, schermdelen en toegang tot private apps voordat u een VPN toevoegt.
De vraag is zelden of beheer van Apple-apparaten versleuteling nodig heeft, want dat heeft het. De echte vraag is of uw vloot een algemene VPN nodig heeft voordat een Mac of iPad überhaupt beheerd kan worden, en voor de meeste via internet beheerde uitrollingen is het antwoord nee. Apple laat het apparaat volgens zijn eigen schema een beheerdienst bereiken, en het verkeer dat ertoe doet is een ondertekend commandokanaal, geen desktopsessie. Of dat voor u werkt hangt van drie voorwaarden af, en ze zijn makkelijk te verwarren omdat ze van buiten allemaal op externe toegang lijken.
Benoem de behoefte voordat u een transport kiest
Beheeropdrachten en configuratieprofielen zijn één behoefte, interactief schermdelen is een tweede, en het bereiken van een private interne applicatie is een derde. Ze hebben verschillende eigenaren, verschillende authenticatie en vaak een heel andere aanvaardbare blootstelling. Ze op één hoop gooien is hoe een vloot eindigt met een openbare poortenlijst die niemand kan verdedigen.
De drie behoeften delen geen 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 |
De verwarring begint meestal met een oude serverchecklist. Een historisch document over OS X Server noemt een lange reeks poorten, en iemand stuurt ze allemaal door aan de rand omdat de beheerdienst daar ergens in zit. Dat is geen beheerarchitectuur, en het verbreedt het blootgestelde oppervlak veel verder dan het controlevlak dat u probeerde te publiceren.
Wat de pushmelding werkelijk doet
In de gedocumenteerde stroom van Apple stuurt de beheerserver een APNs-melding om het apparaat te vertellen dat er werk wacht. Het apparaat opent dan een verbinding naar de beheerserver en vraagt om zijn opdrachten. De push is een deurbel, geen tunnel: hij draagt geen willekeurige lading, geen externe desktopsessie en geen verkeer van een andere app.
Het apparaat moet dus zijn ingeschreven bij de bedoelde dienst, de verwachte eindpunten vertrouwen en zowel de beheerdienst als de Apple-diensten waarvan de stroom afhangt kunnen bereiken. De richtlijn van Apple voor netwerkvoorbereiding noemt die afhankelijkheden, en ze zijn geen onderhandelbare onderdelen van de stroom. Een beheerserver die alleen binnen uw netwerk bestaat heeft nog steeds een ondersteund pad nodig dat het apparaat werkelijk kan gebruiken. Het MDM noemen maakt een onbereikbaar eindpunt niet bereikbaar.
Houd de toegestane paden expliciet, inclusief elk proxy- en TLS-inspectiebeleid in het midden. Een inspectieapparaat dat de verwachte certificaatketen breekt ziet er precies uit als een kapotte inschrijving.
Wanneer de VPN het verkeerde antwoord is
Als uw beheerdienst op internet is gepubliceerd met een juist certificaat en het apparaat elke verbinding start, voegt een VPN een sprong toe zonder een controle toe te voegen. Het apparaat authenticeert zich al met zijn inschrijvingsidentiteit, en de server beslist al welke opdrachten hij accepteert. Een tunnel daarvoor verandert het netwerkpad, niet de vertrouwensbeslissing.
Hetzelfde controlevlak kan ook het VPN-profiel zelf leveren. Die volgorde is belangrijk: een beheerde VPN-configuratie komt binnen als gewoon weer een lading, dus het apparaat heeft de tunnel niet nodig voordat het het profiel kan ontvangen dat hem aanmaakt.
Wanneer de VPN het juiste antwoord is
Er zijn vloten waarbij het beheereindpunt nooit vanaf internet bereikbaar zou moeten zijn, en dat is een legitiem ontwerp, geen gebrek aan moed. Gereguleerde omgevingen, kleine interne IT-teams en servers die ook andere beheerinterfaces hosten belanden daar vaak. In dat geval is een beschermd toegangspad voor de beheerdienst bewuste architectuur, geen noodoplossing.
Schermdelen en toegang tot private applicaties horen meestal ook aan die kant van de lijn. Beide leggen veel meer bloot dan een commandokanaal, en beide verdienen hun eigen authenticatie in plaats van mee te liften op de inschrijvingsidentiteit.
De bootstrap-val die herstel breekt
Hier is de storing waartegen ik zou ontwerpen: het enige pad naar de beheerdienst loopt via een VPN, en het VPN-profiel of de inloggegevens op het apparaat zijn verlopen. Het apparaat kan de server niet bereiken om een vervangende opdracht te halen, en de server kan niets door een tunnel duwen die niet opkomt. Herstel hangt nu af van een gebruiker die honderden kilometers verderop kan zijn.
Houd een tweede, onafhankelijk pad voor herstel, of dat nu een out-of-band beheerkanaal, een lokale beheerder of een beheerdienst is die zonder de tunnel bereikbaar blijft. Test het terwijl alles werkt, want tijdens een incident krijgt u geen schone test.
Schrijf daarna op welke van de drie behoeften elk pad dient, en verwijder de poortdoorschakelingen die geen van alle dienen. Een vloot die zonder algemene tunnel beheerd kan worden, en die nog gerepareerd kan worden als de tunnel het is dat kapotging, is het resultaat waarvoor het de moeite loont te ontwerpen.