Apakah Anda perlu VPN untuk Apple MDM? Tiga kebutuhan akses, satu jawaban
Apple MDM berjalan di atas APNs dan HTTPS yang dimulai perangkat, bukan terowongan LAN. Pisahkan pengelolaan, berbagi layar, dan akses aplikasi privat sebelum menambahkan VPN.
Pertanyaannya jarang tentang apakah pengelolaan perangkat Apple memerlukan enkripsi, karena memang perlu. Pertanyaan sebenarnya adalah apakah armada Anda memerlukan VPN serba guna sebelum Mac atau iPad dapat dikelola sama sekali, dan untuk sebagian besar penerapan yang dikelola lewat internet jawabannya tidak. Apple membiarkan perangkat menjangkau layanan pengelolaan sesuai jadwalnya sendiri, dan lalu lintas yang penting adalah saluran perintah bertanda tangan, bukan sesi desktop. Apakah itu berhasil bagi Anda bergantung pada tiga syarat, dan ketiganya mudah dicampur karena dari luar semuanya tampak seperti akses jarak jauh.
Namai kebutuhannya sebelum memilih transport
Perintah pengelolaan dan profil konfigurasi adalah satu kebutuhan, berbagi layar interaktif adalah kebutuhan kedua, dan menjangkau aplikasi internal privat adalah kebutuhan ketiga. Ketiganya punya pemilik berbeda, autentikasi berbeda, dan sering paparan yang dapat diterima sangat berbeda. Menyatukannya adalah cara sebuah armada berakhir dengan daftar port publik yang tidak dapat dipertahankan siapa pun.
Ketiga kebutuhan tidak berbagi satu 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 |
Kebingungan biasanya dimulai dari daftar periksa server lama. Dokumen historis OS X Server mencantumkan kumpulan port yang panjang, dan seseorang meneruskan semuanya di tepi karena layanan pengelolaan ada di suatu tempat di dalamnya. Itu bukan arsitektur pengelolaan, dan itu memperluas permukaan yang terbuka jauh melampaui bidang kendali yang hendak Anda terbitkan.
Apa yang sebenarnya dilakukan notifikasi push
Dalam alur yang didokumentasikan Apple, server pengelolaan mengirim notifikasi APNs untuk memberi tahu perangkat bahwa ada pekerjaan menunggu. Perangkat kemudian membuka koneksi ke server pengelolaan dan meminta perintahnya. Push adalah bel pintu, bukan terowongan: ia tidak membawa muatan sembarang, tidak membawa sesi desktop jarak jauh, dan tidak membawa lalu lintas aplikasi lain.
Jadi perangkat harus terdaftar pada layanan yang dimaksud, memercayai titik akhir yang diharapkan, dan mampu menjangkau layanan pengelolaan maupun layanan Apple yang menjadi tempat alur bergantung. Panduan Apple untuk persiapan jaringan mencantumkan ketergantungan itu, dan itu bukan bagian alur yang dapat dinegosiasikan. Server pengelolaan yang hanya ada di dalam jaringan Anda tetap memerlukan jalur yang didukung yang benar-benar dapat digunakan perangkat. Menyebutnya MDM tidak membuat titik akhir yang tak terjangkau menjadi terjangkau.
Jaga jalur yang diizinkan tetap eksplisit, termasuk kebijakan proksi dan inspeksi TLS yang berada di tengah. Perangkat inspeksi yang memutus rantai sertifikat yang diharapkan akan tampak persis seperti pendaftaran yang rusak.
Ketika VPN adalah jawaban yang salah
Jika layanan pengelolaan Anda diterbitkan di internet dengan sertifikat yang benar dan perangkat memulai setiap koneksi, VPN menambah satu lompatan tanpa menambah kendali. Perangkat sudah mengautentikasi dengan identitas pendaftarannya, dan server sudah memutuskan perintah mana yang akan diterima. Terowongan di depannya mengubah jalur jaringan, bukan keputusan kepercayaan.
Bidang kendali yang sama juga dapat mengirimkan profil VPN itu sendiri. Urutan itu penting: konfigurasi VPN terkelola datang sebagai muatan lain saja, jadi perangkat tidak memerlukan terowongan untuk ada sebelum menerima profil yang membuatnya.
Ketika VPN adalah jawaban yang benar
Ada armada yang titik akhir pengelolaannya tidak boleh dapat dijangkau dari internet, dan itu desain yang sah, bukan kurang keberanian. Lingkungan teregulasi, tim TI internal kecil, dan server yang juga menghosting antarmuka administratif lain sering berakhir di sana. Dalam kasus itu jalur akses terlindungi di depan layanan pengelolaan adalah arsitektur yang disengaja, bukan jalan pintas.
Berbagi layar dan akses aplikasi privat biasanya juga ada di sisi garis itu. Keduanya mengekspos jauh lebih banyak daripada saluran perintah, dan keduanya layak mendapat autentikasinya sendiri alih-alih menumpang pada identitas pendaftaran.
Perangkap bootstrap yang merusak pemulihan
Inilah kegagalan yang akan saya rancang untuk dicegah: satu-satunya jalur ke layanan pengelolaan melewati VPN, dan profil atau kredensial VPN di perangkat sudah kedaluwarsa. Perangkat tidak dapat menjangkau server untuk mengambil perintah pengganti, dan server tidak dapat mendorong apa pun melalui terowongan yang tidak akan bangun. Pemulihan kini bergantung pada pengguna yang mungkin ratusan mil jauhnya.
Pertahankan jalur kedua yang independen untuk pemulihan, apakah itu saluran pengelolaan di luar jalur, administrator lokal, atau layanan pengelolaan yang tetap terjangkau tanpa terowongan. Ujilah saat semuanya berjalan, karena Anda tidak akan mendapat uji yang bersih saat insiden.
Lalu tuliskan kebutuhan mana dari ketiganya yang dilayani setiap jalur, dan hapus penerusan port yang tidak melayani satu pun. Armada yang dapat dikelola tanpa terowongan umum, dan masih dapat diperbaiki ketika terowongan itulah yang rusak, adalah hasil yang layak dirancang.