तुम्ही mTLS द्वारे साइन इन करता, डॅशबोर्ड लोड होतो, आणि साइट VPN आता अनावश्यक आहे हे विधान रात्री दोन वाजता डेटाबेस पुनर्संचयित करावा लागेपर्यंतच सुमारास योग्य वाटते। ॲपची TLS सीमा केवळ एका चॅनेलचे वर्णन करते। होस्ट, डेटाबेस, बॅकअप लक्ष्य आणि क्लाउड खाते यापैकी प्रत्येकाकडे स्वतःचा प्रवेश मार्ग, स्वतःची ओळख आणि स्वतःचा मंजूरकर्ता आहे, आणि त्यापैकी कोणीही यशस्वी लॉगिनने तपासले जात नाही।

लॉगिन स्क्रीनपासून बाहेर पडा

सामान्य वापरकर्त्याप्रमाणे साइन इन करा आणि विनंती स्पर्श करते ते प्रत्येक पाऊल लिहा: ब्राउझर, एज, ॲप्लिकेशन श्रोता, सत्र संग्रह, बॅकएंड API। प्रत्येक पाऊलाला एक मालक आणि एक प्रमाणीकरण निर्णय असतो। आता होस्टला पॅच करणाऱ्या व्यक्तीसाठी आणि रात्रीचा बॅकअप लिहिणाऱ्या कामासाठी ही चाल पुन्हा करा। त्या वाटा सहसा पहिल्या पाऊलावरच फुटतात।

ती फूट हाच उत्तर देण्यायोग्य प्रश्न आहे। साइट VPN तेव्हाच अनावश्यक असते जेव्हा त्या दुसऱ्या चालीतील प्रत्येक चॅनेलकडे स्वतंत्रपणे उभी राहणारी प्रवेश आणि अधिकृतता धोरणे असतात।

ॲप लॉगिन कधीही व्यापत नसलेली पाच चॅनेल

खालील तक्ता हा इन्व्हेंटरी नमुना आहे, तैनाती तपासणी यादी नाही। दुसरा स्तंभ तुमचे वातावरण आज प्रत्यक्षात जे लागू करते त्याने भरा।

ChannelAccess decision to identify
Application APIAccepted TLS peer, application identity, permitted operations
Operating-system administrationApproved entry path, administrative identity, host permissions
Database maintenanceDatabase identity, protected connection, authorized maintenance role
Backup and restoreService identity, allowed source, access to stored copies
Cloud control planeAccount and role permissions governing infrastructure changes

एकच ओळख प्रदाता सामायिक करून या अधिकृतता एकत्र होत नाहीत। API विनंती पाठवू शकणारा वापरकर्ता यामुळे VM डिस्क बदलण्यास किंवा ॲपच्या क्रेडेन्शियल्सने डेटाबेस पुनर्संचयित करण्यास अधिकृत होत नाही। NIST शून्य-विश्वास स्थापत्यरचना सारांशात नेमक्या याच कारणासाठी संसाधन प्रमाणीकरण आणि अधिकृतता हे नेटवर्क स्थानापासून वेगळे ठेवते।

तिकीट वाचू शकणारा सपोर्ट अभियंता यामुळे त्याच्या मागील होस्टवर कन्सोल उघडण्यास अधिकृत होत नाही।

मार्ग तेव्हाच खरा असतो जेव्हा पर्याय बंद राहतो

खाजगी प्रशासकीय श्रोत्यांपर्यंत पोहोच मर्यादित करणे हा साइट VPNचा कायदेशीर पर्याय आहे, परंतु मर्यादा लागू केली पाहिजे, केवळ रेखाटली नाही। नेहमीचा अपयश म्हणजे कोणालाही आठवण नसलेला पर्यायी श्रोता: सर्व इंटरफेसना अजूनही जोडलेली सेवा, कंत्राटदारासाठी उघडलेला सुरक्षा गट नियम, इंटरनेटवरून पोहोचण्यायोग्य व्यवस्थापन पोर्ट।

आकृती नाही, श्रोते तपासा। होस्टवर ss -ltnp वापरून प्रत्यक्षात काय जोडले आहे त्याची यादी करा आणि प्रशासकीय पोर्ट खाजगी पत्त्यावर आहेत याची खात्री करा। क्लाउड कन्सोलमध्ये कार्यभार उपजाळासाठी येणारे नियम वाचा आणि कोणत्याही प्रशासकीय गोष्टीवर 0.0.0.0/0 शोधा। नंतर खाजगी मार्गाच्या बाहेरून कनेक्शन वापरून पहा, कारण ती चाचणीच प्रश्नाचे उत्तर देते।

SSH वर एकही जागतिक-खुला नियम बोगदा रचनेचे प्रत्येक तर्क रद्द करतो।

रचना तुलना करण्यापूर्वी नकाशा लिहा

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

नंतर प्रत्येक चॅनेलसाठी एक परवानगी आणि एक नकार पडताळा। परवानगी सिद्ध करते की इच्छित ओळख इच्छित मार्गाने संसाधनापर्यंत पोहोचू शकते। नकार सिद्ध करतो की समान ओळख पोहोचू शकत नाही, आणि हीच ती चाचणी लोक वगळतात, म्हणूनच पर्यायी श्रोते ऑडिटमधून टिकतात। प्रस्तावित रचनेची तुलना या निकालांशी करा, ॲपच्या TLS संरचनेशी नाही, जिने यापैकी एकही कधी तपासले नाही।

साइट VPN अजूनही कुठे आपले स्थान मिळवते

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

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

कामाचा क्रम: इन्व्हेंटरी पूर्ण करा, पर्याय बंद करा, प्रत्येक ओळीसाठी एक नकार पडताळा, आणि त्यानंतरच बोगदा काढून टाका। एखादी ओळ नकार निर्माण करू शकत नसेल, तर करू शकेपर्यंत खाजगी मार्ग ठेवा।

संबंधित लेख