लोकांना त्यांना आवश्यक असलेला नेमका ॲक्सेस द्या — आणि इतर काहीही नाही

आज सदस्यत्व एखाद्या संस्थेमध्ये आणि तिच्या रचनेच्या झाडाखालील सर्व घटकांवर तिची भूमिका प्रदान करते, त्यामुळे साइट संच वेगळे करण्याचा मार्ग म्हणजे संस्था वेगळ्या करणे — त्या साइट्स त्यांच्या स्वतःच्या उप-संस्थेत ठेवा आणि सदस्यत्व तेथे प्रदान करा. एजन्सी आणि पुनर्विक्रेत्यांसाठी हे एक स्पष्ट मॉडेल आहे, जेथे प्रत्येक क्लायंटला आधीपासूनच स्वतःची स्वतंत्र सीमा हवी असते. प्रति-सदस्यत्व संसाधन मर्यादा ठरवणे, म्हणजेच एका संस्थेतील विशिष्ट साइट्ससाठीच एकल सदस्यत्व मर्यादित करणे, ही एक नियोजित सुधारणा आहे, सध्या उपलब्ध असलेली गोष्ट नाही.

Developer भूमिकेकडे साइट हटवणे किंवा साइट निलंबित करण्याचे अधिकार नसतात — ते अधिकार Owner भूमिकेकडे असतात. हे साइट्स पाहणे आणि तयार करणे, सेवा रीस्टार्ट करणे, कॅशे साफ करणे, API की व्यवस्थापित करणे आणि तिकिटांवर काम करण्याची अनुमती देते. डिप्लोयमेंट आणि push-to-live परवानग्या देखील Developer अनुदानाचा भाग नाहीत, त्यामुळे प्रोडक्शनवर प्रमोट करण्याचे अधिकार खाते मालकाकडेच राहतात. हे स्टेजिंगसह जोडा जेणेकरून निर्मितीचे काम सुरुवातीपासूनच थेट साइटच्या बाहेर पार पडेल.

हे पूर्णपणे कर्मचाऱ्यांच्या भूमिकेवर अवलंबून असते, आणि प्रत्येक भूमिका ही परवानगी की (permission keys) चा एक मर्यादित संच असतो. उदाहरणार्थ, Support Agent तुमचे खाते आणि साइट्स पाहू शकतात, तुमच्या तिकीटांचे अवलोकन करून त्यांना प्रतिसाद देऊ शकतात, साइट रीस्टार्ट करू शकतात आणि तिची कॅशे साफ करू शकतात — आणि बिलिंग कॉन्फिगरेशन, परतावे, प्लॅन्स किंवा फ्लीटमध्ये बदल करू शकत नाहीत. ग्राहक म्हणून साइन इन करणे ही केवळ Super Admin कडे असणारी स्वतंत्र परवानगी आहे, आणि जेव्हा असे घडते तेव्हा डॅशबोर्ड एक सतत दिसणारा इम्पर्सनॅशन बॅनर दाखवतो. प्रत्येक विशेषाधिकारप्राप्त क्रिया ही कर्ता, क्रिया, लक्ष्य, IP आणि टाइमस्टॅम्पसह ऑडिट लॉगमध्ये नोंदवली जाते, आणि आपण आपल्या संस्थेचा लॉग स्वतः वाचू शकता.

सदस्यत्व काढून टाका आणि त्या संस्थेचा त्यांचा प्रवेश समाप्त होईल — त्यांची स्वतःची ओळख कायम राहील, परंतु तुमच्या खात्यात कोणतीही भूमिका आणि पर्यायाने कोणतीही अनुमती असणार नाही. API की वैयक्तिकरीत्या रद्द केल्या जातात, ज्यामुळे इतर कशालाही अडथळा न आणता पाइपलाइन की बंद केली जाऊ शकते. आपण SAML सिंगल साइन-ऑन वापरत असल्यास, आपल्या ओळख प्रदात्यामधील (identity provider) डीप्रोव्हिजनिंग हे साइन-इनचे केंद्रीय व्यवस्थापन करते. SSH की यांसारखी साइट-स्तरीय क्रेडेंशियल्स डॅशबोर्डमध्ये रद्द केली जातात आणि ही काढण्याची प्रक्रिया स्वतः ऑडिट-लॉगमध्ये नोंदवली जाते.

नाही — परंतु त्याचे कारण स्पष्ट करणे महत्त्वाचे आहे. API की या संस्थेच्या मालकीच्या असतात, कोणत्याही वैयक्तिक सदस्याच्या नाहीत, आणि त्या एकाच परवानगी कॅटलॉगशी जोडलेल्या स्वतःच्या तपशीलवार व्याप्ती (scopes) बाळगतात. त्यामुळे एखाद्या व्यक्तीला की देण्याऐवजी, तुम्ही त्या कामासाठी आवश्यक असलेल्या अत्यंत मर्यादित व्याप्तीसह ते काम करण्यासाठी की तयार करता आणि काम संपल्यावर ती की रद्द करता. केवळ सिक्रेटचा हॅश संग्रहित केला जातो आणि प्रत्येक की शेवटची कधी वापरली गेली होती याची नोंद ठेवली जाते, ज्यामुळे न वापरलेल्या की शोधणे आणि त्या बंद करणे सोपे जाते.

होय. आमचे MCP सर्व्हर OAuth 2.1 सह एजंट्सचे प्रमाणीकरण करते आणि प्रत्येक टूलनुसार रद्द करण्यायोग्य टोकन्ससह त्यांना तुमच्या संस्थेच्या आणि तुमच्या RBAC भूमिकेच्या मर्यादेत ठेवते, ज्यामुळे तुम्ही सरसकट ॲक्सेस देण्याऐवजी एखादी विशिष्ट क्षमता प्रदान करता. विनाशकारी क्रियांसाठी पुष्टीकरण आवश्यक असते, खर्चाच्या मर्यादा लागू होतात आणि प्रत्येक कृती मानवी कृतींप्रमाणेच त्याच ऑडिट लॉगमध्ये नोंदवली जाते.

Postgres Row-Level Security स्वतः डेटाबेसमध्येच कॉलरच्या संस्थात्मक सबट्रीपुरती क्वेरींची व्याप्ती मर्यादित करते, ज्यामध्ये ॲप्लिकेशन-स्तरीय फिल्टर केवळ एकमेव संरक्षण न राहता बहुस्तरीय संरक्षण म्हणून काम करतो. व्याप्तीबाहेरील नोंदींसाठीच्या विनंत्या परवानगी त्रुटीऐवजी 'सापडले नाही' असा प्रतिसाद देतात, ज्यामुळे नक्की काय अस्तित्वात आहे याबद्दल काहीही उघड होत नाही. सर्व्हरच्या बाजूने, CageFS द्वारे प्रति-साइट अलगीकरण प्रत्येक भाडेकरूचे शेल आणि फाइल्स त्यांच्या स्वतःच्या साइटपुरते मर्यादित ठेवते.

होय. १४ दिवसांची ट्रायल कार्ड-मुक्त आहे — कोणतेही पेमेंट तपशील नाहीत, कोणतेही बंधन नाही — आणि यामध्ये कमाल पाच साइट्ससाठी Footprint-Free होस्टिंग समाविष्ट आहे. वचनबद्ध होण्यापूर्वी सहकाऱ्याला आमंत्रित करण्यासाठी, भूमिका नियुक्त करण्यासाठी आणि सीमा तुमच्या गरजेनुसार काम करतात याची खात्री करण्यासाठी हे पुरेसे आहे.