स्टेजिंग प्रोडक्शन नहीं है: उसे अपनी अलग एक्सेस सीमा दें
स्टेजिंग लेबल यह तय नहीं करता कि ऐप तक कौन पहुँचता है या वह किसे छू सकता है। प्रकाशित करने से पहले दर्शक, डेटा, क्रेडेंशियल और एडमिन सतहों की समीक्षा करें।
स्टेजिंग एक परीक्षण प्रणाली जैसा दिखता है जब तक आप उसके वातावरण में नकल की गई प्रोडक्शन डेटाबेस, जीवित मेल क्रेडेंशियल और भुगतान कुंजी न देख लें। उस क्षण टैब पर लगा लेबल महत्वहीन हो जाता है और असली सवाल यह है कि यह परिनियोजन कहाँ तक पहुँच सकता है और उस तक कौन पहुँच सकता है। सामने के दरवाजे का VPN उस सवाल का जवाब नहीं देता, क्योंकि वह सिस्टम में जाने का एक ही रास्ता सीमित करता है और इस बारे में कुछ नहीं कहता कि सिस्टम बाहर जाते समय क्या कर सकता है। दर्शकों से शुरू करें और बाहर की ओर बढ़ें।
URL से नहीं, दर्शकों से शुरू करें
तीन दर्शक तीन अलग डिज़ाइन बनाते हैं। निजी इंजीनियरिंग वातावरण को पहचान और मार्ग चाहिए; ग्राहक स्वीकृति परीक्षण को ग्राहकों का प्रतिनिधित्व करने वाले खाते चाहिए; सार्वजनिक प्रदर्शन को अपने नियंत्रणों के साथ जानबूझकर किया गया प्रदर्शन चाहिए। दर्शकों को पहले लिख लेना उस आम बहाव को रोकता है जहाँ पूर्वावलोकन URL चुपचाप स्थायी हो जाता है। समीक्षा में बाकी सब उस उत्तर पर निर्भर है।
यदि कोई दर्शकों का नाम नहीं बता सकता, तो इसे दस्तावेज़ीकरण की कमी नहीं बल्कि पहला निष्कर्ष मानें।
सामने के दरवाजे और उसके पीछे की सतहों से गुज़रें
जो URL आपको दिया गया है उस पर भरोसा करने से पहले नाम हल करें, फिर प्रशासनिक रास्ते सीधे माँगें।
dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/adminअतिरिक्त रिकॉर्ड अक्सर एक सीधा-स्रोत पता उजागर करते हैं जो CDN या VPN प्रवेश को बायपास करता है, जिससे इच्छित नियंत्रण वैकल्पिक हो जाता है। रीडायरेक्ट आपको बताता है कि ऐप कहाँ रहने की सोचता है, और अप्रत्याशित स्कीम या होस्टनाम आगे जाँच का हक़दार है। संभावित एडमिन रास्ते की जाँच से पृष्ठ नहीं, इनकार मिलना चाहिए। अनधिप्रमाणित प्रशासनिक पथ पर 200 मिलना वही निष्कर्ष है जिसे पूरी समीक्षा खोज रही थी।
देखें कि वातावरण क्या कर सकता है, केवल यह नहीं कि वह क्या दिखाता है
लॉगिन मांगने वाला पृष्ठ फिर भी बैकएंड अधिकार के साथ भेजा जाता है। पूछें कि वर्कलोड किस पहचान के अंतर्गत चलता है, फिर उससे जुड़ी नीतियाँ पढ़ें।
aws sts get-caller-identityवह कॉल उस खाते और प्रिंसिपल की रिपोर्ट करती है जिसे वातावरण वास्तव में उपयोग करता है, और यही हर आगामी अनुमति प्रश्न का शुरुआती बिंदु है। वहाँ से जाँचें कि पहचान मेल भेज सकती है, पैसा हिला सकती है, प्रोडक्शन रहस्य पढ़ सकती है या प्रोडक्शन डेटा लिख सकती है। साझा प्रोडक्शन क्रेडेंशियल को सीमित स्टेजिंग पहचानों से बदलें, और जहाँ मौजूद हों वहाँ विक्रेता सैंडबॉक्स को प्राथमिकता दें। जो परीक्षण खाता असली कार्ड से शुल्क ले सकता है वह दूसरे होस्टनाम वाला प्रोडक्शन सिस्टम है।
समीक्षा खत्म होने के बाद भी सीमा बनाए रखें
वातावरण एक ऑडिट से सुरक्षित नहीं होता; वह ऐसे स्वामित्व से सुरक्षित होता है जो कर्मचारी बदलावों में टिकता है। तय करें कि कौन एक्सेस हटाता है, परीक्षण डेटा रीसेट करता है और परिनियोजन को सेवानिवृत्त करता है, और पूर्वावलोकन को ऐसी समाप्ति दें जिसे किसी को नवीनीकृत करना पड़े। अलगाव तभी मदद करता है जब अलग की गई चीज़ का रखरखाव होता रहे। अगले रिलीज़ के बाद उन्हीं रास्तों को फिर जाँचें, क्योंकि फीचर फ़्लैग या नया एकीकरण ठीक वही तरीका है जिससे अस्वीकृत मार्ग खुला हो जाता है।
अनुमत कार्यप्रवाह और अस्वीकृत कार्यप्रवाह के साथ डिज़ाइन स्वीकार करें। यदि दोनों दस्तावेज़ के अनुसार व्यवहार करते हैं, तो सीमा मौजूद है; यदि केवल सुखद मार्ग का परीक्षण हुआ, तो यह एक आशा है।