Soru nadiren Apple cihaz yönetiminin şifrelemeye ihtiyacı olup olmadığıdır, çünkü vardır. Gerçek soru, bir Mac veya iPad yönetilebilir hale gelmeden önce filonuzun genel amaçlı bir VPN'e ihtiyacı olup olmadığıdır ve internet üzerinden yönetilen dağıtımların çoğunda yanıt hayırdır. Apple, cihazın bir yönetim hizmetine kendi takvimine göre ulaşmasına izin verir ve önemli olan trafik, masaüstü oturumu değil imzalı bir komut kanalıdır. Bunun sizin için işe yarayıp yaramaması üç koşula bağlıdır ve dışarıdan hepsi uzaktan erişim gibi göründüğü için karıştırmak kolaydır.

Bir taşıma seçmeden önce ihtiyacı adlandırın

Yönetim komutları ve yapılandırma profilleri bir ihtiyaçtır, etkileşimli ekran paylaşımı ikincisidir ve özel bir iç uygulamaya ulaşmak üçüncüsüdür. Farklı sahipleri, farklı kimlik doğrulamaları ve çoğu zaman çok farklı kabul edilebilir maruziyetleri vardır. Hepsini aynı kazana atmak, bir filonun kimsenin savunamayacağı bir genel port listesiyle sonuçlanma yoludur.

Üç ihtiyaç aynı taşımayı paylaşmaz:

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

Karışıklık genellikle eski bir sunucu kontrol listesiyle başlar. OS X Server hakkındaki tarihsel bir belge uzun bir port kümesi listeler ve birileri yönetim hizmeti orada bir yerde olduğu için hepsini kenarda yönlendirir. Bu bir yönetim mimarisi değildir ve açık yüzeyi yayımlamaya çalıştığınız kontrol düzleminin çok ötesine genişletir.

Push bildirimi gerçekte ne yapar

Apple'ın belgelediği akışta yönetim sunucusu, cihaza iş beklediğini söylemek için bir APNs bildirimi gönderir. Ardından cihaz yönetim sunucusuna bir bağlantı açar ve komutlarını ister. Push bir kapı zilidir, tünel değildir: rastgele bir yük, uzak masaüstü oturumu veya başka bir uygulamanın trafiğini taşımaz.

Bu nedenle cihaz amaçlanan hizmete kayıtlı olmalı, beklenen uç noktalara güvenmeli ve hem yönetim hizmetine hem de akışın bağlı olduğu Apple hizmetlerine ulaşabilmelidir. Apple'ın ağ hazırlığı kılavuzu bu bağımlılıkları listeler ve bunlar akışın müzakere edilebilir parçaları değildir. Yalnızca ağınızın içinde var olan bir yönetim sunucusu yine de cihazın gerçekten kullanabileceği desteklenen bir yola ihtiyaç duyar. Ona MDM demek, ulaşılamayan bir uç noktayı ulaşılabilir kılmaz.

İzin verilen yolları açık tutun, aradaki herhangi bir proxy ve TLS denetim politikası dahil. Beklenen sertifika zincirini kıran bir denetim cihazı tam olarak bozuk bir kayıt gibi görünecektir.

VPN yanlış yanıt olduğunda

Yönetim hizmetiniz internette doğru bir sertifikayla yayımlanmışsa ve her bağlantıyı cihaz başlatıyorsa, bir VPN kontrol eklemeden bir atlama ekler. Cihaz zaten kayıt kimliğiyle kimlik doğrular ve sunucu hangi komutları kabul edeceğine zaten karar verir. Bunun önüne konan bir tünel ağ yolunu değiştirir, güven kararını değil.

Aynı kontrol düzlemi VPN profilinin kendisini de teslim edebilir. Bu sıralama önemlidir: yönetilen bir VPN yapılandırması yalnızca bir yük daha olarak gelir, bu nedenle cihazın onu oluşturan profili almadan önce tünelin var olmasına gerek yoktur.

VPN doğru yanıt olduğunda

Yönetim uç noktasının internetten asla ulaşılabilir olmaması gereken filolar vardır ve bu cesaret eksikliği değil, meşru bir tasarımdır. Düzenlenmiş ortamlar, küçük iç BT ekipleri ve başka yönetim arayüzlerini de barındıran sunucular genellikle oraya varır. Bu durumda yönetim hizmetinin önünde korumalı bir erişim yolu kasıtlı bir mimaridir, bir geçici çözüm değildir.

Ekran paylaşımı ve özel uygulama erişimi genellikle çizginin o tarafına da aittir. İkisi de komut kanalından çok daha fazlasını açığa çıkarır ve ikisi de kayıt kimliğine binmek yerine kendi kimlik doğrulamasını hak eder.

Kurtarmayı bozan önyükleme tuzağı

Tasarım yapacağım arıza şudur: yönetim hizmetine giden tek yol bir VPN'den geçiyor ve cihazdaki VPN profili veya kimlik bilgisi süresi dolmuş. Cihaz, yedek bir komut almak için sunucuya ulaşamaz ve sunucu, açılmayacak bir tünelden hiçbir şey itemez. Kurtarma artık yüzlerce mil uzakta olabilecek bir kullanıcıya bağlıdır.

Kurtarma için ikinci ve bağımsız bir yol tutun: bant dışı bir yönetim kanalı, yerel bir yönetici veya tünel olmadan ulaşılabilir kalan bir yönetim hizmeti. Her şey çalışırken test edin, çünkü bir olay sırasında temiz bir test elde edemezsiniz.

Ardından her yolun üç ihtiyaçtan hangisine hizmet ettiğini yazın ve hiçbirine hizmet etmeyen port yönlendirmelerini kaldırın. Genel bir tünel olmadan yönetilebilen ve tünel kırıldığında hâlâ onarılabilecek bir filo, tasarlamaya değer sonuçtur.

İlgili makaleler