סקירה כללית על בקרת גישה מבוססת-תפקיד (RBAC) לנתונים
בקרת גישה מבוססת-תפקידים לנתונים (data RBAC) היא מודל אבטחה שמשתמש בתפקידים של משתמשים ספציפיים כדי להגביל את הגישה של המשתמשים לנתונים בארגון. באמצעות RBAC של נתונים, אדמינים יכולים להגדיר היקפים ולהקצות אותם למשתמשים כדי לוודא שהמשתמשים יכולים לגשת רק לנתונים שנדרשים להם לצורך ביצוע התפקיד שלהם.
בדף הזה מוסבר איך פועלת בקרת גישה מבוססת-תפקידים (RBAC) לנתונים, ואיך תוויות והיקפים פועלים יחד כדי להגדיר הרשאות גישה לנתונים.
ההבדל בין RBAC של נתונים לבין RBAC של תכונות
גם RBAC של נתונים וגם RBAC של תכונות הן שיטות לשליטה בגישה בתוך מערכת, אבל הן מתמקדות בהיבטים שונים.
בקרת גישה מבוססת-תפקידים (RBAC) לתכונות מאפשרת לשלוט בגישה לתכונות או לפונקציות ספציפיות במערכת. היא קובעת לאילו תכונות יש למשתמשים גישה בהתאם לתפקידים שלהם. לדוגמה, לאנליסט מתחיל יכולה להיות גישה רק לצפייה במרכזי בקרה, אבל לא ליצור או לשנות כללי זיהוי, בעוד שלאנליסט בכיר יכולות להיות הרשאות ליצור ולנהל כללי זיהוי. מידע נוסף על בקרת גישה מבוססת-תפקידים (RBAC) לפיצ'רים זמין במאמר הגדרת בקרת גישה לפיצ'רים באמצעות IAM.
בקרת גישה מבוססת-תפקידים (RBAC) לנתונים שולטת בגישה לנתונים או למידע ספציפיים במערכת. ההרשאה קובעת אם משתמש יכול לצפות בנתונים, לערוך אותם או למחוק אותם, בהתאם לתפקיד שלו. לדוגמה, במערכת לניהול קשרי לקוחות (CRM), נציג מכירות יכול לקבל גישה לפרטים ליצירת קשר עם לקוחות אבל לא לנתונים פיננסיים, בעוד שמנהל פיננסי יכול לקבל גישה לנתונים הפיננסיים אבל לא לפרטים ליצירת קשר עם לקוחות.
לרוב משתמשים ב-RBAC של נתונים וב-RBAC של תכונות יחד כדי לספק מערכת מקיפה של בקרת גישה. לדוגמה, יכול להיות שלמשתמש תהיה גישה לתכונה ספציפית (RBAC של תכונות), אבל בתוך התכונה הזו הגישה שלו לנתונים ספציפיים תהיה מוגבלת על סמך התפקיד שלו (RBAC של נתונים).
תכנון ההטמעה
כדי לתכנן את ההטמעה, כדאי לעיין ברשימת התפקידים וההרשאות המוגדרים מראש של Google Security Operations ולהתאים אותם לצורכי הארגון. תכננו אסטרטגיה להגדרת היקפים ולתיוג נתונים נכנסים. כדי לנהל היקפי גישה, צריך לוודא שהוקצה לכם התפקיד 'צפייה בתפקידים' (roles/iam.roleViewer).
מזהים אילו חברים צריכים לקבל גישה לנתונים במסגרת ההיקפים האלה.
אם בארגון שלכם נדרשות מדיניות IAM מעבר לתפקידים המוגדרים מראש ב-Google SecOps, אתם יכולים ליצור תפקידים בהתאמה אישית כדי לתמוך בדרישות ספציפיות.
תפקידי משתמשים
למשתמשים יכולה להיות גישה לנתונים בהיקף מוגבל (משתמשים עם היקף מוגבל) או גישה לנתונים גלובלית (משתמשים גלובליים).
למשתמשים עם היקף הרשאות יש גישה מוגבלת לנתונים, בהתאם להיקפים שהוקצו להם. היקפי ההרשאות האלה מגבילים את הגישה של האפליקציות לנתונים ספציפיים ואת הפעולות שהן יכולות לבצע. בטבלה הבאה מפורטות ההרשאות הספציפיות שמשויכות לגישה מוגבלת.
למשתמשים גלובליים לא מוקצים היקפי גישה, ויש להם גישה בלתי מוגבלת לכל הנתונים ב-Google SecOps. בטבלה הבאה מפורטות ההרשאות הספציפיות שמשויכות לגישה גלובלית.
גישה גלובלית מבטלת את הגישה המוגבלת. אם למשתמש מוקצים גם תפקיד גלובלי וגם תפקיד מוגבל, יש לו גישה לכל הנתונים, בלי קשר להגבלות שחלות על התפקיד המוגבל.
אדמינים של RBAC לנתונים יכולים ליצור היקפי הרשאות ולהקצות אותם למשתמשים כדי לשלוט בגישה שלהם לנתונים ב-Google SecOps. כדי להגביל את הגישה של משתמש להיקפים מסוימים, חובה להקצות לו את התפקיד Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess) יחד עם תפקיד מוגדר מראש או תפקיד בהתאמה אישית. התפקיד "גישה מוגבלת לנתונים ב-Chronicle API" מזהה משתמש כמשתמש עם הרשאה מוגבלת. אין צורך להקצות את התפקיד 'גישה מוגבלת לנתונים' ב-Chronicle למשתמשים שזקוקים לגישה לנתונים גלובליים.
אפשר להקצות למשתמשים את התפקידים הבאים:
| סוג הגישה | תפקידים | הרשאות |
|---|---|---|
| גישה גלובלית מוגדרת מראש | אפשר להקצות למשתמשים גלובליים כל אחד מתפקידי ה-IAM המוגדרים מראש. | |
| גישה מוגבלת מראש לקריאה בלבד | גישה מוגבלת לנתונים ב-Chronicle API (roles/chronicle.restrictedDataAccess) וצפייה בגישה מוגבלת לנתונים ב-Chronicle API (roles/chronicle.restrictedDataAccessViewer)
|
Chronicle API Restricted Data Access Viewer |
| גישה בהיקף מותאם אישית | גישה מוגבלת לנתונים ב-Chronicle API (roles/chronicle.restrictedDataAccess) ותפקיד בהתאמה אישית (להגדרת RBAC של תכונה)
|
הרשאות בהתאמה אישית בתכונות |
| גישה גלובלית בהתאמה אישית | הרשאה chronicle.globalDataAccessScopes.permit וגישה גלובלית לנתונים ב-Chronicle API (roles/globalDataAccess)
|
הרשאות גלובליות בתכונות |
בטבלה הבאה מפורטים סוגי הגישה:
גישה גלובלית מוגדרת מראש: בדרך כלל נדרשת למשתמשים שצריכים גישה לכל הנתונים. אתם יכולים להקצות למשתמש תפקיד אחד או יותר, בהתאם להרשאות הנדרשות.
הרשאת קריאה בלבד מוגדרת מראש: הרשאה למשתמשים שצריכים גישה לקריאה בלבד. התפקיד 'גישה מוגבלת לנתונים' ב-Chronicle API מזהה משתמש כמשתמש עם היקף הרשאות מוגבל. התפקיד 'צפייה בגישה מוגבלת לנתונים' ב-Chronicle API מאפשר למשתמשים לצפות בנתונים במסגרת התכונות שלהם.
גישה בהיקף מותאם אישית: התפקיד "גישה מוגבלת לנתונים" ב-Chronicle API מזהה משתמש כמשתמש בהיקף מוגדר. התפקיד בהתאמה אישית מציין את התכונות שהמשתמש יכול לגשת אליהן. ההיקפים שנוספו לתפקיד Chronicle API Restricted Data Access (גישה מוגבלת לנתונים של Chronicle API) מציינים את הנתונים שהמשתמשים יכולים לגשת אליהם בתכונות.
כדי לוודא שההיקפים המותאמים אישית של RBAC פועלים בצורה תקינה, צריך לכלול את ההרשאה chronicle.dataAccessScopes.list כשיוצרים את התפקידים בהתאמה אישית. עם זאת, אל תכללו את ההרשאותchronicle.DataAccessScopes.permit או chronicle.globalDataAccessScopes.permit. יכול להיות שההרשאות האלה נכללות אם השתמשתם בתפקידים המוגדרים מראש "עריכה ב-Chronicle API" או "אדמין ב-Chronicle API" כנקודת התחלה לתפקידים בהתאמה אישית.
גישה גלובלית בהתאמה אישית: הגישה הזו מיועדת למשתמשים שצריכים הרשאות בלתי מוגבלות בתכונות שהוקצו להם. כדי לתת למשתמש גישה גלובלית בהתאמה אישית, צריך לציין את ההרשאה chronicle.globalDataAccessScopes.permit בנוסף לתפקיד בהתאמה אישית שמוקצה למשתמש.
תפקידי משתמשים במרכזי בקרה
הגישה ללוחות הבקרה נקבעת לפי שני גורמים עיקריים: התפקיד הפונקציונלי של המשתמש והיקף הגישה לנתונים שלו. השילוב של שני הרכיבים האלה קובע את הגישה למרכז הבקרה. התפקיד שמוקצה למשתמש משנה באופן ישיר את ממשק המשתמש והיכולות שזמינים לו. אלה התפקידים המוגדרים מראש הכי נפוצים שנותנים למשתמשים גישה ללוחות בקרה:
| סוג הגישה | תפקידים | תיאור |
|---|---|---|
| צפייה | roles/chroniclesiem.viewer |
ההרשאה מאפשרת גישה לקריאה בלבד. המשתמשים יכולים לפתוח את כל מרכזי הבקרה ולבצע בהם פעולות, אבל הם לא יכולים ליצור או לערוך אותם. |
| עריכה | roles/chroniclesiem.editor |
ההרשאה הזו מעניקה גישה לכל הנתונים ולכל ההרשאות, כולל האפשרות ליצור, לערוך ולמחוק מרכזי בקרה בהתאמה אישית. |
| מנהל מערכת | roles/chroniclesiem.admin |
הרשאות מלאות, בדומה לתפקיד העריכה, עם גישה לכל הנתונים. |
| צפייה מוגבלת | roles/chroniclesiem.restrictedViewer |
בדומה לתפקיד "צפייה", אבל כל הנתונים שמוצגים במרכז הבקרה מסוננים בהתאם לאוסף תצוגות היומן (Data RBAC) שהוקצה למשתמש. |
מידע נוסף על RBAC של נתונים ו-RBAC של תכונות זמין במאמר ההבדל בין RBAC של נתונים לבין RBAC של תכונות.
הרשאות לתפקידים בהתאמה אישית
אתם יכולים להגדיר הרשאות מפורטות על ידי יצירת תפקידים בהתאמה אישית.
ההרשאות הבאות חלות על מרכזי בקרה:
chronicle.dashboards.list: מאפשרת למשתמשים לראות את רשימת מרכזי הבקרה הזמינים.
chronicle.dashboards.get: מאפשרת למשתמשים לפתוח את התוכן של מרכז הבקרה ולצפות בו.
chronicle.dashboards.create: מאפשרת למשתמשים ליצור לוחות בקרה חדשים.
chronicle.dashboards.update: מאפשרת למשתמשים לערוך ולשמור שינויים במרכזי בקרה קיימים.
chronicle.dashboards.delete: מאפשרת למשתמשים למחוק מרכזי בקרה בהתאמה אישית.
לדוגמה, אתם יכולים ליצור תפקיד בהתאמה אישית בשם "יוצר מרכז בקרה" עם ההרשאות chronicle.dashboards.create ו-chronicle.dashboards.list permissions בלבד.
משתמש עם התפקיד הזה יכול ליצור מרכז בקרה חדש, אבל לא לערוך מרכז בקרה קיים.
בקרת גישה באמצעות היקפים ותוויות
Google SecOps מאפשר לכם לשלוט בגישה של משתמשים לנתונים באמצעות היקפי הרשאות. היקפי הרשאות מוגדרים בעזרת תוויות שמגדירות את הנתונים שלמשתמש בהיקף יש גישה אליהם. במהלך ההטמעה, מטא-נתונים מוקצים לנתונים בצורה של תוויות כמו מרחב שמות (אופציונלי), מטא-נתונים של הטמעה (אופציונלי) וסוג יומן (חובה). אלה תוויות ברירת מחדל שמוחלות על נתונים במהלך ההטמעה. בנוסף, אתם יכולים ליצור תוויות בהתאמה אישית. אתם יכולים להשתמש בתוויות ברירת מחדל ובתוויות בהתאמה אישית כדי להגדיר את ההיקפים ואת רמת הגישה לנתונים שההיקפים יגדירו.
חשיפת נתונים באמצעות תוויות הרשאה ודחייה
כל היקף מכיל תווית אחת או יותר של allow access (מתן גישה) ותוויות של deny access (דחיית גישה) (אופציונלי). תוויות גישה מאפשרות למשתמשים לגשת לנתונים שמשויכים לתווית. תוויות של דחיית גישה מונעות מהמשתמשים גישה לנתונים שמשויכים לתווית. תוויות של דחיית גישה מבטלות את התוויות של מתן גישה בהגבלת הגישה של המשתמש.
בהגדרת היקף, תוויות גישה מאותו סוג (לדוגמה, סוג יומן) משולבות באמצעות האופרטור OR, ואילו תוויות מסוגים שונים (לדוגמה, סוג יומן ותווית בהתאמה אישית) משולבות באמצעות האופרטור AND. תוויות של דחיית גישה משולבות באמצעות האופרטור OR. אם מוחלות כמה תוויות של דחיית גישה בהיקף מסוים, הגישה נדחית אם יש התאמה לאחת מהתוויות האלה.
לדוגמה, נניח שיש מערכת Cloud Logging שמסווגת יומנים באמצעות סוגי התוויות הבאים:
סוג היומן: גישה, מערכת, חומת אש
מרחב שמות: App1, App2, Database
חומרה: קריטית, אזהרה
נניח שיש היקף הרשאות שנקרא "יומנים מוגבלים" עם הגישה הבאה:
| סוג התווית | ערכים מותרים | ערכים שנדחו |
|---|---|---|
| סוג יומן הביקורת | Access, Firewall | מערכת |
| מרחב שמות | App1 | App2, Database |
| חוּמרה | אזהרה | קריטית |
הגדרת ההיקף נראית כך:
אישור: (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")
דחייה: Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"
דוגמאות ליומנים שתואמים להיקף:
- יומן גישה מ-App1 עם רמת חומרה: אזהרה
- יומן חומת אש מאפליקציה 1 עם חומרה: אזהרה
דוגמאות ליומנים שלא תואמים להיקף:
- יומן מערכת מאפליקציה 1 עם חומרה: אזהרה
- יומן גישה ממסד נתונים עם רמת חומרה: אזהרה
- יומן חומת אש מ-App2 עם חומרה: קריטית
חשיפת הנתונים באירועים מועשרים
אירועים מועשרים הם אירועי אבטחה שנוספו להם הקשר ומידע מעבר למה שכלול בנתוני היומן הגולמיים. אפשר לגשת לאירועים מועשרים בהיקף מסוים רק אם אפשר לגשת לאירוע הבסיס בהיקף הזה, ואם אף אחת מהתוויות המועשרות לא כוללת אף אחת מהתוויות שמונעות גישה בהיקף הזה.
לדוגמה, נניח שיש יומן גולמי שמציין ניסיון כניסה שנכשל מכתובת IP, ויש לו תווית מועשרת user_risk: high (מציינת משתמש בסיכון גבוה).
משתמש עם היקף הרשאות שכולל את תווית הדחייה user_risk: high לא יכול לראות ניסיונות כניסה שנכשלו של משתמשים בסיכון גבוה.
ההשפעה של RBAC על נתונים בתכונות של Google Security Operations
אחרי שמגדירים את ה-RBAC של הנתונים, המשתמשים מתחילים לראות נתונים מסוננים בתכונות של Google Security Operations. ההשפעה תלויה באופן השילוב של התכונה עם הנתונים הבסיסיים. כדי להבין איך RBAC משפיע על כל תכונה, אפשר לעיין במאמר ההשפעה של RBAC על תכונות ב-Google Security Operations.
המאמרים הבאים
הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.