7.4 סוגים ומודלים של בקרת גישה

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

המודלים הפופולריים הם: 

• בקרת גישה מבוססת תפקידים (RBAC)
• בקרת גישה מנדטורית (MAC)
• בקרת גישה מבוססת שיקול דעת (DAC)

מודלים נוספים:

• בקרת גישה מבוססת תכונות (ABAC)
• בקרת גישה מבוססת כללים (RBAC)
• בקרת גישה מבוססת זמן (TBAC)
• בקרת גישה מבוססת סיכונים (RAdAC)
• בקרת גישה מבוססת מדיניות (PBAC)

יישומים מתקדמים בבקרת גישה:

• רשימת בקרת גישה (Access Control List)
• מדיניות גישה מותנית (Conditional Access Policy)
• בקרת גישה מבוססת התנהגות (Behavioral Access Control)
• בקרת גישה רוחבית (Cross Domain Access Control)

בקרת גישה נאכפת באמצעות אחת או יותר מהבקרות הבאות:

1. מבוססת תכונות: כלומר, ההרשאות ניתנות לפי תכונות של המשתמשים או המשאב אליו רוצים לגשת.
2. מבוססת היררכיית מידע (סיווג ומידור): בגישה זו, ה"בעלים" של כל קובץ (לדוגמה), מגדיר מה הסיווג שלו והאדמיניסטרטור אוכף מדיניות ולפיה רק לאנשים שיש להם סיווג "סודי" נניח, מותר לגשת לקבצים שה"בעלים" שלהם סווגו אותם ככאלה.
3. מבוססת התנהגות או היסטוריית שימוש: בגישה זו מביאים בחשבון את ההיסטוריה של המשתמש ומבטלים לו את ההרשאות במקרים שהוא הפסיק להשתמש בהן לאורך זמן גדול מידי, או, כאשר מופיעות "התנהגויות לא הגיוניות" כמו ניסיונות כניסה חוזרים ונשנים עם סיסמה שגויה, פנייה לקבצים בקצב לא אנושי (מספר רב של פעמים בשנייה) וכיוצא באלו.
4. מבוססת הזדהות משתמשים: גישה ולפיה מתן ההרשאות הוא אישי לכל משתמש
5. מבוססת שיוך ארגוני
6. מבוססת תפקיד. לדוגמה: לאיש כוח אדם לא תהיה גישה ליכולת ניהול רכיבי תקשורת ברשת.
7. מבוססת חוקים. לדוגמה – לסטודנטים בשנה א' באוניברסיטה גדולה, ניתן להגביל את הגישה למחשבי המעבדות רק לשעות מסוימות, בימים שבהם האוניברסיטה פתוחה וכדומה.

בקרת גישה מבוססת שיקול דעת: Discretionary Access Control (DAC)

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

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

היתרונות של DAC

• העצמת משתמשים: DAC מעצימה משתמשים בודדים, ומעניקה להם שליטה על הנתונים והמשאבים שלהם. זה יכול להיות שימושי במיוחד בסביבות שבהן שיתוף פעולה הוא המפתח, וייתכן שיהיה צורך להתאים את ההרשאות לעתים קרובות בהתאם לצרכי הפרויקט.
• קלות יישום: בהתחשב בכך ש-DAC טבוע במערכות קבצים וסביבות הפעלה רבות, הוא פשוט יחסית ליישום ללא צורך בתצורות מורכבות.

החסרונות של DAC

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

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

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

בקרת גישה מנדטורית: Mandatory Access Control (MAC)

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

יתרונות MAC

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

חסרונות MAC

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

דוגמאות לשימוש ב-MAC

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

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

דוגמה מוחשית להשוואה בין המודלים DAC ו-MAC לבקרת גישה:

DAC (Discretionary Access Control): נניח חברת הייטק שבה לכל עובד יש תיקייה אישית ברשת הארגון. במודל DAC, כל עובד שולט על רמת הגישה לתיקייה שלו - הוא יכול לתת הרשאות קריאה או שינוי לעמיתים אחרים אם הוא רוצה.

חסרון - עובד יכול לגרום לדליפת מידע רגיש על ידי מתן גישה לאנשים שאינם מורשים.

MAC (Mandatory Access Control): באותה חברה, המידע מסווג על פי רמות ביטחון: סודי, פנימי, ציבורי. כל עובד ומסמך מקבלים סיווג ביטחוני.

במודל MAC, עובד יכול לגשת רק למידע ברמת הסיווג שלו או נמוכה יותר.

יתרון - נמנע "דלף" מידע בין רמות סיווג שונות.

לסיכום, MAC טוב יותר לאכיפת מדיניות אחידה של הפרדת מידע, אך DAC מאפשר יותר גמישות ושליטה אישית.

בקרת גישה מבוססת תפקידים (RBAC) Role-Based Access Control

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

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

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

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

יתרונות RBAC

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

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

אתגרים וחסרונות

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

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

אבולוציה ועיבודים מודרניים של RBAC

נוף הרשת המודרני דורש דגמי RBAC גמישים וניתנים להתאמה כדי להתמודד עם הדרישות המתפתחות של ארגונים.

• בקרת גישה מבוססת מאפיינים (ABAC): מודל מתקדם המשתמש בתכונות של משתמשים, משאבים ותנאי סביבה כדי לקבל החלטות גישה, המספק פירוט ויכולת הסתגלות עדינים יותר.
• מודלים מבוזרים של RBAC: התאמות מודרניות של RBAC עבור סביבות מבוזרות ומפוזרות, כמו שירותי ענן, המבטיחות בקרת גישה עקבית על פני פלטפורמות מגוונות.

RBAC בסביבות ענן

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

דוגמה מוחשית להשוואה בין המודלים MAC ו-RBAC לבקרת גישה:

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

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

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

במודל RBAC, עובד מקבל גישה לפי הגדרת התפקיד שלו, ולא לפי סיווג אישי.

לסיכום,‏ MAC טוב יותר להפרדה ברמת סיווג המידע, אך RBAC מתמקד בהפרדת תפקידים והרשאות.

בקרת גישה מבוססת תכונות (ABAC)

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

מבחינה מעשית, זה מאפשר לך לכתוב כללים ב-eXtensible Access Control Markup Language (XACML), באמצעות צמדי מפתח-ערך כמו Role=Manager ו-Category=Financial.

יתרונות של ABAC

• מיקוד: מכיוון שהוא משתמש בתכונות ולא בתפקידים כדי לציין קשרים בין משתמשים ומשאבים, מנהלי מערכת יכולים ליצור כללים ממוקדים במדויק מבלי ליצור תפקידים נוספים.
• גְמִישׁוּת: קל להתאים את מדיניות ABAC כאשר המשאבים והמשתמשים משתנים. במקום לשנות כללים או ליצור תפקידים חדשים, מנהלי מערכת צריכים רק להקצות את התכונות הרלוונטיות למשתמשים או למשאבים חדשים.
• סְגִילוּת: ABAC מקל על הוספה וביטול של הרשאות בכך שהוא מאפשר למנהלי מערכת לשנות תכונות. זה מפשט את ההטמעה.
• בִּטָחוֹן: ABAC מאפשר למנהלי מערכת ליצור כללים רגישים להקשר כאשר צרכי אבטחה מתעוררים, כך שיוכלו להגן ביתר קלות על פרטיות המשתמש ולעמוד בדרישות התאימות - מבלי לדרוש רמה גבוהה של ידע טכני.

חסרונות של ABAC

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

דוגמה מוחשית להשוואה בין המודלים RBAC ו-ABAC לבקרת גישה:

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

ABAC: באותה חברה, הגישה למידע לקוחות נקבעת על פי מאפיינים כמו: סניף השיוך של הלקוח, סוג הפוליסה, ותק לקוח. לדוגמה: פקיד יכול לגשת רק ללקוחות בסניף שלו, סוגים מסוימים של פוליסות.

לסיכום, RBAC מתבסס על תפקידים ו-ABAC מתבסס על מאפייני משתמשים ומידע. שניהם שימושיים בהקשרים שונים.

בקרת גישה מבוססת כללים: Rule-Based Access Control

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

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

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

יתרונות RBAC

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

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

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

Rule Based: באותה חברה, ניתן להגדיר כללי גישה על בסיס:

• סניף שאליו משויך הלקוח
• סוג וותק הפוליסה
• גיל הלקוח

לדוגמה: גישה לנתוני לקוח מעל גיל 21 רק אם הפוליסה בת יותר מ-5 שנים.

לסיכום, מודל כללים מאפשר הגדרות גישה גמישות יותר, אך RBAC פשוט ונוח יותר לניהול.

בקרת גישה מבוססת זמן: Time-Based Access Control (TBAC)

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

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

יתרונות של TBAC

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

חסרונות של TBAC

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

דוגמה

TBAC: נניח בנק שמגביל גישה למידע רגיש על חשבונות לקוחות על בסיס לוח זמנים:

• גישה מלאה בשעות העבודה
• גישה מוגבלת אחר הצהריים ובסופי שבוע
• חסימת גישה בלילות וחגים

לסיכום,‏ TBAC מתבסס על לוח זמנים קבוע.

בקרת גישה מבוססת סיכונים - Risk Adaptive-Based Access Control - RAdAC

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

בקרת גישה מבוססת סיכונים (Risk Adaptive-Based Access Control - RAdAC) היא מודל בקרת גישה המבוסס על הערכת סיכונים. 

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

הערכת סיכונים

הערכת סיכונים היא תהליך של זיהוי וסיווג של סיכונים. הערכת הסיכונים כוללת את המרכיבים הבאים:

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

קביעת הרשאות גישה

לאחר הערכת הסיכונים, הרשאות הגישה למשאבים נקבעות על סמך המרכיבים הבאים:

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

יתרונות של RAdAC

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

• חסרונות של RAdAC

• מורכבות: RAdAC יכול להיות מורכב יותר ליישום ממודלי בקרת גישה אחרים, מכיוון שהוא דורש הערכה מדויקת של הסיכונים.
• עלות: RAdAC יכול להיות יקר יותר ליישום ממודלי בקרת גישה אחרים, מכיוון שהוא דורש רכישת תוכנה ושירותים מתאימים.
  
  

דוגמאות לשימוש ב-RAdAC

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

להלן דוגמה מוחשית לשימוש במודל RAdAC לבקרת גישה:

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

עם זאת, החברה רוצה להגביל את הגישה בהתאם לרמת הסיכון, על בסיס:

מיקום - גישה מרשת ציבורית מסוכנת יותר מאשר גישה מהרשת הפרטית בבית

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

בקרת גישה מבוססת מדיניות Policy-Based Access Control - PBAC

PBAC היא אסטרטגיית ניהול גישה נוספת המתמקדת בהרשאה. בעוד ש-RBAC מגביל את גישת המשתמש על סמך תפקידים סטטיים, PBAC קובע הרשאות גישה באופן דינמי על סמך כללים ומדיניות. למרות ש-PBAC דומה למדי ל-ABAC, ABAC דורש יותר משאבי IT ופיתוח (למשל, קידוד XML) ככל שמספר התכונות הנדרשות גדל.

יתרונות PBAC:

• גמישות: מנהלי מערכת יכולים ליצור מדיניות המאפשרת גישה עדינה או גסה.
• מְהִירוּת. PBAC מאפשר לך להוסיף, להסיר או לשנות הרשאות במהירות.
• יכולת הסתגלות: מדיניות מתייחסת לבקרות סביבתיות והקשריות (למשל, גישה תלוית זמן או מיקום).
• צפייה: מדיניות הניתנת לקריאה על ידי אדם מספקת נראות לגבי הקשר בין זהויות ומשאבים.

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

דוגמה לשימוש ב-PBAC

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

לדוגמה, ארגון זה יכול להגדיר את רמת הסיווג של המידע הפיננסי הרגיש כ"גבוהה". לאחר מכן, ארגון זה יכול להשתמש ב-PBAC כדי לקבוע שרק משתמשים בתפקידים מסוימים, כגון עובדים בתחום הפיננסים, יכולים לגשת למידע זה.

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

דוגמה מוחשית יותר:

נניח שעובד בשם נדב עובד בתחום הפיננסים בארגון הפיננסי. נדב מורשה לגשת למידע הפיננסי הרגיש של הארגון, אך הוא אינו אמור לשנות אותו.

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

במקרה זה, PBAC עזר להגן על המידע הפיננסי הרגיש של הארגון מפני שינוי לא מורשה.

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

כעת, בואו נראה כיצד ניתן להשתמש ב-PBAC כדי לשפר את הדוגמה הזו.

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

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

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

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

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

עבור למאמר הבא