Exchange Online Protection ותקנים נוספים

שירות EOP אינו מתחיל ונגמר בשירות עצמו ומסביב לשירות ישנם תקנים וטכנולוגיות נוספות שעמם EOP עובד ומבצע אינטגרציה מלאה וע”י כך נותן פתרון הגנה מתקדם ויעיל, כאשר מדובר על דואר אנו צריכים תמיד להיות מוכנים ומעודכנים כי למעשה “כל יום הוא יום חדש” של הגנה מפני ספאם, מאלוויר, פישינג וכאלה נוספים, ואם מזכירים פישינג אז במקרה של פישינג טכנולוגיה לבד לא פותרת את הבעיה (ועוד נגיע לנושא), ולכן שעובדים עם EOP צריך להבין שישנם רכיבים והגדרות נוספות שעמם אנו צריכים להגדיר, כגון: SPF, DKIM, Dmarc ועוד.

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

בואו נעבור בקצרה על היכולות הנ”ל ונבין למה הם יכולים לסייע בהגנה על הארגון.

Sender Policy Framework

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

• כתובת מול רשומת SPF (יותר נכון רשומת TXT)
• דומיין אשר שולח את הדואר
• פרטי נמען עם ערכים, כגון: Mail From

בשירות Exchange Online ניתן להגדיר רשומת TXT לטובת SPF וצריך לשים לב לתרחישים בהם ישנם מצב היברידי או גורם חיצוני שמבצע סינון למיילים (third party emsil ecurity).
כמו שירותי ענן אחרים כך גם בשירות Exchange Online ישנם מספר תקנים כגון HIPPA שמחייב הגדרת SPF מול הדומיין, בכל המקרים האלה ישנה אינפורמציה רבה לגבי הגדרת SPF מול הארגון.

בפורטל הארגוני של Office 365 בקטגוריית Domain ניתן לראות את הגדרות SPF

מבנה רשומת TXT של SPF בנויה משלושה חלקים:

• v=spf – ערך קבוע של גרסת SPF, כיום ישנה רק גרסה של spf1
• mx – סוג זיהוי השולח, במקרה שלנו מוגדר mx ולא ערכים אחרים
• all – מי רשאי לשלוח בשם הדומיין, ערך שניתן להגדרה עם מספר פרמטרים, כגון: ?,+ וכו’

בשירות Exchange Online הגנה על מיילים עם SPF מתבצעת לפי המנגנון הבא:

המנגנון של SPF בודק את ערך Mail from ומשווה אותו לכתובת IP של של הדומיין המפורסם מול רשומת TXT (של SPF), לאחר מכן ניתן להגדיר איך תטופל תעבורת דואר שמגיעה ממקור לא אמין.

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

איך מגדירים SPF

תהליך יצירת SPF הינו פשוט מאד ומצריך הגדרה ברמת שירות DNS (בספק DNS) מול הגדרות הדומיין הייעודי, בשירות Office 365 ישנם מדריכים וכלים שמסייעים בהגדרה של רשומת TXT.
בסיום הגדרת רשומת TXT הדומיין שלנו יהיה מוגדר עם מבנה SPF לפי הפלט הבא:

האם אני צריך בארגון SPF? כן, מומלץ מאד להגדיר SPF בארגון ולוודא תעבורת מיילים דומיין (טסט) שאינו אמין.

DKIM

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

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

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

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

מבנה כללי של DKIM

המבנה של DKIM בנוי ברשומות DNS, חתימות דיגיטליות וגורם חיצוני

רשומות DNS

בסביבת Exchange Online רשומות DNS תריכות להיות רשומות Cname
בסביבת On-Premise רשומות DNS צריכות להיות רשומות TXT

רשומות DNS נקבעות לפי הדומיין שרשום מול רשומת MX ועם ערכים מול selector

פרמטרים ברשומות

• v=DKIM1 – גרסת DKIM, כיום ישנה גרסה ראשונה בלבד
• k=rsa – סוג האלגוריתם שמוגדר לדומיין, בד”כ k=rsa הוא ברירת המחדל אך ניתן להשתמש בפרמטרים נוספים
• p= – המפתח הציבורי (מבוסס base64) אשר משויך לסוג האלגוריתם בפרמטר k

חתימות דיגיטליות

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

איך מגדירים

בכדי להגדיר DKIM בשירות Exchange Online צריך לבצע את הפעולות הבאות:

• הגדרת רשומות Cname של הדומיין שהוגדר מול רשומת MX
• להפעיל DKIM-signing בשירות Exchange Online

Dmarc

בשמו המלא נקרא Domain-based Message Authentication, Reporting and Conformance והוא תקן נוסף לזיהוי תעבורת דואר עם התמקדות בפישינג.
DMARC בודק הודעה שעברה בהצלחה מול SPF או DKIM ןלאחר מכן מבצע בדיקה מול שדות: Mail from וכן From,  במידה וישנו במייל בעיה שאינו תואם להגדרות DMARC המייל יוגדר כדואר זבל או פישינג ואינו יעבור את הלשב של EOP, במידה והמייל יהיה תקין בהתאם להגדרות DMARC המייל ימשיך הלאה לשירות Exchange Online.
מעבר לבדיקה שתקן DMARC מבצע בשירות EOP בנוסף נעשה דיווח לגבי מיילים ותעבורת דואר לא תקינה
בכדי לעבוד עם DMARC צריך להוסיף רשומת TXT בלבד ללא צורך בהגדרות נוספות ברמת שירות Office 365.

בשירות Exchange online נעשה שימוש נוסף עם ספק חיצוני Agari בכדי לשפר את הזיהוי של תעבורת דואר מול שירות הענן.

מבנה כללי של DMARC

• v=DMARC1 – גרסת התקן כרגע בגרסה ראשונה בלבד
• p= – פוליסי ברמת הדומיין, לדוגמא quarantine
• pct= – אחוז הודעות לסינון דואר
• rua= – דיווח לגבי פעולות לא תקינות

המלצות בסיסיות ליישום DMARC

• יישום וביצוע הגדרות SPF
• יישום וביצוע הגדרות DKIM
• פרסום רשומות מול תקן DMARC עם הגדרת פוליסי None
• ניתוח ובדיקת המידע שמתקבל
• שינוי פעולות מול DMARC בהתאם למידע שהתקבל
• שינוי הגדרת פוליסי מול Quarantine

סיכום

בימינו הגנה על דואר בארגון הוא לא דבר פשוט ולכן אנו צריכים לעבוד מול התקנים והטכנולוגיות השונות ולהתעדכן בשינויים שנעשים בתקנים אלה.
שירות Exchange Online יחד עם שירות EOP מאפשר לארגונים לקבל את היכולות המתקדמות להגנה על הדואר בארגון תוך כדי שימוש עם יכולות DKIM ויכולות DMARC.