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

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

מה נחשב תוכנה לא מורשית?

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

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

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

דוגמה למיפוי תוכנות לא מורשות: תרחיש ארגוני

נניח ארגון עם 420 עמדות Windows, 65 מחשבי macOS, מספר שרתים ויחידות עסקיות שעובדות גם מהבית. מערך ה-IT משתמש בכלי גילוי נכסים כגון Lansweeper, בפלטפורמת ניהול עמדות, ב-EDR ובנתוני זהויות מהספרייה הארגונית. במקביל, הרכש מחזיק קובץ זכויות שימוש, הזמנות רכש וחידושי מנוי.

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

לאחר איחוד הנתונים, התמונה עשויה להיראות כך:

| תוכנה או קטגוריה | היקף גילוי | סטטוס מול המדיניות | החלטה ראשונית | |---|---:|---|---| | כלי גישה מרחוק שאינו ברשימת המוצרים המאושרים | 18 עמדות | אין אישור אבטחה ואין בעלים עסקי | חסימה והסרה מבוקרת | | עורך PDF בגרסת ניסיון או רישיון אישי | 74 עמדות | קיים פתרון ארגוני חלופי | מעבר לפתרון המאושר או הסדרת רישוי | | כלי דחיסת קבצים בגרסה ישנה | 126 עמדות | גרסה מחוץ לתמיכה | עדכון או הסרה לפי צורך | | לקוח אחסון ענן אישי | 29 עמדות | עלול ליצור זליגת מידע | בירור שימוש והעברה לאחסון ארגוני | | הרחבת דפדפן לניהול סיסמאות | 41 משתמשים | אין ניהול מרכזי או מדיניות שיתוף | מעבר לכספת ארגונית מנוהלת |

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

כך בונים מאגר השוואה שאפשר לעבוד איתו

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

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

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

שאלות שמכריעות את הטיפול

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

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

מקורות נתונים שחייבים להצליב

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

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

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

מתהליך חד-פעמי לבקרת שינוי שוטפת

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

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

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

מתי נכון להסדיר רישוי במקום להסיר?

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

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

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