סקירה כללית על 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 Restricted Data Access מזהה משתמש כמשתמש עם היקף הרשאות. אין צורך להקצות את התפקיד הזה למשתמשים שזקוקים לגישה גלובלית לנתונים.
אפשר להקצות למשתמשים את התפקידים הבאים:
| סוג הגישה | תפקידים | הרשאות |
|---|---|---|
| גישה גלובלית מוגדרת מראש | אפשר להעניק למשתמשים גלובליים כל אחד מתפקידי ה-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 Restricted Data Access מזהה משתמש כמשתמש בהיקף. התפקיד המותאם אישית מציין את התכונות שהמשתמש יכול לגשת אליהן. ההיקפים שנוספו לתפקיד 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 |
בדומה לתפקיד הצופה, אבל כל הנתונים שמוצגים בלוח הבקרה מסוננים בהתאם לאוסף תצוגות יומן (log scope) שהוקצה למשתמש (Data RBAC). |
מידע נוסף על RBAC של נתונים ו-RBAC של תכונות זמין במאמר ההבדל בין RBAC של נתונים לבין RBAC של תכונות.
הרשאות לתפקידים מותאמים אישית
אפשר ליצור תפקידים בהתאמה אישית כדי להגדיר הרשאות מפורטות.
ההרשאות הבאות חלות על לוחות בקרה:
chronicle.dashboards.list: מאפשרת למשתמשים לראות את רשימת לוחות הבקרה הזמינים.
chronicle.dashboards.get: מאפשר למשתמשים לפתוח ולהציג תוכן של לוח בקרה.
chronicle.dashboards.create: מאפשר למשתמשים ליצור מרכזי בקרה חדשים.
chronicle.dashboards.update: מאפשרת למשתמשים לערוך ולשמור שינויים בלוחות בקרה קיימים.
chronicle.dashboards.delete: מאפשר למשתמשים למחוק מרכזי בקרה בהתאמה אישית.
לדוגמה, אפשר ליצור תפקיד בהתאמה אישית בשם Dashboard Creator (יוצר מרכז בקרה) עם ההרשאות chronicle.dashboards.create ו-chronicle.dashboards.list permissions בלבד. משתמש עם התפקיד הזה יכול ליצור מרכז בקרה חדש, אבל לא יכול לערוך מרכז בקרה קיים.
בקרת גישה באמצעות היקפים ותוויות
Google SecOps מאפשר לכם לשלוט בגישת המשתמשים לנתונים באמצעות היקפי הרשאות. היקפי הרשאות מוגדרים בעזרת תוויות שמגדירות את הנתונים שלמשתמש בהיקף ההרשאות יש גישה אליהם. במהלך ההטמעה, מטא-נתונים מוקצים לנתונים בצורה של תוויות כמו מרחב שמות (אופציונלי), מטא-נתונים של הטמעה (אופציונלי) וסוג יומן (חובה). אלה תוויות ברירת מחדל שמוחלות על נתונים במהלך ההטמעה. בנוסף, אתם יכולים ליצור תוויות בהתאמה אישית. אתם יכולים להשתמש גם בתוויות ברירת מחדל וגם בתוויות בהתאמה אישית כדי להגדיר את היקפי ההרשאות ואת רמת הגישה לנתונים שיוגדרו בהיקפי ההרשאות.
חשיפת נתונים באמצעות תוויות של אישור ודחייה
כל היקף מכיל תווית אחת או יותר של מתן גישה, ואפשרותית גם תוויות של דחיית גישה. תוויות של מתן גישה מאפשרות למשתמשים לגשת לנתונים שמשויכים לתווית. תוויות של דחיית גישה מונעות מהמשתמשים לגשת לנתונים שמשויכים לתווית. תוויות של דחיית גישה מבטלות את ההשפעה של תוויות של מתן גישה בהגבלת הגישה של המשתמש.
בהגדרת היקף, תוויות של הרשאת גישה מאותו סוג (לדוגמה, סוג יומן) משולבות באמצעות האופרטור OR, ואילו תוויות מסוגים שונים (לדוגמה, סוג יומן ותווית בהתאמה אישית) משולבות באמצעות האופרטור AND. תוויות של הרשאת גישה מסוג deny משולבות באמצעות האופרטור OR. כשמחילים כמה תוויות של הרשאת גישה מסוג deny בהיקף, הגישה נדחית אם יש התאמה לאחת מהתוויות האלה.
לדוגמה, נניח שיש מערכת Cloud Logging שמסווגת יומנים באמצעות סוגי התוויות הבאים:
סוג היומן: גישה, מערכת, חומת אש
מרחב שמות: App1, App2, Database
חומרה: קריטית, אזהרה
נניח שיש היקף שנקרא 'יומנים מוגבלים' עם הגישה הבאה:
| סוג התווית | ערכים מותרים | ערכים שנפסלו |
|---|---|---|
| סוג יומן הביקורת | גישה, חומת אש | מערכת |
| מרחב שמות | 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"
דוגמאות ליומנים שתואמים להיקף:
- יומן גישה מאפליקציה 1 עם חומרה: אזהרה
- יומן חומת האש מאפליקציה 1 עם מידת חומרה: אזהרה
דוגמאות ליומנים שלא תואמים להיקף:
- יומן מערכת מאפליקציה 1 עם מידת חומרה: אזהרה
- יומן גישה ממסד נתונים עם מידת חומרה: אזהרה
- יומן חומת אש מאפליקציה 2 עם חומרה: קריטית
הרשאות גישה לנתונים באירועים מועשרים
אירועים מועשרים הם אירועי אבטחה שנוספו להם הקשר ומידע מעבר למה שכלול בנתוני היומן הגולמיים. אפשר לגשת לאירועים מועשרים בהיקף מסוים רק אם אפשר לגשת לאירוע הבסיסי בהיקף הזה, ואם אף אחת מהתוויות המועשרות לא כוללת אף אחת מהתוויות של ההיקף שמונעות גישה.
לדוגמה, נניח שיש יומן גולמי שמציין ניסיון כניסה שנכשל מכתובת IP, ויש לו תווית מועשרת user_risk: high (מציינת משתמש בסיכון גבוה). משתמש עם היקף שכולל את תווית הדחייה user_risk: high לא יכול לראות ניסיונות כניסה שנכשלו של משתמשים בסיכון גבוה.
השפעת ה-RBAC של הנתונים על התכונות של Google Security Operations
אחרי שמגדירים את בקרת הגישה מבוססת-התפקידים לנתונים, המשתמשים מתחילים לראות נתונים מסוננים בתכונות של Google Security Operations. ההשפעה תלויה באופן השילוב של התכונה עם הנתונים הבסיסיים. כדי להבין איך RBAC משפיע על כל תכונה, אפשר לעיין במאמר ההשפעה של RBAC על תכונות ב-Google Security Operations.
המאמרים הבאים
הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.