SharePoint सुरक्षा बुनियादी बातों के रंग का अस्तर / आम नुकसान से बचने

अद्यतन 12/18/07: पॉल Liebrand लेख को हटाने या डिफ़ॉल्ट समूह नामों को संशोधित करने के कुछ तकनीकी परिणाम के लिए देखें (अपनी टिप्पणी के नीचे देखने के रूप में अच्छी तरह से).

अवलोकन:

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

महत्वपूर्ण नोट:

इस वर्णन पर SharePoint सुरक्षा बॉक्स से बाहर आधारित है. हो सकता है इसलिए कुछ काई विशिष्ट चीज़ें यहाँ मेरे निजी अनुभव MOSS के चारों ओर उन्मुख है, लेकिन मेरा मानना है कि यह WSS के लिए सटीक है. मुझे आशा है कि किसी को भी किसी भी त्रुटि या चूक देखकर कि टिप्पणियों में बाहर बिंदु होगा कि या ईमेल मुझे. मैं जल्दबाजी के बाद सुधार कर दूँगा.

बुनियादी बातों:

इस अवलोकन के प्रयोजनों के लिए, सुरक्षा के लिए चार मूलभूत पहलू हैं: उपयोगकर्ता/समूहों, सुरक्षा योग्य ऑब्जेक्ट्स, अनुमति स्तर और वंशानुक्रम.

उपयोगकर्ता और समूह तोड़ने के लिए नीचे:

  • अलग-अलग उपयोगकर्ता: से सक्रिय निर्देशिका या सीधे SharePoint में बनाए गए खींच लिया.
  • कई समूह: सक्रिय निर्देशिका से सीधे मैप्ड या में बनाए गए SharePoint. उपयोगकर्ता का संग्रह समूहों रहे हैं. किसी साइट संग्रह में वैश्विक समूहों रहे हैं. वे कभी नहीं "से बंधा रहे हैं" किसी विशिष्ट सुरक्षा योग्य ऑब्जेक्ट के लिए.

सुरक्षा योग्य ऑब्जेक्ट्स कम से कम करने के लिए नीचे तोड़ना:

  • साइटें
  • दस्तावेज़ लायब्रेरीज़
  • सूचियों और दस्तावेज़ पुस्तकालयों में अलग-अलग आइटम
  • फ़ोल्डर्स
  • विभिन्न BDC सेटिंग्स.

वहाँ अन्य सुरक्षा योग्य ऑब्जेक्ट्स, लेकिन तुम तस्वीर सामने आती है.

अनुमति स्तर: दानेदार का एक बंडल / कम स्तर तक पहुँच अधिकार है कि सूचियों में बनाएँ/पढ़ें/हटाएँ प्रविष्टियों के रूप में ऐसी बातें शामिल करें.

वंशानुक्रम: डिफ़ॉल्ट संस्थाओं द्वारा सुरक्षा सेटिंग्स उनके युक्त ऑब्जेक्ट से अनुवांशिक रूप से प्राप्त. उप साइटों की अनुमति उनके पैरेंट से इनहेरीट. दस्तावेज़ लाइब्रेरी उनकी साइट से इनहेरीट. पर और आगे इतना.

अनुमति स्तर और विरासत के जरिए सुरक्षा योग्य ऑब्जेक्ट्स को उपयोगकर्ता और समूह से संबंधित हैं.

सबसे महत्वपूर्ण सुरक्षा नियमों को समझने के लिए, कभी 🙂 :

  1. बस संग्रह उपयोगकर्ताओं के समूहों के हैं.
  2. किसी साइट संग्रह के भीतर वैश्विक समूहों रहे हैं (अर्थात. वहाँ एक साइट स्तर पर निर्धारित एक समूह के रूप में ऐसी कोई बात नहीं है).
  3. समूह का नाम नहीं बर्दाश्त कर, कई समूह नहीं करते, में और स्वयं का, सुरक्षा के किसी विशेष स्तर है.
  4. समूहों के पास किसी विशेष सुरक्षा योग्य ऑब्जेक्ट के संदर्भ में सुरक्षा.
  5. आप हर सुरक्षा योग्य ऑब्जेक्ट के लिए एक ही समूह के लिए भिन्न अनुमति स्तर असाइन कर सकते हैं.
  6. यह सब वेब अनुप्रयोग नीतियाँ तुरुप का (नीचे देखें).

सुरक्षा व्यवस्थापक समूह और उपयोगकर्ता लिस्टिंग के एक समुद्र में खो दिया हमेशा इन axioms का प्रबंधन और उनके सुरक्षा कॉन्फ़िगरेशन को समझने के लिए पर भरोसा कर सकते हैं.

आम नुकसान:

  • समूह नामों की अनुमति झूठा समझा जाए: बॉक्स से बाहर, SharePoint सुरक्षा का एक अंतर्निहित स्तर जिनके नाम मतलब समूहों का एक सेट को परिभाषित करता है. समूह "योगदानकर्ता" पर विचार. एक SharePoint सुरक्षा के साथ अपरिचित अच्छी तरह से उस नाम को देखो और लगता है उस समूह का कोई सदस्य "में योगदान कर सकते हैं कि हो सकता" किसी भी साइट/सूची/पुस्तकालय करने के लिए पोर्टल. कि सच हो सकते हैं, लेकिन क्योंकि समूह का नाम "योगदानकर्ता" किया जा करने के लिए नहीं होता. यह केवल बॉक्स से बाहर सही है क्योंकि समूह उन्हें रूट साइट पर सामग्री जोड़ें/संपादित करें/हटाने के लिए सक्षम बनाता है एक अनुमति स्तर प्रदान की गई है. विरासत के माध्यम से, "योगदानकर्ताओं" समूह जोड़ें/संपादित करें/हटाने सामग्री हर उप-साइट पर भी हो सकती. एक तोड़ कर सकते हैं"" वंशानुक्रम चेन और परिवर्तन एक उप साइट इस तरह का अनुमति स्तर कि जनताको तथाकथित "योगदानकर्ता" समूह में सभी में योगदान नहीं कर सकते, लेकिन केवल पढ़ने के लिए (उदाहरण के लिए). यह एक अच्छा विचार नहीं होगा, जाहिर है, चूंकि यह बहुत ही भ्रामक होगा.
  • कई समूह एक साइट स्तर पर निर्धारित नहीं कर रहे हैं. यह उपयोगकर्ता इंटरफ़ेस द्वारा भ्रमित किया जा करने के लिए आसान है. हर साइट "लोगों और समूहों के माध्यम से उपयोगकर्ता/समूह प्रबंधन के लिए एक सुविधाजनक लिंक Microsoft प्रदान करता है" लिंक. यह मानना है कि जब मैं साइट "xyzzy रहा हूँ करने के लिए आसान है" और मैं xyzzy के लोगों के माध्यम से एक समूह बनाएँ और कि मैं सिर्फ xyzzy पर ही मौजूद है एक समूह बना लिया समूहों के लिंक. कि मामला नहीं है. मैं वास्तव में पूरे साइट संग्रह के लिए एक समूह बनाया है.
  • समूह सदस्यता द्वारा साइट भिन्नता नहीं है (अर्थात. यह एक ही समूह में उपयोग किया जाता है हर जगह है): "स्वामी समूह पर विचार" और दो साइटों, "मानव संसाधन" और "रसद". यह सामान्य करने के लिए लगता है कि दो अलग-अलग व्यक्तियों उन साइटों ही होता होगा — एक मानव संसाधन के मालिक और एक मालिक के रसद. उपयोगकर्ता इंटरफ़ेस बनाता है यह आसान के लिए इस परिदृश्य को बुरा व्यवहार करना एक सुरक्षा व्यवस्थापक. अगर मैं बेहतर नहीं पता था, मैं मानव संसाधन साइट के माध्यम से लोगों और समूहों के लिंक का उपयोग हो सकता है, "मालिकों का चयन करें" समूहीकृत और मेरी HR स्वामी उस समूह में जोड़ें. एक महीने बाद में, रसद लाइन पर आता है. मैं रसद साइट से लोगों और समूहों का उपयोग, "मालिकों ऊपर खींचो जोड़ें" समूह. मैं वहाँ मानव संसाधन के मालिक को देखने और उसे निकालें, मैं उसे रसद साइट मालिकों से निकाल रहा हूँ कि सोच. वास्तव में, मैं उसे वैश्विक मालिकों के समूह से निकाल रहा हूँ. आनंद ensues.
  • विशिष्ट भूमिका पर आधारित नाम समूहों के लिए असफल: "अनुमोदक" समूह एक आदर्श उदाहरण है. क्या सदस्य इस समूह अनुमोदन के कर सकते हैं? जहां वे इसे अनुमोदन कर सकते हैं? मैं वास्तव में लोगों को रसद विभाग मानव संसाधन दस्तावेज़ों को अनुमोदित करने के लिए सक्षम होना करने के लिए चाहते हैं? बिल्कुल नहीं. हमेशा नाम संगठन के भीतर उनकी भूमिका पर आधारित समूहों. यह समूह किसी विशेष सुरक्षा योग्य ऑब्जेक्ट के लिए एक अनुचित अनुमति स्तर असाइन किया गया है के जोखिम को कम करेगा. अपने अभीष्ट भूमिका पर आधारित नाम समूहों. पिछला घंटा/रसद परिदृश्य में, मैं दो नए समूह बनाया है चाहिए: "HR मालिकों" और रसद मालिकों"" और समझदार की अनुमति स्तरों में से प्रत्येक के लिए और उनके काम करने के लिए उन उपयोगकर्ताओं के लिए आवश्यक न्यूनतम राशि आवंटित.

अन्य उपयोगी संदर्भ:

यदि आप यह इस बना दिया है अब तक:

कृपया टिप्पणी के माध्यम से अपने विचारों को पता है या मुझे ईमेल मुझे. यदि आप अन्य अच्छा संदर्भ पता, कृपया ऐसा ही!

Technorati टैग:

8 पर विचार "SharePoint सुरक्षा बुनियादी बातों के रंग का अस्तर / आम नुकसान से बचने

  1. पेरी

    अधिक बाधाएं:

    * वहाँ एसएसपी में कहीं उपलब्ध है और लोगों और समूहों के अनुभाग में दिखाई नहीं कुछ विशेष अनुमतियाँ हैं: "वैयक्तिकरण सेवा अनुमतियाँ" और "व्यवसाय डेटा कैटलॉग अनुमतियाँ"

    * मैंने पढ़ा है कि वहाँ भी विशेष SharePoint डिज़ाइनर अनुमतियाँ उपलब्ध हैं कुछ रहस्यमय html के अंदर कहीं न कहीं दफन xml में.

    * प्राथमिक और द्वितीयक व्यवस्थापक किसी साइट संग्रह के लिए कहीं और साइट संग्रह सेटिंग में रखा हैं, लोग और समूह अनुभाग नहीं दिखाई दे रहे हैं और.

    * कुछ खातों में जादुई है (विशेष) क्या आप लोग और समूह क्षेत्र में देखने की परवाह किए बिना योग्यता: वेब सर्वरों पर अंतर्निहित व्यवस्थापक समूह का सदस्य, और खेत सेवा खाता.

    (पुनश्च: स्पैम टिप्पणियों को हटाने यहाँ की पठनीयता में सुधार होगा।)

  2. पॉल Liebrand
    डंपिंग समूहों के एक अच्छा विचार हो सकता है नहीं. वहाँ नई सदस्यता सामग्री के आसपास विशेष रूप से किया जा करने के लिए उन समूहों कुछ काई की कार्यक्षमता पर निर्भर करता. http://liebrand.wordpress.com/2007/12/06/sharepoint-security-permission-levels/ यह और अधिक विस्तार में चर्चा.
    @Paul — महान पोस्ट!
    पॉल Liebrand
  3. जीन राइट
    यह एक बहुत ही अच्छा पोस्ट है. मैं कुछ अवसरों पर इस जाल में गिर गया है. सुरक्षा प्रबंधन जटिल प्राप्त कर सकते हैं जब आप प्रमाणन विधियों और विभिन्न सुरक्षा समूहीकरण विधियाँ मिश्रण शुरू. यह योजना प्रक्रिया के भाग के रूप में माना जा करने के लिए की जरूरत है और अनदेखी नहीं की जानी चाहिए.
  4. मार्क मिलर ने लिखा:
    (पॉल से ध्यान दें: मार्क ने अपनी टिप्पणी के लिए एक छोटा सा परिवर्तन करने के लिए मुझसे पूछा लेकिन मैं रहते रिक्त स्थान टिप्पणियाँ संपादित नहीं कर सकते, तो मैं इसे नए सिरे से यहाँ परिवर्तन के साथ जोड़ा गया है और मूल को हटाया).
    पॉल,
    इस जानकारी पेश करने के लिए सारांश दृष्टिकोण बहुत अच्छी तरह से आया था. मैं विशेष रूप से पसंद है "नुकसान" अनुभाग, के बाद से मैं अपने आप को उन में से कुछ में गिर गया है.
    एक और बात आप ने कहा कि घर हिट: सोमवार को सीखना जरूरी नहीं कि इसका मतलब यह नहीं आप इसे शुक्रवार को याद करेंगे. मुझे खुशी है कि मेरे अलावा कोई एक "गुदगुदाने वाला के रूप में अपने ब्लॉग का उपयोग कर रहा हूँ" उन महत्वपूर्ण चीजें हैं जो एक नियमित आधार पर किया नहीं कर रहे हैं के लिए सिस्टम.
    अच्छा काम.
    सादर अभिवादन,
    मार्क
    EndUserSharePoint.com

    नवम्बर 27 9:04 पर हूँ
    (http://www.EndUserSharePoint.com)

  5. पॉल Galvin
    मुझे लगता है कि यह शायद उन डिफ़ॉल्ट समूहों को निकालने के लिए एक अच्छा विचार है, खासकर योगदानकर्ता और मालिक. वे overbroad हैं और आसानी से उलझन में. "सभी प्रमाणीकृत उपयोगकर्ताओं का उपयोग करना पसंद करते हैं" एक "आगंतुक के स्थान पर" समूह में रूचि. का एक विशिष्ट सेट करते हैं तो मैं एक उचित प्रकार से वर्णनात्मक नाम के साथ एक विज्ञापन समूह या SharePoint समूह बनाने की सिफारिश करेंगे उपयोगकर्ताओं को केवल केवल पढ़ने-योग्य पहुँच जाना चाहिए, जैसे. "रसद आगंतुकों".
    –पॉल जी
  6. कोई नाम नहीं
    यह लगता है जैसे बस आगंतुक डंप पहली बात तुम करना चाहिए है, योगदानकर्ता और मालिक समूहों और उन्हें अपने तार्किक समूहों के साथ बदलें. यह भावना करने के लिए करना होगा?

कोई जवाब दो

आपका ईमेल पता प्रकाशित नहीं किया जाएगा. अपेक्षित स्थानों को रेखांकित कर दिया गया है *