דוגמאות לתרחישי שימוש במדיניות לקביעת הגישה לישויות מורשות

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

איך מונעים מהמשתמשים לגשת למשאבים מחוץ לארגון

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

• המנהל טל ([e-mail]) הוא חלק מהארגון 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, ולכן הם לא יכולים להשתמש במדיניות דחייה כדי למנוע מטל גישה לקטגוריה.

עם זאת, באמצעות מדיניות לקביעת הגישה לישויות מורשות (PAB), example.com אדמינים יכולים למנוע מטל לצפות באובייקטים בדלי cymbalgroup.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": "4"
  }
}

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

{
  "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.com לא יכולים להשתמש בהרשאות שנחסמות על ידי מדיניות גבולות הגישה של חשבון המשתמש כדי לגשת למשאבים מחוץ ל-example.com, גם אם יש להם את ההרשאות האלה במשאבים האלה.

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

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

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

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

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

{
  "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": "4"
  }
}

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

אחרי שיוצרים את המדיניות לקביעת הגישה לישויות מורשות, יוצרים קישור למדיניות כדי לקשר את המדיניות החדשה לכל הישויות המורשות ב-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-dev.

ניהול הזכאות לקבוצות שונות של ישויות

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

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

כדי להשיג את היעד הזה, אתם צריכים:

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

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

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

   "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.iam.gserviceaccount.com') && principal.subject != '[e-mail]' && principal.subject != '[e-mail]')"
   }
   

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

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

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

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