नियुक्त प्रवेश
डेव्हलपरला जोडा, बिलिंगची जबाबदारी तुमच्या अकाउंटंटकडे सोपवा, क्लायंटला त्यांच्या स्वत:च्या साइट्स पाहण्यासाठी 'रीड-ओन्ली' ॲक्सेस द्या, किंवा आमच्या सपोर्ट टीमला समस्येचे निवारण करू द्या. प्रत्येक परवानगी ही व्याख्या केलेल्या अधिकारांसह एका रोलच्या रूपात असते, जी एका संस्थेपुरती मर्यादित असते, डेटाबेसमध्ये लागू केली जाते आणि केवळ जोडल्या जाणाऱ्या (ॲपेंड-ओन्ली) ऑडिट लॉगमध्ये नोंदवली जाते.
एकाच लॉगिनची देवाणघेवाण केल्यामुळे खात्याच्या प्रवेशात अडचणी येतात. Zinn Digital® वर प्रत्येक व्यक्तीची स्वतःची ओळख असते आणि प्रवेश हे एक सदस्यत्व असते — एक वापरकर्ता, एक संस्था आणि एक भूमिका — जे तुम्ही स्वतःहून प्रदान करू शकता, बदलू शकता किंवा रद्द करू शकता.
प्रत्येक सहकारी आमची ओळख यंत्रणा असलेल्या Keycloak द्वारे स्वतःची स्वाक्षरी करून लॉग इन करतो. कोणीही तुमचा पासवर्ड टाइप करत नाही, कोणीही ब्राउझर सत्र सामायिक करत नाही, आणि एखाद्याला काढून टाकणे ही पासवर्ड बदलणे आणि इतर कोणाला तो माहीत होता हे शोधून काढण्याच्या धडपडीपेक्षा एका कृतीद्वारे होते.
खाती श्रेणीबद्ध असतात — एक पुनर्विक्रेता संस्था ग्राहक संस्थांवर नियंत्रण ठेवते आणि ग्राहक संस्था साइट्सवर नियंत्रण ठेवतात. सदस्यत्व हे एका संस्थेला आणि त्याच्या अंतर्गत असलेल्या प्रत्येक गोष्टीला लागू होते, त्यामुळे तुम्ही तुमच्या इतर ग्राहकांना कधीही उघड न करता एजन्सी क्लायंटला त्यांच्या स्वतःच्या संस्थेचे नियंत्रण देऊ शकता.
भाडेकरू अलग्गिकरण (टेनंट सेपरेशन) हा ॲप्लिकेशन कोडमधील एखादा असा फिल्टर नाही की जो एखादा बक चुकवू शकेल. पोस्टग्रेज रो-लेव्हल सेक्युरीटी प्रत्येक क्वेरी कॉलरच्या ऑर्गनायझेशन सबट्रीपुरती मर्यादित ठेवते, त्यामुळे तुमच्या स्कोपच्या बाहेरील विनंतीसाठी परत देण्यासारखे काहीच नसते.
तुमच्या कक्षेच्या बाहेरील एखाद्या संस्थेची किंवा साइटची विचारणा केल्यास, परवानगीच्या त्रुटीऐवजी API एक साधे नॉट-फाउंड उत्तर देते. परवानगीची त्रुटी रेकॉर्ड अस्तित्वात असल्याची पुष्टी करेल; नॉट-फाउंड बाहेरील व्यक्तीला काहीही सांगत नाही.
परवानग्या या दाणेदार किल्ल्या आहेत — मॉड्यूल अधिक कृती, जसे की sites.restart किंवा billing.refund — आणि भूमिका (roles) त्या एकत्र करतात. वास्तविक संघांना ज्या आकारांची गरज असते ते चार भूमिकांद्वारे पूर्ण होतात, आणि त्यातील प्रत्येक घटक हा कोडमध्ये दडलेला नसून, आपण पूर्वप्रस्थापित (seed) केलेला डेटा आहे.
पूर्ण नियंत्रण: सब-ऑर्गनायझेशन तयार करा, सदस्यांना आमंत्रित करा आणि काढा, भूमिका बदल करा, API की व्यवस्थापित करा, साइट्स तयार करा, रीस्टार्ट करा, पर्ज करा, सस्पेंड करा आणि हटवा, बिलिंग आणि इनव्हॉइस चालवा, तिकीट वाढवा आणि ऑडिट लॉग वाचा. तुमच्या स्वतःसाठी ठेवलेली भूमिका.
संस्थेचे सदस्य आणि प्लॅन कॅटलॉग पाहते, तसेच बीजक, पेमेंट पद्धती आणि शुल्कांचे व्यवस्थापन करते. कोणतीही एक साईट तयार करण्याचा, बदलण्याचा किंवा हटवण्याचा अधिकार नाही — बाह्य बुककिपरसाठी जसे आवश्यक असते, अगदी तसाच हा अधिकार आहे.
वेबसाइट्स पाहतो आणि तयार करतो, सेवा रीस्टार्ट करतो, कॅशे साफ करतो, API की व्यवस्थापित करतो आणि तिकीट्सवर काम करतो. जाणीवपूर्वक वगळलेले: बिलिंग, बीजक, पेमेंट पद्धती, सदस्य व्यवस्थापन, साइट निलंबन आणि साइट हटवणे. कंत्राटदार तुम्हाला बिलिंग न करता किंवा काहीही नष्ट न करता काम करू शकतो.
संस्थेचे तपशील, तिचे सदस्य, तिची साइट्स, तिचे बिलिंग, प्लॅन कॅटलॉग, तिकीटं, भाषांतर स्थिती आणि ऑudit लॉग पाहू शकतो — पण यातील कशातही बदल करू शकत नाही. ज्या क्लायंटला सर्वकाही पहायचे आहे, ऑडीटरसाठी, किंवा केवळ पाहण्याची गरज असलेल्या भागधारकासाठी योग्य परवाना.
प्रवेशाधिकार देणे तेव्हाच सुरक्षित असते जेव्हा तुम्ही ज्या खात्यांना अधिकार देत आहात ती खाती बळकावणे कठीण असते. खात्यावरील प्रत्येक व्यक्तीसाठी आणि प्रत्येक प्लॅटफॉर्मवर, प्रमाणीकरण (ऑथेंटिकेशन) Keycloak द्वारे चालते.
सपोर्टचे काम कधीकधी तुमच्या खात्याच्या आत पाहणे आवश्यक करते. त्या प्रवेशाचे नियमन इतर सर्व गोष्टींप्रमाणेच समान परवानगी मॉडेलद्वारे केले जाते — कर्मचारी फक्त एका कर्मचारी संस्थेमध्ये बसतात, ज्यांना मर्यादित अधिकारांसह विभागांमध्ये आयोजित केले जाते.
कर्मचाऱ्यांचे वर्गीकरण सपोर्ट, बिलिंग आणि फायनान्स, अब्युस आणि ट्रस्ट-अँड-सेफ्टी, सेल्स, ऑनबोर्डिंग, इंजिनिअरिंग आणि ऑप्स, मार्केटिंग आणि मॅनेजमेंट यामध्ये केले आहे. प्रत्येक भूमिकेमुळे विशिष्ट मॉड्यूल्स आणि कृती मिळतात, ज्यामुळे एजंटला ॲडमिन कन्सोलचा केवळ त्याच्या कामासाठी आवश्यक असलेला भाग दिसतो आणि उर्वरित भाग दिसत नाही.
सपोर्ट एजंट भूमिका नेमकी हीच परवानगी देते: ग्राहक पाहाणे, तिकीट पाहाणे आणि त्यांना उत्तर देणे, साइट्स पाहाणे, साइट रीस्टार्ट करणे आणि कॅशे साफ करणे. यामध्ये कोणतेही बिलिंग कॉन्फिगरेशन, रिफंड, प्लॅन एडिट करणे किंवा फ्लीट मॅनेजमेंट समाविष्ट नाही. एजंट जे उपाय करू शकतो ते चांगल्या हेतूंनी नव्हे तर या भूमिकेद्वारे मर्यादित असतात.
customer.impersonate परवानगी व्यवस्थापक (Manager) भूमिकेचा भाग नाही — ती केवळ सुपर Admin कडे असते. जेव्हा तुमच्या वतीने एखादं सत्र सुरू असतं, तेव्हा डॅशबोर्डवर सतत दिसणारी इम्परसोनेशन बॅनर् (impersonation banner) असते, ज्यामुळे नेमकी कोणती व्यक्ती कृती करत आहे हे कधीही संभ्रमित करत नाही.
प्रत्येक अधिकारप्राप्त आणि प्रशासकीय कृती केवळ-जोडता येणाऱ्या (append-only) ऑडिट लॉगमध्ये जोडली जाते, ज्यामध्ये कृती करणारी व्यक्ती, कृती, लक्ष्य, संबंधित मेटाडाटा, आयपी पत्ता आणि टाइमस्टॅम्प नोंदवला जातो — प्रॉडक्शनमध्ये वेळेनुसार विभागलेला (time-partitioned). मालक आणि फक्त वाचू शकणारे (read-only) सदस्य त्यांच्या संस्थेचा लॉग स्वतः वाचू शकतात.
संवेदनशील आणि विध्वंसक कर्मचारी कृतींसाठी त्या अमलात आणण्यापूर्वी वर्धित प्रमाणीकरण किंवा दोन व्यक्तींच्या मंजुरीची आवश्यकता असू शकते आणि नवीन विभाग व भूमिका या कोडमधील बदलाऐवजी कॉन्फिगरेशन असतात.
स्कript्स, CI पाइपलाइन्स, CLI, Terraform प्रदाता आणि AI एजंट हे सर्व मानकांप्रमाणेच समान परवानगी मॉडेलद्वारे प्रमाणीकरण करतात — कोणतेही सामायिक मानवी क्रेडेन्शियल्स नाहीत, बिल्डमध्ये पेस्ट केलेले कोणतेही दीर्घकाळ टिकणारे सिक्रेट्स नाहीत.
की (Keys) एका संस्थेच्या मालकीच्या असतात आणि त्याच RBAC परवानग्यांशी जोडलेले सविस्तर व्याप्ती (scopes) घेऊन येतात - फक्त-वाचन (read-only), बिलिंग (billing), आणि प्रोव्हिजनिंग (provisioning). सदस्याच्या संपूर्ण खात्याऐवजी पायपलाईनला तिला आवश्यक असलेली नेमकी व्याप्ती द्या.
टेस्ट-मोड आणि लाइव्ह-मोडच्या की वेगवेगळ्या असतात, त्यामुळे डेव्हलपमेंटमधील इंटिग्रेशन चुकीने किंवा कॉपी केलेल्या एन्व्हायर्नमेंट व्हेरिएबलमुळे प्रॉडक्शन डेटापर्यंत पोहोचू शकत नाही.
आम्ही सिक्रेटचा SHA-256 हॅश आणि लुकअप प्रिफिक्स स्टोअर करतो — कधीही रॉ की नाही. तुम्हाला निर्मितीच्या वेळी की एकदाच दिसते. प्रत्येक की ती शेवटी कधी वापरली गेली होती याचा मागोवा ठेवते आणि इतर कशालाही न अडथळा आणता स्वतंत्रपणे रद्द केली जाऊ शकते.
आमचे MCP सर्व्हर कोणत्याही MCP-सक्षम एजंटला नैसर्गिक भाषेमध्ये तुमचे होस्टिंग व्यवस्थापित करण्याची अनुमती देते, जे OAuth 2.1 द्वारे प्रमाणीकृत आणि तुमच्या संस्थेपुरते आणि RBAC भूमिकेपुरते मर्यादित असते, ज्यामध्ये प्रति-टूल रद्द करण्यायोग्य टोकन्स, विनाशात्मक कृतींवर पुष्टीकरण, खर्च मर्यादा आणि संपूर्ण ऑडिट लॉगिंग समाविष्ट असते.
खात्याचा प्रवेश आणि सर्व्हरचा प्रवेश या वेगवेगळ्या समस्या आहेत. साइट-स्तरीय क्रेडेन्शियल डॅशबोर्डमध्ये व्यवस्थापित केले जातात, किमान-प्रवेश अधिकारांवर दिले जातात आणि प्रतिबंधित (जेल्ड) केले जातात, जेणेकरून एका सहकाऱ्याचा शेल हा एकाच साइटचा शेल असेल.
एक एकल ऑपरेटर एकच संस्था आणि एक मालक सदस्यत्व ठेवतो, आणि जेव्हा एखादा कंत्राटदार प्रकल्पासाठी येतो तेव्हा डेवलपर भूमिका जोडतो. जेव्हा प्रकल्प संपतो, तेव्हा सदस्यत्व काढून टाकले जाते आणि त्यांचे साइन-इन तात्काळ काम करणे थांबवते - मागे फिरवण्यासाठी कोणतेही सामायिक क्रेडेन्शियल शिल्लक राहत नाही.
एक एजन्सी ऑर्गनायझेशन ट्री वापरते. प्रत्येक क्लायंटला स्वतःची चाईल्ड ऑर्गनायझेशन मिळते, ज्यामध्ये त्या क्लायंटच्या साइट्स असतात आणि क्लायंटच्या स्वतःच्या लोकांना तिथे मेंबरशिप्स मिळतात - व्हिजिबी जोवू इच्छिणाऱ्या भागधारकासाठी रीड-ऑनली (फक्त वाचण्यासाठी), आणि स्वतःहून सर्व्हिस घेऊ इच्छिणाऱ्या क्लायंटसाठी ओनर. तुमच्या कर्मचाऱ्यांकडे ट्रीमध्ये वरच्या पातळीवरील मेंबरशिप्स असतात आणि ते पोर्टफोलिओ पाहू शकतात; क्लायंट फक्त त्यांची स्वतःची शाखा पाहू शकतो आणि रो-लेव्हल सिक्युरिटी हे केवळ आश्वासन नसून ते शक्य करते.
एक पुनर्विक्रेता (रिसेलर) त्याच प्रकारे काम करतो, एक पातळी वर: एक पुनर्विक्रेता संस्था क्लायंट संस्थांची देखभाल करते, प्रत्येकाचे स्वतःचे सदस्य, बिलिंग दृश्य आणि साइट्स असतात. तीच मूलभूत प्रणाली उप-खाती, एजन्सी टीम आणि पुनर्विक्रेता पदानुक्रम (हायारार्की) चालवते - त्यापैकी कोणत्याही घटकासाठी कोणतीही वेगळी, दुय्यम यंत्रणा नाही.
कार्ड-मुक्त १४ दिवसांच्या चाचणीवर सर्व काही उपलब्ध आहे. पेमेंट तपशीलांशिवाय साइन अप करा, सहकाऱ्याला आमंत्रित करा, प्रत्येक भूमिका काय करू शकते आणि काय करू शकत नाही ते पहा आणि तुमची स्वतःची ऑडिट लॉग पुन्हा वाचा.
आज एक मेंबरशिप संपूर्ण संस्थेत आणि त्याच्या ट्री मधील प्रत्येक गोष्टीवर तिची भूमिका प्रदान करते, त्यामुळे साइटचे संच वेगळे करण्याचा मार्ग म्हणजे संस्था वेगळ्या करणे — त्या साइट्स त्यांच्या स्वतःच्या चाइल्ड संस्थेमध्ये ठेवा आणि तिथे मेंबरशिप प्रदान करा. एजन्सी आणि रिसेलर्ससाठी ही एक स्वच्छ पद्धत आहे, जिथे प्रत्येक क्लायंटला आधीपासूनच स्वतःची सीमा हवी असते. प्रति-मे मेंबरशिप रिसोर्स स्कोपिंग, एकाच संस्थेमधील नावाच्या साइट्सशी एकच मेंबरशिप जोडणे, हे सध्या उपलब्ध असण्यापेक्षा भविष्यात नियोजित केलेले सुधारणा आहे.
डेव्हलपर भूमिकेमध्ये साइट हटवणे किंवा साइट निलंबित करणे समाविष्ट नाही – त्या परवानग्या मालक (Owner) भूमिकेकडे असतात. याद्वारे साइट पाहणे आणि तयार करणे, सेवा रीस्टार्ट करणे, कॅशे साफ करणे, API की व्यवस्थापित करणे आणि तिकीट्सवर काम करणे शक्य होते. उपयोजन (Deployment) आणि थेट साइटवर पाठवण्याची (push-to-live) परवानगी देखील डेव्हलपर भूमिकेत समाविष्ट नाही, त्यामुळे प्रोडक्शनवर जाण्याची परवानगी खात्याच्या मालकाकडेच राहते. यासाठी स्टेजिंगचा वापर करा जेणेकरून बिल्डचे काम थेट लाइव्ह साइटवर होण्याऐवजी वेगळे होईल.
हे पूर्णपणे कर्मचाऱ्यांच्या भूमिकेवर अवलंबून असते आणि प्रत्येक भूमिका म्हणजे परवानगी कींचा एक मर्यादित संच असतो. उदाहरणार्थ, एक सपोर्ट एजंट तुमचे खाते आणि साइट्स पाहू शकतो, तुमच्या तिकिटांना (टिकट्स) पाहू आणि उत्तर देऊ शकतो, साइट रीस्टार्ट करू शकतो आणि त्याचे कॅशे साफ करू शकतो — परंतु बिलिंग कॉन्फिगरेशन, रिफंड्स, प्लॅन्स किंवा फ्लीटला हात लावू शकत नाही. ग्राहक म्हणून लॉग इन करणे ही एक स्वतंत्र परवानगी आहे जी फक्त सुपर Admin कडे असते आणि जेव्हा असे होते तेव्हा डॅशबोर्डवर एक कायमस्वरूपी इम्परसोनेशन बॅनर दिसतो. प्रत्येक विशेष अधिकाराची कृती (प्रिव्हिलेज्ड ॲक्शन) ही कृती करणारी व्यक्ती, कृती, लक्ष्य, आयपी आणि टाइमस्टॅम्पसह ऑडिट लॉगमध्ये रेकॉर्ड केली जाते आणि तुम्ही तुमच्या संस्थेचा लॉग स्वतः वाचू शकता.
सदस्यता काढून टाका आणि त्या संस्थेमध्ये त्यांचा प्रवेश संपतो — त्यांच्याकडे स्वतःची ओळख अजूनही कायम असते, परंतु तुमच्या खात्यात कोणतीही भूमिका आणि त्यामुळे कोणतीही परवानगी नसते. API की वेगवेगळ्या रद्द केल्या जातात, त्यामुळे इतर कशालाही धक्का न लावता पायपलाईन की बंद करता येते. तुम्ही SAML सिंगल साइन-ऑन वापरत असल्यास, तुमच्या आयडेंटिटी प्रोव्हायडरमधील डिप्रोव्हिजनिंग सेंट्रली साइन-इन हँडल करते. SSH की सारखी साइट-स्तरीय क्रेडेन्शियल डॅशबोर्डमध्ये रद्द केली जातात आणि ही काढण्याची क्रिया स्वतः ऑडिट-लग केली जाते.
नाही — परंतु यामागचे नेमके कारण समजून घेणे महत्त्वाचे आहे. एपीआय की (API keys) वैयक्तिक सदस्याच्या मालकीच्या नसून संस्थेच्या मालकीच्या असतात आणि त्याच परवानगी कॅटलॉगशी जोडलेली त्यांची स्वतःची विशिष्ट व्याप्ती असते. त्यामुळे एखाद्या व्यक्तीला की देण्याऐवजी, तुम्ही त्या कामासाठी लागणाऱ्या सर्वात मर्यादित व्याप्तीसह विशिष्ट कामासाठी की तयार करता आणि काम संपल्यानंतर ती की रद्द करता. गुप्त माहितीचा केवळ एक हॅश संग्रहित केला जातो आणि प्रत्येक की ती शेवटची कधी वापरली गेली हे नोंदवते, ज्यामुळे न वापरलेल्या की शोधणे आणि रद्द करणे सोपे होते.
होय. आमचा MCP सर्व्हर OAuth 2.1 द्वारे एजंट्सचे प्रमाणीकरण करतो आणि त्यांना तुमच्या संस्थेच्या व RBAC भूमिकेच्या अधीन ठेवतो, ज्यामध्ये प्रति-टूल रद्द करता येणारे टोकन्स असतात, त्यामुळे तुम्ही संपूर्ण प्रवेश देण्याऐवजी विशिष्ट क्षमता प्रदान करता. विनाशात्मक कृतींसाठी पुष्टीकरणाची आवश्यकता असते, खर्च मर्यादा लागू होतात आणि प्रत्येक कृती मानवी क्रियाकलापांप्रमाणेच समान ऑडिट लॉगमध्ये नोंदवली जाते.
Postgres रो-लेव्हल सिक्युरिटी डेटाबेसमध्येच कॉलरच्या संस्थात्मक सबट्रीपुरती क्वेरी मर्यादित करते, ज्यामध्ये ॲप्लिकेशन-लेव्हल फिल्टर हा एकमेव मार्ग नसून संरक्षणाचा अतिरिक्त थर म्हणून काम करतो. व्याप्तीबाहेरील रेकॉर्डसाठीच्या विनंत्यांवर परवानगीची त्रुटी (permission error) दाखवण्याऐवजी नॉट-फाऊंड (not-found) असे दाखवले जाते, ज्यामुळे काय अस्तित्वात आहे याबद्दल काहीही उघड होत नाही. सर्व्हरच्या बाजूने, CageFS द्वारे प्रति-साइट अलगीकरण (isolation) प्रत्येक भाडेकरूचे (tenant) शेल आणि फाइल्स त्यांच्या स्वतःच्या साइटपुरत्या मर्यादित ठेवते.
होय. १४ दिवसांची ट्रायल कार्ड-मुक्त आहे — कोणतीही पेमेंट तपशील नाहीत, कोणतेही बंधन नाही — आणि यामध्ये पाच साईट्सपर्यंतच्या Footprint-Free Hosting चा समावेश आहे. प्रतिबद्ध होण्यापूर्वी सहकाऱ्याला आमंत्रित करणे, भूमिका नेमणे आणि मर्यादा तुमच्या गरजेनुसार कार्य करतात याची खात्री करणे यासाठी हे पुरेसे आहे.
कार्ड-मुक्त 14-दिवसीय चाचणी सुरू करा, कोणालातरी आमंत्रित करा आणि परवानगी मॉडेलला त्याचे काम करू द्या — तुम्ही नाव देऊ शकता अशा भूमिका, तुम्ही रद्द करू शकता असे व्याप्ती आणि कोणी काय केले हे तंतोतंत सांगणारे ऑडिट लॉग.
विनाशुल्क सुरू करा