איך בודקים תוקף רישיונות תוכנה בארגון שלך?

איך בודקים תוקף רישיונות תוכנה בארגון שלך?

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

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

איך בודקים תוקף רישיונות תוכנה בלי לנחש

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

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

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

התאימו את הבדיקה למודל הרישוי

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

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

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

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

בצעו התאמה בין רכש, הקצאה ושימוש

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

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

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

אל תבלבלו בין אי-שימוש לבין רישיון מיותר

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

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

הגדירו התראות לפני תאריך הפקיעה

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

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

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

בנו תהליך קבוע, לא מבצע חד-פעמי

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

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

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

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

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

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

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


זקוקים למידע נוסף? השאירו פרטים ונחזור אליכם!