एक फाइल आणण्यासाठी संपूर्ण नेटवर्क VPN आवश्यक नाही

VPN प्रवेशाची विनंती अनेकदा तिच्या मागे एक फोल्डर आणि एक फाइल लपवते. संपूर्ण कार्यालय नेटवर्कला मार्ग देणे विनंतीला उत्तर देते आणि कामाच्या गरजेपेक्षा खूप जास्त सुपूर्द करते. मॅप केलेले सामायिकरण अपलोड पृष्ठाने बदलणे दुसऱ्या दिशेनेही तितकेच चुकीचे ठरू शकते, कारण ते लोक कसे काम करतात ते बदलते. निर्णय फाइलशी काय व्हायला हवे यापासून सुरू होतो.

तीन गरजा येथे एकसारख्या दिसतात आणि खूप वेगळ्या पद्धतीने वागतात: तयार PDF ची प्रत करणे, दस्तऐवज त्याच्या जागी संपादित करणे आणि सामायिक डिरेक्टरीविरुद्ध अनुप्रयोग चालवणे.

फोल्डरपासून नाही, संपादनापासून सुरुवात करा

फाइल तयार असेल आणि फक्त वाचायची असेल, तर हस्तांतरण खाते पुरते. ती संपादित करायची असेल, तर प्रश्न असा होतो की दुसरा कोण संपादित करतो आणि संघर्ष कसे सोडवले जातात, हा नेटवर्कचा नाही तर कार्यप्रवाहाचा प्रश्न आहे. अनुप्रयोग डिरेक्टरीतून थेट दस्तऐवज उघडत असेल, तर साठवण स्तराचा विलंब आणि लॉकिंग वर्तन महत्त्वाचे आहे. याला प्रथम उत्तर दिल्यास अशा उपायाला प्रतिबंध होतो जो उत्तम प्रकारे जोडतो पण तरीही वापरता येत नाही.

सामायिक संपादन अशी समस्या आणते जी कोणतेही हस्तांतरण सोडवू शकत नाही. वापरकर्ता स्प्रेडशीट डाउनलोड करतो, ऑफलाइन संपादित करतो आणि दुसऱ्याने मूळ बदलल्यानंतर अपलोड करतो, आणि एन्क्रिप्टेड कनेक्शनला ओव्हरराइटबद्दल कोणतेही मत नसते. ओव्हरराइट, संघर्ष किंवा आवृत्तीबद्दलचा करार प्रवेश पद्धतीपूर्वी असणे आवश्यक आहे.

SFTP हा हस्तांतरण प्रोटोकॉल आहे, सामायिकरण नाही

SFTP एन्क्रिप्टेड SSH वाहतुकीवर फाइली हलवते, जे प्रतीला नेमके हवे असते आणि मॅप केलेल्या ड्राइव्हला नको असते. हे FTP नाही, आणि FTPS देणारे उत्पादन SFTP ऐवजी दुसरा प्रोटोकॉल देते. फाइलसिस्टम स्तराद्वारे SFTP डिरेक्टरी माउंट करणे मूळ सामायिकरणाचे लॉकिंग, परवानगी किंवा अनुप्रयोग वर्तनाची हमी देत नाही. त्याला थेट बदली म्हणण्यापूर्वी क्लायंट अनुप्रयोगाच्या गरजा तपासा.

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

तयार फाइलसाठी संपूर्ण कार्यप्रवाह हाच आहे: जोडा, ठेवा, घ्या. फक्त हस्तांतरणासाठीच्या खात्यालाही मर्यादित SSH सेवा हवी, फक्त फाइलसिस्टम नाही. chroot किंवा ForceCommand internal-sftp सत्र काय चालवू शकते हे मर्यादित करते, आणि TCP फॉरवर्डिंग व टनेलिंग बंद केल्यास फाइल खात्याचे नेटवर्क प्रवेश बिंदू होण्याचे मार्ग बंद होतात. फक्त दिसणारी डिरेक्टरी मर्यादित केल्याने खाते कुठपर्यंत पोहोचू शकते याबद्दल काहीही सिद्ध होत नाही.

तुम्हाला सामायिकरण हवे असल्यास ते प्रकाशित करू नका

कधीकधी मूळ सामायिकरण हीच खरी गरज असते, आणि उत्तर SMB अनियंत्रित इंटरनेट क्लायंटसमोर उघडणे नाही. Microsoft चे मार्गदर्शन सीमेवर थेट SMB रहदारी अवरोधित करणे आहे, आणि त्याला चांगे कारण आहे: प्रोटोकॉल अविश्वासार्ह नेटवर्कना सामोरे जाण्यासाठी बनवलेला नाही. QUIC वर SMB आणि तत्सम रचना अस्तित्वात आहेत, दोन्ही टोकांना विशिष्ट प्लॅटफॉर्म गरजांसह, आणि त्या अनियंत्रित Samba सर्व्हरसाठी सार्वत्रिक स्विच नाहीत. दोन्हीपैकी कोणतेही लागू नसेल, तर काम फॉरवर्ड केलेल्या पोर्टऐवजी समर्थित प्रवेश मार्ग देणे आहे.

काम त्याला अनुकूल असेल तेव्हा ब्राउझर-आधारित पर्याय हे कायदेशीर तिसरे उत्तर आहे. तो स्वतःचे निर्णय आणतो: खाती, सामायिकरण दुवे, कालबाह्यता, ठेवलेल्या आवृत्त्या आणि कोणती प्रत अधिकृत आहे. कोणीही उघडू शकणारा दुवा आणि साइन-इन आवश्यक असलेली कार्यजागा वेगवेगळ्या प्रवेश धोरणांचे प्रतिनिधित्व करतात, आणि दोन्हीपैकी कोणतेही अपघाताने निवडू नये.

प्रवेश सुपूर्द करण्यापूर्वी काय तपासावे

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

तुम्ही कोणतीही रचना निवडा, ती इच्छित डेटा आणि इच्छित क्रियांपुरती मर्यादित ठेवा. पहिला आदेश यशस्वी व्हायला हवा आणि दुसरा नाकारला जायला हवा; दोन्ही यशस्वी झाले तर खाते कामापेक्षा विस्तृत आहे. नंतर खाते काढून टाका आणि पहिला पुन्हा करा, जो आता अयशस्वी व्हायला हवा. स्रोत फाइलींचा मालक ओळखण्यायोग्य ठेवा, जेणेकरून अधिकृत प्रतीबद्दलच्या नंतरच्या प्रश्नाला उत्तर असेल. नोंदवण्यासारखा निकाल म्हणजे वापरण्यायोग्य आणि रद्द करण्यायोग्य फाइल कार्यप्रवाह, गायब कनेक्शन चिन्ह नाही.

वापरकर्त्याच्या अनुप्रयोगाला प्रत्यक्षात कोणता प्रोटोकॉल हवा आणि तुम्ही कोणत्या तीन चाचण्या केल्या ते लिहा. त्या दोन ओळी बहुतेक पुनर्काम टाळतात.