סקירה כללית על IAM

כאן מוסבר איך פועלת מערכת ניהול הזהויות והרשאות הגישה (IAM) ב-Google Cloud, ואיך אפשר להשתמש בה כדי לנהל הרשאות גישה ב-Google Cloud.

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

איך פועל IAM

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

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

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

התרשים הבא מתאר את ניהול ההרשאות ב-IAM.

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

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

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

בתרשים הקודם, למשל, מדיניות ההרשאה מקשרת חשבונות משתמשים, כמו user@example.com, לתפקידים כמו אדמין של App Engine (roles/appengine.appAdmin). אם מדיניות ההרשאה מצורפת לפרויקט, חשבונות המשתמשים מקבלים את התפקידים המצוינים בתוך הפרויקט.

שאר הדף מתאר מושגים אלה בפירוט רב יותר.

ב-IAM, אתם מעניקים גישה לחשבונות משתמשים. חשבונות משתמשים יכולים להיות מהסוגים הבאים:

  • חשבון Google
  • חשבון שירות
  • קבוצת Google
  • חשבון Google Workspace
  • דומיין של Cloud Identity
  • כל המשתמשים המאומתים
  • כל המשתמשים

חשבון Google

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

חשבון שירות

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

קבוצת Google

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

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

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

חשבון Google Workspace

חשבון Google Workspace מייצג קבוצה וירטואלית של כל חשבונות Google שהוא מכיל. חשבונות Google Workspace משויכים לשם הדומיין של הארגון שלכם באינטרנט, כמו example.com. כשיוצרים חשבון Google למשתמש חדש, כמו username@example.com, אותו חשבון Google מתווסף לקבוצה הווירטואלית של חשבון Google Workspace שלכם.

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

דומיין של Cloud Identity

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

כל המשתמשים המאומתים

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

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

חלק מסוגי המשאבים לא תומכים בחשבון משתמש מסוג זה.

כל המשתמשים

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

חלק מסוגי המשאבים לא תומכים בחשבון משתמש מסוג זה.

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

בקטע הזה מתוארות הישויות והמושגים הקשורים בתהליך ההרשאה.

משאב

אם משתמש צריך גישה למשאב מסוים ב-Google Cloud, תוכלו לתת לו תפקיד במשאב הזה. דוגמאות למשאבים: פרויקטים, מכונות ב-Compute Engine וקטגוריות של Cloud Storage.

בשירותים מסוימים אפשר להעניק הרשאות IAM ברמת פירוט גבוהה יותר מרמת הפרויקט. לדוגמה, תוכלו להקצות למשתמש את התפקיד 'אדמין אחסון' (roles/storage.admin) בקטגוריית Cloud Storage מסוימת, או להקצות את תפקיד האדמין של מכונת Compute (roles/compute.instanceAdmin) למשתמש במכונה ספציפית של Compute Engine.

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

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

הרשאות

ההרשאות קובעות אילו פעולות מותרות במשאב. בעולם ה-IAM, הרשאות מיוצגות בפורמט service.resource.verb, לדוגמה, pubsub.subscriptions.consume.

לרוב ההרשאות תואמות ביחס של אחת-לאחת לשיטות API ל-REST. כלומר, לכל שירות ב-Google Cloud משויכת קבוצת הרשאות עבור כל שיטת API ל-REST שהוא חושף. מבצע הקריאה בשיטה הזו צריך את ההרשאות האלה כדי לקרוא לשיטה הזו. לדוגמה, אם אתם משתמשים ב-Pub/Sub וצריך להפעיל את השיטה topics.publish(), נדרשת ההרשאה pubsub.topics.publish לנושא הזה.

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

תפקידים

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

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

יש כמה סוגי תפקידים ב-IAM:

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

  • תפקידים מוגדרים מראש: תפקידים שמעניקים בקרת גישה פרטנית יותר מאשר התפקידים הבסיסיים. לדוגמה, התפקיד המוגדר מראש 'פרסום ב-Pub/Sub' (roles/pubsub.publisher) מאפשר גישה רק לפרסום הודעות בנושא Pub/Sub.

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

מידע נוסף על תפקידים זמין במקורות המידע הבאים:

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

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

מדיניות IAM.

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

  • role: התפקיד שאתם רוצים לתת לחשבון המשתמש. הערך role מצוין בצורת roles/service.roleName. לדוגמה, Cloud Storage מספק את התפקידים roles/storage.objectAdmin, roles/storage.objectCreator ו-roles/storage.objectViewer, בין היתר.

  • members: רשימה של חשבונות משתמשים כפי שמתואר בקטע מושגים הקשורים לזהות במסמך הזה. כל חשבון משתמש מזוהה על ידי קידומת, כמו חשבון Google (user: ), חשבון שירות (serviceAccount: ), קבוצת Google (group: ) או חשבון Google Workspace או דומיין ב-Cloud Identity (domain: ). בקטע הקוד בדוגמה הבאה, התפקיד storage.objectAdmin מוקצה לחשבונות המשתמשים הבאים באמצעות הקידומת המתאימה: user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com, ו-domain:google.com. התפקיד objectViewer מוקצה ל-user:maria@example.com.

קטע הקוד הבא מציג את המבנה של מדיניות ההרשאה.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:ali@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:admins@example.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

ממשקי API של AIM ומדיניות

IAM מספק קבוצה של שיטות שבאמצעותן אפשר ליצור ולנהל כללי מדיניות של משאבים ב-Google Cloud. השיטות האלה נחשפות בשירותים שתומכים ב-IAM. לדוגמה, השיטות של IAM נחשפות על ידי משקי ה-API של 'מנהל המשאבים', Pub/Sub, ו-Cloud Life Sciences, ועוד.

שיטות ה-IAM הן:

  • setIamPolicy(): מגדירה כללי מדיניות הרשאה על המשאבים שלך.
  • getIamPolicy(): מקבלת מדיניות הרשאה שהוגדרה בעבר.
  • testIamPermissions(): בודקת אם למבצע הקריאה יש את ההרשאות המצוינות עבור למשאב.

נושאי העזר של השיטות האלה זמינים במסמכי התיעוד של כל שירות שתומך ב-IAM.

היררכיית משאבים

המשאבים של Google Cloud מסודרים בהיררכיה.

  • הארגון הוא צומת השורש (root) בהיררכיה.
  • תיקיות הן צאצאים של הארגון או של תיקייה אחרת.
  • פרויקטים הם צאצאים של הארגון או של תיקייה.
  • משאבים לכל שירות הם צאצאים של פרויקטים.

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

התרשים הבא הוא דוגמה להיררכיית משאבים ב-Google Cloud.

היררכיה של משאבי IAM.

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

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

לדוגמה: בתרשים הקודם, topic_a הוא משאב Pub/Sub שנמצא בפרויקט example-prod. אם אתם מעניקים את התפקיד 'עריכה' ל-micah@example.com עבור example-prod, ומעניקים את התפקיד 'פרסום' ל-song@example.com עבור topic_a, אתם מעניקים בפועל את התפקיד 'עריכה' עבור topic_a ל-micah@example.com ואת התפקיד 'פרסום' ל-song@example.com.

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

תמיכת IAM לשירותי Google Cloud

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

שירותי Google Cloud מציעים תפקידים מוגדרים מראש שמספקים בקרת גישה פרטנית. לדוגמה, Compute Engine מציע תפקידים כמו 'אדמין מכונות של Compute' ו'אדמין רשת של Compute', בעוד ש-App Engine מציע תפקידים כמו 'אדמין של App Engine' ו-'אדמין שירות של App Engine'.

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

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

מודל עקביות ל-API של IAM

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

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

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

נסו בעצמכם

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

מתחילים לעבוד בלי לשלם