המשאבים ב-Google Cloud מסודרים בהיררכיה, כאשר הצומת של הארגון הוא הצומת של הרמה הבסיסית (root) בהיררכיה, הפרויקטים הם הצאצאים של הארגון והמשאבים האחרים הם הצאצאים של הפרויקטים. אפשר להגדיר מדיניות הרשאות ברמות שונות של היררכיית המשאבים. המשאבים יורשים את מדיניות ההרשאות של משאב ההורה. מדיניות ההרשאות בפועל של משאב היא האיחוד של מדיניות ההרשאות שהוגדרה למשאב הזה, יחד עם כללי מדיניות ההרשאות שעוברים בירושה ממשאב ההורה.
בדף הזה נפרט כמה דוגמאות לאופן שבו פועלת ירושה של מדיניות הרשאות ונסביר מהן השיטות המומלצות שכדאי לקחת בחשבון כשאתם יוצרים משאבים בזמן הפריסה של ניהול זהויות והרשאות גישה (IAM).
דרישות מוקדמות
- כדאי לקרוא ולהבין את המושגים הבסיסיים של IAM, במיוחד את היררכיית המשאבים שלGoogle Cloud .
רקע
בתרשים הבא מוצגת דוגמה להיררכיית משאבים ב- Google Cloud .
אפשר להגדיר כללי מדיניות ב-IAM ברמות הבאות של היררכיית המשאבים:
ברמת הארגון. המשאב של הארגון מייצג את החברה שלכם. כשמעניקים תפקידי IAM ברמה הזו, הם עוברים בירושה לכל המשאבים שנמצאים בארגון הזה. מידע נוסף זמין במאמר בקרת גישה לארגונים שמשתמשים ב-IAM.
ברמת התיקייה. תיקיות יכולות להכיל פרויקטים, תיקיות אחרות, או גם וגם. כשמעניקים תפקידים ברמה העליונה של התיקייה, הם עוברים בירושה לפרויקטים או לתיקיות אחרות באותה תיקיית הורה. מידע נוסף זמין במאמר בקרת גישה לתיקיות שמשתמשות ב-IAM.
ברמת הפרויקט. פרויקטים מייצגים את גבולות האמון בחברה שלכם. לשירותים שמשויכים לאותו פרויקט יש רמת אמון ברירת מחדל. כשמעניקים תפקידי IAM ברמת הפרויקט, הם עוברים בירושה למשאבים בפרויקט הזה. מידע נוסף זמין במאמר בקרת גישה לפרויקטים שמשתמשים ב-IAM.
ברמת המשאב. בנוסף למערכות הקיימות ב-Cloud Storage וב-ACL של BigQuery, משאבים נוספים כמו נושאי Pub/Sub ו-Compute Engine תומכים בהענקת תפקידים ברמה נמוכה יותר, כדי להעניק למשתמשים מסוימים הרשאת גישה למשאב מסוים בתוך פרויקט.
מדיניות ההרשאות מבוססת על היררכיה ומופצת במורד ההיררכיה בהתאם למבנה. מדיניות ההרשאות בפועל למשאב היא האיחוד של מדיניות ההרשאות שהוגדרה למשאב הזה, יחד עם כללי מדיניות ההרשאות שעוברים בירושה ממשאב ההורה.
בדוגמאות הבאות מוסבר איך תהליך הירושה של מדיניות ההרשאות עובד בפועל.
דוגמה: Pub/Sub
ב-Pub/Sub, נושאים ומינויים הם משאבים שנמצאים בפרויקט. נניח של-project_1 יש נושא בשם topic_a מתחתיו. אם תגדירו מדיניות הרשאות ב-project_1 שמעניקה את התפקיד 'עריכה' לקלני, ותגדירו מדיניות הרשאות ב-topic_a שמעניקה את התפקיד 'פרסום' לנור, בפועל המשמעות היא שהקציתם את התפקיד 'עריכה' לקלני ואת התפקיד 'פרסום' לנור במסגרת topic_a.
התרשים הבא מדגים את הדוגמה שלמעלה.
אם תפקיד שעובר בירושה כבר נותן לישות מורשית את כל ההרשאות שהיא צריכה, לא צריך להקצות לה תפקידים נוספים במשאב עצמו. אין צורך להקצות תפקיד אחר שמכיל את אותן הרשאות או פחות הרשאות, ואין לכך השפעה.
לדוגמה, התפקידים הבסיסיים 'בעלים', 'עריכה' ו'צפייה'. התפקידים האלה הם קונצנטריים. כלומר, התפקיד 'בעלים' כולל את ההרשאות של התפקיד 'עריכה', והתפקיד 'עריכה' כולל את ההרשאות של התפקיד 'צפייה'. לכן, אם תקצו לקלני את תפקיד העורך ברמת הפרויקט, הקצאת תפקיד הצופה ב-topic_a תהיה מיותרת. הסיבה לכך היא שלמשתמשת Kalani כבר יש את כל ההרשאות בתפקיד 'צפייה' דרך התפקיד 'עריכה', שעובר בירושה ממדיניות ההרשאות של הפרויקט.
התרשים הבא מדגים את הדוגמה שלמעלה.
דוגמה: Cloud Storage
ב-Cloud Storage, קטגוריות ואובייקטים הם משאבים, כאשר אובייקטים ממוקמים בקטגוריות. שימוש לדוגמה ב-IAM עם Cloud Storage יכול להיות מתן הרשאת גישה לקריאת קבצים שאתם מעלים.
תרחיש לדוגמה יכול להיות מצב שבו הרבה משתמשים מעלים קבצים לקטגוריה, אבל אסור להם לקרוא או למחוק קבצים שמשתמשים אחרים העלו. בנוסף, מומחה עיבוד הנתונים שלכם אמור להיות מסוגל לקרוא ולמחוק קבצים שהועלו, אבל אסור לו למחוק קטגוריות, כי אחרים משתמשים במיקום של הקטגוריה הזאת כדי להעלות את הקבצים שלהם. בתרחיש כזה, תוכלו להגדיר כללי מדיניות הרשאות בפרויקט באופן הבא:
- מעניקים את התפקיד אדמין של אובייקט אחסון (
roles/storage.objectAdmin) למומחה עיבוד הנתונים Nur. התפקיד הזה מאפשר לנור לקרוא, להוסיף ולמחוק כל אובייקט בכל קטגוריה בפרויקט. - מעניקים לקבוצה
data-uploadersאת התפקיד 'יצירת אובייקטים באחסון' (roles/storage.objectCreator). התפקיד הזה מאפשר לחברי הקבוצה להעלות קבצים לקטגוריה, אבל לא מאפשר להם לקרוא או למחוק קבצים שמשתמשים אחרים העלו.
התרשים הבא מדגים את הדוגמה שלמעלה.
דוגמה: Compute Engine
בדרך כלל, בחברות גדולות יותר יש צוות ייעודי (שאינו צוות הפיתוח) שמנהל את משאבי הרשת והאבטחה, כמו חומות אש. יחד עם זאת, יכול להיות שצוותי הפיתוח ירצו גמישות בכל מה שקשור למכונות בפרויקטים שלהם כדי שיוכלו להפעיל מכונות ולבצע פעולות נוספות.
במצב כזה, אפשר להגדיר את כללי מדיניות ההרשאות באופן הבא:
- מקצים לאדמין הרשת והאבטחה, קלני, את התפקיד אדמין רשת של Compute (
roles/compute.networkAdmin) ברמת הארגון. התפקיד הזה מאפשר לקלני לבצע שינויים במשאבי הרשת בארגון ובפרויקטים בארגון. - מקצים את התפקיד אדמין מכונות של Compute (
roles/compute.instanceAdmin) לראש צוות הפיתוח, Nur, בפרויקטproject_2. התפקיד הזה מאפשר לנור לבצע פעולות במכונות שלה, וגם מונע ממנה לבצע שינויים במשאבי הרשת שמשויכים לפרויקט שלה. עם זאת, הם לא יכולים לבצע שינויים במשאבי רשת בפרויקטים אחרים.
הרשאות לצפייה במדיניות שהועברה בירושה
כדי לראות מדיניות IAM שעוברת בירושה ממשאב הורה, צריך הרשאה לצפייה במדיניות ה-IAM של משאב ההורה. לדוגמה, כדי לראות את כל מדיניות ה-IAM שעוברת בירושה בפרויקט, צריך הרשאה לראות את מדיניות ה-IAM של הארגון שמעל הפרויקט בהיררכיית המשאבים, וגם לראות את מדיניות ה-IAM של כל התיקיות שמעל הפרויקט בהיררכיית המשאבים.
כדי לקבל את ההרשאות שדרושות בשביל להציג את כללי ה-IAM שמועברים בירושה ממשאבי אב, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:
-
כדי לראות מדיניות IAM שעוברת בירושה מארגון:
אדמין ארגוני (
roles/resourcemanager.organizationAdmin) באותו ארגון -
כדי להציג מדיניות IAM שעוברת בירושה מתיקייה:
אדמין תיקיות (
roles/resourcemanager.folderAdmin) בתיקייה -
כדי להציג מדיניות IAM שעוברת בירושה מפרויקט:
אדמין IAM של פרויקט (
roles/resourcemanager.projectIamAdmin) בפרויקט
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות לצפייה במדיניות IAM שמועברת בירושה ממשאבי הורה. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:
ההרשאות הנדרשות
כדי לצפות במדיניות IAM שמועברת בירושה ממשאבי אב, נדרשות ההרשאות הבאות:
-
צפייה במדיניות IAM שעוברת בירושה מארגון:
resourcemanager.organizations.getIamPolicyבארגון -
כדי לראות מדיניות IAM שעוברת בירושה מתיקייה:
resourcemanager.folders.getIamPolicyבתיקייה -
כדי לראות מדיניות IAM שעוברת בירושה מפרויקט:
resourcemanager.projects.getIamPolicyבפרויקט
יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.
שיטות מומלצות
שיקוף המבנה של היררכיית המשאבים במבנה של הארגון. Google Cloud היררכיית המשאבים צריכה לשקף את האופן שבו החברה שלכם מאורגנת, לא משנה אם מדובר בחברת סטארט-אפ, בעסק קטן או בינוני או בתאגיד גדול. Google Cloud חברת סטארט-אפ עשויה להכיל בהתחלה רק היררכיית משאבים רגילה ללא משאבים ארגוניים. כשעוד אנשים מתחילים לשתף פעולה לגבי פרויקטים ומספר הפרויקטים גדל, יכול להיות שיתעורר הצורך ליצור משאב ארגוני. מומלץ להשתמש במשאב ארגוני כשמדובר בחברה גדולה יותר עם כמה מחלקות וצוותים, כשכל צוות אחראי על קבוצה נפרדת של אפליקציות ושירותים.
כדאי להשתמש בפרויקטים כדי לקבץ משאבים עם אותם גבולות אמון. למשל, אתם יכולים לשייך לפרויקט מסוים משאבים שקשורים לאותו מוצר או מיקרו-שירות (microservice).
כשזה אפשרי, כדאי להקצות את התפקידים לקבוצה במקום למשתמשים ספציפיים. יותר קל לנהל חברים של קבוצה מאשר לעדכן את מדיניות ההרשאות. חשוב לשים לב שיש לכם אפשרות לנהל את הבעלות על הקבוצה שמשויכת למדיניות ההרשאות.
מידע נוסף על ניהול קבוצות Google מופיע במסמכי העזרה של קבוצות Google.
כדאי להשתמש בעקרון האבטחה של הרשאות מינימליות כשאתם מעניקים תפקידי IAM. כלומר, לתת רק את רמת הגישה המינימלית הדרושה למשאבים שלכם.
תוכלו להיעזר בחומר העזר של תפקידים מוגדרים מראש כדי לאתר איזה תפקיד שהוגדר מראש הכי מתאים לכם. אם אין תפקידים שהוגדרו מראש שמתאימים לכם, תוכלו גם ליצור תפקידים בהתאמה אישית.
כדאי להקצות את התפקידים בהיקף הקטן ביותר הנדרש. לדוגמה, אם משתמש מסוים צריך גישה רק כדי לפרסם הודעות בנושא Pub/Sub, מקצים לו את התפקיד מפרסם בנושא הזה.
חשוב לזכור שכללי מדיניות ההרשאות של משאבים צאצאים יורשים את כללי מדיניות ההרשאות מהמשאבים ההורים. לדוגמה, אם מדיניות ההרשאות של הפרויקט מאפשרת למשתמש לנהל מכונות וירטואליות (VM) של Compute Engine, המשתמש יכול לנהל כל מכונה וירטואלית של Compute Engine באותו פרויקט, בלי קשר למדיניות ההרשאות שתגדירו לכל מכונה וירטואלית.
חשוב לוודא שבכל פרויקט יש לפחות שתי ישויות מורשות עם התפקיד 'בעלים' (
roles/owner). לחלופין, אפשר להקצות את התפקיד 'בעלים' לקבוצה שמכילה לפחות שתי ישויות מורשות.כך תוכלו להבטיח שגם אם אחד מחשבונות המשתמשים יעזוב את החברה, עדיין תוכלו לנהל את הפרויקט.
אם רוצים להקצות תפקיד למשתמש או לקבוצה בכמה פרויקטים במקביל, מקצים את התפקיד ברמת התיקייה במקום ברמת הפרויקט.
כדאי להשתמש בתוויות כדי להוסיף הערות למשאבים, לקבץ אותם ולסנן אותם.
חשוב לבצע ביקורת על כללי מדיניות ההרשאות כדי לוודא שהם עומדים בדרישות. כדי לזהות מתי נוצרה מדיניות הרשאות ומתי היא עודכנה, בודקים את כל הקריאות לפונקציה
setIamPolicy()שמופיעים ביומני הביקורת.חשוב לבצע ביקורת על זהות הבעלים של מדיניות ההרשאות ולבדוק מי החברים בקבוצות שמשויכות למדיניות הזו.
אם אתם רוצים להגביל את האנשים שיכולים ליצור פרויקטים בארגון שלכם, עליכם לשנות את ההגדרה של מדיניות ההרשאות של הארגון ולהעניק את התפקיד יצירת פרויקטים לקבוצה שאתם מנהלים.