שימוש בחשבונות שירות ליצירת כללי מדיניות

חשבון שירות הוא חשבון Google מיוחד לא אנושי שאפליקציות, תהליכים אוטומטיים או עומסי עבודה, כמו מכונה של Compute Engine, משתמשים בו כדי לבצע קריאות מורשות ל-API. בניגוד לחשבונות משתמשים, חשבון שירות מזוהה רק באמצעות כתובת האימייל הייחודית שלו.

אפליקציות משתמשות בחשבונות שירות כדי לבצע אימות ולקבל גישה למשאבים ב-Google Cloud . כשאפליקציה מבצעת אימות באמצעות חשבון שירות, היא מקבלת גישה למשאבים שהוקצו לחשבון השירות הרשאות מפורשות לניהול זהויות והרשאות גישה (IAM). השיטה הזו מספקת אימות מאובטח, ניתן לביקורת ומרכזי של מכונה למכונה.

ב-Secure Web Proxy, חשבונות שירות ממלאים תפקיד חשוב בהרשאה ובאכיפת מדיניות. כשמשתמשים בחשבון שירות כדי לזהות את מקור התנועה של עומס עבודה, אפשר ליצור מדיניות מפורטת של Secure Web Proxy שמאפשרת או חוסמת תנועת אינטרנט באופן ספציפי על סמך הזהות של האפליקציה, ולא רק על סמך כתובת ה-IP שלה.

בדף הזה מוסבר איך:

לפני שמתחילים

  • משלימים את השלבים להגדרה הראשונית.

  • שולחים בקשה למנהל חשבון ארגוני לתת לכם גישה לחשבון שירות.

  • מוודאים שמותקנת אצלכם גרסה 406.0.0 או גרסה מתקדמת יותר של Google Cloud CLI:

    gcloud version | head -n1
    

    אם מותקנת אצלכם גרסה קודמת של ה-CLI של gcloud, צריך לעדכן את הגרסה:

    gcloud components update --version=406.0.0
    

יצירת מופע של Secure Web Proxy עם מדיניות ריקה

כדי ליצור מופע של Secure Web Proxy, צריך קודם ליצור מדיניות אבטחה ריקה ואז ליצור פרוקסי אינטרנט שמשתמש במדיניות הזו.

יצירה של מדיניות אבטחה ריקה

המסוף

  1. נכנסים לדף SWP Policies במסוף Google Cloud .

    מעבר אל מדיניות SWP

  2. לוחצים על יצירת מדיניות.

  3. בשדה Name, מזינים שם למדיניות, כמו myswppolicy.

  4. בשדה Description (תיאור) מזינים תיאור למדיניות, למשל My new swp policy.

  5. בקטע אזורים, בוחרים את האזור שבו רוצים ליצור את המדיניות, כמו us-central1.

  6. לוחצים על יצירה.

Cloud Shell

  1. משתמשים בעורך הטקסט המועדף כדי ליצור קובץ policy.yaml.

  2. מוסיפים את הטקסט הבא לקובץ policy.yaml שיצרתם:

    name: projects/PROJECT_NAME/locations/REGION/gatewaySecurityPolicies/POLICY_NAME
    description: POLICY_DESCRIPTION
    

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

    • PROJECT_NAME: שם הפרויקט

    • REGION: האזור שבו נוצרה המדיניות, למשל us-central1

    • POLICY_NAME: שם המדיניות

    • POLICY_DESCRIPTION: תיאור המדיניות

  3. מייבאים את מדיניות האבטחה באמצעות הפקודה gcloud network-security gateway-security-policies import:

    gcloud network-security gateway-security-policies import POLICY_NAME \
        --source=POLICY_FILE.yaml \
        --location=REGION
    

יצירת שרת proxy לאינטרנט

המסוף

  1. נכנסים לדף Web Proxies במסוף Google Cloud .

    מעבר ל-Web Proxies

  2. לוחצים על יצירת שרת proxy מאובטח לאינטרנט.

  3. בשדה Name, מזינים שם לשרת ה-proxy לאינטרנט, למשל myswp.

  4. בשדה Description (תיאור) מזינים תיאור לשרת ה-proxy לאינטרנט, כמו My new swp.

  5. בקטע מצב ניתוב, בוחרים באחת מהאפשרויות הבאות:

    • מפורש: פריסת מופע Secure Web Proxy במצב שרת proxy מפורש.
    • הצעד הבא: פריסת מופע Secure Web Proxy במצב 'הצעד הבא'.
  6. בקטע Regions (אזורים), בוחרים את האזור שבו רוצים ליצור את שרת ה-proxy לאינטרנט, כמו us-central1.

  7. בקטע רשת, בוחרים את הרשת שבה רוצים ליצור את שרת ה-proxy לאינטרנט.

  8. בשדה Subnetwork (תת-רשת), בוחרים את תת-הרשת של ה-VPC שיצרתם במהלך ההגדרה הראשונית.

  9. אופציונלי: בשדה כתובת ה-IP של שרת ה-proxy לאינטרנט, מזינים את כתובת ה-IP של Secure Web Proxy.

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

  10. בקטע Certificate, בוחרים את האישור שרוצים להשתמש בו כדי ליצור את פרוקסי האינטרנט.

  11. בקטע מדיניות, בוחרים את המדיניות שיצרתם כדי לשייך את שרת ה-proxy לאינטרנט.

  12. לוחצים על יצירה.

Cloud Shell

  1. משתמשים בעורך הטקסט המועדף כדי ליצור קובץ gateway.yaml.

  2. מוסיפים את הטקסט הבא לקובץ gateway.yaml:

    name: projects/PROJECT_NAME/locations/REGION/gateways/GATEWAY_NAME
    type: SECURE_WEB_GATEWAY
    ports: [GATEWAY_PORT_NUMBERS]
    certificateUrls: [CERTIFICATE_URLS]
    gatewaySecurityPolicy: projects/PROJECT_NAME/locations/REGION/gatewaySecurityPolicies/POLICY_NAME
    network: projects/PROJECT_NAME/global/networks/NETWORK_NAME
    subnetwork: projects/PROJECT_NAME/regions/REGION/subnetworks/SUBNETWORK
    routingMode: ROUTING_MODE
    addresses: [GATEWAY_IP_ADDRESS]
    scope: samplescope
    

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

    • GATEWAY_NAME: השם של מופע Secure Web Proxy

    • GATEWAY_PORT_NUMBERS: רשימה של מספרי יציאות לשער הזה, למשל [80,443]

    • CERTIFICATE_URLS: רשימה של כתובות URL של אישורי SSL

    • SUBNETWORK: רשת משנה של VPC שיצרתם במהלך ההגדרה הראשונית

    • ROUTING_MODE: מציינים את מצב הניתוב הנדרש של שרת ה-Proxy לאינטרנט:

      • EXPLICIT_ROUTING_MODE: פריסת מופע Secure Web Proxy במצב שרת proxy מפורש
      • NEXT_HOP_ROUTING_MODE: פריסת מופע Secure Web Proxy במצב next hop
    • GATEWAY_IP_ADDRESS: רשימה אופציונלית של כתובות IP של מופעי Secure Web Proxy ברשתות המשנה של ה-proxy שיצרתם קודם בשלבי ההגדרה הראשונית

      אם אתם בוחרים לא לפרט כתובות IP, אל תמלאו את השדה כדי לאפשר לשרת ה-proxy לבחור כתובת IP בשבילכם.

  3. יוצרים את מופע Secure Web Proxy באמצעות הפקודה gcloud network-services gateways import:

    gcloud network-services gateways import GATEWAY_NAME \
        --source=gateway.yaml \
        --location=REGION
    

בדיקת הקישוריות

כדי לבדוק את הקישוריות, משתמשים בפקודה curl מכל מופע של מכונה וירטואלית (VM) ברשת הענן הווירטואלי הפרטי (VPC):

  curl -x https://GATEWAY_IP_ADDRESS:PORT_NUMBER https://www.example.com --proxy-insecure

אם הכול פועל בצורה תקינה, מופע Secure Web Proxy מחזיר קוד סטטוס 403 Forbidden. השגיאה הזו מאשרת את הפרטים הבאים:

  • הפריסה של מופע Secure Web Proxy הושלמה בהצלחה והוא מקבל תנועה באופן פעיל.

  • מדיניות Secure Web Proxy אוכפת בצורה נכונה את מצב האבטחה שמוגדר כברירת מחדל, שבו כל התנועה נדחית עד שמגדירים כללי allow ספציפיים בקטעים הבאים.

יצירה של חשבון שירות והקצאת תפקידי IAM

  1. יצירת חשבון שירות: משתמשים בפקודה gcloud iam service-accounts create כדי ליצור חשבון שירות בשם my-swp-sa בפרויקט Google Cloud.

    gcloud iam service-accounts create my-swp-sa \
        --display-name="Secure Web Proxy service account" \
        --description="Service account for Secure Web Proxy instances"
  2. הקצאת תפקידי IAM לחשבון השירות: משתמשים בפקודה gcloud projects add-iam-policy-binding כדי להקצות את תפקידי ה-IAM הנדרשים לחשבון השירות, כדי שהוא יוכל לנהל משאבים ב Google Cloud פרויקט או להשתמש בהם.

    לדוגמה, כדי לאפשר לחשבון השירות להשתמש במשאבי רשת, צריך לתת לו את התפקיד Compute Network User ‏(roles/compute.networkUser).

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member="serviceAccount:my-swp-sa@PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/compute.networkUser"

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

יצירת כלל של Secure Web Proxy

המסוף

  1. נכנסים לדף SWP Policies במסוף Google Cloud .

    מעבר אל מדיניות SWP

  2. לוחצים על שם המדיניות שיצרתם קודם, למשל myswppolicy.

  3. לוחצים על הוספת כלל.

  4. לכל כלל, מבצעים את הפעולות הבאות:

    1. בשדה עדיפות, מזינים את סדר ההערכה המספרי של הכלל. הכללים מוערכים מהעדיפות הגבוהה ביותר לנמוכה ביותר, כאשר 0 היא העדיפות הגבוהה ביותר.

    2. בשדה Name, מזינים שם לכלל.

    3. בשדה Description (תיאור), מזינים תיאור לכלל.

    4. בקטע פעולה, בוחרים באחת מהאפשרויות הבאות:

      • אישור: כדי לאשר בקשות לחיבור שתואמות לכלל.
      • Deny: כדי לדחות בקשות לחיבור שתואמות לכלל.
    5. בשדה סטטוס, בוחרים אחת מהאפשרויות הבאות לאכיפת הכלל:

      • מופעלת: כדי לאכוף את הכלל במופע Secure Web Proxy.
      • מושבת: כדי לא לאכוף את הכלל במופע של Secure Web Proxy.
    6. בקטע Session Match, מציינים את כתובת האימייל של חשבון השירות שיצרתם קודם. לדוגמה:

        sessionMatcher: "source.matchServiceAccount(SERVICE_ACCOUNT) && host() == 'example.com'"
      

      מידע נוסף על התחביר של SessionMatcher זמין במאמר הפניה לשפת ההתאמה של CEL.

    7. בקטע Application Match, מציינים את הקריטריונים להתאמת הבקשה.

    8. לוחצים על הוספת כלל.

  5. כדי להוסיף עוד כלל, לוחצים על הוספת כלל.

Cloud Shell

  1. משתמשים בעורך הטקסט המועדף כדי ליצור את הקובץ rule.yaml.

  2. כדי לאפשר גישה לכתובת URL מחשבון השירות המתאים, מוסיפים את הקוד הבא לקובץ rule.yaml שיצרתם:

    name: projects/PROJECT_NAME/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
    description: RULE_DESCRIPTION
    enabled: true
    priority: RULE_PRIORITY
    sessionMatcher: CEL_EXPRESSION
    basicProfile: ALLOW
    

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

    • RULE_NAME: השם של הכלל
    • RULE_DESCRIPTION: תיאור הכלל
    • RULE_PRIORITY: העדיפות של הכלל הזה. מספר נמוך יותר מייצג עדיפות גבוהה יותר.
    • CEL_EXPRESSION: ביטוי של Common Expression Language ‏ (CEL). מידע נוסף זמין במאמר בנושא הפניה לשפת ההתאמה של CEL.

    לדוגמה, כדי לאפשר גישה ל-example.com מהמשאב עם חשבון השירות הנדרש, מוסיפים את השורות הבאות לקובץ ה-YAML שיצרתם עבור sessionMatcher:

    ```yaml
    sessionMatcher: "source.matchServiceAccount('SERVICE_ACCOUNT') && host() == 'example.com'"
    ```
    

    מחליפים את SERVICE_ACCOUNT בחשבון השירות שרוצים לאפשר. זו חייבת להיות כתובת האימייל של חשבון השירות.

  3. מייבאים את הכללים שיצרתם באמצעות הפקודה gcloud network-security gateway-security-policies rules import:

    gcloud network-security gateway-security-policies rules import RULE_NAME \
        --source=RULE_FILE.yaml \
        --location=REGION \
        --gateway-security-policy=POLICY_NAME
    

בדיקת הקישוריות

אפשר לבדוק שוב את הקישוריות כדי לוודא שכל ההגדרות של Secure Web Proxy – כולל חשבון השירות, כללי מדיניות האבטחה והשער – פועלות כמצופה.

כדי לבדוק את הקישוריות, משתמשים בפקודה curl מהמשאב – כמו מכונת VM – עם SERVICE_ACCOUNT המצורף:

curl -x https://IPv4_ADDRESS:443 http://example.com 
--proxy-insecure

מחליפים את IPv4_ADDRESS בכתובת ה-IPv4 של מופע Secure Web Proxy.

אם הכול פועל כמו שצריך, תקבלו קוד סטטוס 200 OK. קוד הסטטוס הזה מאשר את התוצאות העיקריות הבאות:

  • הרשאה מוצלחת: מוכיחה שהתנועה שמגיעה מהמשאב מזוהה בצורה נכונה על ידי חשבון השירות שהוקצה, ושהזהות הזו תואמת לכלל allow שהוספתם למדיניות האבטחה.

  • פונקציונליות מקצה לקצה: המערכת בודקת שהתנועה עוברת בצורה תקינה בנתיב שהוגדר – מהמשאב > למופע של Secure Web Proxy > עוברת את מדיניות האבטחה > ומגיעה ליעד החיצוני.

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