סקירה כללית על בקרת גישה מבוססת-תפקידים (RBAC)

בדף הזה מוסבר על הרשאות פרטניות באמצעות בקרת גישה מבוססת-תפקידים (RBAC) ב-Cloud Data Fusion.

הפעלת RBAC במכונות Cloud Data Fusion מאפשרת לכם לשלוט בגישה בתוך מכונות ובמרחבי שמות, למשל מי יכול לגשת למשאבי Cloud Data Fusion ומה הוא יכול לעשות איתם.

תרחישי שימוש ב-RBAC

ב-RBAC יש בידוד ברמת מרחב השמות בתוך מכונה אחת של Cloud Data Fusion. מומלץ להשתמש בהגדרה הזו בתרחישי השימוש הבאים:

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

בעזרת Cloud Data Fusion RBAC, ארגונים יכולים:

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

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

מגבלות

  • אפשר להקצות למשתמש תפקיד אחד או יותר ברמת המופע או במרחב השמות.
  • ה-RBAC זמין רק במהדורת Enterprise של Cloud Data Fusion.
  • מספר מרחבי השמות: אין מגבלה קשיחה על מספר מרחבי השמות לכל מופע.
  • במחירון תוכלו לראות את המספר המקסימלי של משתמשים בו-זמניים במופע עם RBAC.
  • כשמשתמשים באסימוני גישה מסוג OAuth של חשבון שירות כדי לגשת למופעים עם RBAC בגרסה 6.5, צריך לציין את ההיקפים הבאים, במיוחד את ההיקף userinfo.email. בלעדיהם, תקבלו שגיאות של דחיית הרשאה.
    • https://www.googleapis.com/auth/userinfo.email
    • https://www.googleapis.com/auth/cloud-platform או https://www.googleapis.com/auth/servicecontrol

הקצאות תפקידים

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

חשבון משתמש

אתם מעניקים תפקידים לגורמים מרכזיים כדי לשנות את הגישה שלהם למשאבים של Cloud Data Fusion.

הגדרת התפקיד

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

ב-Cloud Data Fusion יש כמה תפקידים מוגדרים מראש שבהם אפשר להשתמש.

לדוגמה:

  • התפקיד 'אדמין מכונות' (datafusion.admin) מאפשר לחשבונות משתמשים ליצור ולמחוק מרחבי שמות ולהעניק הרשאות.
  • התפקיד 'מפתח' (datafusion.developer) מאפשר לחשבונות משתמשים ליצור ולמחוק צינורות עיבוד נתונים, לפרוס צינורות עיבוד נתונים ולהריץ תצוגות מקדימות.

היקף

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

המלצות בנושא אבטחה

אימוץ מודל אבטחה והתאמתו לצרכים ולדרישות של הארגון יכול להיות מאתגר. ההמלצות הבאות נועדו לעזור לכם לפשט את התהליך של אימוץ מודל RBAC של Cloud Data Fusion:

  • צריך להקצות את התפקיד 'אדמין מכונות' בזהירות. התפקיד הזה מאפשר גישה מלאה למופע ולכל המשאבים הבסיסיים שלו ב-Cloud Data Fusion. חשבון משתמש עם התפקיד הזה יכול להעניק הרשאות לאחרים באמצעות ה-API ל-REST.
  • לא מומלץ להעניק תפקיד אדמין של מכונה כשנדרשת לחשבונות משתמשים גישה למרחבי שמות ספציפיים במכונת Cloud Data Fusion. במקום זאת, מקצים את התפקיד Instance Accessor (גישה למופע) עם אחד מהתפקידים Viewer (צפייה), Developer (מפתח), Operator (מפעיל) או Editor (עריכה) שמוקצים לקבוצת משנה של מרחבי השמות.
  • מומלץ להקצות קודם את התפקיד Instance Accessor, כי הוא מאפשר לחשבונות משתמשים לגשת למופע, אבל לא מעניק גישה למשאבים בתוך המופע. בדרך כלל משתמשים בתפקיד הזה יחד עם אחד מהתפקידים Viewer,‏ Developer,‏ Operator או Editor כדי לתת גישה למרחב שמות אחד או לקבוצת משנה של מרחבי שמות בתוך מופע.
  • מומלץ להקצות את תפקיד הצפייה למשתמשים או לקבוצות Google שרוצים להבין את הסטטוס של משימות שפועלות, או לצפות בצינורות או ביומנים באמצעות מופעים של Cloud Data Fusion. לדוגמה, צרכנים של דוחות יומיים שרוצים לדעת אם העיבוד הסתיים.
  • מומלץ להקצות את תפקיד המפתח למפתחי ETL שאחראים על יצירה, בדיקה וניהול של צינורות עיבוד נתונים.
  • מומלץ להשתמש בתפקיד אופרטור במרחב שמות עבור משתמשים שמספקים שירותי אדמין של פעולות או DevOps. הם יכולים לבצע את כל הפעולות שמפתחים יכולים לבצע (חוץ מתצוגה מקדימה של צינורות), וגם לפרוס ארטיפקטים ולנהל פרופילים של מחשוב.
  • תפקיד עריכה במרחב שמות הוא תפקיד עם הרשאות מיוחדות שנותן למשתמש או לקבוצת Google גישה מלאה לכל המשאבים במרחב השמות. תפקיד העורך יכול להיחשב כאיחוד של תפקידי המפתח והמפעיל.
  • אופרטורים ואדמינים צריכים להיזהר מהתקנה של תוספים או ארטיפקטים לא מהימנים, כי הם עלולים להוות סיכון אבטחה.

פתרון בעיות

בקטע הזה מוסבר איך לפתור בעיות שקשורות ל-RBAC ב-Cloud Data Fusion.

חשבון ראשי עם תפקיד Cloud Data Fusion Viewer במרחב שמות ב-RBAC יכול לערוך צינורות

הגישה מבוססת על שילוב של תפקידי IAM ו-RBAC. לתפקידי IAM יש עדיפות על פני תפקידי RBAC. בודקים אם לחשבון המשתמש יש תפקידי IAM של עריכת פרויקט או אדמין ב-Cloud Data Fusion.

חשבון משתמש עם התפקיד Instance Admin ב-RBAC לא יכול להציג מופעים של Cloud Data Fusion ב Google Cloud מסוף

יש בעיה מוכרת ב-Cloud Data Fusion שבה חשבונות משתמשים עם התפקיד Instance Admin לא יכולים לראות מופעים במסוף Google Cloud . כדי לפתור את הבעיה, צריך להעניק לחשבון המשתמש את התפקיד Project Viewer או אחד מתפקידי ה-IAM של Cloud Data Fusion, בנוסף להגדרת החשבון כאדמין במופע. הפעולה הזו מעניקה לחשבון המשתמש גישת צפייה לכל המופעים בפרויקט.

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

כדי למנוע מחשבון משתמש לצפות במרחבי שמות שאין לו תפקיד בהם, אסור שיהיה לו התפקיד Project Viewer או אחד מתפקידי IAM ב-Cloud Data Fusion. במקום זאת, מקצים תפקידי RBAC לחשבון המשתמש במרחב השמות שבו הוא צריך לפעול.

למשתמש הראשי עם סוג הגישה הזה לא תהיה אפשרות לראות את רשימת המופעים של Cloud Data Fusion במסוף Google Cloud . במקום זאת, אפשר לתת להם קישור ישיר למופע, כמו בדוגמה הבאה: https://INSTANCE_NAME-PROJECT_ID.REGION_NAME.datafusion.googleusercontent.com/

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

הקצאת התפקיד Cloud Data Fusion Accessor לחשבון ראשי

תפקיד Accessor מוקצה לחשבון משתמש באופן מרומז כשמוקצה לו תפקיד אחר של RBAC בכל מופע של Cloud Data Fusion. כדי לבדוק אם לחשבון משתמש יש את התפקיד הזה במופע מסוים, אפשר לעיין במאמר בנושא כלי ניתוח מדיניות IAM.

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