תפקידי IAM לפונקציות של משימות שקשורות ל-Networking

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

במסמך הזה לא נפרט לגבי התפקידים וההרשאות שקשורים לניהול רשתות. למידע מפורט לגבי התפקידים וההרשאות שקשורים לממשקי ה-API של Compute ו-Networking תוכלו לעיין במאמר תפקידי IAM מוגדרים מראש ב-Compute Engine.

צוות אחד מנהל גם את האבטחה וגם את הרשתות בארגון

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

כדי לאפשר את זה, הארגון משתמש ב-VPC משותף (ענן וירטואלי פרטי). ‏VPC משותף מאפשר ליצור רשת VPC שמשתמשת במרחב כתובות IP מסוג RFC 1918. כך פרויקטים משויכים (פרויקטי שירות) יכולים גם להשתמש ברשת הזו. מפתחים שמשתמשים בפרויקטים המשויכים יכולים ליצור מכונות וירטואליות במרחבים של רשת ה-VPC המשותפת. מנהלי הרשת ומנהלי האבטחה של הארגון יכולים ליצור רשתות משנה, רשתות VPN וכללי חומת אש שזמינים לכל הפרויקטים ברשת ה-VPC.

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

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

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

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

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role":"roles/compute.networkAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    }
  ]
}

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

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

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

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

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

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

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

צוותים נפרדים מנהלים את האבטחה ואת הרשתות בארגון

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

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

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

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

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

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

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "group:networks@example.com"
      ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "group:networks@example.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:security@example.com"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "group:security@example.com"
      ]
    }
  ]
}

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

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

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

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

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

כל צוות מנהל את הרשת שלו

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

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

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

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

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

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

אדמין לענייני אבטחה
חשבון משתמש: צוות אבטחה ורשתות
משאב: תיקייה התפקידים האלה מאפשרים למפתחים לנהל את כל מה שקשור ל-BigQuery ול-Compute Engine.
תפקידים: אדמין של מכונות
אדמין של BigQuery
חשבון משתמש: מפתחים

לשם כך צריך לשייך מדיניות הרשאות לכל תיקייה שמוקצית לצוות.

{
  "bindings": [
    {
      "role": "roles/resourcemanager.foldersAdmin",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    },
    {
      "role":"roles/resourcemanager.projectCreator",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
      ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:dev01@example.com"
      ]
    },
    {
      "role": "roles/bigquery.admin",
      "members": [
        "group:dev01@example.com"
      ]
    }
  ]
}