או – איך נותנים לכל משתמש בדיוק את מה שהוא צריך?
(7 דקות קריאה)

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

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

אילו פתרונות קיימים?

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

בנוסף, פתרון ההפרדה כלל לא רלוונטי במערכות הכוללות תוכן רגיש כמו מידע פיננסי או מודיעיני וכן במערכות הכוללות תהליכי עבודה הירארכיים (Hierarchical Workflows) כמו אישור של פוסטים לפני שהם נשלחים לפרסום.

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

3 מודלים של הקצאת הרשאות

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

Access Control List (ACL)

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

Role Based Access Control (RBAC)

• זהו המודל הנפוץ ביותר. במודל זה מנהל המערכת מקצה הרשאות ברמת התפקיד.
• תנאי מקדים להקצאת ההרשאות במודל זה הוא קיומה של רשימת תפקידים (Roles), שלכל אחד מהם שם ייחודי ואוסף הרשאות. לדוגמה, ב-WordPress כל משתמש שהוגדר כ-Subscriber יכול להזדהות במערכת, לעדכן את פרופיל המשתמש שלו, לשנות לעצמו את הסיסמה, לקרוא פוסטים ולהוסיף הערות. משתמשת שקיבלה את התפקיד Contributor תוכל גם להוסיף פוסטים חדשים (אבל לא לפרסם אותם) ולערוך את הפוסטים של עצמה. עוד על roles ב-WordPress

Rule Based Access Control (RAC)

• בניגוד למערכת מבוססת Roles, המאפשרת להקצות הרשאות על סמך מאפייני המשתמש, מערכת מבוססת Rules תאפשר הקצאת הרשאות על סמך מאפיינים חיצוניים למשתמש, כמו מידת הרגישות של מסמך (למשל במערכות מודיעיניות או דיפלומטיות), הזמן ביום, מיקום המשתמש או סוג ה-Device שלו.
• מערכות רבות משלבות בין המודלים. דמיינו חדר כושר המאפשר כניסה למתאמנים באמצעות כרטיס מגנטי בין השעות שש בבוקר לעשר בערב (Rule Based), בעוד שעובדי חדר הכושר יכולים להיכנס לחדר הצוות ללא קשר לשעה ביום (Role Based). עוד על Rule based access control

ישנם מודלים נוספים עם שמות אקזוטיים כמו Break-the-Glass Access Control ואפילו Emotion Based Access Control אך הם הרבה יותר נדירים. תוכלו לקרוא עליהם כאן.

Case Studies

בואו נראה כמה דוגמאות של הקצאת הרשאות במערכות מורכבות:

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

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

ועוד קצת…
עבור חברה העוסקת באבטחת בסיסי נתונים התבקשנו לאפיין פתרון שיאפשר ל-admin לא רק להוסיף roles ולהקצות הרשאות אלא גם לאפשר לכל משתמש גישה לאוסף מסוים של אובייקטים.
לדוגמה, אם ג'ני היא עובדת בחברה בינלאומית כאחראית על בסיסי הנתונים של החברה במזרח אסיה, מנהל המערכת יכול להקצות לה את ה-role המתקדם ביותר אבל להגביל את האובייקטים עליהם היא יכולה לפעול לאזור זה בלבד. תהליך הקצאת ההרשאות במערכת זו כולל שלושה שלבים: א. הגדרה של אוספי האובייקטים (assets); ב. הגדרה של אוספי ההרשאות (roles); ו-ג. עבור כל משתמש הקצאה של role ו-asset אחד או יותר. במקרה זה ההחלטה לוותר על התלות בין assets ו-roles נתנה למנהל המערכת גמישות מקסימלית.

לסיכום

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

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

רוצים עוד?

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

נותרו מקומות אחרונים בלבד. הרשמו עכשיו