Apple MDM-க்கு VPN தேவையா? மூன்று அணுகல் தேவைகள், ஒரு பதில்
Apple MDM APNs மற்றும் சாதனம் தொடங்கும் HTTPS-இல் இயங்குகிறது, LAN சுரங்கப்பாதையில் அல்ல. VPN சேர்ப்பதற்கு முன் நிர்வாகம், திரைப் பகிர்வு மற்றும் தனிப்பட்ட பயன்பாட்டு அணுகலைப் பிரிக்கவும்.
Apple சாதன நிர்வாகத்திற்கு மறையாக்கம் தேவையா என்பது அரிதான கேள்வி, ஏனெனில் தேவை. உண்மையான கேள்வி என்னவென்றால், Mac அல்லது iPad-ஐ நிர்வகிக்கும் முன் உங்கள் குழுவிற்கு பொதுப் பயன்பாட்டு VPN தேவையா என்பதே, மேலும் இணையம் வழியாக நிர்வகிக்கப்படும் பெரும்பாலான பயன்பாடுகளுக்கு பதில் இல்லை. 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 சுயவிவரம் அல்லது சான்றுகள் காலாவதியாகிவிட்டன. சாதனம் மாற்றுக் கட்டளையைப் பெற சேவையகத்தை அடைய முடியாது, சேவையகம் எழாத ஒரு சுரங்கப்பாதை வழியாக எதையும் தள்ள முடியாது. மீட்பு இப்போது நூற்றுக்கணக்கான மைல் தொலைவில் இருக்கக்கூடிய ஒரு பயனரைச் சார்ந்துள்ளது.
மீட்பிற்காக இரண்டாவது, சுயாதீனமான பாதையை வைத்திருங்கள், அது பேண்டுக்கு வெளியேயான நிர்வாகச் சேனலாகவோ, உள்ளூர் நிர்வாகியாகவோ, அல்லது சுரங்கப்பாதை இல்லாமல் அடையக்கூடியதாக இருக்கும் நிர்வாகச் சேவையாகவோ இருக்கலாம். எல்லாம் வேலை செய்யும்போதே அதைச் சோதியுங்கள், ஒரு சம்பவத்தின் போது உங்களுக்குத் தூய சோதனை கிடைக்காது.
பின்னர் ஒவ்வொரு பாதையும் மூன்று தேவைகளில் எதற்குச் சேவை செய்கிறது என்று எழுதி, எதற்கும் சேவை செய்யாத துறைமுக அனுப்புதலை நீக்குங்கள். பொது சுரங்கப்பாதை இல்லாமல் நிர்வகிக்கக்கூடிய, சுரங்கப்பாதையே உடைந்தபோதும் சரிசெய்யக்கூடிய குழுவே வடிவமைக்கத் தகுந்த விளைவு.