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

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

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

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

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

  1. הגדרות הדפדפן בצד הלקוח מעבירות את תעבורת הנתונים של האפליקציה דרך שרת proxy מאובטח של שער.
  2. שער גישה מאובטח בודק את מדיניות בקרת הגישה מבוססת-הקשר כדי לאשר גישה של לקוח (משתמש ומכשיר).
  3. אם הגישה של הלקוח מותרת, השער מעביר את התעבורה לאפליקציה באמצעות כתובות IP ייחודיות של מקור שהוקצו לשער ולאזור הזה. Google Cloudכתובות ה-IP שהוקצו שמורות באופן בלעדי לשער שאתם יוצרים, ומשתמשים או שערים אחרים לא יכולים להשתמש בהן. כדי לשלוט בגישה, אפשר להוסיף את כתובות ה-IP הייעודיות האלה לרשימת ההיתרים באפליקציית ה-SaaS.

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

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

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

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

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

מגבלות

לשער גישה מאובטח של Chrome Enterprise Premium יש את המגבלות הבאות:

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

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

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

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

    PROJECT_ID=PROJECT_ID
APPLICATION_ID=APPLICATION_ID
APPLICATION_DISPLAY_NAME="APPLICATION_DISPLAY_NAME"
HOST_NAME=HOST_NAME

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

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

    • ‫HOST_NAME: שם המארח של האפליקציה. לדוגמה, github.com. אורך שם המארח יכול להיות עד 253 תווים, והוא צריך להיות באחד מהפורמטים הבאים:

      • כתובת IPv4 תקינה
      • כתובת IPv6 תקינה
      • שם DNS תקין
      • כוכבית (*)
      • כוכבית (*) ואחריה שם DNS תקין

  • פרמטרים של שער גישה מאובטח

    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. כדי ליצור שער גישה מאובטח, לוחצים על יצירת שער חדש ומחכים עד שתהליך יצירת השער יסתיים.
  4. אפשר לעקוב אחרי ההתקדמות בקטע 'התראות' במסוף Google Cloud .
  5. לפני שיוצרים משאב של אפליקציית SaaS, מומלץ ליצור מרכזי יציאה של SaaS. הדגל hubs מייצג את המשאבים האזוריים שנדרשים להפעלת קישוריות יוצאת לאפליקציית היעד. אפשר להגדיר מרכז אחד לכל אזור, וכל מרכז מספק שתי כתובות IP. ב-Secure Gateway יכולים להיות עד 20 רכזות. אפשר לציין את האזורים הבאים:
    • africa-south1
    • asia-east1
    • asia-south1
    • asia-south2
    • asia-southeast1
    • europe-central2
    • europe-north1
    • europe-southwest1
    • europe-west1
    • europe-west2
    • europe-west3
    • europe-west4
    • europe-west8
    • europe-west9
    • northamerica-northeast1
    • northamerica-northeast2
    • northamerica-south1
    • southamerica-east1
    • southamerica-west1
    • us-central1
    • us-east1
    • us-east4
    • us-east5
    • us-west1
  6. נכנסים לדף SaaS Egress Hubs במסוף Google Cloud .
    מעבר אל SaaS Egress Hubs
  7. בוחרים את הפרויקט שרוצים ליצור עבורו את מרכזי היציאה של SaaS.
  8. כדי להוסיף רכזת יציאה של SaaS, לוחצים על הוספת רכזת יציאה של SaaS.
  9. בתפריט הנפתח, בוחרים את האזורים שבהם רוצים להוסיף את מרכזי היציאה. כדי להוסיף את מרכזי היציאה, לוחצים על הוספת מרכז יציאה של SaaS כדי להוסיף יותר ממרכז אחד. כשמסיימים, לוחצים על Save (שמירה) כדי ליצור את מרכזי היציאה.

gcloud

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

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

הדגל hubs מגדיר את המשאבים האזוריים שנדרשים להפעלת קישוריות יוצאת לאפליקציית היעד. אפשר להגדיר מרכז אחד לכל אזור, וכל מרכז מספק שתי כתובות IP. ב-Secure Gateway יכולים להיות עד 20 רכזות. אפשר לציין את האזורים הבאים:

  • africa-south1
  • asia-east1
  • asia-south1
  • asia-south2
  • asia-southeast1
  • europe-central2
  • europe-north1
  • europe-southwest1
  • europe-west1
  • europe-west2
  • europe-west3
  • europe-west4
  • europe-west8
  • europe-west9
  • northamerica-northeast1
  • northamerica-northeast2
  • northamerica-south1
  • southamerica-east1
  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-east5
  • us-west1

REST

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

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

הדגל hubs מייצג את המשאבים האזוריים שנדרשים להפעלת קישוריות יוצאת לאפליקציית היעד. אפשר להגדיר מרכז אחד לכל אזור, וכל מרכז מספק שתי כתובות IP. ב-Secure Gateway יכולים להיות עד 20 רכזות. אפשר לציין את האזורים הבאים:

  • africa-south1
  • asia-east1
  • asia-south1
  • asia-south2
  • asia-southeast1
  • europe-central2
  • europe-north1
  • europe-southwest1
  • europe-west1
  • europe-west2
  • europe-west3
  • europe-west4
  • europe-west8
  • europe-west9
  • northamerica-northeast1
  • northamerica-northeast2
  • northamerica-south1
  • southamerica-east1
  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-east5
  • us-west1

הגדרת אפליקציית SaaS

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

console

כדי להגדיר מרכזי יציאה של SaaS:

  1. נכנסים לדף SaaS Egress Hubs במסוף Google Cloud .
    מעבר אל SaaS Egress Hubs
  2. בדף SaaS Egress Hubs (מרכזי יציאה של SaaS), מחפשים את הטבלה שבה מפורטים המרכזים. לכל אזור שבו אתם מתכוונים להשתמש, מעתיקים את כל כתובות ה-IP שמופיעות בעמודה Static dedicated egress IPs (כתובות IP סטטיות ייעודיות ליציאה). בכל אזור מסופקות שתי כתובות IP.
  3. מוסיפים את כתובות ה-IP לרשימת ההיתרים של כתובות ה-IP באפליקציית ה-SaaS. לדוגמה, אם מדובר באפליקציית GitHub, אפשר לפעול לפי המדריך הזה: ניהול כתובות IP מותרות בארגון.

gcloud

כדי להגדיר מרכזי יציאה של SaaS:

  1. מקבלים את כתובות ה-IP שהוקצו על ידי שער הגישה המאובטח לכל Hub. מוקצות שתי כתובות IP לאזור.
    2. gcloud beyondcorp security-gateways describe SECURITY_GATEWAY_ID \
    --project=PROJECT_ID \
    --location=global

    הדוגמה הבאה היא של תשובת GET של שער גישה מאובטח עם hubs. בדוגמה, כתובות ה-IP‏ hubs נוצרות באזורים us-central1 ו-us-east1, וצריך לאפשר את כל כתובות ה-IP שמוחזרות בתגובה באפליקציית ה-SaaS.

    createTime: 'CREATE_TIME'
displayName: My secure gateway
hubs:
  us-central1:
    internetGateway:
      assignedIps:
      -   IP_ADDRESS_1
      -   IP_ADDRESS_2
  us-east1:
    internetGateway:
      assignedIps:
      -   IP_ADDRESS_1
      -   IP_ADDRESS_2
name: projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID
state: RUNNING
updateTime: 'UPDATE_TIME'
  2. מוסיפים את כתובות ה-IP לרשימת ההיתרים של כתובות ה-IP באפליקציית ה-SaaS. לדוגמה, אם מדובר באפליקציית GitHub, אפשר לפעול לפי ההוראות במאמר ניהול כתובות IP מותרות בארגון.

REST

כדי להגדיר מרכזי יציאה של SaaS:

  1. מקבלים את כתובות ה-IP שהוקצו על ידי שער הגישה המאובטח לכל Hub. מוקצות שתי כתובות IP לאזור.
    2. 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"

    הדוגמה הבאה היא של תשובת GET של שער גישה מאובטח עם hubs. בדוגמה, כתובות ה-IP‏ hubs נוצרות באזורים us-central1 ו-us-east1, וצריך לאפשר את כל כתובות ה-IP שמוחזרות בתגובה באפליקציית ה-SaaS.

    {
  "securityGateways": [
    {
      "name": "projects/PROJECT_ID/locations/global/securityGateways/SECURITY_GATEWAY_ID",
      "createTime": "CREATE_TIME",
      "updateTime": "UPDATE_TIME",
      "displayName": "My secure gateway",
      "state": "RUNNING",
      "hubs": {
        "us-central1": {
          "internetGateway": {
            "assignedIps": [
              "IP_ADDRESS_1",
              "IP_ADDRESS_2",
            ]
          }
        },
        "us-east1": {
          "internetGateway": {
            "assignedIps": [
              "IP_ADDRESS_1",
              "IP_ADDRESS_2",
            ]
          }
        }
      }
    }
  ]
}
  2. מוסיפים את כתובות ה-IP לרשימת ההיתרים של כתובות ה-IP באפליקציית ה-SaaS. לדוגמה, אם מדובר באפליקציית GitHub, אפשר לפעול לפי ההוראות במאמר ניהול כתובות IP מותרות בארגון.

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

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

יצירת משאב של אפליקציית שער מאובטח ב- Google Cloud

משאב האפליקציה Google Cloud הוא משאב משנה של משאב השער המאובטח. יוצרים משאב אפליקציה באמצעות מסוף Google Cloud או הפעלת CreateAPI.

console

כדי ליצור אפליקציית SaaS:

  1. במסוף Google Cloud , נכנסים לדף שער הגישה המאובטח.
    מעבר לשער מאובטח
  2. כדי ליצור אפליקציה, לוחצים על הוספת אפליקציה.
  3. בוחרים את סוג האפליקציה: אפליקציה ציבורית.
  4. אם עדיין לא הגדרתם מרכזי יציאה של SaaS לשער המאובטח הזה, תתבקשו ליצור אותם. באפליקציות ציבוריות נדרש לפחות מרכז יציאה אחד של SaaS. כדי להגדיר מרכזי יציאה של SaaS, לוחצים על מעבר למרכזי יציאה של SaaS ומוסיפים אזור אחד או יותר.
  5. אחרי שיוצרים מרכז יציאה אחד או יותר, לוחצים על הבא.
  6. מזינים את פרטי האפליקציה:
    • שם האפליקציה: מזינים שם, לדוגמה, GitHub.
    • התאמות לדומיינים: מזינים רשימה מופרדת בפסיקים של תבניות דומיין כדי להעביר את התנועה דרך שער הגישה המאובטח. כוללים את היציאה בפורמט domain:port. אפשר להשתמש בתווים כלליים לחיפוש (*). לדוגמה: github.com:443.
  7. כדי להגדיר את אפליקציית ה-SaaS, לוחצים על המשך.
  8. מגדירים את אפליקציית ה-SaaS כך שתאפשר תעבורת נתונים משער הגישה המאובטח:
    1. חשוב לרשום או להעתיק את כל כתובות ה-IP שמופיעות עבור האזורים שבהם אתם משתמשים. כתובות ה-IP האלה ייחודיות לשער הגישה המאובטח שלכם.
    2. נכנסים למסוף הניהול של אפליקציית ה-SaaS.
    3. עוברים להגדרות הרשת או להגדרות האבטחה שבהן מנהלים את רשימות היתרים של כתובות IP.
    4. מוסיפים את כל כתובות ה-IP שהתקבלו לרשימת ההיתרים של כתובות ה-IP באפליקציה.
  9. כדי להוסיף את האפליקציה, לוחצים על המשך.
  10. אופציונלי: הגדרת מדיניות גישה: בוחרים מדיניות גישה של Access Context Manager. אפשר לדלג על השלב הזה במדריך הזה.
  11. כדי ליצור את האפליקציה, לוחצים על יצירה.

gcloud

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

gcloud beyondcorp security-gateways applications create APPLICATION_ID \
    --project=PROJECT_ID \
    --security-gateway=SECURITY_GATEWAY_ID \
    --location=global \
    --display-name="APPLICATION_DISPLAY_NAME" \
    --endpoint-matchers="hostname=HOST_NAME,ports=443"

REST

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

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -X POST \
    -d "{ \"display_name\": \"APPLICATION_DISPLAY_NAME\", \"endpoint_matchers\": [{hostname: \"HOST_NAME\", ports: 443}] }" \
    "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 של קובץ ה-PAC או משנים את ההגדרה מתמיד להשתמש בתצורת proxy אוטומטית (PAC) המפורטת למטה למצב שמתאים לרשת שלכם, כמו המשתמשים יכולים להגדיר.
    4. לוחצים על Save.

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

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

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

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

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

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

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