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

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

डेभलपर (Developer) भूमिकाले साइट हटाउने वा साइट निलम्बन गर्ने अधिकार दिँदैन — ती कुराहरू ओनर (Owner) भूमिकामा मात्र सीमित हुन्छन्। यसले साइटहरू हेर्ने र सिर्जना गर्ने, सेवाहरू पुनः सुरु गर्ने, क्यास पर्ज (purge cache) गर्ने, API कुञ्जीहरू प्रबन्ध गर्ने र टिकटहरूमा काम गर्ने अनुमति दिन्छ। डिप्लोयमेन्ट (Deployment) र पुश-टु-लाइभ (push-to-live) अनुमतिहरू पनि डेभलपर भूमिकामा पर्दैनन्, त्यसैले प्रोडक्सनमा प्रवर्द्धन गर्ने अधिकार खाताको मालिकसँगै रहन्छ। त्यसलाई स्टजिङ (staging) सँग जोड्नुहोस् ताकि निर्माणको काम सुरुमै लाइभ साइटभन्दा बाहिर हुन सकोस्।

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

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

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

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

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

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