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

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

רמות גישה מאפשרות להגביל את הגישה למשאבים על סמך כתובת IP ומאפייני המכשיר של משתמש הקצה. תנאי IAM מאפשרים להגביל את הגישה על סמך מארחים, נתיבים, תאריך ושעה של כתובות URL.

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

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

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

  • צריך לתת גישה רק לעובדים בקבוצה 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. ב-Info panel שבצד ימין, לוחצים על Add principal.

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

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

    • כדי לציין רמות גישה קיימות, בוחרים אותן מהרשימה הנפתחת Access levels. כדי לראות את רמות הגישה הקיימות, צריך לבחור את התפקיד משתמש באפליקציית אינטרנט שמאובטחת באמצעות 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. ב-Info panel שבצד ימין, בקטע Role / Principal, לוחצים על התפקיד שרוצים להסיר מהחשבון הראשי.

  4. לוחצים על Remove ליד חשבון המשתמש.

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

      בקטע הקוד הבא מוצג תנאי 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 של האפליקציה, פועלים לפי התהליך שמתאים לסוג האפליקציה. במאמר ניהול הגישה למשאבים שמאובטחים באמצעות IAP מוסבר איך משתמשים ב-IAM API כדי לנהל את מדיניות הגישה.

לפני שמבצעים את השלבים הספציפיים לאפליקציה ב-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 באמצעות השיטה 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 של הבקשה. לדוגמה, אפשר להשתמש בתנאי ה-IAM‏ request.path.startsWith כדי לתת גישה רק לעובדים בקבוצה 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. נכנסים לדף Logs Explorer של הפרויקט במסוף Google Cloud .
    כניסה לדף היומנים
  2. ברשימה הנפתחת בורר המשאבים, בוחרים משאב. משאבי HTTPS שמאובטחים באמצעות IAP נמצאים בקטגוריות אפליקציית App Engine ושירות לקצה העורפי של Compute Engine. משאבי SSH ו-TCP שמאובטחים באמצעות IAP נמצאים בקטגוריה מכונה וירטואלית של Compute Engine.
  3. ברשימה הנפתחת logs type, בוחרים באפשרות data_access.
    • סוג היומן data_access מופיע רק אם הייתה תעבורת נתונים למשאב אחרי שהפעלתם את יומני ביקורת של Cloud ל-IAP.
  4. לוחצים על התאריך והשעה של הגישה שרוצים לבדוק כדי להרחיב את הפרטים.
    • לגישה מורשית יש סמל i כחול.
    • גישה לא מורשית מסומנת בסמל כתום !!.
  5. כדי לראות את רמות הגישה שהמשתמש שמבקש את הגישה עומד בהן, לוחצים על הקטעים כדי להרחיב אותם עד שמגיעים אל protoPayload > requestMetadata > requestAttributes > auth > accessLevels.

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

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