Enterprise Architecture: Authorization

קשה להגדיר מהי Enterprise Architecture, לרוב זוהי ארכיטקטורה של / ועבור ארגונים גדולים.

אחד מנושאי-הליבה שחוזר על עצמו ב Enterprise Architecture הם נושאי ה Authentication ו Authorization (בקיצור: A&A):

• Authentication - אימות הזהות של משתמש ("האם הוא מי שהוא טוען שהוא?")
• Authorization - כיצד שולטים בהרשאות מה המשתמש, לאחר שאימתנו את זהותו, יכול לעשות.

ישנם מעט Enterprise שלא כוללים A&A, למשל כמעט כל הגישות בווב יהיו על גבי HTTPS (הדורשת הזדהות) ולא HTTP.

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

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

הקדמה: המודל הנאיבי

ניהול המשתמשים הפשוט (והנאיבי) ביותר כולל טבלה בבסיס הנתונים של המשתמשים וססמותיהם. כשהמשתמש מתחבר למערכת עליו להקליד שם משתמש (כלומר: user id) וסיסמה ואז משווים את הפרטים למידע בטבלה. אם המידע נכון - שומרים את זהות המשתמש על ה session (באם זה server-side session, cookie וכו').
כמובן שכדאי שהססמאות יהיו "מגובבות" (hashed) ואולי גם "מטושטשות" (מה שנקרא salted [א]). נושא זה הוא תחום ה Authentication, אימות זהות המשתמש, נושא שאנני מתכוון לעסוק בו בפוסט זה.

עבור ה authorization, ניהול ההרשאות של כל משתמש, יוצרים טבלה נוספת "הרשאות" הכוללת user id, resource id, permission type (להזכיר: מימוש נאיבי לחלוטין). כל פעם שמשתמש ייגש למשאב, נבדוק בטבלה אם יש לו הרשאה לפעולה (למשל: read, write וכו') ואז נאפשר לו / נמנע ממנו את הפעולה.

ניתן לתאר את המודל הנאיבי באופן הבא:

מודל נאבי זה אינו scalable לניהול כאשר יש הרבה מאוד אובייקטים ו/או משתמשים. כדי שמודל Authorization "יעבוד כראוי" חשוב מאוד שיהיה נהיל (maintainable) ופשוט. מבחן בסיסי הוא לענות על שתי שאלות:

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

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

עוד בעיה של המודל הוא software scalability. הטבלה בבסיס הנתונים עלולה לצמוח במהירות. למשל: חשבו על שרת קבצים המאכסן כמיליון קבצים עבור כמה מאות משתמשים (תסריט סביר של חברה בינונית). אם עבור כל גישה לכל אובייקט נצטרך לסרוק טבלה של מיליוני שורות (אובייקטים x משתמשים) - אנחנו בבעיה.

יתרון של המודל שהוא בהחלט פשוט וקל להבנה - זוהי תכונת מפתח של המצופה ממודל Authorization.
למה אני חוזר ומדגיש נקודה זו? כי בסוף את ניהול ההרשאות עושים בני-אדם. מודל "מעולה מתמטית" שהמשתמשים לא מבינים  - שקול למודל גרוע. הנה 2 דוגמאות אופייניות:

1. משתמש א' מנסה להגדיר הרשאות למשתמש ב' - אך לא מצליח לעשות זאת. אחרי כמה ניסיונות הוא נשבר, בוחר את הקבוצה "Everyone" ומסמן כל checkbox שהוא רואה ב UI בכדי לאפשר למשתמש ב' את הגישה המיוחלת.
   התוצאה: המידע חשוף לכולם ואיננו מאובטח.
2. מנהל האבטחה / איש IT שאחראי על ההרשאות לא מצליח לעקוב למי יש גישה למה. עובדים עוברים תפקידים, עוזבים, מידע נוסף - אבל אין יכולת לעקוב אחרי מה שמתרחש. אין יכולת לאכוף חוקים אבטחה ארגוניים. מערכת האבטחה מסתמכת בעיקר על עובדים ללא הבנה בענייני אבטחה, שאבטחה היא בעיקר מעצור בשבילם "to get the job done".
   התוצאה: חוסר שליטה. לעתים מוסיפים מערכת אבטחה חיצונית שמגבילה את צעדי המשתמשים באופן דרקוני - בניסיונות להחזיר את השליטה.

מה הוא רואה: הכל, או כלום? 

מודל: Access Control List

בואו נתקדם מהמודל הנאיבי 2 צעדים קדימה:

1. ננהל את המשתמשים בקבוצות (בעזרת מערכת x.509/LDAP/Active Directory וכו') וננהל הרשאות לקבוצות, לא בודדים. התוצאה: הרבה פחות הרשאות לנהל.
2. נקבע היררכיה בין המשאבים, כך שאם נתנו הרשאה למודל אב - האובייקטים הבנים יורשים אותה (אלא אם הוגדר אחרת במפורש) - שוב: פחות משאבים לנהל עליהם הרשאות.

המודל יראה בערך כך:

מודל זה פישט משמעותית את כמות הרשומות ב"טבלת ההרשאות" ושיפר את ה scalability של הניהול: במקום עשרות משאבים / משתמשים, אנו יכולים כעת לנהל מאות. במידה ויש אחידות גבוהה של המשתמשים / משאבים - אולי אפילו אלפים.

מודל ה Access Control Lists (בקיצור: ACL) - מפשט את יכולת הניהול אפילו קצת יותר: הוא מאגד את ה Permissions לאובייקט אחד שנקרא ACL. נובעים מכך כמה יתרונות:

1. ה ACL הוא חלק מהמשאב. אם מזיזים את המשאב - ה ACL זז איתו, ואין צורך לנהל (ברמת הקוד) מעקב ושינויים בטבלת ההרשאות.
2. בגלל שה ACL הוא אובייקט יחיד, יש פחות רשומות לנהל (יותר software scalability) / ניתן לנהל cache יותר יעיל.

יתרונות אלו נראים קטנים - אך הם, בסופו של דבר, חשובים.

לאחר התוספות, המודל יראה כך:

היכן משתמשים במודל זה?

• מערכות קבצים כמו Windows NT או Unix
• IBM Tivoli, Cisco Network Infrastructure ומערכות Enterprise אחרות

כמובן שיש וריאציות מעט-שונות של המודל.

עקרון מוסכם כיום הוא שהרשאות חייבות להיות חיוביות (positive) בלבד - כלומר: "מה המשתמש יכול לעשות" ולא "מה המשתמש לא יכול לעשות". זאת, בכדי למנוע סיבוכיות / דו-משמעות של ההרשאות שניתנו. במערכת הקבצים של "חלונות" עברו על כלל זה - מה שמסבך מאוד את ניהול ההרשאות.

1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" - לא. מודל ה ACL שיפר את ה scalability של המודל הנאיבי, אך הוא עדיין נחשב מודל מאותגר-scalability מבחינת ניהול.
   ארגונים גדולים נוהגים לרכוש כלי ניתוח שסורקים את ה ACLs במערכות הקבצים, ומייצרות דוחות המקלים על ההבנה מה כל משתמש יכול לעשות.
2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" - פחות או יותר כן, כל עוד המשאבים מנוהלים היררכית בצורה הגיונית (מה שלעתים קרובות קורה).

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

מודל: Policy-Based Authorization

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

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

למשל: "לחשבוניות שנוצרו בשבוע האחרון יש הרשאות קריאה למשתמשים מסוג x, המתחברים מתוך הרשת הארגונית".

בהפשטה, המודל יכול להראות משהו כזה:

במודל זה יש וריאציות רבות יותר ממודלים אחרים.

היכן משתמשים במודל זה?

מודל זה מקובל בעולם ה Enterprise במערכות רבות, נפוץ גם בעולם אבטחה (דוגמה מאוד פשוטה: Firewall)

1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" - !Hell No: למרות שיש הרבה פחות חוקים (policies) מ Permission במודלים הקודמים - הם עכשיו מורכבים הרבה יותר ומסובכים למעקב. ליתר דיוק ניתן לומר שמודל זה עשוי להיות מוצלח במקרים מסוימים, במיוחד כאשר כללים בסיסיים יכולים לתאר אוסף גדול מאוד של מקרים, משאבים או משתמשים (למשל: "אסור לגשת ל port 1433 בלי רשות של רגע ודודלי").
   קל במודל להגדיר Policies באופנים שונים, ברמות הפשטה שונות, ובסגנון שונה שיקשה על ההבנה שלהן.
2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" - שוב, מאוד תלוי.

סה"כ, מודל ה PBA הוא שנוי במחלוקת לגבי היכולת שלו לפשט את ניהול ההרשאות במערכת ה Enterprise Scale.

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

מודל ה PBA יכול גם לסבול מבעיות software scalability קשות, כאשר מספר ה policies עולה. בחלק מהמערכות, "מקמפלים" את ה policies לאוטומט שיוכל לבצע את אימות ה policies בצורה יעילה יותר.

מודל ה Role-Based Authorization

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

מודל ה Role-Based Authorization (בקיצור: RBA) הוא מודל נוסף שמנסה לתאר את הארגון וצרכיו, ולא רק להיצמד למבנה המשאבים הטכני.

במודל ה RBA ממדלים Role ("תפקיד") כסט של מטלות (Tasks) לביצוע. אנשים שאמורים לבצע מטלות דומות, לרוב יהיו בתפקידים זהים או דומים. לאותם בעלי תפקידים דומים נותנים סט של הרשאות על משאבים.

בצורה הפשוטה ביותר ניתן לבטא את מודל ה RBA באופן הבא:

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

סמנטיקה: עצם כך שהקבוצה נקראת "Role" מעודדת את המשתמשים לייצר קבוצות ע"פ התפקידים הקיימים בארגון: { רופאים, אחיות, אחיות בכירות } או { קניין, קניין חוץ, מנהל חשבונות }. צורה זו עוזרת לארגן את המשתמשים בשפה/סמנטיקה מרכזית בארגון - שכולם מכירים ומבינים.

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

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

לגישה זו יש מספר תוצרים:

1. למשתמשים תהיה גישה למשאבים שהם לא זקוקים להם (כי עמיתים מקבילים להם היו זקוקים להם לעבודתם). כלומר: ההרשאות הן לא "מינימליות".
2. הרבה יותר קל ופשוט לנהל את ההרשאות:
1. אם ל"רופא" אחר יש הרשאה למשאב, מספיק שאוסיף אותך ל Role "רופא", כדי שתקבל "אותן הרשאות. "שכפול הרשאות" הוא פעולה דיי מסובכת עד בלתי-אפשרית במערכת שמנהלת הרשאות כ ACLs. 
2. כשעובדים מבצעים מעברי פרויקטים / תת-תפקיד, סיכוי גבוה שההרשאות שמוגדרות להם עכשיו - מספיקות. ==> תחזוקה קלה.
3. מכיוון שיש מעט קבוצות, והן מתמפות ל"שפה הטבעית של הארגון", למי שמגדיר את ההרשאות ברור הרבה יותר טוב למי הן מיועדות.
4. כאשר רוצים לבצע סקירה של המשאבים שזמינים לרופאים, קל מאוד לבדוק את ה Role של הרופאים ולראות מה זמין להם.

בואו נבחן את המודל:

1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" - כן. ה Role מוכר בארגון ויש הרבה נקודות התייחסות.
2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" - כן, ניתן לסקור את ה Role בקלות ולמצוא את כל המשאבים. סביר שהמשתמש מכיר את המשאבים כי הוא בעצמו חבר ב Role.

היכן ניתן למצוא את המודל?
שרתי ווב, JEE, Windows, .NET, מערכות שונות של SAP, Oracle, IBM ועוד.

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

הנה גרסה מעט יותר מורכבת של המודל (בכדי לסבר את העין):

כמובן שלמודל ה RBA יש גם כמה חסרונות:

1. המודל לא מספק שליטה במידע רגיש שאמור להיות זמין לקבוצה קטנה של אנשים. במקרים אלו מספקים מודל הרשאות נוסף (למשל: ACL למשאבים רבים - כמו קבצים, PBA למקרים רוחביים / מופשטים כמו Ethical Wall [ב]) על גבי קבוצה מסוימת של משאבים ב Role, כלומר: מגבילים חלק מהמשאבים המשויכים ל Role לתת קבוצה של ה Role.
2. מה קורה בארגון שבו אין בעלי תפקידים ברורים? ארגונים בהם מידע מוגש על בסיס "need to know"? - מודל ה RBA פשוט לא מתאים.

סיכום

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


שיהיה בהצלחה!

ליאור

---

[א] הנה הסבר מוצלח בנושא: https://crackstation.net/hashing-security.htm

[ב] המקרה בו 2 בעלי תפקידים לא מורשים לגשת למידע אחד של השני מסיבות אתיות. לדוגמא: משרד עו"ד שמייצג שתי חברות מתחרות בתיקים שונים. עדיין, אסור לעו"ד שמייצג את חברה א' למצוא מידע על החברה המתחרה ב'.