Mail Relay, Secure Email Gateway וחיבור API לענן הדואר הם שלושה דברים שונים. בלבול ביניהם עלול להוביל לתצורה מורכבת שלא מוסיפה הגנה, או לגרום לארגון להאמין שכל הודעה נבדקת כאשר חלק מהתעבורה עוקף את הנתיב המתוכנן.
Mail Relay הוא תפקיד ניתוב: שרת מקבל הודעות SMTP ומעביר אותן ליעד הבא. הוא יכול לכלול סינון, אך עצם היותו Relay אינה הופכת אותו למוצר אבטחה. Secure Email Gateway מוסיף מנגנוני סינון ואכיפה, ואילו פתרון API מתחבר לפלטפורמת הענן ובוחן הודעות ואירועים דרך ממשקי השירות.
Mail Relay: קודם כול ניתוב
Relay משמש להעברת דואר בין מערכות, למשל מיישום ארגוני ל־Microsoft 365, בין סביבה מקומית לענן או דרך שירות צד שלישי. הוא יכול לאכוף TLS, כתובות מקור וכללי ניתוב. בתיעוד Connectors של Exchange Online מוסבר שחיבורים כאלה מאפשרים תעבורה מול שרת SMTP או ארגון שותף.
Relay פתוח שמאפשר לכל גורם לשלוח דואר דרכו הוא סיכון חמור, אך Relay מוגבל אינו בהכרח מסנן קישורים, קבצים או התחזות. צריך לבדוק אילו מנועים באמת מופעלים עליו, על אילו כיוונים ובאיזה שלב בזרימה.
Secure Email Gateway: סינון בנתיב הדואר
שער אבטחה ממוקם בדרך כלל לפני או אחרי שירות הדואר ומקבל תעבורה לפי רשומת MX או Connector. הוא יכול לנתח מוניטין שולח, קבצים, קישורים, ספאם, התחזות ומדיניות יציאה. היתרון הוא אכיפה בנתיב; החיסרון הוא מורכבות ניתוב, סיכון ללולאות והשפעה אפשרית על מנגנוני האימות.
ב־Microsoft 365, למשל, שירות Exchange Online Protection מספק סינון בסיסי, ו־Defender for Office 365 מוסיף שכבות כגון Safe Links ו־Safe Attachments בהתאם לרישוי ולמדיניות. שירות חיצוני אינו חובה לכל ארגון; הוא מוצדק כאשר הדרישות, הסיכונים או יכולות התגובה אינם מקבלים מענה מספק מהשכבות הקיימות.
הגנה מבוססת API
פתרונות API מתחברים ל־Microsoft 365 או Google Workspace ומנתחים הודעות, משתמשים ואירועים בתוך הפלטפורמה. הם יכולים לזהות הודעה גם לאחר המסירה ולהסיר אותה מתיבות נוספות, בלי לשנות בהכרח את רשומת ה־MX.
עם זאת, יש לבדוק את פער הזמן עד הסריקה, הרשאות האפליקציה, יכולת פעולה בדואר יוצא, טיפול בהודעות פנימיות ומגבלות ה־API. מוצר שאינו יושב בנתיב עשוי לפעול מאוחר יותר משער, בעוד שער עשוי שלא לראות פעילות פנימית מסוימת. לעיתים נדרש שילוב, ולעיתים שכבה אחת מספיקה.
SPF, DKIM ו־DMARC אינם "הגנת DNS"
- SPF מפרסם אילו מקורות מורשים לשלוח בשם דומיין.
- DKIM מוסיף חתימה קריפטוגרפית שמאפשרת לבדוק אם ההודעה שונתה ואם היא קשורה לדומיין החותם.
- DMARC בודק התאמה בין דומיין ה־From לבין SPF או DKIM ומאפשר לפרסם מדיניות ודוחות.
Google ממליצה להגדיר SPF, DKIM ו־DMARC, אך מנגנונים אלה אינם חוסמים כל פישינג ואינם מגנים על DNS כשלעצמו. תוקף יכול לשלוח מדומיין דומה או מחשבון לגיטימי שנפרץ. לכן אימות דומיין הוא בסיס חשוב, לא פתרון מלא.
טעויות תצורה נפוצות
- קבלת דואר ישירות לשירות הענן אף שה־MX מצביע לשער, בגלל Connector או כלל רחב מדי.
- הגדרת IP של השער כשולח אמין בלי לשמר את זהות המקור, כך שסינון הענן מאבד הקשר.
- לולאת ניתוב בין השער לענן.
- סריקה כפולה שפוגעת בחתימות DKIM או מוסיפה השהיה בלי ערך ברור.
- הרשאות API רחבות מהנדרש או אפליקציה ללא תהליך ביטול גישה.
- התעלמות מדואר פנימי, חשבונות שירות והודעות מיישומים.
Microsoft מתעדת Enhanced Filtering for Connectors לתרחישים שבהם שירות צד שלישי נמצא לפני Microsoft 365. מטרת ההגדרה היא לשמר מידע על מקור ההודעה כדי שמנגנוני הסינון בענן יוכלו להעריך אותה נכון.
איך בוחרים ארכיטקטורה
- ממפים זרימה: אינטרנט, שער, ענן, מערכות מקומיות, יישומים ודואר פנימי.
- מגדירים איומים: פישינג, BEC, קבצים, קישורים, דליפת מידע וחשבונות שנפרצו.
- בודקים כיסוי: נכנס, יוצא ופנימי; לפני מסירה ואחריה.
- מצמצמים הרשאות: Connector, IP, תעודות והרשאות API רק למה שנדרש.
- בודקים בפועל: מעקב Message Trace, כותרות, TLS, SPF/DKIM/DMARC ותרחישי כשל.
- מתרגלים תגובה: הסרת הודעה, איפוס חשבון, חסימת IOC ודיווח משתמשים.
שירותי M‑Challenge יכולים לסייע בתכנון ובבדיקת תצורה, אך אף מוצר אינו מבטיח חסימה מלאה. התוצאה תלויה בשילוב בין אימות דומיין, סינון, זהויות, MFA, הדרכת עובדים וניטור מתמשך.
סיכום
Mail Relay מנתב דואר; Secure Email Gateway מסנן ואוכף מדיניות בנתיב; פתרון API פועל דרך פלטפורמת הענן. הארגון צריך לבחור לפי ארכיטקטורה וסיכון, לא לפי הבטחה כללית ש"כל המיילים מוגנים". תרשים זרימה מדויק, הרשאות מצומצמות ובדיקות עקיפה חשובים יותר מהוספת שכבה ללא תכנון.
קרדיט תמונה: Padrinan / Pexels.
