इसके माध्यम से साझा किया गया

सुरक्षा परीक्षण के लिए अनुशंसाएँ

  • आलेख

इस Power Platform अच्छी तरह से निर्मित सुरक्षा चेकलिस्ट अनुशंसा पर लागू होता है:

एसई:09 एक व्यापक परीक्षण व्यवस्था स्थापित करें जो सुरक्षा समस्याओं को रोकने, खतरे की रोकथाम कार्यान्वयन को मान्य करने और खतरे का पता लगाने वाले तंत्रों का परीक्षण करने के तरीकों को जोड़ती हो।

कठोर परीक्षण अच्छे सुरक्षा डिज़ाइन का आधार है। परीक्षण सत्यापन का एक सामरिक रूप है, जिससे यह सुनिश्चित किया जाता है कि नियंत्रण अपेक्षित रूप से कार्य कर रहे हैं। परीक्षण भी प्रणाली में कमजोरियों का पता लगाने का एक सक्रिय तरीका है।

एकाधिक Perspectives से ताल और सत्यापन के माध्यम से परीक्षण कठोरता स्थापित करें। आपको अंदर से बाहर के दृष्टिकोण को शामिल करना चाहिए जो प्लेटफॉर्म और बुनियादी ढांचे का परीक्षण करता है और बाहर से अंदर के मूल्यांकन को शामिल करना चाहिए जो बाहरी हमलावर की तरह सिस्टम का परीक्षण करता है।

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

परिभाषाएं

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

प्रमुख डिजाइन रणनीतियाँ

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

परीक्षण के दायरे में अनुप्रयोग, बुनियादी संरचना, तथा स्वचालित एवं मानवीय प्रक्रियाएं शामिल होनी चाहिए।

नोट

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

परीक्षण योजना में शामिल हों। कार्यभार टीम परीक्षण मामलों को डिज़ाइन नहीं कर सकती है। यह कार्य प्रायः उद्यम में ही केन्द्रीकृत होता है या बाहरी सुरक्षा विशेषज्ञों द्वारा पूरा किया जाता है। कार्यभार टीम को उस डिजाइन प्रक्रिया में शामिल किया जाना चाहिए ताकि यह सुनिश्चित किया जा सके कि सुरक्षा आश्वासन अनुप्रयोग की कार्यक्षमता के साथ एकीकृत हो।

हमलावर की तरह सोचें. अपने परीक्षण मामलों को इस धारणा के साथ डिज़ाइन करें कि सिस्टम पर हमला हुआ है। इस तरह, आप संभावित कमजोरियों को उजागर कर सकते हैं और तदनुसार परीक्षणों को प्राथमिकता दे सकते हैं।

परीक्षणों को संरचित तरीके से तथा दोहराए जाने योग्य प्रक्रिया के साथ चलाएं। अपनी परीक्षण कठोरता को ताल, परीक्षण के प्रकार, प्रेरक कारकों और इच्छित परिणामों के आधार पर तैयार करें।

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

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

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

आप पर्यावरण प्रतिलिपि सुविधा का उपयोग करके अपने उत्पादन परिवेश का एक पृथक क्लोन बना सकते हैं। यदि आपके पास परिनियोजन पाइपलाइन स्थापित है, तो आप अपने समाधानों को एक समर्पित परीक्षण वातावरण में भी परिनियोजित कर सकते हैं।

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

जब आप अपनी परीक्षण योजना तैयार करें, तो निम्नलिखित प्रश्नों पर विचार करें:

  • आप कितनी बार परीक्षण चलाने की अपेक्षा करते हैं, और इसका आपके परिवेश पर क्या प्रभाव पड़ता है?
  • आपको कौन-कौन से विभिन्न प्रकार के परीक्षण करने चाहिए?

आप कितनी बार परीक्षण चलने की अपेक्षा करते हैं?

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

नियमित परीक्षण

नियमित परीक्षण, आपकी मानक संचालन प्रक्रियाओं के भाग के रूप में तथा अनुपालन आवश्यकताओं को पूरा करने के लिए, नियमित गति से किए जाते हैं। विभिन्न परीक्षण अलग-अलग गति से चलाए जा सकते हैं, लेकिन महत्वपूर्ण बात यह है कि वे समय-समय पर और निर्धारित समय पर चलाए जाएं।

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

प्रत्येक चरण पर, इन परीक्षणों को जोड़े गए या हटाए गए कोड या परिवर्तित कॉन्फ़िगरेशन सेटिंग्स को सत्यापित करना चाहिए, ताकि उन परिवर्तनों के सुरक्षा प्रभाव का पता लगाया जा सके। आपको स्वचालन के साथ परीक्षणों की प्रभावकारिता में सुधार करना चाहिए, तथा सहकर्मी समीक्षाओं के साथ संतुलन बनाना चाहिए।

स्वचालित पाइपलाइन या अनुसूचित परीक्षण रन के भाग के रूप में सुरक्षा परीक्षण चलाने पर विचार करें। जितनी जल्दी आप सुरक्षा समस्याओं का पता लगा लेंगे, उतनी ही आसानी से उन समस्याओं का कारण बनने वाले कोड या कॉन्फ़िगरेशन परिवर्तन का पता लग जाएगा।

केवल स्वचालित परीक्षणों पर ही निर्भर न रहें। उन कमजोरियों का पता लगाने के लिए मैन्युअल परीक्षण का उपयोग करें जिन्हें केवल मानवीय विशेषज्ञता ही पकड़ सकती है। मैन्युअल परीक्षण खोजपरक उपयोग मामलों और अज्ञात जोखिमों का पता लगाने के लिए अच्छा है।

तात्कालिक परीक्षण

सुधारित परीक्षण सुरक्षा बचाव का बिंदु-दर-बिंदु सत्यापन प्रदान करते हैं। सुरक्षा अलर्ट जो उस समय कार्यभार को प्रभावित कर सकते हैं, इन परीक्षणों को ट्रिगर करते हैं। यदि चेतावनी आपातकालीन स्थिति में बदल जाती है, तो संगठनात्मक आदेशों के तहत बचाव रणनीतियों की प्रभावशीलता को सत्यापित करने के लिए रुककर परीक्षण करने की मानसिकता की आवश्यकता हो सकती है।

तात्कालिक परीक्षणों का लाभ यह है कि इससे वास्तविक घटना के लिए तैयारी हो जाती है। ये परीक्षण उपयोगकर्ता स्वीकृति परीक्षण (यूएटी) करने के लिए एक बाध्यकारी कार्य हो सकते हैं।

सुरक्षा टीम सभी कार्यभारों का ऑडिट कर सकती है और आवश्यकतानुसार ये परीक्षण चला सकती है। कार्यभार स्वामी के रूप में, आपको सुरक्षा टीमों के साथ सहयोग और सुविधा प्रदान करने की आवश्यकता है। सुरक्षा टीमों के साथ पर्याप्त समय पर बातचीत करें ताकि आप तैयारी कर सकें। अपनी टीम और हितधारकों को यह बताएं कि ये व्यवधान आवश्यक हैं।

अन्य मामलों में, आपको संभावित खतरे के विरुद्ध परीक्षण चलाने और सिस्टम की सुरक्षा स्थिति की रिपोर्ट करने की आवश्यकता हो सकती है।

अदला - बदली क्योंकि तात्कालिक परीक्षण व्यवधानकारी घटनाएँ हैं, इसलिए कार्यों को पुनः प्राथमिकता देने की अपेक्षा करें, जिससे अन्य नियोजित कार्यों में देरी हो सकती है।

जोखिम: अज्ञात जोखिम है। तात्कालिक परीक्षण, स्थापित प्रक्रियाओं या उपकरणों के बिना एक बार का प्रयास हो सकता है। लेकिन सबसे बड़ा जोखिम व्यवसाय की लय में संभावित व्यवधान है। आपको लाभों के सापेक्ष उन जोखिमों का मूल्यांकन करना होगा।

सुरक्षा घटना परीक्षण

ऐसे परीक्षण हैं जो सुरक्षा घटना के कारण का पता उसके स्रोत पर ही लगा देते हैं। यह सुनिश्चित करने के लिए कि घटना दोबारा न हो, इन सुरक्षा खामियों को दूर किया जाना चाहिए।

घटनाएँ समय के साथ मौजूदा कमियों को उजागर करके परीक्षण मामलों में सुधार भी करती हैं। टीम को घटना से सीखे गए सबक को लागू करना चाहिए तथा नियमित रूप से सुधार करना चाहिए।

परीक्षण के विभिन्न प्रकार क्या हैं?

परीक्षणों को प्रौद्योगिकी और परीक्षण पद्धति के आधार पर वर्गीकृत किया जा सकता है। पूर्ण कवरेज प्राप्त करने के लिए उन श्रेणियों और उन श्रेणियों के अंतर्गत दृष्टिकोणों को संयोजित करें।

अनेक परीक्षण और परीक्षण के प्रकार जोड़कर, आप निम्नांकित जानकारी प्राप्त कर सकते हैं:

  • सुरक्षा नियंत्रण या प्रतिपूरक नियंत्रण में अंतराल।
  • ग़लत कॉन्फ़िगरेशन.
  • अवलोकनीयता और पता लगाने के तरीकों में अंतराल।

एक अच्छा खतरा मॉडलिंग अभ्यास परीक्षण कवरेज और आवृत्ति सुनिश्चित करने के लिए प्रमुख क्षेत्रों की ओर संकेत कर सकता है। खतरा मॉडलिंग पर सिफारिशों के लिए, विकास जीवनचक्र को सुरक्षित करने के लिए सिफारिशें देखें।

इन अनुभागों में वर्णित अधिकांश परीक्षण नियमित परीक्षण के रूप में चलाए जा सकते हैं। हालाँकि, कुछ मामलों में पुनरावृत्ति के कारण लागत बढ़ सकती है तथा व्यवधान उत्पन्न हो सकता है। उन समझौतों पर ध्यानपूर्वक विचार करें।

प्रौद्योगिकी स्टैक को मान्य करने वाले परीक्षण

यहां परीक्षणों के प्रकार और उनके फोकस क्षेत्रों के कुछ उदाहरण दिए गए हैं। यह सूची संपूर्ण नहीं है। एप्लिकेशन स्टैक, फ्रंट एंड, बैक एंड, एपीआई, डेटाबेस और किसी भी बाहरी एकीकरण सहित संपूर्ण स्टैक का परीक्षण करें।

  • डेटा सुरक्षा: डेटा एन्क्रिप्शन और एक्सेस नियंत्रण की प्रभावशीलता का परीक्षण करें ताकि यह सुनिश्चित हो सके कि डेटा अनधिकृत पहुंच और छेड़छाड़ से ठीक से सुरक्षित है।
  • नेटवर्क और कनेक्टिविटी: यह सुनिश्चित करने के लिए अपने फ़ायरवॉल का परीक्षण करें कि वे कार्यभार के लिए केवल अपेक्षित, अनुमत और सुरक्षित ट्रैफ़िक की अनुमति देते हैं।
  • अनुप्रयोग: अनुप्रयोग सुरक्षा परीक्षण (AST) तकनीकों के माध्यम से स्रोत कोड का परीक्षण करें ताकि यह सुनिश्चित किया जा सके कि आप सुरक्षित कोडिंग प्रथाओं का पालन करते हैं और मेमोरी भ्रष्टाचार और विशेषाधिकार समस्याओं जैसी रनटाइम त्रुटियों को पकड़ सकें।
  • पहचान: मूल्यांकन करें कि क्या भूमिका असाइनमेंट और सशर्त जाँचें अपेक्षित रूप से काम करती हैं।

परीक्षण पद्धति

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

वास्तविक दुनिया के हमलों के माध्यम से परीक्षण के कुछ लाभ इस प्रकार हैं:

  • जब आप इन हमलों को नियमित परीक्षण का हिस्सा बनाते हैं, तो आप कार्यभार की जांच करने के लिए बाहर से अंदर के परिप्रेक्ष्य का उपयोग करते हैं और सुनिश्चित करते हैं कि रक्षा किसी हमले का सामना कर सकती है।
  • सीखे गए पाठों के आधार पर, टीम अपने ज्ञान और स्तर को उन्नत करती है। टीम परिस्थितिजन्य जागरूकता में सुधार करती है और घटनाओं पर प्रतिक्रिया देने के लिए अपनी तत्परता का आत्म-मूल्यांकन कर सकती है।

जोखिम: सामान्यतः परीक्षण से प्रदर्शन प्रभावित हो सकता है। यदि विनाशकारी परीक्षण डेटा को नष्ट या दूषित कर देते हैं तो व्यवसाय निरंतरता की समस्या उत्पन्न हो सकती है। सूचना के प्रकटीकरण से जोखिम भी जुड़े हैं; डेटा की गोपनीयता बनाए रखना सुनिश्चित करें। परीक्षण पूरा करने के बाद डेटा की अखंडता सुनिश्चित करें।

सिम्युलेटेड परीक्षणों के कुछ उदाहरणों में ब्लैक-बॉक्स और व्हाइट-बॉक्स परीक्षण, पेनेट्रेशन परीक्षण और युद्ध खेल अभ्यास शामिल हैं।

ब्लैक-बॉक्स और व्हाइट-बॉक्स परीक्षण

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

जोखिम: दोनों प्रकारों के बीच का अंतर अग्रिम लागत में है। सिस्टम को समझने में लगने वाले समय की दृष्टि से व्हाइट-बॉक्स परीक्षण महंगा हो सकता है। कुछ मामलों में, व्हाइट-बॉक्स परीक्षण के लिए आपको विशेष उपकरण खरीदने की आवश्यकता होती है। ब्लैक-बॉक्स परीक्षण के लिए अधिक समय की आवश्यकता नहीं होती, लेकिन यह उतना प्रभावी नहीं हो सकता। समस्याओं को उजागर करने के लिए आपको अतिरिक्त प्रयास करने पड़ सकते हैं। यह समय का निवेश है।

परीक्षण जो प्रवेश परीक्षण के माध्यम से हमलों का अनुकरण करते हैं

सुरक्षा विशेषज्ञ जो संगठन की आईटी या एप्लिकेशन टीम का हिस्सा नहीं हैं, वे पैनेट्रेशन परीक्षण, या पेनटेस्टिंग करते हैं। वे सिस्टम को इस दृष्टि से देखते हैं कि दुर्भावनापूर्ण अभिनेता आक्रमण की सतह तैयार करते हैं। उनका लक्ष्य सूचना एकत्र करके, कमजोरियों का विश्लेषण करके, तथा परिणामों की रिपोर्ट देकर सुरक्षा खामियों का पता लगाना है।

ट्रेडऑफ़: पैनेट्रेशन परीक्षण तात्कालिक होते हैं और व्यवधानों और मौद्रिक निवेश के संदर्भ में महंगे हो सकते हैं क्योंकि पेनटेस्टिंग आमतौर पर तीसरे पक्ष के चिकित्सकों द्वारा भुगतान की जाने वाली पेशकश होती है।

जोखिम: पेनटेस्टिंग अभ्यास रनटाइम वातावरण को प्रभावित कर सकता है और सामान्य ट्रैफ़िक की उपलब्धता को बाधित कर सकता है।

व्यवसायियों को सम्पूर्ण संगठन के संवेदनशील डेटा तक पहुंच की आवश्यकता हो सकती है। यह सुनिश्चित करने के लिए कि पहुँच का दुरुपयोग न हो, नियमों का पालन करें। सूचीबद्ध संसाधन देखें संबंधित जानकारी.

युद्ध अभ्यास के माध्यम से हमलों का अनुकरण करने वाले परीक्षण

नकली हमलों की इस पद्धति में दो टीमें होती हैं:

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

यदि इन्हें नियमित परीक्षण के रूप में आयोजित किया जाता है, तो युद्ध अभ्यास निरंतर दृश्यता और आश्वासन प्रदान कर सकते हैं कि आपकी सुरक्षा व्यवस्था डिजाइन के अनुसार काम कर रही है। युद्ध खेल अभ्यास संभावित रूप से आपके कार्यभार के विभिन्न स्तरों का परीक्षण कर सकते हैं।

यथार्थवादी हमले परिदृश्यों का अनुकरण करने के लिए एक लोकप्रिय विकल्प Microsoft डिफेंडर है Office 365 आक्रमण सिमुलेशन प्रशिक्षण.

अधिक जानकारी के लिए, देखें आक्रमण सिमुलेशन प्रशिक्षण के लिए अंतर्दृष्टि और रिपोर्ट।

रेड-टीम और ब्लू-टीम सेटअप के बारे में जानकारी के लिए, देखें Microsoft क्लाउड रेड टीमिंग.

Power Platform सुविधा

Microsoft सेंटिनल समाधान ग्राहकों को विभिन्न संदिग्ध गतिविधियों का पता लगाने की अनुमति देता है, जैसे: Microsoft Power Platform

  • Power Apps अनधिकृत भौगोलिक क्षेत्रों से निष्पादन
  • संदिग्ध डेटा विनाश Power Apps
  • बड़े पैमाने पर विलोपन Power Apps
  • फ़िशिंग हमले के ज़रिए किए गए Power Apps
  • Power Automate प्रस्थान करने वाले कर्मचारियों द्वारा गतिविधि प्रवाहित होती है
  • Microsoft Power Platform किसी परिवेश में जोड़े गए कनेक्टर
  • डेटा हानि रोकथाम नीतियों को अपडेट करना या हटाना Microsoft Power Platform

अधिक जानकारी के लिए, Microsoft Sentinel समाधान का Microsoft Power Platform अवलोकन देखें।

उत्पाद दस्तावेज़ीकरण के लिए, देखें Microsoft Sentinel में हंटिंग क्षमताएँ.

Microsoft डिफेंडर फॉर क्लाउड विभिन्न प्रौद्योगिकी क्षेत्रों के लिए भेद्यता स्कैनिंग प्रदान करता है। अधिक जानकारी के लिए, देखें Microsoft डिफ़ेंडर भेद्यता प्रबंधन के साथ भेद्यता स्कैनिंग सक्षम करें.

DevSecOps का अभ्यास सुरक्षा परीक्षण को एक सतत और निरंतर सुधार मानसिकता के भाग के रूप में एकीकृत करता है। युद्ध खेल अभ्यास एक सामान्य अभ्यास है जो Microsoft में व्यवसाय की लय में एकीकृत है। अधिक जानकारी के लिए, देखें DevOps में सुरक्षा (DevSecOps).

Azure DevOps तृतीय-पक्ष उपकरणों का समर्थन करता है जिन्हें निरंतर एकीकरण/निरंतर परिनियोजन (CI/CD) पाइपलाइनों के भाग के रूप में स्वचालित किया जा सकता है। अधिक जानकारी के लिए, देखें Azure और GitHub के साथ DevSecOps सक्षम करें.

नवीनतम पैठ परीक्षण और सुरक्षा मूल्यांकन Microsoft सेवा ट्रस्ट पोर्टल पर देखे जा सकते हैं.

Microsoft क्लाउड सेवाओं का व्यापक परीक्षण करता है। इस परीक्षण में प्रवेश परीक्षण शामिल है, जिसके परिणाम आपके संगठन के सर्विस ट्रस्ट पोर्टल पर प्रकाशित किए जाते हैं। आपका संगठन Microsoft Power Platform और Microsoft Dynamics 365 सेवाओं पर अपना स्वयं का प्रवेश परीक्षण कर सकता है। सभी प्रवेश परीक्षणों में क्लाउड प्रवेश परीक्षण के नियमों का पालन किया जाना चाहिए। यह याद रखना महत्वपूर्ण है कि कई मामलों में, Microsoft क्लाउड आपकी परिसंपत्तियों और अन्य ग्राहकों की परिसंपत्तियों को होस्ट करने के लिए साझा बुनियादी ढांचे का उपयोग करता है। आपको सभी प्रवेश परीक्षणों को अपनी परिसंपत्तियों तक ही सीमित रखना चाहिए तथा अपने आस-पास के अन्य ग्राहकों के लिए अनपेक्षित परिणामों से बचना चाहिए।

यह सुनिश्चित करने के लिए कि पहुँच का दुरुपयोग न हो, नियमों का पालन करें। नकली हमलों की योजना बनाने और उन्हें क्रियान्वित करने के बारे में मार्गदर्शन के लिए देखें:

आप Azure में सेवा अस्वीकार (DoS) हमलों का अनुकरण कर सकते हैं। Azure DDoS सुरक्षा सिमुलेशन परीक्षण में निर्धारित नीतियों का पालन करना सुनिश्चित करें।

सुरक्षा जांच सूची

कृपया सिफारिशों का पूरा सेट देखें।

सुरक्षा जांच सूची