מעקב אחר תוקף רישיונות סייבר ואבטחת מידע ברשת הארגונית

מעקב אחר תוקף רישיונות סייבר ואבטחת מידע ברשת הארגונית

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

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

למה תוקף רישיון הוא גם אירוע אבטחת מידע

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

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

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

מעקב אחר תוקף רישיונות סייבר ואבטחת מידע ברשת הארגונית

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

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

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

בנו לוח זמנים שאינו מתחיל שבוע לפני הפקיעה

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

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

מדדו שימוש, לא רק כמות שנרכשה

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

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

איפה נוצרים הפערים המסוכנים ביותר

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

יש ארבעה אזורים שכדאי לבחון באופן קבוע:

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

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

אוטומציה עוזרת, אבל לא מחליפה החלטה מקצועית

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

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

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

כך מייצרים תהליך שניתן לבקר ולתחזק

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

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

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


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