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