מעבר ל- Microsoft Defender עבור Office 365 - שלב 3: צירוף

• חל על:

  ✅ Microsoft Defender for Office 365 Plan 2

שלב 1: הכנה	שלב 2: הגדרה	שלב 3: הטמעה
		אתה נמצא כאן!

ברוך הבא לשלב 3: צירוף ההעברה שלך ל- Microsoft Defender עבור Office 365! שלב העברה זה כולל את השלבים הבאים:

1. התחל קליטת צוותי אבטחה
2. (אופציונלי) פטור ממשתמשי ניסיון מסינון על-ידי שירות ההגנה הקיים שלך
3. כוונון בינת התחזות
4. כוונון ההגנה על התחזות ובינת תיבת הדואר
5. שימוש בנתונים מהודעות שדווחו על-ידי משתמש כדי למדוד ולהתאים
6. (אופציונלי) הוספת משתמשים נוספים לנסיונו הראשוני וחזרה
7. הרחב את הגנת Microsoft 365 לכל המשתמשים ובטל את כלל זרימת הדואר SCL=-1
8. החלפת רשומות MX

שלב 1: התחלת קליטת צוותי האבטחה

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

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

אם הארגון שלך רכש Microsoft Defender עבור Office 365 תוכנית 2, עליו להתחיל להכיר תכונות כגון 'סייר האיומים', 'ציד מתקדם' ו'מקרים'. להדרכה רלוונטית, ראה https://aka.ms/mdoninja.

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

SIEM/SOAR

לקבלת מידע נוסף אודות שילוב עם ה- SIEM/SOAR שלך, עיין במאמרים הבאים:

• מבט כולל על ממשקי API של Microsoft Defender XDR
• זרימה של API
• API מתקדם לציד
• ממשקי API של אירועים

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

תפקידי RBAC

ההרשאות ב Defender עבור Office 365 מבוססות על בקרת גישה מבוססת תפקיד (RBAC) מוסברות בהרשאות בפורטל Microsoft Defender שלך. להלן הנקודות החשובות שעליך לזכור:

• Microsoft Entra אלה מעניקים הרשאות לכל עומסי העבודה ב- Microsoft 365. לדוגמה, אם אתה מוסיף משתמש למנהל האבטחה בפורטל Azure, יש לו הרשאות של מנהל אבטחה בכל מקום.
• דואר & תפקידי שיתוף פעולה ב- Microsoft Defender הפורטל מעניקים הרשאות לפורטל Microsoft Defender ול- פורטל התאימות של Microsoft Purview. לדוגמה, אם אתה מוסיף משתמש למנהל אבטחה בפורטל Microsoft Defender, יש לו גישת מנהל אבטחה רק בפורטל Microsoft Defender ובפורטל פורטל התאימות של Microsoft Purview.
• תכונות רבות בפורטל Microsoft Defender מבוססות על רכיבי cmdlet של Exchange Online PowerShell ולכן דורשות חברות בקבוצת תפקידים בתפקידים המתאימים (טכנית, קבוצות תפקידים) ב- Exchange Online (בפרט, לקבלת גישה ל- Exchange Online PowerShell המתאים רכיבי cmdlet).
• בפורטל & של Microsoft Defender יש תפקידי שיתוף פעולה של דואר אלקטרוני שאינם שוות ערך לתפקידי Microsoft Entra, וחשובים לפעולות אבטחה (לדוגמה, התפקיד תצוגה מקדימה ותפקיד חיפוש ו'נקה').

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

שלב 2: (אופציונלי) פטור ממשתמשי ניסיון מסינון על-ידי שירות ההגנה הקיים שלך

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

הערה

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

שלב 3: כוונון בינת התחזות

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

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

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

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

שלב 4: כוונון הגנת התחזות ובינת תיבת דואר

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

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

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

הערה

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

כוונון בינת תיבת הדואר

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

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

• במדיניות למניעת דיוג עם הגדרות ההגנה הרגילה, שנה את הערך של אם בינת תיבת הדואר מזהה משתמש מתחזה להעברת הודעה לתיקיות דואר הזבל של הנמענים.

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

כדי לשנות את המדיניות, ראה קביעת תצורה של מדיניות למניעת דיוג Defender עבור Office 365.

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

כוונון ההגנה על התחזות משתמש

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

בדוק את תובנות התחזות כדי לראות מה נחסם כניסיונות התחזות של משתמש.

כדי לשנות את המדיניות, ראה קביעת תצורה של מדיניות למניעת דיוג Defender עבור Office 365.

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

כוונון הגנת התחזות לתחום

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

בדוק את תובנות התחזות כדי לראות מה נחסם כניסיונות התחזות לתחום.

כדי לשנות את המדיניות, ראה קביעת תצורה של מדיניות למניעת דיוג Defender עבור Office 365.

עקוב אחר התוצאות ובצע את ההתאמות לפי הצורך.

שלב 5: שימוש בנתונים מהודעות שמשתמש דיווח עליהן כדי למדוד ולהתאים

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

השתמש בתכונות הבאות כדי לנטר את הגדרות ההגנה בהגדרות Defender עבור Office 365:

• הסגר
• Threat Explorer (Explorer)
• דוחות אבטחה של דואר אלקטרוני
• Defender עבור Office 365 דוחות
• תובנות זרימת דואר
• דוחות זרימת דואר

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

שלב 6: (אופציונלי) הוספת משתמשים נוספים לנסיון הניסיון וחזרה

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

• Microsoft 365 יוצר התראות כאשר הודעות דיוג ברמת מהימנות גבוהה מותרות על-ידי מדיניות ארגונית. כדי לזהות הודעות אלה, יש לך את האפשרויות הבאות:

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

  דווח על תוצאות חיוביות מוטעות ל- Microsoft בהקדם האפשרי באמצעות שליחות מנהל מערכת, והשתמש בתכונה 'רשימת התרה/ חסימה של דייר' כדי לקבוע את התצורה של עקיפות בטוחות עבור תוצאות חיוביות מוטעות אלה.

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

שלב 7: הרחב את הגנת Microsoft 365 לכל המשתמשים ובטל את כלל זרימת הדואר SCL=-1

בצע את השלבים בסעיף זה כאשר תהיה מוכן להחליף את רשומות ה- MX כך שלהצביע על Microsoft 365.

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

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

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

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

2. בטל את כלל זרימת הדואר SCL=-1 (באפשרותך לבטל אותו מבלי למחוק אותו).

3. ודא שהשינויים הקודמים ייכנסו לתוקף, Defender עבור Office 365 זמין כעת כראוי עבור כל המשתמשים. בשלב זה, כל תכונות ההגנה של Defender עבור Office 365 מותרות כעת לפעול על-פי דואר עבור כל הנמענים, אך שירות ההגנה הקיים כבר סרוק דואר זה.

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

שלב 8: החלפת רשומות MX

הערה

• בעת החלפת רשומת ה- MX עבור התחום שלך, ההפצה של השינויים ברחבי האינטרנט עשויה להימשך עד 48 שעות.
• אנו ממליצים להוריד את ערך ה- TTL של רשומות ה- DNS שלך כדי לאפשר תגובה מהירה יותר וחזרה למצב קודם אפשרי (במידת הצורך). באפשרותך לחזור לערך ה- TTL המקורי לאחר השלמת המעבר ומאומת.
• שקול להתחיל בשינוי תחומים הנמצאים בשימוש בתדירות נמוכה יותר. באפשרותך להשהות ולנטר לפני מעבר לתחום גדול יותר. עם זאת, גם אם תעשה זאת, עדיין עליך לוודא שכל המשתמשים והתחום מכוסים על-ידי פריטי מדיניות, מאחר תחומי SMTP משניים נפתרים לתחום ראשי לפני יישום המדיניות.
• רשומות MX מרובות עבור תחום יחיד יפעלו באופן טכני, דבר שיאפשר לך לפצל את הניתוב, בתנאי שפעלת בהתאם לכל ההנחיות במאמר זה. באופן ספציפי, עליך לוודא שמדיניות מוחלת על כל המשתמשים, שכלל זרימת הדואר SCL=-1 מוחל רק על דואר שעובר דרך שירות ההגנה הקיים שלך כמתואר בשלב ההתקנה 3: שמור או צור את כלל זרימת הדואר SCL=-1. עם זאת, תצורה זו מציגה אופן פעולה שגורם לפתרון בעיות להיות קשה הרבה יותר, ולכן איננו ממליצים עליו בדרך כלל, במיוחד לפרקי זמן מ הארך.
• לפני שתחליף את רשומות ה- MX שלך, ודא שההגדרות הבאות אינן זמינות במחבר הנכנס מתוך שירות ההגנה ל- Microsoft 365. בדרך כלל, למחבר תהיה אחת או יותר מההגדרות הבאות שתצורתן נקבעה:
  • ולדרוש את שם הנושא באישור שבו השותף משתמש כדי לבצע אימות מול Office 365 תואם לשם תחום זה (RestrictDomainsToCertificate)
  • דחה הודעות דואר אלקטרוני אם הן לא נשלחות מתוך טווח כתובות IP זה (RestrictDomainsToIPAddresses) אם סוג המחבר הוא שותף וכל אחת מהגדרות אלה מופעלת, כל מסירת הדואר לתחום שלך תיכשל לאחר החלפת רשומות ה- MX שלך. עליך להפוך הגדרות אלה ללא זמינות לפני שתמשיך. אם המחבר הוא מחבר מקומי המשמש לתצורה היברידית, אין צורך לשנות את המחבר המקומי. עם זאת, עדיין תוכל לבדוק את הנוכחות של מחבר שותף.
• אם שער הדואר הנוכחי שלך מספק גם אימות נמענים, מומלץ לבדוק שהתחום מוגדר כ'סמכותי' ב - Microsoft 365. פעולה זו עשויה למנוע הודעות החזרה מיותרות.

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

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

השלבים הבאים

ברכותינו! השלמת את ההעברה ל- Microsoft Defender עבור Office 365! מאחר שהעברת את השלבים במדריך העברה זה, הימים הראשונים שבהם דואר מועבר ישירות ל- Microsoft 365 אמורים להיות חלקים הרבה יותר.

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

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