שלבי הגדרה ראשוניים

במסמך הזה מתוארים שלבי ההגדרה הראשוניים שנדרשים כדי להשתמש ב-Secure Web Proxy.

הערה: צריך לבצע את שלבי ההגדרה האלה רק לפני השימוש הראשון ב-Secure Web Proxy.

איך מקבלים תפקידים והרשאות ב-IAM

כדי לקבל את ההרשאות שנדרשות להקצאת מופע של Secure Web Proxy, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

• כדי להגדיר כללי מדיניות ולספק מופע של Secure Web Proxy:‏ Compute Network Admin role‏ (roles/compute.networkAdmin)
• כדי להעלות אישורי TLS מפורשים של Secure Web Proxy: תפקיד עורך ב-Certificate Manager (roles/certificatemanager.editor)

כדי לקרוא הסבר על מתן תפקידים, קראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

אופציונלי: אם יש לכם קבוצת משתמשים שאחראית על ניהול מדיניות האבטחה של הארגון ב-Compute Engine, אתם יכולים להקצות להם את התפקיד 'אדמין מדיניות אבטחה של ארגון ב-Compute' (roles/compute.orgSecurityPolicyAdmin).

מידע נוסף על תפקידים והרשאות בפרויקט:

• חומרי עזר שקשורים לניהול זהויות והרשאות גישה
• מאמרי עזרה של Compute Engine API
• חומרי עזר בנושא Cloud Monitoring API

יצירת Google Cloud פרויקט

כדי ליצור או לבחור Google Cloud פרויקט:

המסוף

1. נכנסים לדף לבחירת הפרויקט במסוף Google Cloud .

   כניסה לדף לבחירת הפרויקט

2. יוצרים פרויקט Google Cloud או בוחרים פרויקט קיים.

gcloud

אפשר לפעול לפי אחד מהשלבים הבאים:

• כדי ליצור פרויקט Google Cloud , משתמשים בפקודה gcloud projects create.

  gcloud projects create PROJECT_ID
  

  מחליפים את PROJECT_ID במזהה פרויקט ייחודי.

• כדי לבחור Google Cloud פרויקט קיים, משתמשים בפקודה gcloud config set.

  gcloud config set project PROJECT_ID
  

הפעלת החיוב

מוודאים שהחיוב מופעל בפרויקט Google Cloud . מידע נוסף זמין במאמרים הפעלה, השבתה ושינוי של חיוב בפרויקט ואימות סטטוס החיוב של הפרויקטים.

הפעלת ממשקי ה-API הנדרשים

המסוף

1. נכנסים לדף Enable access to APIs במסוף Google Cloud .

   מעבר אל הפעלת גישה לממשקי API

   פועלים לפי ההוראות כדי להפעיל את ממשקי ה-API הנדרשים האלה: Compute Engine API,‏ Certificate Manager API,‏ Network Services API ו-Network Security API.

2. אופציונלי: אם אתם מתכננים להגדיר בדיקת TLS לשרת ה-proxy, אתם צריכים להפעיל את Certificate Authority Service API.

   מעבר אל הפעלת גישה ל-API

gcloud

כדי להפעיל את ממשקי ה-API הנדרשים, משתמשים בפקודה gcloud services enable. Google Cloud

gcloud services enable \
    compute.googleapis.com \
    certificatemanager.googleapis.com \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    privateca.googleapis.com

אופציונלי: אם אתם מתכננים להגדיר בדיקת TLS לשרת ה-proxy, אתם צריכים להפעיל את Certificate Authority Service (privateca.googleapis.com) API.

יצירת רשת משנה של VPC

יוצרים תת-רשת ברשת ה-VPC לכל אזור שבו רוצים לפרוס את מכונת Secure Web Proxy. אם יצרתם בעבר רשת משנה, אתם יכולים להשתמש בה שוב כרשת משנה של VPC על ידי הגדרת הפרמטר purpose לערך PRIVATE.

חשוב: יש הפניה לרשתות משנה של VPC כשיוצרים מופע של Secure Web Proxy.

gcloud

כדי ליצור רשת משנה, משתמשים בפקודה gcloud compute networks subnets create.

gcloud compute networks subnets create VPC_SUBNET_NAME \
    --purpose=PRIVATE \
    --region=REGION \
    --network=NETWORK_NAME \
    --range=IP_RANGE

מחליפים את מה שכתוב בשדות הבאים:

• ‫VPC_SUBNET_NAME: השם של רשת המשנה של ה-VPC
• ‫REGION: האזור שבו רוצים לפרוס את תת-הרשת של ה-VPC
• ‫NETWORK_NAME: השם של רשת ה-VPC
• ‫IP_RANGE: טווח תת-הרשת, למשל 10.10.10.0/24

יצירת רשת משנה של שרת proxy

יוצרים רשת משנה של שרת Proxy לכל אזור שבו רוצים לפרוס את מופע Secure Web Proxy.

מומלץ ליצור תת-רשת בגודל /23, שיכולה לאחסן עד 512 כתובות של שרת proxy בלבד. מערכת Secure Web Proxy משתמשת בטווח הזה כדי להקצות מאגר ייעודי של כתובות IP ייחודיות. המאגר השמור הזה עוזר לוודא שלשרת ה-proxy יש מספיק קיבולת כדי להתמודד עם שינוי גודל ולקיים אינטראקציה מאובטחת עם Cloud NAT ויעדים ברשת ה-VPC.

חשוב: לא מתבצעת הפניה לרשתות משנה של פרוקסי בלבד כשיוצרים מופע של Secure Web Proxy. מידע נוסף זמין במאמר רשתות משנה לשימוש פרוקסי בלבד במאזני עומסים מבוססי Envoy.

gcloud

כדי ליצור רשת משנה של שרת proxy, משתמשים בפקודה gcloud compute networks subnets create.

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=NETWORK_NAME \
    --range=IP_RANGE

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROXY_SUBNET_NAME: השם של תת-רשת ה-proxy
• ‫REGION: האזור שבו רוצים לפרוס את רשת המשנה של ה-proxy
• ‫NETWORK_NAME: השם של רשת ה-VPC
• ‫IP_RANGE: טווח תת-הרשת, למשל 192.168.0.0/23

פריסת אישור TLS

מכיוון שהפונקציה הבסיסית ביותר שמוגדרת כברירת מחדל ב-Secure Web Proxy – אכיפת מדיניות ללא בדיקה מעמיקה – לא דורשת אישורי אבטחת שכבת התעבורה (TLS), אישורי TLS (לשעבר SSL) הם אופציונליים ב-Secure Web Proxy.

נדרשים אישורי TLS ל-Secure Web Proxy רק כשהלקוחות – עומסי העבודה, האפליקציות או המכשירים ברשת שלכם – מתחברים לשרת ה-proxy באמצעות HTTPS. מידע נוסף זמין בסקירה הכללית על אישורי SSL.

כדי לפרוס אישורי TLS באמצעות Certificate Manager, אפשר להשתמש באחת מהשיטות הבאות:

• פריסת אישור אזורי שמנוהל על ידי Google עם הרשאת DNS לכל פרויקט

• פריסת אישור אזורי שמנוהל על ידי Google באמצעות Certificate Authority Service

• פריסת אישור אזורי בניהול עצמי

בדוגמה הבאה מוצג איך פורסים אישור אזורי בניהול עצמי באמצעות Certificate Manager:

1. ליצור אישור TLS.

   openssl req -x509 -newkey rsa:2048 \
       -keyout KEY_PATH \
       -out CERTIFICATE_PATH -days 365 \
       -subj '/CN=SWP_HOST_NAME' -nodes -addext \
       "subjectAltName=DNS:SWP_HOST_NAME"
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KEY_PATH: הנתיב שבו יישמר המפתח הפרטי, למשל ~/key.pem
   • CERTIFICATE_PATH: הנתיב שבו יישמר האישור, למשל ~/cert.pem
   • ‫SWP_HOST_NAME: שם המארח של מופע Secure Web Proxy, למשל myswp.example.com

2. העלאת אישור TLS ל-Certificate Manager

3. פריסת אישור TLS במאזן עומסים

המאמרים הבאים

• יצירה ופריסה של מופע Secure Web Proxy
• הפעלת בדיקת TLS
• יצירת מדיניות
• הגדרת כללים