गेटवे होस्टको प्रमाणपत्र अझै मान्य हुँदै त्यसमा सम्झौता भएको मानौं। आगन्तुकले कुन पृष्ठहरू अनुरोध गर्न सक्छ भन्ने निर्धारण गर्ने हरेक नियम लागू रहन्छ, र ती नियममध्ये कुनैले पनि आक्रमणकारीले अहिले त्यो होस्टबाट डेटाबेस सबनेटतर्फ खोल्ने जडानलाई सीमित गर्दैन। यही खाडलका कारण केवल-वेब प्रवेश बिन्दु विभाजित नेटवर्कसँग एउटै दाबी होइन। दुवै दाबीलाई फरक सुरुवात बिन्दुबाट छुट्टाछुट्टै समीक्षा चाहिन्छ, तीमध्ये कुनैलाई पनि इमानदारीपूर्वक राख्नुअघि।

दुई दाबी, र तीमध्ये एउटा मात्र आगन्तुकबाट सुरु हुन्छ

पहिलो दाबी एक व्यक्तिबारे हो: ब्राउजर र मान्य सत्र भएको आगन्तुकले एउटा अनुप्रयोग खोल्न सक्छ, त्यसभन्दा बढी केही होइन। केवल-वेब प्रवेश बिन्दुले त्यो दाबीलाई राम्रो जवाफ दिन्छ, किनकि आगन्तुकले मार्ग नभई पृष्ठ प्राप्त गर्छ। त्यो जवाफ राख्न लायक छ, र अधिकांश रेखाचित्रहरूले अभिलेख गर्ने एकमात्र दाबी पनि त्यही हो।

दोस्रो दाबी एक घटकबारे हो: गेटवे, वा त्यसपछाडिको अनुप्रयोग प्रक्रिया, अरू कसैको नियन्त्रणमा छ भनी मानिन्छ। त्यो मान्यताबाट प्रश्न कुन URL अनुमति छन् भन्नेबाट प्रक्रिया अझै कुन गन्तव्य र पहिचानसम्म पुग्न सक्छ भन्नेमा बदलिन्छ।

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

एक कार्यान्वित खर्च सेवा, र त्यो हार्ने दुई तरिका

एउटा खर्च सेवा लिनुहोस्: 10.60.4.10 मा रहेको सार्वजनिक गेटवेले कर्मचारीहरूलाई प्रमाणीकरण गर्छ र स्वीकृत अनुरोधहरू पोर्ट 8443 को अनुप्रयोग श्रोतामा पठाउँछ, र त्यो अनुप्रयोगले expenses_app भूमिकाका रूपमा 10.60.4.20:5432 मा रहेको एउटा PostgreSQL श्रोतासम्म पुग्छ। कर्मचारीहरूले सामान्य आन्तरिक पहुँच पाउने हेतु छैन। सामान्य सञ्चालनमा डिजाइनले साँच्चै डेटाबेस श्रोतालाई कतै पनि प्रकाशित नगरी अनुप्रयोग-विशिष्ट प्रवेश दिन्छ। ठेगानाहरू महत्त्वपूर्ण छन्, किनकि यस लेखमा हरेक पछिल्लो जाँचले तिनीहरूलाई नाम दिन्छ।

अब गेटवेलाई विश्वसनीय समूहबाट हटाउनुहोस्। 10.60.4.10 को प्रक्रिया आक्रमणकारीको भएपछि त्यो कुन गन्तव्यसम्म पुग्न सक्छ? आगन्तुकहरूलाई सीमित गर्ने URL फिल्टरले गेटवे होस्टले डेटाबेस सबनेटतर्फ खोल्ने जडानबारे केही भन्दैन।

बरु अनुप्रयोग प्रक्रिया हटाउनुहोस्, र अधिकारको स्वरूप बदलिन्छ: expenses_app भूमिका, त्यो सर्भरले पुग्न सक्ने सेवाहरू, र त्यो खाताले पढ्न सक्ने फाइलहरू। दुवै अवस्थामा अगाडिको ढोका केवल-वेब रहन सक्छ, जबकि ब्याकएन्डको सीमा अनुपस्थित हुन्छ। त्यसैले अगाडिको ढोकाको लेबल दुई प्रश्नमध्ये कुनैको उत्तर होइन।

हरेक पक्षसँग वास्तवमा रहेको अधिकारको नक्सा बनाउनुहोस्

इच्छित अनुमतिका रूपमा लेखिएको सम्झौताले तपाईंलाई डिजाइन दोहोर्याउँछ। यसलाई धारण गरिएको अधिकार, अतिरिक्तलाई खण्डन गर्ने जाँच र त्यो जाँचको मालिकका रूपमा लेख्नुहोस्, अनि हरेक पंक्ति परीक्षणयोग्य हुन्छ। यो तालिका माथिको उदाहरणका लागि प्रस्ताव हो, उत्पादन दाबी होइन:

ComponentAuthority it actually holdsCheck that proves the denialOwner of the check
Identity providerIssues assertions and session cookies, and holds no network path of its ownA request to the application URL without a session is redirected to the login pageIdentity team
Public gateway hostTCP reachability to whatever its routing table and egress rules permitAn egress rule drops 10.60.4.20:5432 and the probe reports the port filteredNetwork platform team
Application roleSQL privileges granted to expenses_app inside the expenses databaseA privilege query shows no ownership or create right on any other schemaApplication team
Database listenerAccepts connections only from the source ranges named in its host-based rulesA connection from an unlisted address is refused before authenticationDatabase administrator
Management pathAdministrative access reserved for patching, monitoring and recoveryA staff workstation cannot reach the administrative port or jump through itPlatform owner

स्वामित्व अधिकारको पछि लाग्छ। पहिचान टोली दाबीहरूको, नेटवर्क प्लेटफर्म टोली मार्गहरूको, अनुप्रयोग टोली डेटाबेस भूमिकाको, डेटाबेस प्रशासक श्रोता र त्यसका होस्ट-आधारित नियमहरूको, र प्लेटफर्म मालिक व्यवस्थापन तहको मालिक हो। मालिक नभएको अस्वीकृति कागजातको वाक्य हो, नियन्त्रण होइन।

यो विभाजनले दोहोरो गणना पनि रोक्छ। पोर्ट प्रतिबन्धले तालिका विशेषाधिकार व्यक्त गर्न सक्दैन, र डेटाबेस भूमिकाले कुनै होस्टलाई असम्बन्धित सबनेटतर्फ सकेट खोल्नबाट रोक्न सक्दैन।

गेटवे कहाँसम्म पुग्न सक्छ भनी दाबी गर्नुको सट्टा गन्नुहोस्

सीमाको दाबी त्यसपछाडिको गणनाजत्तिकै राम्रो हुन्छ। गेटवे होस्टमा तीन आदेशले मार्ग छनोट, प्रत्यक्ष जाँच र निर्गम नीति समेट्छन्:

ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter output

आउटपुट त्यही क्रममा पढ्नुहोस्। मार्गले 10.60.4.20 त्यो होस्टबाटै छानिन्छ कि छैन भन्छ; जाँचले श्रोता जवाफ दिन्छ कि दिँदैन भन्छ; नियमको सूचीले नीतिले प्याकेट रोक्छ कि त्यसको बाटोमा कहिल्यै केही थिएन भनी देखाउँछ।

अनुप्रयोग होस्टबाट गणना दोहोर्याउनुहोस्। त्यहाँबाट डेटाबेस पक्ष अनुप्रयोग भूमिकाका रूपमा चलाइएको एउटा प्रश्न हो:

psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'

अर्को स्किमा पढ्न नसक्ने भूमिकाअन्तर्गत सफल जडान मालिक भूमिकाअन्तर्गतको सफल जडानभन्दा फरक नतिजा हो। दोस्रो मात्र एउटा खोज हो।

अस्वीकृतिहरू अभिलेख गर्नुहोस्, त्यसपछि समीक्षामा मिति राख्नुहोस्

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

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

समीक्षामा मिति राख्नुहोस् र त्यसका मालिकको नाम भन्नुहोस्। गेटवे इमेज, राउटिङ तालिका वा अनुप्रयोग भूमिकामा कुनै पनि परिवर्तनपछि गणना र विशेषाधिकार प्रश्न फेरि चलाउनुहोस्।

सम्बन्धित लेखहरू