अनुशंसित पहुँच सेटअप
कस्टम भूमिकाएँ, Auth Groups, और folder permissions को मिलाएँ ताकि एक भूमिका बताए कि कोई व्यक्ति क्या कर सकता है और एक group बताए कि कहाँ।
यह पृष्ठ कई साइटों, व्यावसायिक इकाइयों या टीमों वाले वर्कस्पेस के लिए अनुशंसित अभिगम मॉडल का वर्णन करता है। इसमें तीन विशेषताएँ शामिल हैं, जिनका दस्तावेज़ अलग-अलग है: भूमिका-आधारित अभिगम नियंत्रण, प्रोजेक्ट फ़ोल्डर अनुमतियाँ और Auth Groups. स्क्रीनशॉट इस तरह सेट किए गए उदाहरण वर्कस्पेस से लिए गए हैं।
भूमिकाएँ बताती हैं क्या, समूह बतातें हैं कहाँ
भूमिका नाम में स्थान जोड़ना (जैसे: Engineer-PlantA, Engineer-PlantB) भूमिकाओं की संख्या बढ़ा देता है, और प्रतियाँ समय के साथ अलग-अलग दिशा में चली जाती हैं। प्रश्न को दो भागों में बाँटें।
एक भूमिका निर्धारित करती है कि कोई व्यक्ति क्या कर सकता है: एनोटेट करना, ट्रेन करना, डिप्लॉय करना, API कुंजियाँ प्रबंधित करना, फ़ोल्डर प्रबंधित करना। भूमिकाएँ पूरे वर्कस्पेस पर लागू होती हैं।
एक Auth Group निर्धारित करता है कि वे यह कहाँ कर सकते हैं। समूहों को फ़ोल्डरों पर केवल-पढ़ने की या पढ़ने एवं लिखने की अनुमति दी जाती है। सदस्यता मैन्युअल होती है या SSO समूहों से मैप की जाती है।
Plant A में एक production engineer की भूमिका: Eng-Prod तथा समूह: Plant A होता है। Plant B का एक आगंतुक जो Plant A के मॉडल्स की समीक्षा करता है, अपनी स्वयं की भूमिका बनाए रखता है और समूह अनुदान के माध्यम से Plant A फ़ोल्डर पर केवल-पढ़ने की अनुमति पाता है। किसी स्थान के लिए कोई भूमिका नहीं बनाई जाती।

अनुशंसित भूमिका-सीढ़ी
पाँच भूमिकाएँ, सबसे कम से सबसे अधिक पहुँच तक।
नया उपयोगकर्ता (डिफ़ॉल्ट)
हर नया लॉगिन
असाइन किए जाने तक कुछ नहीं।
केवल-पढ़ने की अनुमति
ऑपरेटर, ऑडिटर, आगंतुक
परियोजनाएँ, मॉडल, Vision Events और डिवाइस मॉनिटरिंग देखें। ऐप में इन्फ़ेरेंस चलाएँ। कोई एनोटेशन, ट्रेनिंग या डिप्लॉय नहीं।
Eng-Dev
विकास इंजीनियर
डेटासेट बनाएँ, एनोटेट करें, अपलोड करें, ट्रेन करें, संस्करण बनाएँ, जॉब चलाएँ। कोई डिप्लॉय नहीं, कोई कुंजी प्रबंधन नहीं, कोई फ़ोल्डर निर्माण नहीं।
Eng-Prod
उत्पादन इंजीनियर
Eng-Dev के साथ डिप्लॉय करना, मॉडल और वर्कफ़्लो प्रबंधित करना, डिवाइस प्रबंधित करना, Vision Events बनाना, बैच जॉब चलाना। जिन फ़ोल्डरों तक उनकी पहुँच है, उनमें API कुंजियों का पूरा जीवनचक्र (बनाना, अपडेट करना, रद्द करना)।
साइट प्रशासक
प्रति साइट एक या दो लोग
वर्कस्पेस प्रशासन और सदस्य प्रबंधन को छोड़कर सब कुछ। फ़ोल्डर बनाता है, समूहों को फ़ोल्डर पहुँच देता है, कुंजियाँ प्रबंधित करता है, आँकड़े और ऑडिट लॉग पढ़ता है।
प्रशासक (अंतर्निहित)
केंद्रीय IT, प्रोग्राम लीड
वर्कस्पेस-व्यापी API कुंजियों, बिलिंग, SSO और कस्टम भूमिकाओं सहित पूर्ण पहुँच।
इंजीनियर फ़ोल्डर नहीं बनाते। फ़ोल्डर ट्री (जैसे: Business Unit > Site > Environment) गवर्नेंस संरचना है, इसलिए फ़ोल्डर निर्माण Site Admin और Admin के पास रहता है। केवल Admin को workspace-व्यापी API कुंजियाँ दिखाई देती हैं। Site Admin और Eng-Prod फ़ोल्डर कुंजियों के साथ काम करते हैं, जिससे सबसे संवेदनशील क्रेडेंशियल सबसे कम लोगों के पास रहते हैं।


एक भूमिका क्या कर सकती है और कहाँ देख सकती है
किसी व्यक्ति की प्रभावी पहुँच भूमिका और फ़ोल्डर अनुदान के प्रतिच्छेद से तय होती है। भूमिका स्तंभ तय करती है, अनुदान पंक्ति तय करता है।
कोई अनुदान नहीं
फ़ोल्डर छिपा हुआ
फ़ोल्डर छिपा हुआ
फ़ोल्डर छिपा हुआ
फ़ोल्डर छिपा हुआ
पूर्ण पहुँच (सभी फ़ोल्डर पहुँच)
केवल-पढ़ने की अनुमति
परियोजनाएँ और मॉडल देखें, इन्फ़ेरेंस चलाएँ
Read Only के समान
देखें, साथ ही फ़ोल्डर की API कुंजियाँ प्रबंधित करें (नोट देखें)
देखें, साथ ही फ़ोल्डर की API कुंजियाँ प्रबंधित करें (नोट देखें)
पूर्ण पहुँच
पढ़ें एवं लिखें
देखें, इन्फ़ेरेंस चलाएँ
एनोटेट करें, अपलोड करें, ट्रेन करें, संस्करण बनाएँ
Eng-Dev के साथ डिप्लॉय, वर्कफ़्लो, डिवाइस, Vision Events, API कुंजियाँ
Eng-Prod के साथ उप-फ़ोल्डर बनाएँ और फ़ोल्डर को समूहों के साथ साझा करें
पूर्ण पहुँच
कुंजी से जुड़ी कार्रवाइयाँ भूमिका का अनुसरण करती हैं, जहाँ भी फ़ोल्डर पहुँच योग्य हो। आगंतुकों को केवल आवश्यकता होने पर और किसी समूह के माध्यम से ही Read-Only दें, ताकि इसे एक ही स्थान से हटाया जा सके।
हर व्यक्ति ग्रिड की एक ही सेल में होता है। पंक्तियाँ भूमिकाएँ हैं, कॉलम स्थान हैं।
भूमिका
Plant A फ़ोल्डर
Plant B फ़ोल्डर
सभी फ़ोल्डर
केवल-पढ़ने की अनुमति
लाइन ऑपरेटर
आने वाला ऑडिटर
Eng-Dev
विकास इंजीनियर
Eng-Prod
उत्पादन इंजीनियर
(Read-Only विज़िट)
साइट प्रशासक
Plant A लीड
Plant B लीड
प्रशासक
केंद्रीय IT
स्थानांतरण व्यक्ति का समूह बदलता है। पदोन्नति उनकी भूमिका बदलती है।
इसे सेट करना
भूमिकाएँ बनाएँ
Settings, "Team Members", "Roles" पर जाएँ और "New Role" पर क्लिक करें। ऊपर दी गई सीढ़ी से प्रत्येक भूमिका बनाएँ। सबसे निकटतम अंतर्निहित भूमिका से "Duplicate Permissions From" के साथ शुरू करें और समायोजित करें। एडिटर में अनुमति समूह (जैसे: "Workspace Management", "User & Team Management", "API keys") तालिका की श्रेणियों से मेल खाते हैं। देखें एक कस्टम भूमिका बनाना स्वयं एडिटर के लिए।
प्रत्येक साइट के लिए एक Auth Group बनाएँ
Settings, "Team Members", "Auth Groups" पर जाएँ और "Create Auth Group" पर क्लिक करें। समूहों के नाम स्थानों के आधार पर रखें (जैसे: Plant A, Plant B), कभी भी भूमिकाओं के आधार पर नहीं। यदि किसी साइट के Dev और Prod फ़ोल्डरों में अलग-अलग लोग हैं, तो प्रति साइट और प्रति वातावरण एक समूह बनाएँ। सदस्यों को हाथ से जोड़ें, या SSO समूह नाम मैप करें ताकि सदस्यता आपके पहचान प्रदाता का अनुसरण करे (देखें SSO के साथ इसे स्वचालित करना).

प्रत्येक साइट फ़ोल्डर को उसके समूह के साथ साझा करें
फ़ोल्डर कार्ड पर, मेनू खोलें और "Set Permissions" चुनें। साइट के समूह को Read & Write दें और किसी भी विज़िटिंग समूह को Read-Only दें। जैसे-जैसे समूह जिम्मेदारी लेते हैं, व्यक्तिगत अनुदान हटाते जाएँ। तब स्थानांतरण या प्रस्थान केवल एक समूह संपादन बन जाता है। देखें प्रोजेक्ट फ़ोल्डर अनुमतियाँ पहुँच स्तरों के लिए।

सदस्यों को भूमिकाएँ असाइन करें
Settings, "Team Members", "Members" पर जाएँ और प्रत्येक सदस्य की भूमिका सेट करें। भूमिका और समूह स्वतंत्र हैं, इसलिए किसी को दूसरी साइट पर जाने के लिए दूसरी भूमिका की आवश्यकता नहीं है। देखें किसी टीम सदस्य की भूमिका बदलें.
इस मॉडल में API कुंजियाँ
फ़ोल्डर कुंजियाँ साइट के कार्य के लिए होती हैं। वर्कस्पेस-व्यापी कुंजियाँ केवल Admin के लिए हैं। किसी फ़ोल्डर कुंजी को वह कोई भी देख सकता है जो उस फ़ोल्डर तक पहुँच सकता है। Site Admin और Eng-Prod फ़ोल्डर कार्ड मेनू से कुंजियाँ प्रबंधित करते हैं और Settings में उनका कोई "API Keys" पृष्ठ नहीं होता।
प्रत्येक फ़ोल्डर के लिए कई कुंजियाँ बनाएँ: प्रति उत्पादन लाइन, डिवाइस बेड़े या इंटीग्रेशन एक। उपयोग रिपोर्टिंग में हर कुंजी अपनी अलग पंक्ति होती है, इसलिए खर्च को फ़ोल्डर के भीतर आवंटित किया जा सकता है (देखें बिलिंग फ़ोल्डर), और दो सक्रिय कुंजियाँ रोटेशन के दौरान ओवरलैप की अनुमति देती हैं।
हर कुंजी निर्माण के 365 दिन बाद एक रोटेशन तिथि दिखाती है, और उसके बाद एक Overdue बैज दिखता है। एक नई कुंजी बनाकर, उपभोक्ताओं को उस पर स्थानांतरित करके, और पुरानी को रद्द करके रोटेट करें। जब कठोर कटओवर स्वीकार्य हो, तो "Roll" उसी स्थान पर रोटेट करता है। प्रबंधन API वही तिथि लौटाता है जैसे rotationDueAt.




SSO के साथ इसे स्वचालित करना
यदि आपका पहचान प्रदाता समूह क्लेम भेजता है, तो प्रत्येक भूमिका के लिए एक SSO समूह और प्रत्येक साइट Auth Group के लिए एक समूह मैप करें। देखें सिंगल साइन-ऑन पहचान प्रदाता पक्ष के लिए।
भूमिकाएँ: भूमिका संपादक में, "SSO Auth Groups (auto-assign)" खोलें और पहचान प्रदाता समूह का नाम जोड़ें। उस समूह वाले उपयोगकर्ताओं को अगला लॉगिन या वर्कस्पेस लोड पर वह भूमिका मिल जाती है।
Auth Groups: समूह पर "Edit" क्लिक करें और "SSO Group Mappings" के तहत पहचान प्रदाता समूह का नाम जोड़ें। मेल खाने वाले सदस्यों को साइन-इन पर असाइन किया जाता है और सदस्य सूची में SSO बैज दिखता है।
नया कर्मचारी डिफ़ॉल्ट भूमिका में रहता है जब तक IT उसे सही समूहों में नहीं जोड़ देता। उनकी अगली लॉगिन पर भूमिका और फ़ोल्डर पहुँच दिखाई देती है। मैपिंग को एक समय में एक भूमिका के लिए सक्षम करें। जो भी बिना मैप किया रह जाए, उसके लिए मैन्युअल असाइनमेंट काम करते रहते हैं।


अंतिम अपडेट
क्या यह उपयोगी था?