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

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

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

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

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

כדי להפיק את המרב מפותר הבעיות שקשורות למדיניות, צריך לוודא שיש לכם את התפקיד Security Reviewer (roles/iam.securityReviewer). התפקיד הזה מאפשר לכם לקרוא את כל כללי המדיניות הרלוונטיים של Cloud IAM.

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

1. יוצרים תפקיד אדמין מותאם אישית ב-Google Workspace שכולל את ההרשאה שירותים > ניהול מכשירים ניידים > ניהול מכשירים והגדרות (נמצאת בקטע הרשאות במסוף Admin).
2. מקצים את התפקיד למשתמשים באמצעות מסוף Admin.

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

1. יוצרים תפקיד אדמין בהתאמה אישית ב-Google Workspace שכולל את ההרשאה קבוצות > קריאה (שנמצאת בקטע הרשאות Admin API).
2. מקצים את התפקיד למשתמש. כך המשתמש יכול לראות את החברים בכל הקבוצות בדומיין, ולפתור בעיות גישה בצורה יעילה יותר.

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

סקירה כללית על תהליך העבודה של פותר הבעיות

פתרון בעיות שקשורות לגישה שנחסמה

כדי לפתור בעיות שקשורות לגישה שנחסמה, אפשר להפעיל את התכונה למשאב IAP בהגדרות IAP. לשם כך, לוחצים על סמל האפשרויות הנוספות (3 נקודות) משמאל לאפליקציה שמוגנת על ידי IAP, על הגדרות ואז על יצירת כתובת URL לפתרון בעיות. כדי להפיק את המרב מפותר הבעיות שקשורות למדיניות, צריך לוודא שיש לכם את התפקיד 'אדמין של הגדרות IAP' (roles/iap.settingsAdmin). התפקיד הזה מאפשר לכם לאחזר ולעדכן את הגדרות ה-IAP של כל משאבי ה-IAP.

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

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

הגישה של המשתמש נדחתה

כשמשתמש לא מקבל הרשאה או לא עומד בתנאי הנדרש לגישה למשאב IAP, הוא מופנה לדף שגיאה 403 (הגישה נדחתה). הדף עם השגיאה 403 כולל כתובת URL לפתרון בעיות שאפשר להעתיק ולשלוח באופן ידני לבעלים של האפליקציה או לאדמין האבטחה, או שהמשתמש יכול ללחוץ על שליחת אימייל בממשק המשתמש.

כשמשתמש לוחץ על שליחת אימייל, נשלח אימייל לכתובת האימייל לתמיכה (supportEmail) שהוגדרה במסך ההסכמה של OAuth. למידע נוסף על הגדרת מסך ההסכמה ל-OAuth, ראו יצירת לקוחות OAuth ל-IAP באופן פרוגרמטי.

פתרון בעיות בגישה שנכשלה

כשמקבלים קישור לבקשת גישה שנכשלה ממשתמש קצה, אפשר ללחוץ על כתובת ה-URL והיא תיפתח בדפדפן ברירת המחדל. אם לא נכנסתם למסוף Google Cloud בדפדפן ברירת המחדל, יכול להיות שתופנו לדף התחברות אחר כדי לגשת לדף הניתוח של הכלי לפתרון בעיות שקשורות למדיניות.

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

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

כדי לנתח את הגישה שנכשלה, אפשר לעיין בפרטי הקישור. בפרטי הקישור אפשר לראות את רכיבי הקישור: תפקיד, גורם מרכזי ותנאי. ברכיב שיש לו הרשאות מספיקות יופיע הכיתוב לא נדרשת פעולה. רכיבים שהגישה אליהם נכשלה, הפערים בהרשאות מוסברים באופן מפורש, למשל Principal Category: Please add Principal to the below groups.

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

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

הפעלת כתובת ה-URL לפתרון בעיות בדף השגיאה המותאם אישית Access Denied

כדי להוסיף את כתובת ה-URL של פותר הבעיות שקשורות למדיניות לדף השגיאה של הלקוח Access Denied, צריך לבצע את השלבים הבאים:

1. כדי להפנות את המשתמשים לדף בהתאמה אישית במקום לדף השגיאה שמוגדר כברירת מחדל ב-IAP, צריך לבצע את השלב הבא: הגדרת דף שגיאה בהתאמה אישית לגישה שנחסמה.
2. מפעילים את התכונה 'כתובת URL של פותר הבעיות שקשורות למדיניות' בהגדרות של IAP.

אחרי שמגדירים את כתובת ה-URL של הדף access denied בהגדרות של IAP, כתובת ה-URL של פותר הבעיות שקשורות למדיניות מוטמעת כפרמטר שאילתה עם תווי escape. לפני שפותחים את פרמטר השאילתה, צריך לוודא שהסרתם את הסימון של התווים המיוחדים. המפתח של פרמטר השאילתה הוא troubleshooting-url.

פתרון בעיות בגישת משתמשים באופן יזום

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

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

כשמבצעים פתרון בעיות בבקשות היפותטיות באמצעות מזהה המכשיר, צריך לוודא שהמכשיר שייך לכתובת האימייל של חשבון המשתמש שמוגדר כיעד. אפשר למצוא את מזהה המכשיר ביומן הביקורת של IAP או על ידי מעבר אל מסוף Google Admin -> מכשירים -> ניידים ונקודות קצה -> מכשירים.

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

• is_secured_with_screenlock
• encryption_status
• os_type
• os_version
• verified_chrome_os
• is_admin_approved_device
• is_corp_owned_device

תרחישים נפוצים לפתרון בעיות

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

• אחרי פתרון הבעיה, אתם מספקים למשתמש הקצה פריט פעולה, כמו הנחיה לעבור למכשיר בבעלות החברה או לעדכן את מערכת ההפעלה.
• אתם מגלים שלא הקציתם את ההרשאה הנכונה למשתמש הקצה, ולכן אתם יוצרים קשר חדש עבור הישות העיקרית של היעד בממשק IAP ‏ (roles/iap.httpsResourceAccessor).
• גיליתם שיצרתם רמת גישה באופן שגוי, למשל מהסיבות הבאות:
  • יצרתם הגבלות מורכבות על מאפיינים מוטמעים, כמו רשתות משנה ארגוניות, שכבר לא רלוונטיות כי העובדים עובדים עכשיו מהבית.
  • השתמשתם בפרמטרים שגויים של רמת הגישה. לדוגמה, הגדרתם שהמשתמשים יכולים ליצור רמה מותאמת אישית עם הגבלות על ספקים, אבל השוויתם מאפיינים מסוגים שונים. לדוגמה, device.vendors["vendorX"].data.["should_contain_boolean_value"] == "true". שימו לב שהצד השמאלי מחזיר ערך בוליאני, והצד הימני מחזיר מחרוזת true. בגלל המאפיינים הלא שווי ערך, קשה לזהות את השגיאה במבנה המדיניות. פותר הבעיות שקשורות למדיניות מסביר שמדובר בשגיאה, ומציג תוצאות מפורטות של הערכה חלקית משני הצדדים.

התנהגות צפויה של פותר הבעיות

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

טיפים לפתרון בעיות שקשורות לקישורים

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

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

• במידת הצורך, בודקים קשירות אחרות או יוצרים קשירה חדשה באמצעות ממשק IAP כדי להעניק את התפקיד roles/iap.httpsResourceAccessor למשתמש עם רמות גישה שהוגדרו.
• אם מדובר בתפקיד בהתאמה אישית, אפשר להוסיף את הרשאת היעד לתפקיד בהתאמה אישית כדי להעניק את ההרשאה (אחרי שמתקנים את כל הכשלים בחשבון המשתמש ואת כל הכשלים בתנאי, כשזה רלוונטי). שימו לב: אם מוסיפים הרשאות לתפקיד בהתאמה אישית, יכול להיות שקישורים אחרים עם התפקיד הזה יקבלו יותר הרשאות ממה שצריך. אל תעשו את זה אלא אם אתם מודעים להיקף של התפקיד המותאם אישית ולסיכון של הפעולה שלכם.
• אם זה לא תפקיד בהתאמה אישית, בודקים את ההרשאות האחרות או יוצרים הרשאה חדשה באמצעות ממשק IAP כדי להעניק את התפקיד roles/iap.httpsResourceAccessor לחשבון המשתמש עם רמות הגישה שהוגדרו, אם צריך.

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

• אם רשימת המשתתפים כוללת קבוצה, אתם יכולים להוסיף את חשבון המשתמש לקבוצה כדי להעניק לו את ההרשאות (אחרי שתתקנו את כל הכשלים בתנאים, אם רלוונטי). שימו לב: הוספת חשבון משתמש לקבוצה קיימת עשויה להעניק לקבוצה הרשאות רבות יותר מהנדרש. אל תעשו את זה אלא אם אתם מודעים להיקף של הקבוצה ולסיכון של הפעולה.
• אם החברים לא מכילים קבוצה, בודקים קשרים אחרים או יוצרים קשר חדש באמצעות ממשק IAP כדי להעניק את roles/iap.httpsResourceAccessor למשתמש הראשי עם רמות גישה שהוגדרו, אם צריך.

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