मार्गदर्शिका

बड़े पैमाने पर या हाइब्रिड क्लाउड डिप्लॉयमेंट के लिए IP एड्रेसिंग की योजना बनाएं।

→कस्टम-मोड VPCs का उपयोग करें। ऑन-प्रेम (अक्सर 10.0.0.0/8) के साथ विरोधाभास से बचने के लिए नॉन-ओवरलैपिंग RFC 1918 CIDR ब्लॉक (जैसे, 172.16.0.0/12) आवंटित करें। GKE पॉड सेकेंडरी रेंज के लिए 100.64.0.0/10 का उपयोग करें।

क्यों: भविष्य की हाइब्रिड कनेक्टिविटी के लिए ऑन-प्रेम के साथ IP विरोधाभास से बचाता है और एड्रेस स्पेस पर पूर्ण नियंत्रण प्रदान करता है, जो स्केल और महंगी री-IPिंग से बचने के लिए आवश्यक है।

संदर्भ↗

नेटवर्क प्रबंधन और साझा सेवाओं को केंद्रीकृत करते हुए कई किरायेदारों/वातावरणों (dev, prod) के लिए नेटवर्क अलगाव प्रदान करें।

→Shared VPC का उपयोग करें। होस्ट प्रोजेक्ट में VPC, सबनेट, फ़ायरवॉल और इंटरकनेक्ट होते हैं। Tenants/environments होस्ट प्रोजेक्ट से जुड़े सर्विस प्रोजेक्ट होते हैं।

क्यों: होस्ट प्रोजेक्ट में नेटवर्क प्रशासन को केंद्रीकृत करता है जबकि संसाधन प्रबंधन को सर्विस प्रोजेक्ट को सौंपता है। एक संगठन के भीतर कई प्रोजेक्ट के लिए VPC peering की तुलना में अधिक स्केलेबल और नियंत्रणीय।

संदर्भ↗

VPC-नेटिव नेटवर्किंग का उपयोग करके बड़े GKE क्लस्टर के लिए IP एड्रेसिंग की योजना बनाएं।

→एक कस्टम-मोड VPC में, तीन CIDR रेंज के लिए योजना बनाएं: नोड्स के लिए एक प्राथमिक रेंज, पॉड्स के लिए एक सेकेंडरी रेंज, और सेवाओं के लिए एक और। विस्तार के लिए, discontiguous मल्टी-पॉड CIDR का उपयोग करें।

क्यों: VPC-नेटिव नेटवर्किंग के लिए पॉड और सेवाओं के लिए समर्पित, नॉन-ओवरलैपिंग सेकेंडरी रेंज की आवश्यकता होती है। उचित आकार IP exhaustion को रोकता है, जो बड़े क्लस्टर में एक सामान्य और विघटनकारी समस्या है।

संदर्भ↗

बिना बाहरी IP वाले VMs को Google Cloud APIs (जैसे, Cloud Storage, BigQuery) तक पहुंचने की आवश्यकता है।

→सबनेट पर Private Google Access सक्षम करें। वैकल्पिक रूप से, VPC-SC लागू करने के लिए DNS को `*.googleapis.com` को `restricted.googleapis.com` (199.36.153.4/30) पर रिज़ॉल्व करने के लिए कॉन्फ़िगर करें।

क्यों: VMs पर सार्वजनिक IP की आवश्यकता के बिना Google के आंतरिक नेटवर्क पर Google APIs तक ट्रैफिक को रूट करता है। `restricted.googleapis.com` का उपयोग डेटा exfiltration सुरक्षा की एक परत जोड़ता है।

संदर्भ↗

अपने VPC में एक सेवा के लिए उपभोक्ताओं (भागीदारों, अन्य BUs) के लिए निजी एक्सेस प्रदान करें, जिनके VPCs में ओवरलैपिंग IP रेंज हैं।

→एक Private Service Connect (PSC) सर्विस अटैचमेंट का उपयोग करके सेवा (एक Internal Load Balancer के माध्यम से) प्रकाशित करें। उपभोक्ता अपने स्वयं की रेंज से एक IP के साथ अपने VPC में एक PSC एंडपॉइंट बनाते हैं।

क्यों: PSC प्रोड्यूसर और कंज्यूमर नेटवर्क को डीकपल करता है, ओवरलैपिंग IP को संभालने के लिए NAT का उपयोग करता है। यह सुरक्षित, सर्विस-लेवल एक्सेस प्रदान करता है, न कि VPC peering जैसी पूर्ण नेटवर्क कनेक्टिविटी।

संदर्भ↗

केंद्रीकृत प्रबंधन और कनेक्टिविटी के लिए हब-एंड-स्पोक टोपोलॉजी में बड़ी संख्या (50+) में VPCs और/या ऑन-प्रेम साइटों को कनेक्ट करें।

→Network Connectivity Center का उपयोग करें। हब को कॉन्फ़िगर करें और VPCs को VPC स्पोक्स के रूप में और ऑन-प्रेम कनेक्शन (VPN/Interconnect) को हाइब्रिड स्पोक्स के रूप में अटैच करें।

क्यों: NCC बड़े पैमाने पर हब-एंड-स्पोक टोपोलॉजी के लिए Google का प्रबंधित समाधान है, जो रूट प्रबंधन को सरल बनाता है और VPC peering की 25-पीयर सीमा से आगे बढ़ता है।

बढ़ी हुई सुरक्षा के लिए एक GKE क्लस्टर डिप्लॉय करें जहां नोड्स और कंट्रोल प्लेन में कोई सार्वजनिक IP एड्रेस न हो।

→एक Private GKE क्लस्टर बनाएं। यह नोड्स को केवल आंतरिक IP आवंटित करता है और कंट्रोल प्लेन के लिए एक निजी एंडपॉइंट बनाता है। कंट्रोल प्लेन एक्सेस को प्रतिबंधित करने के लिए अधिकृत नेटवर्क कॉन्फ़िगर करें।

क्यों: एक निजी क्लस्टर कंट्रोल प्लेन और नोड्स को सार्वजनिक इंटरनेट से हटा देता है, जिससे हमले की सतह काफी कम हो जाती है। सभी प्रबंधन और वर्कलोड ट्रैफिक निजी नेटवर्क पर बना रहता है।

सर्वरलेस वर्कलोड (Cloud Run, Functions) को VPC के अंदर संसाधनों (जैसे, Cloud SQL, Memorystore) तक पहुंचने की आवश्यकता है।

→लक्ष्य VPC में एक Serverless VPC Access कनेक्टर बनाएं। ईग्रेस ट्रैफिक के लिए इस कनेक्टर का उपयोग करने के लिए सर्वरलेस सेवा को कॉन्फ़िगर करें।

क्यों: कनेक्टर एक प्रॉक्सी के रूप में कार्य करता है, जिससे सर्वरलेस सेवाओं (जो Google-प्रबंधित वातावरण में चलती हैं) को आंतरिक IP का उपयोग करके ग्राहक-प्रबंधित VPC में ट्रैफिक भेजने की अनुमति मिलती है।

एक एप्लिकेशन (जैसे, HPC, वित्तीय ट्रेडिंग) को VMs के समूह के बीच न्यूनतम नेटवर्क लेटेंसी की आवश्यकता होती है।

→एक कॉम्पैक्ट प्लेसमेंट पॉलिसी बनाएं और इसे VMs पर लागू करें। Tier_1 नेटवर्किंग वाले मशीन प्रकारों का उपयोग करें।

क्यों: एक ही नेटवर्क रैक के भीतर VMs को सह-स्थानित करने से नेटवर्क हॉप्स और भौतिक दूरी कम होती है, जिससे मानक VM प्लेसमेंट की तुलना में लेटेंसी काफी कम हो जाती है।

माइक्रोसेवाओं के लिए एक ज़ीरो-ट्रस्ट सुरक्षा मॉडल लागू करें, जिसके लिए मजबूत पहचान, एन्क्रिप्टेड संचार (mTLS), और ठीक-ठाक प्रमाणीकरण की आवश्यकता होती है।

→Anthos Service Mesh डिप्लॉय करें। सभी सर्विस-से-सेवा संचार के लिए स्वचालित mTLS सक्षम करें। अनुमत संचार को परिभाषित करने के लिए `AuthorizationPolicy` संसाधनों का उपयोग करें।

क्यों: एक सर्विस मेश सुरक्षा को अंतर्निहित नेटवर्क से डीकपल करता है, वर्कलोड पहचान, पारदर्शी mTLS, और L7 प्रमाणीकरण प्रदान करता है, जो ज़ीरो-ट्रस्ट आर्किटेक्चर के मुख्य सिद्धांत हैं।

सार्वजनिक IP वाले वर्कलोड (VMs, GKE पॉड) को बाहरी APIs के लिए आउटबाउंड कनेक्शन के लिए एक स्थिर, अनुमानित स्रोत IP की आवश्यकता होती है जो allow-listing का उपयोग करते हैं।

→Cloud NAT डिप्लॉय करें। "मैनुअल NAT IP आवंटन" विकल्प का उपयोग करें और NAT गेटवे को आरक्षित स्थिर बाहरी IP पते असाइन करें।

क्यों: मैनुअल आवंटन के साथ Cloud NAT स्थिर ईग्रेस IP का एक साझा पूल प्रदान करता है। यह IP से वर्कलोड को डीकपल करता है, जिससे बाहरी allow-lists को अपडेट करने की आवश्यकता के बिना स्केलिंग की अनुमति मिलती है।

VPC peering स्थापित है लेकिन VMs peered VPCs के बीच संवाद नहीं कर सकते।

→सत्यापित करें कि *दोनों* VPCs में फ़ायरवॉल नियम दूसरे VPC की IP रेंज से इनग्रेस ट्रैफिक की अनुमति देते हैं। peering कनेक्शन केवल रूटिंग स्थापित करता है; यह अंतर्निहित रूप से फ़ायरवॉल अनुमतियों को नहीं बनाता है।

क्यों: एक सामान्य गलती यह मान लेना है कि peering फ़ायरवॉल पोर्ट खोलता है। अंतर्निहित deny-all इनग्रेस नियम ट्रैफिक को तब तक ब्लॉक करता है जब तक एक स्पष्ट अनुमति नियम नहीं बनाया जाता है।

एक Shared VPC में, एक टीम/सेवा प्रोजेक्ट को पूरे VPC के बजाय केवल एक विशिष्ट सबनेट का उपयोग करने की अनुमति दें।

→होस्ट प्रोजेक्ट में, सर्विस प्रोजेक्ट की पहचान (जैसे, सर्विस अकाउंट, ग्रुप) को सबनेट-स्तर के संसाधन पर `compute.networkUser` IAM भूमिका प्रदान करें।

क्यों: IAM भूमिकाओं को विशिष्ट संसाधनों तक सीमित किया जा सकता है। `compute.networkUser` को सबनेट स्तर पर लागू करने से न्यूनतम-विशेषाधिकार लागू होता है, जिससे केवल उस सबनेट का उपयोग करने की अनुमति मिलती है।

Compute Engine पर एक मल्टी-टियर एप्लिकेशन (जैसे, वेब, ऐप, db) के लिए माइक्रोसेगमेंटेशन लागू करें।

→VMs को उनके टियर (जैसे, `web-server`) के आधार पर नेटवर्क टैग असाइन करें। फ़ायरवॉल नियम बनाएं जो इन टैग का उपयोग स्रोत और लक्ष्य विशिष्टताओं के रूप में करते हैं।

क्यों: टैग IP-आधारित नियमों के लिए एक लचीला, स्केलेबल विकल्प प्रदान करते हैं। फ़ायरवॉल पॉलिसी एक टियर में VMs की संख्या या IP से स्वतंत्र होती है।

लॉग वॉल्यूम और स्टोरेज लागत को कम करते हुए अनुपालन/ऑडिटिंग के लिए ट्रैफिक मेटाडेटा कैप्चर करें।

→एक लंबे एग्रीगेशन इंटरवल (जैसे, 10 मिनट), एक कम सैंपलिंग दर (जैसे, 0.5), और अनावश्यक फ़ील्ड को बाहर करने के लिए मेटाडेटा फ़िल्टरिंग के साथ VPC Flow Logs सक्षम करें।

क्यों: डिफ़ॉल्ट सेटिंग्स भारी मात्रा में डेटा उत्पन्न करती हैं। इन मापदंडों को ट्यून करने से लागत में काफी कमी आती है जबकि अधिकांश ऑडिट उपयोग मामलों के लिए पर्याप्त दृश्यता प्रदान होती है।

स्वचालित फ़ेलओवर के साथ सबसे नज़दीकी स्वस्थ बैकएंड के लिए उपयोगकर्ताओं को रूट करते हुए, कम लेटेंसी के साथ एक वैश्विक एप्लिकेशन वितरित करें।

→एक Global External Application Load Balancer (या गैर-HTTP के लिए TCP/SSL Proxy LB) का उपयोग करें। कई क्षेत्रों में बैकएंड सेवाओं/NEGs को कॉन्फ़िगर करें। Premium Tier नेटवर्किंग का उपयोग करें।

क्यों: लोड बैलेंसर का anycast IP उपयोगकर्ताओं को निकटतम Google एज PoP पर निर्देशित करता है। ट्रैफिक तब Google के निजी बैकबोन पर सबसे नज़दीकी स्वस्थ बैकएंड तक इष्टतम प्रदर्शन के लिए यात्रा करता है।

संदर्भ↗

URL पाथ या होस्टनाम के आधार पर आंतरिक ट्रैफिक को रूट करें, SSL समाप्ति के साथ, केवल VPC के भीतर या ऑन-प्रेम से सुलभ।

→एक Regional Internal Application Load Balancer का उपयोग करें। होस्ट/पाथ नियमों के आधार पर ट्रैफिक को निर्देशित करने के लिए एक URL मैप कॉन्फ़िगर करें। एक प्रॉक्सी-ओनली सबनेट की आवश्यकता होती है।

क्यों: यह Google का प्रबंधित L7 इंटरनल लोड बैलेंसर है। यह L4 Internal Passthrough Network LB के साथ उपलब्ध न होने वाली उन्नत रूटिंग सुविधाएँ प्रदान करता है।

निजी या उपयोगकर्ता-विशिष्ट सामग्री को सार्वजनिक किए बिना उसे कैश और सर्व करने के लिए Cloud CDN का उपयोग करें।

→एक निजी बैकएंड (जैसे, GCS बकेट) पर Cloud CDN सक्षम करें। उपयोगकर्ताओं को अस्थायी, प्रमाणीकृत पहुंच प्रदान करने के लिए अपने एप्लिकेशन में Cloud CDN Signed URLs या Signed Cookies जनरेट करें।

क्यों: Signed URLs/Cookies एक सुरक्षित टोकन प्रदान करते हैं जिसे Cloud CDN एक कैश किए गए ऑब्जेक्ट को सर्व करने से पहले मान्य करता है, सख्त एक्सेस कंट्रोल बनाए रखते हुए एज कैशिंग का लाभ उठाता है।

एक ऑन-प्रेम नेटवर्क और एक GCP VPC के बीच द्वि-दिशात्मक DNS रिज़ॉल्यूशन सक्षम करें।

→1) ऑन-प्रेम GCP को रिज़ॉल्व करता है: एक Cloud DNS इनबाउंड सर्वर पॉलिसी बनाएं। ऑन-प्रेम DNS को इनबाउंड फॉरवर्डर IP पर फॉरवर्ड करने के लिए कॉन्फ़िगर करें। 2) GCP ऑन-प्रेम को रिज़ॉल्व करता है: एक Cloud DNS फॉरवर्डिंग ज़ोन बनाएं जो ऑन-प्रेम DNS सर्वर की ओर इशारा करता है।

क्यों: यह मानक दो-भाग कॉन्फ़िगरेशन हाइब्रिड वातावरण के लिए सहज, निजी नाम रिज़ॉल्यूशन प्रदान करता है, जो एप्लिकेशन इंटरऑपरेबिलिटी के लिए एक महत्वपूर्ण घटक है।

अनावश्यक URL विविधताओं (जैसे, ट्रैकिंग पैरामीटर) के कारण Cloud CDN कैश हिट अनुपात कम है।

→बैकएंड सेवा के लिए एक कस्टम कैश की पॉलिसी कॉन्फ़िगर करें। अनावश्यक क्वेरी पैरामीटर, कुकीज़ और हेडर को कैश की से बाहर रखें।

क्यों: डिफ़ॉल्ट रूप से, पूर्ण URL कैश की होता है। अप्रासंगिक मापदंडों को छोड़कर की को सामान्य बनाने से कैश विखंडन को रोका जा सकता है और हिट अनुपात में नाटकीय रूप से सुधार होता है।

आंतरिक क्लाइंट के लिए एक DNS नाम को आंतरिक IP पर और बाहरी क्लाइंट के लिए सार्वजनिक IP पर रिज़ॉल्व करें।

→डोमेन के लिए एक Cloud DNS निजी ज़ोन (आपके VPC के लिए दृश्यमान) आंतरिक IP रिकॉर्ड के साथ बनाएं। सार्वजनिक IP रिकॉर्ड के साथ एक मिलान वाला Cloud DNS सार्वजनिक ज़ोन बनाएं।

क्यों: Cloud DNS स्वचालित रूप से अधिकृत VPC के भीतर क्लाइंट को निजी ज़ोन से प्रतिक्रिया देता है, और बाकी सभी को सार्वजनिक ज़ोन से प्रतिक्रिया देता है।

एक क्षेत्र में एक आंतरिक एप्लिकेशन को अन्य क्षेत्रों में क्लाइंट (VMs, ऑन-प्रेम) द्वारा सुलभ होने की आवश्यकता है।

→Internal TCP/UDP Load Balancer या Internal Application Load Balancer के फॉरवर्डिंग नियम पर "Global Access" विकल्प सक्षम करें।

क्यों: डिफ़ॉल्ट रूप से, आंतरिक LBs क्षेत्रीय होते हैं। Global Access उन्हें VPC नेटवर्क के भीतर किसी भी क्षेत्र से सुलभ बनाता है, जिससे मल्टी-रीजन आंतरिक सेवा आर्किटेक्चर सरल हो जाता है।

ऑन-प्रेम और GCP के बीच उच्च उपलब्धता (99.99% SLA), उच्च-बैंडविड्थ (10G+) कनेक्टिविटी स्थापित करें।

→न्यूनतम चार Dedicated Interconnect कनेक्शन प्रदान करें, एक मेट्रो में दो और दूसरे में दो, प्रत्येक मेट्रो जोड़ी अलग-अलग एज उपलब्धता डोमेन में। BGP कॉन्फ़िगर करें।

क्यों: 99.99% SLA के लिए अलग-अलग महानगरीय क्षेत्रों और विफलता डोमेन (एज उपलब्धता डोमेन) में अतिरेक की आवश्यकता होती है।

संदर्भ↗

मध्यम बैंडविड्थ (< 6 Gbps) के साथ एक एन्क्रिप्टेड, विश्वसनीय (99.9% या 99.99% SLA), और जल्दी से डिप्लॉय करने योग्य हाइब्रिड कनेक्शन की आवश्यकता है।

→डायनामिक रूटिंग के लिए BGP के साथ HA VPN का उपयोग करें। 99.99% SLA के लिए, दो HA VPN गेटवे का उपयोग करें। 99.9% SLA के लिए, दो टनल वाले एक सिंगल गेटवे का उपयोग करें।

क्यों: HA VPN Interconnect की तुलना में सेटअप करना तेज़ है, एक मजबूत SLA प्रदान करता है, और कई उपयोग मामलों के लिए पर्याप्त बैंडविड्थ प्रदान करता है, जिससे यह गैर-भौतिक कनेक्शन के लिए डिफ़ॉल्ट विकल्प बन जाता है।

अनुपालन के लिए एक Dedicated या Partner Interconnect लिंक से गुजरने वाले सभी ट्रैफिक को एन्क्रिप्ट करें।

→Interconnect पर HA VPN कॉन्फ़िगर करें। HA VPN टनल बनाएं जो उनके अंतर्निहित ट्रांसपोर्ट के लिए Interconnect के VLAN अटैचमेंट का उपयोग करते हैं।

क्यों: यह पैटर्न Interconnect की उच्च बैंडविड्थ और कम लेटेंसी को HA VPN के IPsec एन्क्रिप्शन के साथ जोड़ता है, जिससे दोनों दुनियाओं का सर्वश्रेष्ठ प्रदान किया जाता है।

GCP और एक अन्य प्रमुख क्लाउड प्रदाता (AWS, Azure, OCI) के बीच समर्पित, निजी, उच्च-बैंडविड्थ कनेक्टिविटी स्थापित करें।

→Cross-Cloud Interconnect का उपयोग करें। Google के नेटवर्क और दूसरे क्लाउड प्रदाता के नेटवर्क के बीच एक समर्पित भौतिक कनेक्शन प्रदान करें। Cloud Router के साथ BGP कॉन्फ़िगर करें।

क्यों: क्लाउड के बीच एक सीधा, SLA-समर्थित, कम-लेटेंसी पथ प्रदान करता है, सार्वजनिक इंटरनेट और VPNs के परिवर्तनीय प्रदर्शन से बचता है।

एक GCP क्षेत्र से Interconnect के माध्यम से जुड़ा एक ऑन-प्रेम नेटवर्क को अन्य सभी GCP क्षेत्रों में संसाधनों तक पहुंचने की आवश्यकता है।

→VPC पर "Global" डायनामिक रूटिंग मोड सक्षम करें। Cloud Router तब VPC में सभी सबनेट के लिए मार्गों का विज्ञापन करेगा, न कि केवल अपने स्थानीय क्षेत्र में।

क्यों: ग्लोबल रूटिंग एक एकल हाइब्रिड कनेक्शन बिंदु को Google के पूरे वैश्विक नेटवर्क के लिए ऑन-रैंप के रूप में कार्य करने की अनुमति देता है, जिससे मल्टी-रीजन एक्सेस सरल हो जाता है।

BGP का उपयोग करके redundant हाइब्रिड कनेक्शन (VPN/Interconnect) पर ट्रैफिक पाथ चयन को प्रभावित करें।

→GCP-से-ऑन-प्रेम ट्रैफिक को प्रभावित करने के लिए, ऑन-प्रेम को अधिक विशिष्ट मार्गों का विज्ञापन करने दें या पसंदीदा पाथ के लिए एक छोटा AS_PATH का उपयोग करें। ऑन-प्रेम-से-GCP को प्रभावित करने के लिए, पसंदीदा पाथ के लिए कम MED मान के साथ Cloud Router से विज्ञापन करें।

क्यों: BGP पाथ चयन एक स्पष्ट एल्गोरिथम का पालन करता है। outbound ट्रैफिक के लिए सबसे लंबा प्रीफिक्स मैच महत्वपूर्ण है, जबकि MED इनबाउंड ट्रैफिक निर्णयों को प्रभावित करता है।

एक प्राथमिक Dedicated Interconnect और एक बैकअप HA VPN के बीच सक्रिय/निष्क्रिय फ़ेलओवर कॉन्फ़िगर करें।

→दोनों पर BGP का उपयोग करें। Cloud Router पर, Interconnect पर कम बेस प्राथमिकता (जैसे, 100) के साथ और VPN पर उच्च बेस प्राथमिकता (जैसे, 200) के साथ मार्गों का विज्ञापन करें।

क्यों: GCP कम प्राथमिकता मान (उच्च वरीयता) वाले BGP मार्गों को पसंद करता है। ट्रैफिक प्राथमिक Interconnect का उपयोग करता है। विफलता पर, इसके मार्ग वापस ले लिए जाते हैं, और बैकअप VPN मार्ग सक्रिय हो जाते हैं।

संवेदनशील Google Cloud सेवाओं (जैसे, BigQuery, GCS) से डेटा exfiltration को रोकें, केवल अधिकृत नेटवर्क से पहुंच सुनिश्चित करें।

→VPC Service Controls लागू करें। संवेदनशील डेटा वाले प्रोजेक्ट के चारों ओर एक सर्विस पेरिमीटर बनाएं। अधिकृत स्रोतों (IP रेंज, डिवाइस स्थिति, पहचान) को परिभाषित करने के लिए एक्सेस स्तर कॉन्फ़िगर करें।

क्यों: VPC-SC Google-प्रबंधित सेवाओं के चारों ओर एक वर्चुअल नेटवर्क सीमा बनाता है, जो वैध क्रेडेंशियल्स के साथ भी पेरिमीटर के बाहर से पहुंच को ब्लॉक करता है। एक महत्वपूर्ण डेटा गवर्नेंस नियंत्रण।

संदर्भ↗

एक संगठन में सुसंगत, गैर-अतिव्याप्ति योग्य बेसलाइन फ़ायरवॉल नियमों को लागू करें, जबकि प्रोजेक्ट-स्तर अनुकूलन की अनुमति दें।

→संगठन या फ़ोल्डर स्तर पर Hierarchical Firewall Policies लागू करें। यहां महत्वपूर्ण नियम रखें। निचले-स्तर की नीतियों के लिए मूल्यांकन को सौंपने के लिए `goto_next` कार्रवाई का उपयोग करें।

क्यों: पदानुक्रमित नीतियों का मूल्यांकन VPC-स्तर के नियमों से पहले किया जाता है और प्रोजेक्ट मालिकों द्वारा संशोधित नहीं किया जा सकता है, जिससे केंद्रीकृत शासन सुनिश्चित होता है। `goto_next` लचीलापन प्रदान करता है।

एक वेब एप्लिकेशन को OWASP Top 10 कमजोरियों से बचाएं और प्रति-क्लाइंट IP दर सीमित लागू करें।

→Global External Application LB पर एक Cloud Armor सुरक्षा नीति अटैच करें। प्री-कॉन्फ़िगर किए गए WAF नियम (जैसे, `sqli-v3.3-stable`) लागू करें और एक दर-आधारित नियम जोड़ें।

क्यों: Cloud Armor एज सुरक्षा प्रदान करता है। प्री-कॉन्फ़िगर किए गए WAF नियम प्रबंधित सुरक्षा प्रदान करते हैं, जबकि दर-आधारित नियम DoS और ब्रूट-फोर्स हमलों को कम करते हैं।

लेबलों के आधार पर एक GKE क्लस्टर के भीतर ठीक-ठाक, पॉड-स्तर नेटवर्क सुरक्षा लागू करें।

→GKE क्लस्टर पर Network Policy enforcement सक्षम करें। Kubernetes `NetworkPolicy` संसाधन बनाएं जो लेबल चयनकर्ताओं का उपयोग करके पॉड्स के लिए इनग्रेस/ईग्रेस नियमों को परिभाषित करते हैं।

क्यों: Kubernetes NetworkPolicy पॉड स्तर पर माइक्रोसेगमेंटेशन लागू करने का मूल तरीका है, जो VPC फ़ायरवॉल नियमों की तुलना में अधिक ग्रैन्युलैरिटी प्रदान करता है जो नोड स्तर पर संचालित होते हैं।

एक केंद्रीकृत तृतीय-पक्ष फ़ायरवॉल/NVA का उपयोग करके सभी इंटर-VPC या VPC-से-इंटरनेट ट्रैफिक का निरीक्षण करें।

→एक हब-एंड-स्पोक टोपोलॉजी बनाएं। NVA(s) को एक हब VPC में डिप्लॉय करें। स्पोक्स में कस्टम मार्ग कॉन्फ़िगर करें जो ट्रैफिक को हब में एक Internal Load Balancer पर अगले-हॉप के रूप में निर्देशित करते हैं।

क्यों: यह पैटर्न एक केंद्रीय निरीक्षण बिंदु के माध्यम से ट्रैफिक को मजबूर करता है। ILB NVAs के लिए एक स्थिर, उच्च उपलब्धता वाला अगले-हॉप IP प्रदान करता है।

उपयोगकर्ताओं को VPN का उपयोग किए बिना आंतरिक वेब अनुप्रयोगों या VMs तक सुरक्षित, पहचान-आधारित, ज़ीरो-ट्रस्ट एक्सेस प्रदान करें।

→वेब ऐप्स के लिए, एक External HTTPS LB बैकएंड सेवा पर IAP सक्षम करें। SSH/RDP के लिए, TCP फॉरवर्डिंग के लिए IAP का उपयोग करें। उपयोगकर्ताओं को उपयुक्त IAP IAM भूमिकाएं प्रदान करें।

क्यों: IAP एक्सेस कंट्रोल को नेटवर्क परिधि से उपयोगकर्ता की पहचान पर ले जाता है, हर अनुरोध को प्रमाणित और अधिकृत करता है। यह Google के BeyondCorp ज़ीरो-ट्रस्ट मॉडल का एक मुख्य घटक है।

मालवेयर डिटेक्शन और TLS निरीक्षण सहित इंटर-VPC या VPC-से-इंटरनेट ट्रैफिक के लिए खतरे की रोकथाम (IDS/IPS) लागू करें।

→Cloud NGFW का उपयोग करें। VPC के साथ एक फ़ायरवॉल नीति संबद्ध करें, खतरे की रोकथाम के लिए सुरक्षा प्रोफाइल के साथ नियम बनाएं, और वैकल्पिक रूप से TLS निरीक्षण सक्षम करें।

क्यों: Cloud NGFW Google की वितरित, प्रबंधित फ़ायरवॉल सेवा है जो Palo Alto Networks से उन्नत L7 निरीक्षण क्षमताएं प्रदान करती है, जो सीधे VPC में एकीकृत होती है।

सुरक्षा और अनुपालन के लिए VPC से सभी इंटरनेट-बाउंड ईग्रेस ट्रैफिक का केंद्रीय रूप से निरीक्षण, लॉग और नियंत्रण करें।

→Secure Web Proxy डिप्लॉय करें। URL फ़िल्टरिंग और TLS निरीक्षण के लिए सुरक्षा नीतियां कॉन्फ़िगर करें। कस्टम मार्गों का उपयोग करके सबनेट से प्रॉक्सी तक ट्रैफिक रूट करें।

क्यों: यह सुरक्षित ईग्रेस के लिए Google का प्रबंधित समाधान है, जो स्व-प्रबंधित प्रॉक्सी फ्लीट की आवश्यकता के बिना L7 दृश्यता और नियंत्रण प्रदान करता है।

GCP के भीतर दो एंडपॉइंट (जैसे, VM-से-VM, VM-से-Cloud SQL) के बीच कनेक्टिविटी विफलता का तुरंत निदान करें।

→Network Intelligence Center के Connectivity Tests का उपयोग करें। स्रोत और गंतव्य निर्दिष्ट करें, और यह मुद्दों के लिए पूरे कॉन्फ़िगर किए गए पाथ का विश्लेषण करेगा।

क्यों: यह गैर-घुसपैठी उपकरण पाथ का एक निश्चित विश्लेषण प्रदान करता है, विफलता के सटीक बिंदु (फ़ायरवॉल, मार्ग, आदि) को मैन्युअल निरीक्षण की तुलना में बहुत तेज़ी से इंगित करता है।

एक हाइब्रिड कनेक्शन पर एक BGP सत्र रुक-रुक कर रीसेट हो रहा है ("फ्लैपिंग")।

→BGP कीपअलाइव/होल्ड टाइमर में बेमेल की जांच करें। यदि टाइमर लोड के तहत समाप्त हो जाते हैं, तो उन्हें बढ़ाएं (जैसे, 60s कीपअलाइव, 180s होल्ड)। साथ ही, MTU सेटिंग्स की जांच करें और BFD सक्षम करें।

क्यों: बेमेल या अत्यधिक आक्रामक टाइमर BGP फ्लैप के एक सामान्य कारण हैं, क्योंकि क्षणिक नेटवर्क कंजेशन कीपअलाइव पैकेट को होल्ड टाइम से आगे देरी कर सकता है।

GCP क्षेत्रों के बीच ट्रैफिक के लिए बढ़ी हुई लेटेंसी की रिपोर्ट की जांच करें।

→सभी GCP ज़ोन जोड़े के बीच ऐतिहासिक और वास्तविक समय लेटेंसी और पैकेट लॉस मेट्रिक्स देखने के लिए Network Intelligence Center के Performance Dashboard का उपयोग करें।

क्यों: यह उपकरण Google के बैकबोन नेटवर्क प्रदर्शन में सीधी दृश्यता प्रदान करता है, जिससे एप्लिकेशन समस्या और नेटवर्क इंफ्रास्ट्रक्चर समस्या के बीच अंतर करने में मदद मिलती है।

Cloud NAT का उपयोग करने वाले VMs को रुक-रुक कर आउटबाउंड कनेक्शन विफलताएं होती हैं, और NAT लॉग `OUT_OF_RESOURCES` ड्रॉप्स दिखाते हैं।

→यह संभवतः NAT पोर्ट exhaustion है। आवंटित NAT IP की संख्या बढ़ाएं, "Minimum ports per VM instance" बढ़ाएं, और/या Dynamic Port Allocation सक्षम करें।

क्यों: कई VMs से उच्च कनेक्शन दरें प्रति NAT IP के आवंटित स्रोत पोर्ट पूल को समाप्त कर सकती हैं। अधिक संसाधन आवंटित करना आवश्यक समाधान है।