הרגע שבו "משתמש וסיסמה" מפסיק להספיק
גרסה ראשונה של פלטפורמת מוצר נבנית כמעט תמיד סביב משתמש בודד: נרשמת, התחברת, אתה רואה את המכשירים שלך. ואז מגיע הלקוח העסקי הראשון ושואל: "אפשר שגם הטכנאי שלנו יראה את המכשירים, אבל בלי למחוק כלום? ושמנהל הסניף יראה רק את הסניף שלו?" — וכאן מתברר שניהול הרשאות בפלטפורמת מוצר הוא לא פיצ'ר קטן אלא שכבת יסוד. אם היא לא תוכננה נכון, הוספתה בדיעבד היא אחד השדרוגים הכואבים והיקרים בפיתוח תוכנה.
המודל הנכון: ארגון כיחידת היסוד
הטעות הנפוצה היא לקשור נתונים (מכשירים, מדידות, הגדרות) ישירות למשתמש. המודל הנכון מוסיף שכבה: ארגון (Organization / Tenant). כל הנתונים שייכים לארגון; משתמשים מקבלים חברות בארגון עם תפקיד. כך עובדים היום כל שירותי הענן הרציניים, וכך צריכה לעבוד גם פלטפורמת מוצר:
- ארגון — הלקוח: חברה, מוסד או משפחה. בעל המנוי, בעל הנתונים.
- משתמש — אדם עם כתובת מייל. יכול להיות חבר בכמה ארגונים (מתקין שמשרת עשרות לקוחות, למשל).
- תפקיד — מה מותר למשתמש בתוך הארגון.
- קבוצות/אתרים — חלוקה פנימית בארגון גדול: סניפים, קומות, קווי ייצור — עם הרשאות ברמת הקבוצה.
תפקידים: להתחיל פשוט
מערכת RBAC (הרשאות מבוססות תפקידים) עם שלושה-ארבעה תפקידים מכסה את רוב הצרכים בשלב הראשון:
- בעלים (Owner): הכול, כולל חיוב, מחיקת ארגון והעברת בעלות.
- מנהל (Admin): ניהול משתמשים ומכשירים, בלי חיוב.
- עורך/מפעיל (Operator): שליטה במכשירים, בלי ניהול משתמשים.
- צופה (Viewer): קריאה בלבד — תפקיד שחשוב הרבה יותר משנדמה: דשבורדים על מסך במפעל, אורחים, רואי חשבון.
הרשאות פר-שדה ופר-פעולה ("מותר לכבות אבל לא לשנות תזמון") — רק כשלקוח משלם מבקש. מה שכן חובה מהיום הראשון: כל בדיקת הרשאה נעשית בצד השרת. הסתרת כפתור באפליקציה אינה אבטחה — עיקרון שמורחב במאמר על אבטחת מידע במוצר מחובר.
הפרדת נתונים — הסעיף שאין בו פשרות
בפלטפורמה רב-ארגונית, דליפת נתונים בין ארגונים היא התקלה החמורה ביותר האפשרית — לקוח שרואה מכשיר של לקוח אחר לא יחזור, ובאירופה זו גם הפרת רגולציה, כמפורט במאמר על GDPR ופרטיות בנתוני מוצר מחובר. לכן מזהה הארגון חייב להיות חלק מכל שאילתה ומכל בדיקת API, רצוי ברמת תשתית (מסנן אוטומטי) ולא באחריות כל מתכנת בנפרד. וכתבו בדיקות אוטומטיות שמנסות במכוון לגשת לנתוני ארגון זר.
תהליכים שחייבים לעבוד חלק
- הזמנת משתמש: מנהל מזין מייל, המוזמן מקבל קישור ומצטרף עם התפקיד שהוגדר. בלי "תפתח חשבון ותגיד לי את השם".
- שיוך מכשירים לארגון: כבר בתהליך ההפעלה הראשוני — נושא שמתחבר לרישום מכשירים מאובטח בענן.
- עזיבת עובד: הסרה מהארגון מנתקת גישה מיידית — בלי למחוק את המשתמש עצמו ובלי לאבד היסטוריית פעולות.
- יומן ביקורת (Audit Log): מי עשה מה ומתי — כניסות, שינויי הרשאות, פקודות למכשירים. לקוחות B2B ישאלו על זה במכרז הראשון, וגם אתם תצטרכו אותו ביום שלקוח יטען "לא אנחנו כיבינו את המערכת".
- העברת בעלות: העסק נמכר, המנהל התחלף — חייב להיות תהליך מסודר להעברת תפקיד הבעלים בלי לערב את התמיכה שלכם בכל מקרה.
צעד אחד קדימה: מה ארגונים גדולים יבקשו
כשמגיעים ללקוחות אנטרפרייז אמיתיים, מופיעות דרישות מהמדרגה הבאה: התחברות דרך מערכת הזהויות הארגונית שלהם (SSO בתקני SAML או OIDC), ניהול משתמשים אוטומטי מול מערכת ה-IT, ומדיניות סיסמאות ואימות דו-שלבי כפויה. אין צורך לבנות את כל זה מראש — אבל מודל ארגונים נקי הוא מה שמאפשר להוסיף את זה בהמשך בלי לשכתב את המערכת, ולתמחר אותו כרכיב פרימיום בעסקה.
למה זה שווה את ההשקעה
מודל ארגונים נכון הוא מה שמאפשר למכור את אותה פלטפורמה גם למשתמש ביתי בודד וגם לרשת עם 200 סניפים — בלי שתי מערכות. הוא הבסיס לפורטל לקוחות בניהול עצמי ולדשבורד ניהול למוצר IoT, והוא ההבדל בין מוצר שנתקע בעולם הפרטי לבין פלטפורמה שסוגרת עסקאות ארגוניות. עוד בנושאי צד השרת — בעמוד פיתוח תוכנה ואפליקציה.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
