mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 05:03:31 -08:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
Translator
@@ -8,27 +8,27 @@
|
||||
|
||||
### 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 समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, **संसाधनों** को उसी संसाधन समूह में जोड़ें जो **एक ही जीवन चक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
|
||||
|
||||
सभी **संसाधन** को **एक संसाधन समूह के भीतर** होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
|
||||
|
||||
@@ -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 Domain Services (पूर्व में Azure AD DS)
|
||||
### Entra Domain Services (formerly Azure AD DS)
|
||||
|
||||
Entra Domain Services Entra ID की क्षमताओं को बढ़ाता है, **पारंपरिक Windows Active Directory वातावरण के साथ संगत प्रबंधित डोमेन सेवाएँ** प्रदान करता है। यह LDAP, Kerberos, और NTLM जैसे विरासती प्रोटोकॉल का समर्थन करता है, जिससे संगठनों को क्लाउड में पुराने अनुप्रयोगों को माइग्रेट या चलाने की अनुमति मिलती है बिना ऑन-प्रिमाइसेस डोमेन नियंत्रकों को तैनात किए। यह सेवा केंद्रीकृत प्रबंधन के लिए समूह नीति का भी समर्थन करती है, जिससे यह उन परिदृश्यों के लिए उपयुक्त बनती है जहां विरासती या AD-आधारित कार्यभार को आधुनिक क्लाउड वातावरण के साथ सह-अस्तित्व में होना आवश्यक है।
|
||||
|
||||
@@ -66,12 +66,12 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
|
||||
- **नए उपयोगकर्ता**
|
||||
- चयनित टेनेट से ईमेल नाम और डोमेन निर्दिष्ट करें
|
||||
- प्रदर्शन नाम निर्दिष्ट करें
|
||||
- डिस्प्ले नाम निर्दिष्ट करें
|
||||
- पासवर्ड निर्दिष्ट करें
|
||||
- गुण निर्दिष्ट करें (पहला नाम, नौकरी का शीर्षक, संपर्क जानकारी…)
|
||||
- डिफ़ॉल्ट उपयोगकर्ता प्रकार “**सदस्य**” है
|
||||
- **बाहरी उपयोगकर्ता**
|
||||
- आमंत्रित करने के लिए ईमेल और प्रदर्शन नाम निर्दिष्ट करें (यह एक गैर-माइक्रोसॉफ्ट ईमेल हो सकता है)
|
||||
- आमंत्रित करने के लिए ईमेल और डिस्प्ले नाम निर्दिष्ट करें (यह एक गैर-माइक्रोसॉफ्ट ईमेल हो सकता है)
|
||||
- गुण निर्दिष्ट करें
|
||||
- डिफ़ॉल्ट उपयोगकर्ता प्रकार “**अतिथि**” है
|
||||
|
||||
@@ -105,8 +105,8 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
- **अतिथि**
|
||||
- **अतिथि उपयोगकर्ता पहुंच प्रतिबंध** विकल्प:
|
||||
- **अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच है**।
|
||||
- **अतिथि उपयोगकर्ताओं को निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)**। यह डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
|
||||
- **अतिथि उपयोगकर्ता पहुंच उनके अपने निर्देशिका वस्तुओं के गुणों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
|
||||
- **अतिथि उपयोगकर्ताओं की संपत्तियों और निर्देशिका वस्तुओं की सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)**। यह डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
|
||||
- **अतिथि उपयोगकर्ता पहुंच उनकी अपनी निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित है** सबसे प्रतिबंधात्मक है।
|
||||
- **अतिथि आमंत्रित कर सकते हैं** विकल्प:
|
||||
- **संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट**
|
||||
- **सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ हैं**
|
||||
@@ -157,7 +157,7 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
|
||||
### Default Consent Permissions
|
||||
|
||||
**अनुप्रयोगों के लिए उपयोगकर्ता सहमति**
|
||||
**User consent for applications**
|
||||
|
||||
- **उपयोगकर्ता सहमति की अनुमति न दें**
|
||||
- सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
|
||||
@@ -169,13 +169,13 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
|
||||
- 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
|
||||
|
||||
प्रशासनिक इकाइयाँ **एक संगठन के विशिष्ट हिस्से पर एक भूमिका से अनुमतियाँ देने** की अनुमति देती हैं।
|
||||
प्रशासनिक इकाइयाँ **एक संगठन के विशिष्ट भाग पर एक भूमिका से अनुमतियाँ देने** की अनुमति देती हैं।
|
||||
|
||||
उदाहरण:
|
||||
|
||||
@@ -205,64 +205,58 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
- कार्यान्वयन:
|
||||
- प्रत्येक क्षेत्र के लिए प्रशासनिक इकाइयाँ बनाएं (जैसे, "उत्तरी अमेरिका AU", "यूरोप AU")।
|
||||
- अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को भरें।
|
||||
- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को समाहित कर सकते हैं
|
||||
- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को **धारण कर सकते हैं**
|
||||
- AUs **डायनामिक सदस्यताओं** का समर्थन करते हैं
|
||||
- AUs **AUs को समाहित नहीं कर सकते**
|
||||
- AUs **AUs को नहीं रख सकते**
|
||||
- प्रशासक भूमिकाएँ असाइन करें:
|
||||
- क्षेत्रीय IT स्टाफ को "उपयोगकर्ता प्रशासक" भूमिका दें, जो उनके क्षेत्र के AU तक सीमित हो।
|
||||
- परिणाम: क्षेत्रीय IT प्रशासक अपने क्षेत्र के भीतर उपयोगकर्ता खातों का प्रबंधन कर सकते हैं बिना अन्य क्षेत्रों को प्रभावित किए।
|
||||
|
||||
### Entra ID Roles
|
||||
### Entra ID Roles & Permissions
|
||||
|
||||
- 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)
|
||||
- EntraID द्वारा **`PRIVILEGED`** के रूप में चिह्नित भूमिकाएँ सावधानी से असाइन की जानी चाहिए क्योंकि Microsoft [दस्तावेज़ों में समझाता है](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): विशेषाधिकार प्राप्त भूमिका असाइनमेंट का उपयोग सुरक्षित और इच्छित तरीके से नहीं किया गया तो विशेषाधिकार में वृद्धि हो सकती है।
|
||||
- सबसे विशेषाधिकार प्राप्त भूमिका **ग्लोबल एडमिनिस्ट्रेटर** है
|
||||
- भूमिका के विवरण में इसकी **सूक्ष्म अनुमतियाँ** देखी जा सकती हैं
|
||||
- भूमिकाएँ **सूक्ष्म अनुमतियों** को समूहित करती हैं और उन्हें उनके विवरण में पाया जा सकता है।
|
||||
- यह **कस्टम भूमिकाएँ** बनाने के लिए संभव है जिनमें इच्छित अनुमतियाँ हों। हालांकि किसी कारण से सभी सूक्ष्म अनुमतियाँ प्रशासकों को कस्टम भूमिकाएँ बनाने के लिए उपलब्ध नहीं हैं।
|
||||
- Entra ID में भूमिकाएँ पूरी तरह से **स्वतंत्र** होती हैं Azure में भूमिकाओं से। केवल संबंध यह है कि Entra ID में **ग्लोबल एडमिनिस्ट्रेटर** भूमिका वाले प्रमुख Azure में **उपयोगकर्ता पहुंच प्रशासक** भूमिका में वृद्धि कर सकते हैं।
|
||||
- Entra ID भूमिकाओं में **वाइल्डकार्ड** का उपयोग करना **संभव नहीं है**।
|
||||
|
||||
## Roles & Permissions
|
||||
## Azure Roles & Permissions
|
||||
|
||||
**भूमिकाएँ** **प्रमुखों** को **स्कोप** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
|
||||
|
||||
**भूमिकाएँ** जो **समूहों** को असाइन की जाती हैं, समूह के सभी **सदस्यों** द्वारा **विरासत में** ली जाती हैं।
|
||||
|
||||
स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा सभी संसाधन समूहों पर जो सदस्यता के भीतर हैं और **संसाधन समूह के भीतर सभी संसाधनों** पर।
|
||||
|
||||
### Classic Roles
|
||||
|
||||
| **Owner** | <ul><li>सभी संसाधनों तक पूर्ण पहुंच</li><li>अन्य उपयोगकर्ताओं के लिए पहुंच प्रबंधित कर सकते हैं</li></ul> | सभी संसाधन प्रकार |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **Contributor** | <ul><li>सभी संसाधनों तक पूर्ण पहुंच</li><li>पहुंच प्रबंधित नहीं कर सकते</li></ul> | सभी संसाधन प्रकार |
|
||||
| **Reader** | • सभी संसाधनों को देखें | सभी संसाधन प्रकार |
|
||||
| **User Access Administrator** | <ul><li>सभी संसाधनों को देखें</li><li>अन्य उपयोगकर्ताओं के लिए पहुंच प्रबंधित कर सकते हैं</li></ul> | सभी संसाधन प्रकार |
|
||||
- **भूमिकाएँ** **प्रमुखों** को **स्कोप** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
|
||||
- **भूमिकाएँ** समूहों को असाइन की गई हैं जो समूह के सभी **सदस्यों** द्वारा **विरासत में** ली जाती हैं।
|
||||
- जिस स्कोप पर भूमिका असाइन की गई थी, उसके आधार पर, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** के सभी संसाधन समूहों के भीतर और संसाधन समूह के भीतर **सभी संसाधनों** पर होगी।
|
||||
|
||||
### 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 उदाहरणों की जांच करें:
|
||||
|
||||
| [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` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जो आपको संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने, या हटाने की अनुमति देती हैं।
|
||||
- `dataActions` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जिससे आप संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने, या हटाने की अनुमति देते हैं।
|
||||
- `notActions` और `notDataActions` भूमिका से विशिष्ट अनुमतियों को बाहर करने के लिए उपयोग किए जाते हैं। हालाँकि, **वे उन्हें अस्वीकार नहीं करते**, यदि एक अलग भूमिका उन्हें प्रदान करती है, तो प्रमुख के पास वे होंगी।
|
||||
- `assignableScopes` उन स्कोपों की एक सूची है जहां भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।
|
||||
- `assignableScopes` उन स्कोपों की एक सूची है जहाँ भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।
|
||||
|
||||
कस्टम भूमिका के लिए अनुमतियों का JSON का उदाहरण:
|
||||
```json
|
||||
@@ -296,16 +290,16 @@ Azure Active Directory में प्रबंधित पहचानें
|
||||
```
|
||||
### Permissions order
|
||||
|
||||
- किसी **principal को एक resource पर कुछ access प्राप्त करने के लिए** उसे एक स्पष्ट भूमिका (role) दी जानी चाहिए (किसी भी तरह से) **उसे वह अनुमति देने के लिए**।
|
||||
- किसी **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 भूमिका वाले उपयोगकर्ताओं के पास '**User Access Administrator Azure भूमिका में Root Management Group में 'elevate' करने की क्षमता है**। इसलिए 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>
|
||||
@@ -316,9 +310,9 @@ Global Administrator भूमिका वाले उपयोगकर्त
|
||||
|
||||
### Deny Assignments
|
||||
|
||||
भूमिका असाइनमेंट की तरह, **deny assignments** का उपयोग **Azure संसाधनों तक पहुँच को नियंत्रित करने के लिए** किया जाता है। हालाँकि, **deny assignments** का उपयोग एक संसाधन तक पहुँच को **स्पष्ट रूप से अस्वीकार करने** के लिए किया जाता है, भले ही किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई हो। **Deny assignments** की प्राथमिकता **भूमिका असाइनमेंट** पर होती है, जिसका अर्थ है कि यदि किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई है लेकिन उसे एक deny assignment के माध्यम से स्पष्ट रूप से पहुँच से वंचित किया गया है, तो deny assignment की प्राथमिकता होगी।
|
||||
भूमिका असाइनमेंट की तरह, **deny assignments** का उपयोग **Azure संसाधनों तक पहुँच को नियंत्रित करने के लिए** किया जाता है। हालाँकि, **deny assignments** का उपयोग किसी संसाधन तक पहुँच को **स्पष्ट रूप से अस्वीकार करने** के लिए किया जाता है, भले ही किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई हो। **Deny assignments** की प्राथमिकता **role assignments** पर होती है, जिसका अर्थ है कि यदि किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई है लेकिन उसे deny assignment के माध्यम से स्पष्ट रूप से पहुँच से वंचित किया गया है, तो deny assignment की प्राथमिकता होगी।
|
||||
|
||||
भूमिका असाइनमेंट की तरह, **deny assignments** कुछ दायरे पर लागू होते हैं जो प्रभावित होने वाले principals और उन अनुमतियों को इंगित करते हैं जो अस्वीकृत की जा रही हैं। इसके अलावा, deny assignments के मामले में, यह संभव है कि **deny को बच्चों के संसाधनों द्वारा विरासत में प्राप्त होने से रोका जा सके**।
|
||||
भूमिका असाइनमेंट की तरह, **deny assignments** कुछ दायरे पर लागू होते हैं जो प्रभावित होने वाले principals और उन अनुमतियों को इंगित करते हैं जो अस्वीकृत की जा रही हैं। इसके अलावा, deny assignments के मामले में, यह संभव है कि **deny को बच्चों के संसाधनों द्वारा विरासत में प्राप्त होने से रोका जाए**।
|
||||
|
||||
### Azure Policies
|
||||
|
||||
@@ -337,9 +331,9 @@ Azure Policies **proactive** हैं: वे अनुपालन न कर
|
||||
|
||||
1. **Specific Azure Regions के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात किए जाएं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसके सभी डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हों।
|
||||
2. **Naming Standards को लागू करना**: नीतियाँ Azure संसाधनों के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में संसाधनों को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
|
||||
3. **Certain Resource Types को प्रतिबंधित करना**: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति को महंगे संसाधन प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकने के लिए सेट किया जा सकता है, ताकि लागत को नियंत्रित किया जा सके।
|
||||
4. **Tagging Policies को लागू करना**: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि सभी संसाधनों के लिए कुछ टैग मौजूद होने चाहिए, या उनके पास विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणीकरण के लिए उपयोगी है।
|
||||
5. **Resources तक सार्वजनिक पहुँच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ संसाधनों, जैसे स्टोरेज खाते या डेटाबेस, में सार्वजनिक एंडपॉइंट नहीं होना चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
|
||||
3. **Certain Resource Types को प्रतिबंधित करना**: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति सेट की जा सकती है जो महंगे संसाधन प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकती है, ताकि लागत को नियंत्रित किया जा सके।
|
||||
4. **Tagging Policies को लागू करना**: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि कुछ टैग मौजूद होने चाहिए, या सभी संसाधनों के लिए विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणीकरण के लिए उपयोगी है।
|
||||
5. **Resources तक सार्वजनिक पहुँच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ संसाधन, जैसे स्टोरेज खाते या डेटाबेस, सार्वजनिक एंडपॉइंट न हों, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
|
||||
6. **Automatically Applying Security Settings**: नीतियों का उपयोग संसाधनों पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
|
||||
|
||||
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आमतौर पर root management group** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
|
||||
@@ -364,19 +358,19 @@ Azure policy json example:
|
||||
```
|
||||
### Permissions Inheritance
|
||||
|
||||
Azure में **permissions किसी भी भाग को हायरार्की में असाइन की जा सकती हैं**। इसमें प्रबंधन समूह, सब्सक्रिप्शन, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। **Permissions** उन **resources** द्वारा **inherited** की जाती हैं जिनके लिए उन्हें असाइन किया गया था।
|
||||
Azure में **permissions किसी भी भाग को हायरार्की में सौंपे जा सकते हैं**। इसमें प्रबंधन समूह, सब्सक्रिप्शन, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। **Permissions** उन **resources** द्वारा **inherited** होते हैं जिनमें उन्हें सौंपा गया था।
|
||||
|
||||
यह हायरार्किकल संरचना एक्सेस permissions के कुशल और स्केलेबल प्रबंधन की अनुमति देती है।
|
||||
यह हायरार्किकल संरचना **access permissions** के प्रबंधन को कुशल और स्केलेबल बनाती है।
|
||||
|
||||
<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azure RBAC vs ABAC
|
||||
|
||||
**RBAC** (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: **एक प्रिंसिपल को एक भूमिका असाइन करना ताकि उसे एक संसाधन पर एक्सेस मिल सके**।\
|
||||
हालांकि, कुछ मामलों में आप **और अधिक बारीक एक्सेस प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **असाइनमेंट्स** के प्रबंधन को **सरल** करना चाहते हैं।
|
||||
**RBAC** (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: **एक प्रिंसिपल को एक भूमिका सौंपना ताकि उसे एक संसाधन पर पहुंच मिल सके**।\
|
||||
हालांकि, कुछ मामलों में आप **और अधिक बारीक पहुंच प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **सौंपने** के प्रबंधन को **सरल** करना चाहते हैं।
|
||||
|
||||
Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें** जोड़ी जाती हैं। एक _भूमिका असाइनमेंट शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं** ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है**।\
|
||||
आप **explicitly** **deny** **access** को विशिष्ट संसाधनों के लिए **शर्तों का उपयोग करके** नहीं कर सकते।
|
||||
Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका सौंपने की शर्तें** जोड़ी जाती हैं। एक _भूमिका सौंपने की शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका सौंपने में जोड़ सकते हैं** ताकि अधिक बारीक पहुंच नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका सौंपने के हिस्से के रूप में दी गई अनुमतियों को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक वस्तु को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता होती है**।\
|
||||
आप **विशेष रूप से** **resources** पर **access** को **शर्तों** का उपयोग करके **निषेध** नहीं कर सकते।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
Reference in New Issue
Block a user