प्रत्यायोजित एक्सेस
किसी डेवलपर को जोड़ें, बिलिंग का काम अपने अकाउंटेंट को सौंपें, क्लाइंट को उनकी अपनी साइटों के लिए केवल-पढ़ने योग्य एक्सेस दें, या हमारी सहायता टीम को किसी समस्या की जांच करने दें। प्रत्येक एक्सेस निश्चित अनुमतियों वाली एक भूमिका है, जो किसी संगठन तक सीमित है, डेटाबेस में लागू है, और केवल-जोड़ने योग्य ऑडिट लॉग में दर्ज है।
एक ही लॉगिन साझा करने से खाते के एक्सेस में गड़बड़ी होती है। Zinn Digital® पर प्रत्येक व्यक्ति की अपनी पहचान होती है, और एक्सेस एक सदस्यता है — एक उपयोगकर्ता, एक संगठन, और एक भूमिका — जिसे आप अलग से प्रदान कर सकते हैं, बदल सकते हैं या रद्द कर सकते हैं।
प्रत्येक सहयोगी हमारे पहचान स्तर Keycloak के माध्यम से स्वयं के रूप में साइन इन करता है। कोई भी आपका पासवर्ड टाइप नहीं करता है, कोई भी ब्राउज़र सत्र साझा नहीं करता है, और किसी को हटाना पासवर्ड बदलने और यह पता लगाने की भागदौड़ के बजाय केवल एक ही कार्रवाई है कि इसे और कौन जानता था।
खाते पदानुक्रमित होते हैं — एक पुनर्विक्रेता संगठन में ग्राहक संगठन होते हैं, और ग्राहक संगठनों में साइटें होती हैं। सदस्यता किसी संगठन और उसके अंतर्गत आने वाली प्रत्येक वस्तु पर लागू होती है, जिससे आप अपने अन्य ग्राहकों को कभी भी उजागर किए बिना किसी एजेंसी ग्राहक को उनके अपने संगठन का नियंत्रण सौंप सकते हैं।
टेनेंट पृथक्करण एप्लिकेशन कोड में कोई ऐसा फ़िल्टर नहीं है जिसे कोई बग छोड़ सके। Postgres रो-लेवल सिक्योरिटी प्रत्येक क्वेरी को कॉलर के संगठन सब-ट्री तक सीमित रखती है, इसलिए आपके दायरे से बाहर के किसी भी अनुरोध के पास वापस करने के लिए कुछ नहीं होता है।
अपने दायरे से बाहर किसी संगठन या साइट के लिए अनुरोध करने पर API अनुमति त्रुटि के बजाय केवल 'नहीं मिला' (not-found) का उत्तर देता है। अनुमति त्रुटि इस बात की पुष्टि करेगी कि रिकॉर्ड मौजूद है; 'नहीं मिला' किसी बाहरी व्यक्ति को कुछ भी नहीं बताता है।
अनुमतियाँ सूक्ष्म कुंजियाँ हैं — मॉड्यूल और क्रिया, जैसे sites.restart या billing.refund — और भूमिकाएँ उन्हें बंडल करती हैं। चार भूमिकाएँ उन स्वरूपों को पूरा करती हैं जिनकी वास्तविक टीमों को आवश्यकता होती है, और इनमें से प्रत्येक वह डेटा है जिसे हम सीड करते हैं, न कि कोड में छिपा हुआ लॉजिक।
पूर्ण नियंत्रण: बाल संगठन बनाएं, सदस्यों को आमंत्रित करें और हटाएं, भूमिकाएं बदलें, API कुंजियों का प्रबंधन करें, साइटें बनाएं, पुनरारंभ करें, पर्ज करें, निलंबित करें और हटाएं, बिलिंग और इनवॉइस प्रबंधित करें, टिकट दर्ज करें और ऑडिट लॉग पढ़ें। वह भूमिका जो आप अपने लिए रखते हैं।
संगठन, उसके सदस्यों और प्लान कैटलॉग को देखता है, और इनवॉइस, भुगतान विधियों तथा शुल्कों का प्रबंधन करता है। किसी भी साइट को बनाने, बदलने या हटाने की कोई पहुँच नहीं — बिल्कुल वही स्वरूप जो एक बाहरी मुनीम के पास होना चाहिए।
साइट्स देखता है और बनाता है, सेवाओं को पुनरारंभ करता है, कैश को साफ़ करता है, API कुंजियों का प्रबंधन करता है और टिकटों पर काम करता है। जानबूझकर बाहर रखा गया: बिलिंग, इनवॉइस, भुगतान विधियां, सदस्य प्रबंधन, साइट निलंबन और साइट विलोपन। कोई ठेकेदार आपको बिल भेजे बिना या कुछ भी नष्ट किए बिना निर्माण कर सकता है।
संगठन, उसके सदस्यों, उसकी साइटों, उसकी बिलिंग, प्लान कैटलॉग, टिकटों, अनुवाद स्थिति और ऑडिट लॉग को देखता है — और इसमें से कुछ भी नहीं बदल सकता। उस क्लाइंट के लिए सही अनुमति जो दृश्यता चाहता है, किसी ऑडिटर के लिए, या किसी ऐसे हितधारक के लिए जिसे केवल देखने की आवश्यकता है।
एक्सेस सौंपना केवल तभी सुरक्षित होता है जब वे खाते जिन्हें आप एक्सेस सौंपते हैं, उन पर कब्ज़ा करना मुश्किल हो। खाते में मौजूद प्रत्येक व्यक्ति के लिए, प्रत्येक इंटरफ़ेस पर प्रमाणीकरण Keycloak के माध्यम से संचालित होता है।
सपोर्ट कार्य के लिए कभी-कभी आपके खाते के अंदर देखने की आवश्यकता होती है। वह एक्सेस उसी अनुमति मॉडल द्वारा नियंत्रित होती है जैसे कि अन्य सभी चीजें — कर्मचारी केवल एक कर्मचारी संगठन में शामिल होते हैं, जो सीमित अनुमतियों वाले विभागों में व्यवस्थित होते हैं।
कर्मचारियों को सहायता, बिलिंग और वित्त, दुरुपयोग और विश्वास-तथा-सुरक्षा, बिक्री, ऑनबोर्डिंग, इंजीनियरिंग और संचालन, विपणन और प्रबंधन में समूहीकृत किया गया है। प्रत्येक भूमिका विशिष्ट मॉड्यूल और कार्रवाइयां प्रदान करती है, ताकि एक एजेंट व्यवस्थापक कंसोल का केवल वही हिस्सा देख सके जिसकी उसके कार्य के लिए आवश्यकता है, बाकी नहीं।
सपोर्ट एजेंट भूमिका ठीक यही अनुमति देती है: ग्राहकों को देखना, टिकट देखना और उनका उत्तर देना, साइटें देखना, किसी साइट को पुनः आरंभ करना और उसके कैश को साफ़ करना। इसमें कोई बिलिंग कॉन्फ़िगरेशन, कोई रिफंड, कोई योजना संपादन और कोई बेड़ा प्रबंधन शामिल नहीं है। एजेंट द्वारा किया जा सकने वाला समाधान भूमिका द्वारा सीमित है, अच्छे इरादों से नहीं।
customer.impersonate अनुमति Manager भूमिका का हिस्सा नहीं है — यह केवल Super Admin के पास होती है। जब आपकी ओर से कोई सत्र चल रहा होता है, तो डैशबोर्ड पर एक स्थायी प्रतिरूपण (इम्पर्सननेशन) बैनर प्रदर्शित होता है ताकि यह कभी अस्पष्ट न रहे कि कौन कार्य कर रहा है।
प्रत्येक विशेषाधिकार प्राप्त और प्रशासनिक कार्रवाई केवल-जोड़ने योग्य (अपेंड-ओनली) ऑडिट लॉग में जुड़ जाती है, जो कर्ता, कार्रवाई, लक्ष्य, सहायक मेटाडेटा, आईपी पता और टाइमस्टैम्प को रिकॉर्ड करती है — जो प्रोडक्शन में समय-विभाजित होती है। स्वामी और केवल-पठन वाले सदस्य स्वयं अपने संगठन का लॉग पढ़ सकते हैं।
कर्मचारियों की संवेदनशील और विनाशकारी कार्रवाइयों को निष्पादित करने से पहले अतिरिक्त प्रमाणीकरण या दो व्यक्तियों की मंज़ूरी की आवश्यकता हो सकती है, और नए विभाग व भूमिकाएँ कोड परिवर्तन के बजाय केवल कॉन्फ़िगरेशन का मामला हैं।
स्क्रिप्ट्स, CI पाइपलाइनें, CLI, Terraform प्रदाता और AI एजेंट सभी लोगों की तरह ही समान अनुमति मॉडल के माध्यम से प्रमाणित होते हैं — कोई साझा किए गए मानवीय क्रेडेंशियल नहीं, किसी बिल्ड में चिपकाए गए कोई दीर्घकालिक रहस्य नहीं।
कुंजियाँ किसी संगठन से संबंधित होती हैं और समान RBAC अनुमतियों से जुड़े विस्तृत दायरे रखती हैं — केवल-पढ़ने के लिए, बिलिंग, प्रावधान। किसी सदस्य के पूरे खाते के बजाय पाइपलाइन को केवल उतनी ही सीमित सीमा प्रदान करें जितनी उसे आवश्यकता है।
टेस्ट-मोड और लाइव-मोड कुंजियाँ अलग-अलग होती हैं, इसलिए विकास के अधीन कोई एकीकरण गलती से या कॉपी किए गए एनवायरनमेंट वेरिएबल के माध्यम से प्रोडक्शन डेटा तक नहीं पहुँच सकता है।
हम सीक्रेट का SHA-256 हैश और एक लुकअप प्रीफिक्स स्टोर करते हैं — मूल की (raw key) को कभी नहीं। आप की (key) को केवल एक बार इसके निर्माण के समय देख सकते हैं। प्रत्येक की यह ट्रैक करती है कि उसका अंतिम बार कब उपयोग किया गया था और किसी अन्य चीज़ को प्रभावित किए बिना उसे स्वतंत्र रूप से निरस्त किया जा सकता है।
हमारा MCP सर्वर किसी भी MCP-सक्षम एजेंट को प्राकृतिक भाषा में आपकी होस्टिंग प्रबंधित करने की अनुमति देता है, जो OAuth 2.1 के साथ प्रमाणित है और आपके संगठन तथा RBAC भूमिका तक सीमित है, जिसमें प्रति-टूल निरसनीय टोकन, विनाशकारी कार्रवाइयों पर पुष्टि, खर्च सीमाएं और पूर्ण ऑडिट लॉगिंग शामिल हैं।
अकाउंट एक्सेस और सर्वर एक्सेस अलग-अलग समस्याएं हैं। साइट-स्तरीय क्रेडेंशियल्स को डैशबोर्ड में प्रबंधित किया जाता है, न्यूनतम विशेषाधिकार के साथ जारी किया जाता है, और अलग किया जाता है ताकि एक सहयोगी का शेल केवल एक साइट का शेल हो।
एकल संचालक एक संगठन और एक स्वामी सदस्यता बनाए रखता है, और किसी प्रोजेक्ट के लिए अनुबंधकर्ता के आने पर डेवलपर भूमिका जोड़ता है। प्रोजेक्ट समाप्त होने पर, सदस्यता हटा दी जाती है और उनका साइन-इन तुरंत काम करना बंद कर देता है — रोटेट करने के लिए कोई साझा क्रेडेंशियल पीछे नहीं बचता है।
एक एजेंसी संगठन ट्री (organisation tree) का उपयोग करती है। प्रत्येक क्लाइंट को उसका अपना चाइल्ड संगठन मिलता है, जिसमें उस क्लाइंट की साइटें होती हैं, और क्लाइंट के अपने लोगों को वहाँ सदस्यताएँ मिलती हैं — केवल देखने की इच्छा रखने वाले हितधारक के लिए रीड-ओनली (read-only), और स्वयं सेवा का विकल्प चुनने वाले क्लाइंट के लिए ओनर (owner)। आपके कर्मचारी ट्री में उच्च स्तर पर सदस्यता रखते हैं और पूरे पोर्टफोलियो को देखते हैं; एक क्लाइंट केवल अपनी शाखा को देखता है, और Row-Level Security ही इसे केवल एक वादे के बजाय वास्तविकता बनाती है।
एक पुनर्विक्रेता एक स्तर ऊपर उसी तरह काम करता है: पुनर्विक्रेता संगठन में क्लाइंट संगठन शामिल होते हैं, जिनमें से प्रत्येक के अपने सदस्य, बिलिंग दृश्य और साइटें होती हैं। वही मूल घटक उप-खातों, एजेंसी टीमों और पुनर्विक्रेता पदानुक्रमों को संचालित करता है — इनमें से किसी के लिए भी कोई अलग, कमजोर तंत्र नहीं है।
बिना कार्ड वाले 14-दिवसीय परीक्षण में सब कुछ उपलब्ध है। भुगतान विवरण के बिना साइन अप करें, किसी सहकर्मी को आमंत्रित करें, देखें कि प्रत्येक भूमिका किस तक पहुंच सकती है और किस तक नहीं, और अपना स्वयं का ऑडिट लॉग पढ़ें।
वर्तमान में, सदस्यता संगठन और ट्री में उसके अंतर्गत आने वाली प्रत्येक वस्तु पर अपनी भूमिका प्रदान करती है, इसलिए साइट सेट को अलग करने का तरीका संगठनों को अलग करना है — उन साइटों को उनके स्वयं के चाइल्ड संगठन में रखें और सदस्यता वहीं प्रदान करें। यह एजेंसियों और पुनर्विक्रेताओं के लिए एक स्पष्ट मॉडल है, जहाँ प्रत्येक ग्राहक पहले से ही अपनी सीमा चाहता है। सदस्यता-वार संसाधन क्षेत्र निर्धारण, यानी किसी एक संगठन के भीतर एकल सदस्यता को निर्दिष्ट साइटों तक सीमित करना, एक नियोजित सुधार है न कि वर्तमान में उपलब्ध कोई सुविधा।
Developer भूमिका में साइट को हटाना या साइट को निलंबित करना शामिल नहीं है — वे अधिकार Owner भूमिका के अंतर्गत आते हैं। यह साइटों को देखने और बनाने, सेवाओं को पुनरारंभ करने, कैश को साफ़ करने, API कुंजियों को प्रबंधित करने और टिकटों पर काम करने की अनुमति प्रदान करता है। परिनियोजन (Deployment) और push-to-live अनुमतियां भी Developer अनुमति का हिस्सा नहीं हैं, इसलिए उत्पादन (production) में ले जाने का अधिकार खाता स्वामी के पास ही रहता है। इसे स्टेजिंग के साथ जोड़ें ताकि निर्माण कार्य शुरू से ही लाइव साइट से बाहर हो सके।
यह पूरी तरह से कर्मचारी की भूमिका पर निर्भर करता है, और प्रत्येक भूमिका अनुमति कुंजियों का एक सीमित सेट होती है। उदाहरण के लिए, एक सपोर्ट एजेंट आपके खाते और साइटों को देख सकता है, आपके टिकटों को देख सकता है और उनका उत्तर दे सकता है, किसी साइट को पुनः प्रारंभ कर सकता है और उसके कैश को साफ़ कर सकता है — और वह बिलिंग कॉन्फ़िगरेशन, धनवापसी, योजनाओं या फ़्लीट में कोई बदलाव नहीं कर सकता है। ग्राहक के रूप में साइन इन करना एक अलग अनुमति है जो केवल Super Admin के पास होती है, और जब ऐसा होता है तो डैशबोर्ड पर एक निरंतर प्रतिरूपण बैनर दिखाई देता है। प्रत्येक विशेषाधिकार प्राप्त कार्रवाई ऑडिट लॉग में कर्ता, कार्रवाई, लक्ष्य, आईपी और टाइमस्टैम्प के साथ दर्ज की जाती है, और आप अपने संगठन के लॉग को स्वयं पढ़ सकते हैं।
सदस्यता हटाएं और उस संगठन तक उनकी पहुंच समाप्त हो जाएगी — उनकी अपनी पहचान अभी भी बनी रहेगी, लेकिन आपके खाते में उनकी कोई भूमिका नहीं होगी और इसलिए कोई अनुमति नहीं होगी। API कुंजियाँ व्यक्तिगत रूप से निरस्त की जाती हैं, इसलिए किसी अन्य चीज़ को बाधित किए बिना एक pipeline कुंजी को हटाया जा सकता है। यदि आप SAML एकल साइन-ऑन का उपयोग करते हैं, तो आपके पहचान प्रदाता में deprovisioning साइन-इन को केंद्रीय रूप से संभालता है। SSH कुंजियों जैसे साइट-स्तरीय क्रेडेंशियल्स को डैशबोर्ड में निरस्त कर दिया जाता है, और हटाने की प्रक्रिया स्वयं ऑडिट-लॉग की जाती है।
नहीं — लेकिन इसके कारण के बारे में सटीक होना महत्वपूर्ण है। API कुंजियाँ संगठन की होती हैं, किसी व्यक्तिगत सदस्य की नहीं, और इनमें उसी अनुमति कैटलॉग से जुड़े अपने स्वयं के सूक्ष्म दायरे (granular scopes) होते हैं। इसलिए किसी व्यक्ति को कुंजी सौंपने के बजाय, आप उस कार्य के लिए आवश्यक संकीर्ण दायरे के साथ एक कुंजी बनाते हैं, और कार्य समाप्त होने पर उस कुंजी को रद्द कर देते हैं। गुप्त कोड का केवल एक हैश संग्रहीत किया जाता है, और प्रत्येक कुंजी यह दर्ज करती है कि इसका अंतिम उपयोग कब किया गया था ताकि अप्रयुक्त कुंजियों को ढूंढना और उन्हें निष्क्रिय करना आसान हो।
हाँ। हमारा MCP सर्वर OAuth 2.1 के साथ एजेंटों को प्रमाणित करता है और उन्हें आपके संगठन और आपकी RBAC भूमिका तक सीमित करता है, जिसमें प्रति-टूल निरसन योग्य टोकन होते हैं, ताकि आप व्यापक पहुँच के बजाय एक विशिष्ट क्षमता प्रदान करें। विनाशकारी कार्रवाइयों के लिए पुष्टि की आवश्यकता होती है, खर्च की सीमाएँ लागू होती हैं, और प्रत्येक कार्रवाई मानव गतिविधि की तरह ही उसी ऑडिट लॉग में दर्ज होती है।
Postgres रो-लेवल सिक्योरिटी डेटाबेस के भीतर ही कॉलर के संगठन सब-ट्री तक प्रश्नों को सीमित करती है, जिसमें एप्लिकेशन-स्तरीय फ़िल्टर एकमात्र रक्षा पंक्ति होने के बजाय गहराई से सुरक्षा प्रदान करता है। दायरे से बाहर के रिकॉर्ड के लिए अनुरोध अनुमति त्रुटि के बजाय 'नॉट-फाउंड' लौटाते हैं, जिससे यह पता नहीं चलता कि क्या मौजूद है। सर्वर साइड पर, CageFS के माध्यम से प्रति-साइट पृथक्करण प्रत्येक किरायेदार के शेल और फ़ाइलों को उनकी अपनी साइट तक ही सीमित रखता है।
हाँ। 14-दिन का ट्रायल कार्ड-मुक्त है — कोई भुगतान विवरण नहीं, कोई प्रतिबद्धता नहीं — और इसमें अधिकतम पाँच साइटों के लिए Footprint-Free होस्टिंग शामिल है। प्रतिबद्ध होने से पहले किसी सहकर्मी को आमंत्रित करने, कोई भूमिका सौंपने और यह पुष्टि करने के लिए कि सीमाएँ आपकी आवश्यकतानुसार काम करती हैं, यह पर्याप्त है।
बिना क्रेडिट कार्ड वाले 14-दिवसीय परीक्षण के साथ शुरुआत करें, किसी को आमंत्रित करें, और अनुमति मॉडल को अपना काम करते हुए देखें — ऐसी भूमिकाएँ जिन्हें आप नाम दे सकते हैं, ऐसे दायरे जिन्हें आप निरस्त कर सकते हैं, और एक ऑडिट लॉग जो सटीक रूप से बताता है कि किसने क्या किया।
मुफ़्त शुरू करें