EC2 बाट निजी RDS: उही VPC, peering वा अरू केही?

विकासकर्ताको ल्यापटप कर्मचारी VPN मार्फत निजी RDS इन्स्ट्यान्समा पुग्छ, तर EC2 मा रहेको अनुप्रयोग कुनै पनि हिसाबले जोडिन सक्दैन। यो बिग्रिएको डिप्लोयमेन्ट होइन। ल्यापटपमा EC2 इन्स्ट्यान्सले कहिल्यै नपाउने टनेल छ, र RDS मा «निजी» भन्नाले डेटाबेसको सार्वजनिक अन्त्यबिन्दु छैन भन्ने बुझिन्छ, मानव VPN प्रयोगकर्ताहरू मात्र अनुमति प्राप्त कलर हुन् भन्ने होइन। अनुप्रयोगलाई आफ्नै अधिकृत मार्ग, सुरक्षा समूहसँग आफ्नै सम्बन्ध र डेटाबेसमा आफ्नै पहिचान चाहिन्छ, र यी तीन छान्ने क्रमले डिबगिङको धेरै भाग बचाउँछ। पहिले मार्ग तय गर्नुहोस्, त्यसपछि अनुमतिहरू, र त्यसपछि आफ्नो डेस्कबाट होइन, डिप्लोय गरिएको वातावरणबाट प्रमाणित गर्नुहोस्।

ल्यापटपको VPN अनुप्रयोगको मार्ग होइन

कर्मचारी VPN ले मानिसहरूका लागि जे गरे पनि, त्यो इन्स्ट्यान्सका लागि केही गर्दैन, जबसम्म त्यो इन्स्ट्यान्स स्पष्ट रूपमा उही नेटवर्क मार्गको भाग होइन। निजी सबनेटमा रहेको EC2 इन्स्ट्यान्स VPC राउटिङ, सुरक्षा समूह र नेटवर्क ACL मार्फत RDS मा पुग्छ। त्यो मानिसको टनेल, मानिसको सत्र वा मानिसको प्रमाणहरू प्राप्त गर्दैन, र गर्नु हुँदैन: अवलोकनविहीन अनुप्रयोग जडान र कर्मचारीको टाढाको पहुँच स्वतन्त्र रूपमा सञ्चालनयोग्य हुनुपर्छ।

यो स्वतन्त्रता एक विशेषता हो। VPN डाउन हुँदा अनुप्रयोग काम गरिरहन्छ। अनुप्रयोगले गलत व्यवहार गर्दा कसैले पनि आफ्नो टाढाको पहुँच गुमाउँदैन। दुवैलाई एउटै मार्गमा मिलाउने डिजाइनहरू सामान्यतया घटनाको क्रममा, सबैभन्दा नराम्रो क्षणमा पत्ता लाग्छन्।

निर्णय 1: उही VPC, सीधा मार्ग

जब अनुप्रयोग र डेटाबेस एउटै VPC मा सीधा राउटिङसहित र तिनीहरूबीच कुनै निरीक्षण मध्यस्थ उपकरण बिना हुन्छन्, मार्ग सरल हुन्छ र सुरक्षा समूह सन्दर्भ उपलब्ध सबैभन्दा शक्तिशाली उपकरण हो। अनुप्रयोगलाई आफ्नै समूह दिनुहोस्, त्यसपछि ठेगाना दायराबाट होइन, त्यही समूहबाट डेटाबेस पोर्टको अनुमति दिनुहोस्:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

पोर्ट उदाहरणका लागि मात्र हो र इन्जिनसँग मिल्नुपर्छ। समूह सन्दर्भले अनुप्रयोगका इन्स्ट्यान्सबाट ट्राफिक अधिकृत गर्छ; यसले तिनका नियमहरू प्रतिलिपि गर्दैन र डेटाबेस लगइन बनाउँदैन। दुई अलग समस्या, दुई अलग समाधान।

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

निर्णय 2: अर्को VPC वा अर्को खाता

यदि अनुप्रयोग अर्को VPC मा छ भने, नेटवर्कका मालिकहरूले समर्थित निजी इन्टरकनेक्ट छान्छन्: peering, ट्रान्जिट डिजाइन वा साझा VPC व्यवस्था। त्यसपछि राउटिङका दुवै दिशा हुनुपर्छ, नाम समाधान RDS अन्त्यबिन्दुका लागि काम गर्नुपर्छ, र डेटाबेस नीतिले मूल्याङ्कन गर्ने स्रोत वास्तवमा आउनेसँग मिल्नुपर्छ। खाताका नाम मिल्नु वा साझा बिलिङ सम्बन्धले यीमध्ये केही पनि दिँदैन।

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

हराएको मार्गलाई डेटाबेस सार्वजनिक रूपमा पहुँचयोग्य बनाएर समाधान नगर्नुहोस्। त्यो फरक मालिक भएको फरक एक्सपोजर निर्णय हो, र सामान्यतया परिणामबाट सबैभन्दा टाढा रहेको व्यक्तिले त्यो सुझाव दिन्छ।

निर्णय 3: डेटाबेसले कुन पहिचान स्वीकार गर्छ

नेटवर्क पहुँच र डेटाबेस प्रमाणीकरण अलग तहहरू हुन्, र तिनलाई मिसाउँदा सबैभन्दा भ्रमित गर्ने त्रुटिहरू बन्छन्। इन्स्ट्यान्सको भूमिका AWS API कल गर्नका लागि AWS पहिचान हो। त्यो डेटाबेस प्रयोगकर्ता होइन। IAM डेटाबेस प्रमाणीकरण एक समर्थित सुविधा हो जहाँ इन्जिन र कन्फिगरेसनले अनुमति दिन्छ, र यो अझै पनि डेटाबेस प्रयोगकर्तामा म्यापिङ हो, त्यसको विकल्प होइन।

अनुप्रयोगको कन्फिगरेसनमा एउटा खोजबाट समातिएको ठेगानाको सट्टा RDS अन्त्यबिन्दुको नाम प्रयोग गर्नुहोस्। Multi-AZ फेलओभरले त्यो नामपछाडिको ठेगाना बदल्छ, र IP मा पिन गरिएको अनुप्रयोग ठ्याक्कै आवश्यक पर्ने क्षणमा असफल हुन्छ। त्रुटि हराउन इन्जिनको TLS प्रमाणीकरण बन्द गर्नुको सट्टा सक्रिय राख्नुहोस्, किनभने प्रमाणीकरण असफलताले तपाईं पुगेको अन्त्यबिन्दुबारे केही बताउँछ।

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

डिप्लोय गरिएको वातावरणबाट प्रमाणित गर्नुहोस्

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

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

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