הרבה ארגונים ב-Microsoft 365 עדיין מעבירים את הדואר דרך שירות סינון חיצוני כמו Pineapp, לפני שהוא מגיע לתיבות. במקרים רבים הארגון כבר משלם על הגנת דואר של מיקרוסופט, כי Defender for Office 365 כלול ב-Business Premium וב-E5.
לאחרונה ליווינו לקוח שהתקשה לנהל את אבטחת הדואר שלו ב-Pineapp. כשחידוש הרישיונות התקרב, החלטנו יחד לעבור במלואו ל-Defender for Office 365. המעבר פישט את התפעול, חסך את עלות השירות החיצוני ונתן הגנה משולבת. כאן נתאר איך עשינו את זה, כדי שתוכלו ללכת בדרך דומה.
הבעיה: שתי מערכות לנהל ולשלם עליהן
שירותי סינון חיצוניים בדרך כלל עובדים טוב, אבל הם מוסיפים שלוש בעיות:
- מורכבות: שתי פלטפורמות, Microsoft 365 והשירות החיצוני, עם שני ממשקים ושני מקומות לחפש בהם מייל שלא הגיע.
- עלות: תשלום כפול, גם על Microsoft 365 וגם על השירות החיצוני.
- חוסר עקביות: שתי שיטות הגנה שונות יוצרות פערים וחוויית משתמש לא אחידה.
זה בדיוק היה המצב אצל הלקוח. צוות ה-IT התקשה לנהל כמה מערכות, והעלות של Pineapp הלכה וגדלה. במקביל כבר היינו באמצע הטמעה של Defender for Endpoint, ולכן היה טבעי להרחיב את אותה פלטפורמה גם להגנה על הדואר.
למה Defender for Office 365
- ניהול במקום אחד: כל אבטחת הדואר בפורטל Microsoft Defender, לצד ההגנה על תחנות הקצה והזהויות.
- חיסכון: ארגון עם Business Premium (שכולל Plan 1) או E5 (שכולל Plan 2) כבר משלם על Defender for Office 365.
- הגנה משולבת: Safe Links, Safe Attachments, הגנה מפני התחזות, ונתונים שמשותפים עם שאר מוצרי Defender.
עבדנו לפי מדריך המעבר של מיקרוסופט, שמחלק את התהליך לשלושה שלבים: הכנה, הקמה וקליטה.
1שלב ההכנה
- מיפוי ההגדרות ב-Pineapp. תיעדנו את כל הכללים, החריגים ורשימות ההיתר והחסימה. אחרי סיום השירות כבר אין גישה להגדרות האלה, אז זה הצעד הראשון.
- בדיקת ההגדרות ב-Microsoft 365. עברנו על ההגדרות הקיימות בטננט כדי לזהות תצורות מיותרות ולפשט את סביבת הדואר לפני המעבר.
- בדיקת שירותים ששולחים בשם הדומיין. ללקוח היו שני שירותים חיצוניים ששלחו מיילים בשם הדומיין שלו. וידאנו שרשומות ה-SPF, ה-DKIM וה-DMARC שלהם תקינות.
- ניתוב הדואר. כללי הניתוב ב-Pineapp היו מינימליים, כך שלא נדרשו שינויים משמעותיים.
- החלטה על חוויית המשתמש. הגדרנו יחד עם הלקוח מה קורה לספאם ולדיוור המוני: ספאם עובר להסגר (quarantine), ודיוור המוני (bulk) נכנס לתיקיית Junk Email.
2שלב ההקמה
- קבוצות פיילוט. יצרנו קבוצות של משתמשים לבדיקת Safe Attachments, Safe Links ומדיניות anti-spam, כדי לראות את ההשפעה על קבוצה קטנה לפני שמרחיבים לכל הארגון.
- שמירה על כלל ה-SCL=-1. השארנו בתוקף את כלל זרימת הדואר (mail flow rule) שמגדיר SCL=-1 להודעות שעברו דרך Pineapp. הכלל הזה מונע סינון כפול בזמן המעבר, ומאפשר לבדוק את ההגדרות החדשות בלי לפגוע במיילים של המשתמשים.
- ניתוח עם ORCA. הרצנו את ORCA (Office 365 Recommended Configuration Analyzer), מודול PowerShell שסורק את מדיניות Defender for Office 365 ומשווה אותה להמלצות של מיקרוסופט. הדוח שלו נתן לנו רשימת פערים מעשית.
- Safe Attachments ו-Safe Links. ב-Safe Attachments הפעלנו Dynamic Delivery, כך שגוף המייל נמסר קודם והקובץ המצורף מצטרף אחרי הסריקה. לקבוצות בסיכון גבוה, כמו ההנהלה, הגדרנו מדיניות מחמירה יותר. ב-Safe Links הפעלנו בדיקה של כל קישור ברגע הלחיצה, גם ב-Teams ובמסמכי Office.
- כוונון anti-spam. העברנו את רשימות ההיתר והחסימה מ-Pineapp, וכיוונו את סף ה-Bulk Complaint Level (BCL) כדי לטפל טוב יותר בדיוור שיווקי, בלי לסמן מיילים לגיטימיים כספאם.
- דיווח משתמשים. הפעלנו את כפתור Report המובנה ב-Outlook. הודעות שמשתמשים מדווחים עליהן מגיעות לצוות האבטחה בפורטל Defender, ועוזרות לכוונן את המסננים לאורך זמן.
3שלב הקליטה
- הדרכת צוות האבטחה. הדרכנו את הצוות על הכלים של Defender for Office 365, כמו Threat Explorer ו-Attack simulation training, כדי שיוכלו לחקור איומים ולהגיב אליהם בעצמם.
- כוונון ההגנה מפני התחזות. לפי משוב המשתמשים והמלצות ORCA, כיוונו את spoof intelligence ואת impersonation protection, כדי לאזן בין הגנה לבין התראות שווא.
- הרחבה הדרגתית. הרחבנו את הפיילוט בהדרגה לכל הארגון, ותיקנו את המדיניות תוך כדי לפי הדיווחים.
- סיום המעבר. כיבינו את כלל ה-SCL=-1, כך שכל הסינון עובר ל-Defender for Office 365, ועדכנו את רשומות ה-MX כך שיצביעו ישירות ל-Microsoft 365.
- connectors לשירותים חיצוניים. הגדרנו connectors לשירותים ששולחים מיילים בשם הדומיין של הלקוח, כדי שהדואר שלהם ימשיך להגיע כרגיל.
אתגרים ולקחים
- מדפסות וסורקים: מכשירים ששלחו מיילים דרך Pineapp הפסיקו לעבוד אחרי המעבר. הגדרנו connector ב-Microsoft 365 שמזהה את כתובת ה-IP של המשרד, כך שהמכשירים שולחים ישירות ל-Microsoft 365 בלי שרת SMTP חיצוני. כדאי למפות את כל המכשירים האלה כבר בשלב ההכנה.
- הגדרות שלא עוברות אחד לאחד: חלק מההגדרות ב-Pineapp לא תורגמו ישירות ל-Defender for Office 365, ונדרשו פתרונות חלופיים.
- הדרכת משתמשים: המשתמשים היו צריכים הסבר איך לשחרר מייל מההסגר ואיך לדווח על הודעה חשודה.
- התראות שווא: בהתחלה היו יותר התראות שווא מהצפוי. אחרי כוונון המדיניות הן ירדו משמעותית.
לסיכום
מעבר מ-Pineapp ל-Defender for Office 365 מפשט את הניהול, חוסך את העלות של שירות נוסף ומחבר את הגנת הדואר לשאר מוצרי האבטחה של מיקרוסופט. המפתח הוא לא למהר: למפות את ההגדרות, להריץ פיילוט עם כלל ה-SCL=-1, לכוונן עם ORCA, ורק בסוף להחליף את רשומות ה-MX.
ב-OnCloud אנחנו מלווים מעברים כאלה מקצה לקצה: מיפוי ההגדרות ב-Pineapp, פיילוט, כוונון המדיניות והחלפת רשומות ה-MX. חידוש הרישיון מתקרב?
צרו איתנו קשר