Bihirang tanungin kung ang pamamahala ng mga Apple device ay nangangailangan ng encryption, dahil kailangan nito. Ang tunay na tanong ay kung ang iyong fleet ay nangangailangan ng pangkalahatang VPN bago pa man mapamahalaan ang isang Mac o iPad, at para sa karamihan ng deployment na pinamamahalaan sa internet ang sagot ay hindi. Hinahayaan ng Apple ang device na maabot ang isang serbisyo ng pamamahala ayon sa sarili nitong iskedyul, at ang trapikong mahalaga ay isang pinirmahang channel ng utos, hindi isang sesyon ng desktop. Kung gagana iyon sa iyo ay nakasalalay sa tatlong kondisyon, at madaling pagkamalitin ang mga ito dahil mula sa labas ay mukhang remote access ang lahat.

Pangalanan ang pangangailangan bago pumili ng transport

Ang mga utos ng pamamahala at mga profile ng configuration ay isang pangangailangan, ang interactive na pagbabahagi ng screen ay pangalawa, at ang pag-abot sa isang pribadong panloob na application ay pangatlo. May iba silang may-ari, iba ang authentication, at kadalasan ay ibang-iba ang katanggap-tanggap na exposure. Ang pagsasama-sama ng mga ito ay ang paraan kung paano nauuwi ang isang fleet sa isang pampublikong listahan ng port na walang makapagtatanggol.

Hindi nagbabahagi ng isang transport ang tatlong pangangailangan:

NeedWhat actually carries it
Management commands and profilesThe enrolled device pulls from a service it can reach; APNs only wakes it
Interactive screen sharingA remote-support tool or private desktop path with its own authentication
Private application accessThat application's permitted network path, which may well be a VPN

Karaniwang nagsisimula ang kalituhan sa isang lumang checklist ng server. Isang makasaysayang dokumento tungkol sa OS X Server ang naglilista ng mahabang hanay ng port, at may nagpapasa sa lahat ng ito sa gilid dahil ang serbisyo ng pamamahala ay nasa loob nito sa isang lugar. Hindi iyon arkitektura ng pamamahala, at pinalalawak nito ang nakalantad na surface nang malayo sa control plane na sinusubukan mong i-publish.

Ano ang talagang ginagawa ng push notification

Sa dokumentadong daloy ng Apple, ang server ng pamamahala ay nagpapadala ng APNs notification para sabihin sa device na may naghihintay na trabaho. Pagkatapos ay magbubukas ang device ng koneksyon sa server ng pamamahala at hihingin ang mga utos nito. Ang push ay isang kampanilya ng pinto, hindi tunnel: wala itong dinadalang arbitraryong payload, walang malayuang sesyon ng desktop, at walang trapiko ng ibang app.

Kaya ang device ay dapat na nakarehistro sa nilalayong serbisyo, nagtitiwala sa inaasahang endpoint, at kayang maabot ang serbisyo ng pamamahala at ang mga serbisyo ng Apple na pinagkakatiwalaan ng daloy. Ang gabay ng Apple sa paghahanda ng network ay naglilista ng mga dependency na iyon, at hindi sila mga bahagi ng daloy na maaaring pag-usapan. Ang isang server ng pamamahala na umiiral lamang sa loob ng iyong network ay kailangan pa rin ng suportadong landas na talagang magagamit ng device. Ang pagtawag dito na MDM ay hindi ginagawang maabot ang isang endpoint na hindi maabot.

Panatilihing tahas ang mga pinapayagang landas, kabilang ang anumang patakaran sa proxy at inspeksyon ng TLS sa gitna. Ang isang kagamitan sa inspeksyon na sisira sa inaasahang certificate chain ay magmumukhang eksaktong sirang enrolment.

Kapag ang VPN ay maling sagot

Kung ang iyong serbisyo ng pamamahala ay nai-publish sa internet na may tamang certificate at ang device ang nagsimula ng bawat koneksyon, ang VPN ay nagdadagdag ng isang lukso nang walang dagdag na kontrol. Nagpapatunay na ng pagkakakilanlan ang device gamit ang identity ng enrolment nito, at nagpapasya na ang server kung aling mga utos ang tatanggapin. Ang isang tunnel sa harap nito ay nagbabago ng landas ng network, hindi ng desisyon sa pagtitiwala.

Ang parehong control plane ay maaari ring maghatid ng profile ng VPN mismo. Mahalaga ang pagkakasunod-sunod na iyon: dumarating ang pinamamahalaang VPN configuration bilang isa pang payload lamang, kaya hindi kailangan ng device na umiral ang tunnel bago nito matanggap ang profile na lumilikha nito.

Kapag ang VPN ay tamang sagot

May mga fleet kung saan ang endpoint ng pamamahala ay hindi dapat maabot mula sa internet, at iyon ay lehitimong disenyo, hindi kakulangan ng tapang. Ang mga regulated na kapaligiran, maliliit na panloob na IT team, at mga server na nagho-host din ng iba pang administratibong interface ay madalas mapunta roon. Sa ganoong kaso, ang protektadong landas ng pag-access sa harap ng serbisyo ng pamamahala ay sadyang arkitektura, hindi isang paraan ng pag-iwas.

Ang pagbabahagi ng screen at pag-access sa mga pribadong app ay karaniwang kabilang din sa panig na iyon ng linya. Pareho silang naglalantad ng higit pa sa isang channel ng utos, at pareho silang karapat-dapat sa sariling authentication sa halip na sumakay sa identity ng enrolment.

Ang bitag sa bootstrap na sumisira sa pag-recover

Narito ang pagkabigo na ididesenyo ko laban: ang tanging landas patungo sa serbisyo ng pamamahala ay dumadaan sa isang VPN, at ang profile o kredensyal ng VPN sa device ay nag-expire na. Hindi maabot ng device ang server para kumuha ng kapalit na utos, at hindi maipapasok ng server ang anuman sa tunnel na hindi babangon. Ang pag-recover ay nakasalalay na ngayon sa isang user na maaaring daan-daang milya ang layo.

Panatilihin ang pangalawa, malayang landas para sa pag-recover, maging ito man ay out-of-band na channel ng pamamahala, lokal na administrator, o serbisyo ng pamamahala na nananatiling maabot nang walang tunnel. Subukan ito habang gumagana ang lahat, dahil hindi ka makakakuha ng malinis na pagsubok kapag may insidente.

Pagkatapos, isulat kung alin sa tatlong pangangailangan ang pinaglilingkuran ng bawat landas, at alisin ang mga port forwarding na wala sa kanila ang pinaglilingkuran. Ang isang fleet na mapamamahalaan nang walang pangkalahatang tunnel, at maaayos pa kapag ang tunnel ang nasira, ay ang resultang sulit na idisenyo.

Kaugnay na mga artikulo