Adakah anda perlukan VPN untuk Apple MDM? Tiga keperluan akses, satu jawapan
Apple MDM berjalan pada APNs dan HTTPS yang dimulakan peranti, bukan terowong LAN. Asingkan pengurusan, perkongsian skrin dan akses aplikasi peribadi sebelum menambah VPN.
Soalannya jarang tentang sama ada pengurusan peranti Apple memerlukan penyulitan, kerana ia memerlukannya. Soalan sebenar ialah sama ada armada anda memerlukan VPN tujuan umum sebelum Mac atau iPad boleh diuruskan langsung, dan bagi kebanyakan penggunaan yang diurus melalui internet jawapannya tidak. Apple membenarkan peranti mencapai perkhidmatan pengurusan mengikut jadualnya sendiri, dan trafik yang penting ialah saluran arahan bertandatangan, bukan sesi desktop. Sama ada ia berkesan untuk anda bergantung pada tiga syarat, dan ia mudah dikelirukan kerana dari luar semuanya kelihatan seperti akses jauh.
Namakan keperluan sebelum memilih pengangkutan
Arahan pengurusan dan profil konfigurasi ialah satu keperluan, perkongsian skrin interaktif ialah yang kedua, dan mencapai aplikasi dalaman peribadi ialah yang ketiga. Ia mempunyai pemilik berbeza, pengesahan berbeza dan selalunya pendedahan boleh terima yang sangat berbeza. Menggabungkannya ialah cara sesuatu armada berakhir dengan senarai port awam yang tiada siapa dapat mempertahankannya.
Ketiga-tiga keperluan tidak berkongsi satu pengangkutan:
| 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 |
Kekeliruan biasanya bermula dengan senarai semak pelayan lama. Dokumen sejarah OS X Server menyenaraikan set port yang panjang, dan seseorang memajukan semuanya di pinggir kerana perkhidmatan pengurusan ada di suatu tempat di dalamnya. Itu bukan seni bina pengurusan, dan ia meluaskan permukaan terdedah jauh melebihi satah kawalan yang anda cuba terbitkan.
Apa yang pemberitahuan push sebenarnya lakukan
Dalam aliran yang didokumenkan Apple, pelayan pengurusan menghantar pemberitahuan APNs untuk memberitahu peranti bahawa kerja sedang menunggu. Peranti kemudian membuka sambungan ke pelayan pengurusan dan meminta arahannya. Push ialah loceng pintu, bukan terowong: ia tidak membawa muatan sewenang-wenangnya, tiada sesi desktop jauh, dan tiada trafik aplikasi lain.
Jadi peranti mesti didaftarkan dengan perkhidmatan yang dimaksudkan, mempercayai titik akhir yang dijangka, dan mampu mencapai kedua-dua perkhidmatan pengurusan dan perkhidmatan Apple yang menjadi sandaran aliran itu. Panduan penyediaan rangkaian Apple menyenaraikan kebergantungan itu, dan ia bukan bahagian aliran yang boleh dirunding. Pelayan pengurusan yang hanya wujud di dalam rangkaian anda masih memerlukan laluan yang disokong yang benar-benar boleh digunakan oleh peranti. Menamakannya MDM tidak menjadikan titik akhir yang tidak dapat dicapai itu boleh dicapai.
Kekalkan laluan yang dibenarkan secara eksplisit, termasuk sebarang dasar proksi dan pemeriksaan TLS di tengah. Perkakas pemeriksaan yang memutuskan rantaian sijil yang dijangka akan kelihatan tepat seperti pendaftaran yang rosak.
Apabila VPN ialah jawapan yang salah
Jika perkhidmatan pengurusan anda diterbitkan di internet dengan sijil yang betul dan peranti memulakan setiap sambungan, VPN menambah satu lompatan tanpa menambah kawalan. Peranti sudah mengesahkan dirinya dengan identiti pendaftarannya, dan pelayan sudah memutuskan arahan mana yang akan diterimanya. Terowong di hadapannya mengubah laluan rangkaian, bukan keputusan kepercayaan.
Satah kawalan yang sama juga boleh menyampaikan profil VPN itu sendiri. Urutan itu penting: konfigurasi VPN terurus tiba sebagai satu lagi muatan sahaja, jadi peranti tidak memerlukan terowong itu wujud sebelum menerima profil yang menciptanya.
Apabila VPN ialah jawapan yang betul
Ada armada di mana titik akhir pengurusan tidak sepatutnya boleh dicapai dari internet, dan itu reka bentuk yang sah, bukan kekurangan keberanian. Persekitaran terkawal, pasukan IT dalaman yang kecil dan pelayan yang juga menghoskan antara muka pentadbiran lain sering berakhir di situ. Dalam kes itu laluan akses terlindung di hadapan perkhidmatan pengurusan ialah seni bina yang disengajakan, bukan jalan pintas.
Perkongsian skrin dan akses aplikasi peribadi biasanya juga tergolong di sebelah garisan itu. Kedua-duanya mendedahkan jauh lebih banyak daripada saluran arahan, dan kedua-duanya wajar mendapat pengesahan sendiri dan bukannya menumpang identiti pendaftaran.
Perangkap butstrap yang memecahkan pemulihan
Inilah kegagalan yang akan saya reka untuk dielakkan: satu-satunya laluan ke perkhidmatan pengurusan melalui VPN, dan profil atau kelayakan VPN pada peranti sudah tamat tempoh. Peranti tidak dapat mencapai pelayan untuk mengambil arahan pengganti, dan pelayan tidak dapat menolak apa-apa melalui terowong yang tidak akan bangkit. Pemulihan kini bergantung pada pengguna yang mungkin beratus batu jauhnya.
Kekalkan laluan kedua yang bebas untuk pemulihan, sama ada saluran pengurusan luar jalur, pentadbir tempatan, atau perkhidmatan pengurusan yang kekal boleh dicapai tanpa terowong. Ujinya semasa semuanya berfungsi, kerana anda tidak akan mendapat ujian bersih semasa insiden.
Kemudian tuliskan keperluan mana antara tiga itu yang dilayani oleh setiap laluan, dan buang pemajuan port yang tidak melayani mana-mana daripadanya. Armada yang boleh diurus tanpa terowong umum, dan masih boleh dibaiki apabila terowong itulah yang rosak, ialah hasil yang wajar direka.