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

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

‫IAM הוא כלי לניהול הרשאות פרטניות ל-Google Cloud. במילים אחרות, המערכת מאפשרת לכם לקבוע למי תהיה אפשרות לבצע אילו פעולות על אילו משאבים.

גישה אל Google Cloud

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

הענקת הרשאות למישהו ב-IAM כוללת את שלושת הרכיבים הבאים:

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

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

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

בקטעים הבאים נרחיב על כך בפירוט.

חשבונות משתמשים

ב- Google Cloud אתם שולטים בגישה של חשבונות משתמשים. המונח 'גורמים' מייצג זהות אחת או יותר שאומתו ב- Google Cloud.

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

ב-IAM יש סוגים שונים של חשבונות משתמשים, אבל אפשר לחלק אותם לשתי קטגוריות רחבות:

  • משתמשים אנושיים: חלק מסוגי החשבונות ב-IAM מייצגים משתמשים אנושיים. משתמשים בסוגי העקרונות האלה כדי לנהל את הגישה של העובדים למשאבים ב-Google Cloud .

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

  • עומסי עבודה: חלק מהסוגים של חשבונות משתמשים ב-IAM מייצגים עומסי עבודה. משתמשים בסוגי החשבונות האלה כשמנהלים את הגישה של עומסי העבודה למשאבים של Google Cloud .

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

מידע נוסף על חשבונות משתמשים מופיע במאמר חשבונות משתמשים ב-IAM.

הרשאות ותפקידים

ההרשאות קובעות אילו פעולות מותרות על משאב. ב-IAM, הרשאות מיוצגות בדרך כלל בפורמט service.resource.verb. במקרים רבים ההרשאות זהות לגמרי ל-methods של API בארכיטקטורת REST. לדוגמה, ההרשאה resourcemanager.projects.list מאפשרת לכם לראות רשימה של פרויקטים במנהל המשאבים.

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

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

יש שלושה סוגים של תפקידים:

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

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

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

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

משאבים

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

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

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

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

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

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

מדיניות הרשאה היא אובייקט YAML או JSON שמצורף ל Google Cloudמשאב.

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

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

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

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

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

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

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

היררכיית המשאבים של Google Cloud היא כזו:

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

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

היררכיית משאבים ב-IAM.

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

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

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

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

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

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

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

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

בקרת גישה מתקדמת

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

  • סוגי מדיניות נוספים: בנוסף למדיניות הרשאות, ב-IAM יש את סוגי המדיניות הבאים:

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

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

    מידע נוסף על סוגי המדיניות

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

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

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

  • ‫Privileged Access Manager (PAM): באמצעות Privileged Access Manager, אפשר לאפשר לחשבונות משתמשים לבקש ולקבל גישה זמנית למשאבים, עם אפשרות לביקורת. לדוגמה, אתם יכולים לדרוש שחשבונות משתמש יבקשו גישה בכל פעם שהם רוצים לצפות במשאב רגיש, במקום להקצות להם תפקיד IAM באופן קבוע.

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

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

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

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

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

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

נסו בעצמכם

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

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