این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

Cloud Secure Web Proxy (SWP) Codelab

۱. مقدمه

پروکسی وب امن ابری

Cloud SWP یک سرویس ابری است که یک پروکسی وب امن برای کمک به شما در ایمن‌سازی ترافیک وب خروجی (HTTP/S) ارائه می‌دهد. شما کلاینت‌های خود را طوری پیکربندی می‌کنید که صریحاً از Cloud SWP به عنوان پروکسی استفاده کنند. درخواست‌های وب می‌توانند از منابع زیر سرچشمه بگیرند:

نمونه‌های ماشین مجازی (VM)
ظروف
یک محیط بدون سرور که از یک رابط بدون سرور استفاده می‌کند
حجم کار در سراسر VPC Peering
بارهای کاری خارج از Google Cloud که از طریق Cloud VPN یا Cloud Interconnect متصل شده‌اند

Cloud SWP سیاست‌های انعطاف‌پذیر و جزئی را بر اساس هویت‌های مبتنی بر ابر و برنامه‌های وب فعال می‌کند.

مزایا

در زیر چند نمونه از مزایایی که Cloud SWP می‌تواند برای یک سازمان فراهم کند، آورده شده است:

مهاجرت به فضای ابری گوگل

Cloud SWP به شما کمک می‌کند تا ضمن حفظ سیاست‌های امنیتی و الزامات موجود برای ترافیک وب خروجی، به Google Cloud مهاجرت کنید. می‌توانید از استفاده از راه‌حل‌های شخص ثالث که به کنسول مدیریتی دیگری نیاز دارند یا ویرایش دستی فایل‌های پیکربندی اجتناب کنید.

دسترسی به سرویس‌های وب خارجی قابل اعتماد

Cloud SWP به شما امکان می‌دهد سیاست‌های دسترسی جزئی را برای ترافیک وب خروجی خود اعمال کنید تا بتوانید شبکه خود را ایمن کنید. شما هویت‌های بار کاری یا برنامه‌های کاربردی را ایجاد و شناسایی می‌کنید و سپس سیاست‌ها را اعمال می‌کنید.

دسترسی تحت نظارت به سرویس‌های وب غیرقابل اعتماد

شما می‌توانید از Cloud SWP برای ارائه دسترسی تحت نظارت به سرویس‌های وب غیرقابل اعتماد استفاده کنید. Cloud SWP ترافیکی را که با خط‌مشی‌ها مطابقت ندارد شناسایی کرده و آن را در Cloud Logging (ثبت وقایع) ثبت می‌کند. سپس می‌توانید استفاده از اینترنت را رصد کنید، تهدیدات شبکه خود را کشف کنید و به تهدیدات پاسخ دهید.

کنترل‌های جزئی سیاست برای APIهای گوگل

شما می‌توانید از Cloud SWP برای ارائه سیاست‌های جزئی‌تر برای APIهای گوگل استفاده کنید. به عنوان مثال، می‌توانید سیاست‌های سطح سطل/شی را با استفاده از زبان بیان مشترک (CEL) تنظیم کنید.

ویژگی‌های پشتیبانی‌شده

Cloud SWP از ویژگی‌های زیر پشتیبانی می‌کند:

سرویس پروکسی صریح

کلاینت‌ها باید به طور صریح برای استفاده از سرور پروکسی پیکربندی شوند. پروکسی Cloud SWP با ایجاد اتصالات TCP جدید از طرف کلاینت، آنها را از اینترنت جدا می‌کند.

مقیاس‌بندی خودکار پروکسی‌های Cloud SWP Envoy

از تنظیم خودکار اندازه مخزن پروکسی Envoy و ظرفیت مخزن در یک منطقه پشتیبانی می‌کند، که عملکرد پایدار را در دوره‌های تقاضای بالا با کمترین هزینه امکان‌پذیر می‌سازد.

سیاست‌های دسترسی خروجی ماژولار

Cloud SWP به طور خاص از سیاست‌های خروجی زیر پشتیبانی می‌کند:

هویت منبع بر اساس برچسب‌های امن، حساب‌های سرویس یا آدرس‌های IP.
مقاصد بر اساس URLها، نام‌های میزبان.
درخواست‌های مبتنی بر متدها، هدرها یا URLها. URLها را می‌توان با استفاده از لیست‌ها، کاراکترهای جایگزین (wildcards) یا الگوها مشخص کرد.
رمزگذاری سرتاسری: تونل‌های پروکسی کلاینت ممکن است از طریق TLS منتقل شوند. Cloud SWP همچنین از HTTP/S CONNECT برای اتصالات TLS سرتاسری و آغاز شده توسط کلاینت به سرور مقصد پشتیبانی می‌کند.

یکپارچه‌سازی ساده‌شده‌ی Cloud NAT

Cloud NAT به طور خودکار آدرس‌های IP عمومی بیشتری را در زمانی که مجموعه پروکسی‌هایی که ترافیک Cloud SWP را ارائه می‌دهند افزایش می‌یابد، فراهم می‌کند.

آدرس‌های IP عمومی استاتیک دستی نیز گزینه‌ای برای کسانی است که می‌خواهند IPهای خروجی شناخته‌شده‌ای داشته باشند.

یکپارچه‌سازی گزارش‌های حسابرسی ابری و مجموعه عملیات گوگل کلود

گزارش‌های حسابرسی ابری و مجموعه عملیات گوگل کلود، فعالیت‌های مدیریتی و درخواست‌های دسترسی به منابع مرتبط با Cloud SWP را ثبت می‌کنند. آن‌ها همچنین معیارها و گزارش‌های تراکنش را برای درخواست‌های رسیدگی شده توسط پروکسی ثبت می‌کنند.

بازرسی TLS

Secure Web Proxy یک سرویس بازرسی TLS ارائه می‌دهد که به شما امکان می‌دهد ترافیک TLS را رهگیری کنید، درخواست رمزگذاری شده را بررسی کنید و سیاست‌های امنیتی را اعمال کنید.

ادغام کامل با سرویس مرجع صدور گواهی (CAS)، که یک مخزن با قابلیت دسترسی بالا و مقیاس‌پذیر برای CA های خصوصی است.
امکان استفاده از root of trust خودتان در صورت نیاز. همچنین می‌توانید از یک root CA موجود برای امضا با subordinate CA های نگهداری شده توسط CAS استفاده کنید. در صورت تمایل، می‌توانید یک root certificate جدید در CAS ایجاد کنید.
معیارهای رمزگشایی جزئی با استفاده از SessionMatcher و ApplicationMatcher در چارچوب قوانین سیاست Secure Web Proxy. این معیار شامل تطبیق میزبان‌های موجود در لیست‌های URL، عبارات منظم، محدوده‌های آدرس IP و عبارات مشابه می‌شود. در صورت لزوم، معیارها را می‌توان با عبارات بولی ترکیب کرد.
هر سیاست Secure Web Proxy می‌تواند با سیاست بازرسی TLS و مجموعه CA خود پیکربندی شود. از طرف دیگر، چندین سیاست Secure Web Proxy می‌توانند یک سیاست بازرسی TLS واحد را به اشتراک بگذارند.

آنچه یاد خواهید گرفت

نحوه استقرار و مدیریت Cloud SWP.

آنچه نیاز دارید

آشنایی با پیاده‌سازی نمونه‌ها و پیکربندی اجزای شبکه
دانش پیکربندی فایروال VPC

۲. محیط آزمایش

این آزمایشگاه کد از یک VPC واحد استفاده خواهد کرد. یک منبع محاسباتی در این محیط با استفاده از Cloud SWP همانطور که در نمودار زیر مشاهده می‌شود، خارج می‌شود.

در این آزمایش، ما دو ماشین مجازی با حجم کاری خواهیم داشت.

کلاینت A طوری پیکربندی خواهد شد که تمام درخواست‌های HTTP/HTTPS را به Cloud SWP ارسال کند.

کلاینت B طوری پیکربندی نخواهد شد که صریحاً درخواست‌های HTTP/HTTPS را به Cloud SWP ارسال کند، بلکه در عوض از Cloud NAT برای ترافیک محدود به اینترنت استفاده می‌کند.

۳. قبل از شروع

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"

۴. فعال کردن APIها

فعال کردن APIها برای استفاده از محصولات

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com

۵. ایجاد شبکه، زیرشبکه و زیرشبکه فقط پروکسی 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

۶. ایجاد قوانین فایروال

برای اینکه به IAP اجازه دهید به ماشین‌های مجازی شما متصل شود، یک قانون فایروال ایجاد کنید که:

برای تمام نمونه‌های ماشین مجازی که می‌خواهید با استفاده از IAP به آنها دسترسی داشته باشید، اعمال می‌شود.
اجازه ورود ترافیک از محدوده IP 35.235.240.0/20 را می‌دهد. این محدوده شامل تمام آدرس‌های IP است که IAP برای ارسال TCP استفاده می‌کند.

از cloudshell:

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

۷. ایجاد روتر ابری و NAT ابری

ایجاد روتر ابری برای Cloud NAT.

gcloud compute routers create ${prefix}-cr \
--region=$region \
--network=${prefix}-vpc

ایجاد Cloud NAT Gateway برای کلاینت 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

۸. ایجاد یک سیاست امنیتی دروازه (Gateway Security Policy)

یک فایل 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}

۹. ایجاد یک قانون سیاست امنیتی دروازه (Gateway Security Policy)

یک فایل yaml ایجاد کنید که شامل قوانین باشد. این قوانین به زبان عبارات مشترک (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

اکنون می‌توانیم این قانون را به سیاست امنیتی دروازه (gateway security policy) متصل کنیم:

gcloud network-security gateway-security-policies rules import rule-com --source=/tmp/rule-com.yaml --location=${region} --gateway-security-policy=${prefix}-policy

۱۰. یک گواهی ایجاد کنید و در 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

۱۱. ایجاد دروازه 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}

۱۲. ایجاد نمونه‌های محاسباتی

از آنجایی که Cloud SWP یک پروکسی صریح است، باید IP پروکسی را برای ترافیک بار کاری به صراحت مشخص کنیم. متغیر محیطی در نمونه محاسبه شده 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
'

۱۳. تست تطبیق جلسه

SSH به ماشین مجازی محاسباتی "clienta" که اخیراً ایجاد شده است. این ماشین مجازی دارای متغیر محیطی است که برای استفاده از Cloud SWP تنظیم شده است.

از cloudshell:

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

برای تأیید رفتار، می‌توانید دامنه‌های دیگر را نیز امتحان کنید.

از جلسه SSH به "clienta" خارج شوید و یک اتصال SSH جدید به "clientb" برقرار کنید.

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

برای بررسی رفتار، چند دستور curl اجرا کنید:

curl https://google.com

این باید طبق انتظار در ماشین مجازی clientb کار کند:

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>

آزمایش در برابر دامنه org:

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 باشد مجاز است و سایر مقاصد رد می‌شوند.

خروج از کلاینتb.

۱۴. به‌روزرسانی قانون سیاست امنیتی دروازه برای تطبیق برنامه

بیایید این قانون را به‌روزرسانی کنیم تا با جزئیات سطح برنامه مطابقت داشته باشد. ما قانونی خواهیم ساخت که مسیر درخواست را بررسی کند و فقط در صورتی که با 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

۱۵. تست قانون ApplicationMatcher

به ماشین مجازی محاسباتی کلاینت SSH وصل شوید. متغیر محیطی این ماشین مجازی روی استفاده از Cloud SWP تنظیم شده است.

از cloudshell:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

curl http://google.com --proxy-insecure

توجه داشته باشید که این کوئری وقتی قبلاً با موفقیت ارسال شده باشد، با شکست مواجه خواهد شد.

Access denied

هر مسیر درخواستی غیر از "index.html" باید با خطای ۴۰۳ مسدود شود. می‌توانید این مورد را بیشتر آزمایش کنید.

کوئری را طوری تغییر دهید که مسیر /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>

انتظار می‌رود که شاهد ریدایرکت ۳۰۱ باشیم، زیرا وب‌سایت به آدرس 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 ارزیابی کند.

از کلنتا خارج شوید.

۱۶. فعال کردن بازرسی TLS

بدون بازرسی 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

ایجاد 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

۱۷. بازرسی TLS را آزمایش کنید

به ماشین مجازی محاسباتی کلاینت SSH وصل شوید. متغیر محیطی این ماشین مجازی روی استفاده از Cloud SWP تنظیم شده است.

از cloudshell:

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 راه‌اندازی کردیم!

خروج از حساب مشتریان.

۱۸. مراحل پاکسازی

از 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

۱۹. تبریک می‌گویم!

تبریک بابت تکمیل آزمایشگاه کد. شما با موفقیت Cloud Secure Web Proxy را روی Google Cloud پیکربندی و مستقر کرده‌اید.

آنچه ما پوشش داده‌ایم

Cloud SWP و مزایای آن!

Cloud Secure Web Proxy (SWP) Codelab با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

۱. مقدمه

پروکسی وب امن ابری

مزایا

مهاجرت به فضای ابری گوگل

دسترسی به سرویس‌های وب خارجی قابل اعتماد

دسترسی تحت نظارت به سرویس‌های وب غیرقابل اعتماد

کنترل‌های جزئی سیاست برای APIهای گوگل

ویژگی‌های پشتیبانی‌شده

سرویس پروکسی صریح

مقیاس‌بندی خودکار پروکسی‌های Cloud SWP Envoy

سیاست‌های دسترسی خروجی ماژولار

یکپارچه‌سازی ساده‌شده‌ی Cloud NAT

یکپارچه‌سازی گزارش‌های حسابرسی ابری و مجموعه عملیات گوگل کلود

بازرسی TLS

آنچه یاد خواهید گرفت

آنچه نیاز دارید

۲. محیط آزمایش

۳. قبل از شروع

۴. فعال کردن APIها

۵. ایجاد شبکه، زیرشبکه و زیرشبکه فقط پروکسی VPC

۶. ایجاد قوانین فایروال

۷. ایجاد روتر ابری و NAT ابری

۸. ایجاد یک سیاست امنیتی دروازه (Gateway Security Policy)

۹. ایجاد یک قانون سیاست امنیتی دروازه (Gateway Security Policy)

۱۰. یک گواهی ایجاد کنید و در Cloud Certificate Manager آپلود کنید

۱۱. ایجاد دروازه SWP

۱۲. ایجاد نمونه‌های محاسباتی

۱۳. تست تطبیق جلسه

۱۴. به‌روزرسانی قانون سیاست امنیتی دروازه برای تطبیق برنامه

۱۵. تست قانون ApplicationMatcher

۱۶. فعال کردن بازرسی TLS

ایجاد حساب کاربری سرویس

اطمینان حاصل کنید که CAS فعال است

ایجاد یک مخزن CA

ایجاد CA ریشه

ایجاد فایل سیاست صدور گواهی

ایجاد فایل yaml بازرسی TLS

ایجاد سیاست بازرسی TLS

به‌روزرسانی CA Pool برای استفاده از سیاست صدور گواهی

اعطای مجوزها

به‌روزرسانی خط‌مشی yaml برای گنجاندن بازرسی TLS

به‌روزرسانی قوانین برای گنجاندن بازرسی TLS

۱۷. بازرسی TLS را آزمایش کنید

۱۸. مراحل پاکسازی

۱۹. تبریک می‌گویم!

آنچه ما پوشش داده‌ایم

Cloud Secure Web Proxy (SWP) Codelab