VPC रिमोट प्रवेश स्वीकारण्यासाठी नकार चाचण्या आवश्यक आहेत

रिमोट प्रवेशाची स्वीकृती ही अपेक्षित परिणामांची तक्ता आहे, कार्यरत पृष्ठाचा स्क्रीनशॉट नाही। प्रत्येक गटासाठी काय यशस्वी व्हायला हवे आणि काय अयशस्वी व्हायला हवे ते लिहा, नंतर नियंत्रित कालावधीत समर्पित चाचणी ओळखींसह दोन्ही चालवा। सीमा सिद्ध करणारा भाग म्हणजे नकार; यशस्वी लॉगिन फक्त बोगदा अस्तित्वात असल्याचे सिद्ध करते। हे सर्व आधीच निवडलेल्या VPN उत्पादनासह कार्य करते।

चाचण्यांसाठी वेगळी खाती वापरा आणि चाचणी ओळखीला खऱ्या अपवादासोबत कोणी गोंधळणार नाही अशा प्रकारे लेबल करा।

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

घटकांपासून नाही, भूमिकांपासून सुरुवात करा: कोणाला कोणती सेवा हवी, कुठून आणि कोणत्या ओळखीने। एक उदाहरण VPC घ्या: एका गटाला HTTPS द्वारे स्टेजिंग हवे, दुसऱ्याला उत्पादन डेटाबेस हवा, आणि तिसरा लहान गट गेटवेचेच व्यवस्थापन करतो। प्रत्येक ओळीला अपेक्षित परवानगी आणि अपेक्षित नकार मिळतो, कार्य करू नये अशा शेजारच्या सेवेचा आणि शेजारच्या खात्याचाही समावेश होतो। तीच तक्ता स्वीकृतीचा निकष आहे, आणि चाचण्या न चालवणारे लोकही तिचे पुनरावलोकन करू शकतात।

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

मार्ग म्हणजे अधिकृतता नाही

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

म्हणूनच नकार चाचण्या सर्व्हर बाजूकडे लक्ष्य करतात: ते परिणाम क्लायंट संपादित करून बदलता येत नाहीत।

नियंत्रण प्रत्यक्षात कोणता स्रोत पाहते?

नियंत्रण ज्या स्रोत पत्त्याचे मूल्यांकन करते ते गेटवेच्या रचनेवर अवलंबून असते। EC2 वर होस्ट केलेले गेटवे राउटेड पूल पुढे पाठवू शकते, त्याचे स्वतःच्या पत्त्यात भाषांतर करू शकते किंवा NAT नंतर वेगळा पत्ता सादर करू शकते; व्यवस्थापित Client VPN सबनेटशी जोडले जाते आणि स्वतःचे मॉडेल अनुसरते। सुरक्षा गट आणि नेटवर्क ACL त्या प्रक्रियेनंतर जे येते ते पाहतात। चुकीच्या स्रोत गृहीतकाच्या आधारे नियम तपासणे ही बरोबर दिसणारी आणि चुकीचा रहदारी स्वीकारणारी सीमा तयार करण्याची सामान्य पद्धत आहे।

प्रत्येक परिणाम सर्वात लहान उपयुक्त घटनेशी जोडा: ओळख आणि सत्र, संसाधन, क्रिया, वेळ आणि निर्णय। CloudTrail API कॉल, VPC प्रवाह नोंद आणि VPN सत्र लॉग वेगवेगळ्या प्रश्नांची उत्तरे देतात, आणि त्यातील कोणतेही एकटे अनुप्रयोगाचे ऑडिट नाही।

ओळख मागे घ्या आणि पुन्हा चाचणी करा

मागे घेण्याचाही समावेश त्याच तक्त्यात करा। चाचणी ओळख काढा, नवीन सत्र नाकारले जाते याची खात्री करा, नंतर विद्यमान सत्रांशी कसे वागले जाते याची स्वतंत्रपणे खात्री करा, कारण ही वेगवेगळ्या मालकांची वेगवेगळी वर्तणूक आहे। गेटवे पुन्हा सुरू केल्यानंतर किंवा बदलल्यानंतर काय होते ते तपासा, जेणेकरून हाताने जोडलेला अपवाद गुपचूप नाहीसा होणार नाही किंवा अधिक व्यापक होऊन परत येणार नाही। पुढील तैनातीपर्यंतच टिकणारी सीमा सीमा नसते।

यातील काहीही पॅचिंग, पुनर्प्राप्ती किंवा क्रेडेन्शियल जीवनचक्राच्या कामाची जागा घेत नाही। हे अरुंद वचन मोजण्यायोग्य बनवते: योग्य लोक योग्य सेवांपर्यंत पोहोचतात, तर जवळचे मार्ग, खाती आणि व्यवस्थापन पृष्ठभाग अनुदानाबाहेर राहतात।

तक्ता तैनातीसोबत ठेवा आणि गेटवे बदलल्यावर पुन्हा चालवा। चाचण्या स्वस्त आहेत; त्यांच्यामागील गृहीतके नाहीत।