Ձեզ 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-ը ճիշտ պատասխան է
Կան պարկեր, որտեղ կառավարման վերջնակետը երբեք չպետք է ինտերնետից հասանելի լինի, և դա օրինական ձևավորում է, ոչ խիզախության պակաս։ Կարգավորվող միջավայրերը, փոքր ներքին ՏՏ թիմերը և այլ վարչական ինտերֆեյսներ նույնպես տեղակայող սերվերները հաճախ այնտեղ են հայտնվում։ Այդ դեպքում կառավարման ծառայության առջև պաշտպանված մուտքի ուղին դիտավորյալ ճարտարապետություն է, ոչ շրջանցիկ լուծում։
Էկրանի համօգտագործումը և մասնավոր հավելվածների հասանելիությունը սովորաբար նույնպես պատկանում են գծի այդ կողմին։ Երկուսն էլ շատ ավելին են բացահայտում, քան հրամանի ալիքը, և երկուսն էլ արժանի են իրենց նույնականացմանը՝ գրանցման ինքնության վրա հեծնելու փոխարեն։
Բութստրապ թակարդը, որը կոտրում է վերականգնումը
Ահա ձախողումը, որի դեմ ես կնախագծեի. կառավարման ծառայության միակ ուղին անցնում է VPN-ով, և սարքի վրա գտնվող VPN պրոֆիլը կամ վկայականը սպառվել է։ Սարքը չի կարող հասնել սերվերին փոխարինող հրաման վերցնելու, և սերվերը չի կարող որևէ բան մղել թունելով, որը չի բարձրանա։ Վերականգնումն այժմ կախված է օգտատիրոջից, որը կարող է հարյուրավոր մղոններ հեռու լինել։
Պահեք երկրորդ, անկախ ուղի վերականգնման համար՝ լինի դա ժապավենից դուրս կառավարման ալիք, տեղական ադմինիստրատոր, թե կառավարման ծառայություն, որը մնում է հասանելի առանց թունելի։ Փորձարկեք այն, քանի դեռ ամեն ինչ աշխատում է, որովհետև միջադեպի ընթացքում մաքուր փորձարկում չեք ստանա։
Ապա գրեք, թե ուղիներից յուրաքանչյուրը երեք կարիքներից որին է ծառայում, և հեռացրեք պորտերի փոխանցումները, որոնք ոչ մեկին չեն ծառայում։ Պարկը, որը կարելի է կառավարել առանց ընդհանուր թունելի և դեռ հնարավոր է վերանորոգել, երբ թունելն է կոտրվել, այն արդյունքն է, որի համար արժե նախագծել։