გჭირდებათ VPN Apple MDM-ისთვის? სამი წვდომის მოთხოვნილება, ერთი პასუხი
Apple MDM მუშაობს APNs-ზე და მოწყობილობის მიერ დაწყებულ HTTPS-ზე და არა LAN გვირაბზე. VPN-ის დამატებამდე გამოყავით მართვა, ეკრანის გაზიარება და კერძო აპებზე წვდომა.
კითხვა იშვიათად არის იმის შესახებ, სჭირდება თუ არა Apple მოწყობილობების მართვას დაშიფვრა, რადგან სჭირდება. ნამდვილი კითხვაა, სჭირდება თუ არა თქვენს პარკს ზოგადი დანიშნულების VPN სანამ Mac-ის ან iPad-ის მართვა საერთოდ შესაძლებელი გახდება, და ინტერნეტით მართული განლაგებების უმეტესობისთვის პასუხია არა. Apple საშუალებას აძლევს მოწყობილობას მართვის სერვისს მიაღწიოს საკუთარი გრაფიკით, და მნიშვნელოვანი ტრაფიკი ხელმოწერილი ბრძანების არხია და არა სამუშაო მაგიდის სესია. იმუშავებს თუ არა ეს თქვენთვის, სამ პირობაზეა დამოკიდებული და მათი არევა ადვილია, რადგან გარედან ყველა დისტანციურ წვდომას ჰგავს.
დაასახელეთ მოთხოვნილება სანამ ტრანსპორტს აირჩევთ
მართვის ბრძანებები და კონფიგურაციის პროფილები ერთი მოთხოვნილებაა, ინტერაქტიული ეკრანის გაზიარება მეორე, და კერძო შიდა აპლიკაციაზე მიღწევა მესამე. მათ განსხვავებული მფლობელები, განსხვავებული ავთენტიფიკაცია და ხშირად ძალიან განსხვავებული დასაშვები გამჟღავნება აქვთ. მათი ერთად თავმოყრა ის გზაა, რომლითაც პარკი საჯარო პორტების სიას იღებს, რომლის დაცვაც ვერავინ შეძლებს.
სამი მოთხოვნილება ერთ ტრანსპორტს არ იზიარებს:
| 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 |
დაბნეულობა ჩვეულებრივ ძველი სერვერის შემოწმების სიით იწყება. OS X Server-ის ისტორიული დოკუმენტი პორტების გრძელ ნაკრებს ჩამოთვლის, და ვიღაც ყველას კიდეზე გადამისამართებს, რადგან მართვის სერვისი სადღაც იქ არის. ეს არ არის მართვის არქიტექტურა და ის ღია ზედაპირს გაცილებით აფართოებს, ვიდრე საკონტროლო სიბრტყე, რომლის გამოქვეყნებასაც ცდილობდით.
რას აკეთებს სინამდვილეში push შეტყობინება
Apple-ის დოკუმენტირებულ ნაკადში მართვის სერვერი APNs შეტყობინებას აგზავნის, რომ მოწყობილობას უთხრას სამუშაოს ლოდინის შესახებ. შემდეგ მოწყობილობა მართვის სერვერთან კავშირს ხსნის და თავის ბრძანებებს ითხოვს. Push კარზე ზარია და არა გვირაბი: ის არ ატარებს არც თვითნებურ დატვირთვას, არც დისტანციური სამუშაო მაგიდის სესიას და არც სხვა აპის ტრაფიკს.
ამიტომ მოწყობილობა უნდა იყოს რეგისტრირებული განზრახ სერვისში, ენდობოდეს მოსალოდნელ ბოლო წერტილებს და შეძლოს როგორც მართვის სერვისის, ისე იმ Apple სერვისების მიღწევა, რომლებზეც ნაკადია დამოკიდებული. Apple-ის ქსელის მომზადების სახელმძღვანელო ამ დამოკიდებულებებს ჩამოთვლის და ისინი ნაკადის სავაჭრო ნაწილები არ არის. მხოლოდ თქვენი ქსელის შიგნით არსებულ მართვის სერვერს მაინც სჭირდება მხარდაჭერილი გზა, რომელსაც მოწყობილობა ნამდვილად გამოიყენებს. MDM-ად წოდება მიუწვდომელ ბოლო წერტილს მისაწვდომს არ ხდის.
შეინახეთ დაშვებული გზები მკაფიოდ, მათ შორის შუაში მდგომი ნებისმიერი პროქსის და TLS შემოწმების პოლიტიკა. შემოწმების მოწყობილობა, რომელიც მოსალოდნელ სერტიფიკატების ჯაჭვს ტეხავს, ზუსტად გატეხილ რეგისტრაციას ჰგავს.
როცა VPN არასწორი პასუხია
თუ თქვენი მართვის სერვისი ინტერნეტში გამოქვეყნებულია სათანადო სერტიფიკატით და ყოველ კავშირს მოწყობილობა იწყებს, VPN ნახტომს ამატებს კონტროლის დამატების გარეშე. მოწყობილობა უკვე ავთენტიფიცირდება თავისი რეგისტრაციის იდენტობით, და სერვერი უკვე წყვეტს, რომელ ბრძანებებს მიიღებს. მის წინ გვირაბი ცვლის ქსელურ გზას და არა ნდობის გადაწყვეტილებას.
იგივე საკონტროლო სიბრტყეს შეუძლია თავად VPN პროფილის მიწოდებაც. ეს თანმიმდევრობა მნიშვნელოვანია: მართული VPN კონფიგურაცია უბრალოდ კიდევ ერთ დატვირთვად მოდის, ამიტომ მოწყობილობას გვირაბის არსებობა არ სჭირდება მანამ, სანამ მიიღებს პროფილს, რომელიც მას ქმნის.
როცა VPN სწორი პასუხია
არსებობს პარკები, სადაც მართვის ბოლო წერტილი არასოდეს უნდა იყოს ინტერნეტიდან მისაწვდომი, და ეს ლეგიტიმური დიზაინია და არა სიმამაცის ნაკლებობა. რეგულირებადი გარემოები, მცირე შიდა IT გუნდები და სერვერები, რომლებიც სხვა ადმინისტრაციულ ინტერფეისებსაც მასპინძლობენ, ხშირად იქ ხვდებიან. ამ შემთხვევაში მართვის სერვისის წინ დაცული წვდომის გზა განზრახ არქიტექტურაა და არა გვერდის ავლა.
ეკრანის გაზიარება და კერძო აპებზე წვდომა ჩვეულებრივ ხაზის იმ მხარესაც ეკუთვნის. ორივე ბრძანების არხზე გაცილებით მეტს ამჟღავნებს და ორივე იმსახურებს საკუთარ ავთენტიფიკაციას რეგისტრაციის იდენტობაზე ჯდომის ნაცვლად.
ჩატვირთვის ხაფანგი, რომელიც აღდგენას ტეხავს
აი ის გაუმართაობა, რომლის წინააღმდეგაც დავაპროექტებდი: მართვის სერვისამდე ერთადერთი გზა VPN-ზე გადის, და მოწყობილობაზე არსებული VPN პროფილი ან სერტიფიკატი ვადაგასულია. მოწყობილობა ვერ აღწევს სერვერამდე შემცვლელი ბრძანების მისაღებად, და სერვერი ვერაფერს უბიძგებს გვირაბში, რომელიც არ ამოვა. აღდგენა ახლა დამოკიდებულია მომხმარებელზე, რომელიც შესაძლოა ასობით მილის მანძილზე იყოს.
შეინახეთ მეორე, დამოუკიდებელი გზა აღდგენისთვის, იქნება ეს ზოლის გარეთ მართვის არხი, ადგილობრივი ადმინისტრატორი თუ მართვის სერვისი, რომელიც გვირაბის გარეშე რჩება მისაწვდომი. გამოსცადეთ ის სანამ ყველაფერი მუშაობს, რადგან ინციდენტის დროს სუფთა გამოცდას ვერ მიიღებთ.
შემდეგ ჩამოწერეთ, სამი მოთხოვნილებიდან რომელს ემსახურება თითოეული გზა, და წაშალეთ პორტების გადამისამართებები, რომლებიც არცერთს არ ემსახურება. პარკი, რომლის მართვაც ზოგადი გვირაბის გარეშე შეიძლება და რომლის შეკეთებაც კვლავ შესაძლებელია, როცა გვირაბია გატეხილი, ის შედეგია, რომლისთვისაც ღირს დაპროექტება.