הגדרה של בקרת גישה מבוססת-הקשר באמצעות שרת proxy לאימות זהויות (IAP)

במדריך הזה מוסבר איך להרחיב את מדיניות הגישה של Identity-Aware Proxy ‏ (IAP) באמצעות רמות גישה ומסגרת התנאים של ניהול הזהויות והרשאות הגישה (IAM). רמות גישה מאפשרות להגביל את הגישה למשאבים על סמך כתובת ה-IP ומאפייני המכשיר של משתמש הקצה. תנאי IAM מאפשרים להגביל את הגישה לפי מארחים, נתיבים, תאריך ושעה של כתובות URL.

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

  • להעניק גישה לכל העובדים אם הם משתמשים במכשיר ארגוני מהימן מהרשת הארגונית.
  • נותנים גישה לעובדים בקבוצה גישה מרחוק אם הם משתמשים במכשיר ארגוני מהימן עם סיסמה מאובטחת ורמת תיקון עדכנית, מכל רשת.
  • מאפשרים גישה לעובדים בקבוצה Privileged Access רק אם נתיב כתובת ה-URL מתחיל ב-/admin.

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

לפני שמתחילים, צריך:

  • אפליקציה שמאובטחת באמצעות IAP, שאליה רוצים להוסיף גישה למשתמשים או לקבוצות.
  • שמות של משתמשים או קבוצות שרוצים להעניק להם גישה.

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

כדי להגביל את הגישה על סמך כתובת IP או מאפיינים של מכשיר משתמש הקצה, צריך ליצור רמת גישה. כדי להשתמש בחלק מהמאפיינים, כמו מאפייני מכשיר, צריך רישיון Chrome Enterprise Premium. אימות הרישיון מתבצע רק כשמגדירים רמות גישה, והוא לא משפיע על הגישה בזמן הריצה. במדריך בנושא Access Context Manager מוסבר איך ליצור רמת גישה. מערכת IAP משתמשת בשם של רמת הגישה כדי לשייך אותה לאפליקציה שמוגנת באמצעות IAP.

‫IAP לא תומך בשימוש במדיניות בהיקף מוגבל. צריך להגדיר את רמות הגישה במדיניות הגישה הארגונית. מידע נוסף זמין במאמר יצירת מדיניות גישה.

עריכת מדיניות IAM

באפליקציה שמוגנת באמצעות IAP יש מדיניות IAM שמקשרת את תפקיד ה-IAP לאפליקציה.

הוספה של קישור מותנה ב-IAM למדיניות IAM מגבילה עוד יותר את הגישה למשאבים על סמך מאפייני הבקשה. מאפייני הבקשות האלה כוללים:

  • רמות גישה
  • מארח/נתיב של כתובת URL
  • תאריך/שעה

חשוב לזכור שהערכים של הבקשה שמושווים לערכים request.host ו-request.path שצוינו בקישור תנאי של IAM חייבים להיות זהים. לדוגמה, אם מגבילים את הגישה לנתיבים שמתחילים ב-/internal admin, אפשר לעקוף את ההגבלה על ידי מעבר אל /internal%20admin. מידע נוסף על תנאים של שם מארח ונתיב זמין במאמר שימוש בתנאים של שם מארח ונתיב.

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

המסוף

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

  1. עוברים אל דף האדמין של IAP.

    כניסה לדף הניהול של IAP

  2. מסמנים את התיבה לצד המשאבים שרוצים לעדכן את הרשאות ה-IAM שלהם.

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

  4. בתיבה New principal, מזינים את חשבונות המשתמשים שרוצים להקצות להם תפקיד.

  5. ברשימה הנפתחת Select a role (בחירת תפקיד), בוחרים בתפקיד IAP-secured Web App User (משתמש באפליקציית אינטרנט שמאובטחת באמצעות IAP) ומציינים את תנאי רמת הגישה שהגורמים המורשים צריכים לעמוד בהם כדי לגשת למשאב.

    • כדי לציין רמות גישה קיימות, בוחרים אותן מהרשימה הנפתחת רמות גישה. כדי לראות את רמות הגישה הקיימות, צריך לבחור בתפקיד משתמש באפליקציית אינטרנט מאובטחת באמצעות IAP ולקבל הרשאות ברמת הארגון. צריך לקבל אחד מהתפקידים הבאים:
      • אדמין של Access Context Manager
      • עורך Access Context Manager
      • בעל הרשאת קריאה ב-Access Context Manager
    • כדי ליצור ולנהל רמות גישה, משתמשים ב-Access Context Manager.

  6. אם רוצים להוסיף עוד תפקידים לחשבונות הראשיים, לוחצים על Add another role.

  7. כשמסיימים להוסיף תפקידים, לוחצים על Save.

    הוספתם קישור מותנה למשאב.

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

  1. עוברים אל דף האדמין של IAP.

    כניסה לדף הניהול של IAP

  2. מסמנים את התיבה לצד המשאב שממנו רוצים להסיר את תפקיד ה-IAM של חשבון המשתמש.

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

  4. לוחצים על הסרה לצד הגורם המרכזי.

  5. בתיבת הדו-שיח Remove role from principal שמופיעה, לוחצים על Remove. כדי להסיר מהחשבון הראשי את כל התפקידים שלא הועברו בירושה במשאב שנבחר, מסמנים את תיבת הסימון לפני שלוחצים על הסרה.

gcloud

בשלב הזה, אפשר להשתמש רק בכלי gcloud כדי להגדיר קשירות מותנות ברמת הפרויקט.

כדי להגדיר קשירות מותנות, עורכים את הקובץ policy.yaml של הפרויקט לפי התהליך הבא:

  1. פותחים את מדיניות IAM של האפליקציה באמצעות פקודת gcloud הבאה: 

    gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml

  2. עורכים את הקובץ policy.yaml ומציינים בו את הפרטים הבאים:

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

    • התנאי לניהול הזהויות והרשאות הגישה.

      בקטע הקוד הבא מוצג תנאי IAM עם מאפיין אחד בלבד. התנאי הזה מעניק גישה למשתמש ולמשתמשים בקבוצה אם הם עומדים בדרישות של רמת הגישה ACCESS_LEVEL_NAME ונתיב כתובת ה-URL של המשאב מתחיל ב-/.

    bindings:
...
  - members:
    - group:EXAMPLE_GROUP@GOOGLE.COM
    - user:EXAMPLE_USER@GOOGLE.COM
    role: roles/iap.httpsResourceAccessor
    condition:
              expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in
                          request.auth.access_levels && request.path.startsWith("/")
              title: CONDITION_TITLE
...

  3. מבצעים קישור של המדיניות לאפליקציה באמצעות הפקודה set-iam-policy. 

    gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml

מדיניות ה-IAM שלכם כוללת עכשיו קישור מותנה.

API

כדי לערוך את קובץ policy.json של האפליקציה, פועלים לפי התהליך שמתאים לסוג האפליקציה. מידע נוסף על שימוש ב-IAM API לניהול מדיניות גישה זמין במאמר ניהול גישה למשאבים שמאובטחים באמצעות IAP.

לפני שמבצעים את השלבים הספציפיים ל-API של האפליקציה שבהמשך, צריך לייצא את המשתנים הבאים:

 export PROJECT_NUM=PROJECT_NUMBER
 export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web
 # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy
 export JSON_NEW_POLICY=POLICY_FILE.JSON

App Engine

  1. מייצאים את המשתנים הבאים של App Engine: 

    # The APP_ID is usually the project ID
export GAE_APP_ID=APP_ID
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}

  2. מקבלים את מדיניות ה-IAM של אפליקציית App Engine באמצעות השיטה getIamPolicy. ביט הנתונים הריק בסוף הופך את בקשת curl ל-POST במקום ל-GET. 

    curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''

  3. מוסיפים את הקישור המותנה של IAM לקובץ ה-JSON של מדיניות ה-IAM. הדוגמה הבאה מציגה קובץ policy.json שעבר עריכה וקושר בו התפקיד iap.httpsResourceAccessor לשני משתמשים, וכך ניתנת להם גישה למשאבים שמוגנים על ידי IAP. נוסף תנאי IAM כדי להעניק להם גישה למשאבים רק אם מתקיימת הדרישה של רמת הגישה ACCESS_LEVEL_NAME ונתיב כתובת ה-URL של המשאב מתחיל ב-/. לכל קשירה יכול להיות רק תנאי אחד.

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

    {
"policy": {
"bindings": [
{
  "role": "roles/iap.httpsResourceAccessor",
  "members": [
      "group:EXAMPLE_GROUP@GOOGLE.COM",
      "user:EXAMPLE_USER@GOOGLE.COM"
  ],
  "condition": {
    "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")",
    "title": "CONDITION_NAME"
  }
}
]
}
}

  4. מגדירים את קובץ policy.json החדש באמצעות ה-method‏ setIamPolicy. 

    curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}

שירותים וגרסאות של App Engine

אפשר גם לעדכן את מדיניות IAM של שירות App Engine, את כל הגרסאות או גרסה ספציפית של שירות. כדי לעשות את זה לגרסה ספציפית של שירות:

  1. מייצאים את המשתנים הנוספים הבאים. 
    export GAE_SERVICE=SERVICE_NAME
export GAE_VERSION=VERSION_NAME
  2. מעדכנים את המשתנה GAE_BASE_URL שיוצא. 
    export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
  3. מקבלים ומגדירים את מדיניות ה-IAM לגרסה באמצעות הפקודות getIamPolicy ו-setIamPolicy שמוצגות למעלה.

‫GKE ו-Compute Engine

  1. מייצאים את מזהה הפרויקט של שירות לקצה העורפי. 

    export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME

  2. מקבלים את מדיניות ה-IAM של אפליקציית Compute Engine באמצעות ה-method‏ getIamPolicy. ביט הנתונים הריק בסוף הופך את בקשת curl ל-POST במקום ל-GET. 

    curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
 ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \
 -d ''

  3. מוסיפים את הקישור המותנה של IAM לקובץ ה-JSON של מדיניות ה-IAM. הדוגמה הבאה מציגה קובץ policy.json שעבר עריכה וקושר בו התפקיד iap.httpsResourceAccessor לשני משתמשים, וכך ניתנת להם גישה למשאבים שמוגנים על ידי IAP. נוסף תנאי IAM כדי להעניק להם גישה למשאבים רק אם הם עומדים בדרישה של רמת הגישה ACCESS_LEVEL_NAME ונתיב כתובת ה-URL של המשאב מתחיל ב-/. לכל קשירה יכול להיות רק תנאי אחד.


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

    {
"policy": {
"bindings": [
{
"role": "roles/iap.httpsResourceAccessor",
"members": [
  "group":EXAMPLE_GROUP@GOOGLE.COM,
  "user:EXAMPLE_USER@GOOGLE.COM"
],
"condition": {
  "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")",
  "title": "CONDITION_NAME"
}
}
]
}
}

  4. מגדירים את קובץ policy.json החדש באמצעות ה-method‏ setIamPolicy. 

    curl -i -H "Content-Type:application/json" \
     -H "Authentication: Bearer $(gcloud auth print-access-token)" \
     ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \
     -d @${JSON_NEW_POLICY}

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

אפשר לאבטח את הגישה לאפליקציה באמצעות שם המארח והנתיב של כתובת URL של בקשה. לדוגמה, אפשר להשתמש בתנאי request.path.startsWith IAM כדי להעניק גישה רק לעובדים בקבוצה Privileged Access אם נתיב כתובת ה-URL מתחיל ב-/admin.

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

נירמול מחרוזות

כתובת URL כוללת שם מארח ונתיב. לדוגמה, לכתובת ה-URL‏ https://sheets.google.com/create?query=param יש שם מארח sheets.google.com ונתיב /create.

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

‫IAP מבצע שתי בדיקות מדיניות כשנתיב הבקשה לא מנורמל. אם הנתיב הלא מנורמלי עובר את בדיקת המדיניות, IAP מנרמל את הנתיב ומבצע בדיקת מדיניות שנייה. הגישה תינתן אם גם הנתיב הלא מנורמלי וגם הנתיב המנורמלי יעברו את בדיקת המדיניות.

לדוגמה, אם הנתיב של בקשה הוא /internal;some_param/admin,‏ IAP קודם מבצע בדיקת מדיניות בנתיב הלא מנורמל (/internal). אם הבדיקה הזו עוברת,‏ IAP מבצע בדיקת מדיניות שנייה בנתיב המנורמל (/internal/admin).

שמות מארחים

שמות המארחים עוברים נורמליזציה על ידי:

  • הסרת נקודות בסוף
  • המרת אותיות קטנות
  • המרה ל-ASCII

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

כדי להמיר את מחרוזת שם המארח ל-Punycode, אפשר להשתמש בכלי המרה כמו Punycoder.

דוגמאות לשמות מארחים שעברו נורמליזציה:

  • הערך FOO.com מנורמל ל-foo.com
  • הערך café.fr מנורמל ל-xn--caf-dma.fr

נתיבים

הנתיבים מנורמלים באופן הבא:

  • הסרת פרמטרים של נתיב
  • פתרון נתיבים יחסיים למקבילה המוחלטת שלהם

פרמטר של נתיב כולל את כל התווים מ-; עד ל-/ הבא או עד לסוף הנתיב.

בקשות שמכילות ..; בתחילת קטע נתיב נחשבות לא תקינות. לדוגמה, הפונקציות /..;bar/ ו-/bar/..;/ מחזירות את השגיאה HTTP 400: Bad Request.

דוגמאות לנתיבים מנורמלים:

  • הערך /internal;some_param/admin מנורמל ל-/internal/admin
  • הערך /a/../b מנורמל ל-/b
  • הערך /bar;param1/baz;baz;param2 מנורמל ל-/bar/baz

סיומות של תת-דומיינים

מדיניות שהוגדרה באמצעות request.host.endsWith("google.com") תתאים גם ל-sub_domain.google.com וגם ל-testgoogle.com. אם רוצים להגביל את המדיניות לכל תת-הדומיינים שמסתיימים ב-google.com, צריך להגדיר את המדיניות ל-request.host.endsWith(".google.com").

שימו לב שאם תגדירו את המדיניות שלכם ל-request.host.endsWith(".google.com"), היא תתאים ל-sub_domain.google.com אבל לא ל-google.com בגלל התוספת ..

יומני ביקורת של Cloud ורמות גישה

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

  1. עוברים אל Google Cloud Logs Explorer במסוף של הפרויקט.
    כניסה לדף היומנים
  2. בתפריט הנפתח resource selector, בוחרים משאב. משאבי HTTPS שמוגנים באמצעות IAP נמצאים בקטע App Engine Application (אפליקציית App Engine) ובקטע Compute Engine Backend Service (שירות קצה עורפי של Compute Engine). משאבי SSH ו-TCP מאובטחים באמצעות IAP נמצאים בקטע מכונה וירטואלית ב-Compute Engine.
  3. ברשימה הנפתחת סוג היומנים, בוחרים באפשרות data_access.
    • סוג היומן data_access מופיע רק אם הייתה תנועה למשאב אחרי שהפעלתם את יומני הביקורת של Cloud עבור IAP.
  4. לוחצים כדי להרחיב את התאריך והשעה של הגישה שרוצים לבדוק.
    • לגישה מורשית יש סמל כחול i.
    • גישה לא מורשית מסומנת בסמל כתום !!.
  5. כדי לראות את רמות הגישה שהמבקש עומד בהן, לוחצים על סימן החץ כדי להרחיב את הקטעים עד שמגיעים אל protoPayload > requestMetadata > requestAttributes > auth > accessLevels.

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

מידע נוסף על יומנים זמין במדריך בנושא יומני ביקורת של Cloud.