הרשאה שגויה אחת יכולה לעצור תהליך תפעולי שלם, לחשוף מידע רגיש או לאפשר שינוי נתונים שאין ממנו דרך פשוטה לחזור. לכן השאלה איך מתכננים הרשאות במערכת ארגונית אינה סעיף טכני שמוסיפים בסוף הפיתוח. זו החלטה ארכיטקטונית שמגדירה מי יכול לבצע פעולה, באיזה הקשר, על אילו נתונים, ואיך הארגון יישאר בשליטה גם כשהמערכת, הצוותים והתהליכים גדלים.
במערכת פנימית קטנה קל להתחיל עם שני סוגי משתמשים: מנהל ומשתמש. אבל כאשר נכנסים לתמונה צוותי מכירות, שירות, כספים, תפעול, מנהלי אזור, ספקים ולקוחות - מודל כזה הופך במהירות למסוכן או מגביל. תכנון נכון נועד לייצר מערכת אמינה, לא רק קוד שעובד בתרחיש הראשוני.
מתחילים מהפעולות העסקיות, לא מרשימת תפקידים
הטעות הנפוצה היא לפתוח טבלה של תפקידים ולהחליט מראש מי הוא "מנהל", "נציג" או "צופה". התפקידים עצמם משתנים בין ארגונים, ולעיתים גם בין מחלקות באותו ארגון. מה שנשאר יציב יותר הוא הפעולה העסקית.
בשלב האפיון יש למפות מה המשתמשים באמת עושים: פתיחת לקוח, צפייה בתיק, עדכון סטטוס, אישור הנחה, הקצאת משימה, ייצוא דוח, מחיקת רשומה, שינוי הגדרות או צפייה במידע פיננסי. עבור כל פעולה יש להגדיר את רמת הסיכון ואת תנאי הגישה.
לדוגמה, נציג שירות עשוי להיות מורשה לעדכן פנייה, אך לא למחוק אותה. מנהל צוות עשוי לראות את כלל הפניות של הצוות שלו, אך לא פניות של צוות אחר. מנהל כספים עשוי לאשר זיכוי מעל סכום מסוים, אך לא לשנות פרטי לקוח. ההבדל בין צפייה, יצירה, עדכון, אישור ומחיקה צריך להיות מפורש - לא הנחה שמסתתרת בקוד.
מפרידים בין זהות, תפקיד, הרשאה והיקף נתונים
כדי לבנות מודל שיחזיק לאורך זמן, חשוב להבחין בין ארבע שכבות שונות:
- זהות - המשתמש הספציפי שמתחבר למערכת, כולל אופן ההזדהות שלו ומצב החשבון.
- תפקיד - קבוצת אחריות עסקית, כגון נציג שירות, מנהל תפעול או מנהל מערכת.
- הרשאה - פעולה מוגדרת שהמערכת יודעת לאכוף, למשל `orders.approve` או `reports.export`.
- היקף נתונים - הגבול שבתוכו ההרשאה תקפה: הרשומות של המשתמש, של הצוות שלו, של יחידה עסקית מסוימת או של הארגון כולו.
ההפרדה הזו מונעת קיצורי דרך יקרים. תפקיד אינו בהכרח הרשאה, והרשאה אינה בהכרח זכות לראות את כל הנתונים. משתמש יכול להיות מורשה לעדכן הזמנות, אך רק הזמנות של אזור הפעילות שלו. בלי שכבת היקף, מתקבלת מערכת שבה משתמשים רואים הרבה יותר מידע ממה שנדרש להם כדי לעבוד.
במערכות מרובות לקוחות או יחידות עסקיות, ההיקף חייב לכלול גם בידוד ארגוני. אסור להסתמך על כך שהמסך מציג רק את הנתונים הרלוונטיים. הבקרה חייבת להתבצע גם בשכבת השרת ובשאילתות הנתונים עצמן.
עקרון ההרשאה המינימלית הוא כלל תפעולי
העיקרון פשוט: כל משתמש מקבל רק את הגישה הנדרשת לביצוע עבודתו. בפועל, היישום דורש שיקול דעת. הרשאות מצומצמות מדי יוצרות פקקים, פניות תמיכה ועקיפות ידניות. הרשאות רחבות מדי פוגעות בבקרה, בפרטיות וביכולת לחקור טעויות.
המטרה אינה להקשות על עובדים, אלא לבנות מסלול עבודה שבו הפעולה הנכונה זמינה למי שאחראי עליה. אם נציג צריך אישור מנהל לצורך פעולה חריגה, המערכת צריכה להעביר את הבקשה לאישור בצורה מובנית - ולא לגרום לו לבקש סיסמה, לשלוח קובץ באימייל או לעדכן נתונים מחוץ למערכת.
במקרים מסוימים נדרש מנגנון חריגים. למשל, מנהל אזורי יכול לקבל גישה זמנית לתיק של צוות אחר בעת היעדרות. זו יכולה להיות החלטה נכונה, כל עוד היא תחומה בזמן, מתועדת ונבדקת. הרשאה קבועה שניתנת כדי לפתור צורך חד-פעמי היא חוב תפעולי שמצטבר.
בונים מטריצת הרשאות לפני כתיבת מסכים
מטריצת הרשאות היא מסמך עבודה שמחבר בין תפקידים, פעולות, אובייקטים עסקיים והיקפי גישה. היא לא חייבת להיות מסובכת, אבל היא חייבת להיות מדויקת מספיק כדי שהפיתוח, הבדיקות והלקוח ידברו באותה שפה.
במקום לכתוב "מנהל יכול לנהל הזמנות", מפרקים את ההגדרה: האם הוא יכול לראות את כל ההזמנות? ליצור? לשנות לאחר אישור? לבטל? לייצא? להחזיר הזמנה לשלב קודם? האם אותן זכויות תקפות גם לגבי הזמנות שנסגרו או כאלה ששויכו למחלקה אחרת?
המסמך הזה חושף פערים כבר באפיון. לעיתים מתברר שאין בעל תפקיד ברור לאישור פעולה רגישה, או שתהליך עסקי בנוי על כך שכל עובד יכול לעקוף שלב. עדיף לפתור את השאלות האלה לפני שהן מתגלות בפרודקשן דרך תקלה או אירוע אבטחה.
לא כל הרשאה צריכה להיות תפקיד חדש
ככל שמוסיפים תפקידים ייחודיים, המערכת נעשית קשה יותר לתחזוקה. "מנהל מכירות צפון עם גישת דוחות חלקית", "נציג בכיר זמני" ו"מנהל שירות ללא ייצוא" עשויים להיראות כמו פתרונות מהירים, אך תוך זמן קצר נוצרת רשימה שאיש אינו מבין.
במקום זאת, כדאי להגדיר מספר תפקידים עסקיים יציבים ולהרכיב עבורם הרשאות. חריגים נקודתיים צריכים להיות מוגבלים, מתועדים ובעלי תוקף. כאשר החריג חוזר שוב ושוב, זה סימן שיש לעדכן את המודל ולא להמשיך להוסיף תיקונים ידניים.
אכיפה בצד השרת, לא רק בממשק
הסתרת כפתור אינה מנגנון הרשאות. היא משפרת את חוויית המשתמש, אבל אינה מונעת קריאה ישירה לממשק תכנותי, שינוי בקשה או שימוש במסך ישן. כל פעולה רגישה חייבת להיבדק בצד השרת לפני ביצועה.
הבדיקה צריכה לכלול גם את הפעולה וגם את האובייקט. לא מספיק לבדוק שלמשתמש יש הרשאה לעדכן לקוח. יש לבדוק שהוא רשאי לעדכן את הלקוח המסוים הזה, במצב הנתונים הנוכחי, ובהתאם לארגון או לצוות שאליו הוא שייך.
אותו עיקרון חל על אוטומציות ואינטגרציות. תהליך אוטומטי שמעדכן נתונים ממערכת אחרת זקוק לזהות שירות מוגדרת ולהרשאות מצומצמות משלו. שימוש בחשבון מנהל כללי עבור כל אינטגרציה הוא פתרון נוח בתחילת הדרך, אך הוא מקשה מאוד על אבחון תקלות ועל צמצום נזק במקרה של חשיפה.
מתכננים הרשאות גם סביב סטטוסים ותהליכי אישור
במערכות תפעוליות, ההרשאה לעיתים תלויה לא רק בזהות המשתמש אלא גם בשלב שבו נמצא התהליך. הזמנה במצב טיוטה אינה זהה להזמנה שאושרה, ופנייה פתוחה אינה זהה לפנייה שנסגרה.
לכן יש להגדיר מי רשאי להעביר רשומה בין סטטוסים, מי יכול להחזיר אותה לאחור, ומה קורה כאשר פעולה מתבצעת מחוץ לסדר הרגיל. תהליך אישור טוב אינו רק כפתור "אשר". הוא כולל בעלים ברורים, תנאים עסקיים, התראות, תיעוד החלטה וטיפול במקרים שבהם המאשר אינו זמין.
כאן יש גם החלטת מוצר: האם המערכת תחסום פעולה ללא אישור, או תאפשר המשך עבודה תוך סימון חריגה? במערכות כספיות או רגולטוריות לרוב נחוצה חסימה. בתהליכי שירות מהירים ייתכן שנכון לאפשר חריגה מתועדת כדי לא לפגוע בלקוח. אין תשובה אחת נכונה - יש התאמה לרמת הסיכון ולמחיר התפעולי של עיכוב.
תיעוד, בקרה ובדיקות הם חלק מהמודל
מערכת ארגונית צריכה לענות על שאלות פשוטות אך קריטיות: מי שינה את הנתון, מתי, מה היה הערך הקודם, מאיזו פעולה השינוי הגיע והאם בוצע תחת הרשאה חריגה. ללא יומן פעילות מסודר, קשה לחקור טעויות, לפתור מחלוקות ולשפר תהליכים.
יש להגדיר אילו פעולות מתועדות ברמת פירוט גבוהה במיוחד: שינוי הרשאות, מחיקה, ייצוא נתונים, עדכון פרטים פיננסיים, אישור חריגים ושינוי הגדרות מערכת. גם צפייה במידע רגיש יכולה לדרוש תיעוד, בהתאם לסוג הנתונים ולדרישות הארגון.
בדיקות הרשאות אינן מסתיימות בבדיקה ידנית של מסכים. נדרשות בדיקות שמוודאות שמשתמש ללא הרשאה אכן נחסם, שמשתמש בעל הרשאה מוגבל לנתונים שבתחומו, וששינוי תפקיד מעדכן את הגישה באופן צפוי. ככל שהמערכת מתרחבת, בדיקות אוטומטיות של תרחישי הרשאה הופכות להגנה ממשית מפני רגרסיות.
מי מנהל את ההרשאות לאחר ההשקה?
גם המודל המדויק ביותר ייכשל אם לא ברור מי מוסמך לשנות אותו. יש לקבוע מי פותח משתמשים חדשים, מי מאשר גישה חריגה, מי מסיר גישה בעת עזיבת עובד, ומי מבצע סקירה תקופתית של משתמשים פעילים והרשאות רגישות.
בארגונים קטנים, האחריות יכולה להיות אצל מנהל תפעול עם תהליך אישור ברור. בארגון גדול יותר ייתכן שתידרש הפרדה בין בקשת גישה, אישור עסקי וביצוע טכני. העיקר הוא להימנע ממצב שבו ההרשאות מנוהלות בהודעות פרטיות או על בסיס זיכרון של אדם אחד.
ב-DevCo מתייחסים למודל הרשאות כחלק מתכנון המוצר והתהליך, לא כתוספת אבטחה מאוחרת. ההחלטות הנכונות מתקבלות כאשר ממפים יחד את המשתמשים, הנתונים, החריגים ונקודות האישור - ואז מתרגמים אותם למנגנון שאפשר לפתח, לבדוק ולתחזק.
מערכת טובה אינה נמדדת רק במה שהיא מאפשרת לעובדים לעשות. היא נמדדת גם ביכולת שלה למנוע פעולה לא נכונה, להסביר מדוע נחסמה גישה, ולשמור על תפעול רציף כשהארגון משתנה.