Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -9,7 +9,7 @@
 ### Management Groups
 
 - यह **अन्य प्रबंधन समूहों या सदस्यताओं** को समाहित कर सकता है।
-- यह **प्रबंधन समूह स्तर पर शासन नियंत्रण** जैसे RBAC और Azure नीति को लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा **विरासत में** प्राप्त किया जाता है।
+- यह **प्रबंधन समूह स्तर पर शासन नियंत्रण** जैसे RBAC और Azure नीति को एक बार लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा **विरासत में** लिया जाता है।
 - **10,000 प्रबंधन** समूह एकल निर्देशिका में समर्थित हो सकते हैं।
 - एक प्रबंधन समूह का पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
 - प्रत्येक प्रबंधन समूह और सदस्यता **केवल एक माता-पिता** का समर्थन कर सकती है।
@@ -24,11 +24,11 @@
 - यह एक और **तार्किक कंटेनर है जहां संसाधन** (VMs, DBs…) चलाए जा सकते हैं और बिल किया जाएगा।
 - इसका **माता-पिता** हमेशा एक **प्रबंधन समूह** होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सदस्यताएँ अन्य सदस्यताओं को समाहित नहीं कर सकती हैं।
 - यह **केवल एक Entra ID** निर्देशिका पर भरोसा करता है।
-- सदस्यता स्तर (या इसके किसी भी माता-पिता) पर लागू **अनुमतियाँ** सभी संसाधनों पर **विरासत में** मिलती हैं।
+- सदस्यता स्तर (या इसके किसी भी माता-पिता) पर लागू **अनुमतियाँ** सभी संसाधनों पर **विरासत में** ली जाती हैं।
 
 ### Resource Groups
 
-[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) एक संसाधन समूह एक **कंटेनर** है जो एक Azure समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, उन **संसाधनों** को एक ही संसाधन समूह में जोड़ें जो **एक ही जीवन चक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
+[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) एक संसाधन समूह एक **कंटेनर** है जो एक Azure समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, **संसाधनों** को उसी संसाधन समूह में जोड़ें जो **एक ही जीवनचक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटाकर प्रबंधित कर सकें।
 
 सभी **संसाधन** को **एक संसाधन समूह के भीतर** होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
 
@@ -50,11 +50,11 @@ Azure Resource ID का प्रारूप इस प्रकार है:
 
 ### Azure
 
-Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं** की एक विस्तृत श्रृंखला प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे का निर्माण करने और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
+Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो एक विस्तृत श्रृंखला की सेवाएँ** प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता, और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे का निर्माण करने, और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
 
 ### Entra ID (पूर्व में Azure Active Directory)
 
-Entra ID एक क्लाउड-आधारित **पहचान और पहुंच प्रबंधन सेवा** है जिसे प्रमाणीकरण, प्राधिकरण और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी Microsoft सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
+Entra ID एक क्लाउड-आधारित **पहचान और पहुंच प्रबंधन सेवा** है जिसे प्रमाणीकरण, प्राधिकरण, और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure, और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी Microsoft सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
 
 ### Entra Domain Services (पूर्व में Azure AD DS)
 
@@ -65,21 +65,21 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 ### Users
 
 - **नए उपयोगकर्ता**
-- चयनित टेनेट से ईमेल नाम और डोमेन का संकेत दें
-- डिस्प्ले नाम का संकेत दें
-- पासवर्ड का संकेत दें
-- गुणों का संकेत दें (पहला नाम, नौकरी का शीर्षक, संपर्क जानकारी…)
+- चयनित टेनेट से ईमेल नाम और डोमेन निर्दिष्ट करें
+- प्रदर्शन नाम निर्दिष्ट करें
+- पासवर्ड निर्दिष्ट करें
+- गुण निर्दिष्ट करें (पहला नाम, नौकरी का शीर्षक, संपर्क जानकारी…)
 - डिफ़ॉल्ट उपयोगकर्ता प्रकार “**सदस्य**” है
 - **बाहरी उपयोगकर्ता**
-- आमंत्रित करने के लिए ईमेल और डिस्प्ले नाम का संकेत दें (यह एक गैर-माइक्रोसॉफ्ट ईमेल हो सकता है)
-- गुणों का संकेत दें
+- आमंत्रित करने के लिए ईमेल और प्रदर्शन नाम निर्दिष्ट करें (यह एक गैर-माइक्रोसॉफ्ट ईमेल हो सकता है)
+- गुण निर्दिष्ट करें
 - डिफ़ॉल्ट उपयोगकर्ता प्रकार “**अतिथि**” है
 
 ### Members & Guests Default Permissions
 
 आप उन्हें [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) में देख सकते हैं लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:
 
-- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं और उनके सार्वजनिक गुणों को पढ़ें
+- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं, और उनके सार्वजनिक गुणों को पढ़ें
 - अतिथियों को आमंत्रित करें (_बंद किया जा सकता है_)
 - सुरक्षा समूह बनाएं
 - गैर-छिपे समूह सदस्यताओं को पढ़ें
@@ -99,7 +99,7 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 - Microsoft Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट **नहीं**
 - यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
 - उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट **हाँ**
-- उपयोगकर्ता को साइन इन रखने का विकल्प दिखाएं: डिफ़ॉल्ट **हाँ**
+- उपयोगकर्ता को साइन इन रखे: डिफ़ॉल्ट **हाँ**
 - उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
 - अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट **हाँ** (Microsoft Graph के माध्यम से)
 - **अतिथि**
@@ -157,25 +157,25 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 
 ### Default Consent Permissions
 
-**User consent for applications**
+**अनुप्रयोगों के लिए उपयोगकर्ता सहमति**
 
 - **उपयोगकर्ता सहमति की अनुमति न दें**
 - सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
 - **सत्यापित प्रकाशकों से ऐप्स के लिए चयनित अनुमतियों के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
-- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स या इस संगठन में पंजीकृत ऐप्स के लिए।
+- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स के लिए या इस संगठन में पंजीकृत ऐप्स के लिए।
 - **डिफ़ॉल्ट** कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
 - User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
 - offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे एक्सेस करने की अनुमति दी है
 - openid - उपयोगकर्ताओं को साइन इन करें
 - profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
 - email - उपयोगकर्ता के ईमेल पते को देखें
-- **ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
+- **अनुप्रयोगों के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
 - सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच प्राप्त करने के लिए सहमति दे सकते हैं।
 
-**Admin consent requests**: डिफ़ॉल्ट **नहीं**
+**प्रशासक सहमति अनुरोध**: डिफ़ॉल्ट **नहीं**
 
 - उपयोगकर्ता उन ऐप्स के लिए प्रशासक सहमति का अनुरोध कर सकते हैं जिनके लिए वे सहमति नहीं दे सकते
-- यदि **हाँ**: यह संकेत देना संभव है कि उपयोगकर्ता, समूह और भूमिकाएँ अनुरोधों के लिए सहमति दे सकती हैं
+- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को निर्दिष्ट करें जो अनुरोधों पर सहमति दे सकते हैं
 - यह भी कॉन्फ़िगर करें कि क्या उपयोगकर्ताओं को ईमेल सूचनाएँ और समाप्ति अनुस्मारक प्राप्त होंगे
 
 ### **Managed Identity (Metadata)**
@@ -184,10 +184,10 @@ Azure Active Directory में प्रबंधित पहचानें
 
 प्रबंधित पहचान के दो प्रकार हैं:
 
-- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जिसे उस सदस्यता द्वारा विश्वसनीय किया जाता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, तो Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
-- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID में एक सेवा प्रमुख बनाया जाएगा जिसे सदस्यता द्वारा विश्वसनीय किया जाता है। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) पर असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान उन संसाधनों से अलग से प्रबंधित की जाती है जो इसका उपयोग करती हैं**।
+- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जो उस सदस्यता द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, तो Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
+- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID में एक सेवा प्रमुख बनाया जाएगा जो सदस्यता द्वारा विश्वसनीय होता है। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) को असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान उन संसाधनों से अलग से प्रबंधित की जाती है जो इसका उपयोग करती हैं**।
 
-प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से जुड़े इसे एक्सेस किया जा सके।
+प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से इसे एक्सेस किया जा सके।
 
 ### Enterprise Applications
 
@@ -197,7 +197,7 @@ Azure Active Directory में प्रबंधित पहचानें
 
 ### Administrative Units
 
-प्रशासनिक इकाइयाँ **एक संगठन के विशिष्ट भाग पर एक भूमिका से अनुमतियाँ देने** की अनुमति देती हैं।
+प्रशासनिक इकाइयाँ **एक संगठन के विशिष्ट हिस्से पर एक भूमिका से अनुमतियाँ देने** की अनुमति देती हैं।
 
 उदाहरण:
 
@@ -223,9 +223,9 @@ Azure Active Directory में प्रबंधित पहचानें
 
 **भूमिकाएँ** **प्रमुखों** को **स्कोप** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
 
-**भूमिकाएँ** जो **समूहों** को असाइन की जाती हैं, समूह के सभी **सदस्यों** द्वारा **विरासत में** प्राप्त की जाती हैं।
+**भूमिकाएँ** जो **समूहों** को असाइन की जाती हैं, समूह के सभी **सदस्यों** द्वारा **विरासत में** ली जाती हैं।
 
-स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** मिल सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा जो सदस्यता के भीतर सभी संसाधन समूहों और **संसाधनों** पर है।
+स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा सभी संसाधन समूहों पर जो सदस्यता के भीतर हैं और **संसाधन समूह के भीतर सभी संसाधनों** पर।
 
 ### Classic Roles
 
@@ -255,12 +255,12 @@ Azure Active Directory में प्रबंधित पहचानें
 - [**कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बनाना भी संभव है
 - ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूह, सदस्यता और संसाधन समूह) में हो सकती है
 - यह संभव है कि कस्टम भूमिका के पास सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए
-- अनुमतियों को बाहर करना भी संभव है
-- एक प्रमुख जिसके पास एक बाहर की गई अनुमति है, वह इसका उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
-- वाइल्डकार्ड का उपयोग करना भी संभव है
+- अनुमतियों को बाहर करना संभव है
+- एक प्रमुख जिसके पास एक बाहर की गई अनुमति है, वह इसे उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
+- वाइल्डकार्ड का उपयोग करना संभव है
 - उपयोग किया गया प्रारूप JSON है
-- `actions` संसाधनों पर प्रबंधन संचालन के लिए अनुमतियों को संदर्भित करता है, जैसे संसाधन परिभाषाओं और सेटिंग्स को बनाने, अपडेट करने या हटाने के लिए।
-- `dataActions` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जो आपको संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने या हटाने की अनुमति देती हैं।
+- `actions` संसाधनों पर प्रबंधन संचालन के लिए अनुमतियों को संदर्भित करता है, जैसे संसाधन परिभाषाओं और सेटिंग्स को बनाने, अपडेट करने, या हटाने के लिए।
+- `dataActions` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जो आपको संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने, या हटाने की अनुमति देती हैं।
 - `notActions` और `notDataActions` भूमिका से विशिष्ट अनुमतियों को बाहर करने के लिए उपयोग किए जाते हैं। हालाँकि, **वे उन्हें अस्वीकार नहीं करते**, यदि एक अलग भूमिका उन्हें प्रदान करती है, तो प्रमुख के पास वे होंगी।
 - `assignableScopes` उन स्कोपों की एक सूची है जहां भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।
 
@@ -296,60 +296,53 @@ Azure Active Directory में प्रबंधित पहचानें
 ```
 ### Permissions order
 
-- किसी **principal को किसी resource पर कुछ access प्राप्त करने के लिए** उसे एक स्पष्ट भूमिका (role) दी जानी चाहिए (किसी भी तरह से) **उसे वह अनुमति (permission) देने के लिए**।
+- किसी **principal को एक resource पर कुछ access प्राप्त करने के लिए** उसे एक स्पष्ट भूमिका (role) दी जानी चाहिए (किसी भी तरह से) **उसे वह अनुमति देने के लिए**।
 - एक स्पष्ट **deny assignment की प्राथमिकता होती है** उस भूमिका पर जो अनुमति देती है।
 
 <figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
 
 ### Global Administrator
 
-Global Administrator एक भूमिका है जो Entra ID से **Entra ID tenant पर पूर्ण नियंत्रण** प्रदान करती है। हालाँकि, यह डिफ़ॉल्ट रूप से Azure संसाधनों पर कोई अनुमति नहीं देती है।
+Global Administrator एक भूमिका है Entra ID से जो **Entra ID tenant पर पूर्ण नियंत्रण प्रदान करती है**। हालाँकि, यह डिफ़ॉल्ट रूप से Azure संसाधनों पर कोई अनुमति नहीं देती है।
 
-Global Administrator भूमिका वाले उपयोगकर्ताओं के पास **Root Management Group में User Access Administrator Azure भूमिका में 'elevate' करने की क्षमता** होती है। इसलिए Global Administrators **सभी Azure subscriptions और management groups में access प्रबंधित कर सकते हैं।**\
+Global Administrator भूमिका वाले उपयोगकर्ताओं के पास '**User Access Administrator Azure भूमिका में Root Management Group में 'elevate' करने की क्षमता है**। इसलिए Global Administrators **सभी Azure subscriptions और management groups में access प्रबंधित कर सकते हैं।**\
 यह elevation पृष्ठ के अंत में किया जा सकता है: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
 
 <figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
 
 ### Assignments Conditions & MFA
 
-यह संभव है कि **जब एक भूमिका (role) एक principal को सौंपा जाता है तो कुछ शर्तें स्थापित की जाएं**। एक सामान्य शर्त यह है कि कुछ भूमिका अनुमतियों (permissions) तक पहुँचने के लिए MFA की आवश्यकता हो:
-```bash
-az role assignment create \
---assignee <user-or-service-principal-id> \
---role <custom-role-id-or-name> \
---scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \
---condition "PrincipalClaims['amr'] contains 'mfa'" \
---condition-version 2.0
-```
+**[the docs](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)** के अनुसार: वर्तमान में, शर्तें उन अंतर्निहित या कस्टम भूमिका असाइनमेंट में जोड़ी जा सकती हैं जिनमें **blob storage data actions या queue storage data actions** हैं।
+
 ### Deny Assignments
 
-Just like role assignments, **deny assignments** are used to **control access to Azure resources**. However, **deny assignments** are used to **explicitly deny access** to a resource, even if a user has been granted access through a role assignment. **Deny assignments** take precedence over **role assignments**, meaning that if a user is granted access through a role assignment but is also explicitly denied access through a deny assignment, the deny assignment will take precedence.
+भूमिका असाइनमेंट की तरह, **deny assignments** का उपयोग **Azure संसाधनों तक पहुँच को नियंत्रित करने के लिए** किया जाता है। हालाँकि, **deny assignments** का उपयोग एक संसाधन तक पहुँच को **स्पष्ट रूप से अस्वीकार करने** के लिए किया जाता है, भले ही किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई हो। **Deny assignments** की प्राथमिकता **भूमिका असाइनमेंट** पर होती है, जिसका अर्थ है कि यदि किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई है लेकिन उसे एक deny assignment के माध्यम से स्पष्ट रूप से पहुँच से वंचित किया गया है, तो deny assignment की प्राथमिकता होगी।
 
-Just like role assignments, **deny assignments** are applied over some scope indicating the affected principals and the permissions that are being denied. Moreover, in the case of deny assignments, it's possible to **prevent the deny to be inherited** by children resources.
+भूमिका असाइनमेंट की तरह, **deny assignments** कुछ दायरे पर लागू होते हैं जो प्रभावित होने वाले principals और उन अनुमतियों को इंगित करते हैं जो अस्वीकृत की जा रही हैं। इसके अलावा, deny assignments के मामले में, यह संभव है कि **deny को बच्चों के संसाधनों द्वारा विरासत में प्राप्त होने से रोका जा सके**।
 
 ### Azure Policies
 
-**Azure Policies** are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to **enforce or audit settings on resources in Azure**. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.
+**Azure Policies** नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके संसाधन विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको **Azure में संसाधनों पर सेटिंग्स को लागू या ऑडिट करने** की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी संसाधनों में ट्रैकिंग के लिए विशिष्ट टैग हों।
 
-Azure Policies are **proactive**: they can stop non-compliant resources from being created or changed. They are also **reactive**, allowing you to find and fix existing non-compliant resources.
+Azure Policies **proactive** हैं: वे अनुपालन न करने वाले संसाधनों के निर्माण या परिवर्तन को रोक सकती हैं। वे **reactive** भी हैं, जिससे आप मौजूदा अनुपालन न करने वाले संसाधनों को खोज और ठीक कर सकते हैं।
 
 #### **Key Concepts**
 
-1. **Policy Definition**: A rule, written in JSON, that specifies what is allowed or required.
-2. **Policy Assignment**: The application of a policy to a specific scope (e.g., subscription, resource group).
-3. **Initiatives**: A collection of policies grouped together for broader enforcement.
-4. **Effect**: Specifies what happens when the policy is triggered (e.g., "Deny," "Audit," or "Append").
+1. **Policy Definition**: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
+2. **Policy Assignment**: एक नीति को एक विशिष्ट दायरे (जैसे, सब्सक्रिप्शन, संसाधन समूह) पर लागू करना।
+3. **Initiatives**: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
+4. **Effect**: यह निर्दिष्ट करता है कि नीति को सक्रिय करने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।
 
-**Some examples:**
+**कुछ उदाहरण:**
 
-1. **Ensuring Compliance with Specific Azure Regions**: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
-2. **Enforcing Naming Standards**: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
-3. **Restricting Certain Resource Types**: This policy can restrict the creation of certain types of resources. For example, a policy could be set to prevent the creation of expensive resource types, like certain VM sizes, to control costs.
-4. **Enforcing Tagging Policies**: Tags are key-value pairs associated with Azure resources used for resource management. Policies can enforce that certain tags must be present, or have specific values, for all resources. This is useful for cost tracking, ownership, or categorization of resources.
-5. **Limiting Public Access to Resources**: Policies can enforce that certain resources, like storage accounts or databases, do not have public endpoints, ensuring that they are only accessible within the organization's network.
-6. **Automatically Applying Security Settings**: Policies can be used to automatically apply security settings to resources, such as applying a specific network security group to all VMs or ensuring that all storage accounts use encryption.
+1. **Specific Azure Regions के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात किए जाएं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसके सभी डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हों।
+2. **Naming Standards को लागू करना**: नीतियाँ Azure संसाधनों के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में संसाधनों को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
+3. **Certain Resource Types को प्रतिबंधित करना**: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति को महंगे संसाधन प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकने के लिए सेट किया जा सकता है, ताकि लागत को नियंत्रित किया जा सके।
+4. **Tagging Policies को लागू करना**: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि सभी संसाधनों के लिए कुछ टैग मौजूद होने चाहिए, या उनके पास विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणीकरण के लिए उपयोगी है।
+5. **Resources तक सार्वजनिक पहुँच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ संसाधनों, जैसे स्टोरेज खाते या डेटाबेस, में सार्वजनिक एंडपॉइंट नहीं होना चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
+6. **Automatically Applying Security Settings**: नीतियों का उपयोग संसाधनों पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
 
-Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are **commonly used in the root management group** or in other management groups.
+ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आमतौर पर root management group** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
 
 Azure policy json example:
 ```json
@@ -383,7 +376,7 @@ Azure में **permissions किसी भी भाग को हायर
 हालांकि, कुछ मामलों में आप **और अधिक बारीक एक्सेस प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **असाइनमेंट्स** के प्रबंधन को **सरल** करना चाहते हैं।
 
 Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें** जोड़ी जाती हैं। एक _भूमिका असाइनमेंट शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं** ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है**।\
-आप **स्पष्ट रूप से** **विशिष्ट संसाधनों** के लिए **एक्सेस** को **शर्तों** का उपयोग करके **निषेध** नहीं कर सकते।
+आप **explicitly** **deny** **access** को विशिष्ट संसाधनों के लिए **शर्तों का उपयोग करके** नहीं कर सकते।
 
 ## References