Tarvitsetko VPN:n Apple MDM:ää varten? Kolme käyttötarvetta, yksi vastaus

Kysymys on harvoin siitä, tarvitseeko Apple-laitteiden hallinta salausta, koska se tarvitsee. Todellinen kysymys on, tarvitseeko laitekantasi yleiskäyttöisen VPN:n ennen kuin Macia tai iPadia voi ylipäätään hallita, ja useimmissa internetin kautta hallittavissa käyttöönotoissa vastaus on ei. Apple antaa laitteen tavoittaa hallintapalvelun oman aikataulunsa mukaan, ja merkityksellinen liikenne on allekirjoitettu komentokanava, ei työpöytäistunto. Toimiiko tämä sinulla, riippuu kolmesta ehdosta, ja ne on helppo sekoittaa, koska ulkopuolelta ne kaikki näyttävät etäkäytöltä.

Nimeä tarve ennen kuin valitset kuljetuksen

Hallintakomennot ja kokoonpanoprofiilit ovat yksi tarve, vuorovaikutteinen näytönjako toinen ja pääsy yksityiseen sisäiseen sovellukseen kolmas. Niillä on eri omistajat, eri todennus ja usein hyvin erilainen hyväksyttävä näkyvyys. Niiden lyöminen yhteen on se tapa, jolla laitekanta päätyy julkiseen porttiluetteloon, jota kukaan ei pysty puolustamaan.

Kolme tarvetta eivät jaa yhtä kuljetusta:

Sekaannus alkaa yleensä vanhasta palvelimen tarkistuslistasta. Historiallinen OS X Server -asiakirja luettelee pitkän joukon portteja, ja joku välittää ne kaikki reunassa, koska hallintapalvelu on jossain siellä. Se ei ole hallinta-arkkitehtuuri, ja se laajentaa altistettua pintaa paljon kauemmas hallintatasosta, jota yritit julkaista.

Mitä push-ilmoitus itse asiassa tekee

Applen dokumentoidussa kulussa hallintapalvelin lähettää APNs-ilmoituksen kertoakseen laitteelle, että työtä odottaa. Sitten laite avaa yhteyden hallintapalvelimeen ja pyytää komentonsa. Push on ovikello, ei tunneli: se ei kuljeta mielivaltaista hyötykuormaa, ei etätyöpöytäistuntoa eikä muun sovelluksen liikennettä.

Laite on siis rekisteröitävä aiottuun palveluun, sen on luotettava odotettuihin päätepisteisiin ja sen on voitava tavoittaa sekä hallintapalvelu että ne Apple-palvelut, joista kulku riippuu. Applen verkkovalmistelua koskeva ohje luettelee nämä riippuvuudet, eivätkä ne ole kulun neuvoteltavia osia. Hallintapalvelin, joka on olemassa vain verkkosi sisällä, tarvitsee silti tuetun polun, jota laite voi todella käyttää. Sen kutsuminen MDM:ksi ei tee saavuttamattomasta päätepisteestä saavutettavaa.

Pidä sallitut polut selvinä, mukaan lukien mikä tahansa välissä oleva välityspalvelin- ja TLS-tarkastuskäytäntö. Tarkastuslaite, joka rikkoo odotetun varmenteketjun, näyttää täsmälleen rikkinäiseltä rekisteröinniltä.

Kun VPN on väärä vastaus

Jos hallintapalvelusi on julkaistu internetissä asianmukaisella varmenteella ja laite aloittaa jokaisen yhteyden, VPN lisää hypyn lisäämättä valvontaa. Laite todentaa jo itsensä rekisteröinti-identiteetillään, ja palvelin päättää jo, mitkä komennot se hyväksyy. Tunneli sen edessä muuttaa verkkopolkua, ei luottamuspäätöstä.

Sama hallintataso voi toimittaa myös itse VPN-profiilin. Tällä järjestyksellä on väliä: hallittu VPN-kokoonpano saapuu vain yhtenä hyötykuormana, joten laite ei tarvitse tunnelia ennen kuin se voi vastaanottaa profiilin, joka sen luo.

Kun VPN on oikea vastaus

On laitekantoja, joissa hallinnan päätepisteen ei pitäisi koskaan olla saavutettavissa internetistä, ja se on perusteltu suunnittelu eikä rohkeuden puute. Säännellyt ympäristöt, pienet sisäiset IT-tiimit ja palvelimet, jotka isännöivät myös muita hallintaliittymiä, päätyvät usein sinne. Siinä tapauksessa suojattu käyttöpolku hallintapalvelun edessä on tarkoituksellinen arkkitehtuuri, ei kiertotie.

Näytönjako ja yksityisten sovellusten käyttö kuuluvat yleensä myös linjan sille puolelle. Molemmat paljastavat paljon enemmän kuin komentokanava, ja molemmat ansaitsevat oman todennuksensa sen sijaan, että ratsastaisivat rekisteröinti-identiteetillä.

Käynnistyksen ansa, joka rikkoo palautuksen

Tässä on se vika, jonka varalta suunnittelisin: ainoa polku hallintapalveluun kulkee VPN:n kautta, ja laitteen VPN-profiili tai tunniste on vanhentunut. Laite ei pääse palvelimeen hakemaan korvaavaa komentoa, eikä palvelin voi työntää mitään tunnelin läpi, joka ei nouse. Palautus riippuu nyt käyttäjästä, joka voi olla satojen kilometrien päässä.

Pidä toinen, riippumaton polku palautusta varten, olipa se kaistanulkoinen hallintakanava, paikallinen ylläpitäjä tai hallintapalvelu, joka pysyy saavutettavissa ilman tunnelia. Testaa sitä, kun kaikki toimii, sillä häiriön aikana et saa puhdasta testiä.

Kirjoita sitten muistiin, mitä kolmesta tarpeesta kukin polku palvelee, ja poista porttien edelleenohjaukset, jotka eivät palvele mitään niistä. Laitekanta, jota voidaan hallita ilman yleistä tunnelia ja joka voidaan vielä korjata, kun tunneli on se, mikä hajosi, on tulos, jonka vuoksi kannattaa suunnitella.