1. परिचय
Cloud Secure Web Proxy
Cloud SWP, क्लाउड-फ़र्स्ट सेवा है. यह इग्रेस डेटा ट्रैफ़िक (एचटीटीपी/एस) को सुरक्षित रखने में आपकी मदद करने के लिए, सुरक्षित वेब प्रॉक्सी उपलब्ध कराती है. आप अपने क्लाइंट को Cloud SWP का, प्रॉक्सी के तौर पर इस्तेमाल करने के लिए कॉन्फ़िगर करते हैं. वेब अनुरोध इन सोर्स से आ सकते हैं:
- वर्चुअल मशीन (वीएम) इंस्टेंस
- कंटेनर
- बिना सर्वर वाला एनवायरमेंट जो बिना सर्वर वाले कनेक्टर का इस्तेमाल करता है
- VPC पीयरिंग में वर्कलोड
- Cloud वीपीएन या Cloud इंटरकनेक्ट की मदद से कनेक्ट किए गए Google Cloud से बाहर के वर्कलोड
Cloud SWP, क्लाउड-फ़र्स्ट आइडेंटिटी और वेब ऐप्लिकेशन के आधार पर, सुविधाजनक और विस्तृत नीतियों को लागू करता है.
फ़ायदे
यहां कुछ ऐसे फ़ायदों के उदाहरण दिए गए हैं जो Cloud SWP से किसी संगठन को मिल सकते हैं:
Google Cloud पर माइग्रेशन
Cloud SWP, Google Cloud पर माइग्रेट करने में आपकी मदद करता है. इससे, इग्रेस डेटा ट्रैफ़िक के लिए आपकी मौजूदा सुरक्षा नीतियों और ज़रूरी शर्तों को पूरा किया जा सकता है. ऐसे तीसरे पक्ष के समाधानों का इस्तेमाल करने से बचा जा सकता है जिनके लिए दूसरे मैनेजमेंट कंसोल या मैन्युअल तरीके से कॉन्फ़िगरेशन फ़ाइलों में बदलाव करने की ज़रूरत होती है.
भरोसेमंद बाहरी वेब सेवाओं का ऐक्सेस
Cloud SWP, आपको इग्रेस डेटा ट्रैफ़िक के लिए विस्तृत ऐक्सेस की नीतियां लागू करने देता है. इससे आपको अपने नेटवर्क को सुरक्षित रखने में मदद मिलती है. आपको वर्कलोड या ऐप्लिकेशन आइडेंटिटी बनाने और उनकी पहचान करने का विकल्प मिलता है. इसके बाद, नीतियां लागू की जाती हैं.
गैर-भरोसेमंद वेब सेवाओं के ऐक्सेस पर निगरानी रखा गया
गैर-भरोसेमंद वेब सेवाओं का मॉनिटर किया गया ऐक्सेस देने के लिए, Cloud SWP का इस्तेमाल किया जा सकता है. Cloud SWP, उस ट्रैफ़िक की पहचान करता है जो नीति के मुताबिक नहीं है और उसे Cloud Logging (लॉगिंग) में लॉग करता है. इसके बाद, इंटरनेट के इस्तेमाल को मॉनिटर किया जा सकता है, अपने नेटवर्क के लिए खतरों का पता लगाया जा सकता है, और खतरों को ठीक किया जा सकता है.
Google API के लिए नीति के ज़्यादा कंट्रोल
Google API के बारे में ज़्यादा जानकारी वाली नीतियां देने के लिए, Cloud SWP का इस्तेमाल किया जा सकता है. उदाहरण के लिए, कॉमन एक्सप्रेशन लैंग्वेज (सीईएल) का इस्तेमाल करके, बकेट/ऑब्जेक्ट लेवल की नीतियां सेट की जा सकती हैं.
इस्तेमाल की जा सकने वाली सुविधाएं
Cloud SWP में ये सुविधाएं काम करती हैं:
अश्लील प्रॉक्सी सेवा
प्रॉक्सी सर्वर का उपयोग करने के लिए क्लाइंट को स्पष्ट रूप से कॉन्फ़िगर किया जाना चाहिए. Cloud SWP प्रॉक्सी, क्लाइंट की ओर से नए टीसीपी कनेक्शन बनाकर, क्लाइंट को इंटरनेट से अलग करती है.
ऑटो स्केलिंग Cloud SWP Envoy प्रॉक्सी
इसकी मदद से, Envoy प्रॉक्सी पूल के साइज़ और किसी इलाके में पूल की क्षमता को अपने-आप अडजस्ट किया जा सकता है. इससे, सबसे कम लागत पर ज़्यादा मांग वाली अवधि के दौरान परफ़ॉर्मेंस को एक जैसा रखा जा सकता है.
मॉड्यूलर इग्रेस डेटा ऐक्सेस करने की नीतियां
Cloud SWP, खास तौर पर इग्रेस डेटा ट्रैफ़िक की इन नीतियों के साथ काम करता है:
- सोर्स की पहचान, सुरक्षित टैग, सेवा खातों या आईपी पतों के आधार पर होती है.
- यूआरएल और होस्टनेम पर आधारित डेस्टिनेशन.
- तरीकों, हेडर या यूआरएल के आधार पर किए गए अनुरोध. यूआरएल की जानकारी सूचियों, वाइल्डकार्ड या पैटर्न का इस्तेमाल करके दी जा सकती है.
- एंड-टू-एंड एन्क्रिप्शन (E2EE): क्लाइंट-प्रॉक्सी टनल, TLS के ज़रिए एक जगह से दूसरी जगह भेज सकती हैं. Cloud SWP, डेस्टिनेशन सर्वर पर क्लाइंट की ओर से शुरू किए गए और एंड-टू-एंड TLS कनेक्शन के लिए एचटीटीपी/एस कनेक्ट के साथ भी काम करता है.
क्लाउड एनएटी का आसान इंटिग्रेशन
Cloud SWP ट्रैफ़िक बढ़ाने वाली प्रॉक्सी का सेट बढ़ने पर, Cloud NAT, दूसरे सार्वजनिक आईपी पतों का प्रावधान अपने-आप कर देता है.
अगर किसी को, इग्रेस डेटा ट्रैफ़िक के बारे में जानकारी चाहिए, तो उसे मैन्युअल स्टैटिक सार्वजनिक आईपी पते की ज़रूरत होती है.
क्लाउड ऑडिट लॉग और Google Cloud के ऑपरेशंस सुइट का इंटिग्रेशन
क्लाउड ऑडिट लॉग और Google Cloud के ऑपरेशन सुइट, Cloud SWP से जुड़े संसाधनों के लिए एडमिन की गतिविधियों और ऐक्सेस के अनुरोधों को रिकॉर्ड करते हैं. वे प्रॉक्सी के ज़रिए हैंडल किए जाने वाले अनुरोधों के लिए मेट्रिक और लेन-देन लॉग भी रिकॉर्ड करते हैं.
TLS की जांच करना
सिक्योर वेब प्रॉक्सी, TLS की जांच करने वाली सेवा उपलब्ध कराता है. इसकी मदद से, TLS के ट्रैफ़िक को रोका जा सकता है, एन्क्रिप्ट (सुरक्षित) किए गए अनुरोध की जांच की जा सकती है, और सुरक्षा नीतियों को लागू किया जा सकता है.
- सर्टिफ़िकेट अथॉरिटी सर्विस (सीएएस) के साथ बेहतर इंटिग्रेशन, जो कि निजी सीए के लिए काफ़ी उपलब्ध है और बड़े पैमाने पर डेटा स्टोर करने की जगह है.
- ज़रूरत पड़ने पर, अपने भरोसे के मूल सोर्स का इस्तेमाल करने की क्षमता. सीएएस के तहत आने वाले सीए के लिए साइन करने के लिए, किसी मौजूदा रूट सीए का इस्तेमाल भी किया जा सकता है. अगर आप चाहें, तो सीएएस में नया रूट सर्टिफ़िकेट जनरेट किया जा सकता है.
- सुरक्षित वेब प्रॉक्सी नीति के नियमों में, SessionMatcher और AppMatcher का इस्तेमाल करके, बेहतर डिक्रिप्शन के लिए ज़रूरी शर्तें. इस शर्त में, यूआरएल की सूचियों, रेगुलर एक्सप्रेशन, आईपी पते की रेंज, और मिलते-जुलते एक्सप्रेशन में मौजूद मिलते-जुलते होस्ट शामिल हैं. ज़रूरी होने पर, शर्तों को बूलियन एक्सप्रेशन के साथ जोड़ा जा सकता है.
- हर सिक्योर वेब प्रॉक्सी नीति को उसकी खुद की TLS जांच नीति और सीए पूल के साथ कॉन्फ़िगर किया जा सकता है. इसके अलावा, सिक्योर वेब प्रॉक्सी की एक से ज़्यादा नीतियों के तहत, TLS की जांच करने से जुड़ी एक ही नीति को शेयर किया जा सकता है.
आप इन चीज़ों के बारे में जानेंगे
- Cloud SWP को डिप्लॉय और मैनेज करने का तरीका.
आपको इनकी ज़रूरत होगी
- इंस्टेंस को डिप्लॉय करने और नेटवर्किंग कॉम्पोनेंट को कॉन्फ़िगर करने की जानकारी
- VPC फ़ायरवॉल के कॉन्फ़िगरेशन की जानकारी
2. टेस्ट एनवायरमेंट
यह कोडलैब, एक ही VPC का इस्तेमाल करेगा. इस एनवायरमेंट में इस्तेमाल किया जाने वाला कंप्यूट रिसॉर्स, Cloud SWP का इस्तेमाल करके इग्रेस डेटा ट्रैफ़िक करेगा. जैसा कि नीचे दिए गए डायग्राम में दिखाया गया है.
इस लैब में, हमारे पास दो वर्कलोड वीएम होंगे.
क्लाइंट A को Cloud SWP पर सभी एचटीटीपी/एचटीटीपीएस अनुरोध भेजने के लिए कॉन्फ़िगर किया जाएगा.
क्लाइंट B को Cloud SWP पर खास तौर पर एचटीटीपी/एचटीटीपीएस अनुरोध भेजने के लिए कॉन्फ़िगर नहीं किया जाएगा. इसके बजाय, इसे इंटरनेट से मिलने वाले ट्रैफ़िक के लिए, Cloud NAT का इस्तेमाल किया जाएगा.
3. शुरू करने से पहले
कोडलैब के लिए एक प्रोजेक्ट होना ज़रूरी है.
Cloud Shell में, पक्का करें कि आपका प्रोजेक्ट आईडी सेट अप किया गया हो
export project_id=`gcloud config list --format="value(core.project)"` export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export region=us-west1 export zone=us-west1-a export prefix=codelab-swp export member="serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com"
4. एपीआई चालू करें
प्रॉडक्ट इस्तेमाल करने के लिए, एपीआई चालू करें
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. VPC नेटवर्क, सबनेट, और सिर्फ़ प्रॉक्सी के लिए सबनेट बनाएं
VPC नेटवर्क
codelab-swp-vpc VPC बनाएं:
gcloud compute networks create $prefix-vpc --subnet-mode=custom
सबनेट
चुने गए क्षेत्र में संबंधित सबनेट बनाएं:
gcloud compute networks subnets create $prefix-vpc-subnet \ --range=10.10.10.0/24 --network=$prefix-vpc --region=$region
सिर्फ़ प्रॉक्सी सबनेट
चुने गए इलाके में सिर्फ़ प्रॉक्सी सबनेट बनाएं:
gcloud compute networks subnets create $prefix-proxy-only-subnet --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE --region=$region --network=$prefix-vpc --range=172.16.0.0/23
6. फ़ायरवॉल के नियम बनाएं
आईएपी को अपने वीएम इंस्टेंस से कनेक्ट करने की अनुमति देने के लिए, फ़ायरवॉल का नियम बनाएं:
- यह उन सभी वीएम इंस्टेंस पर लागू होता है जिन्हें आपको आईएपी का इस्तेमाल करके ऐक्सेस करना है.
- आईपी रेंज 35.235.240.0/20 से, इन्ग्रेस डेटा ट्रैफ़िक की अनुमति देता है. इस रेंज में वे सभी आईपी पते शामिल होते हैं जिनका इस्तेमाल आईएपी, टीसीपी फ़ॉरवर्ड करने के लिए करता है.
Cloud Shell से:
gcloud compute firewall-rules create $prefix-allow-iap-proxy \ --direction=INGRESS \ --priority=1000 \ --network=$prefix-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
7. क्लाउड राऊटर बनाएं और क्लाउड एनएटी
Cloud NAT के लिए क्लाउड राऊटर बनाएं.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
क्लाइंट B के लिए Cloud NAT गेटवे बनाएं.
gcloud compute routers nats create $prefix-nat-gw-$region \ --router=$prefix-cr \ --router-region=$region \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges
8. गेटवे की सुरक्षा के लिए नीति बनाएं
एक ऐसी yaml फ़ाइल बनाएं जिसमें नीति के लिए काम की जानकारी हो:
cat > /tmp/policy.yaml << EOF
description: Policy to allow .com traffic, then (/index.html), and finally TLS.
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
EOF
yaml फ़ाइल से नीति बनाने के लिए, gcloud कमांड चलाएं:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. गेटवे की सुरक्षा के लिए नीति का नियम बनाएं
ऐसी yaml फ़ाइल बनाएं जिसमें नियम शामिल हों. ये नियम, कॉमन एक्सप्रेशन लैंग्वेज (सीईएल) में दिखाए जाते हैं. यह लैब एक आसान नियम का इस्तेमाल करेगा, जो .com डोमेन पर ट्रैफ़िक लाने और बाकी सभी को ब्लॉक करने देगा:
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
EOF
अब हम नियम को गेटवे सुरक्षा नीति से जोड़ सकते हैं:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
10. एक प्रमाणपत्र बनाएं और Cloud Certificate Manager पर अपलोड करें
वर्कलोड ट्रैफ़िक को खत्म करने के लिए सर्टिफ़िकेट बनाएं:
openssl req -x509 -newkey rsa:2048 -keyout /tmp/key.pem -out /tmp/cert.pem -days 365 -subj '/CN=www.codelab-swp.com' -nodes -addext \ "subjectAltName = DNS:www.codelab-swp.com"
सर्टिफ़िकेट को Cloud Certificate Manager में अपलोड करें, ताकि SWP इसका रेफ़रंस सिक्योरिटी गेटवे नीति में दे सके.
gcloud certificate-manager certificates create ${prefix}-cert --location=${region} --private-key-file=/tmp/key.pem --certificate-file=/tmp/cert.pem
11. एसडब्ल्यूपी गेटवे बनाएं
सर्टिफ़िकेट, गेटवे सुरक्षा नीति, नेटवर्क, और सबनेट जैसी पिछली जानकारी का रेफ़रंस देने के लिए, SWP गेटवे के लिए yaml फ़ाइल बनाएं.
cat > /tmp/gateway.yaml << EOF
name: projects/${project_id}/locations/${region}/gateways/${prefix}-gateway
type: SECURE_WEB_GATEWAY
addresses: [10.10.10.50]
ports: [443]
certificateUrls: [projects/${project_id}/locations/${region}/certificates/${prefix}-cert]
gatewaySecurityPolicy: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
network: projects/${project_id}/global/networks/${prefix}-vpc
subnetwork: projects/${project_id}/regions/${region}/subnetworks/${prefix}-vpc-subnet
EOF
गेटवे बनाएं:
gcloud network-services gateways import ${prefix}-swp --source=/tmp/gateway.yaml --location=${region}
पुष्टि करें कि गेटवे बना लिया गया है:
gcloud network-services gateways describe ${prefix}-swp --location ${region}
12. कंप्यूट इंस्टेंस बनाएं
Cloud SWP एक खास प्रॉक्सी है, इसलिए हमें वर्कलोड ट्रैफ़िक के लिए साफ़ तौर पर प्रॉक्सी आईपी की जानकारी देनी होगी. कंप्यूट इंस्टेंस clientA में एनवायरमेंट वैरिएबल सेट होगा. ClientB ऐसा नहीं करेगा.
ClientA और ClientB कंप्यूट इंस्टेंस बनाएं:
gcloud compute instances create clienta \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.10 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update sudo echo http_proxy=https://10.10.10.50:443/ >> /etc/environment sudo echo https_proxy=https://10.10.10.50:443/ >> /etc/environment '
gcloud compute instances create clientb \ --subnet=$prefix-vpc-subnet \ --no-address \ --private-network-ip=10.10.10.200 \ --zone $zone \ --metadata startup-script='#! /bin/bash apt-get update '
13. सेशन मैचिंग की जांच की जा रही है
एसएसएच को "clienta" में जोड़ें कंप्यूट वीएम हाल ही में बनाई गई. इस वीएम में पर्यावरण वैरिएबल को Cloud SWP का इस्तेमाल करने के लिए सेट किया गया है.
Cloud Shell से:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
इस सुविधा के काम करने के तरीके की पुष्टि करने के लिए, कुछ वेब क्वेरी चलाएं. हमें -प्रॉक्सी-असुरक्षित प्लैटफ़ॉर्म की ज़रूरत है, क्योंकि हमने इस लैब के लिए खुद हस्ताक्षर किया हुआ सर्टिफ़िकेट बनाया है:
curl https://google.com --proxy-insecure
अनुमानित आउटपुट:
davidtu@clienta:~$ curl https://google.com --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
जैसा कि आपको दिख रहा है, अनुरोध "स्वीकार हो गया" है. हमें 301 रीडायरेक्ट देखने की उम्मीद है, क्योंकि वेबसाइट https://www.google.com पर रीडायरेक्ट कर रही है.
इस निर्देश को चलाने से, कनेक्शन के बारे में जानकारी के साथ ज़्यादा जानकारी वाले लॉग मिलेंगे:
curl https://google.com --proxy-insecure -v
प्रॉक्सी कनेक्शन की जानकारी, सर्टिफ़िकेट, और डेस्टिनेशन दिखाने के लिए, कुछ आउटपुट हाइलाइट किए जा रहे हैं.
davidtu@clienta:~$ curl https://google.com --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to google.com:443 > CONNECT google.com:443 HTTP/1.1 > Host: google.com:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < date: Mon, 12 Dec 2022 19:22:04 GMT < * Proxy replied 200 to CONNECT request * CONNECT phase completed! ...
सुविधा के काम करने की पुष्टि करने के लिए, बेझिझक अन्य .com डोमेन आज़माएं.
आइए, ब्लॉक करने के डिफ़ॉल्ट तरीके की पुष्टि करने के लिए, अब कुछ अन्य नॉन-.com डोमेन आज़माते हैं:
curl https://wikipedia.org --proxy-insecure
अनुमानित आउटपुट:
curl: (56) Received HTTP code 403 from proxy after CONNECT
इसी तरह, वर्बोस आउटपुट लॉगिंग देखें और पुष्टि करें कि Cloud SWP इस ट्रैफ़िक को ब्लॉक कर रहा है:
curl https://wikipedia.org --proxy-insecure -v
davidtu@clienta:~$ curl https://wikipedia.org --proxy-insecure -v * Uses proxy env variable https_proxy == 'https://10.10.10.50:443/' * Trying 10.10.10.50:443... * Connected to 10.10.10.50 (10.10.10.50) port 443 (#0) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use http/1.1 * Proxy certificate: * subject: CN=www.codelab-swp.com * start date: Dec 12 17:16:35 2022 GMT * expire date: Dec 12 17:16:35 2023 GMT * issuer: CN=www.codelab-swp.com * SSL certificate verify result: self signed certificate (18), continuing anyway. * allocate connect buffer! * Establish HTTP proxy tunnel to wikipedia.org:443 > CONNECT wikipedia.org:443 HTTP/1.1 > Host: wikipedia.org:443 > User-Agent: curl/7.74.0 > Proxy-Connection: Keep-Alive > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 403 Forbidden < content-length: 13 < content-type: text/plain < date: Mon, 12 Dec 2022 19:35:09 GMT < connection: close < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT
व्यवहार की पुष्टि करने के लिए, बेझिझक अन्य डोमेन भी आज़माएं.
एसएसएच सेशन से, "clienta" पर बाहर निकलें और "clientb" से एक नया एसएसएच कनेक्शन चालू करें.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
व्यवहार की जांच करने के लिए कुछ कर्ल निर्देश चलाएं:
curl https://google.com
इसे उम्मीद के मुताबिक Clientb VM के तौर पर काम करना चाहिए:
davidtu@clientb:~$ curl https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML>
संगठन के डोमेन की जांच करना:
curl https://wikipedia.org
यह उम्मीद के मुताबिक काम करता है, क्योंकि Clientb ने Cloud SWP का इस्तेमाल नहीं किया है:
davidtu@clientb:~$ curl https://wikipedia.org <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.wikipedia.org/">here</a>.</p> </body></html>
Cloud SWP के ज़रिए ट्रैफ़िक को साफ़ तौर पर भेजने की जांच करें:
curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure
हमने देखा है कि यह ट्रैफ़िक Cloud SWP नीति के ज़रिए अस्वीकार किया गया है:
davidtu@clientb:~$ curl -x https://10.10.10.50:443/ https://wikipedia.org --proxy-insecure curl: (56) Received HTTP code 403 from proxy after CONNECT
जैसा कि आपने पुष्टि की है, Cloud SWP का इस्तेमाल करने वाले ट्रैफ़िक को कॉन्फ़िगर की गई सुरक्षा नीति के हिसाब से लागू किया जा रहा है. .com के लिए तय किए गए ट्रैफ़िक की अनुमति है और बाकी सभी डेस्टिनेशन को अस्वीकार किया जाता है.
Clientb से बाहर निकलें.
14. ऐप्लिकेशन मैच करने के लिए, गेटवे की सुरक्षा नीति के नियम को अपडेट करें
आइए, नियम को ऐप्लिकेशन लेवल की जानकारी से मैच करने के लिए अपडेट करते हैं. हम अनुरोध के पाथ को देखने के लिए एक नियम बनाएंगे और उसे सिर्फ़ तब अनुमति देंगे, जब वह index.html से मेल खाए.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
EOF
अब हम अपडेट किए गए नियम को गेटवे सुरक्षा नीति से बाइंड कर सकते हैं:
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
15. AppMatcher के नियम की जाँच की जा रही है
क्लाइंटा कंप्यूट वीएम में एसएसएच की मदद से. इस वीएम में पर्यावरण वैरिएबल को Cloud SWP का इस्तेमाल करने के लिए सेट किया गया है.
Cloud Shell से:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
इस सुविधा के काम करने के तरीके की पुष्टि करने के लिए, कुछ वेब क्वेरी चलाएं. हमें -प्रॉक्सी-असुरक्षित प्लैटफ़ॉर्म की ज़रूरत है, क्योंकि हमने इस लैब के लिए खुद हस्ताक्षर किया हुआ सर्टिफ़िकेट बनाया है:
curl http://google.com --proxy-insecure
ध्यान दें कि क्वेरी पहले पास हो जाने पर, वह फ़ेल हो जाएगी.
Access denied
"index.html" के अलावा कोई भी अनुरोध पाथ कोड 403 के साथ ब्लॉक होना चाहिए. इसे आज़माकर देखें.
/index.html पाथ शामिल करने के लिए क्वेरी में बदलाव करें
curl http://google.com/index.html --proxy-insecure
इस अनुरोध को स्वीकार किया जाना चाहिए:
davidtu@clienta:~$ curl http://google.com/index.html --proxy-insecure <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
हमें 301 रीडायरेक्ट देखने की उम्मीद है, क्योंकि वेबसाइट http://www.google.com/index.html पर रीडायरेक्ट कर रही है
ध्यान दें कि यह एक एचटीटीपी अनुरोध है. इसके बाद, आपको TLS की जांच करने की सुविधाएं देने के लिए, एसडब्ल्यूपी को चालू करना होगा.
इसके बाद उसी क्वेरी को लेकिन TLS पर चलाएं:
curl -k https://google.com/index.html --proxy-insecure
अनुमानित आउटपुट:
curl: (56) Received HTTP code 403 from proxy after CONNECT
यह अनुरोध पूरा नहीं होना चाहिए, क्योंकि एसडब्ल्यूपी को TLS की जांच करने के लिए कॉन्फ़िगर नहीं किया गया है. साथ ही, यह appMatcher नियम के हिसाब से पाथ का आकलन नहीं कर सकता.
clenta से बाहर निकलें.
16. TLS की जांच करने की सुविधा चालू करें
TLS की जांच किए बिना, ऐप्लिकेशन मैच करने वाले टूल का एचटीटीपीएस ट्रैफ़िक से मैच नहीं होगा.
"applicationMatcher" निम्न को फ़िल्टर करने की अनुमति देता है:
- अनुरोध हेडर मैप
- अनुरोध करने का तरीका
- होस्ट से अनुरोध करें
- अनुरोध का पाथ
- क्वेरी का अनुरोध करें
- स्कीम के लिए अनुरोध करें
- पूरे अनुरोध का यूआरएल
- अनुरोध उपयोगकर्ता एजेंट
सेवा खाता बनाएं
इस सेवा खाते के पास SWP TLS की जांच के लिए, सर्टिफ़िकेट जनरेट करने की अनुमति होगी.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
पक्का करें कि सीएएस चालू हो
gcloud services enable privateca.googleapis.com
सीए पूल बनाएं
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
रूट सीए (सर्टिफ़िकेट देने वाली संस्था) बनाएं
सर्टिफ़िकेट पर हस्ताक्षर करने के लिए इस्तेमाल किया जाने वाला CA.
gcloud privateca roots create $prefix-root-ca --pool=$prefix-ca-pool \ --location=$region \ --auto-enable \ --subject="CN=my-swp-ca, O=SWP LLC"
सर्टिफ़िकेट जारी करने की नीति की फ़ाइल बनाएं
cat > /tmp/tls-issuance-policy.yaml << EOF
maximumLifetime: 1209600s
baselineValues:
caOptions:
isCa: false
keyUsage:
extendedKeyUsage:
serverAuth: true
EOF
TLS की जांच करने वाली yaml फ़ाइल बनाएं
cat > /tmp/tls-inspection-policy.yaml << EOF caPool: projects/$project_id/locations/$region/caPools/$prefix-ca-pool name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-inspection EOF
TLS की जांच करने से जुड़ी नीति बनाएं
gcloud network-security tls-inspection-policies import $prefix-tls-inspection \
--source=/tmp/tls-inspection-policy.yaml \
--location=$region
सर्टिफ़िकेट जारी करने की नीति का इस्तेमाल करने के लिए, सीए पूल को अपडेट करें
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
अनुमतियां दें
इससे आपके सेवा खाते को सर्टिफ़िकेट जनरेट करने के लिए, सीए पूल का इस्तेमाल करने की अनुमति मिलती है.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
टीएलएस की जांच को शामिल करने के लिए, नीति yaml को अपडेट करें
cat > /tmp/policy.yaml << EOF
description: some policy description
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy
tlsInspectionPolicy: projects/${project_id}/locations/${region}/tlsInspectionPolicies/${prefix}-tls-inspection
EOF
अपडेट की गई नीति लागू करने के लिए निर्देश चलाएं
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
टीएलएस की जांच को शामिल करने के लिए नियमों को अपडेट करें
इसके बाद यह तय करें कि किन नियमों में TLS जांच "enabtlsंदionEnabled: true" होना चाहिए फ़्लैग करें.
cat > /tmp/rule-com.yaml << EOF
name: projects/${project_id}/locations/${region}/gatewaySecurityPolicies/${prefix}-policy/rules/rule-com
enabled: true
priority: 1
description: Allow .com traffic with path index.html
basicProfile: ALLOW
sessionMatcher: host().endsWith('com')
applicationMatcher: request.path.matches('index.html')
tlsInspectionEnabled: true
EOF
अपडेट किए गए नियम को लागू करने के लिए निर्देश चलाएं
gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy
17. TLS की जांच करना
क्लाइंटा कंप्यूट वीएम में एसएसएच की मदद से. इस वीएम में पर्यावरण वैरिएबल को Cloud SWP का इस्तेमाल करने के लिए सेट किया गया है.
Cloud Shell से:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
पिछली वेब क्वेरी चलाकर पुष्टि करें कि SWP, पाथ को फिर से पाने के लिए TLS की जांच कर रहा है या नहीं
curl -k https://google.com/index.html --proxy-insecure
इस बार यह प्रोसेस पूरी हो जानी चाहिए, क्योंकि SWP,ApplicationMatcher का आकलन कर सकता है.
अनुमानित आउटपुट:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/index.html">here</A>. </BODY></HTML>
हमने TLS की जांच करने और ऐप्लिकेशन मैच करने वाले लॉजिक का आकलन करने के लिए, Cloud SWP को सेट अप कर लिया है!
Clienta से बाहर निकलें.
18. क्लीनअप का तरीका
Cloud Shell से, SWP गेटवे, सुरक्षा नीति, सर्टिफ़िकेट, इंस्टेंस, Cloud NAT, और Cloud राऊटर को हटाएं:
gcloud -q network-services gateways delete ${prefix}-swp --location=${region}
gcloud -q network-security gateway-security-policies rules delete rule-com --location=${region} --gateway-security-policy=${prefix}-policy
gcloud -q network-security gateway-security-policies delete ${prefix}-policy --location=${region}
gcloud -q certificate-manager certificates delete ${prefix}-cert --location=${region}
gcloud -q network-security tls-inspection-policies delete $prefix-tls-inspection --location=$region
gcloud -q privateca roots disable $prefix-root-ca --pool=$prefix-ca-pool --location=$region
gcloud -q privateca roots delete $prefix-root-ca --pool=$prefix-ca-pool --location=$region --ignore-active-certificates --skip-grace-period
gcloud -q privateca pools delete $prefix-ca-pool --location=$region
gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region
gcloud -q compute routers delete `gcloud compute routers list --regions=$region --format="value(NAME)" | grep -e swg-autogen -e codelab-swp` --region=$region
सबनेट, FW के नियम, और VPC हटाएं:
gcloud -q compute networks subnets delete $prefix-vpc-subnet \
--region $region
gcloud -q compute networks subnets delete $prefix-proxy-only-subnet \
--region=$region
gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute networks delete $prefix-vpc
19. बधाई हो!
कोडलैब पूरा करने के लिए बधाई. आपने Google Cloud पर Cloud Secure वेब प्रॉक्सी को कॉन्फ़िगर और डिप्लॉय कर लिया है.
हमने इन विषयों के बारे में बताया
- Cloud SWP और उसके फ़ायदे!