אימות דואר אלקטרוני ב- Microsoft 365

עצה

הידעת שתוכל לנסות את התכונות ב- Microsoft Defender XDR עבור Office 365 2 ללא תשלום? השתמש בגירסת הניסיון ל- 90 Defender עבור Office 365 במרכז Microsoft Defender של הפורטל. למד מי יכול להירשם ולתנאי ניסיון כאן.

כארגון Microsoft 365 עם תיבות דואר ב- Exchange Online, או ארגון Exchange Online Protection (EOP) עצמאי ללא תיבות דואר של Exchange Online, חשוב להגן על התקינות של הודעות דואר אלקטרוני משולחים בתחום שלך. הנמענים צריכים להיות בטוחים שהודעות משולחים בתחום שלך הגיעו באמת משולחים בתחום שלך.

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

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

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

כדי לקבוע תצורה של אימות דואר אלקטרוני עבור דואר שנשלח מארגונים של Microsoft 365 עם תיבות דואר ב- Exchange Online או בארגונים עצמאיים של Exchange Online Protection (EOP) ללא תיבות דואר של Exchange Online, עיין במאמרים הבאים:

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

שאר המאמר מסביר:

מדוע יש צורך באימות בדואר אלקטרוני באינטרנט

כברירת מחדל, דואר אלקטרוני מסוג Simple Mail Transfer Protocol (SMTP) באינטרנט אינו מבצע כל מאמץ לאמת ששולח ההודעה הוא מי שהוא טוען שהוא.

הודעת דואר אלקטרוני סטנדרטית מסוג SMTP מורכבת ממעטפה של הודעה ותוכן הודעה:

  • מעטפת ההודעה מכילה מידע לגבי שידור וקבלה של ההודעה בין שרתי SMTP. מעטפת ההודעה מתוארת ב- RFC 5321. הנמענים לעולם לא רואים את מעטפת ההודעה מכיוון שהיא נוצרה במהלך תהליך שידור ההודעה.
  • תוכן ההודעה מכיל שדות כותרת הודעה (הנקראים במשותף כותרת ההודעה) וגוף ההודעה. כותרת ההודעה מתוארת ב - RFC 5322.

עקב עיצוב זה, הודעה כוללת ערכי שולח מרובים:

  • כתובת MAIL FROM ( 5321.MailFrom המכונה גם כתובת, שולח P1 או שולח מעטפה) היא כתובת הדואר האלקטרוני שבה נעשה שימוש בהעברה של ההודעה בין שרתי דואר אלקטרוני של SMTP. כתובת זו מתועדת בדרך כלל בשדה הכותרת Return-Path בכותרת ההודעה (למרות ששרת הדואר האלקטרוני המשמש כמקור יכול להגדיר כתובת דואר אלקטרוני אחרת של נתיב החזרה). כתובת דואר אלקטרוני זו משמשת בדוחות אי-מסירה (נקראים גם הודעות אי-מסירה או הודעות החזרה).
  • כתובת 'מ' (5322.Fromהמכונה גם כתובת או שולח P2) היא כתובת הדואר האלקטרוני בשדה הכותרת 'מ', והיא כתובת הדואר האלקטרוני של השולח המוצגת ללקוחות דואר אלקטרוני.

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

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

בדוגמה זו:

  • שרת המקור של הדואר האלקטרוני מזהה את woodgrovebank.com לשרת הדואר האלקטרוני המהווה יעד tailspintoys.com בפקודה HELO.
  • נמען ההודעה הוא astobes@tailspintoys.com.
  • כתובת MAIL FROM במעטפת ההודעה (המשמשת להעברת ההודעה בין שרתי דואר אלקטרוני של SMTP) היא dubious@proseware.com.
  • כתובת 'מ' המוצגת בלקוח הדואר האלקטרוני של הנמען היא security@woodgrovebank.com.

למרות שהודעה זו חוקית בהתאם ל- SMTP, התחום של כתובת MAIL FROM (proseware.com) אינו תואם לתחום בכתובת 'מאת' (woodgrovebank.com). הודעה זו היא דוגמה קלאסית של התחזות, שבה המטרה עשויה להטעות את הנמען על-ידי הסתרת המקור האמיתי של ההודעה לשימוש בהתקפת דיוג.

ברור, דואר אלקטרוני מסוג SMTP זקוק לעזרה כדי לוודא ששולחי הודעות הם מי שהם טוענים שהם!

כיצד SPF, DKIM ו- DMARC פועלים יחד כדי לאמת שולחים של הודעות דואר אלקטרוני

סעיף זה מתאר מדוע דרושים לך SPF, DKIM ו- DMARC עבור תחומים באינטרנט.

  • SPF: כפי שמוסבר בהגדרת SPF לזיהוי מקורות דואר אלקטרוני חוקיים עבור תחום Microsoft 365 שלך, SPF משתמש ברשומת TXT ב- DNS כדי לזהות מקורות דואר חוקיים מהתחום MAIL FROM, ומה לעשות אם שרת הדואר האלקטרוני המהווה יעד מקבל דואר ממקור לא מוגדר (כשל קשיח' כדי לדחות את ההודעה; 'כשל רך' כדי לקבל ולסמן את ההודעה).

    בעיות SPF:

    • SPF מאמת מקורות עבור שולחים בתחום MAIL FROM בלבד. SPF אינו מחשיב את התחום בכתובת From או ביישור בין התחומים MAIL FROM ו- From:

      • תוקף יכול לשלוח דואר אלקטרוני המעביר אימות SPF (ערך שלילי מוטעה) על-ידי ביצוע השלבים הבאים:
        • רשום תחום (לדוגמה, proseware.com) והגדר SPF עבור התחום.
        • שלח דואר אלקטרוני ממקור חוקי עבור התחום הרשום, עם כתובות הדואר האלקטרוני מאת בתחום אחר (לדוגמה, woodgrovebank.com).
      • שירות דואר אלקטרוני חוקי השולח דואר בשם תחומים אחרים עשוי לשלוט בכתובת MAIL FROM. התחומים האחרים והתחום MAIL FROM אינם תואמים, כך שההודעות אינן יכולות לעבור אימות SPF (חיובי מוטעה).

    • SPF מתנתק לאחר שהודעות נתקלות בהעברת דואר אלקטרוני מבוססת-שרת המנתבת מחדש או ממסרת הודעות.

      • העברת דואר אלקטרוני מבוססת-שרת משנה את מקור ההודעה מהשרת המקורי לשרת ההעברה.
      • שרת ההעברה אינו מורשה לשלוח דואר מהתחום המקורי של MAIL FROM, ולכן ההודעה אינה יכולה לעבור אימות SPF (חיובי מוטעה).

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

  • DKIM: כפי שמוסבר בנושא הגדרת DKIM לחתימה על דואר מהתחום שלך ב- Microsoft 365, DKIM משתמש בתחום כדי להוסיף חתימה דיגיטלית לרכיבים חשובים של ההודעה (כולל כתובת 'מאת') ולאחסן את החתימה בכותרת ההודעה. שרת היעד מוודא שהרכיבים החתמו של ההודעה לא השתנו.

    כיצד DKIM עוזר ל- SPF: DKIM יכול לאמת הודעות ש- SPF נכשל. לדוגמה:

    • הודעות מתוך שירות אירוח דואר אלקטרוני שבו אותה כתובת MAIL FROM משמשת עבור דואר מ תחומים אחרים.
    • הודעות שנתקלות בהעברת דואר אלקטרוני מבוססת-שרת.

    מאחר שחתימה של DKIM בכותרת ההודעה אינה מושפעת או משתנה בתרחישים אלה, הודעות אלה מצליחות להעביר DKIM.

    בעיות DKIM: התחום שבו משתמש DKIM כדי לחתום על הודעה אינו צריך להתאים לתחום בכתובת 'מ' המוצגת אצל לקוחות דואר אלקטרוני.

    כמו SPF, תוקף יכול לשלוח דואר אלקטרוני המעביר אימות DKIM (ערך שלילי מוטעה) על-ידי ביצוע השלבים הבאים:

    • רשום תחום (לדוגמה, proseware.com) וקבע את תצורת DKIM עבור התחום.
    • שלח דואר אלקטרוני עם כתובות הדואר האלקטרוני מאת בתחום אחר (לדוגמה, woodgrovebank.com).

  • DMARC: כפי שמוסבר בהגדרת DMARC לאימות התחום כתובת מאת עבור שולחים ב- Microsoft 365, DMARC משתמש ב- SPF וב- DKIM כדי לבדוק יישור בין התחומים בכתובות MAIL FROM ו- From. DMARC מציין גם את הפעולה שמערכת הדואר האלקטרוני המהווה יעד אמורה לבצע בהודעות שנכשלות ב- DMARC, ומזהה לאן לשלוח תוצאות DMARC (גם לעבור וגם להיכשל).

    כיצד DMARC עוזר ל- SPF ול- DKIM: כפי שתואר קודם לכן, SPF לא מנסה להתאים את התחום בתחום MAIL FROM ובכתובות From. ל- DKIM לא אכפת אם התחום שחתם על ההודעה תואם לתחום בכתובת 'מ'.

    DMARC מטפל במחסורים אלה באמצעות SPF ו- DKIM כדי לאשר כי התחומים בכתובות MAIL FROM ו- From תואמים.

    בעיות DMARC: שירותים לגיטימיים ששינויי הודעות במעבר לפני SPF, DKIM, ולכן DMARC בודקת.

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

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

אימות דואר אלקטרוני נכנס עבור דואר שנשלח אל Microsoft 365

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

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

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

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

אימות מורכב

התוצאות של בדיקת האימות המפורשת של Microsoft 365 משולבות והן מאוחסנות באימות מורכב בעל ערך יחיד אוcompauth קצר. הערך compauth מוחתם בכותרת 'תוצאות אימות ' בכותרות ההודעה. הכותרת Authentication-Results משתמשת בתחביר הבא:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

ערכים אלה מוסברים בכותרת ההודעה של תוצאות אימות.

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

עצה

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

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

  • תרחיש: התחום ברשומת ה- SPF או בחתימה של DKIM אינו תואם לתחום בכתובת From.

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

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • תרחיש: לתחום fabrikam.com אין רשומות SPF, DKIM או DMARC.

  • תוצאה: הודעות משולחים בתחום fabrikam.com עלולות להיכשל באימות מורכב:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • תרחיש: fabrikam.com כולל רשומת SPF ולא רשומת DKIM. התחומים בכתובות MAIL FROM ו- From תואמים.

  • תוצאה: ההודעה יכולה להעביר אימות מורכב, מכיוון שהתחום שהעביר SPF תואם לתחום בכתובת 'מ':

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • תרחיש: fabrikam.com יש רשומת DKIM ללא רשומת SPF. התחום ש- DKIM חתם על ההודעה תואם לתחום בכתובת 'מ'.

  • תוצאה: ההודעה יכולה להעביר אימות מורכב, מכיוון שהתחום בחתימה של DKIM תואם לתחום בכתובת 'מ':

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • תרחיש: התחום ברשומת ה- SPF או בחתימה של DKIM אינו תואם לתחום בכתובת From.

  • תוצאה: ההודעה עלולה להיכשל באימות מורכב:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

כיצד להימנע מכשלים באימות דואר אלקטרוני בעת שליחת דואר אל Microsoft 365

עצה

לקוחות Microsoft 365 יכולים להשתמש בשיטות הבאות כדי לאפשר הודעות משולחים המזוהים ככשלים של התחזות או אימות:

  • קביעת תצורה של רשומות SPF, DKIM ו- DMARC עבור התחומים שלך: השתמש בפרטי התצורה המסופקים על-ידי רשם התחומים או שירות אירוח ה- DNS שלך. יש גם חברות של ספקים חיצוניים המוקדשות לסייע בהגדדרת רשומות אימות דואר אלקטרוני.

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

    1. התחל על-ידי פרסום רשומת SPF המכילה את כל מקורות הדואר האלקטרוני שאתה מכיר (במיוחד היכן ממוקמת תעבורת החברה שלך), והשתמש בערך כלל האכיפה "כשל רך" (~all). לדוגמה:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

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

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

      • שרתי דואר אלקטרוני מקומיים.
      • דואר אלקטרוני שנשלח מספק תוכנה כשירות (SaaS).
      • דואר אלקטרוני שנשלח מתוך שירות אירוח ענן (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services וכן הלאה).

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

    3. הגדר את DKIM כדי להוסיף חתימה דיגיטלית להודעות.

    4. הגדר את DMARC כדי לאמת כי התחומים בכתובות MAIL FROM ו- From תואמים, כדי לציין מה לעשות עם הודעות הנכשלות בבדיקת DMARC (דחה או העבר), ולזהות שירותי דיווח לניטור תוצאות DMARC.

    5. אם אתה משתמש בשולחים בצובר כדי לשלוח דואר אלקטרוני בשמך, ודא שהתחום בכתובת 'מ' תואם לתחום שעובר SPF או DMARC.

  • אתה מארח דואר אלקטרוני של תחום או מספק תשתית אירוח ה יכולה לשלוח דואר אלקטרוני:

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

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