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

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

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

גישה ב- Cloud de Confiance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

משאבים

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

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

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

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

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

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

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

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

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

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

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

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

היררכיית המשאבים של Cloud de Confiance בנויה באופן הבא:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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