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

This commit is contained in:
Translator
2025-02-08 18:50:58 +00:00
parent d6f9f82b8a
commit bf939e3590

View File

@@ -8,23 +8,23 @@
### Management Groups
- यह **अन्य प्रबंधन समूहों या सब्सक्रिप्शन** को समाहित कर सकता है।
- यह **प्रबंधन समूह स्तर पर शासन नियंत्रण** जैसे RBAC और Azure नीति को एक बार लागू करने की अनुमति देता है और इन्हें समूह में सभी सब्सक्रिप्शन द्वारा **विरासत में** िया जाता है।
- यह **अन्य प्रबंधन समूहों या सदस्यताओं** को समाहित कर सकता है।
- यह **प्रबंधन समूह स्तर पर शासन नियंत्रण** जैसे RBAC और Azure नीति को लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा **विरासत में** प्राप्त किया जाता है।
- **10,000 प्रबंधन** समूह एकल निर्देशिका में समर्थित हो सकते हैं।
- एक प्रबंधन समूह का पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सब्सक्रिप्शन स्तर को शामिल नहीं करती है।
- प्रत्येक प्रबंधन समूह और सब्सक्रिप्शन केवल **एक माता-पिता** का समर्थन कर सकत है।
- एक प्रबंधन समूह का पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
- प्रत्येक प्रबंधन समूह और सदस्यता **केवल एक माता-पिता** का समर्थन कर सकत है।
- कई प्रबंधन समूह बनाए जा सकते हैं, लेकिन **केवल 1 मूल प्रबंधन समूह** है।
- मूल प्रबंधन समूह **सभी अन्य प्रबंधन समूहों और सब्सक्रिप्शन** को **समाहित करता है** और **इसे स्थानांतरित या हटाया नहीं जा सकता**
- एकल प्रबंधन समूह के भीतर सभी सब्सक्रिप्शन को **समान Entra ID टेनेट** पर भरोसा करना चाहिए।
- मूल प्रबंधन समूह **सभी अन्य प्रबंधन समूहों और सदस्यताओं** को **समाहित करता है** और **इसे स्थानांतरित या हटाया नहीं जा सकता**
- एकल प्रबंधन समूह के भीतर सभी सदस्यताओं को **समान Entra ID टेनेट** पर भरोसा करना चाहिए।
<figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
### Azure Subscriptions
- यह एक और **तार्किक कंटेनर है जहां संसाधन** (VMs, DBs…) चलाए जा सकते हैं और बिल किया जाएगा।
- इसका **माता-पिता** हमेशा एक **प्रबंधन समूह** होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सब्सक्रिप्शन अन्य सब्सक्रिप्शन को समाहित नहीं कर सकत
- इसका **माता-पिता** हमेशा एक **प्रबंधन समूह** होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सदस्यताएँ अन्य सदस्यताओं को समाहित नहीं कर सकती हैं
- यह **केवल एक Entra ID** निर्देशिका पर भरोसा करता है।
-ब्सक्रिप्शन स्तर (या इसके किसी भी माता-पिता) पर लागू **अनुमतियाँ** सभी संसाधनों पर **विरासत में**ी जाती हैं।
-दस्यता स्तर (या इसके किसी भी माता-पिता) पर लागू **अनुमतियाँ** सभी संसाधनों पर **विरासत में** मिलती हैं।
### Resource Groups
@@ -42,7 +42,7 @@ Azure Resource ID का प्रारूप इस प्रकार है:
- `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
एक वर्चुअल मशीन जिसका नाम myVM है, एक संसाधन समूह `myResourceGroup` के तहत सब्सक्रिप्शन ID `12345678-1234-1234-1234-123456789012` में, Azure Resource ID इस प्रकार दिखता है:
एक वर्चुअल मशीन जिसका नाम myVM है, एक संसाधन समूह `myResourceGroup` के तहत सदस्यता ID `12345678-1234-1234-1234-123456789012` में, Azure Resource ID इस प्रकार दिखता है:
- `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
@@ -50,13 +50,13 @@ Azure Resource ID का प्रारूप इस प्रकार है:
### Azure
Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो एक विस्तृत श्रृंखला की सेवाएँ** प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता, और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे बनाने, और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं** की एक विस्तृत श्रृंखला प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे का निर्माण करने और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
### Entra ID (formerly Azure Active Directory)
### 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 (formerly Azure AD DS)
### Entra Domain Services (पूर्व में Azure AD DS)
Entra Domain Services Entra ID की क्षमताओं को बढ़ाता है, **पारंपरिक Windows Active Directory वातावरण के साथ संगत प्रबंधित डोमेन सेवाएँ** प्रदान करता है। यह LDAP, Kerberos, और NTLM जैसे विरासती प्रोटोकॉल का समर्थन करता है, जिससे संगठनों को क्लाउड में पुराने अनुप्रयोगों को माइग्रेट या चलाने की अनुमति मिलती है बिना ऑन-प्रिमाइसेस डोमेन नियंत्रकों को तैनात किए। यह सेवा केंद्रीकृत प्रबंधन के लिए समूह नीति का भी समर्थन करती है, जिससे यह उन परिदृश्यों के लिए उपयुक्त बनती है जहां विरासती या AD-आधारित कार्यभार को आधुनिक क्लाउड वातावरण के साथ सह-अस्तित्व में होना आवश्यक है।
@@ -65,24 +65,24 @@ 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) में देख सकते हैं लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:
- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सब्सक्रिप्शन, और उनके सार्वजनिक गुणों को पढ़ें
- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं और उनके सार्वजनिक गुणों को पढ़ें
- अतिथियों को आमंत्रित करें (_बंद किया जा सकता है_)
- सुरक्षा समूह बनाएं
- गैर-छिपे समूह सदस्यता पढ़ें
- गैर-छिपे समूह सदस्यताओं को पढ़ें
- स्वामित्व वाले समूहों में अतिथियों को जोड़ें
- नया अनुप्रयोग बनाएं (_बंद किया जा सकता है_)
- Azure में 50 उपकरणों तक जोड़ें (_बंद किया जा सकता है_)
@@ -99,17 +99,17 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
- Microsoft Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट **नहीं**
- यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
- उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट **हाँ**
- उपयोगकर्ता को साइन इन रख: डिफ़ॉल्ट **हाँ**
- उपयोगकर्ता को साइन इन रखने का विकल्प दिखाएं: डिफ़ॉल्ट **हाँ**
- उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
- अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट **हाँ** (Microsoft Graph के माध्यम से)
- **अतिथि**
- **अतिथि उपयोगकर्ता पहुंच प्रतिबंध** विकल्प:
- **अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच है**।
- **अतिथि उपयोगकर्ताओं की संपत्तियों और निर्देशिका वस्तुओं क सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)**। यह डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
- **अतिथि उपयोगकर्ता पहुंच उनक अपन निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
- **अतिथि उपयोगकर्ताओं क निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)**। यह डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
- **अतिथि उपयोगकर्ता पहुंच उनक अपन निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
- **अतिथि आमंत्रित कर सकते हैं** विकल्प:
- **संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट**
- **सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ शामिल हैं**
- **सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ हैं**
- **केवल विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं**
- **संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित नहीं कर सकता जिसमें प्रशासक शामिल हैं (सबसे प्रतिबंधात्मक)**
- **बाहरी उपयोगकर्ता छोड़ें**: डिफ़ॉल्ट **सच**
@@ -148,8 +148,8 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
1. **Application ID (Client ID):** Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
2. **Redirect URIs:** URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
3. **Certificates, Secrets & Federated Credentials:** यह संभव है कि एक गुप्त या प्रमाणपत्र उत्पन्न किया जाए ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो यह संभव है कि एक व्यक्ति **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन** कर सके, **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानकर
3. **Certificates, Secrets & Federated Credentials:** एक गुप्त या प्रमाणपत्र उत्पन्न करना संभव है ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो किसी व्यक्ति के लिए **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन करना संभव है** यदि वह **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानता है
4. **API Permissions:** निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच प्राप्त कर सकता है।
5. **Authentication Settings:** ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
6. **Service Principal**: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
@@ -162,10 +162,10 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
- **उपयोगकर्ता सहमति की अनुमति न दें**
- सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
- **सत्यापित प्रकाशकों से ऐप्स के लिए चयनित अनुमतियों के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स के लिए या इस संगठन में पंजीकृत ऐप्स के लिए।
- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स या इस संगठन में पंजीकृत ऐप्स के लिए।
- **डिफ़ॉल्ट** कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
- User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
- offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे पहुंच प्रदान की है
- offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे एक्सेस करने की अनुमति दी है
- openid - उपयोगकर्ताओं को साइन इन करें
- profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
- email - उपयोगकर्ता के ईमेल पते को देखें
@@ -175,7 +175,7 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
**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
@@ -217,17 +217,17 @@ Azure Active Directory में प्रबंधित पहचानें
- Entra ID का प्रबंधन करने के लिए कुछ **निर्मित भूमिकाएँ** हैं जिन्हें Entra ID प्रमुखों को Entra ID का प्रबंधन करने के लिए असाइन किया जा सकता है
- भूमिकाएँ देखें [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
- सबसे विशेषाधिकार प्राप्त भूमिका **ग्लोबल एडमिनिस्ट्रेटर** है
- भूमिका के विवरण में इसक **सूक्ष्म अनुमतियाँ** देखी जा सकती हैं
- भूमिका के विवरण में इसक **सूक्ष्म अनुमतियाँ** देखी जा सकती हैं
## Roles & Permissions
**भूमिकाएँ** **प्रमुखों** को **दायरे** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
**भूमिकाएँ** **प्रमुखों** को **स्कोप** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
**भूमिकाएँ** **समूहों** को असाइन की जाती हैं और समूह के सभी **सदस्यों** द्वारा **विरासत में** ी जाती हैं।
**भूमिकाएँ** जो **समूहों** को असाइन की जाती हैं, समूह के सभी **सदस्यों** द्वारा **विरासत में** प्राप्त की जाती हैं।
जिस दायरे पर भूमिका असाइन की गई थी, उसके आधार पर, **भूमिका** को **दायरे के कंटेनर** के भीतर **अन्य संसाधनों** पर **विरासत में**िया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सब्सक्रिप्शन पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा जो सब्सक्रिप्शन के भीतर सभी संसाधन समूहों और **संसाधनों** पर है।
स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** मिल सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा जो सदस्यता के भीतर सभी संसाधन समूहों और **संसाधनों** पर है।
### **Classic Roles**
### Classic Roles
| **Owner** | <ul><li>सभी संसाधनों तक पूर्ण पहुंच</li><li>अन्य उपयोगकर्ताओं के लिए पहुंच प्रबंधित कर सकते हैं</li></ul> | सभी संसाधन प्रकार |
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
@@ -241,26 +241,28 @@ Azure Active Directory में प्रबंधित पहचानें
**निर्मित** भूमिकाएँ केवल उन **संसाधनों** पर लागू होती हैं जिनके लिए वे **निर्धारित** हैं, उदाहरण के लिए, Compute संसाधनों पर **निर्मित भूमिकाओं** के इन 2 उदाहरणों की जांच करें:
| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | डिस्क बैकअप करने के लिए बैकअप वॉल्ट अनुमति प्रदान करता है। | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | बैकअप वॉल्ट को डिस्क बैकअप करने अनुमति प्रदान करता है। | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | पोर्टल में वर्चुअल मशीनों को देखें और एक सामान्य उपयोगकर्ता के रूप में लॉगिन करें। | fb879df8-f326-4884-b1cf-06f3ad86be52 |
ये भूमिकाएँ **तार्किक कंटेनरों** (जैसे प्रबंधन समूह, सब्सक्रिप्शन और संसाधन समूह) पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को **उन कंटेनरों के भीतर संसाधनों पर** अधिकार प्राप्त होंगे।
ये भूमिकाएँ **तार्किक कंटेनरों** (जैसे प्रबंधन समूह, सदस्यताएँ और संसाधन समूह) पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को **उन कंटेनरों के भीतर संसाधनों पर** अधिकार प्राप्त होंगे।
- यहाँ [**सभी Azure निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) की सूची प्राप्त करें।
- यहाँ [**सभी Entra ID निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) की सूची प्राप्त करें।
- यहाँ [**सभी Azure निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) की एक सूची प्राप्त करें।
- यहाँ [**सभी Entra ID निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) की एक सूची प्राप्त करें।
### Custom Roles
- यह भी संभव है कि [**कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बनाई जाएँ
- ये एक दायरे के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई दायरों (प्रबंधन समूह, सब्सक्रिप्शन और संसाधन समूह) में हो सकती है
- [**कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बनाना भी संभव है
- ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूह, सदस्यता और संसाधन समूह) में हो सकती है
- यह संभव है कि कस्टम भूमिका के पास सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए
- यह अनुमतियों को बाहर करने की भी अनुमति देता है
- एक प्रमुख जिसके पास बाहर की गई अनुमति है, वह इसका उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
- यह वाइल्डकार्ड का उपयोग करने की अनुमति देता है
- अनुमतियों को बाहर करना भी संभव है
- एक प्रमुख जिसके पास एक बाहर की गई अनुमति है, वह इसका उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
- वाइल्डकार्ड का उपयोग करना भी संभव है
- उपयोग किया गया प्रारूप JSON है
- `actions` संसाधन पर नियंत्रण क्रियाओं के लिए हैं
- `dataActions` वस्तु के भीतर डेटा पर अनुमतियाँ हैं
- `actions` संसाधनों पर प्रबंधन संचालन के लिए अनुमतियों को संदर्भित करता है, जैसे संसाधन परिभाषाओं और सेटिंग्स को बनाने, अपडेट करने या हटाने के लिए
- `dataActions` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जो आपको संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने या हटाने की अनुमति देती हैं।
- `notActions` और `notDataActions` भूमिका से विशिष्ट अनुमतियों को बाहर करने के लिए उपयोग किए जाते हैं। हालाँकि, **वे उन्हें अस्वीकार नहीं करते**, यदि एक अलग भूमिका उन्हें प्रदान करती है, तो प्रमुख के पास वे होंगी।
- `assignableScopes` उन स्कोपों की एक सूची है जहां भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।
कस्टम भूमिका के लिए अनुमतियों का JSON का उदाहरण:
```json
@@ -294,43 +296,60 @@ Azure Active Directory में प्रबंधित पहचानें
```
### Permissions order
- किसी **resource पर कुछ access पने के लिए** एक **principal** को उसे (किसी भी तरह से) **वह अनुमति देने वाला एक स्पष्ट भूमिका** दी जानी चाहिए
- एक स्पष्ट **deny role assignment** उस भूमिका पर प्राथमिकता रखता है जो अनुमति देती है।
- किसी **principal को किसी resource पर कुछ access प्राप्त करने के लिए** उसे एक स्पष्ट भूमिका (role) दी जानी चाहिए (किसी भी तरह से) **उसे वह अनुमति (permission) देने के लिए**
- एक स्पष्ट **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 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 प्रबंधित कर सकते हैं।**\
यह 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
```
### 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.
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.
### Azure Policies
**Azure Policies** नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके संसाधन विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको **Azure में संसाधनों पर सेटिंग्स को लागू या ऑडिट** करने की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी संसाधनों में ट्रैकिंग के लिए विशिष्ट टैग हों।
**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 **proactive** हैं: वे अनुपालन न करने वाले संसाधनों के निर्माण या परिवर्तन को रोक सकती हैं। वे **reactive** भी हैं, जिससे आप मौजूदा अनुपालन न करने वाले संसाधनों को खोज और ठीक कर सकते हैं।
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.
#### **Key Concepts**
1. **Policy Definition**: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
2. **Policy Assignment**: एक नीति को एक विशिष्ट दायरे (जैसे, subscription, resource group) पर लागू करना।
3. **Initiatives**: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
4. **Effect**: यह निर्दिष्ट करता है कि नीति को सक्रिय करने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")
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").
**कुछ उदाहरण:**
**Some examples:**
1. **Specific Azure Regions के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात हैं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसका सारा डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हो।
2. **Naming Standards को लागू करना**: नीतियाँ Azure संसाधनों के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में संसाधनों को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
3. **Certain Resource Types को प्रतिबंधित करना**: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति को महंगे संसाधन प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकने के लिए सेट किया जा सकता है, ताकि लागत को नियंत्रित किया जा सके।
4. **Tagging Policies को लागू करना**: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि सभी संसाधनों के लिए कुछ टैग मौजूद होने चाहिए, या उनके पास विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणीकरण के लिए उपयोगी है।
5. **Resources पर सार्वजनिक पहुंच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ संसाधन, जैसे स्टोरेज खाते या डेटाबेस, सार्वजनिक एंडपॉइंट न हों, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
6. **Automatically Security Settings लागू करना**: नीतियों का उपयोग संसाधनों पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
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.
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आम तौर पर root management group** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
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 policy json example:
```json
@@ -363,8 +382,8 @@ Azure में **permissions किसी भी भाग को हायर
**RBAC** (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: **एक प्रिंसिपल को एक भूमिका असाइन करना ताकि उसे एक संसाधन पर एक्सेस मिल सके**।\
हालांकि, कुछ मामलों में आप **और अधिक बारीक एक्सेस प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **असाइनमेंट्स** के प्रबंधन को **सरल** करना चाहते हैं।
Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें** जोड़ी जाती हैं। एक _भूमिका असाइनमेंट शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं** ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता होती है**।\
आप **विशिष्ट संसाधनों के लिए एक्सेस को स्पष्ट रूप से **deny** **नहीं कर सकते** **using conditions**
Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें** जोड़ी जाती हैं। एक _भूमिका असाइनमेंट शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं** ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है**।\
आप **स्पष्ट रूप से** **विशिष्ट संसाधनों** के लिए **एक्सेस** को **शर्तों** का उपयोग करक**निषेध** नहीं कर सकते।
## References