फ़ाइल सर्वर पर डिज़ाइन अनुमतियों के लिए अच्छा टोन नियम

मैं फ़ाइल सर्वर पर अनुमतियों को डिजाइन करने में अपना अनुभव साझा करना चाहता हूं। सिद्धांत और व्यवहार में, यूनिक्स और विंडोज (दो सबसे लोकप्रिय प्लेटफार्मों के रूप में) फ़ाइल सर्वर पर ऑब्जेक्ट को अनुमति देने के लिए पर्याप्त उपकरण और क्षमताएं प्रदान करते हैं। यह एक काफी सामान्य कार्य है जब आपके पास सैकड़ों उपयोगकर्ता, कुछ सर्वर और डायरेक्टरी ट्री के नेस्टिंग के कुछ ही स्तर होते हैं। सर्वर की संख्या, निर्देशिकाओं की संख्या में वृद्धि के साथ, और ऐसी कंपनियों में बहुत अधिक उपयोगकर्ता हैं, एक अप्रिय परिस्थिति उत्पन्न होती है - फाइल शेयरिंग बुनियादी ढांचे (समय और कर्मियों) का समर्थन करने के लिए खर्च तेजी से बढ़ रहे हैं। इस विषय में, मैं एक फ़ाइल साझाकरण सेवा के डिजाइन के लिए बुनियादी आवश्यकताओं के बारे में बात करना चाहता हूं, जिससे इसके लिए समर्थन को सरल बनाना और लागत कम करना संभव हो जाएगा। मैं आपका ध्यान पहले से आकर्षित करता हूं कि हम सर्वर (हार्डवेयर, फ़ाइल और ऑपरेटिंग सिस्टम) और वस्तुओं की सामग्री (सामग्री के प्रकार) को बनाए रखने की प्रक्रिया की चिंता नहीं करते हैं, लेकिन केवल साझा संरचना के डिजाइन पर विचार करते हैं।


आइए उन परिस्थितियों का वर्णन करें जिन्हें हम एक उदाहरण और वास्तविक अनुप्रयोग के रूप में मानेंगे।
फिलहाल उपलब्ध:

• पांच कोर फाइल शेयरिंग सर्वर
• प्रत्येक सर्वर पर नेस्टिंग के पाँच से अधिक स्तर
• प्रत्येक सर्वर पर 500 से अधिक निर्देशिका
• प्रत्येक सर्वर पर 10 हजार से अधिक फाइलें
• 300 से अधिक उपयोगकर्ता

इस स्थिति के लिए सर्वर, उपयोगकर्ताओं, नेटवर्क के बुनियादी ढांचे का भौगोलिक स्थान विशेष महत्व नहीं है।

कुछ वर्षों के लिए इस बुनियादी ढांचे का उपयोग करने के परिणामस्वरूप, कई सिस्टम प्रशासक बदलते हुए, नियमित रूप से उपयोगकर्ताओं के अनुरोध पर निर्देशिकाओं (लक्ष्यों के लिए महत्वपूर्ण अनुमति नहीं देना), यहां तक ​​कि सावधानीपूर्वक प्रलेखन के साथ, परिवर्तन प्रक्रियाओं का अवलोकन करना और ऐसे सर्वरों में बुनियादी ढांचे में बदलाव का ट्रैक रखना। निर्देशिका अनुमतियों में गड़बड़ी है। गड़बड़ी की एक विशिष्ट अभिव्यक्ति: आपको यह समझने की आवश्यकता है कि उपयोगकर्ता, इवानोवा ओल्गा (उदाहरण के लिए अनुवादक) के पास वित्त के बारे में जानकारी के साथ एक कैटलॉग तक पहुंच है, और वह इसे संपादित भी कर सकती है। हम कैटलॉग की अनुमतियों को खोलते हैं, इस उपयोगकर्ता के लिए प्रभावी एक्सेस अनुमतियों का अनुकरण करते हैं और देखते हैं कि वह वहां तितलियों को भी प्रजनन कर सकती है, हालांकि सदस्यता समूहों में दो स्तरों से ऊपर देखते हुए यह नहीं होना चाहिए। सवाल उठता है: यह स्थिति कैसे विकसित हुई? निश्चित रूप से कारण अनुमतियों की विरासत है, हालांकि पहली नज़र में कुछ विशेष अनुमतियाँ भी हो सकती हैं। एक रिवर्स स्थिति हो सकती है जब कोई उपयोगकर्ता उन दस्तावेजों तक पहुंच प्राप्त नहीं कर सकता है जिन्हें वह संपादित करने वाला है, और यहां एक नियम के रूप में खर्च करने के लिए पहले से ही आवश्यक है, कारणों की तलाश में और अधिक समय और त्रुटियों को ठीक करना। यह सब समय के एक बड़े निवेश की ओर ले जाता है जो वास्तव में उचित योजना और डिजाइन अनुपालन से बचा जा सकता था।

इस स्थिति के समाधान के रूप में क्या प्रस्तावित किया जा सकता है (और जैसा कि हम बाद में देखेंगे, अधिकांश फ़ाइल सर्वर उठता है)। शुरुआत के लिए, यह फ़ाइल साझाकरण बुनियादी ढांचे के लिए डिजाइन विकास है। डिज़ाइन में कम से कम निम्नलिखित क्षेत्रों का वर्णन करने वाला एक दस्तावेज़ शामिल होना चाहिए:

• लक्ष्य
• इस नीति के अनुपालन के लाभ
• आवेदन के क्षेत्र
• फ़ाइल का उपयोग तार्किक संरचना आवश्यकताओं
• साझा किए गए ऑब्जेक्ट्स के लिए एक्सेस अनुमतियों की आवश्यकताएं
• भूमिकाएँ जो आवश्यक हैं / इस बुनियादी ढांचे के डिजाइन, कार्यान्वयन, समर्थन में भाग लेंगे
• बुनियादी ढांचे के कार्यान्वयन और समर्थन में जोखिम
• मुख्य समस्याएं जो डिजाइन, कार्यान्वयन, समर्थन के दौरान हो सकती हैं
• किसी भी अन्य नीतियों, समझौतों, अनुबंधों के साथ संबंध जो फ़ाइल साझा सेवा के डिजाइन, कार्यान्वयन और समर्थन को प्रभावित कर सकते हैं

मैं तार्किक संरचना और पहुंच की अनुमति के लिए आवश्यकताओं पर ध्यान केंद्रित करना चाहता हूं, डिजाइन के शेष वर्गों का वर्णन सेवा प्रबंधन के क्षेत्र से संबंधित है और इस विषय के दायरे से परे है।

सेवा का समर्थन करते समय कई त्रुटियों से बचने के लिए मुख्य सिफारिशें:

• निर्देशिका ट्री की तार्किक संरचना के लिए, सभी सर्वरों पर एकल डिज़ाइन का उपयोग करना सबसे अच्छा है
• सभी सर्वरों पर, समान प्रविष्टि बिंदुओं को निर्देशिकाओं (रूट स्तर) का उपयोग करने की अनुशंसा की जाती है
• सभी निर्देशिकाएं जिनके पास विशेष पहुंच अधिकार होना चाहिए, उन उपयोगकर्ताओं के लिए अपने स्वयं के समूह होने चाहिए जिन्हें इस निर्देशिका तक पहुंच की आवश्यकता है
• निर्देशिकाओं तक पहुंच प्रदान करने के लिए, अलग-अलग उपयोगकर्ता समूहों का उपयोग करने की सिफारिश की जाती है जिन्हें अन्य समूहों से अलग कंटेनर में रखा जाना चाहिए
• सभी समूहों के पास पहुंच के लिए एकल पूर्वनिर्धारित नामकरण डिजाइन होना चाहिए।
• निर्देशिकाओं पर अनुमतियां केवल उस समूह के सदस्यों में शामिल किए जाने के माध्यम से जारी की जा सकती हैं जो इस निर्देशिका से मेल खाती हैं (कभी-कभी किसी व्यक्तिगत उपयोगकर्ता से सीधे)
• किसी नई बनाई गई निर्देशिका के लिए अनुमतियाँ सेट करते समय, सभी सिस्टम गैर-इनहेरिट की गई पहुँच समूह को हटा दिया जाना चाहिए
• अनुमति विरासत को रूट निर्देशिका (रूट स्तर) से शुरू करने में सक्षम होना चाहिए और किसी भी स्थिति में अक्षम नहीं होना चाहिए
• वस्तुओं तक पहुंच केवल अधिकारों के दो मूल सेटों को देने के द्वारा दी जा सकती है - पढ़ने के लिए (वस्तुओं की सूची पढ़ें, अनुमतियाँ पढ़ें, सामग्री पढ़ें) और बदलने के लिए (अधिकार + सामग्री बदलें, फ़ाइलों और निर्देशिकाओं को हटाएं, फाइलें और निर्देशिकाएं बनाएं)। कुछ मामलों में, आप विशेष समूहों (एक अलग प्रकार के समूह) का उपयोग कर सकते हैं जो एक्सेस अधिकारों के दो बुनियादी पूर्ण सेटों का केवल आवश्यक हिस्सा प्रदान कर सकते हैं
• किसी भी परिस्थिति में "पहुंच से इनकार" का उपयोग न करें
• आंखों से अतिरिक्त निर्देशिकाओं को छिपाने के लिए, यदि आवश्यक हो, तो एबीई का उपयोग करने की सिफारिश की जाती है या यदि आवश्यक हो, न केवल पहुंच से इनकार करते हैं, बल्कि यदि संभव हो तो, उनकी अनुपस्थिति की दृश्यता सुनिश्चित करें

सहायक फ़ाइल साझाकरण में विशेष ध्यान अंतिम तीन बिंदुओं को दिया जाना चाहिए, क्योंकि उनमें से किसी का उल्लंघन घटनाओं की जांच और सेवा के आगे के डिजाइन और विकास को बहुत जटिल करता है। एक्सेस अनुमतियों के साथ कोई भी आवश्यक कार्रवाई अंतिम तीन बिंदुओं के भीतर की जा सकती है।
इन नियमों का अनुपालन आपकी साझा सेवा को स्केलेबल, किसी भी इंजीनियर के लिए समझने योग्य, अधिक सुरक्षित बनाता है। मुख्य परिणाम सेवा समर्थन लागत और कुछ जोखिमों में स्पष्ट कमी होगी।

पुनश्च

इस मामले में डिजाइन के शेष खंड (लक्ष्य, जोखिम, भूमिका, अन्य नीतियों के साथ संबंध) इष्टतम और सफल डिजाइन, कार्यान्वयन और सेवा के समर्थन के लिए कम महत्वपूर्ण नहीं हैं। निम्नानुसार उन्हें डिज़ाइन अनुमतियों से कम ध्यान देने या निर्देशिका संरचना में ऑर्डर बनाए रखने की आवश्यकता नहीं है।
बिंदु 10 के बारे में होलीवर से बचने के लिए, मैं तुरंत जोड़ना चाहता हूं कि किसी भी निषेध का उपयोग ठीक से डिज़ाइन की गई अनुमतियों से किया जा सकता है। "इनकार एक्सेस" का उपयोग करना घोंसले के उच्च स्तर के साथ घटनाओं की जांच को बहुत जटिल करता है, लेकिन छोटे लोगों के साथ भी यह बहुत परेशानी हो सकती है। तदनुसार, उपयोग के अधिकारों के उत्तराधिकार और केवल अनुमेय सेटों का उपयोग एक पारदर्शी विरासत तंत्र में विश्वास दिलाता है और यह कि कई स्तरों के बीच कहीं भी आप से कुछ भी छिपा नहीं है।
एबीई के साथ, आपको बहुत सावधानी बरतने और इसकी उपस्थिति के बारे में याद रखने की आवश्यकता है, अन्यथा घटनाओं की जांच करते समय बहुत घबराहट होगी।