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

במסמך הזה מוסבר איך להגדיר שער גישה מאובטח של Chrome Enterprise Premium כדי לאבטח את הגישה לאפליקציות האינטרנט הפרטיות שלכם.

שער גישה מאובטח של Chrome Enterprise Premium פועל כשרת proxy קדימה, ומחיל מסגרת גישה של אפס אמון ומספק שליטה מפורטת ומבוססת-הקשר על מי שמקבל גישה לאפליקציות האינטרנט הפרטיות שלכם.

איך מאבטחים את הגישה לאפליקציות אינטרנט פרטיות

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

שער הגישה המאובטח יכול לעזור להגן על אפליקציות אינטרנט פרטיות שמתארחות בסביבות הבאות:

  • Google Cloud פרויקט: שער הגישה המאובטח יכול להפנות גישה לאפליקציות שפועלות ברשת ה-VPC שלכם. Google Cloud

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

התפקידים הנדרשים

צריך לבקש מהאדמין להקצות את התפקידים הבאים:

מידע נוסף על תפקידים בניהול זהויות והרשאות גישה (IAM)

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

לפני שמגדירים את שער הגישה המאובטח, צריך לוודא שיש לכם את הפריטים הבאים:

הגדרת סביבת מעטפת

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

  • פרמטרים כלליים 
    PROJECT_ID=PROJECT_ID

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

    • ‫PROJECT_ID: מזהה הפרויקט שבו נוצר שער גישה מאובטח.
  • פרמטרים של שער גישה מאובטח 
    SECURITY_GATEWAY_ID=SECURITY_GATEWAY_ID
SECURITY_GATEWAY_DISPLAY_NAME="SECURITY_GATEWAY_DISPLAY_NAME"

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

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

יצירת שער מאובטח

שער גישה מאובטח של Chrome Enterprise Premium הוא אבן בניין בסיסית ליצירת חיבורים מאובטחים לאפליקציות.

console

כדי ליצור שער גישה מאובטח:

  1. במסוף Google Cloud , נכנסים לדף שער הגישה המאובטח.
    מעבר לשער מאובטח
  2. בוחרים את הפרויקט שרוצים ליצור עבורו שער גישה מאובטח.
  3. כדי ליצור שער גישה מאובטח, לוחצים על יצירת שער חדש ומחכים עד שתהליך יצירת השער יסתיים. אפשר לעקוב אחרי ההתקדמות בקטע התראות במסוף Google Cloud .

gcloud

כדי ליצור שער גישה מאובטח באמצעות gcloud, מריצים את הפקודה הבאה:

gcloud beyondcorp security-gateways create SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --display-name="SECURITY_GATEWAY_DISPLAY_NAME" \
    --service-discovery={}

REST

כדי ליצור שער גישה מאובטח באמצעות ה-API בארכיטקטורת REST, מריצים את הפקודה הבאה:

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -X POST \
    -d '{ "display_name": "SECURITY_GATEWAY_DISPLAY_NAME", "service_discovery": {} }' \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways?security_gateway_id=SECURITY_GATEWAY_ID"

הגדרת אפליקציית אינטרנט פרטית

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

מתן הרשאות לחשבון השירות

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

כדי לתת הרשאות לחשבון השירות, מבצעים את הפעולות הבאות:

  1. כדי לזהות את כתובת האימייל בחשבון של חשבון השירות שמקצה הרשאות, צריך לקבל את הפרטים של שער הגישה המאובטח. האימייל מופיע בשדה delegatingServiceAccount של התשובה.

    gcloud

    gcloud beyondcorp security-gateways describe SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global

    REST

    curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID"
  2. מגדירים משתני סביבה לחשבון השירות ולפרויקט של ה-VPC של היעד. כדי לקבל את כתובת האימייל בחשבון השירות, אפשר להשתמש בפקודה הבאה: 
    DELEGATING_SERVICE_ACCOUNT=`gcloud beyondcorp security-gateways describe SECURITY_GATEWAY_ID --project=PROJECT_ID --location=global --format="value(delegatingServiceAccount)"`
  3. מקצים לחשבון השירות המקבל הרשאה בפרויקט ה-VPC הפרטי את התפקיד roles/beyondcorp.upstreamAccess ב-IAM. 
    gcloud projects add-iam-policy-binding PRIVATE_VPC_PROJECT_ID \
    --role=roles/beyondcorp.upstreamAccess \
    --member=serviceAccount:DELEGATING_SERVICE_ACCOUNT
    מחליפים את PRIVATE_VPC_PROJECT_ID במזהה הפרויקט של רשת ה-VPC שבה אפליקציית האינטרנט הפרטית פרוסה או שבה מוגדר Cloud VPN/Interconnect.

אחרי שמעניקים את התפקיד, צריך לחכות בערך שתי דקות עד שמדיניות ניהול הזהויות והרשאות הגישה (IAM) תיכנס לתוקף.

הגדרת ניתוב ברשת וכללים לחומת אש

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

כללי חומת אש לאפליקציות ב- Google Cloud

אם אפליקציית האינטרנט הפרטית שלכם מתארחת ברשת ה- Google Cloud VPC, למשל במכונה וירטואלית ב-Compute Engine, בשירות Google Kubernetes Engine עם כתובת IP פנימית או מאחורי מאזן עומסים פנימי מסוג TCP/UDP, צריך להגדיר כללי חומת אש שלGoogle Cloud VPC. כך מאפשרים תעבורת TCP נכנסת מטווח כתובות ה-IP של שער הגישה המאובטח: 136.124.16.0/20.

gcloud

כדי ליצור כלל בחומת האש באמצעות gcloud, מריצים את הפקודה הבאה:

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
   --project=PRIVATE_VPC_PROJECT_ID \
   --network=NETWORK_NAME \
   --allow=tcp \
   --source-ranges=136.124.16.0/20

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

  • ‫FIREWALL_RULE_NAME: שם לכלל חומת האש.
  • ‫PRIVATE_VPC_PROJECT_ID: מזהה הפרויקט שבו מתארחת רשת ה-VPC.
  • ‫NETWORK_NAME: השם של רשת ה-VPC שבה האפליקציה מתארחת.

כללי חומת אש לאפליקציות בסביבות לאGoogle Cloud

אם אפליקציית האינטרנט הפרטית שלכם נמצאת במרכז נתונים מקומי או ברשת של ספק ענן אחר, ומחוברת ל- Google CloudVPC שלכם באמצעות Cloud VPN או Cloud Interconnect, צריך להגדיר כללי חומת אש בחומת האש המקומית או באמצעי בקרה מקבילים לאבטחת רשת, כמו קבוצות אבטחה ורשימות ACL של רשת, בסביבת הענן האחרת. כך אפשר לאפשר תעבורת TCP נכנסת מטווח כתובות ה-IP של שער הגישה המאובטח: 136.124.16.0/20.

הגדרת ניתוב מסביבות שאינןGoogle Cloud לשער גישה מאובטח

כדי לאפשר תקשורת דו-כיוונית לאפליקציות פרטיות שמארחות בסביבות שאינן שלGoogle Cloud , כמו בסביבה מקומית או בעננים אחרים, הרשת החיצונית שלכם צריכה ליצור נתיב חזרה לטווח כתובות ה-IP של שער הגישה המאובטח הבא: 136.124.16.0/20.

מוודאים שהרשת הפרטית יכולה להגיע לטווח כתובות ה-IP של שער הגישה המאובטח דרך Cloud VPN או Cloud Interconnect:

  • ניתוב דינמי: אם אתם משתמשים בניתוח דינמי, כמו פרוטוקול Border Gateway ‏ (BGP) עם Cloud Router, ודאו ש-Cloud Router Google Cloud מפרסם באופן מפורש את טווחי כתובות ה-IP של שער גישה מאובטח למכשיר BGP המקומי. למרות ש-BGP מחליף באופן דינמי הרבה מסלולים, צריך לפרסם באופן מפורש את טווחי כתובות ה-IP של שער הגישה המאובטח.

    gcloud

    כדי לבדוק אם טווח המקורות מפורסם, מריצים את הפקודה הבאה:

    gcloud compute routers list-bgp-routes ROUTER_NAME \
--peer=PEER_NAME \
--region=REGION \
--project=PROJECT_ID \
--route-direction=OUTBOUND \
--address-family=IPV4 \
--destination-range=136.124.16.0/20

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

    • ‫ROUTER_NAME: השם של Cloud Router.
    • ‫PEER_NAME: השם של עמית ה-BGP.
    • ‫REGION: האזור שבו נמצא הנתב.
    • ‫PROJECT_ID: מזהה הפרויקט שמכיל את הנתב.

  • ניתוב סטטי: אם אתם משתמשים בניתוב סטטי, אתם צריכים להוסיף ידנית מסלולים לכל אחד מטווח כתובות ה-IP של שערים מאובטחים בציוד של הרשת המקומית, כמו הנתב או חומת האש. במסלולים הסטטיים האלה צריך לציין שתעבורת נתונים שמיועדת לטווח כתובות ה-IP של שער הגישה המאובטח צריכה להישלח דרך חיבור Cloud VPN או Cloud Interconnect.

    כשמשתמשים בניתוב סטטי, Cloud VPN צריך להיות באחד מהאזורים הנתמכים הבאים:

    • africa-south1
    • asia-east1
    • asia-east2
    • asia-northeast1
    • asia-northeast2
    • asia-northeast3
    • asia-south1
    • asia-south2
    • asia-southeast1
    • asia-southeast2
    • asia-southeast3
    • australia-southeast2
    • europe-central2
    • europe-north1
    • europe-north2
    • europe-southwest1
    • europe-west1
    • europe-west10
    • europe-west12
    • europe-west2
    • europe-west3
    • europe-west4
    • europe-west6
    • europe-west8
    • europe-west9
    • me-central1
    • me-central2
    • me-west1
    • northamerica-northeast1
    • northamerica-northeast2
    • northamerica-south1
    • southamerica-east1
    • southamerica-west1
    • us-central1
    • us-central2
    • us-east1
    • us-east4
    • us-east5
    • us-east7
    • us-south1
    • us-west1
    • us-west2
    • us-west3
    • us-west4
    • us-west8

הגדרת DNS לפענוח שמות מארח פרטיים של שער גישה מאובטח

כדי ששער הגישה המאובטח יוכל לפתור את שמות המארחים של האפליקציות הפרטיות, רשת ה-VPCGoogle Cloud צריכה להיות מסוגלת לפתור את שמות המארחים באמצעות Cloud DNS. ההגדרה הספציפית של Cloud DNS תלויה במיקום שבו רשומות ה-DNS הפרטיות שלכם מתארחות באופן סמכותי:

  • אפליקציות ב- Google Cloud שמשתמשות בתחומים פרטיים של Cloud DNS: אם האפליקציות הפרטיות שלכם מתארחות ב- Google Cloud ורשומות ה-DNS שלהן מנוהלות בתחומים פרטיים של Cloud DNS שמשויכים לרשת ה-VPC שלכם, צריך לוודא שהתחומים מוגדרים בצורה נכונה ושיש אליהם גישה. השער המאובטח משתמש ביכולות הקיימות של Cloud DNS לפתרון בעיות ב-VPC.

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

הוראות מפורטות להגדרת DNS זמינות במאמר יצירת אזור העברה.

יצירה של משאב אפליקציה

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

  1. מגדירים את משתני הסביבה הנדרשים על ידי הרצת הפקודה הבאה: 
       APPLICATION_ID=APPLICATION_ID
   APP_DISPLAY_NAME="APP_DISPLAY_NAME"
   HOST_NAME=HOST_NAME
   PRIVATE_NETWORK_RESOURCE_NAME=PRIVATE_NETWORK_RESOURCE_NAME
    מחליפים את מה שכתוב בשדות הבאים:
    • ‫APPLICATION_ID: מזהה ייחודי של משאב האפליקציה.
    • ‫APP_DISPLAY_NAME: השם שיוצג, שקריא לאנשים.
    • ‫HOST_NAME: שם המארח הראשי שהמשתמשים ניגשים אליו (לדוגמה, private.local).
    • ‫PRIVATE_NETWORK_RESOURCE_NAME: שם המשאב המלא של רשת ה-VPC (לדוגמה, projects/my-project/global/networks/my-network).
  2. יוצרים את משאב האפליקציה.

    console

    כדי ליצור את משאב האפליקציה באמצעות מסוף Google Cloud :

    1. במסוף Google Cloud , נכנסים לדף שער הגישה המאובטח.
      מעבר לשער מאובטח
    2. כדי להוסיף אפליקציה, לוחצים על הוספת אפליקציה.
    3. בוחרים את סוג האפליקציה: אפליקציה פרטית.
    4. מזינים את פרטי האפליקציה:
      • שם האפליקציה: מזינים שם, לדוגמה, GitHub.
      • התאמה לדומיין: מזינים רשימה מופרדת בפסיקים של תבניות דומיין כדי להעביר את התנועה דרך שער גישה מאובטח. כוללים את היציאה בפורמט domain:port. אפשר להשתמש בתווים כלליים לחיפוש (*). לדוגמה: github.com:443.
    5. הגדרת רשת VPC:
      • בפרויקט הנוכחי: אם רשת ה-VPC נמצאת בפרויקט הנוכחי, בוחרים את רשת ה-VPC מהתפריט הנפתח.
      • בפרויקט אחר: אם רשת ה-VPC נמצאת בפרויקט אחר Google Cloud , מציינים את שם המשאב המלא של רשת ה-VPC, למשל projects/my-project/global/networks/my-network.
    6. אופציונלי: הגדרת מדיניות יציאה: בוחרים אזור אחד או יותר Google Cloud מהתפריט הנפתח.
    7. אופציונלי: הגדרת מדיניות גישה: בוחרים מדיניות גישה של Access Context Manager. אפשר לדלג על השלב הזה במדריך הזה.
    8. כדי ליצור את משאב האפליקציה, לוחצים על Create.

    gcloud

    כדי ליצור את משאב האפליקציה באמצעות gcloud, מריצים את הפקודה הבאה:

    gcloud beyondcorp security-gateways applications create APPLICATION_ID \
    --project=PROJECT_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --location=global \
    --display-name="APP_DISPLAY_NAME" \
    --endpoint-matchers="hostname=HOST_NAME,ports=[443]" \
    --upstreams=network=name="PRIVATE_NETWORK_RESOURCE_NAME"

    כדי לציין אזור יציאה (לדוגמה, כשמשתמשים בנתיבים סטטיים), מוסיפים את הדגל --egress-regions:

    gcloud beyondcorp security-gateways applications create APPLICATION_ID \
    --project=PROJECT_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --location=global \
    --display-name="APP_DISPLAY_NAME" \
    --endpoint-matchers="hostname=HOST_NAME,ports=[443]" \
    --upstreams=network=name="PRIVATE_NETWORK_RESOURCE_NAME",egressPolicy=regions=us-central1

    מחליפים את us-central1 ב Google Cloud אזור (לדוגמה, europe-west1 או asia-northeast1) שתואם להגדרת הניתוב הסטטי האזורי. אם אין לכם דרישות ספציפיות לניתוב סטטי אזורי, אתם יכולים להשמיט את מדיניות היציאה מההגדרה.

    REST

    כדי ליצור משאב אפליקציה באמצעות ה-API, מבצעים את השלבים הבאים:

    1. יוצרים קובץ בשם application.json.

      {
"display_name": "APP_DISPLAY_NAME",
"endpoint_matchers": [
   {"hostname": "HOST_NAME", "ports": [443]}
],
"upstreams": [{
   "network": {
      "name": "PRIVATE_NETWORK_RESOURCE_NAME"
   }
}]
}

      כדי לציין אזור יציאה (לדוגמה, כשמשתמשים בניתוב סטטי), מוסיפים egress_policy להגדרת ה-upstream:

      {
"display_name": "APP_DISPLAY_NAME",
"endpoint_matchers": [
   {"hostname": "HOST_NAME", "ports": [443]}
],
"upstreams": [{
   "network": {
      "name": "PRIVATE_NETWORK_RESOURCE_NAME"
   },
   "egress_policy": {
      "regions": [
      "us-central1"
      ]
   }
}]
}

      מחליפים את us-central1 ב Google Cloud אזור (לדוגמה, europe-west1 או asia-northeast1) שתואם להגדרת הניתוב הסטטי האזורי. אם אין לכם דרישות ספציפיות לניתוב סטטי אזורי, אתם יכולים להשמיט את מדיניות היציאה מההגדרה.

    2. מבצעים קריאה לשיטת ה-API ‏Create.

      curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -X POST \
    -d @application.json \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID/applications?application_id=APPLICATION_ID"

הגדרת מדיניות גישה

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

console

יצירת מדיניות לכמה אפליקציות

כדי להגדיר מדיניות גישה:

  1. כדי ליצור מדיניות שחלה על כמה אפליקציות שמקושרות לשער גישה מאובטח, עוברים לדף Policies (מדיניות).
    מעבר אל 'מדיניות'
  2. כדי להוסיף מדיניות גישה לאפליקציות, לוחצים על יצירת מדיניות.
  3. מהרשימה הנפתחת, בוחרים את האפליקציות שרוצים שהמדיניות תחול עליהן.
  4. מוסיפים חשבונות משתמש למדיניות:

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

    1. כדי להוסיף משתמש, לוחצים על Add principal.
    2. בשדה Principal, מזינים את כתובת האימייל של המשתמש, הקבוצה או חשבון השירות, או את שם הדומיין.
    3. בתפריט הנפתח רמות גישה, בוחרים רמת גישה מוגדרת מראש אחת או יותר של בקרת גישה מבוססת-הקשר. הגישה תינתן רק אם הגורם המורשה עומד בתנאים של רמות הגישה שנבחרו.

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

    אפשר ליצור ולנהל רמות גישה בAccess Context Manager.

  5. כדי להחיל את המדיניות על האפליקציה, לוחצים על Create Policy.

שינוי מדיניות גישה ברמת האפליקציה

  1. כדי לשנות מדיניות עבור אפליקציה אחת, עוברים לדף אפליקציות.
    מעבר אל Applications
  2. כדי למצוא את האפליקציה שרוצים לערוך:
    1. ברשימה Applications (אפליקציות), מחפשים את האפליקציה שרוצים לשנות.
    2. כדי לראות את פרטי האפליקציה, לוחצים על תפריט פעולות נוספות () ובוחרים באפשרות הצגת פרטים.
  3. כדי לערוך את הבקשה, לוחצים על עריכה.
  4. מוסיפים חשבונות משתמש למדיניות:

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

    1. כדי להוסיף משתמש, לוחצים על Add principal.
    2. בשדה Principal, מזינים את כתובת האימייל של המשתמש, הקבוצה או חשבון השירות, או את שם הדומיין.
    3. ברשימה הנפתחת רמות גישה, בוחרים רמת גישה מבוססת-הקשר מוגדרת מראש. הגישה תינתן רק אם הגורם המורשה עומד בתנאים של רמות הגישה שנבחרו.

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

    אפשר ליצור ולנהל רמות גישה בAccess Context Manager.

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

gcloud

הוספת קישור ברמת שער Service Discovery

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

gcloud beyondcorp security-gateways add-iam-policy-binding SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --role="roles/beyondcorp.serviceDiscoveryUser" \
    --member=MEMBER

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

  • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח
  • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
  • ‫MEMBER: המשתמש, הקבוצה או חשבון השירות שרוצים להקצות להם את התפקיד Service Discovery. מידע נוסף זמין במאמר חשבונות ראשיים ב-IAM

הוספה של קישור ברמת האפליקציה

gcloud beyondcorp security-gateways applications add-iam-policy-binding APPLICATION_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --role="roles/beyondcorp.sgApplicationUser" \
    --member=MEMBER

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

  • ‫APPLICATION_ID: המזהה של משאב האפליקציה
  • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח
  • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
  • ‫MEMBER: המשתמש, הקבוצה או חשבון השירות שרוצים להקצות להם את התפקיד Service Discovery. מידע נוסף זמין במאמר חשבונות ראשיים ב-IAM

הוספה של קישור מותנה

אפשר גם להוסיף קשירה עם תנאים. תנאים מציינים דרישות, כמו כתובת IP של משתמש שמגיעה ממיקום ספציפי. (אפשר להגדיר את רמת הגישה במדיניות גישה ברמת הארגון או במדיניות גישה בהיקף מוגבל).

הפקודה הבאה מעניקה גישה רק אם כתובת ה-IP של המקור נמצאת ברמת גישה שצוינה:

gcloud beyondcorp security-gateways applications add-iam-policy-binding APPLICATION_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --role="roles/beyondcorp.sgApplicationUser" \
    --member=MEMBER \
    --condition="expression='accessPolicies/1234567890/accessLevels/in_us' in request.auth.access_levels,title=Source IP must be in US"

הסרה של קישור ברמת השער של Service Discovery

ביטול הרשאות של משתמש לגילוי שירותים ברמת השער המאובטח.

gcloud beyondcorp security-gateways remove-iam-policy-binding SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --role="roles/beyondcorp.serviceDiscoveryUser" \
    --member=MEMBER

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

  • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח
  • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
  • ‫MEMBER: המשתמש, הקבוצה או חשבון השירות שרוצים להסיר מהם את התפקיד Service Discovery. מידע נוסף זמין במאמר חשבונות ראשיים ב-IAM

הסרה של קישור ברמת האפליקציה

gcloud beyondcorp security-gateways applications remove-iam-policy-binding APPLICATION_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --role="roles/beyondcorp.sgApplicationUser" \
    --member=MEMBER

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

  • ‫APPLICATION_ID: המזהה של משאב האפליקציה
  • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח
  • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
  • ‫MEMBER: המשתמש, הקבוצה או חשבון השירות שרוצים להסיר מהם את התפקיד Service Discovery. מידע נוסף זמין במאמר חשבונות ראשיים ב-IAM

הסרה של קישור מותנה

אפשר גם להסיר קשר עם תנאים. תנאים מציינים דרישות, כמו כתובת IP של משתמש שמגיעה ממיקום ספציפי. (אפשר להגדיר את רמת הגישה במדיניות גישה ברמת הארגון או במדיניות גישה בהיקף מוגבל).

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

gcloud beyondcorp security-gateways applications remove-iam-policy-binding APPLICATION_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global \
    --role="roles/beyondcorp.sgApplicationUser" \
    --member=MEMBER \
    --condition="expression='accessPolicies/1234567890/accessLevels/in_us' in request.auth.access_levels,title=Source IP must be in US"

REST

עדכון מדיניות גישה בצורה בטוחה

הפקודה setIamPolicy מחליפה את כל המדיניות הקיימת במדיניות שאתם מספקים. כדי להימנע מהסרה בטעות של הרשאות קיימות, מומלץ להשתמש בתבנית 'קריאה-שינוי-כתיבה' הבאה. הדפוס הזה עוזר למנוע הסרה בטעות של הרשאות קיימות.

  1. קריאה: שמירת מדיניות הגישה הנוכחית בקובץ.
  2. שינוי: עורכים את קובץ המדיניות באופן מקומי כדי להוסיף או לשנות הרשאות.
  3. כתיבה: החלת קובץ המדיניות המעודכן.

הגדרת מדיניות ברמת שער של Service Discovery

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

מאחזרים את המדיניות הנוכחית ושומרים אותה בקובץ בשם gateway_policy.json.

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID:getIamPolicy" > gateway_policy.json

לאחר מכן, פותחים את הקובץ gateway_policy.json בכלי לעריכת טקסט ומוסיפים את חשבונות המשתמשים הנדרשים לרשימה members של התפקיד roles/beyondcorp.serviceDiscoveryUser, בדומה לשינויים ברמת האפליקציה.

קובץ gateway_policy.json דומה לדוגמה הבאה:

{
  "version": 3,
  "bindings": [
    {
      "role": "roles/beyondcorp.serviceDiscoveryUser",
      "members": [
        "group:existing-group@example.com"
      ]
    }
  ],
  "etag": "BwXN8_d-bOM="
}

אפשר גם להוסיף סוגים אחרים של חברים, כמו serviceAccount,‏ user,‏ group,‏ principal ו-principalSet, בהגדרות של מדיניות. מידע נוסף מופיע במאמר חשבונות משתמשים ב-IAM.

החלת המדיניות המעודכנת:

jq '{policy: .}' gateway_policy.json | curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -d @- \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID:setIamPolicy"

הגדרת מדיניות גישה ברמת האפליקציה

טעינת המדיניות הנוכחית

מאחזרים את המדיניות הנוכחית. השדה etag מונע עדכונים סותרים אם כמה אדמינים מבצעים שינויים בו-זמנית.

הפקודה הבאה מאחזרת את המדיניות ושומרת אותה בקובץ בשם policy.json. 

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID/applications/APPLICATION_ID:getIamPolicy" > policy.json

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

  • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
  • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח
  • ‫APPLICATION_ID: המזהה של משאב האפליקציה

הפקודה יוצרת קובץ policy.json שמכיל את המדיניות הנוכחית.

שינוי קובץ המדיניות

כדי להעניק לקבוצה גישה לשימוש בשער הגישה המאובטח:

  1. פותחים את הקובץ policy.json בכלי לעריכת טקסט.
  2. מוסיפים את הקבוצה לרשימה members לתפקיד roles/beyondcorp.securityGatewayUser.

קובץ policy.json דומה לדוגמה הבאה:

{
  "version": 3,
  "bindings": [
    {
      "role": "roles/beyondcorp.sgApplicationUser",
      "members": [
        "group:existing-group@example.com"
      ]
    }
  ],
  "etag": "BwXN8_d-bOM="
}

כדי להוסיף עוד קבוצה, מוסיפים רשומה חדשה למערך members. כוללים פסיק אחרי הרשומה הקודמת. בדוגמה הבאה מוסיפים את new-group@example.com:

{
  "version": 3,
  "bindings": [
    {
      "role": "roles/beyondcorp.sgApplicationUser",
      "members": [
        "group:existing-group@example.com",
        "group:new-group@example.com"
      ]
    }
  ],
  "etag": "BwXN8_d-bOM="
}

אפשר גם להוסיף סוגים אחרים של חברים, כמו serviceAccount,‏ user,‏ group,‏ principal ו-principalSet, בהגדרות של מדיניות. מידע נוסף מופיע במאמר חשבונות משתמשים ב-IAM.

החלת המדיניות המעודכנת

אחרי שעורכים ושומרים את הקובץ policy.json, מפעילים אותו על המשאב באמצעות הפקודה setIamPolicy. הפקודה הזו משתמשת ב-etag מהקובץ כדי לוודא שאתם מעדכנים את הגרסה הנכונה.

jq '{policy: .}' policy.json | curl -X POST \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -d @- \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID/applications/APPLICATION_ID:setIamPolicy"

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

  • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
  • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח
  • ‫APPLICATION_ID: המזהה של משאב האפליקציה

הוספה של מדיניות גישה מותנית

אפשר גם להגדיר מדיניות גישה עם תנאים. תנאים מציינים דרישות, כמו כתובת IP של משתמש שמגיעה ממיקום ספציפי. (אפשר להגדיר את רמת הגישה במדיניות גישה ברמת הארגון או במדיניות גישה בהיקף מוגבל).

מדיניות ההרשאות הבאה מעניקה גישה רק אם כתובת ה-IP של המקור נמצאת ברמת גישה שצוינה:

{
  "version": 3,
  "bindings": [
    {
      "role": "roles/beyondcorp.sgApplicationUser",
      "members": [
        "group:group@example.com"
      ],
      "condition": {
        "expression": "request.auth.access_levels.contains('accessPolicies/1234567890/accessLevels/in_us')",
        "title": "Source IP must be in US"
      }
    }
  ],
  "etag": "BwXN8_d-bOM="
}

כדי להחיל את המדיניות הזו, פועלים לפי השלבים שמתוארים למעלה.

שיפור האבטחה באמצעות בקרת גישה מבוססת-הקשר

כדי לשפר עוד יותר את האבטחה ולוודא שרק מופעים מנוהלים של Google Chrome יוכלו לגשת לאפליקציות האינטרנט שלכם דרך שער האבטחה, מומלץ להוסיף כלל של בקרת גישה מבוססת הקשר (CAA). הכלל הזה מוודא שפרופיל Chrome של המשתמש נמצא בניהול, כדי למנוע שימוש לרעה בדפדפנים לא מנוהלים או זדוניים.

הערה: כדי להשתמש בתכונה הזו, צריך להתקין ולהגדיר את התוסף Endpoint Verification.

כדי להטמיע את זה, מוסיפים תנאי לרמות הגישה המותאמות אישית של Access Context Manager. הנה דוגמה לתנאי שאפשר להתאים:

  device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_PROFILE_MANAGED

מידע נוסף על הגדרה, בדיקה וניהול של המצב הזה זמין במאמר מאפיינים של דפדפן Chrome.

התקנת התוסף Chrome Enterprise Premium

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

  1. נכנסים למסוף Google Admin.
  2. לוחצים על דפדפן Chrome > אפליקציות ותוספים.
  3. לוחצים על הכרטיסייה משתמשים ודפדפנים.
  4. כדי להוסיף את התוסף ל-Chrome, לוחצים על הלחצן + ואז בוחרים באפשרות הוספה של אפליקציית Chrome או של תוסף לפי המזהה שלהם.

  5. מחפשים את התוסף Secure Enterprise Browser באמצעות המזהה הבא, ואז מגדירים את מדיניות ההתקנה שלו להתקנה בהגדרת מנהל מערכת לכל המשתמשים ביחידה הארגונית או בקבוצה:

    ekajlcmdfcigmdbphhifahdfjbkciflj

  6. לוחצים על התוסף המותקן, ובשדה מדיניות לגבי תוספים מזינים את ערך ה-JSON הבא:

    {
  "securityGateway": {
    "Value": {
      "authentication": {},
      "context": { "resource": "projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID" },
      "serviceDiscovery": { "routes": {} }
    }
  }
}

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

    • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדר שער גישה מאובטח
    • ‫SECURITY_GATEWAY_ID: המזהה של שער הגישה המאובטח

  7. כדי לשמור את ההגדרות, לוחצים על Save.

הגדרה של קובץ PAC מדור קודם

כשמפעילים את זיהוי השירותים, לקוח דפדפן Chrome יכול לזהות אוטומטית את האפליקציות שהגדרתם ולנתב אליהן תעבורת נתונים דרך שער הגישה המאובטח. כך לא צריך להגדיר ניתוב ידני באמצעות קובץ PAC.

אם התכונה 'גילוי שירותים' לא מופעלת בשער הגישה המאובטח, יש לכם הגדרה מדור קודם. תצטרכו להגדיר קובץ PAC כדי לשלוט בניתוב בלקוח של דפדפן Chrome.

כדי לבדוק אם יש לכם הגדרה מדור קודם, משתמשים בפקודות הבאות כדי לראות אם גילוי השירותים מופעל:

gcloud

gcloud beyondcorp security-gateways describe SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global | grep -i "serviceDiscovery"

REST

curl --silent \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID" | grep -i "serviceDiscovery"

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

שלב 1: יוצרים ומארחים את קובץ ה-PAC

  1. יוצרים קובץ בשם pac_config.js עם קוד ה-JavaScript הבא, ומחליפים את HOST_NAME בדומיין של האפליקציה (לדוגמה, myapp.example.com):

    function FindProxyForURL(url, host) {
  const PROXY = "HTTPS via.prod.securegateway.goog:443";
  const sites = ["HOST_NAME"];

  for (const site of sites) {
    if (shExpMatch(url, 'https://' + site + '/*') || shExpMatch(url, '*.' + site + '/*')) {
      return PROXY;
    }
  }
  return 'DIRECT';
}

  2. מעלים את קובץ ה-PAC לשירות אחסון, כמו קטגוריה של Cloud Storage.

    • מוודאים שאפשר להוריד את הקובץ באופן ציבורי.
    • מגדירים את כותרת ה-HTTP‏ Cache-Control לערך no-cache כדי שהדפדפנים תמיד יאחזרו את כללי הניתוב העדכניים ביותר.

  3. מעתיקים את כתובת ה-URL הציבורית של קובץ ה-PAC שהועלה.

שלב 2: החלת קובץ ה-PAC במסוף Google Admin

  1. נכנסים למסוף Google Admin.
  2. עוברים אל מכשירים > Chrome > הגדרות.
  3. בוחרים את היחידה הארגונית או הקבוצה ולוחצים על מצב פרוקסי.
  4. בקטע מצב Proxy, בוחרים באפשרות תמיד להשתמש בתצורת Proxy אוטומטית (PAC) המפורטת למטה.
  5. מזינים את כתובת ה-URL הציבורית של קובץ ה-PAC המתארח בשדה המתאים.
  6. לוחצים על Save.

שלב 3: הגדרת התוסף Chrome Enterprise Premium

התוסף נדרש לטיפול באימות. המדיניות הזו לגבי תוספים שונה מההגדרה הרגילה כי היא לא כוללת את החסימה של serviceDiscovery.

  1. במסוף Google Admin, עוברים אל דפדפן Chrome > אפליקציות ותוספים.
  2. עוברים לכרטיסייה משתמשים ודפדפנים ומוודאים שהתוסף Secure Enterprise Browser‏ (ekajlcmdfcigmdbphhifahdfjbkciflj) נוסף ונאכף.

  3. לוחצים על התוסף, ובשדה מדיניות לתוספים מזינים את ערך ה-JSON הבא:

    {
  "securityGateway": {
    "Value": {
      "authentication": {},
      "context": {
        "resource": "projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID"
      }
    }
  }
}

  4. לוחצים על Save.

מעבר להגדרת גילוי השירותים

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

  1. הפעלת זיהוי שירותים בשער הגישה המאובטח: צריך לעדכן את השער הקיים כדי להפעיל זיהוי שירותים.

    gcloud

    gcloud beyondcorp security-gateways update SECURITY_GATEWAY_ID \
--project=PROJECT_ID \
--location=global \
--service-discovery={}

    REST

    curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{ "service_discovery": {} }' \
"https://beyondcorp.googleapis.com/v1/projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID?updateMask=service_discovery"

  2. הגדרת מדיניות הגישה ברמת השער: מעניקים למשתמשים את התפקיד roles/beyondcorp.serviceDiscoveryUser ברמת השער כדי שהם יוכלו להשתמש באיתור שירותים. פועלים לפי ההוראות שבקטע הוספת קישור ברמת שער של Service Discovery.

  3. מעדכנים את ההגדרה של התוסף Chrome Enterprise Premium: פועלים לפי ההוראות שבקטע התקנת התוסף Chrome Enterprise Premium כדי לעדכן את מדיניות התוסף. הגדרות ה-JSON החדשות חייבות לכלול את הבלוק "serviceDiscovery": { "routes": {} }.

  4. הסרת קובץ ה-PAC מדור קודם: אחרי שהתכונה 'גילוי שירותים' מופעלת, קובץ ה-PAC מדור קודם כבר לא נחוץ.

    1. במסוף Google Admin, עוברים אל מכשירים > Chrome > הגדרות > הגדרות משתמש ודפדפן > רשת.
    2. מחפשים את ההגדרה מצב שרת proxy.
    3. מסירים את כתובת ה-URL של קובץ התצורה האוטומטית של שרת ה-proxy (PAC) או משנים את ההגדרה מתמיד להשתמש בתצורת proxy אוטומטית (PAC) המפורטת למטה למצב מתאים לרשת, כמו המשתמשים יכולים להגדיר.
    4. לוחצים על Save.

חוויית השימוש של משתמש הקצה

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

גישה לאפליקציה ב-Chrome

התוסף Chrome Enterprise Premium נדרש כדי להפנות את התנועה דרך השער המאובטח. התוסף מטפל באימות בין המשתמש לבין שער הגישה המאובטח. התוסף מותקן באופן אוטומטי דרך מדיניות הדומיין.

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

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

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