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

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

בדף הזה מוצגים כללי מדיניות הרשאה בפורמט JSON. אפשר גם להשתמש ב-Google Cloud CLI כדי לאחזר את כללי מדיניות ההרשאה בפורמט YAML.

מבנה המדיניות

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

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

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

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

    אם קישור התפקיד מכיל תנאי, הוא מכונה קישור תפקיד מותנה.

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

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

מגבלות על כל החשבונות

כל מדיניות הרשאה יכולה להכיל עד 1,500 חשבונות משתמשים. למטרות המגבלה הזו, IAM סופר את כל המופעים של כל חשבון משתמש בקישורי התפקידים של מדיניות ההרשאות, וגם את חשבונות המשתמשים שמדיניות ההרשאות פוטרת מרישום ביומני ביקורת של גישה לנתונים. הוא לא מבטל כפילויות של חשבונות משתמשים שמופיעים בכמה קישורי תפקידים. לדוגמה, אם מדיניות הרשאות כוללת רק קישורי תפקידים לחשבון המשתמש user:my-user@example.com, וחשבון המשתמש הזה מופיע ב-50 קישורי תפקידים, תוכלו להוסיף עוד 1,450 חשבונות משתמשים לקישורי התפקידים במדיניות ההרשאות.

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

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

מגבלות על קבוצות ודומיינים

עד 250 מחשבונות המשתמשים של מדיניות הרשאה יכולים להיות קבוצות של Google, דומיינים של Cloud Identity או חשבונות Google Workspace.

לצורכי המגבלה הזו, דומיינים של Cloud Identity, חשבונות Google Workspace וקבוצות Google נספרים באופן הבא:

  • לקבוצות Google, כל קבוצה ייחודית נספרת פעם אחת בלבד בלי קשר למספר הפעמים שהקבוצה מופיעה במדיניות ההרשאות. הספירה הזו שונה מהספירה של קבוצות במסגרת המגבלה על המספר הכולל של חשבונות משתמשים במדיניות הרשאה – במסגרת המגבלה הזו, כל מופע של קבוצה נספר במסגרת המגבלה.
  • בדומיינים של Cloud Identity או בחשבונות Google Workspace, ‏ IAM סופר את כל המופעים של כל דומיין או חשבון בקישורי התפקידים של מדיניות ההרשאות. הוא לא מבטל כפילויות של דומיינים או חשבונות שמופיעים בכמה קישורי תפקידים.

לדוגמה, אם מדיניות ההרשאות כוללת רק קבוצה אחת, group:my-group@example.com, והקבוצה מופיעה במדיניות ההרשאות 10 פעמים, תוכלו להוסיף עוד 249 דומיינים של Cloud Identity, חשבונות Google Workspace או קבוצות ייחודיות עד שתגיעו למגבלה.

לחלופין, אם מדיניות ההרשאות כוללת רק דומיין אחד, domain:example.com, והדומיין מופיע במדיניות ההרשאות 10 פעמים, תוכלו להוסיף עוד 240 דומיינים של Cloud Identity, חשבונות Google Workspace או קבוצות ייחודיות עד שתגיעו למגבלה.

מטא-נתונים של מדיניות

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

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

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

שימוש ב-ETag במדיניות

אם מספר מערכות מנסות לכתוב יחד לאותה מדיניות הרשאה, ייתכן שהמערכות האלו יחליפו את השינויים אחת של השנייה. הסיכון הזה קיים כי מדיניות ההרשאות מתעדכנת באמצעות התבנית read-modify-write, שכוללת כמה פעולות:

  1. קריאת מדיניות ההרשאה הקיימת
  2. שינוי מדיניות ההרשאה
  3. כתיבת כל מדיניות ההרשאה

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

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

השדה etag מכיל ערך כמו BwUjMhCsNvY=. כשמעדכנים את מדיניות ההרשאה, חשוב לכלול את השדה etag במדיניות ההרשאה המעודכנת. אם מדיניות ההרשאה שונתה מאז האחזור שלה, הערך של etag לא יתאים והעדכון ייכשל. ב-API ל-REST, מקבלים את קוד הסטטוס 409 Conflict של HTTP, וגוף התשובה דומה לקוד הבא:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

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

דוגמה: מדיניות פשוטה

נבחן את מדיניות ההרשאה הבאה המקשרת חשבון משתמש לתפקיד:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

בדוגמה הקודמת, ל-Jie מוענק התפקיד הבסיסי 'בעלים' ללא תנאים כלשהם. התפקיד הזה נותן ל-Jie גישה כמעט בלתי מוגבלת.

דוגמה: מדיניות עם קישורי תפקידים מרובים

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

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

בדוגמה הקודמת, בקישור התפקיד הראשון, מעניקים ל-Jie את התפקיד המוגדר מראש אדמין בארגון (roles/resourcemanager.organizationAdmin). תפקיד זה מכיל הרשאות לארגונים, לתיקיות ולפעולות מוגבלות בתיקיות. בקישור התפקיד השני, מעניקים גם ל-Jie וגם ל-Raha את היכולת ליצור פרויקטים באמצעות התפקיד 'יצירת פרויקטים' (roles/resourcemanager.projectCreator). ביחד, קישורי התפקידים האלו מעניקים גישה פרטנית גם ל-Jie וגם ל-Raha, ומעניקים ל-Jie גישה רחבה יותר מאשר ל-Raha.

דוגמה: מדיניות עם קישור תפקיד מותנה

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

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

בדוגמה הזו השדה version מוגדר להיות 3, כי מדיניות ההרשאה כוללת ביטוי תנאי. קישור התפקידים במדיניות ההרשאה מותנה; הוא מעניק את התפקיד לקבוצה prod-dev ולחשבון השירות prod-dev-example@appspot.gserviceaccount.com, אבל רק עד ה-1 ביולי 2022.

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

דוגמה: מדיניות עם קישורי תפקידים מותנים ולא מותנים

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

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

בדוגמה הזו, חשבון השירות serviceAccount:prod-dev-example@appspot.gserviceaccount.com כלול בשני קישורי תפקידים בשביל אותו תפקיד. בקישור התפקיד הראשון אין תנאי. בקישור התפקיד השני יש תנאי שמעניק את התפקיד רק עד ה-1 ביולי 2022.

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

לעומת זאת, הקבוצה prod-dev כלולה רק בקישור התפקיד המותנה. לכן, יש לה את התפקיד רק לפני ה-1 ביולי 2022.

דוגמה: מדיניות שמקשרת תפקיד לחשבון משתמש שנמחק

נבחן את מדיניות ההרשאה הבאה. מדיניות ההרשאה הזו מקשרת תפקיד לחשבון שירות, serviceAccount:my-service-account@my-project.iam.gserviceaccount.com, שנמחק. לכן מזהה חשבון השירות כולל עכשיו את התחילית deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

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

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

לכל החשבונות הראשיים שנמחקו יש את הקידומת deleted:. לסוגים מסוימים של חשבונות משתמש שנמחקו, כמו חשבונות שירות, יש גם את הסיומת ?uid=numeric-id, כאשר numeric-id הוא המזהה המספרי הייחודי של חשבון המשתמש שנמחק. בדוגמה הזו, במקום serviceAccount:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com, מדיניות ההרשאה מציגה את המזהה deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901.

מדיניות ברירת המחדל

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

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

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

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

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

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

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

  • מדיניות ההרשאה שהוגדרה במשאב
  • כללי מדיניות ההרשאה שהוגדרו בכל רמות משאבי האב של המשאב בהיררכיה

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

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

דוגמה: ירושה של מדיניות

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

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

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

מדיניות ההרשאה הזו מעניקה ל-Raha את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer) שמכיל את ההרשאות get ו-list לפרויקטים ולאובייקטים של Cloud Storage. בגלל שמדיניות ההרשאה הוגדרה ברמת הארגון, Raha יכולה להשתמש בהרשאות האלו בכל הפרויקטים ובכל האובייקטים של Cloud Storage בארגון.

כדי לתת ל-Raha תפקיד ברמת הפרויקט, מגדירים את מדיניות ההרשאה הבאה בפרויקט myproject-123:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

מדיניות ההרשאה הזו מעניקה ל-Raha את התפקיד 'יצירת אובייקטים באחסון' (roles/storage.objectCreator), שמאפשר לה ליצור אובייקטים של Cloud Storage. בגלל שמדיניות ההרשאה הוגדרה ב-myproject-123, Raha יכולה ליצור אובייקטים של Cloud Storage רק ב-myproject-123.

עכשיו יש שני קישורי תפקידים המעניקים ל-Raha גישה לאובייקטי מטרה של Cloud Storage ב-myproject-123, בכפוף לכללי מדיניות ההרשאה הבאים:

  • מדיניות הרשאה ברמת הארגון מעניקה את היכולת להציג ולקבל את כל האובייקטים של Cloud Storage בארגון הזה.
  • מדיניות הרשאה ברמת הפרויקט, בפרויקט myproject-123, מעניקה את היכולת ליצור אובייקטים בפרויקט הזה.

הטבלה הבאה מסכמת את המדיניות האפקטיבית של Raha:

הרשאות מהתפקיד 'צפייה באובייקט אחסון' בארגון הרשאות מהתפקיד 'יצירת אובייקטים באחסון' בפרויקט myproject-123 ההרשאות שבתוקף של Raha בפרויקט myproject-123
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
 resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.create
 resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
storage.objects.create

גרסאות של מדיניות

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

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

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

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

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

גרסאות תקפות של מדיניות

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

גרסה תיאור
1 הגרסה הראשונה של סכימת התחביר של IAM בשביל כללי מדיניות. מאפשרת לקשר תפקיד אחד לחשבון משתמש אחד או יותר. לא תומכת בקישורי תפקידים מותנים.
2 שמורה לשימוש פנימי בלבד.
3 כוללת בקישורי התפקידים את השדה condition, שמגביל אותם באמצעות כללים מבוססי-הקשר ומבוססי מאפיינים. למידע נוסף, עיינו במאמר סקירה כללית של תנאי IAM.

ציון גרסת המדיניות בזמן קבלת המדיניות

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

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

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

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

  • אם מדיניות ההרשאה כוללת תנאים, ונשלחה בקשה לגרסה 1 של מדיניות ההרשאה או שלא צוינה גרסה, אז IAM יחזיר את גרסה 1 של מדיניות ההרשאה.

    לקישורי תפקידים שכוללים תנאי, IAM מצרף את המחרוזת _withcond_ לשם התפקיד, ולאחר מכן ערך גיבוב. למשל, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. התנאי עצמו לא קיים. לדוגמה, ראו תרחיש 2 בדף הזה.

תרחיש 1: גרסת מדיניות שתומכת באופן מלא בתנאי IAM

נניח שקוראים ל-method של API ל-REST כדי לקבל את מדיניות ההרשאה של פרויקט:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

גוף הבקשה מכיל את הטקסט הבא:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

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

{
  "bindings": [
    {
      "members": [
        "user:tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

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

{
  "bindings": [
    {
      "members": [
        "user:tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

תרחיש 2: גרסת מדיניות עם תמיכה מוגבלת בתנאי IAM

נניח שקוראים ל-method של API ל-REST כדי לקבל את מדיניות ההרשאה של פרויקט:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

גוף הבקשה ריק; הוא לא מציין מספר גרסה. כתוצאה מכך, IAM ישתמש בגרסת מדיניות ההרשאה המוגדרת כברירת מחדל, 1.

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

{
  "bindings": [
    {
      "members": [
        "user:tal@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

ציון גרסת המדיניות בזמן הגדרת המדיניות

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

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

תרחיש: גרסאות של מדיניות בבקשות ובתגובות

נניח שמשתמשים ב-API ל-REST כדי לקבל מדיניות הרשאה, ומציינים את גרסה 3 בבקשה. התשובה כוללת את מדיניות ההרשאה הבאה, שמשתמשת בגרסה 3:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

החלטתם ש-Raha צריכה את התפקיד 'אדמין באחסון' (roles/storage.admin) במהלך כל השבוע, ולא רק בימי חול. מסירים את התנאי מקישור התפקידים ושולחים בקשת API בארכיטקטורת REST כדי להגדיר את מדיניות ההרשאה ושוב מציינים את גרסה 3 בבקשה:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

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

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

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

כללי מדיניות בנוגע לחשבונות משתמשים שנמחקו

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

לדוגמה, נבחן את מדיניות ההרשאה הזו שכוללת קישור תפקידים לחשבון שירות שנמחק, my-service-account@project-id.iam.gserviceaccount.com. כתוצאה מכך, למזהה של כל חשבון שירות יש תחילית deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

נניח שיוצרים חשבון שירות חדש שגם השם שלו הוא my-service-account@project-id.iam.gserviceaccount.com, ורוצים להעניק לו את התפקיד 'יצירת פרויקטים' (roles/resourcemanager.projectCreator). כדי להעניק את התפקיד לחשבון השירות החדש, מעדכנים את מדיניות ההרשאות כמו בדוגמה הזו:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "serviceAccount:my-service-account@project-id.iam.gserviceaccount.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

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

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

שיטות מומלצות למדיניות

השיטות המומלצות הבאות רלוונטיות לארגונים עם משתמשי Google Cloud רבים:

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

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

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

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

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

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

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