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

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

בדף הזה מוצגים כללי מדיניות הרשאה בפורמט 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 את היכולת ליצור פרויקטים באמצעות התפקיד 'Project Creator' (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"