Vai jums vajag VPN Apple MDM vajadzībām? Trīs piekļuves vajadzības, viena atbilde
Apple MDM darbojas uz APNs un ierīces uzsākta HTTPS, nevis LAN tunelī. Atdaliet pārvaldību, ekrāna koplietošanu un piekļuvi privātām lietotnēm, pirms pievienojat VPN.
Jautājums reti ir par to, vai Apple ierīču pārvaldībai vajadzīga šifrēšana, jo tā ir vajadzīga. Īstais jautājums ir, vai jūsu parkam vajag vispārēja lietojuma VPN, pirms Mac vai iPad vispār var pārvaldīt, un lielākajai daļai interneta pārvaldītu ieviešanu atbilde ir nē. Apple ļauj ierīcei sasniegt pārvaldības pakalpojumu pēc sava grafika, un svarīgākā plūsma ir parakstīts komandu kanāls, nevis darbvirsmas sesija. Vai tas jums darbosies, ir atkarīgs no trim nosacījumiem, un tos ir viegli sajaukt, jo no malas tie visi izskatās kā attālināta piekļuve.
Nosauciet vajadzību, pirms izvēlaties transportu
Pārvaldības komandas un konfigurācijas profili ir viena vajadzība, interaktīva ekrāna koplietošana ir otrā, un piekļuve privātai iekšējai lietotnei ir trešā. Tiem ir dažādi īpašnieki, dažāda autentifikācija un bieži ļoti atšķirīga pieņemama pakļautība. To visu sajaukšana kopā ir ceļš, kā parks nonāk pie publiska portu saraksta, ko neviens nevar aizstāvēt.
Trīs vajadzības nedala vienu transportu:
| 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 |
Apjukums parasti sākas ar vecu servera kontrolsarakstu. Vēsturisks OS X Server dokuments uzskaita garu portu kopumu, un kāds tos visus pārsūta malā, jo pārvaldības pakalpojums ir kaut kur tur iekšā. Tā nav pārvaldības arhitektūra, un tā paplašina atklāto virsmu daudz tālāk par to vadības plakni, ko jūs mēģinājāt publicēt.
Ko push paziņojums patiešām dara
Apple dokumentētajā plūsmā pārvaldības serveris nosūta APNs paziņojumu, lai ierīcei pateiktu, ka gaida darbs. Pēc tam ierīce atver savienojumu ar pārvaldības serveri un pieprasa savas komandas. Push ir durvju zvans, nevis tunelis: tas nepārvadā nekādu patvaļīgu kravu, ne attālinātas darbvirsmas sesiju, ne citas lietotnes plūsmu.
Tāpēc ierīcei jābūt reģistrētai paredzētajā pakalpojumā, jāuzticas gaidītajiem galapunktiem un jāspēj sasniegt gan pārvaldības pakalpojumu, gan Apple pakalpojumus, no kuriem plūsma ir atkarīga. Apple tīkla sagatavošanas norādes uzskaita šīs atkarības, un tās nav plūsmas apspriežamas daļas. Pārvaldības serverim, kas pastāv tikai jūsu tīklā, joprojām vajag atbalstītu ceļu, ko ierīce patiešām var izmantot. To nosaukt par MDM nepadara nesasniedzamu galapunktu sasniedzamu.
Turiet atļautos ceļus skaidrus, ieskaitot jebkuru starpniekservera un TLS pārbaudes politiku vidū. Pārbaudes iekārta, kas salauž gaidīto sertifikātu ķēdi, izskatīsies tieši kā salauzta reģistrācija.
Kad VPN ir nepareizā atbilde
Ja jūsu pārvaldības pakalpojums ir publicēts internetā ar pareizu sertifikātu un katru savienojumu uzsāk ierīce, VPN pievieno lēcienu, nepievienojot kontroli. Ierīce jau autentificējas ar savu reģistrācijas identitāti, un serveris jau izlemj, kuras komandas pieņems. Tunelis tā priekšā maina tīkla ceļu, nevis uzticēšanās lēmumu.
Tā pati vadības plakne var piegādāt arī pašu VPN profilu. Šī secība ir svarīga: pārvaldīta VPN konfigurācija ierodas kā vēl viena krava, tāpēc ierīcei nav vajadzīgs, lai tunelis pastāvētu, pirms tā saņem profilu, kas to izveido.
Kad VPN ir pareizā atbilde
Ir parki, kuros pārvaldības galapunktam nekad nevajadzētu būt sasniedzamam no interneta, un tas ir leģitīms dizains, nevis drosmes trūkums. Regulētas vidēs, mazas iekšējās IT komandas un serveri, kas mitina arī citas administratīvās saskarnes, bieži nonāk tur. Tādā gadījumā aizsargāts piekļuves ceļš pārvaldības pakalpojuma priekšā ir apzināta arhitektūra, nevis apvedceļš.
Ekrāna koplietošana un piekļuve privātām lietotnēm parasti pieder arī tai pašai līnijas pusei. Abi atklāj daudz vairāk nekā komandu kanāls, un abi ir pelnījuši savu autentifikāciju, nevis braukšanu uz reģistrācijas identitātes.
Sāknēšanas slazds, kas salauž atjaunošanu
Lūk, kļūme, pret kuru es projektētu: vienīgais ceļš uz pārvaldības pakalpojumu iet caur VPN, un ierīcē esošais VPN profils vai akreditācijas dati ir beigušies. Ierīce nevar sasniegt serveri, lai paņemtu aizvietojošu komandu, un serveris nevar neko izstumt caur tuneli, kas necelsies. Atjaunošana tagad ir atkarīga no lietotāja, kas var būt simtiem jūdžu attālumā.
Turiet otru, neatkarīgu ceļu atjaunošanai: vai nu joslas ārpusē esošu pārvaldības kanālu, vai vietēju administratoru, vai pārvaldības pakalpojumu, kas paliek sasniedzams bez tuneļa. Pārbaudiet to, kamēr viss darbojas, jo incidenta laikā jūs nesaņemsit tīru pārbaudi.
Pēc tam pierakstiet, kuru no trim vajadzībām apkalpo katrs ceļš, un noņemiet portu pāradresācijas, kas neapkalpo nevienu no tām. Parks, ko var pārvaldīt bez vispārēja tuneļa un ko joprojām var salabot, kad tunelis ir tas, kas salūza, ir rezultāts, kura dēļ ir vērts projektēt.