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

This commit is contained in:
Translator
2025-02-05 23:38:44 +00:00
parent 1fb785429e
commit 16639aa816

View File

@@ -8,31 +8,31 @@
### 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
[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 समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, उन **संसाधनों** को एक ही संसाधन समूह में जोड़ें जो **एक ही जीवन चक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
सभी **संसाधन** को **एक संसाधन समूह के भीतर** होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1</a></p></figcaption></figure>
<figure><img src="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
### Azure Resource IDs
@@ -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 (पूर्व में Azure Active Directory)
### Entra ID (formerly 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)
### Entra Domain Services (formerly Azure AD DS)
Entra Domain Services Entra ID की क्षमताओं को बढ़ाता है, **पारंपरिक Windows Active Directory वातावरण के साथ संगत प्रबंधित डोमेन सेवाएँ** प्रदान करता है। यह LDAP, Kerberos, और NTLM जैसे विरासती प्रोटोकॉल का समर्थन करता है, जिससे संगठनों को क्लाउड में पुराने अनुप्रयोगों को माइग्रेट या चलाने की अनुमति मिलती है बिना ऑन-प्रिमाइसेस डोमेन नियंत्रकों को तैनात किए। यह सेवा केंद्रीकृत प्रबंधन के लिए समूह नीति का भी समर्थन करती है, जिससे यह उन परिदृश्यों के लिए उपयुक्त बनती है जहां विरासती या AD-आधारित कार्यभार को आधुनिक क्लाउड वातावरण के साथ सह-अस्तित्व में होना आवश्यक है।
@@ -77,12 +77,12 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
### 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) में देख सकते हैं, लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:
आप उन्हें [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,15 +99,15 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
- Microsoft Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट **नहीं**
- यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
- उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट **हाँ**
- उपयोगकर्ता को साइन इन रखने के लिए दिखाएं: डिफ़ॉल्ट **हाँ**
- उपयोगकर्ता को साइन इन रख: डिफ़ॉल्ट **हाँ**
- उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
- अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट **हाँ** (Microsoft Graph के माध्यम से)
- **अतिथि**
- **अतिथि उपयोगकर्ता पहुंच प्रतिबंध**
- **अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच** डिफ़ॉल्ट रूप से सभी सदस्य उपयोगकर्ता अनुमतियों को अतिथि उपयोगकर्ताओं को प्रदान करता है।
- **अतिथि उपयोगकर्ताओं क निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)** डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
- **अतिथि उपयोगकर्ता पहुंच उनक अपन निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
- **अतिथि आमंत्रित कर सकते हैं**
- **अतिथि उपयोगकर्ता पहुंच प्रतिबंध** विकल्प:
- **अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच है**
- **अतिथि उपयोगकर्ताओं की संपत्तियों और निर्देशिका वस्तुओं क सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)**। यह डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
- **अतिथि उपयोगकर्ता पहुंच उनक अपन निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
- **अतिथि आमंत्रित कर सकते हैं** विकल्प:
- **संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट**
- **सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ शामिल हैं**
- **केवल विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं**
@@ -120,20 +120,20 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
### **Groups**
यहा **2 प्रकार के समूह** हैं:
यहा **2 प्रकार के समूह** हैं:
- **सुरक्षा**: इस प्रकार के समूह का उपयोग सदस्यों को अनुप्रयोगों, संसाधनों तक पहुंच देने और लाइसेंस असाइन करने के लिए किया जाता है। उपयोगकर्ता, उपकरण, सेवा प्रमुख और अन्य समूह सदस्य हो सकते हैं।
- **Microsoft 365**: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को एक साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच प्रदान करता है। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
- इसका एक **ईमेल पता** होगा जो EntraID टेनेट के डोमेन के साथ होगा।
यहा **2 प्रकार की सदस्यताएँ** हैं:
यहा **2 प्रकार की सदस्यताएँ** हैं:
- **नियुक्त**: एक समूह में विशिष्ट सदस्यों को मैन्युअल रूप से जोड़ने की अनुमति देता है।
- **डायनामिक सदस्यता**: नियमों का उपयोग करके सदस्यता को स्वचालित रूप से प्रबंधित करता है, जब सदस्यों के गुण बदलते हैं तो समूह में समावेश को अपडेट करता है।
### **Service Principals**
एक **Service Principal** एक **पहचान** है जो **अनुप्रयोगों**, होस्टेड सेवाओं, और स्वचालित उपकरणों के साथ Azure संसाधनों तक पहुंच के लिए बनाई गई है। यह पहुंच **सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित** होती है, जिससे आपको **कौन से संसाधनों तक पहुंचा जा सकता है** और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि **स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें** बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।
एक **Service Principal** एक **पहचान** है जो **अनुप्रयोगों**, होस्टेड सेवाओं, और स्वचालित उपकरणों के लिए Azure संसाधनों तक पहुंच प्राप्त करने के लिए बनाई गई है। यह पहुंच **सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित** होती है, जिससे आपको **कौन से संसाधनों तक पहुंच प्राप्त है** और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि **स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें** बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।
आप **सेवा प्रमुख के रूप में सीधे लॉगिन** कर सकते हैं, इसके लिए एक **गुप्त** (पासवर्ड), एक **प्रमाणपत्र**, या तीसरे पक्ष के प्लेटफार्मों (जैसे Github Actions) के लिए **संघीय** पहुंच प्रदान करके।
@@ -146,48 +146,48 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
#### Key Components:
1. **अनुप्रयोग ID (Client ID):** Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
1. **Application ID (Client ID):** Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
2. **Redirect URIs:** URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
3. **प्रमाणपत्र, गुप्त और संघीय क्रेडेंशियल्स:** सेवा प्रमुख के रूप में लॉगिन करने के लिए एक गुप्त या प्रमाणपत्र उत्पन्न करना संभव है, या इसके लिए संघीय पहुंच प्रदान करना (जैसे Github Actions)।
1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो किसी व्यक्ति के लिए **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन करना संभव है** यदि वह **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानता है
4. **API Permissions:** निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच सकता है।
3. **Certificates, Secrets & Federated Credentials:** यह संभव है कि एक गुप्त या प्रमाणपत्र उत्पन्न किया जाए ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो यह संभव है कि एक व्यक्ति **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन** कर सके, **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानकर
4. **API Permissions:** निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच प्राप्त कर सकता है।
5. **Authentication Settings:** ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
6. **Service Principal**: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
1. **सेवा प्रमुख** सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनसे इसे कॉन्फ़िगर किया गया था।
1. **सेवा प्रमुख** सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनके साथ इसे कॉन्फ़िगर किया गया था।
### Default Consent Permissions
**अनुप्रयोगों के लिए उपयोगकर्ता सहमति**
**User consent for applications**
- **उपयोगकर्ता सहमति की अनुमति न दें**
- सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
- **सत्यापित प्रकाशकों से ऐप्स के लिए चयनित अनुमतियों के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स या इस संगठन में पंजीकृत ऐप्स के लिए।
- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स के लिए या इस संगठन में पंजीकृत ऐप्स के लिए।
- **डिफ़ॉल्ट** कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
- User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
- offline_access - उन डेटा तक पहुंच बनाए रखें जिनकी उपयोगकर्ताओं ने इसे पहुंच ी है
- offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे पहुंच प्रदान की है
- openid - उपयोगकर्ताओं को साइन इन करें
- profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
- email - उपयोगकर्ता के ईमेल पते को देखें
- **अनुप्रयोगों के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
- सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच देने के लिए सहमति दे सकते हैं।
- **ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
- सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच प्राप्त करने के लिए सहमति दे सकते हैं।
**प्रशासक सहमति अनुरोध**: डिफ़ॉल्ट **नहीं**
**Admin consent requests**: डिफ़ॉल्ट **नहीं**
- उपयोगकर्ता उन ऐप्स के लिए प्रशासक सहमति का अनुरोध कर सकते हैं जिनके लिए वे सहमति नहीं दे सकते
- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों पर सहमति दे सकते हैं
- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों के लिए सहमति दे सकते हैं
- यह भी कॉन्फ़िगर करें कि क्या उपयोगकर्ताओं को ईमेल सूचनाएँ और समाप्ति अनुस्मारक प्राप्त होंगे
### **Managed Identity (Metadata)**
Azure Active Directory में प्रबंधित पहचानें अनुप्रयोगों की पहचान को **स्वचालित रूप से प्रबंधित करने** के लिए एक समाधान प्रदान करती हैं। ये पहचानें अनुप्रयोगों द्वारा Azure Active Directory (**Azure AD**) प्रमाणीकरण के साथ संगत **संसाधनों** से **जोड़ने** के लिए उपयोग की जाती हैं। यह कोड में क्लाउड क्रेडेंशियल्स को हार्डकोड करने की आवश्यकता को **हटाने** की अनुमति देता है क्योंकि अनुप्रयोग **मेटाडेटा** सेवा से संपर्क करके एक मान्य टोकन प्राप्त कर सकेगा ताकि Azure में निर्दिष्ट प्रबंधित पहचान के रूप में **क्रियाएँ** सके।
Azure Active Directory में प्रबंधित पहचानें अनुप्रयोगों की पहचान को **स्वचालित रूप से प्रबंधित करने** के लिए एक समाधान प्रदान करती हैं। ये पहचानें अनुप्रयोगों द्वारा Azure Active Directory (**Azure AD**) प्रमाणीकरण के साथ संगत **संसाधनों** से **जोड़ने** के लिए उपयोग की जाती हैं। यह कोड में क्लाउड क्रेडेंशियल्स को हार्डकोड करने की आवश्यकता को **हटाने** की अनुमति देता है क्योंकि अनुप्रयोग **मेटाडेटा** सेवा से संपर्क करके एक मान्य टोकन प्राप्त कर सकेगा ताकि Azure में निर्दिष्ट प्रबंधित पहचान के रूप में **क्रियाएँ**ी जा सके
प्रबंधित पहचान के दो प्रकार हैं:
- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जो उस सदस्यता द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, तो Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID द्वारा विश्वसनीय सेवा प्रमुख बनाया जाएगा। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान का प्रबंधन उन संसाधनों से अलग किया जात है जो इसका उपयोग करत हैं**
- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जो उस सब्सक्रिप्शन द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सब्सक्रिप्शन के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID द्वारा विश्वसनीय सब्सक्रिप्शन में एक सेवा प्रमुख बनाया जाएगा। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान उन संसाधनों से अलग से प्रबंधित की जात है जो इसका उपयोग करत हैं**
प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से जुड़े इसे एक्सेस किया जा सके।
प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से इसे एक्सेस किया जा सके।
### Enterprise Applications
@@ -204,10 +204,10 @@ Azure Active Directory में प्रबंधित पहचानें
- परिदृश्य: एक कंपनी चाहती है कि क्षेत्रीय IT प्रशासक केवल अपने क्षेत्र के उपयोगकर्ताओं का प्रबंधन करें।
- कार्यान्वयन:
- प्रत्येक क्षेत्र के लिए प्रशासनिक इकाइयाँ बनाएं (जैसे, "उत्तरी अमेरिका AU", "यूरोप AU")।
- अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को Populate करें।
- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को **धारण कर सकते हैं**
- अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को रें।
- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को समाहित कर सकते हैं
- AUs **डायनामिक सदस्यताओं** का समर्थन करते हैं
- AUs **AUs को नहीं र सकते**
- AUs **AUs को समाहित नहीं र सकते**
- प्रशासक भूमिकाएँ असाइन करें:
- क्षेत्रीय IT स्टाफ को "उपयोगकर्ता प्रशासक" भूमिका दें, जो उनके क्षेत्र के AU तक सीमित हो।
- परिणाम: क्षेत्रीय IT प्रशासक अपने क्षेत्र के भीतर उपयोगकर्ता खातों का प्रबंधन कर सकते हैं बिना अन्य क्षेत्रों को प्रभावित किए।
@@ -217,15 +217,15 @@ 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**
@@ -237,7 +237,7 @@ Azure Active Directory में प्रबंधित पहचानें
### Built-In roles
[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) में कई Azure **निर्मित भूमिकाएँ** हैं जिन्हें आप **उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान** को **असाइन** कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप **Azure संसाधनों तक पहुंच को नियंत्रित** करते हैं। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी [**Azure कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** बना सकते हैं।**
[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) में कई Azure **निर्मित भूमिकाएँ** हैं जिन्हें आप **उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान** को **असाइन** कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप **Azure संसाधनों तक पहुंच को नियंत्रित करते हैं**। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी [**Azure कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** बना सकते हैं।**
**निर्मित** भूमिकाएँ केवल उन **संसाधनों** पर लागू होती हैं जिनके लिए वे **निर्धारित** हैं, उदाहरण के लिए, Compute संसाधनों पर **निर्मित भूमिकाओं** के इन 2 उदाहरणों की जांच करें:
@@ -245,19 +245,19 @@ Azure Active Directory में प्रबंधित पहचानें
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [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` वस्तु के भीतर डेटा पर अनुमतियाँ हैं
@@ -294,43 +294,43 @@ Azure Active Directory में प्रबंधित पहचानें
```
### Permissions order
- एक **principal को किसी resource पर कुछ access प्राप्त करने के लिए** उसे एक स्पष्ट भूमिका दी जानी चाहिए (किसी भी तरह से) **उसे वह अनुमति देने के लिए**
- एक स्पष्ट **deny role assignment प्राथमिकता लेता है** उस भूमिका पर जो अनुमति देती है।
- किसी **resource पर कुछ access पने के लिए** एक **principal** को उसे (किसी भी तरह से) **वह अनुमति देने वाला एक स्पष्ट भूमिका** दी जानी चाहिए
- एक स्पष्ट **deny role 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 resources पर कोई अनुमति नहीं देती है।
Global Administrator एक भूमिका है जो **Entra ID tenant पर पूर्ण नियंत्रण** प्रदान करती है। हालाँकि, यह डिफ़ॉल्ट रूप से Azure संसाधनों पर कोई अनुमति नहीं देती है।
Global Administrator भूमिका वाले उपयोगकर्ताओं के पास '**User Access Administrator Azure role में Elevate करने की क्षमता है Root Management Group में**। इसलिए Global Administrators **सभी Azure subscriptions और management groups में access प्रबंधित कर सकते हैं।**\
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>
### Azure Policies
**Azure Policies** नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके resources विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको **Azure में resources पर सेटिंग्स को लागू या ऑडिट करने** की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी resources में ट्रैकिंग के लिए विशिष्ट टैग हों।
**Azure Policies** नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके संसाधन विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको **Azure में संसाधनों पर सेटिंग्स को लागू या ऑडिट** करने की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी संसाधनों में ट्रैकिंग के लिए विशिष्ट टैग हों।
Azure Policies **proactive** हैं: वे अनुपालन न करने वाले resources के निर्माण या परिवर्तन को रोक सकती हैं। वे **reactive** भी हैं, ज आपको मौजूदा अनुपालन न करने वाले resources को खोजने और ठीक करने की अनुमति देती हैं।
Azure Policies **proactive** हैं: वे अनुपालन न करने वाले संसाधनों के निर्माण या परिवर्तन को रोक सकती हैं। वे **reactive** भी हैं, जिससे आप मौजूदा अनुपालन न करने वाले संसाधनों को खोज और ठीक कर सकते हैं।
#### **Key Concepts**
1. **Policy Definition**: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
2. **Policy Assignment**: एक नीति को एक विशिष्ट दायरे (जैसे, subscription, resource group) पर लागू करना।
3. **Initiatives**: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
4. **Effect**: निर्दिष्ट करता है कि नीति सक्रिय होने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।
4. **Effect**: यह निर्दिष्ट करता है कि नीति को सक्रिय करने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।
**कुछ उदाहरण:**
1. **विशिष्ट Azure क्षेत्रों के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी resources विशिष्ट Azure क्षेत्रों में तैनात हैं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसका सारा डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हो।
2. **नामकरण मानकों को लागू करना**: नीतियाँ Azure resources के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में resources को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
3. **कुछ resource प्रकारों को प्रतिबंधित करना**: यह नीति कुछ प्रकार के resources के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति को महंगे resource प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकने के लिए सेट किया जा सकता है, ताकि लागत को नियंत्रित किया जा सके।
4. **टैगिंग नीतियों को लागू करना**: टैग Azure resources के साथ जुड़े कुंजी-मूल्य जोड़े हैं जो resource प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि कुछ टैग मौजूद होने चाहिए, या सभी resources के लिए विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या resources की श्रेणीकरण के लिए उपयोगी है।
5. **resources के लिए सार्वजनिक पहुंच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ resources, जैसे स्टोरेज खाते या डेटाबेस, में सार्वजनिक एंडपॉइंट नहीं होना चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हं।
6. **स्वचालित रूप से सुरक्षा सेटिंग्स लागू करना**: नीतियों का उपयोग resources पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
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 पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आमतौर पर root management group में** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आम तौर पर root management group** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
Azure policy json example:
```json
@@ -350,23 +350,23 @@ Azure policy json example:
"mode": "All"
}
```
### अनुमतियों का उत्तराधिकार
### Permissions Inheritance
Azure में **अनुमतियाँ किसी भी भाग को सौंपा जा सकत है**। इसमें प्रबंधन समूह, सदस्यताएँ, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। अनुमतियाँ उस इकाई के अंतर्गत **संसाधनों** द्वारा **उत्तराधिकार** में ली जाती हैं जहाँ उन्हें सौंपा गया था।
Azure में **permissions किसी भी भाग को हायरार्की में असाइन की जा सकत है**। इसमें प्रबंधन समूह, सब्सक्रिप्शन, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। **Permissions** उन **resources** द्वारा **inherited** ी जाती हैं जिनके लिए उन्हें असाइन किया गया था।
यह पदानुक्रमित संरचना पहुँच अनुमतियों के प्रबंधन कुशल और स्केलेबल बनाती है।
यह हायरार्किकल संरचना एक्सेस permissions कुशल और स्केलेबल प्रबंधन की अनुमति देती है।
<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
### Azure RBAC बनाम ABAC
### Azure RBAC vs ABAC
**RBAC** (भूमिका-आधारित पहुँच नियंत्रण) वही है जो हमने पहले के अनुभागों में देखा है: **एक संसापर पहुँच देने के लिए एक प्रमुख को भूमिका सौंपना**।\
हालांकि, कुछ मामलों में आप **अधिक बारीक पहुँच प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **सौंपने** के प्रबंधन को **सरल** करना चाहते हैं।
**RBAC** (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: **एक प्रिंसिपल को एक भूमिका असाकरना ताकि उसे एक संसाधन पर एक्सेस मिल सके**।\
हालांकि, कुछ मामलों में आप **और अधिक बारीक एक्सेस प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **असाइनमेंट्** के प्रबंधन को **सरल** करना चाहते हैं।
Azure **ABAC** (गुण-आधारित पहुँच नियंत्रण) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में गुणों के आधार पर भूमिका सौंपने की शर्तें** जोड़ी जाती हैं। एक _भूमिका सौंपने की शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका सौंपने में जोड़ सकते हैं** ताकि अधिक बारीक पहुँच नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका सौंपने के हिस्से के रूप में दी गई अनुमतियों को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक वस्तु को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है**।\
आप **विशिष्ट संसाधनों** के लिए **शर्तों** का उपयोग करके **पहुँच** को स्पष्ट रूप से **अस्वीकृत** **नहीं** कर सकते।
Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें** जोड़ी जाती हैं। एक _भूमिका असाइनमेंट शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं** ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता होती है**।\
आप **विशिष्ट संसाधनों के लिए एक्सेस को स्पष्ट रूप से **deny** **नहीं कर सकते** **using conditions**
## संदर्भ
## References
- [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
- [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions)