सुरक्षा अक्सर पूछे जाने वाले प्रश्न 

क्या पिछले 5 वर्षों में कोई महत्वपूर्ण सुरक्षा उल्लंघन या घटनाएं हुई हैं?

नहीं।

क्या विशेषाधिकार प्राप्त और सामान्य खाता पहुंच कम से कम समय-समय पर नियंत्रित और समीक्षा की जाती है

सालाना?

हाँ।

उपयोगकर्ता के बारे में कौन सा डेटा एकत्र किया जा रहा है? 

सॉफ्टवेयर खाता स्वामी और अंतिम ग्राहक के बारे में डेटा एकत्र करता है। दोनों सेट अप डेटा खाता स्वामी और अंतिम ग्राहक द्वारा प्रदान किए गए डेटा पर आधारित होते हैं। हम अंतिम उपयोगकर्ता या खाता स्वामी द्वारा दिए गए स्वैच्छिक डेटा के बाहर कोई डेटा एकत्र नहीं करते हैं। 

खाता स्वामी बुकिंग के समय विभिन्न डेटा बिंदुओं को एकत्र करने के लिए टेक्स्ट फ़ील्ड बना सकता है, लेकिन ग्राहक इस बात से पूरी तरह वाकिफ है कि डेटा एकत्र किया जा रहा है क्योंकि अंतिम उपयोगकर्ता फ़ील्ड में डेटा टाइप कर रहा होगा। अंतिम उपयोगकर्ता या खाता स्वामी किसी भी समय data@bookafy.com पर ईमेल करके डेटा हटाने का अनुरोध कर सकता है 

ऐप किन उद्देश्यों के लिए डेटा का उपयोग कर रहा है?

ऐप डेटा का उपयोग केवल उस लेन-देन के लिए किया जाता है जिसके लिए अंतिम ग्राहक ने साइन अप किया है। यदि एसएसओ के साथ लॉगिन करने के लिए फेसबुक या गूगल जैसे किसी तीसरे पक्ष के ऐप का उपयोग कर रहे हैं, तो हम उस कनेक्शन का उपयोग केवल अकाउंट एक्सेस के लिए करते हैं। हम खाते से संपर्क, ईवेंट, ईमेल संदेशों जैसे डेटा का उपयोग नहीं करते हैं और हम आपकी ओर से पोस्ट नहीं करते हैं या आपके खाते में किसी भी गतिविधि में भाग नहीं लेते हैं। यह केवल लॉगिन के लिए प्रयोग किया जाता है। 

डेटा हटाने के लिए उपयोगकर्ता के अधिकार क्या हैं और उपयोगकर्ता डेटा को हटाने का अनुरोध कैसे कर सकता है? 

हम खाता स्वामी (हमारे ग्राहक) से एकत्र किए गए डेटा का उपयोग खाता स्वामी को बेहतर अनुभव प्रदान करने के लिए करते हैं। इसमें कोई भी स्थान शामिल है जहां एओ फंस गया है, कई बार दौरा किया है, या कोई बग हो सकता है। हम इस डेटा का उपयोग अपने ग्राहकों (खाता स्वामी) के साथ सही समय पर सही संदेश के साथ संवाद करने के लिए करते हैं। 

अंतिम उपयोगकर्ता के लिए, हमारे ग्राहक के ग्राहक… हम केवल खाता स्वामी के साथ लेनदेन (बुकिंग) के लिए इस डेटा का उपयोग करते हैं। हम इन ग्राहकों के लिए मार्केटिंग नहीं करते हैं, या किसी अन्य तरीके से उनके डेटा का उपयोग नहीं करते हैं। उनका डेटा बेचा या उधार नहीं लिया जाता… यह हमारे सिस्टम में रहता है। 

एओ और अंतिम ग्राहक दोनों के मामले में, उनका डेटा किसी भी समय मिटाया जा सकता है। एओ data@bookafy.com पर ईमेल कर सकते हैं और अपने खाते और डेटा को हटाने का अनुरोध कर सकते हैं। अंतिम ग्राहक एओ द्वारा अपने डेटा को हटाने का अनुरोध कर सकता है। 

क्या साझा उपयोगकर्ता खाते कर्मचारियों के लिए प्रतिबंधित हैं? ग्राहकों के बारे में क्या?

कर्मचारियों के अपने समर्पित खाते हैं। ग्राहकों के पास अपने स्वयं के समर्पित खाते भी होते हैं, केवल उनके डेटा तक पहुंच के साथ।

क्या आपके पासवर्ड निर्माण के लिए कई ताकत की आवश्यकता होती है, यानी मजबूत पासवर्ड और अल्फा, न्यूमेरिक और विशेष वर्णों के यादृच्छिक अनुक्रम का उपयोग करता है?

बुनियादी पासवर्ड प्रबंधन स्तर पर हमें पासवर्ड में कम से कम 6 वर्णों की आवश्यकता होती है। आने वाले वर्ष में OWASP और NIST SP 800-63-3 पासवर्ड नीति विकल्प उपलब्ध हो सकते हैं।

क्या नेटवर्क सीमा प्रवेश और निकास फ़िल्टरिंग के साथ फ़ायरवॉल से सुरक्षित है?

हाँ। Azure और Amazon AWS द्वारा सभी फायरवॉल और लोड बैलेंसिंग सुविधाएं प्रदान की जाती हैं।

क्या पब्लिक फेसिंग सर्वर एक अच्छी तरह से परिभाषित डी-मिलिटरीकृत ज़ोन (DMZ) में हैं?

हां, यह एज़्योर के डिफॉल्ट इन्फ्रास्ट्रक्चर ज़ोनिंग से विरासत में मिला है और बुकाफी के क्षेत्रीय सर्वर दुनिया भर में फैले हुए हैं। 

क्या पीसीआई डेटा जैसे संवेदनशील उत्पादन संसाधनों को और अलग करने के लिए आंतरिक नेटवर्क विभाजन का उपयोग किया जाता है?

PCI डेटा संग्रहीत नहीं किया जाता है क्योंकि इसे केवल Bookafy द्वारा स्ट्राइप और ऑथराइज़.नेट जैसे तृतीय पक्ष प्रदाताओं से तैयार किया जाता है। बुकाफी डेटा एकत्र नहीं करता है या डेटा स्टोर नहीं करता है। 

क्या नेटवर्क घुसपैठ का पता लगाने या रोकथाम को लागू और मॉनिटर किया गया है?

एज़्योर द्वारा प्रदान की गई सूचनाओं और अलर्ट द्वारा पूरक निगरानी उपकरणों का एक व्यापक स्पेक्ट्रम लगातार बना रहता है। इसमें घुसपैठ का पता लगाना और नेटवर्क एक्सेस की ईमेल पुष्टि शामिल है।

क्या सभी डेस्कटॉप नियमित रूप से अपडेट किए गए वायरस, वर्म, स्पाईवेयर और दुर्भावनापूर्ण कोड सॉफ़्टवेयर का उपयोग करके सुरक्षित हैं?

हाँ।

क्या उद्योग सख्त प्रथाओं का उपयोग करके सर्वर सुरक्षित हैं? क्या प्रथाओं का दस्तावेजीकरण किया गया है?

सिस्टम सुरक्षा ऑडिट प्रदान करने के लिए सुरक्षा सेवाओं का नियमित रूप से उपयोग किया जाता है। 

क्या सभी ऑपरेटिंग सिस्टम, नेटवर्क डिवाइस और एप्लिकेशन के लिए सक्रिय वेंडर पैच प्रबंधन है?

हाँ। यह एज़्योर द्वारा स्वचालित रूप से उनकी सेवा के माध्यम से प्रदान किया जाता है।

क्या सभी उत्पादन प्रणाली की त्रुटियां और सुरक्षा घटनाएं रिकॉर्ड और संरक्षित हैं?

गंभीरता और कार्रवाई की आवश्यकता के आधार पर लॉग को कम से कम 1 महीने के लिए संरक्षित किया जाता है, कुछ को 6 महीने तक के लिए रखा जाता है।

क्या सुरक्षा घटनाओं और लॉग डेटा की नियमित रूप से समीक्षा की जाती है?

हाँ। लॉग घटनाओं की प्रकृति के आधार पर लॉग की दैनिक, साप्ताहिक और मासिक समीक्षा की जाती है।

क्या ग्राहक की गोपनीय जानकारी की सुरक्षा सुनिश्चित करने के लिए सुरक्षा उपायों के साथ एक प्रलेखित गोपनीयता कार्यक्रम मौजूद है?

हाँ।

क्या कोई गोपनीयता उल्लंघन होने पर ग्राहकों को सूचित करने की कोई प्रक्रिया है?

हाँ।

क्या आप व्यक्तिगत रूप से पहचान योग्य जानकारी (PII) को स्टोर, प्रोसेस, ट्रांसमिट (यानी “हैंडल”) करते हैं?

हाँ।

PII किस देश या देशों में संग्रहीत है?

हमारा अधिकांश PII डेटा यूएस में संग्रहीत है। हालाँकि, हम एक विशिष्ट क्षेत्रीय केंद्र में अपने उद्यम ग्राहकों के लिए खाता डेटा संग्रहीत करने में सक्षम हैं। उदाहरण। ऑस्ट्रेलियाई संगठन हमारे कैनबरा एज़्योर स्थान में अपना डेटा संग्रहीत करने का चुनाव कर सकते हैं। या यूरोपीय देश यूरोपीय डाटा सेंटर में स्टोर कर सकते हैं। 

क्या सिस्टम लॉग परिवर्तन और विनाश से सुरक्षित हैं?

यह एज़्योर द्वारा प्रदान किया गया है और ड्रॉपबॉक्स क्लाउड स्टोरेज पर बैकअप लिया गया है।

क्या प्रवेश के सीमा और वीएलएएन बिंदु घुसपैठ सुरक्षा और पहचान उपकरणों द्वारा संरक्षित हैं जो हमले के दौरान अलर्ट प्रदान करते हैं?

हाँ। ये सेवाएँ हमारे Azure फ़ायरवॉल में शामिल हैं जो घुसपैठ से सुरक्षा करती हैं और हमारी विकास टीम को स्वचालित अलर्ट भेजती हैं। 

क्या लॉग और ईवेंट किसी हमले की प्रगति की चेतावनी प्रदान करने वाले टूल से संबंधित हैं?

हां, हमारी सुरक्षा सेवा में वास्तविक समय में हमलों की लॉगिंग और अलर्ट शामिल हैं। 

नेटवर्किंग, फ्रंट-एंड, बैक-एंड स्टोरेज और बैकअप सहित समाधान के भीतर अन्य क्लाइंट से डेटा को कैसे अलग किया जाता है?

सभी डेटाबेस रिकॉर्ड पर एक आवश्यक स्थायी किरायेदार पहचानकर्ता के उपयोग के माध्यम से प्रत्येक ग्राहक खाता तार्किक रूप से अन्य ग्राहकों से अलग होता है।

इसके अतिरिक्त सभी एप्लिकेशन कोड को सभी कार्यों के लिए इस किरायेदार पहचानकर्ता की आवश्यकता होती है – पढ़ने और लिखने दोनों। प्रतिगमन और संभावित क्रॉस-किरायेदार डेटा संदूषण से कोड परिवर्तन की रक्षा के लिए एक स्वचालित परीक्षण व्यवस्था भी मौजूद है।

टेनेंट आइडेंटिफ़ायर प्रत्येक उपयोगकर्ता खाते से “हार्ड लिंक्ड” है और डेटाबेस क्वेरीज़ और फ़ाइल एक्सेस के समकक्ष उपायों पर निश्चित “WHERE” क्लॉज़ के माध्यम से तार्किक रूप से लागू होता है। एक प्लेटफ़ॉर्म उपयोगकर्ता इस टेनेंट पहचानकर्ता से अपने सत्र या खाते को बदलने या अन्यथा अनलिंक करने में सक्षम नहीं है। इस प्रकार एक उपयोगकर्ता के पास एक अलग किरायेदार पहचानकर्ता के तहत लॉगिन प्राधिकरण होने की कोई तार्किक संभावना नहीं है। यहां तक कि अगर वे एक अलग किरायेदार की आईडी का उपयोग कर पृष्ठों तक पहुंचने का प्रयास करते हैं, तो अनुरोधित किरायेदार आईडी पर उपयोगकर्ता खाता पंजीकृत नहीं होने के कारण सिस्टम अनुरोध को अस्वीकार कर देगा।

क्या आपके पास घटना प्रतिक्रिया योजना है?

हां, एक “जीवित दस्तावेज” रखा जाता है जो आपदा और घटना की प्रतिक्रिया की रूपरेखा तैयार करता है

घटनाओं को समझने और प्रतिक्रिया देने के लिए चेकलिस्ट, संपर्क विवरण और प्रमुख प्रणाली सुविधाएं।

किस स्तर की नेटवर्क सुरक्षा लागू की गई है?

हम एज़्योर क्लाउड पर चलने वाली वर्चुअल मशीनों के अपने नेटवर्क की सुरक्षा के लिए एज़्योर वेब एप्लीकेशन गेटवे (लोड बैलेंसर) और नेक्स्ट जेनरेशन फ़ायरवॉल का उपयोग करते हैं। 

क्या प्लेटफॉर्म सेवा की गुणवत्ता (क्यूओएस) प्रदर्शन मापन (संसाधन उपयोग, थ्रूपुट, उपलब्धता आदि) के लिए रिपोर्ट प्रदान करता है?

स्थिति.पिंगडम.कॉम पर हमारे स्थिति पृष्ठ के अनुसार उपलब्धता और प्रतिक्रिया समय के अलावा ऐसे मेट्रिक्स ग्राहकों को प्रदान नहीं किए जाते हैं।

क्या डिजास्टर रिकवरी प्रोग्राम का कम से कम सालाना परीक्षण किया जाता है?

हां, रिकवरी चेक और सालाना प्रदर्शन और परीक्षण।

सिस्टम का रिकवरी टाइम ऑब्जेक्टिव (RTO) और रिकवरी पॉइंट ऑब्जेक्टिव (RPO) क्या है?

RTO 4 घंटे का होता है, RPO 1 घंटे का होता है।

क्या आप अलग-अलग क्लाइंट के लिए बैकअप और रीस्टोर प्लान प्रदान करते हैं?

सभी पहलू बहु-किरायेदार हैं, इसलिए बैकअप पूरे ग्राहक आधार पर लिया जाता है। पूर्ण फ़ाइल बैकअप हर 24 घंटे में चलाया जाता है और प्रत्येक 5 मिनट में लिए जाने वाले एज़्योर डेटाबेस पॉइंट इन टाइम बैकअप से लाभान्वित होता है। बैकअप ड्रॉपबॉक्स क्लाउड के साथ-साथ निरर्थक एज़्योर वर्चुअल मशीनों पर संग्रहीत हैं। 

बैकअप बनाए रखने के लिए अधिकतम समय क्या है?

डेटाबेस पॉइंट-इन-टाइम बैकअप 30 दिनों के लिए बनाए रखा जाता है, जिसमें सामान्य फ़ाइल बैकअप न्यूनतम 90 दिनों के लिए होता है।

डेटा रिस्टोर के लिए अपेक्षित टर्नअराउंड समय क्या है?

किसी भी गैर-आपदा परिदृश्य में किसी भी ग्राहक को पुनर्स्थापित करने का अनुरोध किया जाना चाहिए और हमारे साथ निर्धारित किया जाना चाहिए। टर्नअराउंड 1 और 2 व्यावसायिक दिनों के बीच है। 

क्या पूरे प्लेटफॉर्म को प्रभावित किए बिना एकल इकाई खाता बहाल किया जा सकता है?

यदि क्लाइंट द्वारा किसी विशिष्ट रिकॉर्ड या आर्टिफैक्ट की बहाली की आवश्यकता होती है, तो इसे प्रति अनुरोध के आधार पर ऑनलाइन किया जा सकता है और यह कार्य शुल्क योग्य है। प्लेटफ़ॉर्म या ग्राहक खाते पर कोई प्रभाव नहीं पड़ता है।

क्या उच्च उपलब्धता प्रदान की जाती है – i. इ। जहां एक सर्वर उदाहरण अनुपलब्ध हो जाता है, क्या दूसरा उपलब्ध हो जाता है?

एज़्योर की वर्चुअल मशीन के माध्यम से सभी सिस्टम स्तरों पर कई सर्वर इंस्टेंस चल रहे हैं, जिसमें वेब एप्लिकेशन गेटवे लोड संतुलन को संभाल रहा है। डेटा सेंटर के भीतर एक सर्वर इंस्टेंस की विफलता को Azure WAG द्वारा नियंत्रित किया जाता है, जिसमें समस्या का इंस्टेंस रीसायकल किया जाता है और/या हटा दिया जाता है और एक नए इंस्टेंस के साथ बदल दिया जाता है।

क्या आपदा पुनर्प्राप्ति आवश्यकताओं को पूरा करने के लिए डेटा किसी अन्य स्थान (डेटा केंद्र) में संग्रहीत और उपलब्ध है?

हाँ। सभी डेटा को दूसरे डेटा सेंटर में दोहराया जाता है जो भौगोलिक स्थिति के साथ-साथ ड्रॉपबॉक्स क्लाउड स्टोरेज पर संग्रहीत बैकअप डेटा से भिन्न होता है। .

क्या फेलओवर प्रक्रिया एक सक्रिय/सक्रिय, स्वचालित स्विचओवर प्रक्रिया है?

प्राथमिक डेटा केंद्र के भीतर एक सर्वर उदाहरण की विफलता को Azure WAG लोड बैलेंसर्स द्वारा नियंत्रित किया जाता है, जिसमें समस्या का उदाहरण रीसायकल और/या हटा दिया जाता है और एक नए उदाहरण के साथ बदल दिया जाता है।

इस घटना में कि पूरे डेटा केंद्र में एक महत्वपूर्ण विफलता थी, तो द्वितीयक केंद्र पर स्विच करना एक मैन्युअल प्रक्रिया है, क्योंकि हमें यह सुनिश्चित करने के लिए पहले समस्या का पूर्ण मूल्यांकन करने की आवश्यकता है कि मौजूदा प्राथमिक को बनाए रखने के लिए कोई सरल समाधान नहीं है। केंद्र उपस्थिति उपलब्ध है। यदि यह निर्धारित किया जाता है कि द्वितीयक केंद्र में जाने की आवश्यकता है, तो लक्ष्य पुनर्प्राप्ति उद्देश्यों को पूरा करने के लिए मैन्युअल रूप से स्विचओवर शुरू किया जाएगा।