क्या यह फ़ाइल सर्वर अनुमतियों के लिए अनुशंसित / मान्य दृष्टिकोण है?


10

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

अपनी वर्तमान नौकरी में, मैंने ACL पर दर्जनों समूहों से लेकर अलग-अलग उपयोगकर्ताओं को सीधे फाइलसिस्टम पर डालने के लिए अलग-अलग तरीकों से ऐसा करने में काफी गड़बड़ की है। मेरा काम गंदगी को साफ करना था और कंपनी (बड़े पर्यावरण, 150k कर्मियों, 90k क्लाइंट कंप्यूटर, 100 के फ़ाइल सर्वरों) में इस तरह के दृष्टिकोण के कुछ मानकीकृत तरीके के साथ आना था।

इस मुद्दे की मेरी समझ से, ऐसा लगता है कि आपको कम से कम एक समूह प्रति आवश्यक पहुँच स्तर प्रति सुरक्षित संसाधन की आवश्यकता है। यह मॉडल सबसे अधिक लचीलापन देने के लिए लगता है कि आपको फाइल सिस्टम अनुमतियों को फिर से छूने की आवश्यकता नहीं है जब तक कि आपको एक अलग पहुँच स्तर का समर्थन करने की आवश्यकता न हो। नकारात्मक पक्ष यह है कि आप एक से अधिक साझा संसाधनों पर एक ही समूह का पुनः उपयोग करने की तुलना में अधिक समूह बनाएंगे।

यहाँ एक उदाहरण दिखाया गया है जिसका मेरा मतलब है:

FILE01 नामक फ़ाइल सर्वर पर "परीक्षण के परिणाम" नामक एक हिस्सा है और आपके पास ऐसे लोग हैं जिन्हें केवल-पढ़ने के लिए उपयोग, पढ़ने-लिखने और पूर्ण नियंत्रण की आवश्यकता है। 1 सुरक्षित संसाधन * 3 पहुँच स्तर = 3 सुरक्षा समूह। हमारे AD वातावरण में, हम इन्हें सार्वभौमिक समूह बनाते हैं ताकि हम जंगल के किसी भी डोमेन से उपयोगकर्ताओं / समूहों को आसानी से जोड़ सकें। चूंकि प्रत्येक समूह विशिष्ट रूप से एक साझा फ़ोल्डर और एक्सेस स्तर को संदर्भित करता है, समूह के नाम उन "कुंजी" डेटा के टुकड़ों को शामिल करते हैं और अनुमतियाँ इस प्रकार हैं:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

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

दो सवाल:

1) क्या यह वास्तव में अनुमतियों को संभालने के लिए अनुशंसित या मान्य दृष्टिकोण है या मैं कुछ सरल, अधिक सुरुचिपूर्ण समाधान याद कर रहा हूं? मैं विशेष रूप से किसी भी समाधान में दिलचस्पी लेता हूँ जो विरासत का उपयोग करते हैं लेकिन फिर भी जब चीजें बदलती हैं तो फाइल सिस्टम के बड़े हिस्सों को फिर से एसीएल में न रखने में लचीलापन बनाए रखते हैं।

2) आप अपने वातावरण में फ़ाइल सर्वर अनुमतियों और समूह संरचना को कैसे संभाल रहे हैं? उन लोगों के लिए बोनस अंक जो बड़े वातावरण में भी काम कर रहे हैं।


बहुत ही रोचक सवाल। अच्छे वर्णन के लिए +1। अच्छी तरह से पढ़ने लायक।
जॉन उर्फ ​​हॉट2use 12

जवाबों:


5

मेरा दृष्टिकोण फ़ाइल / निर्देशिका स्तर फ़ाइल अनुमतियों का उपयोग नहीं करना है; फ़ाइल शेयर स्तर की अनुमतियों का उपयोग करें, और सभी सर्वर फ़ाइल सिस्टम डेटा ड्राइव को सभी पूर्ण नियंत्रण (जो मूट हो जाता है) पर सेट करें।

इन वर्षों में (10+), मैंने पाया है कि NTFS अनुमतियां अधिक जटिल हैं और अधिक त्रुटियों की ओर ले जाती हैं। यदि अनुमतियाँ गलत हैं, या वंशानुक्रम टूट गया है, तो आप डेटा और इसे खोजने और इसे देखने के लिए कड़ी मेहनत को उजागर करते हैं। साथ ही, आपको मूव / कॉपी समस्या से अवगत कराया जाता है ... फाइल को स्थानांतरित करने वाले उपयोगकर्ता फ़ाइल के ACL को भी स्थानांतरित करते हैं, जबकि प्रतिलिपि गंतव्य ACL को इनहेरिट करती है।

अपने पढ़ने / लिखने वाले समूहों का उपयोग करें, लेकिन संपूर्ण फ़ाइल शेयर पर Comp Mgmt MMC का उपयोग करें। पूर्ण मत करो ... उपयोगकर्ता आंशिक-ज्ञान / सर्वश्रेष्ठ इरादों के साथ खुद को गोली मार लेंगे।


मैं भी इस दृष्टिकोण का उपयोग करता हूं और मुझे लगता है कि यह छोटे से मध्यम आकार के व्यवसायों के लिए अच्छी तरह से काम करता है जहां पहुंच आवश्यकताएं विस्तृत नहीं हैं।
केविन कुफल

+1 यह एक उपन्यास और दिलचस्प दृष्टिकोण है। अगर मैं आपको सही तरीके से समझ रहा हूं, तो आप NTFS के बजाय ACL को शेयर पर सेट करेंगे और हर "संसाधन" को अपना हिस्सा बनाएंगे। यह कदम / कॉपी समस्या को साइड-स्टेप करने के साथ-साथ बदलती अनुमतियों को त्वरित और पीड़ारहित बना देगा क्योंकि आपको बदलाव करने के लिए आवश्यक सभी फाइलों / फ़ोल्डरों को नहीं छूना होगा। नेस्टेड संसाधनों के लिए डीएफएस के कुछ रचनात्मक उपयोग के साथ संयुक्त, इस दृष्टिकोण के कुछ स्पष्ट फायदे हैं।
डेविड आर्चर

7

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

TechNet वेबकास्ट: विंडोज सर्वर 2003 प्रशासन श्रृंखला (12 का भाग 4): समूह प्रबंधन (स्तर 200)

अभिगम आधारित अभिगम जीवन को आसान भी बना सकता है:

अभिगम आधारित अभिगम

ABE आपके द्वारा प्रबंधित किए जाने वाले विभिन्न शेयरों की संख्या को कम करने में मदद कर सकता है।


जिम, मुख्य "जाल" से मैं चिंतित हूं कि एक ही समूह को कई संसाधनों में फिर से उपयोग करने से, इसका जवाब देने का कोई तरीका नहीं है कि "समूह X के पास क्या संसाधन हैं?" पर्यावरण में हर संसाधन की जांच किए बिना (माफ करना, अगर मैं यहां थोड़ा सार हूं)। इसके अलावा, यदि आप किसी अन्य समूह के रूप में अच्छी तरह से फ़ाइलों का उपयोग करने की जरूरत है, तो आप फाइल-सिस्टम को फिर से ACL करने की जरूरत है।
डेविड आर्चर

@ डेविड, वास्तव में यह पूरी तरह सच नहीं है: जैसा कि आप एक वर्णनात्मक नाम के साथ संसाधन समूहों का नामकरण कर रहे हैं, आप भूमिका समूहों (प्रबंधकों का कहना है) पर जा सकते हैं और जाँच कर सकते हैं कि कौन से समूह (FileServer01_HR_RO और FileServer01_Mgmt_RW) से संबंधित हैं। बेशक, इस मॉडल को नामकरण और समूह सदस्यता मानक दोनों के साथ सख्त होना चाहिए। लेकिन इस या किसी भी अन्य मॉडल में सख्त नहीं होने से वैसे भी गड़बड़ हो जाएगी।
कर्पूर

@curropar: यह 7 साल हो गया है, लेकिन मुझे लगता है कि मैं जिस बारे में बात कर रहा था, अगर आप वास्तव में भूमिका समूह को सीधे एसीएलएस में डालते हैं तो यह समस्याग्रस्त होगा। हम वास्तव में उस परियोजना में भूमिका समूहों का उपयोग नहीं कर रहे थे जिस परियोजना में मैं काम कर रहा था, जिससे मूल प्रश्न प्रेरित हुआ क्योंकि यह सभी स्वचालित था। उपयोगकर्ता सीधे ऑनलाइन वेब फ़ॉर्म का उपयोग करके संसाधन समूहों तक पहुंच का अनुरोध करेंगे और संसाधन स्वामी (व्यवसाय के लोग) उन अनुरोधों को स्वीकृत / अस्वीकार करने के लिए जिम्मेदार थे।
डेविड आर्चर

यह समझ आता है; और भले ही यह 7 वर्ष का हो, मैं अपने फ़ाइल सर्वर के लिए मॉडल की तलाश कर रहा था, और यह पोस्ट Google खोज में थी, इसलिए मैंने भविष्य के आगंतुकों के लिए टिप्पणी की, बस मामले में;)
13

1
@curropar लगता है कि मैं वर्षों पहले के सवालों के जवाब नहीं देता। जहां तक ​​ऑडिटिंग की बात है, आपको हर संसाधन का वैसे भी ऑडिट करना होगा क्योंकि दूसरा तरीका मान्य ऑडिट नहीं है।
जिम बी

2

आपका दृष्टिकोण मूल रूप से मैं जिस तरह से यह दृष्टिकोण होगा।
केवल एक चीज जो मैं जोड़ूंगा वो ये हैं:

1) मैं आपकी "भूमिकाओं" योजना में यह मूल्यांकन करके जोड़ूंगा कि उन्हें उन सर्वरों की क्या आवश्यकता है जो केवल एक सर्वर पर नहीं हैं जो आप शायद आउटलेयर में चलाने जा रहे हैं, लेकिन मेरा सिद्धांत उन लोगों के साथ है जब आप उनमें भाग लेते हैं, एक और समूह बनाते हैं। मेरे अनुभव में जहाँ एक से एक बहार है वहाँ कई हैं।

2) मैं हर चीज के लिए सार्वभौमिक समूहों की आवश्यकता को फिर से स्पष्ट करूँगा क्योंकि आप उनके साथ एक हिट हिट लेते हैं क्योंकि यूनिवर्सल समूह के अंदर सदस्यों और समूहों को ग्लोबल कैटलॉग सर्वरों के लिए दोहराया जाता है जबकि डोमेन लोकल और ग्लोबल केवल समूह के साथ होता है। वैश्विक कैटलॉग सर्वर के लिए दोहराया गया। इसलिए यदि आप एक सार्वभौमिक समूह में बदलाव करते हैं तो यह एक प्रतिकृति को बंद कर देता है, जबकि वैश्विक और डोमेन स्थानीय के साथ ऐसा नहीं करता है।


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

बस इस पर फॉलो-अप करने के लिए: हमने समूहों को डोमेन लोकल में परिवर्तित करना समाप्त कर दिया और लगभग 6 महीने तक अच्छा काम किया। जब हमें एक आपदा रिकवरी वातावरण स्थापित करने की आवश्यकता होती है और एक डोमेन से फ़ाइल सर्वरों को दूसरे डोमेन से फ़ाइल सर्वरों के लिए प्रतिकृतियां के रूप में सेट किया जाता है, तो हमने समाप्त कर दिया कि हम वापस सार्वभौमिक समूहों में परिवर्तित हो जाएं क्योंकि अन्यथा, डीआर सर्वरों को ' उन अनुमतियों की व्याख्या न करें (चूंकि DR सर्वर स्रोत फ़ाइल सर्वर और डोमेन स्थानीय समूहों के समान डोमेन में नहीं थे)।
डेविड आर्चर

1

प्रत्येक एक्सेस स्तर के लिए संसाधन समूह का उपयोग करने का आपका तरीका सही है। केवल एक चीज जिस पर मैं विचार करूंगा वह है संसाधनों के लिए डोमेन स्थानीय समूहों का उपयोग करना। यदि आप सर्वर-विशिष्ट संसाधन समूह बना रहे हैं तो आपको सार्वभौमिक समूहों का उपयोग करने की आवश्यकता नहीं है।

संसाधनों के लिए डोमेन स्थानीय समूहों का उपयोग करने का नकारात्मक पक्ष यह है कि आप अधिक कुल समूहों के साथ समाप्त होते हैं। उल्टा यह है कि आपके पास प्रतिकृति के साथ समस्या कम है, जैसा कि ज़ीफ़र ने नोट किया है।


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

1

प्रस्तावित दृष्टिकोण काफी ठोस लगता है। एक बात के लिए बाहर देखने के लिए हालांकि आप शुरू में फ़ाइल शेयर सेट है जिस तरह से है। अनुशंसित अभ्यास में एक एकल शीर्ष-स्तरीय हिस्सा होता है, जिसमें सबफ़ोल्डर्स होते हैं जिन्हें आप तब समूह की अनुमतियाँ असाइन करते हैं। NTFS तब शीर्ष स्तर के फ़ोल्डर पर "ट्रैवर्स फ़ोल्डर / एक्सक्यूट फाइल" को बायपास कर सकता है और सबफ़ोल्डर को एक्सेस दे सकता है।

संरचना तब \ Servername \ sharename \ group-folder की तरह दिखेगी, जिसमें शेयर अनुमतियों के साथ केवल "sharename" फ़ोल्डर पर सेट करने की आवश्यकता होती है, और "समूह-फ़ोल्डर" फ़ोल्डर पर सेट वास्तविक NTFS अनुमतियाँ।

आपका फ़ाइल सर्वर इस तरह के सेटअप के साथ बेहतर प्रदर्शन करने में सक्षम होगा।

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


हाँ, हम AD समूह नाम लंबाई सीमाओं के कारण विवरण में UNC डाल रहे हैं। मेरे उत्पादन वातावरण में, समूह का नाम फ़ोल्डर में बैकस्लैश के साथ पूर्ण UNC पथ को डैश में परिवर्तित कर देता है। यदि नाम फिट होने के लिए बहुत बड़ा है, तो हम अंत बंद (-RW या -RO प्रत्यय से पहले) काटते हैं और 001 पर शुरू होने वाले 3 अंकों की वृद्धिशील संख्या डालते हैं। सबसे सरल दृष्टिकोण नहीं है, लेकिन यह सुसंगत और ईडी के प्रश्न के लिए पर्याप्त आसान है।
डेविड आर्चर

1

विंडोज 2000 के बाद से मैं विंडोज फाइल सर्वर के लिए जो मानक अभ्यास कर रहा हूं, (मार्क मिनसी की मास्टरिंग विंडोज सर्वर श्रृंखला में रखा गया है, इसलिए वहां अधिक जानकारी के लिए देखें) उन समूहों का उपयोग करना है जो फ़ाइल सर्वर के लिए स्थानीय हैं।

उदाहरण के लिए, MUPPETS नामक डोमेन में KERMIT नामक फ़ाइल सर्वर पर विचार करें।

कहो किर्मिट में कुछ फ़ाइल शेयर हैं:

\\KERMIT\Applications
\\KERMIT\Finance
\\KERMIT\Sales
\\KERMIT\Manufacturing

उपयोग के लिए KERMIT के लिए स्थानीय समूह बनाएं और उन्हें फ़ाइल सिस्टम पर ठीक वैसे ही अनुमति दें जैसे आपने निर्दिष्ट किया है (यानी प्रति शेयर प्रति एक्सेस स्तर)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

क्योंकि ये स्थानीय समूह हैं, आप जो भी अन्य समूह या उपयोक्ता चाहें, उनमें डाल सकते हैं - डोमेन स्थानीय समूह, वैश्विक समूह, सार्वभौमिक समूह, आपके जंगल में किसी भी डोमेन के उपयोगकर्ता खाते। अधिकार प्रबंधन अब फ़ाइल सिस्टम या AD के बजाय फ़ाइल सर्वर के समूहों के लिए स्थानीय है।

इससे आपके समूह प्रबंधन में एक अतिरिक्त परत जुड़ जाती है, लेकिन इसमें उस फ़ाइल सर्वर के लिए व्यवस्थापक अधिकारों से अधिक आवश्यकता के बिना अपने स्वयं के फ़ाइल सर्वरों को प्रबंधित करने की अनुमति (कहना) साइट-स्थानीय व्यवस्थापक को लाभ होता है। यदि आपके पास शाखा कार्यालय संरचना का एक संघबद्ध प्रकार है, जहां हर कार्यालय का प्रकार अपने सर्वरों के साथ अपनी बात करता है, तो यह एक वास्तविक लाभ हो सकता है। आप कुछ दर्जन स्थानीय साइट व्यवस्थापक को AD व्यवस्थापक अधिकार देना नहीं चाह सकते हैं।

यह आपके AD को बहुत सारे समूहों (एक समूह प्रति एक्सेस स्तर प्रति सर्वर प्रति शेयर बहुत तेज़ी से जोड़ सकता है) से क्लू किया जा रहा है, और GCs के बीच समूह प्रतिकृति को कम करता है। यह आपको अनुमतियों के बजाय भूमिकाओं के लिए अपने विज्ञापन समूहों को आरक्षित करने की अनुमति देता है।

यदि आपका वातावरण कठोरता से मानकीकृत है और सभी फ़ाइल सर्वर समान और प्रतिकृति हैं, तो यह स्पष्ट रूप से उन समूहों की एक और परत है जिनकी आपको आवश्यकता नहीं है। इसके अलावा, यदि आप जानते हैं कि आपको प्रत्येक शेयर फ़ाइल सर्वर पर मौजूद समान अधिकारों के लिए एक विशेष AD समूह की आवश्यकता है, तो आपको इसे बनाए रखने के लिए कुछ स्वचालन की आवश्यकता होगी।

संक्षेप में, आपके फ़ाइल सर्वर एक दूसरे से जितने अलग हैं, मशीन स्थानीय समूहों का उपयोग करने में उतना ही अधिक अर्थ है। जितना अधिक वे समान हैं, जितना अधिक आप उस सिस्टम का उपयोग करना चाहते हैं जो आप वर्तमान में उपयोग कर रहे हैं।


0

मैं NetWare से Windows Server 2008 के माइग्रेशन को देख रहा हूं इसलिए यह हाल ही में मेरे दिमाग में आया है। सर्वर 2008 (और कुछ हद तक सर्वर 2003R2) में कुछ बहुत अच्छी विशेषताएं हैं जो वास्तव में इस संक्रमण को कम करती हैं। सर्वर 2008 बॉक्स के बाहर प्रवेश आधारित अभिगम के साथ आता है। यह एक बहुत अच्छी सुविधा है जो उपयोगकर्ताओं को केवल उन निर्देशिकाओं को देखने की अनुमति देती है जिनके पास उनके अधिकार हैं। यदि आपके पास एक शेयर है ...

\\ उपयोगकर्ता के घर SRV \ घरों \

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

एक और चीज जो सर्वर 2008 को लगता है कि वह अपने पहले के संस्करणों से बेहतर है, एसीएल इनहेरिटेंस है। यह सिर्फ एक बड़े पेड़ के शीर्ष पर एक एसीएल परिवर्तन के पत्ते को फैलाने में तेजी से लगता है।

हमारी नेटवेयर विरासत के कारण, हमारे पास बड़ी संख्या में ऐसे समूह हैं, जो उन पर आधारित हैं, जो उनमें से कुछ के साथ हैं, जिनके नाम पर वे उन लोगों के लिए नाम रखते हैं जो उन्हें एक्सेस देते हैं। उन निर्देशिकाओं के लिए, जिनके पास पुन: पहुंच है, हम "RO" "पूर्ण" नामकरण का भी उपयोग करते हैं।

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

मेरी पिछली नौकरी में हम अनुमतियाँ सेट करने में सक्षम थे, इसलिए नौकरियों के लिए आवेदन करने वाले एचआर कर्मचारी अपने सर्वर पर अपने स्वयं के आवेदन डेटा नहीं देख पाएंगे। इसे करने के लिए कुछ वंशानुक्रम-अधिकार-फ़िल्टर लगे, जो विंडोज़ पर "ब्लॉक इनहेरिटेंस" टैग के समान है। मुश्किल हिस्सा वहाँ यह सब दस्तावेज था, लेकिन यह काम किया


मैंने पहले वाली सगाई में ABE का उपयोग किया है, लेकिन मुख्य शिकायत यह थी कि उपयोगकर्ताओं से संसाधन (फ़ोल्डर) की मौजूदगी को छुपाना जो इसे एक्सेस नहीं कर सकते थे, इससे उनके लिए वास्तव में पहुंच का अनुरोध करना कठिन हो गया था यदि यह कुछ था। में उतरने की एक वैध आवश्यकता थी। मेरे वर्तमान परिवेश में, हमारे पास ये लिनक्स-आधारित NAS सर्वर हैं इसलिए ABE यहाँ कोई विकल्प नहीं है।
डेविड आर्चर

0

एक सर्वोत्तम स्थिति यह है कि प्रत्येक उपयोगकर्ता को उपयोगकर्ता की नौकरी की भूमिका के लिए सिर्फ एक सुरक्षा समूह में जोड़ा जाता है। इसके बाद भूमिका को जरूरत पड़ने पर पहुँच प्रदान की जाती है।

समान रूप से, एक साझा फ़ोल्डर को आपके "FILE01-Test Results-RW" उदाहरण की तरह "संसाधन" सुरक्षा समूहों का उपयोग करके पहुंच दी जानी चाहिए। इसमें नौकरी की भूमिका, विभाग की भूमिका या अन्य लागू समूह होंगे।

इस डिज़ाइन का उल्टा यह है कि आप प्रति-समूह आधार (टीम, विभाग, इत्यादि) तक पहुंच को सौंपते हैं, न कि एक-बंद पहुंच को जिसे ट्रैक करना मुश्किल हो सकता है। जब उपयोगकर्ता किसी अन्य विभाग में स्थानांतरित होता है, तो आपको सभी पुराने एक्सेस को साफ करने की आवश्यकता होती है।

नकारात्मक पक्ष यह है कि समूहों का दुरुपयोग किया जा सकता है। समूहों के लिए क्या उपयोग किया जाता है, इस बारे में स्पष्ट रूप से बताएं, ताकि एक हिस्से को सौंपे गए संसाधन समूहों का पुन: उपयोग न किया जाए जैसे कि वे विभागीय समूह थे, जिससे पहुंच में गड़बड़ हो गई थी।


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

पुरानी पहुंच तक चाल और "सफाई" के लिए, फिर से, हमने प्रक्रिया को स्वचालित कर दिया है और संसाधन स्वामी पर समय-समय पर समीक्षा करने और उन लोगों के लिए पहुंच हटाने का अनुरोध करने के लिए जिम्मेदारी दी गई है जिनके पास अब पहुंच नहीं होनी चाहिए। हमारे वातावरण में "चालें" आम तौर पर संसाधनों तक पहुंच को हटाने में शामिल नहीं होती हैं, क्योंकि यह जानने के लिए संसाधन स्वामी की तुलना में बेहतर है कि इस व्यक्ति को अभी भी एक्सेस की आवश्यकता है या नहीं?
डेविड आर्चर

150k उपयोगकर्ताओं और उनकी भूमिकाओं को मैप करने की कोशिश एक संकेत है कि कंपनी ने उस आकार में बढ़ने से पहले अपना शोध नहीं किया था। जाहिर है, विस्तारक विकास से पहले इसकी रूपरेखा तैयार करना बहुत आसान है।
स्पूलसन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.