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

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

מדריך לרישוי Microsoft 365: מתחילים ממיפוי ולא מחבילה

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

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

במקביל, צריך לבדוק ארבעה נתונים לפני שמבקשים הצעת רישוי:

• כמה משתמשים פעילים באמת קיימים, ולא כמה משתמשים מופיעים במערכת ה-HR או ברשימת הדוא"ל.
• אילו עובדים זקוקים ליישומי Office מותקנים במחשב, ואילו מסתפקים בגרסאות ווב ומובייל.
• אילו מכשירים ארגוניים ואישיים מתחברים למשאבי החברה, ומה נדרש כדי לנהל אותם באמצעות Intune או MDM אחר.
• אילו בקרות אבטחה ותאימות כבר קיימות, ואילו יכולות חסרות מול מדיניות ה-CISO, מבדקים או דרישות לקוחות.

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

מסלולי Business, Enterprise ו-Frontline

Microsoft 365 Business Basic, Standard ו-Premium

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

Business Basic מספק בעיקר שירותי ענן: Exchange Online, Teams, OneDrive ו-SharePoint, לצד יישומי Office בגרסת ווב ומובייל. הוא יכול להתאים לעובדי שטח, משתמשים מזדמנים או תפקידים שבהם אין צורך ביישומי Office מלאים על תחנת העבודה.

Business Standard מוסיף יישומי Office להתקנה במחשב. זהו מסלול רלוונטי לעובדי משרד שעובדים באופן שוטף עם Excel, Outlook, PowerPoint וקבצים מקומיים, אך לא בהכרח זקוקים לניהול מתקדם של עמדת הקצה.

Business Premium הוא בדרך כלל נקודת הבדיקה החשובה ביותר בארגון שמחפש גם אבטחה וניהול. הוא כולל יכולות כגון Intune, Entra ID P1 והגנת Endpoint המתאימה לעסקים. בפועל, הוא מאפשר להחיל MFA, גישה מותנית, מדיניות תאימות למכשירים והקשחת עמדות קצה בצורה מרכזית יותר. אם ארגון משלם על כלי MDM נפרד אך אין לו מדיניות מכשירים עקבית, ייתכן שהמסלול הזה מצמצם פער תפעולי, לא רק מוסיף עוד רכיב לרשימת המנויים.

Microsoft 365 E3 ו-E5

בארגונים עם יותר מ-300 משתמשים, דרישות ניהול מורכבות או צורך ביכולות Enterprise, בוחנים לרוב את משפחת E. Microsoft 365 E3 מיועד לעובדי ידע שזקוקים לשילוב רחב של יישומי פרודוקטיביות, Windows Enterprise, ניהול מכשירים וזהויות ארגוניות.

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

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

רישיונות Frontline

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

אבטחה אינה תוספת שאפשר לדחות לרבעון הבא

לא מעט ארגונים מתחילים מרישוי דואר ו-Office, ורק לאחר אירוע פישינג או דרישת ביקורת בודקים MFA, Conditional Access, הצפנה, DLP או הגנת Endpoint. הגישה הזו מייצרת פער בין סביבת העבודה לבין רמת הבקרה שהארגון חושב שיש לו.

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

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

ניהול מחזור החיים של הרישיון

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

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

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

מה לבדוק לפני חידוש או מעבר מסלול

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

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

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

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