1. परिचय
Cloud Secure Web Proxy
Cloud SWP, क्लाउड-फ़र्स्ट सेवा है. यह सुरक्षित वेब प्रॉक्सी उपलब्ध कराती है, ताकि आपको इग्रेस वेब ट्रैफ़िक (एचटीटीपी/एस) को सुरक्षित करने में मदद मिल सके. क्लाइंट को इस तरह कॉन्फ़िगर करें कि वे Cloud SWP को प्रॉक्सी के तौर पर इस्तेमाल करें. वेब अनुरोध इन सोर्स से आ सकते हैं:
- वर्चुअल मशीन (वीएम) इंस्टेंस
- कंटेनर
- सर्वर के बिना काम करने वाला एनवायरमेंट, जो सर्वर के बिना काम करने वाले कनेक्टर का इस्तेमाल करता है
- VPC पीयरिंग के ज़रिए वर्कलोड
- Google Cloud से बाहर के वर्कलोड, जो Cloud वीपीएन या Cloud Interconnect से कनेक्ट किए गए हैं
Cloud SWP, क्लाउड-फ़र्स्ट आइडेंटिटी और वेब ऐप्लिकेशन के आधार पर, लचीली और विस्तृत नीतियां लागू करने की सुविधा देता है.
फ़ायदे
यहां कुछ ऐसे फ़ायदों के उदाहरण दिए गए हैं जो Cloud SWP किसी संगठन को दे सकता है:
Google Cloud पर माइग्रेशन
Cloud SWP की मदद से, Google Cloud पर माइग्रेट किया जा सकता है. साथ ही, आउटगोइंग वेब ट्रैफ़िक के लिए, मौजूदा सुरक्षा नीतियां और ज़रूरी शर्तें लागू रखी जा सकती हैं. आपको तीसरे पक्ष के ऐसे समाधानों का इस्तेमाल करने की ज़रूरत नहीं होती है जिनके लिए किसी अन्य मैनेजमेंट कंसोल की ज़रूरत होती है या कॉन्फ़िगरेशन फ़ाइलों में मैन्युअल तरीके से बदलाव करना पड़ता है.
भरोसेमंद बाहरी वेब सेवाओं का ऐक्सेस
Cloud SWP की मदद से, अपने वेब ट्रैफ़िक पर ऐक्सेस से जुड़ी नीतियां लागू की जा सकती हैं. इससे आपको अपने नेटवर्क को सुरक्षित रखने में मदद मिलती है. इसमें वर्कलोड या ऐप्लिकेशन की पहचान बनाई जाती है और उनकी पुष्टि की जाती है. इसके बाद, नीतियां लागू की जाती हैं.
भरोसेमंद नहीं मानी जाने वाली वेब सेवाओं के ऐक्सेस पर नज़र रखी जाती है
Cloud SWP का इस्तेमाल करके, भरोसेमंद न होने वाली वेब सेवाओं को मॉनिटर किया गया ऐक्सेस दिया जा सकता है. Cloud SWP, ऐसे ट्रैफ़िक की पहचान करता है जो नीति के मुताबिक नहीं है. साथ ही, इसे Cloud Logging (Logging) में लॉग करता है. इसके बाद, इंटरनेट के इस्तेमाल पर नज़र रखी जा सकती है. साथ ही, नेटवर्क के लिए ख़तरों का पता लगाया जा सकता है और उनका जवाब दिया जा सकता है.
Google API के लिए, नीति से जुड़े बेहतर कंट्रोल
Google API के लिए, ज़्यादा बेहतर नीतियां लागू करने के लिए Cloud SWP का इस्तेमाल किया जा सकता है. उदाहरण के लिए, कॉमन एक्सप्रेशन लैंग्वेज (सीईएल) का इस्तेमाल करके, बकेट/ऑब्जेक्ट लेवल की नीतियां सेट की जा सकती हैं.
इस्तेमाल की जा सकने वाली सुविधाएं
Cloud SWP में ये सुविधाएं काम करती हैं:
एक्सप्लिसिट प्रॉक्सी सेवा
क्लाइंट को प्रॉक्सी सर्वर का इस्तेमाल करने के लिए, साफ़ तौर पर कॉन्फ़िगर किया जाना चाहिए. Cloud SWP प्रॉक्सी, क्लाइंट की ओर से नए टीसीपी कनेक्शन बनाकर, क्लाइंट को इंटरनेट से अलग करती है.
Cloud SWP Envoy प्रॉक्सी को अपने-आप स्केल करने की सुविधा
यह सुविधा, किसी क्षेत्र में Envoy प्रॉक्सी पूल के साइज़ और पूल की क्षमता को अपने-आप अडजस्ट करती है. इससे, मांग ज़्यादा होने पर भी कम लागत में बेहतर परफ़ॉर्मेंस मिलती है.
मॉड्यूलर इग्रेस ऐक्सेस की नीतियां
Cloud SWP, खास तौर पर इन इग्रेस नीतियों के साथ काम करता है:
- सुरक्षित टैग, सेवा खातों या आईपी पतों के आधार पर सोर्स-पहचान.
- यूआरएल और होस्टनेम के आधार पर डेस्टिनेशन.
- अनुरोध, तरीकों, हेडर या यूआरएल पर आधारित होते हैं. यूआरएल को सूचियों, वाइल्डकार्ड या पैटर्न का इस्तेमाल करके तय किया जा सकता है.
- एंड-टू-एंड एन्क्रिप्शन: क्लाइंट-प्रॉक्सी टनल, टीएलएस पर ट्रांसिट हो सकती हैं. Cloud SWP, क्लाइंट की ओर से शुरू किए गए, डेस्टिनेशन सर्वर के लिए एंड-टू-एंड टीएलएस कनेक्शन के लिए एचटीटीपी/एस कनेक्ट का भी इस्तेमाल करता है.
Cloud NAT को आसानी से इंटिग्रेट करने की सुविधा
Cloud NAT, Cloud SWP के ट्रैफ़िक को मैनेज करने वाली प्रॉक्सी की संख्या बढ़ने पर, सार्वजनिक आईपी पते अपने-आप उपलब्ध कराता है.
जिन लोगों को इग्रेस आईपी के बारे में जानकारी चाहिए उनके लिए, मैन्युअल स्टैटिक पब्लिक आईपी पते का विकल्प भी उपलब्ध है.
Cloud Audit Logs और Google Cloud के कार्रवाइयों वाले सुइट का इंटिग्रेशन
Cloud Audit Logs और Google Cloud का कार्रवाइयों वाला सुइट, Cloud SWP से जुड़ी संसाधनों के लिए एडमिन की गतिविधियों और ऐक्सेस के अनुरोधों को रिकॉर्ड करते हैं. ये प्रॉक्सी के ज़रिए हैंडल किए गए अनुरोधों के लिए, मेट्रिक और लेन-देन के लॉग भी रिकॉर्ड करते हैं.
TLS की जांच
Secure Web Proxy, टीएलएस की जांच करने की सेवा देता है. इससे टीएलएस ट्रैफ़िक को रोका जा सकता है, एन्क्रिप्ट किए गए अनुरोध की जांच की जा सकती है, और सुरक्षा नीतियों को लागू किया जा सकता है.
- Certificate Authority Service (CAS) के साथ बेहतर तरीके से इंटिग्रेट किया गया है. CAS, निजी CA के लिए एक ऐसी रिपॉज़िटरी है जो हर समय उपलब्ध रहती है और जिसे ज़रूरत के हिसाब से बढ़ाया जा सकता है.
- ज़रूरत पड़ने पर, अपने रूट ऑफ़ ट्रस्ट का इस्तेमाल करने की सुविधा. सीएएस के पास मौजूद सबऑर्डिनेट सीए के लिए साइन करने के लिए, किसी मौजूदा रूट सीए का भी इस्तेमाल किया जा सकता है. अगर आपको CAS में नया रूट सर्टिफ़िकेट जनरेट करना है, तो ऐसा किया जा सकता है.
- सुरक्षित वेब प्रॉक्सी की नीति के नियमों में SessionMatcher और ApplicationMatcher का इस्तेमाल करके, डिक्रिप्ट करने की बारीकी से तय की गई शर्तें. इस मानदंड में, यूआरएल सूचियों, रेगुलर एक्सप्रेशन, आईपी पते की रेंज, और मिलते-जुलते एक्सप्रेशन में मौजूद होस्ट से मेल खाना शामिल है. ज़रूरत पड़ने पर, शर्तों को बूलियन एक्सप्रेशन के साथ जोड़ा जा सकता है.
- हर Secure Web Proxy नीति को, टीएलएस की जांच करने वाली अपनी नीति और सीए पूल के साथ कॉन्फ़िगर किया जा सकता है. इसके अलावा, एक से ज़्यादा सुरक्षित वेब प्रॉक्सी नीतियां, टीएलएस की जांच करने वाली एक ही नीति को शेयर कर सकती हैं.
आपको क्या सीखने को मिलेगा
- Cloud SWP को डिप्लॉय और मैनेज करने का तरीका.
आपको किन चीज़ों की ज़रूरत होगी
- नेटवर्किंग कॉम्पोनेंट को कॉन्फ़िगर करने और इंस्टेंस डिप्लॉय करने की जानकारी
- वीपीसी फ़ायरवॉल कॉन्फ़िगरेशन के बारे में जानकारी
2. टेस्ट एनवायरमेंट
इस कोडलैब में, एक ही वीपीसी का इस्तेमाल किया जाएगा. इस एनवायरमेंट में मौजूद कंप्यूट रिसोर्स, 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 नेटवर्क
codelab-swp-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 आईपी रेंज से इन्ग्रेस ट्रैफ़िक को आने की अनुमति मिलती है. इस रेंज में वे सभी आईपी पते शामिल हैं जिनका इस्तेमाल IAP, टीसीपी फ़ॉरवर्डिंग के लिए करता है.
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 Router और Cloud NAT बनाना
Cloud NAT के लिए Cloud Router बनाएं.
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 गेटवे बनाना
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 एक प्रॉक्सी है. इसलिए, हमें वर्कलोड ट्रैफ़िक के लिए प्रॉक्सी आईपी की जानकारी देनी होगी. Compute instance 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
सुविधा की पुष्टि करने के लिए, कुछ वेब क्वेरी चलाएं. हमने इस लैब के लिए, खुद से हस्ताक्षर किया गया सर्टिफ़िकेट बनाया है. इसलिए, हमें –proxy-insecure की ज़रूरत है:
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
क्लाइंटबी वीएम पर, यह उम्मीद के मुताबिक काम करना चाहिए:
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. ApplicationMatching के लिए, गेटवे की सुरक्षा नीति से जुड़े नियम को अपडेट करना
आइए, ऐप्लिकेशन लेवल की जानकारी से मैच करने के लिए नियम को अपडेट करें. हम अनुरोध के पाथ की जांच करने के लिए एक नियम बनाएंगे. हम सिर्फ़ तब अनुरोध को अनुमति देंगे, जब वह 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. ApplicationMatcher नियम की जांच करना
clienta कंप्यूट वीएम में एसएसएच करें. इस वीएम में, Cloud SWP का इस्तेमाल करने के लिए एनवायरमेंट वैरिएबल सेट है.
Cloud Shell से:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
सुविधा की पुष्टि करने के लिए, कुछ वेब क्वेरी चलाएं. हमने इस लैब के लिए, खुद से हस्ताक्षर किया गया सर्टिफ़िकेट बनाया है. इसलिए, हमें –proxy-insecure की ज़रूरत है:
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 पर रीडायरेक्ट हो रही है
ध्यान दें कि यह एक एचटीटीपी अनुरोध है. इसके बाद, आपको टीएलएस की जांच करने की सुविधाओं का इस्तेमाल करने के लिए, एसडब्ल्यूपी चालू करना होगा.
इसके बाद, उसी क्वेरी को टीएलएस पर चलाएं:
curl -k https://google.com/index.html --proxy-insecure
अनुमानित आउटपुट:
curl: (56) Received HTTP code 403 from proxy after CONNECT
यह अनुरोध पूरा नहीं होना चाहिए, क्योंकि SWP को टीएलएस की जांच करने के लिए कॉन्फ़िगर नहीं किया गया है. साथ ही, यह ऐप्लिकेशनमैचर नियम के हिसाब से पाथ का आकलन नहीं कर सकता.
clenta से बाहर निकलें.
16. TLS Inspection की सुविधा चालू करना
टीएलएस की जांच के बिना, applicationMatcher, एचटीटीपीएस ट्रैफ़िक से मैच नहीं करेगा.
"applicationMatcher" की मदद से, इन पर फ़िल्टर किया जा सकता है:
- अनुरोध के हेडर का मैप
- अनुरोध का तरीका
- अनुरोध करने वाला होस्ट
- अनुरोध का पाथ
- अनुरोध से जुड़ी क्वेरी
- अनुरोध का स्कीमा
- अनुरोध का पूरा यूआरएल
- उपयोगकर्ता एजेंट का अनुरोध करें
सेवा खाता बनाएं
इस सेवा खाते के पास, SWP TLS की जांच के लिए सर्टिफ़िकेट जनरेट करने की अनुमतियां होंगी.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
पक्का करें कि CAS चालू हो
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
सर्टिफ़िकेट जारी करने की नीति का इस्तेमाल करने के लिए, CA पूल को अपडेट करना
gcloud privateca pools update $prefix-ca-pool --issuance-policy=/tmp/tls-issuance-policy.yaml --location=$region
अनुमतियां दें
इससे आपका सेवा खाता, CA पूल का इस्तेमाल करके सर्टिफ़िकेट जनरेट कर सकता है.
gcloud privateca pools add-iam-policy-binding $prefix-ca-pool \
--member=$member \
--role='roles/privateca.certificateManager' \
--location=$region
TLS की जांच करने के लिए, नीति की 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 की जांच करने के लिए, नियमों को अपडेट करना
इसके बाद, यह तय करें कि किन नियमों के लिए टीएलएस की जांच "enabtlsInspectionEnabled: 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 की जांच करने की सुविधा की जांच करना
clienta कंप्यूट वीएम में एसएसएच करें. इस वीएम में, Cloud SWP का इस्तेमाल करने के लिए एनवायरमेंट वैरिएबल सेट है.
Cloud Shell से:
gcloud compute ssh clienta --zone=$zone --tunnel-through-iap
यह पुष्टि करने के लिए कि SWP, पाथ को वापस पाने के लिए टीएलएस की जांच कर रहा है या नहीं, पिछली वेब क्वेरी चलाएं
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>
हमने टीएलएस की जांच करने और applicationMatcher लॉजिक का आकलन करने के लिए, Cloud SWP को सेट अप कर लिया है!
clienta से बाहर निकलें.
18. क्लीनअप करने का तरीका
Cloud Shell से, SWP गेटवे, सुरक्षा नीति, सर्टिफ़िकेट, इंस्टेंस, Cloud NAT, और Cloud Router हटाएं:
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
सबनेट, फ़ायरवॉल के नियम, और वीपीसी हटाएं:
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 Web Proxy को कॉन्फ़िगर और डिप्लॉय कर लिया है.
हमने क्या-क्या कवर किया है
- Cloud SWP और इसके फ़ायदे!