פיתוח מערכת תפקידים והרשאות גישה באפליקציית מובייל

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

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

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

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

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

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

מה נותן גישה מנוהלת: אפקטים מדידים

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

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

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

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

שינוי גישה בלי גרסה חדשה של האפליקציה

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

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

גישות להפרדת תפקידים: היכן לשמור הרשאות

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

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

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

שלבי הטמעה: מניתוח תרחישים ועד מסירת נהלים

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

1. מיפוי פעולות באפליקציה. עוברים על המסכים ועל קריאות הרשת, ורושמים כל פעולה — מצפייה בכרטיס הזמנה ועד החלפת תעריף. התוצאה — טבלת «פעולה → משאב → בעלים»; היא הופכת למקור האמת היחיד, ופעולה שלא נכנסה אליה לא מחלחלת לתפקיד.

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

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

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

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

מה נשאר בפרויקט: מטריצת גישה, תוכניות ונהלים

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

• מטריצת «תפקיד — פעולה» — לכל פעולה מסומן מי מבצע אותה ועל אילו אובייקטים היא חלה. מקור אמת אחוד בפניות שנויות במחלוקת: רואים שהמגבלה הוטמעה בכוונה, ולא אבדה בעת שינוי.
• תיאור ירושת תפקידים — מאילו תפקידי בסיס מורכבים תפקידים משולבים (לדוגמה, מנהל אזורי = מנהל + דוחות של האזור שלו). משנים תפקיד בסיס — מבינים אצל מי עוד ההרשאות ישתנו.
• הגדרות בדיקות — היכן בדיוק מוחלטת הגישה: בשרת, באפליקציה או בשניהם, ולמה אי אפשר לראות בממשק הגנה.
• בדיקות אוטומטיות לגישה — סט בדיקות מסוג «תפקיד X לא יכול לבצע פעולה Y», שרץ בכל בנייה. הרחיבו תפקיד — הבדיקה תראה אם לא נפתחה גישה מיותרת.
• נוהל הענקה ושלילת גישה — מי מאשר, תוך כמה זמן הרשאות מופיעות בעת העברת עובד ונסגרות בעת פיטורים, והיכן נשמר תיעוד על השינוי.
• הוראות לצוות התמיכה — פניות טיפוסיות («אני לא רואה את המדור», «הנתונים נעלמו») ותשובות מוכנות, כדי לא להעביר כל פנייה לפיתוח.

מקרה בוחן: הענקת הרשאות הפסיקה להיות פעולה ידנית

מסלול השותפים של רשת המרפאות «גאראנט-מד» נשען על הנפקה ידנית של גישות: 9 תפקידים ו-60 תרחישים באפליקציה, אך הרשאות למדורים חדשים נרשמו ישירות בטבלת «משתמש — מסך». תפקיד למעבדת שותפים הורכב בהעתקה של רשומה שכנה, ולכן רופא מרשת אחת ראה את לוח הזמנים של אחרת. פניות לתמיכה בנושא גישות הגיעו בקצב של 8–10 בשבוע, וכל שינוי הרשאות המתין לשחרור בנייה חדשה.

מה שינו

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

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

מדידות לפני ואחרי

במקרה זה של הפרדת גישה, חלק הפעולות הידניות בהנפקה ירד מ-60% ל-5%: מקרים טיפוסיים כוסו בתבניות תפקידים. פניות לתמיכה הצטמצמו מ-8–10 ל-1–2 בשבוע, וזמן שחרור שינויי ההרשאות — מיומיים של אישורים לחצי שעה וללא גרסה חדשה של האפליקציה. יומן שינויי התפקידים נשאר חובה: מצבים שנויים במחלוקת מנותחים לפיו תוך דקות, ולא לפי התכתבות.

במה שונה תפקיד מהרשאת גישה?

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

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

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

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

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

ספקות טכניים: אינטגרציות, מטמון, מצב לא מקוון

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

איך האפליקציה יודעת על שינוי הרשאות אם המטמון מיושן?

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

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

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

כמה מהר נסגרת הגישה של עובד שפוטר?

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

בואו נדבר על המשימה: שלחו תיאור גישה — נחזור עם תוכנית

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

מה עוזר לזרז את תחילת הפרויקט:

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

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