משולש CIA מציג את עקרונות אבטחת המידע ולמעשה מרכיב את בסיס העבודה של אנשי אבטחת המידע. ע"פ בסיס זה, יש לכוון את כל מאמצי העבודה ע"מ להשיג איזון הולם (בהתאם לסביבה) ליצירת סביבה מאובטחת. לעתים קרובות, משולש CIA, או AIC – מתואר כמשולש שווה-צלעות, וזאת בשביל לתאר את חשיבות האיזון בין שלושת הרבדים. CIA, או Confidentiality, Integrity, Availability , בעברית; סודיות, שלמות וזמינות, הם לא אחר מאשר מאפיינים, תכונות, עקרונות שיש להחיל על סביבה מסוימת כדי להבטיח כי אופן שימורה\אבטחתה הינו מתאים.
כל עקרון תופס מקום נפרד בסביבה המאובטחת – לכאורה. לדוגמא, מנהל א"מ יכול ליצור סביבה (סביבה יכולה להיות כל דבר המכיל מידע, כגון תוכנה, מערכת, מחשב, מקום...) בעלת רמה גבוהה מאוד של סודיות ושלמות בעוד שרמת(או עיקרון) הזמינות כמעט ולא נלקחת בחשבון. למרות שבסביבה זו – המידע הינו מוגן משינויים ומגישות לא מורשות – הוא גם יכול להיות לא זמין בעת שנצטרך לגשת אליו – דבר שלא בא בחשבון – בעיקר בגופים מסחריים.
סודיות הינו העיקרון המבטיח כי מידע מסוים לא יהיה נגיש למי שאין לו גישה אליו. רבים סבורים כי עקרון זה ממומש בעיקר בסביבות צבאיות, ממשלתיות. אך בד"כ, גם חברות מסחריות, בעיקר במאה ה-21 של זמננו – עושות שימוש בעקרון זה ע"מ להגן על הקניין הרוחני שלהם, נתוני מחקר, נתוני לקוחות ועוד. נושא הפרטיות, הגנת המידע וחקיקה היו גורם מניע לחשיבות (הגוברת) של עקרון הסודיות. בתחומים\מגזרים רבים כיום, עקרון זה אינו בגדר המלצה אם כי בגדר חובה – בהתאם לחוק.
שלמות הינו העיקרון המבטיח כי נתוני מידע כאלה או אחרים – לא שונו. הן בתעבורתם והן באחסונם. יש להבחין מתי דרישת העיקרון נחוצה ומתי פחות. לדוגמא, בעת הזרמת מדיה – מוזיקה, סרטים... אין דרישה לבקרת שלמות גבוהה – זאת משום שאם פאקט (צרור נתונים הנוצר כחלק מפעולת הכימוס בעת העברת נתונים) נופל, נעלם – הזרמת המדיה תמשיך ללא הפרעה מורגשת. חרף זאת, ארגונים פיננסיים כגון הבנקים, יראו בעיקרון זה מרכיב קריטי לאבטחת פעילותם, שכן חלילה בעת העברת סכום כסף, למשל, לא תתווסף ספרה ו\או כי סכום הכסף המיועד להעברה – לא שונה.
זמינות הינו העיקרון המבטיח כי מידע מסוים יהיה נגיש – עת שיהיה צורך לגשת אליו. זמן השבתה הינו זמן קריטי לחברות וארגונים שכן הוא גורר פגיעה בפעילות עסקית שותפת - הגוררת סיכון להפסד כספי.
אחריות בבקרת גישה
כמובן, כמו בכל תחום בחיינו, יש צורך בקביעת אחריות – מישהו\משהו המקבל החלטות ובזאת גם אחראי על השלכות ותוצאות הנגרמות ל-\מ-תחום אחריותו.
קיימים כ-שני תפקידי מפתח בתפעול בקרת גישה:
הנה כמה מושגי יסוד שיש לדעת כאשר מדברים על בקרות גישה:
בקרת גישה מבוססת חוקים או RSBAC מפקחת על פעולות המבוססות חוקים החלים על הסובייקט (זה שרוצה גישה) ביחס לאותו אובייקט אליו הוא רוצה לגשת. מודל זה מיושם במגוון מערכות הפעלה (כולל Linux) ומבוסס על מודל אבטחת מידע לה-פאדולה.
בקרת גישה מבוססת רשומה, פועלת ע"פ רשימה של סובייקטים(משתמשים) אל מול הרשאתם (Privilege) לכל אובייקט .
בקרת גישה מבוססת אסימונים פועלת ע"פ רשימה של אובייקטים והרשאות מתאימות לכל סובייקט (משתמש). אפשר להגיד כי זוהי בקרה הפוכה (באופן פעילותה) לבקרת גישה מבוסס רשומות.
מודל בקרת גישה מוגדר כתיאור פורמלי של מדיניות אבטחה. אבל מהי מדיניות אבטחה? מדיניות אבטחה מכילה את דרישות האבטחה או מתארת את הצעדים שיש לקחת ע"מ להשיג רמת אבטחה נדרשת.
דוגמאות ליישום MAC
יתרונותיה של בקרת גישה מסוג MAC
חסרונותיה של בקרת גישה מסוג MAC
כמו בכל דבר באבטחה, MAC הוא רק חתיכה מפאזל. יש ליישם MAC באופן נכון וראוי כדי להבטיח יעילות ביצירת סביבה מאובטחת. לדוגמא, אם לא קיימת מדיניות אבטחה ברורה, לא נעשות בדיקות רקע מקיפות לעובד, היפטרות נכונה ממדיה (דיסק קשיח, תקליטורים וכו.) – המערכת לא תהיה מאובטחת.
סוגים אחרים של בקרה זו כוללים:
תחת בקרת DAC, נוכל לבטא את מדיניות האבטחה כדלקמן: ישנם בעלים (A) , ישנו אובייקט (B) , וישנם משתמשים אחרים (C) . אז:
DAC הוא: "הבעלים (A), מחליט למי מבין שאר המשתמשים (C) , יש רמת גישה כלשהי לאובייקט (B)" .
דוגמאות ליישום DAC :
יישום הבקרה נעשה לעתים קרובות ע"י מטריצת גישה – Access Matrix . מטריצת גישה נותנת את היכולת להתאים גישת סובייקט לאובייקט – בעזרת העמודות ו\או השורות עליהן היא בנויה. מימוש בעזרת חלוקה לעמודות תיצור רשימות גישה, או ACL – Access control List.
יתרונות DAC :
חסרונות ה-DAC
RBAC התפתח כתכונה \ מאפיין מצוין לניהול מסד נתונים ומערכות הפעלה מרושתות. היתרון המובהק של בקרה זו הוא האפשרות של מנהלי המערכת להקצות משתמשים בודדים – לתפקידים. התפקיד הוא כלי זיהוי המזהה משתמשים לקבוצות, יכולות ודרישות. המשתמש יכול להשתייך לכמה תפקידים – ובכך להעניק רמה מתאימה של גישה – בהתאם לדרישות המשתמש – ולא יותר.
דוגמאות ליישום RBAC
אח"כ, נקצה הרשאות:
לסיכום, בפוסט זה הצגתי במבוא את נושא בקרות הגישה באבטחת מידע. זהו הבסיס לניהול מושכל של גישות. בין אם שמתם לב או לא, מדי יום אנו נתקלים בסוג כזה או אחר של בקרת גישה - בין אם זה כאשר אנחנו מזפזפים בממיר או מריצים אפליקציה בסמארטפון שלנו. בקרות גישה אינן בהכרח מונעות גישה, הן גם יכולות לזהות איומים ולתקן ליקויים שונים. כן, IDS, מצלמות במעגל סגור והצפנה - גם הן בקרות גישה - או יותר נכון, בקרות למדידת גישה. זה נושא בפני עצמו שאקווה לִגעת בו בפוסטים הבאים...
כל עקרון תופס מקום נפרד בסביבה המאובטחת – לכאורה. לדוגמא, מנהל א"מ יכול ליצור סביבה (סביבה יכולה להיות כל דבר המכיל מידע, כגון תוכנה, מערכת, מחשב, מקום...) בעלת רמה גבוהה מאוד של סודיות ושלמות בעוד שרמת(או עיקרון) הזמינות כמעט ולא נלקחת בחשבון. למרות שבסביבה זו – המידע הינו מוגן משינויים ומגישות לא מורשות – הוא גם יכול להיות לא זמין בעת שנצטרך לגשת אליו – דבר שלא בא בחשבון – בעיקר בגופים מסחריים.
סודיות הינו העיקרון המבטיח כי מידע מסוים לא יהיה נגיש למי שאין לו גישה אליו. רבים סבורים כי עקרון זה ממומש בעיקר בסביבות צבאיות, ממשלתיות. אך בד"כ, גם חברות מסחריות, בעיקר במאה ה-21 של זמננו – עושות שימוש בעקרון זה ע"מ להגן על הקניין הרוחני שלהם, נתוני מחקר, נתוני לקוחות ועוד. נושא הפרטיות, הגנת המידע וחקיקה היו גורם מניע לחשיבות (הגוברת) של עקרון הסודיות. בתחומים\מגזרים רבים כיום, עקרון זה אינו בגדר המלצה אם כי בגדר חובה – בהתאם לחוק.
שלמות הינו העיקרון המבטיח כי נתוני מידע כאלה או אחרים – לא שונו. הן בתעבורתם והן באחסונם. יש להבחין מתי דרישת העיקרון נחוצה ומתי פחות. לדוגמא, בעת הזרמת מדיה – מוזיקה, סרטים... אין דרישה לבקרת שלמות גבוהה – זאת משום שאם פאקט (צרור נתונים הנוצר כחלק מפעולת הכימוס בעת העברת נתונים) נופל, נעלם – הזרמת המדיה תמשיך ללא הפרעה מורגשת. חרף זאת, ארגונים פיננסיים כגון הבנקים, יראו בעיקרון זה מרכיב קריטי לאבטחת פעילותם, שכן חלילה בעת העברת סכום כסף, למשל, לא תתווסף ספרה ו\או כי סכום הכסף המיועד להעברה – לא שונה.
זמינות הינו העיקרון המבטיח כי מידע מסוים יהיה נגיש – עת שיהיה צורך לגשת אליו. זמן השבתה הינו זמן קריטי לחברות וארגונים שכן הוא גורר פגיעה בפעילות עסקית שותפת - הגוררת סיכון להפסד כספי.
בקרת גישה
- בקרת גישה, כשמה היא, מבקרת וקובעת "מי יכול לעשות מה" .
- מי הם הסובייקטים? מי רוצה לגשת?
- מי הם האובייקטים? למי\מה רוצים לגשת?
- בקרת גישה מכוונת להגן על:
- סודיות.
- שלמות.
- זמינות.
- בקרת גישה מכוונת לצמצום סיכון כזה או אחר;
- Risk = Threat x Vulnerability
אחריות בבקרת גישה
כמובן, כמו בכל תחום בחיינו, יש צורך בקביעת אחריות – מישהו\משהו המקבל החלטות ובזאת גם אחראי על השלכות ותוצאות הנגרמות ל-\מ-תחום אחריותו.
קיימים כ-שני תפקידי מפתח בתפעול בקרת גישה:
- בעל המידע: באנגלית Data Owner – הישות (אדם, תוכנה...) האוטוריטרית והאחראית למידע. בעל המידע קובע ומקבל החלטות.
- אחראי המידע: באנגלית Data Custodian – ישות המשתמשת בנתונים ברגע מסוים ולכן באופן זמני גם אחראית על אותם נתונים. לרוב, אחראי המידע מיישם את החלטות בעל המידע.
הנה כמה מושגי יסוד שיש לדעת כאשר מדברים על בקרות גישה:
- סובייקט, Subject – ACTIVE. סובייקט (נתין, בעברית) הינו המשתמש, התהליך או ההתקן המשמש כישות פעילה במודל בקרת הגישה. הסובייקטים הסטנדרטים במערכות הפעלה כגון NDS (Novell), Windows NT 4.0 ו- Active Directory במערכת Windows - מתחלקים ל-2 קבוצות עיקריות: מובנה או מותאם.
- סובייקטים מובנים (Built-In) יכולים להתקיים בכל מיני צורות ואופנים אך הם מוגדרים בעת פיתוח\תכנון מערכת ההפעלה.
- סובייקטים מותאמים User-defined נוצרים ע"י מנהל המערכת – באופן ידני.
- אובייקט – PASSIVE – הינו הישות הפאסיבית המכיל מידע. אובייקט יכול להיות קובץ, תיקייה, התקנים, פורטים (Ports) ועוד.
- חוקים – FILTERS – במערכת ההפעלה UNIX, החוקים הסטנדרטיים הם קריאה, כתיבה וביצוע Read/Write/Execute ובמערכות Windows Read/Write/Execute/No Access . במערכות הפעלה חדשות יותר, כגון Windows 2008, קיימים יותר מ-30 חוקים, הידועים יותר כהרשאות Permissions.
- התוויות – מהמילה תווית – Label. התוויה קובעת מהי רמת הרגישות של אובייקט. זהו אוסף חוקים הנקבע בתלות רמת הרגישות של האובייקט אל מול הסובייקט. מילה נרדפת בהקשר זה היא "רמת בטיחות". חשוב לדעת כי לא לכל בקרות הגישה קיימות התוויות. בנוסף, אין להתבלבל בין התוויה לבין הרשאה. התוויה מוגדרת כאוסף חוקים המתווספים לאוסף הקיים (להלן ההרשאה).
- מבוסס תפקידים, Role-Based.
- לעתים מוצג כטבלת\מטריצת הרשאות\גישות.
- מבוסס חוקים, Rule-Based .
- מבוסס רשומה, List-Based – שם נרדף לרשימות גישה, Access Control List.
- מבוסס "אסימון", Token-Based.
- מטריצת סיכונים, Risk Matrix .
בקרת גישה מבוססת חוקים או RSBAC מפקחת על פעולות המבוססות חוקים החלים על הסובייקט (זה שרוצה גישה) ביחס לאותו אובייקט אליו הוא רוצה לגשת. מודל זה מיושם במגוון מערכות הפעלה (כולל Linux) ומבוסס על מודל אבטחת מידע לה-פאדולה.
בקרת גישה מבוססת רשומה, פועלת ע"פ רשימה של סובייקטים(משתמשים) אל מול הרשאתם (Privilege) לכל אובייקט .
בקרת גישה מבוססת אסימונים פועלת ע"פ רשימה של אובייקטים והרשאות מתאימות לכל סובייקט (משתמש). אפשר להגיד כי זוהי בקרה הפוכה (באופן פעילותה) לבקרת גישה מבוסס רשומות.
מודל בקרת גישה מוגדר כתיאור פורמלי של מדיניות אבטחה. אבל מהי מדיניות אבטחה? מדיניות אבטחה מכילה את דרישות האבטחה או מתארת את הצעדים שיש לקחת ע"מ להשיג רמת אבטחה נדרשת.
סוגי בקרות גישה
בקרת גישה מנדטורית (כפויה) – Mandatory Access Control או MAC
- בקרת הגישה נשלטת ע"י המערכת. MAC דורשת עבודה רבה לתחזוקה וזאת משום שלכל הנתונים רמת רגישות מסוימת בעוד שלמשתמשים רמת סיווג אחרת – בהתאם לדרישת העסק\ארגון.
- כאמור, בקרת הגישה מבוססת על התווית רגישות וסיווג המידע.
- לכל ישות קיימת רמת גישה Access Level כאשר:
- ישות
- משתמשים.
- אובייקטים.
- רמת גישה
- סיווג – Classification .
- משתמש יכול לגשת לאובייקט רק אם הוא בעל רמת גישה מתאימה.
- הגישה נאכפת ע"י המערכת עצמה – ללא אפשרות ל-עוקפה.
 |
| מה בין MAC ל-DAC. תמונת קליפ-ארט. |
דוגמאות ליישום MAC
יתרונותיה של בקרת גישה מסוג MAC
- נשלטת ע"י המערכת עצמה ללא אפשרות ל-עוקפה.
- לא מושפעת משגיאות של המשתמש.
- בד"כ, מיושמת כדי למנוע דליפת מידע.
חסרונותיה של בקרת גישה מסוג MAC
כמו בכל דבר באבטחה, MAC הוא רק חתיכה מפאזל. יש ליישם MAC באופן נכון וראוי כדי להבטיח יעילות ביצירת סביבה מאובטחת. לדוגמא, אם לא קיימת מדיניות אבטחה ברורה, לא נעשות בדיקות רקע מקיפות לעובד, היפטרות נכונה ממדיה (דיסק קשיח, תקליטורים וכו.) – המערכת לא תהיה מאובטחת.
- MAC מגן על מדיה דיגיטלית בלבד.
- ישנן הנחות לפיהן מיישמים את בקרת ה-MAC:
- קיימת אמינות בין המשתמש\מנהל.
- משתמשים לא משתפים את חשבונותיהם או את גישתם לגורמים אחרים (שוב, אמינות היא מרכיב עיקרי).
- הגנה סביבתית-פיזית מיושמת כראוי.
בקרה מבוססת שיקול דעת – Discretionary Access Control או DAC
בבקרה מבוססת שיקול דעת, הסובייקט (משתמש) או הישות הם בעלי הרשות להקצות גישה לאובייקטים וכן להקצות את ההרשאות לאותו אובייקט.סוגים אחרים של בקרה זו כוללים:
- מכוון-משתמש – הקצאת משתמשים עם מגבלות כלשהן.
- מבוסס-זהות – התבססות ע"פ מס' מזהה (ID) הן של האובייקט והן של הסובייקט.
- היברידי – שילוב של השניים.
תחת בקרת DAC, נוכל לבטא את מדיניות האבטחה כדלקמן: ישנם בעלים (A) , ישנו אובייקט (B) , וישנם משתמשים אחרים (C) . אז:
DAC הוא: "הבעלים (A), מחליט למי מבין שאר המשתמשים (C) , יש רמת גישה כלשהי לאובייקט (B)" .
דוגמאות ליישום DAC :
- רוב מע' UNIX , מע' Windows ממשפחת NT – כולן משתמשות ב-DAC .
יישום הבקרה נעשה לעתים קרובות ע"י מטריצת גישה – Access Matrix . מטריצת גישה נותנת את היכולת להתאים גישת סובייקט לאובייקט – בעזרת העמודות ו\או השורות עליהן היא בנויה. מימוש בעזרת חלוקה לעמודות תיצור רשימות גישה, או ACL – Access control List.
קובץ X
|
משה
|
רינה
|
יוסי
|
|
R(Read only)
|
OWNER, RW(Read and Write)
|
יוסי
|
||
RW
|
R
|
R
|
R
|
ליאת
|
R
|
OWNER, RW
|
רינה
|
יתרונות DAC :
- נוח.
- קל לשימוש וגמיש (Flexible) .
- המשתמש מרגיש כי הוא נמצא בשליטה כלשהי.
- קל להבנה.
- מגדיר את המושג בעלות (Ownership) בבקרות גישה.
- מימוש ע"פ התאמה אישית.
חסרונות ה-DAC
- DAC נכשל בזיהוי בין משתמשים לבין תוכנות ו\או תהליכים.
- תהליכים פועלים בקבוצה אחרת מהקבוצה בה נמצא המשתמש המפעיל את התהליך – מה שנותן למשתמש את היכולת להריץ פקודות שרירותיות מחוץ לסמכותו.
- DAC תמיד ייושם בסביבה לוגית (תחת מעטפת של מע' הפעלה, לדוגמא).
- DAC כאמור, נתון לשיקול דעת בעל המשאב – שיקול הדעת יכול להיות מוטעה באופן שרירותי.
- כתוצאה מכך, אירועים לא רצויים יכולים להתרחש:
- המערכת תהיה "פתוחה" לכל תוכנה\קוד זדוני (סוסים טרויאנים, למשל).
- שגיאות יכולות לגרור הסלמת הרשאות - Escalation of Privilege .
- אין הגנה מפני שגיאות וטעויות של משתמשים.
בקרה ללא שיקול דעת – Non-Discretionary Access Control או NDAC
- בקרה המנוהלת באופן ריכוזי ובלבד שתעמוד מול מדיניות האבטחה בארגון.
- מבוססת-תפקיד: התבססות על תפקידי העובד\משתמש.
- מבוססת-משימות: התבססות על המשימות שהוקצו לאותו סובייקט.
בקרת גישה מבוססת תפקידים – RBAC
- RBAC, Role-Based Access Control. כן, רבאק.
- ללא שיקול דעת.
- סמכות מרכזית\ריכוזית.
- ניהוליות מבוססת בסיסי נתונים.
- ההרשאות ניתנות לכל תפקיד ותפקיד.
 |
| נלקח מ-identitysander |
RBAC התפתח כתכונה \ מאפיין מצוין לניהול מסד נתונים ומערכות הפעלה מרושתות. היתרון המובהק של בקרה זו הוא האפשרות של מנהלי המערכת להקצות משתמשים בודדים – לתפקידים. התפקיד הוא כלי זיהוי המזהה משתמשים לקבוצות, יכולות ודרישות. המשתמש יכול להשתייך לכמה תפקידים – ובכך להעניק רמה מתאימה של גישה – בהתאם לדרישות המשתמש – ולא יותר.
דוגמאות ליישום RBAC
- בסיסי נתונים.
- גישה לבקשות שאילתה.
- מוצרי מיקרוסופט למיניהם:
- מיקרוסופט מיישמת RBAC במוצריה ע"י יצירת תפקידים כגון Data Reader\Data Writer
עובד פיתוח
|
עובד מ. אנוש
|
מנהל רשת
|
|
X
|
X
|
X
|
יוסי
|
X
|
רינה
|
||
X
|
ליאת
|
||
X
|
X
|
משה
|
אח"כ, נקצה הרשאות:
קבצי פיתוח
|
עובדי החברה
|
משתמשי הרשת
|
|
R
|
R
|
OWNER, RW
|
מנהל רשת
|
RW
|
עובד משאבי אנוש
|
||
OWNER, RW
|
R
|
עובד פיתוח
|
לסיכום, בפוסט זה הצגתי במבוא את נושא בקרות הגישה באבטחת מידע. זהו הבסיס לניהול מושכל של גישות. בין אם שמתם לב או לא, מדי יום אנו נתקלים בסוג כזה או אחר של בקרת גישה - בין אם זה כאשר אנחנו מזפזפים בממיר או מריצים אפליקציה בסמארטפון שלנו. בקרות גישה אינן בהכרח מונעות גישה, הן גם יכולות לזהות איומים ולתקן ליקויים שונים. כן, IDS, מצלמות במעגל סגור והצפנה - גם הן בקרות גישה - או יותר נכון, בקרות למדידת גישה. זה נושא בפני עצמו שאקווה לִגעת בו בפוסטים הבאים...
