VPN விதி ஒரு கோப்பைப் பதிவேற்றுவதைத் தடுக்க முடியாதது ஏன்
ஒரு சேவையை அடைவதும், அதிலிருந்து எந்தக் கோப்புகள் வெளியேறுகின்றன என்பதைக் கட்டுப்படுத்துவதும் இரண்டு தேவைகள். கோப்பு தெரியும் இடத்தில் விதியை வையுங்கள்: மின்னஞ்சல், பயன்பாடு அல்லது இறுதிப் புள்ளி முகவர்.
ஒரு சிறிய குழு தனது பணி அமைப்புகளுக்கு தொலை அணுகலைக் கேட்கிறது, அதே மூச்சில் சில இணைப்புகள் நிறுவனத்தை விட்டு வெளியேறுவதை நிறுத்த வேண்டும் என்றும் கேட்கிறது. இரண்டு கோரிக்கைகளும் ஒரே VPN மாற்றம் போலத் தெரிகின்றன. அவை வெவ்வேறு அமலாக்கப் புள்ளிகளைக் கொண்ட இரண்டு தேவைகள், முதல் தேவையை நிறைவேற்றும் விதி இரண்டாவதற்கு எதுவும் செய்யாது. முதலில் செயலையும் தரவையும் பெயரிட்டு, அவற்றை உண்மையில் பார்க்கக்கூடிய கூறைத் தேர்ந்தெடுங்கள்.
ஒரு கோரிக்கை, இரண்டு தேவைகள்
முதல் தேவை அணுகல்தன்மையைப் பற்றியது: எந்தப் பயனர்களும் சாதனங்களும் எந்தச் சேவைக்கு இணைப்பைத் திறக்கலாம். இரண்டாவது அந்த இணைப்பு ஏற்பட்ட பிறகான நடத்தையைப் பற்றியது: எந்த ஆவணங்களை இணைக்கலாம், ஒட்டலாம் அல்லது பதிவேற்றலாம். சுரங்கப்பாதை முதல் தேவையில் செயல்படுகிறது, வடிவமைப்பின் படி இரண்டாவதற்குக் குருட்டுத்தன்மை கொண்டது.
IP மட்டத்திலான கட்டுப்பாடு பாக்கெட்டுகளை அனுப்புகிறது. அது பல்பகுதி பதிவேற்றத்தை பகுப்பாய்வு செய்யாது, PDF-ஐ பரிசோதிக்காது, விரிதாளில் கணக்கு எண்கள் உள்ளனவா என்பதைத் தீர்மானிக்காது. அதை அதிலிருந்து எதிர்பார்ப்பது கட்டமைப்புப் பிழை அல்ல; அது வகைப் பிழை.
ஒரு தயாரிப்பைத் தேடும் முன் தேவையை அதே வடிவில் சத்தமாகச் சொல்லுங்கள். «பயனர்கள் கோப்பு வலைவாசலை அடையலாம்» மற்றும் «பயனர்கள் வாடிக்கையாளர் பட்டியல்களை கோப்பு வலைவாசலில் பதிவேற்ற முடியாது» வெவ்வேறு வாக்கியங்கள், இரண்டாவது மட்டுமே உள்ளடக்கக் கொள்கையை விவரிக்கிறது.
கோப்பைப் பார்க்கக்கூடிய கூறைத் தேர்ந்தெடுங்கள்
அமலாக்கம் கோப்பு படிக்கக்கூடிய இடத்தில் நடைபெற வேண்டும். மின்னஞ்சலுக்கு இது வழக்கமாக மின்னஞ்சல் தளம் அல்லது நுழைவாயில், ஏற்கனவே இணைப்புகளைக் கையாள்கிறது மற்றும் வழங்கலுக்கு முன் அவற்றை மதிப்பிட முடியும். அங்கீகரிக்கப்பட்ட சேவைக்கு உலாவி பதிவேற்றங்களுக்கு, பயன்பாடே உள்ளடக்கத்தைப் பார்க்கும் ஒரே தரப்பாக இருக்கலாம். நிர்வகிக்கப்படும் மடிக்கணினி கோப்புகளை நீக்கக்கூடிய ஊடகத்திற்கு நகலெடுக்கும்போது இறுதிப் புள்ளி முகவர் அந்தச் செயலைப் பார்க்கிறது.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
சில வணிக தொலை அணுகல் தொகுப்புகள் இறுதிப் புள்ளி முகவர், வலைக் கட்டுப்பாடு மற்றும் தரவு இழப்பு தடுப்பு தொகுதியை ஒன்றாகத் தருகின்றன. அந்தக் கூறுகள் உள்ளடக்கக் கொள்கையை அமல்படுத்தலாம், ஆனால் திறன் சுரங்கப்பாதைக்கு அல்ல, தொகுதிக்கு உரியது. முடிவை உறுதியளிக்கும் முன் தொகுப்பில் உண்மையில் என்ன உள்ளது என்பதைப் படியுங்கள்.
ஒப்பிடுவதற்குப் பயனுள்ள மாதிரி Microsoft-இன் Purview தரவு இழப்பு தடுப்பு மேலோட்டம் ஆகும்: அது கொள்கைகளை மறையுணர்வு தகவல் வகைகள், இருப்பிடங்கள் மற்றும் செயல்பாடுகளின் அடிப்படையில் விவரிக்கிறது. அந்தச் சொல்லகராதி உள்ளடக்கம் மற்றும் செயல்களைப் பற்றியது, IP முன்னொட்டுகளைப் பற்றியது அல்ல.
TLS சுரங்கப்பாதையைக் கடந்து வாழ்கிறது, எனவே அதற்குத் திட்டமிடுங்கள்
பயன்பாட்டு குறியாக்கம் வாடிக்கையாளருக்கும் சேவைக்கும் இடையே பேச்சுவார்த்தை செய்யப்படுகிறது, VPN சுரங்கப்பாதை அந்த பைட்டுகளைத் திறக்காமல் எடுத்துச் செல்கிறது. எனவே பாதையில் உள்ள நுழைவாயில் ஒரு இணைப்பை வகைப்படுத்தும் திறனைத் தானாகப் பெறாது, பாதையின் எவ்வளவு பங்கு அதற்கு இருந்தாலும்.
பயணத்தில் உள்ளடக்கத்தைப் பரிசோதிக்க நம்பகமான சான்றிதழுடன் TLS-ஐ முடிக்கும் கூறு தேவை, அது அதன் சொந்தத் தனியுரிமை மற்றும் செயல்பாட்டு விளைவுகளைக் கொண்ட முக்கியக் கட்டமைப்பு முடிவு. இது VPN சுயவிவரத்தில் ஒரு தேர்வுப்பெட்டி அல்ல. வாடிக்கையாளர்கள் பரிசோதனைச் சான்றிதழை நம்ப வேண்டும், சான்றிதழ்களைப் பூட்டும் பயன்பாடுகள் உடையும், இயக்குபவர் முன்பு படிக்க முடியாத போக்குவரத்தைப் படிக்கும் திறனைப் பெறுகிறார். இந்த முடிவு சுரங்கப்பாதையை இயக்குபவருக்கு அல்ல, பாதுகாப்பு உரிமையாளருக்கு உரியது என்பதற்கு இதுவே காரணங்கள்.
எனவே «VPN இந்தப் பதிவேற்றத்தைத் தடுக்க முடியுமா» என்ற கேள்விக்கு நேர்மையான பதில் பொதுவாக இல்லை என்பதே, அதைத் தொடர்ந்து ஒரு உறுதியான மாற்று வருகிறது. மாற்று பயன்பாட்டு மட்டக் கட்டுப்பாடுகள், மின்னஞ்சல் விதி அல்லது இறுதிப் புள்ளிக் கொள்கையாக இருக்கலாம், ஒவ்வொன்றுக்கும் அதை மாற்றக்கூடிய உரிமையாளர் உண்டு.
விதிக்கு முன் ஏற்புப் பரிசோதனையை எழுதுங்கள்
உள்ளடக்க விதிக்கு ஒன்றல்ல, இரண்டு எடுத்துக்காட்டுகள் தேவை: தொடர்ந்து செயல்பட வேண்டிய அனுமதிக்கப்பட்ட செயல், மற்றும் நிறுத்தப்பட வேண்டிய தடைசெய்யப்பட்ட செயல். வரம்பில் உள்ள பயன்பாடுகள் மற்றும் சாதனங்களில் இருந்து இரண்டையும் சோதியுங்கள், ஏனெனில் ஒரு உலாவியில் மட்டும் செயல்படும் கொள்கை யாரோ கேட்ட கொள்கை அல்ல.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadமுதல் கோரிக்கையை விதியைக் கொண்ட கூறு நிராகரிக்க வேண்டும், இரண்டாவது வெற்றிபெற வேண்டும். இரண்டும் வெற்றிபெற்றால் கட்டுப்பாடு பாதையில் இல்லை. இரண்டும் தோல்வியடைந்தால் நீங்கள் சேவையைப் பாதுகாப்பதற்குப் பதிலாக உடைத்துள்ளீர்கள், அனுமதிக்கப்பட்ட எடுத்துக்காட்டு இல்லாமல் எழுதப்பட்ட விதியின் பொதுவான முடிவு அதுவே.
பயனர் என்ன பார்க்கிறார், யார் விதிவிலக்கு வழங்கலாம், நிர்வாகி பின்னர் எங்கே முடிவை உறுதிப்படுத்துகிறார் என்பதை முன்கூட்டியே முடிவு செய்யுங்கள். செய்தி இல்லாமல் தடுக்கப்பட்ட பதிவேற்றம் ஒரு ஆதரவு டிக்கெட்டை உருவாக்குகிறது, யாரும் தணிக்கை செய்ய முடியாத விதி ஒரு விவாதத்தை உருவாக்குகிறது. கொள்கை நடைமுறைக்கு வரும் முன் எழுதப்பட்ட ஒரு வாக்கிய ஆவணப்படுத்தலால் இரண்டையும் தவிர்க்கலாம்.
இறுதியாக, இரண்டு தேவைகளையும் வெவ்வேறு உரிமையாளர்களுடன் வெவ்வேறு டிக்கெட்டுகளில் வையுங்கள். அவற்றை «VPN» கீழ் ஒன்றிணைப்பது, பிணையக் குழுவிடம் உள்ளடக்கச் சிக்கலைத் தீர்க்கக் கேட்கப்படும் என்பதையும், சுரங்கப்பாதை எழும்போது உள்ளடக்கச் சிக்கல் தீர்க்கப்பட்டதாக அறிவிக்கப்படும் என்பதையும் உறுதி செய்கிறது.