मानिसहरूलाई उनीहरूलाई चाहिने पहुँच मात्र दिनुहोस् — अरू केही पनि होइन

आज सदस्यताले संस्था र संरचनाको रूखमा त्यस अन्तर्गतका सबै कुराहरूमा आफ्नो भूमिका प्रदान गर्छ, त्यसैले साइट सेटहरू अलग गर्ने तरिका भनेको संस्थाहरूलाई अलग गर्नु हो — ती साइटहरूलाई तिनीहरूको आफ्नै शाखा संस्थामा राख्नुहोस् र सदस्यता त्यहाँ प्रदान गर्नुहोस्। यो एजेन्सीहरू र पुनर्विक्रेताहरूका लागि एक स्पष्ट मोडेल हो, जहाँ प्रत्येक ग्राहक पहिले नै आफ्नै सीमा चाहन्छन्। प्रति-सदस्यता स्रोत स्कोपिङ, अर्थात् एउटै संस्थाभित्र तोकिएका साइटहरूमा एकल सदस्यता सीमित गर्नु, हाल उपलब्ध सुविधा नभई एक योजनाबद्ध सुधार हो।

Developer भूमिकामा साइट मेटाउने वा साइट निलम्बन गर्ने अधिकार हुँदैन — ती अधिकारहरू Owner भूमिकामा रहन्छन्। यसले साइटहरू हेर्ने र सिर्जना गर्ने, सेवाहरू पुनः सुरु गर्ने, क्यास खाली गर्ने, API कीहरू व्यवस्थापन गर्ने र टिकटहरूमा काम गर्ने अनुमति दिन्छ। डिप्लोयमेन्ट र push-to-live अनुमतिहरू पनि Developer अधिकारको हिस्सा होइनन्, त्यसैले उत्पादन (production) मा पठाउने अधिकार खाताधनीसँगै रहन्छ। यसलाई स्टिजिंगसँग जोड्नुहोस् ताकि निर्माण कार्य सुरुदेखि नै प्रत्यक्ष साइट बाहिर होस्।

यो पूर्ण रूपमा कर्मचारीको भूमिकामा निर्भर गर्दछ, र प्रत्येक भूमिका अनुमति कुञ्जीहरूको सीमित सेट हो। उदाहरणका लागि, Support Agent ले तपाईंको खाता र साइटहरू हेर्न, तपाईंका टिकटहरू हेर्न र जवाफ दिन, साइट पुन: सुरु गर्न र यसको क्यास खाली गर्न सक्छन् — र बिलिङ कन्फिगरेसन, फिर्ता रकम, योजनाहरू वा फ्लीटलाई चलाउन सक्दैनन्। ग्राहकको रूपमा साइन इन गर्नु एक छुट्टै अनुमति हो जुन Super Admin सँग मात्र हुन्छ, र यसो हुँदा ड्यासबोर्डले निरन्तर प्रतिरूपण ब्यानर प्रदर्शन गर्दछ। प्रत्येक विशेषाधिकार प्राप्त कार्यलाई कर्ता, कार्य, लक्ष्य, IP र टाइमस्ट्याम्पसहित अडिट लगमा रेकर्ड गरिन्छ, र तपाईं आफ्नो संस्थाको लग आफैं पढ्न सक्नुहुन्छ।

सदस्यता हटाउनुहोस् र त्यो संस्थामा उनीहरूको पहुँच समाप्त हुन्छ — उनीहरूसँग अझै पनि आफ्नै पहिचान हुन्छ, तर कुनै भूमिका हुँदैन र त्यसैले तपाईंको खातामा कुनै अनुमतिहरू हुँदैनन्। API कीहरू व्यक्तिगत रूपमा खारेज गरिन्छन्, त्यसैले अन्य कुनै कुरामा बाधा नपुर्‍याई पाइपलाइन की हटाउन सकिन्छ। यदि तपाईंले SAML एकल साइन-अन प्रयोग गर्नुहुन्छ भने, तपाईंको पहिचान प्रदायकमा गरिएको डिप्रोभिजनिङले साइन-इनलाई केन्द्रीय रूपमा व्यवस्थापन गर्छ। SSH की जस्ता साइट-स्तरका प्रमाणहरू ड्यासबोर्डमा खारेज गरिन्छन्, र हटाउने कार्य आफैं अडिट-लग हुन्छ।

होइन — तर किन हो भन्ने बारेमा स्पष्ट हुनु आवश्यक छ। API कुञ्जीहरू व्यक्तिगत सदस्यका नभई संस्थाका हुन्छन्, र तिनीहरूले एउटै अनुमति सूचीसँग जोडिएका आफ्नै विशिष्ट स्कोपहरू बोकेका हुन्छन्। त्यसैले कुनै व्यक्तिलाई कुञ्जी दिनुको सट्टा, तपाईंले त्यो कामलाई चाहिने सबैभन्दा सानो स्कोपको साथ कामको लागि एउटा कुञ्जी सिर्जना गर्नुहोस्, र काम सकिएपछि त्यो कुञ्जी खारेज गर्नुहोस्। गोप्य कुराको ह्यास मात्र भण्डारण गरिन्छ, र प्रत्येक कुञ्जीले यो कहिले अन्तिम पटक प्रयोग भएको थियो भनेर रेकर्ड गर्दछ ताकि प्रयोग नभएका कुञ्जीहरू फेला पार्न र हटाउन सजिलो होस्।

हो। हाम्रो MCP सर्भरले OAuth 2.1 मार्फत एजेन्टहरूलाई प्रमाणीकरण गर्दछ र तिनीहरूलाई तपाईंको संस्था र तपाईंको RBAC भूमिकामा प्रति-उपकरण रद्द गर्न सकिने टोकनहरूसहित सीमित गर्दछ, जसले गर्दा तपाईंले पूर्ण पहुँचको सट्टा निश्चित क्षमता प्रदान गर्नुहुन्छ। विनाशकारी कार्यहरूका लागि पुष्टि आवश्यक पर्दछ, खर्च सीमाहरू लागू हुन्छन्, र प्रत्येक कार्य मानवीय गतिविधि जस्तै समान अडिट लगमा दर्ता हुन्छ।

Postgres Row-Level Security ले एप्लिकेसन-स्तरको फिल्टरलाई एकमात्र रक्षा पङ्क्तिका रूपमा नभई गहिरो सुरक्षाका रूपमा प्रयोग गर्दै डाटाबेसमै क्वेरीहरूको दायरा कलरको संस्थागत सबट्रीमा सीमित गर्दछ। दायरा बाहिरका रेकर्डहरूका लागि अनुरोध गर्दा अनुमति त्रुटिको सट्टा फेला परेन भन्ने सन्देश आउँछ, जसले गर्दा के अवस्थित छ भन्ने बारे केही पनि खुलासा हुँदैन। सर्भरतर्फ, CageFS मार्फत प्रति-साइट पृथकीकरणले प्रत्येक भाडामा लिनेको शेल र फाइलहरूलाई उनीहरूको आफ्नै साइटमा मात्र सीमित राख्छ।

हो। १४-दिने परीक्षण कार्ड-रहित छ — कुनै भुक्तानी विवरण पर्दैन, कुनै प्रतिबद्धता चाहिँदैन — र यसले ५ वटा सम्म साइटहरूसहित Footprint-Free होस्टिङलाई समेट्छ। तपाईंले प्रतिबद्धता जनाउनु अघि सहकर्मीलाई आमन्त्रण गर्न, भूमिका तोक्न र सीमाहरूले तपाईंलाई आवश्यक परे अनुसार काम गर्छन् भनी पुष्टि गर्न यो पर्याप्त छ।