1. مقدمه
Cloud Secure Web Proxy
Cloud SWP اولین سرویس ابری است که یک پروکسی وب ایمن برای کمک به شما در ایمن سازی ترافیک وب خروجی (HTTP/S) ارائه می کند. شما مشتریان خود را به گونه ای پیکربندی می کنید که صریحاً از Cloud SWP به عنوان یک پروکسی استفاده کنند. درخواست های وب می توانند از منابع زیر سرچشمه بگیرند:
- نمونه های ماشین مجازی (VM).
- ظروف
- یک محیط بدون سرور که از کانکتور بدون سرور استفاده می کند
- بارهای کاری در سراسر VPC Peering
- بارهای کاری خارج از Google Cloud با Cloud VPN یا Cloud Interconnect متصل می شوند
Cloud SWP سیاست‌های منعطف و دقیق را بر اساس هویت‌های ابری و برنامه‌های کاربردی وب فعال می‌کند.
مزایا
در زیر چند نمونه از مزایایی که Cloud SWP می تواند برای یک سازمان فراهم کند آورده شده است:
مهاجرت به Google Cloud
Cloud SWP به شما کمک می‌کند در حالی که خط‌مشی‌های امنیتی موجود و الزامات ترافیک وب خروجی را حفظ می‌کنید، به Google Cloud مهاجرت کنید. می‌توانید از راه‌حل‌های شخص ثالثی که نیاز به کنسول مدیریت دیگری یا ویرایش دستی فایل‌های پیکربندی دارند اجتناب کنید.
دسترسی به خدمات وب خارجی قابل اعتماد
Cloud SWP به شما امکان می‌دهد سیاست‌های دسترسی گرانول را برای ترافیک وب خروجی خود اعمال کنید تا بتوانید شبکه خود را ایمن کنید. شما حجم کار یا هویت برنامه ها را ایجاد و شناسایی می کنید و سپس سیاست ها را اعمال می کنید.
نظارت بر دسترسی به خدمات وب غیرقابل اعتماد
می‌توانید از Cloud SWP برای دسترسی نظارت شده به سرویس‌های وب غیرقابل اعتماد استفاده کنید. Cloud SWP ترافیکی را که با خط مشی مطابقت ندارد شناسایی می کند و آن را در Cloud Logging (Logging) ثبت می کند. سپس می توانید استفاده از اینترنت را کنترل کنید، تهدیدات شبکه خود را کشف کنید و به تهدیدات پاسخ دهید.
کنترل‌های خط مشی ریز برای APIهای Google
می‌توانید از Cloud SWP برای ارائه خط‌مشی‌های دقیق برای APIهای Google استفاده کنید. برای مثال، می‌توانید خط‌مشی‌های سطح سطل/شی را با استفاده از زبان عبارات رایج (CEL) تنظیم کنید.
ویژگی های پشتیبانی شده
Cloud SWP از ویژگی های زیر پشتیبانی می کند:
سرویس پروکسی صریح
کلاینت ها باید به طور صریح برای استفاده از سرور پراکسی پیکربندی شوند. پروکسی Cloud SWP با ایجاد اتصالات TCP جدید از طرف مشتری، مشتریان را از اینترنت جدا می کند.
مقیاس خودکار پروکسی های Cloud SWP Envoy
از تنظیم خودکار اندازه استخر پروکسی Envoy و ظرفیت استخر در یک منطقه پشتیبانی می‌کند، که عملکرد ثابت را در دوره‌های پرتقاضا با کمترین هزینه ممکن می‌سازد.
سیاست های دسترسی خروجی مدولار
Cloud SWP به طور خاص از سیاست های خروج زیر پشتیبانی می کند:
- هویت منبع بر اساس برچسب‌های ایمن، حساب‌های سرویس یا آدرس‌های IP.
- مقصد بر اساس URL ها، نام میزبان.
- درخواست ها بر اساس روش ها، سرصفحه ها یا URL ها. URL ها را می توان با استفاده از لیست ها، حروف عام یا الگوها مشخص کرد.
- رمزگذاری سرتاسر: تونل های پروکسی مشتری ممکن است از طریق TLS عبور کنند. Cloud SWP همچنین از HTTP/S CONNECT برای اتصالات TLS سرتاسری به سرور مقصد که توسط کلاینت آغاز می شود، پشتیبانی می کند.
ادغام Cloud NAT ساده شده
Cloud NAT به‌طور خودکار آدرس‌های IP عمومی اضافی را زمانی که مجموعه پراکسی‌هایی که ترافیک Cloud SWP را ارائه می‌کنند، ارائه می‌کند.
آدرس های IP عمومی استاتیک دستی نیز گزینه ای برای کسانی است که می خواهند IP های خروجی شناخته شده داشته باشند.
گزارش‌های حسابرسی ابری و مجموعه عملیات Google Cloud یکپارچه‌سازی می‌شوند
Cloud Audit Logs و مجموعه عملیات Google Cloud فعالیت‌های اداری و درخواست‌های دسترسی به منابع مربوط به Cloud SWP را ثبت می‌کنند. آنها همچنین معیارها و گزارش تراکنش‌ها را برای درخواست‌هایی که توسط پروکسی رسیدگی می‌شود، ثبت می‌کنند.
بازرسی TLS
Secure Web Proxy یک سرویس بازرسی TLS را ارائه می دهد که به شما امکان می دهد ترافیک TLS را رهگیری کنید، درخواست رمزگذاری شده را بررسی کنید و سیاست های امنیتی را اعمال کنید.
- ادغام دقیق با Certificate Authority Service (CAS)، که یک مخزن بسیار در دسترس و مقیاس پذیر برای CAهای خصوصی است.
- توانایی استفاده از ریشه اعتماد خود در صورت لزوم. همچنین می توانید از یک CA ریشه موجود برای امضای CAهای تابعه که توسط CAS نگهداری می شوند استفاده کنید. اگر ترجیح می دهید، می توانید یک گواهی ریشه جدید در CAS ایجاد کنید.
- معیارهای رمزگشایی دانه ای با استفاده از SessionMatcher و ApplicationMatcher در قوانین خط مشی پروکسی وب امن. این معیار شامل میزبان های تطبیق موجود در لیست های URL، عبارات منظم، محدوده آدرس IP و عبارات مشابه است. در صورت لزوم، معیارها را می توان با عبارات بولی ترکیب کرد.
- هر خط مشی پروکسی وب امن را می توان با خط مشی بازرسی TLS و استخر CA پیکربندی کرد. از طرف دیگر، چندین خط مشی پروکسی وب امن می توانند یک خط مشی بازرسی TLS را به اشتراک بگذارند.
چیزی که یاد خواهید گرفت
- نحوه استقرار و مدیریت Cloud SWP.
آنچه شما نیاز دارید
- دانش استقرار نمونه ها و پیکربندی اجزای شبکه
- دانش پیکربندی فایروال VPC
2. محیط تست
این کد لبه از یک VPC استفاده می کند. همانطور که در نمودار زیر مشاهده می شود، یک منبع محاسباتی در این محیط با استفاده از Cloud SWP خارج می شود.
در این آزمایشگاه 2 ماشین مجازی حجم کاری خواهیم داشت.
کلاینت A برای ارسال تمام درخواست های HTTP/HTTPS به Cloud SWP پیکربندی می شود.
کلاینت B برای ارسال صریح درخواست های HTTP/HTTPS به Cloud SWP پیکربندی نمی شود، اما در عوض از Cloud NAT برای ترافیک محدود به اینترنت استفاده می کند.
3. قبل از شروع
Codelab به یک پروژه واحد نیاز دارد.
در داخل 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. API ها را فعال کنید
API ها را برای استفاده از محصولات فعال کنید
gcloud services enable networksecurity.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable networkservices.googleapis.com
5. شبکه VPC، زیرشبکه و زیر شبکه فقط پروکسی ایجاد کنید
شبکه VPC
ایجاد کدlab-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. قوانین فایروال را ایجاد کنید
برای اینکه به IAP اجازه دهید به نمونه های VM شما متصل شود، یک قانون فایروال ایجاد کنید که:
- برای تمام نمونه های VM که می خواهید با استفاده از IAP در دسترس باشند، اعمال می شود.
- به ترافیک ورودی از محدوده IP 35.235.240.0/20 اجازه می دهد. این محدوده شامل تمام آدرس های IP است که IAP برای ارسال TCP استفاده می کند.
از پوسته ابری:
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 Router برای Cloud NAT.
gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc
دروازه NAT Cloud را برای Client B ایجاد کنید.
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
دستور gcloud را برای ایجاد خط مشی از فایل yaml اجرا کنید:
gcloud network-security gateway-security-policies import ${prefix}-policy --source=/tmp/policy.yaml --location=${region}
9. یک قانون سیاست امنیتی دروازه ایجاد کنید
یک فایل yaml ایجاد کنید که حاوی قوانین است. این قوانین به زبان Common Expression Language (CEL) نشان داده شده است. این آزمایشگاه از قانون ساده ای استفاده می کند که به ترافیک دامنه های 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 را برای SWP Gateway ایجاد کنید تا به اطلاعات قبلی مانند گواهی، خط مشی امنیتی دروازه، شبکه و زیرشبکه ارجاع دهید.
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 یک پروکسی صریح است، باید به صراحت IP پروکسی را برای ترافیک حجم کاری مشخص کنیم. 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. تطبیق جلسه تست
SSH به "clienta" محاسبه VM اخیرا ایجاد شده است. این VM دارای متغیر محیطی برای استفاده از Cloud SWP است.
از پوسته ابری:
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
برای تأیید رفتار، می توانید دامنه های دیگر را نیز امتحان کنید.
از جلسه SSH به "clienta" خارج شوید و یک اتصال SSH جدید به "clientb" را آغاز کنید.
gcloud compute ssh clientb --zone=$zone --tunnel-through-iap
چند دستور curl را برای بررسی رفتار اجرا کنید:
curl https://google.com
این باید مطابق با مشتری 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. یک قانون سیاست امنیتی دروازه برای 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
SSH به VM محاسباتی مشتری. این VM دارای متغیر محیطی برای استفاده از Cloud SWP است.
از پوسته ابری:
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 است.
توجه داشته باشید که این یک درخواست HTTP است. در مرحله بعد، باید SWP را فعال کنید تا قابلیت های بازرسی TLS را داشته باشد.
بعد همان پرس و جو را اجرا کنید اما از طریق TLS:
curl -k https://google.com/index.html --proxy-insecure
خروجی مورد انتظار:
curl: (56) Received HTTP code 403 from proxy after CONNECT
این درخواست باید شکست بخورد زیرا SWP برای بازرسی TLS پیکربندی نشده است و نمی تواند مسیر را در برابر قانون applicationMatcher ارزیابی کند.
از کلنتا خارج شوید
16. TLS Inspection را فعال کنید
بدون بازرسی TLS، applicationMatcher با ترافیک HTTPS مطابقت نخواهد داشت.
"applicationMatcher" اجازه فیلتر کردن موارد زیر را می دهد:
- درخواست نقشه سرصفحه
- روش درخواست
- درخواست میزبان
- مسیر درخواست
- درخواست پرس و جو
- طرح درخواست
- آدرس کامل درخواست
- کاربر عامل را درخواست کنید
ایجاد حساب سرویس
این حساب سرویس دارای مجوزهایی برای تولید گواهی برای بازرسی SWP TLS خواهد بود.
gcloud beta services identity create \
--service=networksecurity.googleapis.com \
--project=$project_id
اطمینان حاصل کنید که CAS فعال است
gcloud services enable privateca.googleapis.com
یک استخر CA ایجاد کنید
gcloud privateca pools create $prefix-ca-pool \
--tier=devops \
--project=$project_id \
--location=$region
Root CA را ایجاد کنید
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
فایل yaml بازرسی TLS ایجاد کنید
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 Pool را به روز کنید
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
سیاست yaml را به‌روزرسانی کنید تا بازرسی TLS را نیز شامل شود
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 به روز کنید
سپس مشخص کنید چه قوانینی باید دارای پرچم بازرسی 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 Inspection
SSH به VM محاسبه مشتری. این VM دارای متغیر محیطی برای استفاده از Cloud SWP است.
از پوسته ابری:
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>
ما با موفقیت Cloud SWP را برای بازرسی TLS و ارزیابی منطق applicationMatcher راه‌اندازی کردیم!
خروج از مشتری
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
زیرشبکه ها، قوانین 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. تبریک می گویم!
برای تکمیل کد لبه تبریک می گویم. شما با موفقیت Cloud Secure Web Proxy را در Google Cloud پیکربندی و مستقر کرده اید.
آنچه را پوشش داده ایم
- Cloud SWP و مزایا!