Skip to main content
שלחו עמוד זה לצוות ה-IT שלכם לפני ההטמעה. העמוד מרכז במקום אחד את יעדי האינטרנט, שולחי הדוא”ל, כתובות ה-IP של המקור ודרישות ההעלאה והאינטגרציה האופציונליות. מוצרי אבטחה מסוימים מכנים allowlisting בשם whitelisting או safelisting.

התחילו ברשימה הקצרה

גישה לאינטרנט: HTTPS / TCP 443. בסביבות רבות, שני תווי הגנריות (wildcards) של Living Security יחד עם מארחי התוכן החיצוניים ומארחי נכסי הכניסה המפורטים להלן מכסים את גישת העובדים. שרתי תוכן הלקוח, ההעלאות ו-Contentful נמצאים מחוץ לתווים הכלליים (wildcards) של Living Security. שרתי תוכן הלקוח וההעלאות משתמשים ב-livingsecurity-content-cdn.ai, דומיין נפרד מ-livingsecurity.ai. אפשרו גם את static.descope.com ואת descopecdn.com עבור נכסי כניסה מוטמעים בלבד; בקשות הכניסה משתמשות ב-auth.livingsecurity.ai. אם אתם משתמשים רק ב-*.livingsecurity.ai, הוסיפו את platform-cdn.livingsecurity.com ואת שאר מארחי התוכן של .com המפורטים להלן.
טבלאות שמות המארחים המפורטות מיועדות לצוותי IT שאינם יכולים להשתמש ב-wildcards; הן אינן מחייבות כללים כפולים. בדקו אם ה-wildcard בשער שלכם תואם שמות מקוננים כגון api.eu-west-1.livingsecurity.ai. ייתכן ש-wildcard אינו כולל את הדומיין החשוף. השתמשו בשמות מארחים עבור יעדי אינטרנט, מכיוון שכתובות ה-IP שלהם עשויות להשתנות.
השלימו גם את כללי הדוא”ל שלהלן. מחברי תוכן זקוקים גם ליעדי ההעלאה. אינטגרציות עם הגבלות על כתובות IP של מקור זקוקות לכללים במערכות המחוברות. הרשומות הסטנדרטיות מופיעות בעמוד זה; המדריכים המקושרים כוללים הוראות הגדרה.

מסירת דוא”ל

דוא”ל אימות

החילו רשומות אלה על דוא”ל כניסה בשירות ההגנה על הדואר שלכם. ודאו שההודעות מגיעות לפני שפג תוקף הקישורים שלהן. התראות משתמשות באותן כתובות IP; סימולציות משתמשות בטווחים נפרדים המפורטים להלן. ראו Enterprise Identity.

דוא”ל פלטפורמה טרנזקציוני

אותן שתי כתובות IP שולחות המפורטות לעיל שולחות גם התראות פלטפורמה הן בארה”ב והן באיחוד האירופי. אפשרו את כתובות From הבאות ואת דומיין ה-return-path המאומת: אלה כוללות הודעות פתיחה, הקצאות הדרכה, תזכורות והתראות נוספות. השאירו את אימות SPF,‏ DKIM ו-DMARC מופעל. SMTP של סימולציות משתמש בטווחים משלו המפורטים להלן. אם שרת ה-SMTP relay שלכם מגביל חיבורים לפי כתובת IP של מקור, בקשו מהתמיכה את כתובות ה-IP של מקור חיבור ה-SMTP של Living Security עבור האזור שלכם לפני הגדרת ה-relay. כתובות אלה מזהות את החיבור אל ה-relay שלכם, בנפרד מכתובות ה-IP השולחות של ה-relay עצמו. אל תחליפו אותן בכתובות ה-IP של הדואר המנוהל על ידי הפלטפורמה לעיל או בכתובות ה-IP של ממשק ה-API של האינטגרציות להלן.

סימולציות פישינג

עבור SMTP המנוהל על ידי הפלטפורמה, השתמשו באזור הארגון שלכם: אפשרו את טווח ה-IP המלא עבור האזור שלכם. השתמשו בדומיין אימות הדוא”ל עבור כללי שער הדורשים זאת. כתובת From הגלויה משתנה בין סימולציות; השתמשו בחבילת ה-allowlist העדכנית עבור הסימולציות שבחרתם. לפני ההשקה, קבלו את החבילה הייעודית לארגון שלכם דרך הגדרות → סימולציית דיוג → Allowlisting → Export allowlist package, או בקשו אותה ממנהל הצלחת הלקוח שלכם לפני שתהיה לכם גישה. היא כוללת דומיינים שולחים מופעלים, מארחי דפי נחיתה/URL, וכן את דומיין Reply-To הנפרד. אם השער שלכם דורש כתובות מלאות, עיינו בכתובות From בפועל עבור הסימולציות שבחרתם. הורידו חבילה מעודכנת כאשר הגדרות הסימולציה שלכם משתנות. מסירה ישירה (DMI) משתמשת באינטגרציית Microsoft 365 או Google Workspace המחוברת שלכם; טווחי המקור של SMTP אינם חלים על נתיב מסירה זה. Google Workspace מציבה הודעות בכל תיבת דואר נכנס מבלי לשלוח דוא”ל. Microsoft 365 שולחת דוא”ל אמיתי מתיבת הדואר של הסימולציה שלכם, ולכן מסנני Microsoft 365 שלכם עדיין חלים עליו. גישה ל-URL, הסכמת הספק ובדיקת תיבת הדואר הנכנס עדיין חשובות. פעלו לפי השלבים הייעודיים לספק ב-הגדרות סימולציה, כולל בקרות הסימולציה של Microsoft Defender כאשר הדבר רלוונטי.

גישה ליישום ול-API

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

דרישות כניסה

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

תוכן, רשתות CDN והעלאות לקוח

אפשרו מארחים אלה עבור מנהלי מערכת המציגים תצוגה מקדימה של תוכן ועובדים הצורכים אותו. ייתכן שהגנת תמונות בדוא”ל תזדקק אף היא לגישה למארחי תמונות. מארחי הנכסים והווידאו של הלקוח נמצאים ב-livingsecurity-content-cdn.ai, דומיין שונה מ-livingsecurity.ai. אפשור *.livingsecurity.ai בלבד אינו מכסה אותם. הזינו את המארחים המפורשים לעיל כאשר השער שלכם אינו תומך ב-wildcards. ייתכן גם ש-wildcard במוצר האבטחה שלכם אינו כולל את הדומיין החשוף או תת-דומיינים מקוננים. אם אתם מוסיפים תוכן המתארח חיצונית, אפשרו גם את היעדים שבהם התוכן משתמש. בדקו כתובות אלה לפני הקצאת התוכן לעובדים.

יעדי העלאה

מנהלי מערכת המעלים תוכן או קובצי מיתוג. יעדים אלה מקבלים העלאות חדשות; עובדים הצופים בתוכן קיים זקוקים למארחי ה-CDN לעיל. אפשרו את שני מארחי העלאת הנכסים עבור תמונות, מסמכים, גופנים מותאמים אישית, סמלי מדווח וחבילות SCORM. תמונות ומסמכים קיימים יכולים להישאר באזור האחסון המקורי שלהם. השתמשו ב-API הווידאו של האזור של הארגון שלכם. התירו את PUT ואת OPTIONS להעלאות קבצים, ואת POST,‏ PATCH,‏ HEAD,‏ DELETE ו-OPTIONS להעלאות וידאו הניתנות לחידוש. שמרו על מחרוזות השאילתה של ה-URL ועל כותרות ההעלאה שמספק היישום. חבילות SCORM יכולות להגיע עד 500 MiB (524288000 בתים). התירו את החבילה המלאה בבקשת העלאה אחת; מגבלה נמוכה יותר על גוף הבקשה בשער שלכם עלולה לחסום את ההעלאה. יעדי ההעלאה אומתו בסביבות Production בארה”ב ובאיחוד האירופי ב-4 בנובמבר 2026.

תכונות ואינטגרציות נוספות

  • SSO/MFA והסכמה לאינטגרציה: אפשרו את ספק הזהויות שלכם ואת דפי הכניסה וההסכמה של כל מערכת שאתם מחברים.
  • סיורי הטמעה: onboard.livingsecurity.ai, מכוסה על ידי ה-wildcard ‏.ai; התירו HTTPS ו-WebSockets מאובטחים ב-TCP 443.
  • Livvy ועדכונים חיים: התירו תגובות HTTPS בסטרימינג ו-WebSockets מאובטחים ב-TCP 443.
  • תוכן חיצוני, דומיינים מותאמים אישית וה-LMS שלכם: כללו את המארחים המדויקים שהארגון שלכם משתמש בהם. בדקו SCORM מתארח מרשת הלומד.

כללי IP במערכות המחוברות שלכם

אם מערכת שאתם מחברים מגבילה גישת API לפי כתובת IP של מקור, הוסיפו כתובות אלה ל-רשימת ההיתרים של ה-API של אותה מערכת. אלה כתובות המקור שהיא תראה כאשר Living Security מבקשת נתונים. הן אינן יעדים יוצאים עבור מכשירי עובדים. אפשרו את כל ארבע כתובות ה-sync (זהות בארה”ב ובאיחוד האירופי): אפשרו גם את זוג כתובות ה-platform עבור האזור שלכם כאשר אתם משתמשים באחת מהאינטגרציות הבאות: זוג כתובות ה-platform חל גם על חיבורים שהוגדרו עם direct egress ועל ספקים הדורשים פעולות ישירות. השאירו את שתי קבוצות הכתובות מותרות לצורך המשך אימות, סנכרונים ופעולות: השאירו את כל הכתובות הנדרשות מותרות לאחר ההגדרה כדי שהאימות וסנכרוני הנתונים ימשיכו לפעול. השתמשו ברשומות אלה לגישת API של אינטגרציות בלבד. מדריך ה-egress של האינטגרציות מפרט דרישות ייעודיות לכל ספק.

אימות לפני ההשקה

בדקו דרך אותה רשת ארגונית, proxy, VPN, הגנת נקודות קצה ובקרות תיבות דואר שבהן העובדים שלכם משתמשים:
  • היכנסו ללוח המחוונים ול-Engage; השלימו SSO/MFA או קבלו קישור כניסה תקין בדוא”ל.
  • פתחו עמוד בלוח המחוונים ושאלו את Livvy שאלה.
  • פתחו תמונות קטלוג, הפעילו סרטון עם כתוביות ופתחו מסמך להורדה.
  • העלו נכס לקוח, ולאחר מכן הציגו אותו בתצוגה מקדימה כלומד; הפעילו חבילת SCORM שהועלתה אם אתם משתמשים באחת.
  • מסרו דוא”ל פתיחה או הקצאת הדרכה; בדקו את השולח, האימות, הקישורים והתמונות שלו.
  • הריצו סימולציה בנתיב המסירה שנבחר; ודאו הגעה לתיבת הדואר הנכנס, גישה לדף הנחיתה ותשובות בתרחישים מבוססי תשובה.
  • חברו כל אינטגרציה מופעלת וודאו סנכרון נתונים בפועל, ולא רק הרשאה מוצלחת.
אם בדיקה אחת נכשלת, תעדו את שם המארח החסום, השעה, האזור, התכונה המושפעת ושגיאת השער או מעקב הדואר, ולאחר מכן פנו לתמיכה. הסירו אישורים, אסימוני הפעלה ומחרוזות שאילתה של URL חתומים לפני שיתוף אבחונים. בדקו שוב מדריך זה ואת חבילת הסימולציה שייצאתם כאשר התצורה משתנה.