मार्गदर्शिका

अनुमोदन और औचित्य की आवश्यकता वाले विशेषाधिकार प्राप्त Azure AD भूमिकाओं तक जस्ट-इन-टाइम (JIT) एक्सेस प्रदान करें।

→भूमिका के लिए Microsoft Entra Privileged Identity Management (PIM) कॉन्फ़िगर करें। 'सक्रिय करने के लिए अनुमोदन की आवश्यकता' सेट करें, अनुमोदक निर्दिष्ट करें, 'सक्रियण पर औचित्य की आवश्यकता' सक्षम करें, और अधिकतम सक्रियण अवधि निर्धारित करें।

क्यों: PIM JIT भूमिका उन्नयन के लिए मूल Azure सेवा है। केवल एक उपयोगकर्ता को पात्र बनाना पर्याप्त नहीं है; नीति सेटिंग्स अनुमोदन और औचित्य वर्कफ़्लो को लागू करती हैं।

संदर्भ↗

संवेदनशील ऐप्स तक पहुँचने वाले सभी उपयोगकर्ताओं के लिए MFA और एक अनुपालन डिवाइस को लागू करें, लेकिन एक विशिष्ट हेल्प डेस्क समूह को डिवाइस अनुपालन नियम से छूट दें।

→दो Conditional Access (CA) नीतियां बनाएं। नीति 1 हेल्प डेस्क समूह को छोड़कर 'सभी उपयोगकर्ताओं' को लक्षित करती है, जिसके लिए MFA और एक अनुपालन डिवाइस की आवश्यकता होती है। नीति 2 केवल हेल्प डेस्क समूह को लक्षित करती है, जिसके लिए केवल MFA की आवश्यकता होती है।

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

संदर्भ↗

पहचाने गए पहचान जोखिमों पर स्वचालित रूप से प्रतिक्रिया दें: उच्च-जोखिम वाले साइन-इन को ब्लॉक करें और उच्च-जोखिम वाले उपयोगकर्ताओं के लिए पासवर्ड रीसेट लागू करें।

→दो Microsoft Entra ID Protection नीतियां कॉन्फ़िगर करें। 'साइन-इन जोखिम नीति' को उच्च जोखिम स्तर पर एक्सेस ब्लॉक करने के लिए सेट करें। 'उपयोगकर्ता जोखिम नीति' को उच्च जोखिम स्तर पर पासवर्ड परिवर्तन की आवश्यकता के लिए सेट करें।

क्यों: साइन-इन जोखिम एक एकल प्रमाणीकरण प्रयास (रीयल-टाइम) के बारे में है, जबकि उपयोगकर्ता जोखिम स्वयं पहचान (समझौता किए गए क्रेडेंशियल) के बारे में एक संचयी स्कोर है। उन्हें विभिन्न उपचार कार्यों की आवश्यकता होती है।

एक हाइब्रिड पहचान वातावरण में उपयोगकर्ताओं को अपना क्लाउड पासवर्ड रीसेट करने और इसे ऑन-प्रिमाइसेस Active Directory में वापस सिंक करने की अनुमति दें।

→Microsoft Entra Connect में, 'Password writeback' सुविधा सक्षम करें। Azure AD में, लक्षित उपयोगकर्ताओं के लिए Self-Service Password Reset (SSPR) सक्षम और कॉन्फ़िगर करें।

क्यों: SSPR पासवर्ड रीसेट के लिए क्लाउड-साइड उपयोगकर्ता इंटरफ़ेस प्रदान करता है, जबकि Password Writeback Entra Connect में वह घटक है जो नए पासवर्ड हैश को ऑन-प्रिमाइसेस AD में वापस सिंक करता है।

सभी अतिथि उपयोगकर्ता एक्सेस की समय-समय पर समीक्षा करें और उन अतिथियों को स्वचालित रूप से हटा दें जिन्हें अब अनुमोदित नहीं किया गया है या जो निष्क्रिय हैं।

→Microsoft Entra ID Governance में एक Access Review बनाएं। सभी समूहों में अतिथि उपयोगकर्ताओं को लक्षित करें, एक आवर्ती शेड्यूल (जैसे, त्रैमासिक) सेट करें, और 'परिणामों को संसाधन पर स्वतः लागू करें' सक्षम करें। वैकल्पिक रूप से, निष्क्रिय उपयोगकर्ताओं की समीक्षा करें।

क्यों: Access Reviews एक्सेस के आवधिक पुन: प्रमाणन के लिए समर्पित शासन उपकरण हैं। 'परिणामों को स्वतः लागू करें' सुविधा लूप को बंद करने और हटाने को स्वचालित करने के लिए महत्वपूर्ण है।

बाहरी भागीदारों को एक्सेस (समूह, ऐप्स, SharePoint साइटें) के बंडल का अनुरोध करने का एक स्व-सेवा तरीका प्रदान करें जो 90 दिनों के बाद स्वचालित रूप से समाप्त हो जाता है।

→Microsoft Entra Entitlement Management का उपयोग करें। पार्टनर के लिए एक Connected Organization बनाएं। संसाधनों वाला एक Access Package बनाएं। पैकेज के लिए एक नीति परिभाषित करें जो कनेक्टेड ऑर्ग के उपयोगकर्ताओं को 90-दिवसीय समाप्ति के साथ इसका अनुरोध करने की अनुमति देती है।

क्यों: Entitlement Management विशेष रूप से बाहरी उपयोगकर्ताओं के लिए, बड़े पैमाने पर एक्सेस को नियंत्रित करने के लिए डिज़ाइन किया गया है। यह संसाधनों को बंडल करता है और अनुरोध और अनुमोदन से लेकर समाप्ति और हटाने तक पूरे एक्सेस जीवनचक्र को स्वचालित करता है।

एक उच्च-सुरक्षा एप्लिकेशन के लिए उपयोगकर्ताओं को एक ऐसी विधि से प्रमाणित करने की आवश्यकता होती है जो फ़िशिंग और मैन-इन-द-मिडल हमलों के प्रति प्रतिरोधी हो।

→FIDO2 सुरक्षा कुंजी या Windows Hello for Business जैसी प्रमाणीकरण विधियों को लागू करें। ये विधियां पब्लिक-की क्रिप्टोग्राफी का उपयोग करती हैं और डिवाइस से बंधी होती हैं, जिससे क्रेडेंशियल चोरी को रोका जा सके।

क्यों: SMS, वॉयस कॉल, या साधारण पुश नोटिफिकेशन जैसी विधियां फ़िशेबल हैं। FIDO2 और WHfB क्रिप्टोग्राफिक चुनौतियों का उपयोग करते हैं जो अनुरोध के मूल से बंधी होती हैं, जिससे वे फ़िशिंग के प्रति प्रतिरोधी बन जाते हैं।

एक VM पर चल रही एक बैकग्राउंड सेवा को किसी भी उपयोगकर्ता इंटरैक्शन के बिना Microsoft Graph से सभी उपयोगकर्ता प्रोफाइल को पढ़ने की आवश्यकता है।

→Microsoft Entra ID में एप्लिकेशन को रजिस्टर करें। API अनुमतियों के तहत, इसे `User.Read.All` के लिए Microsoft Graph 'एप्लिकेशन' अनुमतियां (न कि 'Delegated') प्रदान करें। एक प्रशासक को एडमिन कंसेंट प्रदान करना होगा।

क्यों: एप्लिकेशन अनुमतियां ऐप को अपनी पहचान (क्लाइंट ID/सीक्रेट या प्रमाणपत्र) का उपयोग करके स्वयं के रूप में कार्य करने की अनुमति देती हैं। Delegated अनुमतियों के लिए एक साइन-इन उपयोगकर्ता संदर्भ की आवश्यकता होती है, जो एक गैर-इंटरैक्टिव डीमॉन ऐप में उपलब्ध नहीं है।

एक AKS क्लस्टर में एक पॉड को क्लाइंट सीक्रेट या प्रमाणपत्रों जैसे संग्रहीत क्रेडेंशियल का उपयोग किए बिना Azure Key Vault तक सुरक्षित रूप से पहुंचने की अनुमति दें।

→Azure AD Workload Identity का उपयोग करें। एक उपयोगकर्ता-असाइन की गई प्रबंधित पहचान बनाएं, K8s सेवा खाते और प्रबंधित पहचान के बीच एक Federated Identity Credential स्थापित करें, और Key Vault तक प्रबंधित पहचान पहुंच प्रदान करें।

क्यों: Workload Identity एक Kubernetes टोकन को Azure AD टोकन के लिए आदान-प्रदान करने के लिए OIDC फ़ेडरेशन का उपयोग करती है, जिससे क्लस्टर में सीक्रेट को स्टोर करने, प्रबंधित करने या घुमाने की आवश्यकता पूरी तरह समाप्त हो जाती है।

संदर्भ↗

एक Azure Key Vault को सुरक्षित करें ताकि केवल विशिष्ट VNets से एक्सेस की अनुमति दी जा सके, सभी ऑपरेशंस को लॉग करें, और महत्वपूर्ण कुंजियों के आकस्मिक विलोपन से बचाएं।

→Key Vault फ़ायरवॉल को 'निजी एंडपॉइंट और चयनित नेटवर्क' से एक्सेस की अनुमति देने के लिए कॉन्फ़िगर करें। Log Analytics वर्कस्पेस में डायग्नोस्टिक लॉगिंग सक्षम करें। Soft Delete और Purge Protection दोनों को सक्षम करें।

क्यों: Soft Delete आकस्मिक विलोपन से रिकवरी की अनुमति देता है, लेकिन Purge Protection एक विशेषाधिकार प्राप्त उपयोगकर्ता को भी रिटेंशन अवधि के दौरान वॉल्ट या उसकी सामग्री को स्थायी रूप से हटाने से रोकता है। TDE कुंजियों की सुरक्षा के लिए यह संयोजन महत्वपूर्ण है।

एक Azure App Service को कॉन्फ़िगरेशन में कनेक्शन स्ट्रिंग पासवर्ड संग्रहीत किए बिना डेटा पुनर्प्राप्त करने के लिए Azure SQL Database पर प्रमाणीकरण करने की आवश्यकता है।

→App Service पर एक सिस्टम-असाइन की गई प्रबंधित पहचान सक्षम करें। Azure SQL में, App Service के प्रबंधित पहचान नाम पर मैप किया गया एक निहित उपयोगकर्ता बनाएं और उसे आवश्यक डेटाबेस भूमिकाएँ (जैसे, db_datareader) प्रदान करें।

क्यों: Managed Identity Azure AD में Azure संसाधन के लिए स्वयं एक पहचान प्रदान करती है। Azure क्रेडेंशियल निर्माण और रोटेशन को स्वचालित रूप से संभालता है, जिससे संग्रहीत सीक्रेट समाप्त हो जाते हैं, जो एक प्रमुख सुरक्षा सर्वोत्तम अभ्यास है।

Azure Key Vault में आपके संगठन द्वारा नियंत्रित कुंजी का उपयोग करके Azure VM प्रबंधित डिस्क को स्थिर अवस्था में एन्क्रिप्ट करें।

→एक Disk Encryption Set संसाधन बनाएं। इसे आपके Azure Key Vault से एक ग्राहक-प्रबंधित कुंजी (CMK) का उपयोग करने के लिए कॉन्फ़िगर करें। VM के प्रबंधित डिस्क को Disk Encryption Set असाइन करें।

क्यों: यह CMK के साथ Server-Side Encryption (SSE) है, जो स्टोरेज इंफ्रास्ट्रक्चर में डेटा को एन्क्रिप्ट करता है। यह Azure Disk Encryption (ADE) की तुलना में सरल है, जो गेस्ट OS के अंदर डेटा को एन्क्रिप्ट करने के लिए BitLocker/dm-crypt का उपयोग करता है और आमतौर पर OS और डेटा डिस्क के लिए एक साथ उपयोग किया जाता है।

यह सुनिश्चित करें कि Azure Container Registry (ACR) में संग्रहीत कंटेनर छवियों को डिप्लॉय करने से पहले कमजोरियों के लिए स्कैन किया जाता है।

→Microsoft Defender for Containers सक्षम करें। यह ACR में छवियों को स्वचालित रूप से स्कैन करेगा जब उन्हें पुश किया जाता है, जब उन्हें खींचा जाता है, और नई खोजी गई कमजोरियों के लिए निरंतर आधार पर।

क्यों: यह 'शिफ्ट-लेफ्ट' सुरक्षा अभ्यास CI/CD पाइपलाइन में कमजोरियों की पहचान जल्दी करता है। Defender for Containers Azure इकोसिस्टम के भीतर मूल रूप से यह स्कैनिंग क्षमता प्रदान करता है।

Azure SQL Database पर संभावित SQL इंजेक्शन हमलों और असामान्य एक्सेस पैटर्न के लिए अलर्ट का पता लगाएं और प्राप्त करें।

→लॉजिकल SQL सर्वर पर Microsoft Defender for SQL सक्षम करें। यह उन्नत खतरे की सुरक्षा और भेद्यता मूल्यांकन प्रदान करता है।

क्यों: Defender for SQL समर्पित वर्कलोड सुरक्षा योजना है जो SQL इंजेक्शन, ब्रूट फोर्स हमलों और असामान्य डेटा एक्सेस जैसे खतरों का पता लगाने के लिए व्यवहार विश्लेषण और मशीन लर्निंग का उपयोग करती है, जो नेटवर्क-स्तरीय उपकरणों के लिए दृश्यमान नहीं हैं।

एक स्टोरेज खाते को एक विशिष्ट VNet तक सीमित करें, लेकिन फिर भी Azure Backup जैसी विश्वसनीय Microsoft सेवाओं को उस तक पहुंचने की अनुमति दें।

→स्टोरेज खाता नेटवर्किंग सेटिंग्स में, 'चयनित वर्चुअल नेटवर्क और IP एड्रेस से सक्षम' का चयन करें। आवश्यक VNet/सबनेट जोड़ें। फिर, 'इस स्टोरेज खाते तक पहुंचने के लिए विश्वसनीय Microsoft सेवाओं की अनुमति दें' के लिए बॉक्स को चेक करें।

क्यों: विश्वसनीय सेवाओं का अपवाद विशिष्ट Microsoft सेवाओं के लिए VNet फ़ायरवॉल नियमों को बायपास करने के लिए एक सुरक्षित मार्ग बनाता है। इसके बिना, उपयोगकर्ता की ओर से संचालित होने वाली सेवाएं (जैसे Backup या Portal) ब्लॉक हो जाएंगी।

एक Azure SQL डेटाबेस में विशिष्ट संवेदनशील डेटा कॉलम (जैसे, क्रेडिट कार्ड नंबर) को सुरक्षित रखें, यहां तक कि विशेषाधिकार प्राप्त डेटाबेस प्रशासकों (DBAs) से भी।

→Always Encrypted का उपयोग करें। क्लाइंट एप्लिकेशन ड्राइवर डेटा को डेटाबेस में भेजने से पहले उसे पारदर्शी रूप से एन्क्रिप्ट करता है, और एन्क्रिप्शन कुंजी कभी भी डेटाबेस इंजन को प्रकट नहीं की जाती हैं।

क्यों: Transparent Data Encryption (TDE) पूरे डेटाबेस को स्थिर अवस्था में (डिस्क पर) एन्क्रिप्ट करता है, लेकिन एक्सेस वाला एक DBA अभी भी डेटा देख सकता है। Always Encrypted क्लाइंट-साइड एन्क्रिप्शन प्रदान करता है, डेटा का प्रबंधन करने वालों (DBAs) को उसे देखने वालों से अलग करता है।

एक Azure VM पर अत्यधिक संवेदनशील डेटा को प्रोसेस करें, यह सुनिश्चित करते हुए कि यह हाइपरवाइजर और क्लाउड ऑपरेटरों से मेमोरी में भी एन्क्रिप्टेड और सुरक्षित रहता है।

→एक Azure Confidential VM डिप्लॉय करें। ये VMs एक पृथक, एन्क्रिप्टेड मेमोरी स्पेस बनाने के लिए AMD SEV-SNP जैसे हार्डवेयर-आधारित Trusted Execution Environments (TEEs) का उपयोग करते हैं।

क्यों: Standard VM एन्क्रिप्शन (जैसे ADE या SSE) डेटा को स्थिर अवस्था में सुरक्षित रखता है। Confidential Computing एकमात्र ऐसी तकनीक है जो मेमोरी में *उपयोग के दौरान* डेटा को सुरक्षित रखती है, जो क्लाउड में डेटा गोपनीयता और अलगाव का उच्चतम स्तर प्रदान करती है।

एक App Service को Key Vault से एक सीक्रेट को एप्लिकेशन सेटिंग के रूप में उपयोग करने की आवश्यकता है, एप्लिकेशन कोड को Key Vault SDK का उपयोग करने के लिए बदले बिना।

→App Service पर प्रबंधित पहचान सक्षम करें और इसे Key Vault में सीक्रेट पर 'Get' अनुमतियां प्रदान करें। App Service कॉन्फ़िगरेशन में, Key Vault संदर्भ के रूप में स्वरूपित मान के साथ एक एप्लिकेशन सेटिंग बनाएं: `@Microsoft.KeyVault(SecretUri=...)`।

क्यों: यह सुविधा App Service प्लेटफॉर्म को प्रबंधित पहचान का उपयोग करके रनटाइम पर सीक्रेट मान को हल करने की अनुमति देती है। एप्लिकेशन कोड बस एक मानक पर्यावरण चर को पढ़ता है, Key Vault इंटरैक्शन को अमूर्त करता है।

अनुपालन-संबंधित डेटा को Azure Blob Storage में 7-वर्ष की रिटेंशन अवधि के लिए WORM (Write-Once, Read-Many) स्थिति में संग्रहीत करें।

→स्टोरेज कंटेनर पर, एक immutability नीति कॉन्फ़िगर करें। 7 साल के लिए निर्धारित एक समय-आधारित रिटेंशन नीति का उपयोग करें और नीति को लॉक करें। एक बार लॉक होने के बाद, डेटा को रिटेंशन अवधि समाप्त होने तक किसी भी व्यक्ति द्वारा संशोधित या हटाया नहीं जा सकता है।

क्यों: यह सुविधा विशेष रूप से नियामक अनुपालन आवश्यकताओं (जैसे, SEC 17a-4) को पूरा करने के लिए डिज़ाइन की गई है। नीति को लॉक करना महत्वपूर्ण कदम है जो इसे वास्तव में अपरिवर्तनीय बनाता है।

एक एकल Azure SQL डेटाबेस का उपयोग करने वाले बहु-किरायेदार एप्लिकेशन में, यह सुनिश्चित करें कि एक किरायेदार के उपयोगकर्ता केवल अपने स्वयं के किरायेदार से संबंधित डेटा देख सकते हैं।

→Row-Level Security (RLS) लागू करें। एक प्रेडिकेट फ़ंक्शन के साथ एक सुरक्षा नीति बनाएं जो उपयोगकर्ता के किरायेदार ID के आधार पर पंक्तियों को फ़िल्टर करती है, जो सत्र संदर्भ या उपयोगकर्ता लुकअप तालिका में संग्रहीत होती है।

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

UEFI से OS कर्नेल तक पूरी बूट चेन की अखंडता सुनिश्चित करके बूट किट और रूटकिट के खिलाफ जनरेशन 2 VMs को सुरक्षित रखें।

→Trusted Launch सक्षम के साथ VM को प्रोविज़न करें। यह Secure Boot को सक्रिय करता है, जो सभी बूट घटकों के हस्ताक्षर को मान्य करता है, और measured boot और अटेंशन के लिए एक वर्चुअल Trusted Platform Module (vTPM) को सक्रिय करता है।

क्यों: Trusted Launch परिष्कृत, निम्न-स्तरीय मैलवेयर को संबोधित करता है जो पारंपरिक OS-स्तरीय सुरक्षा नियंत्रणों को विफल कर सकता है। यह VM के लिए विश्वास का एक हार्डवेयर रूट स्थापित करता है।

अलग-अलग सबनेट में होस्ट किए गए एप्लिकेशन टियर (वेब, ऐप, डेटा) के बीच ट्रैफ़िक को अलग करें।

→प्रत्येक सबनेट के लिए एक समर्पित Network Security Group (NSG) बनाएं। प्रत्येक NSG में, इनबाउंड नियम बनाएं जो केवल पिछले टियर के स्रोत IP रेंज से आवश्यक पोर्ट पर ट्रैफ़िक की अनुमति देते हैं। (उदाहरण के लिए, App-tier NSG वेब-टियर सबनेट से TCP/8080 की अनुमति देता है)।

क्यों: प्रत्येक सबनेट पर एक अद्वितीय, न्यूनतम-विशेषाधिकार NSG लागू करने से गहराई में सुरक्षा मिलती है और पूर्व-पश्चिम ट्रैफ़िक प्रवाह पर दानेदार नियंत्रण मिलता है, जो VNet के लिए एक एकल, जटिल NSG की तुलना में अधिक सुरक्षित है।

एक हब-स्पोक टोपोलॉजी में, स्पोक VNets के बीच सभी ट्रैफ़िक को हब में एक NVA या Azure Firewall द्वारा निरीक्षण के लिए बाध्य करें।

→प्रत्येक स्पोक सबनेट पर, अन्य स्पोक के एड्रेस स्पेस के लिए एक User Defined Route (UDR) बनाएं, जिसमें अगला हॉप प्रकार 'VirtualAppliance' और NVA/Firewall का IP हो। NVA के NIC पर IP फ़ॉरवर्डिंग सक्षम करें।

क्यों: डिफ़ॉल्ट रूप से, VNet पीयरिंग स्पोक को सीधे संचार करने की अनुमति देती है। UDRs इस डिफ़ॉल्ट रूटिंग व्यवहार को ओवरराइड करते हैं, जिससे ट्रैफ़िक केंद्रीय निरीक्षण बिंदु पर जाता है।

अपने VNet के अंदर एक निजी IP एड्रेस के साथ एक PaaS सेवा (जैसे, Azure SQL, Storage) प्रदान करें, यह सुनिश्चित करते हुए कि ट्रैफ़िक कभी भी सार्वजनिक इंटरनेट पर नहीं जाता है।

→अपने VNet में PaaS सेवा के लिए एक Private Endpoint बनाएं। महत्वपूर्ण रूप से, PaaS सेवा की नेटवर्किंग सेटिंग्स में, सार्वजनिक एंडपॉइंट को ब्लॉक करने के लिए सार्वजनिक नेटवर्क एक्सेस को अक्षम करें।

क्यों: एक Private Endpoint सेवा को एक निजी IP के साथ आपके VNet में लाता है। एक Service Endpoint सार्वजनिक IP तक Azure बैकबोन पर मार्ग को अनुकूलित करता है। केवल निजी संचार को लागू करने के लिए सार्वजनिक एक्सेस को अक्षम करना आवश्यक है।

IP सूचियों को मैन्युअल रूप से बनाए बिना VMs से Microsoft सेवा एंडपॉइंट्स, जैसे Windows Update, के एक गतिशील सेट पर आउटबाउंड ट्रैफ़िक की अनुमति दें।

→Azure Firewall में, एक Application Rule कलेक्शन बनाएं। लक्ष्य FQDN प्रकार को 'FQDN Tag' पर सेट करें और 'WindowsUpdate' टैग का चयन करें।

क्यों: FQDN Tags FQDNs के क्यूरेटेड कलेक्शन हैं जिन्हें Microsoft प्रबंधित करता है। PaaS सेवाओं तक पहुँचने की अनुमति देने का यह सही तरीका है जिनके अंतर्निहित IP अक्सर बदलते रहते हैं। Service Tags IP-आधारित नियमों के लिए हैं।

एक Web Application Firewall (WAF) एक प्रबंधित नियम (जैसे, SQL इंजेक्शन) में गलत सकारात्मक के कारण आपके एप्लिकेशन पर वैध ट्रैफ़िक को ब्लॉक कर रहा है।

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

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

इंटरनेट पर प्रबंधन पोर्ट को उजागर किए बिना या VMs पर सार्वजनिक IP की आवश्यकता के बिना Azure VMs तक सुरक्षित RDP/SSH एक्सेस प्रदान करें।

→Azure Bastion (उन्नत सुविधाओं के लिए Standard SKU) को VNet में एक समर्पित सबनेट में डिप्लॉय करें। Azure पोर्टल के माध्यम से VMs तक पहुँचें, जो Bastion सेवा के माध्यम से जुड़ता है।

क्यों: Bastion एक सुरक्षित जंप बॉक्स के रूप में कार्य करता है, RDP/SSH कनेक्शन को ब्रोकर करता है। केवल सार्वजनिक IP स्वयं Bastion सेवा पर है, जिसे Microsoft द्वारा कठोर और प्रबंधित किया जाता है, जिससे आपके VMs के अटैक सतह को नाटकीय रूप से कम किया जा सके।

डेवलपमेंट VMs पर प्रबंधन पोर्ट (RDP/SSH) तक डेवलपर्स को समय-सीमित, ऑडिटेड एक्सेस प्रदान करें।

→Microsoft Defender for Cloud सक्षम करें और VMs के लिए Just-in-Time (JIT) VM एक्सेस कॉन्फ़िगर करें। उपयोगकर्ता Defender for Cloud के माध्यम से एक्सेस का अनुरोध करेंगे, जो एक विशिष्ट IP से सीमित समय के लिए एक्सेस की अनुमति देने के लिए NSG नियमों को गतिशील रूप से संशोधित करता है।

क्यों: JIT Defender for Cloud की एक मुख्य विशेषता है जो डिफ़ॉल्ट रूप से प्रबंधन पोर्ट को बंद रखकर VMs की नेटवर्क स्थिति को कठोर करती है, उन्हें केवल मांग पर खोलती है।

डिप्लॉयमेंट के समय एक Azure Kubernetes Service (AKS) क्लस्टर पर सुरक्षा सर्वोत्तम प्रथाओं, जैसे विशेषाधिकार प्राप्त कंटेनरों की अनुमति न देना, को लागू करें।

→AKS के लिए Azure Policy ऐड-ऑन सक्षम करें। 'Linux-आधारित वर्कलोड के लिए Kubernetes क्लस्टर पॉड सुरक्षा प्रतिबंधित मानक' नामक बिल्ट-इन नीति पहल असाइन करें।

क्यों: यह Azure Policy का उपयोग Kubernetes के लिए एक केंद्रीकृत, बड़े पैमाने पर प्रवेश नियंत्रक के रूप में करता है, वर्कलोड को क्लस्टर में बनाए जाने से पहले सुरक्षा और अनुपालन गार्डरेल्स को लागू करता है।

Azure VNet से सभी इंटरनेट-बाउंड ट्रैफ़िक को इंटरनेट तक पहुंचने से पहले निरीक्षण के लिए एक ऑन-प्रिमाइसेस सुरक्षा उपकरण पर वापस रूट करें।

→एक साइट-टू-साइट VPN या ExpressRoute कॉन्फ़िगर करें। एड्रेस प्रीफिक्स 0.0.0.0/0 के लिए एक User Defined Route (UDR) बनाएं, और अगले हॉप को Virtual Network Gateway पर सेट करें।

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

Azure Firewall का उपयोग करके खतरों के लिए VMs से आउटबाउंड TLS-एन्क्रिप्टेड ट्रैफ़िक का निरीक्षण करें।

→Azure Firewall Premium डिप्लॉय करें। TLS Inspection और Intrusion Detection (IDPS) सक्षम करें। Firewall पर एक अधीनस्थ CA प्रमाणपत्र कॉन्फ़िगर करें और इसकी सार्वजनिक कुंजी को क्लाइंट VMs पर एक विश्वसनीय रूट CA के रूप में डिप्लॉय करें।

क्यों: एन्क्रिप्टेड ट्रैफ़िक का निरीक्षण करने के लिए, फ़ायरवॉल को मैन-इन-द-मिडल ऑपरेशन करना होगा। इसके लिए प्रीमियम SKU, खतरे का पता लगाने के लिए IDPS, और क्लाइंट मशीनों पर TLS त्रुटियों से बचने के लिए एक उचित प्रमाणपत्र इन्फ्रास्ट्रक्चर की आवश्यकता होती है।

लागत प्रभावी तरीके से कई VNets और सब्सक्रिप्शन में सभी सार्वजनिक-सामने वाले अनुप्रयोगों को वॉल्यूमेट्रिक DDoS हमलों से बचाएं।

→एक एकल Azure DDoS Protection Plan बनाएं। इस एक योजना को उन सभी वर्चुअल नेटवर्क से जोड़ें जिनमें सार्वजनिक IP एड्रेस हैं जिन्हें सुरक्षा की आवश्यकता है।

क्यों: एक एकल DDoS Protection Plan 100 VNets तक कवर कर सकता है, और आप योजना के लिए एक निश्चित मासिक शुल्क का भुगतान करते हैं, न कि प्रति VNet या प्रति IP। यह केंद्रीकृत मॉडल कई योजनाओं को डिप्लॉय करने या प्रति-IP सुरक्षा SKU का उपयोग करने की तुलना में बहुत अधिक लागत प्रभावी है।

जब Microsoft Sentinel में एक उच्च-गंभीरता वाली घटना बनाई जाती है, तो Azure AD में शामिल उपयोगकर्ता खाते को स्वचालित रूप से अक्षम करें और Teams में सुरक्षा टीम को सूचित करें।

→एक Automation Rule बनाएं जो उच्च-गंभीरता वाली घटना निर्माण पर ट्रिगर होता है। नियम को एक Playbook (Logic App) को कॉल करना चाहिए। प्लेबुक उपयोगकर्ता को अक्षम करने के लिए Azure AD कनेक्टर और एक संदेश पोस्ट करने के लिए Teams कनेक्टर का उपयोग करता है।

क्यों: यह SOAR (Security Orchestration, Automation, and Response) पैटर्न को प्रदर्शित करता है। Automation Rule ट्रिगर/कंडीशन इंजन है, और Playbook एक्शन/वर्कफ़्लो इंजन है।

संदर्भ↗

Azure सब्सक्रिप्शन की एक बड़ी संख्या में सुरक्षा नीतियों का एक सुसंगत सेट लागू करें और Defender for Cloud योजनाओं को सक्षम करें।

→सभी सब्सक्रिप्शन को एक Management Group के तहत व्यवस्थित करें। Azure Security Benchmark नीति पहल असाइन करें और प्रबंधन समूह स्तर पर आवश्यक Defender for Cloud योजनाओं को सक्षम करें।

क्यों: Management Groups एंटरप्राइज़-स्केल गवर्नेंस के लिए प्राथमिक उपकरण हैं। इस स्तर पर लागू की गई नीतियां और सेटिंग्स सभी चाइल्ड सब्सक्रिप्शन द्वारा विरासत में मिलती हैं, जिससे निरंतरता सुनिश्चित होती है और प्रशासनिक ओवरहेड कम होता है।

पहली बार किसी नए देश से साइन इन करने वाले उपयोगकर्ता के लिए Sentinel में एक कस्टम डिटेक्शन बनाएं।

→एक Scheduled query analytics rule बनाएं। एक KQL क्वेरी का उपयोग करें जो हाल के `SigninLogs` को पिछले `SigninLogs` के सारांशित इतिहास के साथ जोड़ता है ताकि UserPrincipalName/Country संयोजनों की पहचान की जा सके जो पहले नहीं देखे गए थे।

क्यों: KQL के साथ Scheduled query rules Sentinel में कस्टम खतरे का पता लगाने का आधार हैं, जो जटिल, स्टेटफुल लॉजिक की अनुमति देते हैं जो साधारण इवेंट मिलान से परे जाता है।

अनुपालन के लिए Sentinel में सुरक्षा लॉग को 2 साल तक बनाए रखें, लेकिन लागतों का प्रबंधन करने के लिए तेज़, इंटरैक्टिव प्रश्नों के लिए केवल सबसे हाल के 90 दिनों को उपलब्ध रखें।

→Log Analytics वर्कस्पेस में, 'Interactive Retention' को 90 दिनों पर सेट करें। 'Total retention' (Archive) को 730 दिनों (2 साल) पर सेट करें। यदि आवश्यक हो तो प्रति-तालिका रिटेंशन नीतियां कॉन्फ़िगर करें।

क्यों: यह स्तरीय दृष्टिकोण लागत और क्षमता को संतुलित करता है। इंटरैक्टिव टियर महंगा लेकिन तेज़ है। दीर्घकालिक स्टोरेज के लिए आर्काइव टियर बहुत कम लागत वाला है। संग्रहीत डेटा को अभी भी एसिंक्रोनस Search Jobs के माध्यम से क्वेरी किया जा सकता है या अस्थायी रूप से पुनर्स्थापित किया जा सकता है।

एक घटना की जांच के दौरान, आपको एक समझौता किए गए उपयोगकर्ता, जिस IP से उन्होंने साइन इन किया था, और उन संसाधनों के बीच संबंधों को तुरंत कल्पना करने की आवश्यकता है जिन तक उन्होंने पहुंच बनाई थी।

→Microsoft Sentinel में घटना पृष्ठ से, Investigation Graph खोलें। विभिन्न अलर्ट और लॉग स्रोतों में संस्थाओं और उनके कनेक्शन को देखने के लिए ग्राफ का उपयोग करें।

क्यों: Investigation Graph एक शक्तिशाली विज़ुअलाइज़ेशन टूल है जो हमले की कहानी को मैप करता है, जिससे मैन्युअल रूप से लॉग प्रश्नों में घटनाओं को सहसंबंधित करने की तुलना में किसी घटना के दायरे और समयरेखा को समझना बहुत आसान हो जाता है।

एक हमलावर का पता लगाएं जिसने एक उपयोगकर्ता खाते से समझौता किया है और अब नेटवर्क के भीतर असामान्य संसाधनों या होस्ट तक पहुंचने का प्रयास कर रहा है।

→सुनिश्चित करें कि Microsoft Sentinel में User and Entity Behavior Analytics (UEBA) सक्षम है और संबंधित डेटा स्रोत (Azure AD लॉग, Defender for Endpoint/Security Events) जुड़े हुए हैं। Lateral Movement से संबंधित विसंगति detections के लिए UEBA की निगरानी करें।

क्यों: UEBA प्रत्येक उपयोगकर्ता और इकाई के लिए सामान्य व्यवहार का एक आधारभूत निर्माण करता है। यह उन विचलनों का पता लगाने में उत्कृष्ट है जो lateral movement को इंगित करते हैं, जैसे कि एक उपयोगकर्ता पहली बार एक सर्वर तक पहुंच रहा है या असामान्य प्रोटोकॉल का उपयोग कर रहा है, जिन्हें स्थैतिक नियमों के साथ पहचानना मुश्किल है।

उच्च-मात्रा, वर्बोज़ लॉग के लिए Microsoft Sentinel अंतर्ग्रहण लागतों को कम करें जो अनुपालन के लिए आवश्यक हैं लेकिन रीयल-टाइम एनालिटिक्स के लिए नहीं।

→इन लॉग के लिए तालिका योजना को 'Basic Logs' पर कॉन्फ़िगर करें। इसके अतिरिक्त, अंतर्ग्रहण से पहले शोरगुल वाले, कम-मूल्य वाले इवेंट्स को फ़िल्टर करने के लिए XPath प्रश्नों या अन्य परिवर्तनों के साथ Data Collection Rules (DCRs) का उपयोग करें।

क्यों: Basic Logs सीमित क्वेरी क्षमताओं और छोटी रिटेंशन के बदले में काफी कम अंतर्ग्रहण लागत प्रदान करते हैं। DCRs के साथ स्रोत पर फ़िल्टरिंग वॉल्यूम को कम करने का सबसे प्रभावी तरीका है ताकि अवांछित डेटा को वर्कस्पेस तक पहुंचने से रोका जा सके।

सभी मौजूदा और नए Azure Storage खातों पर 'सुरक्षित स्थानांतरण आवश्यक' सक्षम करने जैसी सुरक्षा सेटिंग को स्वचालित रूप से लागू करें।

→ `DeployIfNotExists` या `Modify` प्रभाव के साथ एक Azure Policy असाइन करें। मौजूदा गैर-अनुपालन संसाधनों के लिए, परिवर्तन लागू करने के लिए नीति अनुपालन ब्लेड से एक remediation कार्य बनाएं।

क्यों: Audit और Deny नीतियां केवल गैर-अनुपालन की रिपोर्ट करती हैं या उसे ब्लॉक करती हैं। `DeployIfNotExists` और remediation कार्यों के साथ `Modify` गलत कॉन्फ़िगरेशन को सक्रिय रूप से ठीक करते हैं, जिससे नीति स्वचालित शासन और सुरक्षा कठोरता के लिए एक शक्तिशाली उपकरण बन जाती है।

एक AKS क्लस्टर में रनटाइम खतरों का पता लगाएं, जैसे संदिग्ध प्रक्रिया निष्पादन या एक कंटेनर एक ज्ञात दुर्भावनापूर्ण IP से जुड़ रहा है।

→Microsoft Defender for Containers सक्षम करें। यह क्लस्टर में प्रत्येक नोड पर एक DaemonSet (Defender एजेंट) डिप्लॉय करता है, जो होस्ट और कंटेनरों से सुरक्षा संकेतों को एकत्र करता है ताकि रीयल-टाइम खतरे का पता लगाया जा सके।

क्यों: जबकि ACR स्कैनिंग 'शिफ्ट-लेफ्ट' सुरक्षा प्रदान करती है, रनटाइम सुरक्षा पोस्ट-डिप्लॉयमेंट होने वाले खतरों का पता लगाने के लिए महत्वपूर्ण है। Defender for Containers क्लस्टर के भीतर होस्ट और वर्कलोड स्तर पर यह दृश्यता प्रदान करता है।