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

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

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

מהו רישוי צף לעומת רישוי לפי משתמש?

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

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

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

איך המנגנון עובד בפועל?

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

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

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

לא כל "רישיון צף" נמדד באותה צורה

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

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

מתי רישוי צף באמת חוסך כסף?

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

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

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

סיכוני תאימות ואבטחה שלא כדאי לפספס

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

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

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

שאלות שחייבים להפנות ליצרן או לספק

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

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

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

כך בונים החלטה על בסיס נתונים

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

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

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

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