Authentication מול Authorization

הרעיון המרכזי

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

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

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

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

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

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

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

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

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

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

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

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

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

המודל שנריץ כאן מקבל זהות כנתון מוכן מראש. בדיקת סיסמה, כניסה לחשבון ויצירת סשן נמצאות מחוץ למודל. תפקידו הוא לחשב החלטת הרשאה תחת הנחות ברורות. כך אפשר לראות את ההפרדה בין הנתון ״זהות קיימת״ לבין ההחלטה. בהמשך נלמד איך שירות שומר קשר לזהות בין בקשות.

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

קריאה מודרכת

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

authorization-result.txt

1. זהות: חסרה; קבוצה: north; פעולה: read; קבוצת רשומה: north; תוצאה: חסרה זהות מאומתת.
2. זהות: netta; קבוצה: north; פעולה: read; קבוצת רשומה: north; תוצאה: קריאה מותרת.
3. זהות: netta; קבוצה: north; פעולה: read; קבוצת רשומה: south; תוצאה: הפעולה נדחתה לפי המדיניות.
4. זהות: netta; קבוצה: north; פעולה: approve; קבוצת רשומה: north; תוצאה: הפעולה נדחתה לפי המדיניות.

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

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

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

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

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

יישום מודרך

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