ניהול זהויות והרשאות גישה

שימוש

במאמר הזה מופיעה סקירה כללית של ניהול זהויות והרשאות גישה (IAM) והשימוש בו במסגרת בקרת גישה למשאבים, כמו קטגוריות, תיקיות מנוהלות ואובייקטים ב-Cloud Storage.

סקירה כללית

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

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

לדוגמה, ההרשאה storage.objects.create מאפשרת ליצור אובייקטים. ההרשאה הזו כלולה בתפקידים כמו Storage Object Creator‏ (roles/storage.objectCreator), שמעניק את ההרשאות שבאמצעותן אפשר ליצור אובייקטים בקטגוריה, ו-Storage Object Admin‏ (roles/storage.objectAdmin), שמעניק מגוון רחב של הרשאות לעבודה עם אובייקטים.

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

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

הרשאות

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

רשימה של הרשאות IAM שרלוונטיות ל-Cloud Storage מופיעה במאמר הרשאות IAM ל-Cloud Storage.

תפקידים

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

במאמר תפקידי IAM ל-Cloud Storage מופיעה רשימה של תפקידי ה-IAM שרלוונטיים ל-Cloud Storage.

הקצאת תפקידים ברמת הפרויקט, ברמת הקטגוריה או ברמת התיקייה המנוהלת

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

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

אפשר להשתמש בחלק מהתפקידים בכל הרמות בהיררכיית המשאבים. ברמת הפרויקט, ההרשאות שהתפקיד כולל רלוונטיות לכל הקטגוריות, התיקיות והאובייקטים בפרויקט. ברמת הקטגוריה, ההרשאות רלוונטיות רק לקטגוריה ספציפית ולתיקיות ולאובייקטים שבתוכה. דוגמאות לתפקידים כאלה: התפקיד Storage Admin‏ (roles/storage.admin), התפקיד Storage Object Viewer‏ (roles/storage.objectViewer) והתפקיד Storage Object Creator‏ (roles/storage.objectCreator).

יש תפקידים שרלוונטיים רק לרמה אחת. לדוגמה, התפקיד Storage Legacy Object Owner (roles/storage.legacyObjectOwner) רלוונטי רק לרמת הקטגוריה או לרמת התיקייה המנוהלת. תפקידי IAM שמאפשרים לשלוט בכללי מדיניות הדחייה ב-IAM רלוונטיים רק לרמת הארגון.

קשר לרשימות ACL

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

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

תפקיד Legacy Bucket התפקיד המקביל ב-ACL
קריאה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketReader) בעל הרשאת קריאה לקטגוריה
בעל הרשאת כתיבה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketWriter) בעל הרשאת כתיבה של קטגוריות
בעלים של קטגוריה באחסון מדור קודם (roles/storage.legacyBucketOwner) Bucket Owner

כל שאר תפקידי ה-IAM ברמת הקטגוריה, כולל תפקידי Legacy Bucket של IAM, פועלים בנפרד מרשימות ה-ACL. באופן דומה, כל תפקידי ה-IAM ברמת הפרויקט פועלים בנפרד מרשימות ה-ACL. לדוגמה, אם נותנים למשתמש את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer), רשימות ה-ACL לא ישתנו.

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

כללי מדיניות דחייה של IAM לעומת רשימות ACL

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

הרשאת IAM לשינוי רשימות ACL

אפשר להשתמש ב-IAM כדי לתת לחשבונות המשתמשים את ההרשאה הנדרשת לשינוי רשימות ACL של אובייקטים. ההרשאות הבאות של storage.buckets, ביחד, מאפשרות למשתמשים לעבוד עם רשימות ACL של קטגוריות, ועם רשימות ה-ACL שמוגדרות כברירת מחדל של אובייקטים: .get‏, .getIamPolicy‏, .setIamPolicy ו-.update.

באופן דומה, ההרשאות הבאות של storage.objects, ביחד, מאפשרות למשתמשים לעבוד עם רשימות ACL של אובייקטים: .get, .getIamPolicy, .setIamPolicy ו-.update.

תפקידים בהתאמה אישית

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

סוגים של חשבונות משתמשים

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

ערכי נוחות

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

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

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

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

לדוגמה, נניח של-jane@example.com ול-john@example.com יש את התפקיד הבסיסי Viewer (roles/viewer) בפרויקט בשם my-example-project, ונניח שיש בפרויקט הזה קטגוריה בשם my-bucket. אם תקצו את התפקיד Storage Object Creator ‏ (roles/storage.objectCreator) של my-bucket לערך הנוחות projectViewer:my-example-project, גם jane@example.com וגם john@example.com יקבלו את ההרשאות ל-my-bucket שמשויכות לתפקיד Storage Object Creator.

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

תנאים

תנאי IAM מאפשרים להגדיר תנאים כדי לקבוע איך להעניק או לדחות הרשאות לחשבונות משתמשים. Cloud Storage תומך בסוגים הבאים של מאפייני תנאי:

  • ‫resource.name: נותן או דוחה גישה לקטגוריות או לאובייקטים על בסיס שם הקטגוריה או האובייקט. אפשר גם להשתמש ב-resource.type כדי להעניק גישה לקטגוריות או לאובייקטים, אבל אם משתמשים ב-resource.name, בדרך כלל אין בכך צורך. בדוגמה של התנאי הבא כל האובייקטים עם אותה הקידומת מקבלים את ההגדרה של IAM: 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • תאריך/שעה: מגדירים תאריך תפוגה להרשאה. 

    request.time < timestamp('2019-01-01T00:00:00Z')

הביטויים המותנים האלה הם הצהרות לוגיות שמשתמשות בקבוצת משנה של Common Expression Language‏ (CEL). אתם מציינים את התנאים במסגרת קישור התפקידים במדיניות ה-IAM של הקטגוריה.

חשוב לזכור את ההגבלות הבאות:

  • לפני שמוסיפים תנאים ברמת הקטגוריה, צריך להפעיל גישה אחידה ברמת הקטגוריה. למרות שאפשר להוסיף תנאים ברמת הפרויקט, כדאי להעביר את כל הקטגוריות בפרויקט לגישה אחידה ברמת הקטגוריה כדי למנוע מצב שבו רשימות ה-ACL של Cloud Storage יבטלו תנאי IAM ברמת הפרויקט. אפשר לכפות אילוץ של גישה אחידה ברמת הקטגוריה כדי לאפשר גישה אחידה ברמת הקטגוריה לכל הקטגוריות החדשות בפרויקט.
  • כששולחים קריאה באמצעות API בפורמט JSON ל-getIamPolicy ול-setIamPolicy בקטגוריות עם תנאים, הגרסה של מדיניות ה-IAM צריכה להיות 3.
  • ההרשאה storage.objects.list ניתנת ברמת הקטגוריה, ולכן אי אפשר להגביל את הגישה להצגת רשימה של אובייקטים לקבוצת משנה של אובייקטים בקטגוריה באמצעות מאפיין של התנאי resource.name.
  • תנאים שפג תוקפם נשארים במדיניות ה-IAM עד שמסירים אותם.

שימוש בכלים של Cloud Storage

למרות שאי אפשר להגדיר הרשאות IAM דרך API בפורמט XML, למשתמשים שקיבלו הרשאות IAM עדיין יש גישה ל-Cloud Storage באמצעות API בפורמט XML וכל כלי אחר.

מידע על אילו הרשאות IAM מאפשרות למשתמשים לבצע פעולות באמצעות כלים שונים ב-Cloud Storage מופיע במסמכי העזרה של IAM ל-Cloud Storage.

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