संक्षिप्त सूची से शुरू करें
वेब एक्सेस: HTTPS / TCP 443। कई परिवेशों में, Living Security के दो वाइल्डकार्ड और नीचे दिए गए बाहरी कंटेंट तथा साइन-इन एसेट होस्ट कर्मचारियों की एक्सेस के लिए पर्याप्त होते हैं।
ग्राहक सामग्री, अपलोड और Contentful होस्ट Living Security वाइल्डकार्ड के बाहर हैं। ग्राहक सामग्री और अपलोड होस्ट
livingsecurity-content-cdn.ai का उपयोग करते हैं, जो livingsecurity.ai से भिन्न डोमेन है।
साथ ही static.descope.com और descopecdn.com को केवल एम्बेडेड साइन-इन एसेट के लिए अनुमति दें; साइन-इन अनुरोध auth.livingsecurity.ai का उपयोग करते हैं।
यदि आप केवल *.livingsecurity.ai का उपयोग करते हैं, तो platform-cdn.livingsecurity.com और नीचे सूचीबद्ध अन्य .com कंटेंट होस्ट जोड़ें।
विस्तृत होस्टनाम तालिकाएँ उन IT टीमों के लिए हैं जो वाइल्डकार्ड का उपयोग नहीं कर सकतीं; इनके लिए डुप्लिकेट नियमों की आवश्यकता नहीं है। जाँच करें कि आपके गेटवे का वाइल्डकार्ड
api.eu-west-1.livingsecurity.ai जैसे नेस्टेड नामों से मेल खाता है या नहीं। वाइल्डकार्ड में बेयर डोमेन शामिल न हो, ऐसा हो सकता है। वेब डेस्टिनेशन के लिए होस्टनाम का उपयोग करें, क्योंकि उनके IP बदल सकते हैं।ईमेल डिलीवरी
ऑथेंटिकेशन ईमेल
इन प्रविष्टियों को अपनी मेल सुरक्षा सेवा में साइन-इन ईमेल पर लागू करें। सुनिश्चित करें कि संदेश उनके लिंक समाप्त होने से पहले पहुँच जाएँ। नोटिफिकेशन इन्हीं IP का उपयोग करते हैं; सिमुलेशन नीचे दी गई अलग रेंज का उपयोग करते हैं। Enterprise Identity देखें।
ट्रांज़ैक्शनल प्लेटफ़ॉर्म ईमेल
ऊपर सूचीबद्ध वही दो सेंडिंग IP US और EU दोनों में प्लेटफ़ॉर्म नोटिफिकेशन भी भेजते हैं। इन From पते और ऑथेंटिकेटेड रिटर्न-पाथ डोमेन को अनुमति दें:
इनमें स्वागत संदेश, Training असाइनमेंट, रिमाइंडर और अन्य नोटिफिकेशन शामिल हैं। SPF, DKIM और DMARC सत्यापन सक्षम रखें। सिमुलेशन SMTP नीचे दी गई अपनी रेंज का उपयोग करता है।
यदि आपका अपना SMTP रिले सोर्स IP के आधार पर कनेक्शन सीमित करता है, तो रिले कॉन्फ़िगर करने से पहले Support से अपने क्षेत्र के लिए Living Security के SMTP कनेक्शन सोर्स IP प्राप्त करें। ये आपके रिले से कनेक्शन की पहचान करते हैं, जो आपके रिले के अपने सेंडिंग IP से अलग हैं। ऊपर दिए गए प्लेटफ़ॉर्म-प्रबंधित मेल IP या नीचे दिए गए इंटीग्रेशन API IP का प्रतिस्थापन के रूप में उपयोग न करें।
Phishing simulations
प्लेटफ़ॉर्म-प्रबंधित SMTP के लिए, अपने संगठन के क्षेत्र का उपयोग करें:
अपने क्षेत्र की पूरी IP रेंज को अनुमति दें। जिन गेटवे नियमों में मेल ऑथेंटिकेशन डोमेन आवश्यक है, उनके लिए उसका उपयोग करें। दिखाई देने वाला From पता सिमुलेशन के अनुसार बदलता है; अपने चुने गए सिमुलेशन के लिए वर्तमान allowlist पैकेज का उपयोग करें।
लॉन्च से पहले, Settings → Simulations → Allowlisting → Export allowlist package से संगठन-विशिष्ट पैकेज प्राप्त करें, या एक्सेस मिलने से पहले अपने Customer Success Manager से अनुरोध करें। इसमें सक्षम सेंडिंग डोमेन, लैंडिंग/URL होस्ट और अलग Reply-To domain शामिल हैं। यदि आपके गेटवे को पूरे पते चाहिए, तो अपने चुने गए सिमुलेशन के वास्तविक From पते देखें। सिमुलेशन सेटिंग बदलने पर अद्यतन पैकेज डाउनलोड करें।
डायरेक्ट डिलीवरी (DMI) आपके कनेक्टेड Microsoft 365 या Google Workspace इंटीग्रेशन का उपयोग करती है; SMTP सोर्स रेंज उस डिलीवरी पाथ पर लागू नहीं होतीं। Google Workspace ईमेल भेजे बिना संदेशों को प्रत्येक Inbox में रखता है। Microsoft 365 आपके सिमुलेशन मेलबॉक्स से वास्तविक ईमेल भेजता है, इसलिए आपके Microsoft 365 फ़िल्टर उस पर लागू रहते हैं। URL एक्सेस, प्रदाता की सहमति और इनबॉक्स परीक्षण फिर भी महत्वपूर्ण हैं। प्रदाता-विशिष्ट चरणों के लिए Simulation Settings का पालन करें, जिसमें लागू होने पर Microsoft Defender के सिमुलेशन नियंत्रण भी शामिल हैं।
एप्लिकेशन और API एक्सेस
EU संगठनों के लिए, ब्राउज़र साइन-इन और एप्लिकेशन एक्सेस हेतु दोनों API होस्टनाम को अनुमति दें। डायरेक्ट API इंटीग्रेशन के लिए, अपने संगठन को असाइन किए गए क्षेत्रीय URL का उपयोग करें। API क्विकस्टार्ट देखें।
यदि आपका संगठन कस्टम एप्लिकेशन या साइन-इन होस्टनाम का उपयोग करता है, तो सेटअप के दौरान प्रदान किया गया सटीक होस्टनाम शामिल करें।
साइन-इन आवश्यकताएँ
साइन-इन अनुरोध
auth.livingsecurity.ai का उपयोग करते हैं, जो ऊपर सूचीबद्ध है। एम्बेडेड फ़ॉर्म इस तालिका के होस्ट से भी एसेट लोड करता है। यदि फ़ॉर्म ठीक से प्रदर्शित नहीं होता, तो अपनी IT टीम से जाँच करने को कहें कि वे एसेट अनुरोध ब्लॉक तो नहीं हैं।
कंटेंट, CDN और ग्राहक अपलोड
कंटेंट का पूर्वावलोकन करने वाले एडमिनिस्ट्रेटर और उसे देखने वाले कर्मचारियों के लिए इन होस्ट को अनुमति दें। ईमेल इमेज सुरक्षा के लिए इमेज होस्ट की एक्सेस भी आवश्यक हो सकती है।
ग्राहक एसेट और वीडियो होस्ट
livingsecurity-content-cdn.ai पर हैं, जो livingsecurity.ai से अलग डोमेन है। केवल *.livingsecurity.ai को अनुमति देना इन्हें कवर नहीं करता। यदि आपका गेटवे वाइल्डकार्ड का समर्थन नहीं करता, तो ऊपर दिए गए स्पष्ट होस्ट दर्ज करें। आपके सुरक्षा उत्पाद में वाइल्डकार्ड बेयर डोमेन या नेस्टेड सबडोमेन को भी शामिल न करे, ऐसा हो सकता है।
यदि आप बाहरी रूप से होस्ट किया गया कंटेंट जोड़ते हैं, तो उस कंटेंट द्वारा उपयोग किए जाने वाले डेस्टिनेशन को भी अनुमति दें। कंटेंट को कर्मचारियों को असाइन करने से पहले उन पतों की समीक्षा करें।
अपलोड डेस्टिनेशन
कंटेंट या ब्रांडिंग फ़ाइलें अपलोड करने वाले एडमिन। ये डेस्टिनेशन नए अपलोड प्राप्त करते हैं; मौजूदा कंटेंट देखने वाले कर्मचारियों को ऊपर दिए गए CDN होस्ट चाहिए।
इमेज, दस्तावेज़, कस्टम फ़ॉन्ट, रिपोर्टर आइकन और SCORM पैकेज के लिए दोनों एसेट-अपलोड होस्ट को अनुमति दें। मौजूदा इमेज और दस्तावेज़ अपना मूल स्टोरेज क्षेत्र रख सकते हैं। अपने संगठन के क्षेत्र के लिए वीडियो API का उपयोग करें।
फ़ाइल अपलोड के लिए
PUT और OPTIONS को, तथा रिज़्यूमेबल वीडियो अपलोड के लिए POST, PATCH, HEAD, DELETE और OPTIONS को अनुमति दें। एप्लिकेशन द्वारा दिए गए URL क्वेरी स्ट्रिंग और अपलोड हेडर यथावत रखें।
SCORM पैकेज 500 MiB (524288000 बाइट) तक हो सकते हैं। पूरे पैकेज को एक ही अपलोड अनुरोध में अनुमति दें; आपके गेटवे पर कम रिक्वेस्ट-बॉडी सीमा अपलोड को ब्लॉक कर सकती है।
अपलोड डेस्टिनेशन का सत्यापन 4 नवंबर 2026 को US और EU Production में किया गया।
अतिरिक्त सुविधाएँ और Integrations
- SSO/MFA और इंटीग्रेशन सहमति: अपने आइडेंटिटी प्रदाता तथा प्रत्येक कनेक्ट किए जाने वाले सिस्टम के साइन-इन/सहमति पेज को अनुमति दें।
- ऑनबोर्डिंग टूर:
onboard.livingsecurity.ai,.aiवाइल्डकार्ड द्वारा कवर; TCP 443 पर HTTPS और सुरक्षित WebSockets की अनुमति दें। - Livvy और लाइव अपडेट: TCP 443 पर स्ट्रीमिंग HTTPS प्रतिक्रियाओं और सुरक्षित WebSockets की अनुमति दें।
- बाहरी कंटेंट, कस्टम डोमेन और आपका LMS: अपने संगठन द्वारा उपयोग किए जाने वाले सटीक होस्ट शामिल करें। होस्टेड SCORM का परीक्षण Learner नेटवर्क से करें।
आपके कनेक्टेड सिस्टम में IP नियम
यदि आपके द्वारा कनेक्ट किया गया कोई सिस्टम सोर्स IP के आधार पर API एक्सेस को सीमित करता है, तो इन पतों को उस सिस्टम की API allowlist में जोड़ें। जब Living Security डेटा का अनुरोध करता है, तो सिस्टम को ये ही सोर्स पते दिखाई देंगे। ये कर्मचारी डिवाइस के लिए आउटबाउंड डेस्टिनेशन नहीं हैं। चारों sync पतों को अनुमति दें (US और EU में समान):
इनमें से किसी भी इंटीग्रेशन का उपयोग करने पर अपने क्षेत्र की platform जोड़ी को भी अनुमति दें:
- Auth0
- Check Point Harmony Email
- Cofense Triage
- Code42
- Cornerstone
- CrowdStrike Falcon
- Keepnet Labs
- Microsoft Entra ID — Microsoft Graph सहित
- OneLogin
- SailPoint IdentityNow
- Sophos Central
- Zscaler Client Connector
ऑथेंटिकेशन और डेटा sync निरंतर काम करते रहें, इसके लिए सेटअप के बाद सभी आवश्यक पते अनुमत रखें। इन प्रविष्टियों का उपयोग केवल इंटीग्रेशन API एक्सेस के लिए करें। प्रदाता-विशिष्ट आवश्यकताएँ integration egress गाइड में सूचीबद्ध हैं।
लॉन्च से पहले सत्यापन
उसी कॉर्पोरेट नेटवर्क, प्रॉक्सी, VPN, एंडपॉइंट सुरक्षा और मेलबॉक्स नियंत्रणों के माध्यम से परीक्षण करें जिनका उपयोग आपके कर्मचारी करते हैं:- Dashboard और Engage में साइन इन करें; SSO/MFA पूरा करें या कार्यशील ईमेल साइन-इन लिंक प्राप्त करें।
- कोई Dashboard पेज खोलें और Livvy से कोई प्रश्न पूछें।
- कैटलॉग इमेज खोलें, कैप्शन के साथ कोई वीडियो चलाएँ और कोई डाउनलोड योग्य दस्तावेज़ खोलें।
- कोई ग्राहक एसेट अपलोड करें, फिर Learner के रूप में उसका पूर्वावलोकन करें; यदि आप अपलोड किए गए SCORM पैकेज का उपयोग करते हैं, तो उसे लॉन्च करें।
- कोई स्वागत या Training असाइनमेंट ईमेल डिलीवर करें; उसके सेंडर, ऑथेंटिकेशन, लिंक और इमेज जाँचें।
- चुने गए डिलीवरी पाथ पर कोई सिमुलेशन चलाएँ; इनबॉक्स में आगमन, लैंडिंग-पेज एक्सेस और रिप्लाई-आधारित परिदृश्यों के लिए उत्तर सत्यापित करें।
- प्रत्येक सक्षम इंटीग्रेशन को कनेक्ट करें और केवल सफल प्राधिकरण नहीं, बल्कि वास्तविक डेटा sync सत्यापित करें।