רוב הדואר יוצא מתיבות של עובדים
אם הארגון שולח בעיקר מ-Microsoft 365 או מ-Gmail, ההגנה מפני התחזות והניתוב לפי תפקיד עובדים מהענן בלי שום שרת. התקנה פנימית מוצדקת כשיש הרבה מערכות שולחות בתוך הרשת.
התקנה באתר הלקוח
ארגון שרוצה שכל המערכות השולחות שלו יתחברו לממסר אחד בתוך הרשת מקבל את שכבת הדואר של Brand My Inbox כהתקנה אצלו. ממסר ה-SMTP, הסיסמאות לכל מערכת, ניתוב הכתובות לפי תפקיד ויומן המסירה רצים על השרתים שלכם, וההודעה יוצאת דרך ספק שליחה שחותם עליה ב-DKIM בשם הדומיין. התיבות שהעובדים קוראים בהן נשארות בדיוק איפה שהן.
ההתקנה מתוכננת יחד עם צוות ה-IT ואבטחת המידע של הארגון
המסלול של הודעה
המערכות שכבר שולחות דואר אצלכם, מהמדפסת ועד מערכת ה-ERP, מתחברות לממסר פנימי אחד במקום שכל אחת תשלח לבד. משם ההודעה עוברת לספק שליחה שחותם עליה בשם הדומיין שלכם.
ענן או בתוך הרשת
אותה תוכנה. ההבדל הוא איפה הממסר והיומנים יושבים ומי מתחזק את השרת.
| נושא | בענן של Brand My Inbox | בתוך הארגון |
|---|---|---|
| איפה יושב הממסר | בתשתית שלנו באירופה | בשרתים או בענן הפרטי שלכם |
| מי חותם ב-DKIM | ספק השליחה, בשם הדומיין שלכם | ספק השליחה, בשם הדומיין שלכם. חתימה במפתח שהארגון מחזיק עוד לא בנויה |
| יומני מסירה וביקורת | אצלנו, עם ייצוא | במסד הנתונים שלכם |
| עדכוני גרסה | אוטומטיים | גרסה עם מספר, שאתם מחליטים מתי להתקין |
| זמן הקמה | דקות | שבועות, לפי תהליך האישור בארגון |
למה בתוך הרשת
בארגון גדול, הדואר שיוצא לא נשלח רק מתיבות של עובדים. חשבוניות יוצאות ממערכת הכספים, התראות ממערכות פנימיות, קודים חד פעמיים מהאפליקציה, ומסמכים סרוקים מהמדפסת. כל אחת מהן צריכה לשלוח בשם הדומיין של הארגון, וכל אחת שמשתמשת בשרת אחר בלי חתימה פוגעת במוניטין של הדומיין ופותחת פתח להתחזות.
ממסר שמותקן בתוך הרשת מרכז את כל השליחה הזו במקום אחד שהארגון שולט בו. לכל מערכת יש סיסמה ומכסה משלה, כל הודעה נרשמת ביומן ויוצאת חתומה ב-DKIM דרך ספק השליחה, ותקלה במערכת אחת לא חוסמת את השליחה של מערכת אחרת. צוות האבטחה רואה מי שלח, מה נשלח ולאן, מתוך מסד הנתונים שלכם.
את ההתקנה מתכננים יחד עם צוות ה-IT שלכם ובעברית, ומי מתקין ומי מתחזק נקבע בכל פרויקט. אם הארגון צריך חיבור שעוד לא קיים, למשל למערכת זהות פנימית או לכלי ניטור מסוים, כותבים אותו כחלק מהפרויקט ולא מבקשים מכם לשנות את התשתית.
בכנות
התקנה פנימית היא פרויקט שדורש תחזוקה. אלה המצבים שבהם השירות בענן יתאים לכם יותר.
אם הארגון שולח בעיקר מ-Microsoft 365 או מ-Gmail, ההגנה מפני התחזות והניתוב לפי תפקיד עובדים מהענן בלי שום שרת. התקנה פנימית מוצדקת כשיש הרבה מערכות שולחות בתוך הרשת.
ממסר דואר שנפל בלילה עוצר חשבוניות וקודי כניסה. בלי צוות שמנטר אותו, שירות בענן שמתוחזק על ידינו בטוח יותר.
להמשיך מכאן
מאות כתובות, מסך אחד, בלי פרויקט הגירה
איך מערכות שולחות מהדומיין שלכם בלי להגיע לספאם
שלוש הרשומות שקובעות מי רשאי לשלוח בשמכם
מה נשמר, איך מוצפן ומי ניגש
מערכת הדיוור, ה-SMS והסוכנים של EmailPro, על השרתים שלכם
כן. כל מערכת שיודעת לשלוח ב-SMTP עם סיסמה, כולל מדפסות, מערכות כספים ותוכנות ותיקות, מתחברת לממסר עם פרטי גישה משלה. מערכות חדשות יכולות להשתמש גם ב-API. בשלב האפיון עוברים על רשימת המערכות השולחות ומחליטים לכל אחת איזה חיבור מתאים לה.
היום ספק השליחה שהוקצה לדומיין, גם בהתקנה בתוך הארגון. הממסר הפנימי מעביר אליו את ההודעה, והוא חותם עליה ב-DKIM בשם הדומיין שלכם לפי הרשומה שפורסמה ב-DNS. מצב שבו הארגון מחזיק את המפתח בעצמו ושולח דרך שרת הדואר שלו עוד לא בנוי, וזה נאמר מראש בשלב האפיון.
ל-API של הדואר, לממסר ולאפליקציה יש הגדרת קונטיינר שנבנית ל-amd64 ול-arm64, ולכן הרכיבים יכולים לעלות על שרתי לינוקס בחדר המחשב, על מכונות וירטואליות או בחשבון הענן של הארגון. מסד הנתונים הוא PostgreSQL. גודל השרתים נקבע לפי מספר המערכות השולחות וכמות ההודעות ביום.
הם נשמרים במסד הנתונים שלכם. העברה אוטומטית שלהם למערכת ניטור חיצונית עוד לא בנויה, ואם צריך אותה היא נכתבת בפרויקט. כל הודעה מקבלת רשומה עם המערכת ששלחה אותה, הנמען, תוצאת המסירה וסיבת החזרה אם הייתה, כך שצוות התמיכה יודע למה חשבונית מסוימת לא הגיעה.
שיחת אפיון עם מי שבונה את המערכת, ובסופה רשימה כתובה של המערכות השולחות ושל מה שצריך להתקין.
לקבוע שיחת אפיון