יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

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

הסבר על מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

כברירת מחדל, לחשבונות ראשיים יש אפשרות לגשת לכל משאב. Cloud de Confiance by S3NS כלומר, אם לחשבון משתמש יש הרשאה למשאב וההרשאה הזו לא נדחתה, הוא יכול להשתמש בה כדי לגשת למשאב.

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

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

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

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

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

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

מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שמונעת גישה למשאב

המנהל טל (tal@example.com) הוא חלק מהארגון example.com ב-Google Workspace.
לתל מוקצה התפקיד 'אדמין אחסון' (roles/storage.admin) בקטגוריה של Cloud Storage בארגון אחר, cymbalgroup.com. התפקיד הזה מכיל את ההרשאה storage.objects.get, שנדרשת כדי להציג אובייקטים בקטגוריה.
אין ב-cymbalgroup.com כללי מדיניות דחייה שמונעים מטאל להשתמש בהרשאה storage.objects.get.

אם יש רק מדיניות הרשאה ומדיניות דחייה, example.com לא יכול למנוע מטל לצפות באובייקטים בקטגוריה החיצונית הזו. לאף אחד מחשבונות המשתמשים הראשיים example.com אין הרשאה לערוך את מדיניות ההרשאה של הדלי, ולכן הם לא יכולים לבטל את התפקיד של טל. אין להם גם הרשאה ליצור כללי מדיניות דחייה ב-cymbalgroup.com, ולכן הם לא יכולים להשתמש בכללי מדיניות דחייה כדי למנוע מטל גישה לקטגוריה.

עם זאת, באמצעות מדיניות של גבולות גישה לחשבונות משתמשים, אדמינים ב-example.com יכולים לוודא שטלי לא יכולה לראות אובייקטים בקטגוריה cymbalgroup.com או בכל קטגוריה אחרת מחוץ ל-example.com. כדי לעשות את זה, האדמינים יכולים ליצור מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שקובעת שחשבונות משתמשים example.com יכולים לגשת רק למשאבים ב-example.com. לאחר מכן, הם יכולים ליצור קשר בין המדיניות לבין כל החשבונות הראשיים בארגון example.com. אם מדיניות כזו מוגדרת, טל לא יוכל לצפות באובייקטים בקטגוריה cymbalgroup.com, גם אם הוקצה לו התפקיד'אדמין אחסון' בקטגוריה.

הערכה מסוג Fail-closed

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

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

הרשאות שנחסמות על ידי מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

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

לדוגמה, נניח שחשבון משתמש, Lee (lee@example.com), קיבל את התפקיד 'מפתח Dataflow' (roles/dataflow.developer). התפקיד הזה כולל את ההרשאה dataflow.jobs.snapshot, שמאפשרת ל-Lee ליצור תמונות מצב של משימות Dataflow. בנוסף, לי כפוף למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB), ולכן הוא לא יכול לגשת למשאבים מחוץ ל-example.com. עם זאת, אם מדיניות גבולות הגישה של הגורם המורשה לא חוסמת את ההרשאה dataflow.jobs.snapshot, לי עדיין יכול לצלם תמונות של משימות Dataflow בארגונים מחוץ ל-example.com.

ההרשאות שהמדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) חוסמת תלויות בגרסת האכיפה של גבול הגישה לחשבונות משתמשים.

גרסאות של אכיפת בקרת גישה לישויות מורשות (PAB)

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

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

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

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

גרסת ברירת המחדל לאכיפה

גרסת האכיפה שמוגדרת כברירת מחדל משמשת למדיניות הבאה לקביעת גבול הגישה לחשבונות משתמשים (PAB):

מדיניות חדשה שלא מצוין בה מספר גרסה
מדיניות שמשתמשת בערך latest לגרסה

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

קישור מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) לקבוצות של חשבונות משתמשים

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

אפשר לקשר מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) לכל מספר של קבוצות חשבונות משתמשים. כל קבוצת חשבונות משתמשים יכולה לכלול עד 10 כללי מדיניות לקביעת גבול הגישה לחשבונות משתמשים.

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

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

קבוצות נתמכות של ישויות

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

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

קבוצת חשבונות משתמש	פרטים	משאב ההורה של קשרי מדיניות
מאגר זהויות של כוח עבודה	מכיל את כל הזהויות במאגר הזהויות של כוח העבודה שצוין. פורמט: `//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID`	הארגון שמכיל את מאגר הזהויות של כוח העבודה
מאגר זהויות של עומסי עבודה	מכיל את כל הזהויות במאגר הזהויות של עומסי העבודה שצוין. פורמט: `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID`	הפרויקט שמכיל את מאגר הזהויות של עומסי העבודה
דומיין של Google Workspace	כולל את כל הזהויות בדומיין Google Workspace שצוין. פורמט: `//iam.googleapis.com/locations/global/workspace/CUSTOMER_ID` אפשר למצוא את מספר הלקוח בדרכים הבאות: משתמשים בפקודה `gcloud organizations describe`. מזהה סביבת העבודה מופיע בשדה `directoryCustomerId` בתגובה. משתמשים בשיטה `organizations.get` ב-Cloud Resource Manager API. מזהה סביבת העבודה מופיע בשדה `directoryCustomerId` בתגובה. איך רואים את מזהה הלקוח במסוף Admin כדי להשתמש בשיטה הזו, נדרש תפקיד סופר-אדמין ב-Google Workspace.	הארגון שמשויך לדומיין Google Workspace
הגדרת העיקרון של הפרויקט	מכיל את כל חשבונות השירות, מאגרי הזהויות של עומסי העבודה והזהויות של הסוכנים בפרויקט שצוין. פורמט: `//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	הפרויקט
הוגדר עיקרון לתיקייה	מכיל את כל חשבונות השירות, את כל מאגרי הזהויות של עומסי העבודה ואת כל הזהויות של הסוכנים בכל פרויקט בתיקייה שצוינה. פורמט: `//cloudresourcemanager.googleapis.com/folders/FOLDER_ID`	התיקייה
הקבוצה העיקרית של הארגון	מכיל את הזהויות הבאות: כל הזהויות בכל הדומיינים שמשויכים למספר הלקוח שלכם ב-Google Workspace כל מאגרי הזהויות של כוח העבודה בארגון כל חשבונות השירות, מאגרי הזהויות של כוח העבודה והזהויות של הסוכנים בכל פרויקט בארגון פורמט: `//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	הארגון
זהויות של נציגים	כל הזהויות של הסוכנים בדומיין המהימן של הפרויקט שצוין. כברירת מחדל, דומיין האמון של פרויקט מכיל את כל זהויות הסוכנים בפרויקט. פורמטים: `//agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.container/projects/PROJECT_NUMBER` `//agents.global.proj-PROJECT_NUMBER.system.id.goog/attribute.container/projects/PROJECT_NUMBER`	הפרויקט

קישורי מדיניות מותנים למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

אפשר להשתמש במאפיינים principal.type ו-principal.subject בתנאים של קישורי מדיניות. אין תמיכה במאפיינים אחרים בתנאים של קישורי מדיניות.

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

לדוגמה, אם מוסיפים את ביטוי התנאי הבא לקישור במדיניות של גבולות גישה לחשבון משתמש, המדיניות חלה רק על חשבונות שירות:
```
principal.type == 'iam.googleapis.com/ServiceAccount'
```
המאפיין principal.subject מציין את הזהות של חשבון המשתמש בבקשה – לדוגמה, cruz@example.com. אפשר להשתמש בתנאים עם המאפיין הזה כדי לקבוע בדיוק אילו חשבונות משתמשים כפופים למדיניות של גבולות גישה לחשבונות משתמשים.

לדוגמה, אם מוסיפים את ביטוי התנאי הבא לקישור של מדיניות גבולות גישה לחשבון משתמש, המדיניות לא תחול על המשתמש special-admin@example.com:
```
principal.subject != 'special-admin@example.com'
```

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

דוגמה: שימוש בתנאים כדי לצמצם את המשאבים שחשבון משתמש יכול לגשת אליהם

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

נניח שיש לכם חשבון שירות, dev-project-service-account, עם כתובת האימייל dev-project-service-account@dev-project.s3ns.iam.gserviceaccount.com. חשבון השירות הזה כפוף למדיניות של גבולות גישה לחשבונות ראשיים, שמאפשרת לחשבונות ראשיים לגשת לכל המשאבים בארגון example.com. המדיניות הזו מצורפת לקבוצת העקרונות של הארגון example.com.

אתם מחליטים שאתם לא רוצים שdev-project-service-account יוכל לגשת לכל המשאבים ב-example.com – אתם רוצים שהוא יוכל לגשת רק למשאבים ב-dev-project. עם זאת, אתם לא רוצים לשנות את המשאבים שחשבונות ראשיים אחרים בexample.com קבוצת החשבונות הראשיים יכולים לגשת אליהם.

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

אתם מאשרים שמדיניות הגבלת הגישה לחשבונות משתמשים היחידה שחלה על dev-project-service-account היא המדיניות שמאפשרת לחשבונות משתמשים לקבל גישה לכל המשאבים ב-example.com.
יוצרים מדיניות חדשה לקביעת גבול הגישה לחשבונות משתמשים שמאפשרת לחשבונות משתמשים לגשת למשאבים ב-dev-project ומצרפים אותה לקבוצת חשבונות המשתמשים של dev-project. משתמשים בתנאי הבא בקישור המדיניות כדי לוודא שהמדיניות נאכפת רק עבור dev-project-service-account:
```
"condition": {
  "title": "Only dev-project-service-account",
  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.s3ns.iam.gserviceaccount.com'"
}
```
אתם מחריגים את dev-project-service-account ממדיניות גבול הגישה לחשבונות משתמשים, שמאפשרת לחשבונות משתמשים לגשת לכל המשאבים ב-example.com. כדי לעשות את זה, מוסיפים את התנאי הבא לקישור המדיניות שמצרף את המדיניות לקביעת גבול הגישה לחשבונות משתמשים לקבוצת החשבונות הראשיים של הארגון:
```
"condition": {
  "title": "Exempt dev-project-service-account",
  "expression": "principal.subject != 'dev-project-service-account@dev-project.s3ns.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
}
```
במאמר עריכת מדיניות לקביעת גבול הגישה לחשבונות משתמשים מוסבר איך מעדכנים מדיניות קיימת לקביעת גבול הגישה לחשבונות משתמשים.

אחרי שמוסיפים את התנאי הזה לקישור המדיניות, לחשבון dev-project-service-account כבר אין יותר אפשרות לגשת לכל המשאבים ב-example.com, אלא רק למשאבים ב-dev-project.

קישורי מדיניות בין ארגונים

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

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

יש לכם פרויקט, example-project, בארגון example.com.
אתם רוצים שחשבונות משתמשים ב-example-project יוכלו לגשת למשאבים ב-example.com. כדי לעשות את זה, יוצרים ב-example.com מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שמאפשרת לחשבונות משתמשים לגשת למשאבים ב-example.com, ומקשרים את המדיניות הזו לקבוצת החשבונות שמוגדרת ל-example-project.
העברת example-project מ-example.com אל cymbalgroup.com.

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

אינטראקציות עם המדיניות

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

אינטראקציה עם סוגי מדיניות אחרים

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

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

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

מידע נוסף על הערכת מדיניות IAM זמין במאמר הערכת מדיניות.

אינטראקציה בין מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

לדוגמה, נניח שחשבון משתמש, Dana (dana@example.com), כפוף למדיניות אחת לקביעת גבול הגישה לחשבונות משתמשים, prod-projects-policy. המדיניות הזו מאפשרת לחשבונות משתמשים לגשת למשאבים ב-prod-project. המדיניות הזו חלה על דנה כי היא קשורה לקבוצת המשתמשים הראשית של הארגון שלה.

יוצרים מדיניות חדשה של גבולות גישה למשתמשים, dev-staging-projects-policy, שמאפשרת למשתמשים לגשת למשאבים ב-dev-project וב-staging-project, ואז מקשרים אותה לקבוצת המשתמשים של הארגון.

כתוצאה ממדיניות הגבלת הגישה לחשבונות משתמשים, דנה יכולה לגשת למשאבים ב-dev-project, ב-staging-project וב-prod-project.

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

לדוגמה, אפשר לערוך את dev-staging-projects-policy כך שחשבונות משתמשים לא יוכלו לגשת למשאבים ב-dev-project. במקרה כזה, דנה תוכל לגשת רק למשאבים ב-staging-project וב-prod-project.

אפשר גם להסיר את prod-projects-policy על ידי מחיקת קשירת המדיניות שמקשרת אותה לקבוצת החשבונות של הארגון. במקרה כזה, דנה תוכל לגשת רק למשאבים ב-dev-project וב-staging-project.

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

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

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

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

לדוגמה, נניח שיש ארגון בשם example.com. הארגון הזה משויך לדומיין example.com, ויש לו את המשאבים הבאים של מנהל המשאבים:

היררכיית משאבים לדומיין example.com

ארגון, example.com
פרויקט, project-1, שהוא צאצא של הארגון
תיקייה, folder-a, שהיא צאצא של הארגון
שני פרויקטים, project-2 ו-project-3, שהם צאצאים של folder-a

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

קבוצת חשבונות משתמש	זהויות ב-Google Workspace בדומיין `example.com`	מאגרי זהויות של כוח עבודה ב-`example.com`	חשבונות שירות ומאגרי זהויות של עומסי עבודה ב-`project-1`	חשבונות שירות ומאגרי זהויות של עומסי עבודה ב-`project-2`	חשבונות שירות ומאגרי זהויות של עומסי עבודה ב-`project-3`
הוגדר עיקרון ל-`example.com`
הוגדר עיקרון ל-`folder-a`
הוגדר עיקרון ל-`project-1`
הוגדר עיקרון ל-`project-2`
הוגדר עיקרון ל-`project-3`

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

זהות ב-Google Workspace בדומיין example.com נמצאת בקבוצת החשבונות הראשיים של example.com, ותושפע ממדיניות הגבלת הגישה לחשבונות ראשיים שקשורה לקבוצת החשבונות הראשיים הזו.
חשבון שירות ב-project-1 נמצא בקבוצות של חשבונות משתמשים עבור project-1 ו-example.com, וישפיעו עליו כללי מדיניות של גבולות גישה לחשבונות משתמשים שקשורים לאחת מהקבוצות האלה.
חשבון שירות ב-project-3 נמצא בקבוצות של חשבונות משתמשים עבור project-3,‏ folder-a ו-example.com, ויושפע ממדיניות של גבולות גישה לחשבונות משתמשים שקשורה לאחת מהקבוצות האלה של חשבונות משתמשים.

המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) ומשאבים במטמון

שירותים מסוימים Cloud de Confiance by S3NS שומרים במטמון משאבים שגלויים לכולם. לדוגמה, מערכת Cloud Storage שומרת במטמון אובייקטים שניתנים לקריאה באופן ציבורי.

האם בקרת גישה לישויות מורשות (PAB) יכולה למנוע מישויות מורשות לא כשירות לצפות במשאב שגלוי לציבור? התשובה תלויה בשאלה אם המשאב נשמר במטמון:

אם המשאב נשמר במטמון, בקרת גישה לישויות מורשות (PAB) לא יכולה למנוע מישויות מורשות לצפות במשאב
אם המשאב לא נשמר במטמון, בקרת גישה לישויות מורשות (PAB) מונעת מישויות מורשות לא מתאימות לצפות במשאב

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

המבנה של מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

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

מטא-נתונים

כללי מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) מכילים את המטא-נתונים הבאים:

name: השם של המדיניות לקביעת גבול הגישה לחשבונות משתמשים. הפורמט של השם הוא organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, שבו ORGANIZATION_ID הוא המזהה המספרי של הארגון שבו נוצרה המדיניות לקביעת גבול הגישה לחשבונות משתמשים ו-PAB_POLICY_ID הוא המזהה האלפאנומרי של המדיניות לקביעת גבול הגישה לחשבונות משתמשים.
uid: מזהה ייחודי שמוקצה למדיניות לקביעת גבול הגישה לחשבונות משתמשים.
etag: מזהה של המצב הנוכחי של המדיניות. הערך הזה משתנה כשמעדכנים את המדיניות. כדי למנוע עדכונים סותרים, הערך של etag חייב להיות זהה לערך שמאוחסן ב-IAM. אם ערכי etag לא תואמים, הבקשה תיכשל.
‫displayName: שם קריא לאנשים של המדיניות לקביעת גבול הגישה לחשבונות משתמשים.
‫annotations: אופציונלי. רשימה של צמדי מפתח/ערך שהוגדרו על ידי המשתמש. אפשר להשתמש באנוטציות האלה כדי להוסיף מטא נתונים נוספים למדיניות – לדוגמה, מי יצר את המדיניות או אם המדיניות נפרסה על ידי צינור אוטומטי. מידע נוסף על הערות זמין במאמר בנושא הערות.
createTime: השעה שבה נוצרה המדיניות לקביעת גבול הגישה לחשבונות משתמשים.
updateTime: השעה שבה עודכנה לאחרונה המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

פרטים

כל מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) מכילה שדה details. השדה הזה מכיל את הכללים של בקרת גישה לישויות מורשות (PAB) ואת גרסת האכיפה:

rules: רשימה של כללים להגבלת הגישה לחשבונות משתמשים, שמגדירים את המשאבים שחשבונות המשתמשים המושפעים יכולים לגשת אליהם. כל כלל מכיל את השדות הבאים:
- ‫description: תיאור של הכלל שקריא לאנשים.
- ‫resources: רשימה של משאבים ב-מנהל המשאבים (פרויקטים, תיקיות וארגונים) שרוצים שישויות מורשות יוכלו לגשת אליהם. כל גורם (principal) שחל עליו כלל המדיניות הזה יכול לגשת למשאבים האלה.
  
  כל מדיניות לקביעת גבול הגישה לחשבונות משתמשים יכולה להפנות ל-500 משאבים לכל היותר בכל הכללים במדיניות.
- ‫effect: הקשר של חשבונות המשתמשים למשאבים שמופיעים בשדה resources. ההשפעה היחידה שאפשר לציין בכללי בקרת גישה לישויות מורשות (PAB) היא "ALLOW". הקשר הזה מאפשר לחשבונות המשתמשים לגשת למשאבים שמפורטים בכלל.
‫enforcementVersion: גרסת האכיפה שבה IAM משתמש כשהוא אוכף את המדיניות. הגרסה של המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) קובעת אילו הרשאות המדיניות יכולה לחסום.

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

המבנה של קישור מדיניות

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

לדוגמה, קישור המדיניות הבא מקשר את המדיניות example-policy לכל חשבונות המשתמשים בארגון example.com, שמזהה שלו הוא 0123456789012. קישור המדיניות מכיל גם תנאי שמונע את האכיפה של המדיניות עבור החשבון הראשי super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

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

name: השם של קישור המדיניות. הפורמט של השם הוא RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, שבו RESOURCE_TYPE/RESOURCE_ID הוא הסוג והמזהה של משאב ההורה של שיוך המדיניות ו-BINDING_ID הוא המזהה האלפאנומרי של שיוך המדיניות.
uid: מזהה ייחודי שמוקצה לקישור של מדיניות.
etag: מזהה של המצב הנוכחי של המדיניות. הערך הזה משתנה כשמעדכנים את המדיניות. כדי למנוע עדכונים סותרים, הערך של etag חייב להיות זהה לערך שמאוחסן ב-IAM. אם ערכי etag לא תואמים, הבקשה תיכשל.
displayName: שם קריא לאנשים של קישור המדיניות.
‫annotations: אופציונלי. רשימה של צמדי מפתח/ערך שהוגדרו על ידי המשתמש. אפשר להשתמש באנוטציות האלה כדי להוסיף מטא נתונים נוספים לקשירת המדיניות – לדוגמה, מי יצר את קשירת המדיניות, או אם קשירת המדיניות נפרסה על ידי צינור אוטומטי. מידע נוסף על הערות זמין במאמר בנושא הערות.
‫target: חשבון המשתמש שאליו המדיניות משויכת. הערך הוא בפורמט {"principalSet": PRINCIPAL_SET}, כאשר PRINCIPAL_SET הוא המזהה של קבוצת חשבונות המשתמשים שרוצים לקשר אליה את המדיניות.

לכל יעד יכולים להיות עד 10 כללי מדיניות שמשויכים אליו.
‫policyKind: סוג המדיניות שאליה מתייחס קישור המדיניות. במקרה של קשירת מדיניות למדיניות לקביעת גבול הגישה לחשבונות משתמשים, הערך הזה הוא תמיד PRINCIPAL_ACCESS_BOUNDARY.
‫policy: המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שרוצים לקשר לקבוצת חשבונות המשתמשים של היעד.
policyUid: מזהה ייחודי שמוקצה למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שמצוינת בשדה policy.
‫condition: אופציונלי. ביטוי לוגי שמשפיע על החשבונות שבהם IAM אוכף את המדיניות. אם התנאי מקבל את הערך true או שהוא לא יכול לקבל שום ערך, מערכת ניהול הזהויות והרשאות הגישה (IAM) אוכפת את המדיניות על חשבון המשתמש ששולח את הבקשה. אם התנאי מקבל את הערך False, מערכת ניהול הזהויות והרשאות הגישה לא אוכפת את המדיניות על חשבון המשתמש. מידע נוסף זמין בקטע בקרת גישה לישויות מורשות (PAB) ותנאים שבדף הזה.
createTime: השעה שבה נוצר קישור המדיניות.
‫updateTime: השעה שבה עודכן לאחרונה קישור המדיניות.

תרחישים לדוגמה

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

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

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

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

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

כדי להגדיר חשבונות משתמשים כבעלי הרשאה לגשת למשאבים ב-example.com וכחסרי הרשאה לגשת למשאבים מחוץ ל-example.com, יוצרים מדיניות של גבולות גישה לחשבונות משתמשים, שמגדירה את חשבונות המשתמשים כבעלי הרשאה לגשת למשאבים ב-example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

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

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

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

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

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

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

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

יש לכם מדיניות של גבולות גישה לחשבונות משתמשים שמאפשרת לכל חשבונות המשתמשים בארגון, כולל חשבונות השירות ב-example-dev, לגשת למשאבים ב-example.com. כדי לראות איך נראית מדיניות כזו, אפשר לעיין במאמר הגדרת חשבונות משתמשים כבעלי הרשאה לגשת למשאבים בארגון.

כדי למנוע מחשבונות השירות ב-example-dev לגשת למשאבים מחוץ ל-example-dev, קודם יוצרים מדיניות של גבולות גישה לחשבונות משתמשים שמאפשרת לחשבונות משתמשים לגשת למשאבים ב-example-dev

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

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

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

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

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

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.s3ns.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.s3ns-system.iam.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.s3ns-system.iam.gserviceaccount.com'"
  }
}

מעכשיו, חשבונות השירות ב-example-dev יכולים לגשת רק למשאבים ב-example-dev. הם לא יכולים להשתמש בהרשאות שנחסמות על ידי המדיניות לקביעת גבול הגישה לחשבונות משתמשים כדי לגשת למשאבים מחוץ ל-example-dev, גם אם יש להם את ההרשאות האלה במשאבים האלה.

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