VPC रिमोट एक्सेस स्वीकार करने के लिए अस्वीकृति परीक्षण ज़रूरी हैं

रिमोट एक्सेस की स्वीकृति अपेक्षित परिणामों की तालिका है, काम करते पृष्ठ का स्क्रीनशॉट नहीं। हर समूह के लिए लिखें कि क्या सफल होना चाहिए और क्या विफल होना चाहिए, फिर नियंत्रित अवधि में समर्पित परीक्षण पहचानों के साथ दोनों चलाएँ। अस्वीकृतियाँ वह हिस्सा हैं जो सीमा सिद्ध करती हैं; सफल लॉगिन केवल यह सिद्ध करता है कि टनल मौजूद है। यह सब पहले से चुने गए VPN उत्पाद के साथ काम करता है।

परीक्षणों के लिए अलग खाते इस्तेमाल करें और उन्हें ऐसे लेबल करें कि कोई परीक्षण पहचान को असली अपवाद न समझे।

सीमा को अपेक्षित परिणामों के रूप में लिखें

घटकों से नहीं, भूमिकाओं से शुरू करें: किसे कौन-सी सेवा चाहिए, कहाँ से, और किस पहचान के साथ। एक उदाहरण VPC लें: एक समूह को HTTPS से स्टेजिंग चाहिए, दूसरे को प्रोडक्शन डेटाबेस चाहिए, और तीसरा छोटा समूह गेटवे का ही प्रबंधन करता है। हर पंक्ति को एक अपेक्षित अनुमति और एक अपेक्षित अस्वीकृति मिलती है, जिसमें पड़ोसी सेवा और पड़ोसी खाता भी शामिल है जिन्हें काम नहीं करना चाहिए। वही तालिका स्वीकृति का मानदंड है, और जो लोग परीक्षण नहीं चलाते वे भी इसकी समीक्षा कर सकते हैं।

डेटाबेस लॉगिन का परीक्षण नेटवर्क पथ से अलग करें। पहुँच में आने वाला TCP पोर्ट किसी अस्वीकृत डेटाबेस खाते को सफल नहीं बनाना चाहिए, और VPN सदस्यता को क्लाउड IAM भूमिका नहीं बनानी चाहिए या प्रशासनिक API पहुँच नहीं देनी चाहिए। ये तीन स्वतंत्र नियंत्रण हैं, और ये स्वतंत्र रूप से विफल होते हैं।

रूट अनुमति नहीं है

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

इसी कारण अस्वीकृति परीक्षण सर्वर पक्ष को लक्षित करते हैं: वे परिणाम क्लाइंट संपादित करके बदले नहीं जा सकते।

नियंत्रण वास्तव में कौन-सा स्रोत देखता है?

नियंत्रण जिस स्रोत पते का मूल्यांकन करता है वह गेटवे की संरचना पर निर्भर करता है। EC2 पर होस्ट किया गया गेटवे रूट किए गए पूल को आगे भेज सकता है, उसे अपने पते में अनुवादित कर सकता है, या NAT के बाद अलग पता प्रस्तुत कर सकता है; प्रबंधित Client VPN किसी सबनेट से जुड़ता है और अपना मॉडल अपनाता है। सुरक्षा समूह और नेटवर्क ACL उस प्रसंस्करण के बाद जो आता है उसे देखते हैं। गलत स्रोत धारणा के सामने नियम की जाँच करना ऐसी सीमा बनाने का आम तरीका है जो सही दिखती है और गलत ट्रैफ़िक स्वीकार करती है।

हर परिणाम को सबसे छोटी उपयोगी घटना से जोड़ें: पहचान और सत्र, संसाधन, क्रिया, समय और निर्णय। CloudTrail API कॉल, VPC फ़्लो रिकॉर्ड और VPN सत्र लॉग अलग-अलग प्रश्नों के उत्तर देते हैं, और इनमें से कोई अकेला एप्लिकेशन ऑडिट नहीं है।

पहचान हटाएँ और फिर परीक्षण करें

हटाने को भी उसी तालिका में शामिल करें। परीक्षण पहचान हटाएँ, पुष्टि करें कि नया सत्र अस्वीकार होता है, फिर अलग से पुष्टि करें कि मौजूदा सत्रों के साथ कैसा व्यवहार होता है, क्योंकि ये अलग मालिकों वाले अलग व्यवहार हैं। गेटवे के पुनः आरंभ या बदलने के बाद क्या होता है, यह जाँचें, ताकि हाथ से जोड़ा गया अपवाद चुपचाप गायब न हो या और व्यापक होकर न लौटे। जो सीमा केवल अगली तैनाती तक टिके, वह सीमा नहीं है।

इनमें से कुछ भी पैचिंग, रिकवरी या क्रेडेंशियल जीवनचक्र के काम को नहीं बदलता। यह एक संकीर्ण वादे को मापने योग्य बनाता है: सही लोग सही सेवाओं तक पहुँचते हैं, जबकि निकट के रूट, खाते और प्रबंधन सतहें अनुदान से बाहर रहती हैं।

तालिका को तैनाती के साथ रखें और गेटवे बदलने पर इसे फिर चलाएँ। परीक्षण सस्ते हैं; उनके पीछे की धारणाएँ नहीं।