Az - Basic Information

Reading time: 25 minutes

Organization Hierarchy

Management Groups

• इसमें अन्य प्रबंधन समूह या सदस्यता हो सकते हैं।
• यह शासन नियंत्रण जैसे RBAC और Azure नीति को प्रबंधन समूह स्तर पर एक बार लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा विरासत में लिया जाता है।
• 10,000 प्रबंधन समूह एकल निर्देशिका में समर्थित हो सकते हैं।
• एक प्रबंधन समूह का पेड़ छह स्तर की गहराई तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
• प्रत्येक प्रबंधन समूह और सदस्यता केवल एक माता-पिता का समर्थन कर सकती है।
• कई प्रबंधन समूह बनाए जा सकते हैं, लेकिन केवल 1 मूल प्रबंधन समूह है।
• मूल प्रबंधन समूह सभी अन्य प्रबंधन समूहों और सदस्यताओं को धारण करता है और इसे स्थानांतरित या हटाया नहीं जा सकता।
• एकल प्रबंधन समूह के भीतर सभी सदस्यताओं को एक ही Entra ID टेनेट पर भरोसा करना चाहिए।

Azure Subscriptions

• यह एक और तार्किक कंटेनर है जहां संसाधन (VMs, DBs…) चलाए जा सकते हैं और बिल किया जाएगा।
• इसका माता-पिता हमेशा एक प्रबंधन समूह होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सदस्यताएँ अन्य सदस्यताओं को नहीं रख सकती हैं।
• यह केवल एक Entra ID निर्देशिका पर भरोसा करता है।
• सदस्यता स्तर (या इसके किसी भी माता-पिता) पर लागू अनुमतियाँ सभी संसाधनों पर विरासत में ली जाती हैं।

Resource Groups

From the docs: एक संसाधन समूह एक कंटेनर है जो एक Azure समाधान के लिए संबंधित संसाधनों को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं। सामान्यतः, संसाधनों को उसी संसाधन समूह में जोड़ें जो एक ही जीवनचक्र साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।

सभी संसाधन को एक संसाधन समूह के भीतर होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।

Azure Resource IDs

Azure में प्रत्येक संसाधन का एक Azure Resource ID होता है जो इसे पहचानता है।

Azure Resource ID का प्रारूप इस प्रकार है:

• /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

एक वर्चुअल मशीन जिसका नाम myVM है, एक संसाधन समूह myResourceGroup के तहत सदस्यता ID 12345678-1234-1234-1234-123456789012 में, Azure Resource ID इस प्रकार दिखता है:

• /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Azure AD Domain Services

Azure

Azure Microsoft का व्यापक क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं की एक विस्तृत श्रृंखला प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता और स्टोरेज शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे का निर्माण करने और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।

Entra ID (formerly Azure Active Directory)

Entra ID एक क्लाउड-आधारित पहचान और पहुंच प्रबंधन सेवा है जिसे प्रमाणीकरण, प्राधिकरण और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी Microsoft सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।

Entra Domain Services (formerly Azure AD DS)

Entra Domain Services Entra ID की क्षमताओं को बढ़ाता है, पारंपरिक Windows Active Directory वातावरण के साथ संगत प्रबंधित डोमेन सेवाएँ प्रदान करता है। यह LDAP, Kerberos, और NTLM जैसे विरासती प्रोटोकॉल का समर्थन करता है, जिससे संगठनों को क्लाउड में पुराने अनुप्रयोगों को माइग्रेट या चलाने की अनुमति मिलती है बिना ऑन-प्रिमाइसेस डोमेन नियंत्रकों को तैनात किए। यह सेवा केंद्रीकृत प्रबंधन के लिए समूह नीति का भी समर्थन करती है, जिससे यह उन परिदृश्यों के लिए उपयुक्त बनती है जहां विरासती या AD-आधारित कार्यभार को आधुनिक क्लाउड वातावरण के साथ सह-अस्तित्व में होना आवश्यक है।

Entra ID Principals

Users

• नए उपयोगकर्ता
• चयनित टेनेट से ईमेल नाम और डोमेन निर्दिष्ट करें
• डिस्प्ले नाम निर्दिष्ट करें
• पासवर्ड निर्दिष्ट करें
• गुण निर्दिष्ट करें (पहला नाम, नौकरी का शीर्षक, संपर्क जानकारी…)
• डिफ़ॉल्ट उपयोगकर्ता प्रकार “सदस्य” है
• बाहरी उपयोगकर्ता
• आमंत्रित करने के लिए ईमेल और डिस्प्ले नाम निर्दिष्ट करें (यह एक गैर-माइक्रोसॉफ्ट ईमेल हो सकता है)
• गुण निर्दिष्ट करें
• डिफ़ॉल्ट उपयोगकर्ता प्रकार “अतिथि” है

Members & Guests Default Permissions

आप उन्हें https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions में देख सकते हैं लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:

• सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं और उनके सार्वजनिक गुणों को पढ़ें
• अतिथियों को आमंत्रित करें (बंद किया जा सकता है)
• सुरक्षा समूह बनाएं
• गैर-छिपे समूह सदस्यताओं को पढ़ें
• स्वामित्व वाले समूहों में अतिथियों को जोड़ें
• नया अनुप्रयोग बनाएं (बंद किया जा सकता है)
• Azure में 50 उपकरणों तक जोड़ें (बंद किया जा सकता है)

Users Default Configurable Permissions

• सदस्य (docs)
• अनुप्रयोगों को पंजीकृत करें: डिफ़ॉल्ट हाँ
• गैर-प्रशासक उपयोगकर्ताओं को टेनेट बनाने से रोकें: डिफ़ॉल्ट नहीं
• सुरक्षा समूह बनाएं: डिफ़ॉल्ट हाँ
• Microsoft Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट नहीं
• यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
• उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट हाँ
• उपयोगकर्ता को साइन इन रखे: डिफ़ॉल्ट हाँ
• उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
• अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट हाँ (Microsoft Graph के माध्यम से)
• अतिथि
• अतिथि उपयोगकर्ता पहुंच प्रतिबंध विकल्प:
• अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच है।
• अतिथि उपयोगकर्ताओं की संपत्तियों और निर्देशिका वस्तुओं की सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट)। यह डिफ़ॉल्ट रूप से अतिथि पहुंच को केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
• अतिथि उपयोगकर्ता पहुंच उनकी अपनी निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित है सबसे प्रतिबंधात्मक है।
• अतिथि आमंत्रित कर सकते हैं विकल्प:
• संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट
• सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ हैं
• केवल विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं
• संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित नहीं कर सकता जिसमें प्रशासक शामिल हैं (सबसे प्रतिबंधात्मक)
• बाहरी उपयोगकर्ता छोड़ें: डिफ़ॉल्ट सच
• बाहरी उपयोगकर्ताओं को संगठन छोड़ने की अनुमति दें

Groups

यहाँ 2 प्रकार के समूह हैं:

• सुरक्षा: इस प्रकार के समूह का उपयोग सदस्यों को अनुप्रयोगों, संसाधनों तक पहुंच देने और लाइसेंस असाइन करने के लिए किया जाता है। उपयोगकर्ता, उपकरण, सेवा प्रमुख और अन्य समूह सदस्य हो सकते हैं।
• Microsoft 365: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच प्रदान करता है। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
• इसका एक ईमेल पता होगा जो EntraID टेनेट के डोमेन के साथ होगा।

यहाँ 2 प्रकार की सदस्यताएँ हैं:

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

Service Principals

एक Service Principal एक पहचान है जो अनुप्रयोगों, होस्टेड सेवाओं, और स्वचालित उपकरणों के लिए Azure संसाधनों तक पहुंच प्राप्त करने के लिए बनाई गई है। यह पहुंच सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित होती है, जिससे आपको कौन से संसाधनों तक पहुंच प्राप्त है और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।

आप सेवा प्रमुख के रूप में सीधे लॉगिन कर सकते हैं, इसके लिए एक गुप्त (पासवर्ड), एक प्रमाणपत्र, या तीसरे पक्ष के प्लेटफार्मों (जैसे Github Actions) के लिए संघीय पहुंच प्रदान करके।

• यदि आप पासवर्ड प्रमाणीकरण चुनते हैं (डिफ़ॉल्ट), तो उत्पन्न पासवर्ड को सहेजें क्योंकि आप इसे फिर से एक्सेस नहीं कर पाएंगे।
• यदि आप प्रमाणपत्र प्रमाणीकरण चुनते हैं, तो सुनिश्चित करें कि अनुप्रयोग के पास निजी कुंजी पर पहुंच होगी।

App Registrations

एक App Registration एक कॉन्फ़िगरेशन है जो एक अनुप्रयोग को Entra ID के साथ एकीकृत करने और क्रियाएँ करने की अनुमति देता है।

Key Components:

1. Application ID (Client ID): Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
2. Redirect URIs: URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
3. Certificates, Secrets & Federated Credentials: यह संभव है कि एक गुप्त या प्रमाणपत्र उत्पन्न किया जाए ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
4. यदि एक प्रमाणपत्र या गुप्त उत्पन्न किया जाता है, तो यह संभव है कि एक व्यक्ति सेवा प्रमुख के रूप में लॉगिन CLI उपकरणों के साथ कर सके, अनुप्रयोग ID, गुप्त या प्रमाणपत्र और टेनेट (डोमेन या ID) को जानकर।
5. API Permissions: निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच प्राप्त कर सकता है।
6. Authentication Settings: ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
7. Service Principal: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
8. सेवा प्रमुख सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनके साथ इसे कॉन्फ़िगर किया गया था।

Default Consent Permissions

User consent for applications

• उपयोगकर्ता सहमति की अनुमति न दें
• सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
• सत्यापित प्रकाशकों, आंतरिक ऐप्स, और केवल चयनित अनुमतियों के लिए अनुरोध करने वाले ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)
• सभी उपयोगकर्ता केवल उन ऐप्स के लिए सहमति दे सकते हैं जो केवल "कम प्रभाव" के रूप में वर्गीकृत अनुमतियाँ मांगते हैं, सत्यापित प्रकाशकों से ऐप्स और टेनेट में पंजीकृत ऐप्स।
• डिफ़ॉल्ट कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
• User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
• offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे पहुंच प्रदान की है
• openid - उपयोगकर्ताओं को साइन इन करें
• profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
• email - उपयोगकर्ता के ईमेल पते को देखें
• ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)
• सभी उपयोगकर्ता किसी भी ऐप के लिए संगठन के डेटा तक पहुंच प्राप्त करने के लिए सहमति दे सकते हैं।

Admin consent requests: डिफ़ॉल्ट नहीं

• उपयोगकर्ता उन ऐप्स के लिए प्रशासक सहमति का अनुरोध कर सकते हैं जिनके लिए वे सहमति नहीं दे सकते
• यदि हाँ: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों पर सहमति दे सकते हैं
• यह भी कॉन्फ़िगर करें कि क्या उपयोगकर्ताओं को ईमेल सूचनाएँ और समाप्ति अनुस्मारक प्राप्त होंगे

Managed Identity (Metadata)

Azure Active Directory में प्रबंधित पहचानें अनुप्रयोगों की पहचान को स्वचालित रूप से प्रबंधित करने के लिए एक समाधान प्रदान करती हैं। ये पहचानें अनुप्रयोगों द्वारा Azure Active Directory (Azure AD) प्रमाणीकरण के साथ संगत संसाधनों से जोड़ने के लिए उपयोग की जाती हैं। यह कोड में क्लाउड क्रेडेंशियल्स को हार्डकोड करने की आवश्यकता को हटाने की अनुमति देता है क्योंकि अनुप्रयोग मेटाडेटा सेवा से संपर्क करके एक मान्य टोकन प्राप्त कर सकेगा ताकि Azure में निर्दिष्ट प्रबंधित पहचान के रूप में क्रियाएँ की जा सकें।

प्रबंधित पहचान के दो प्रकार हैं:

• सिस्टम-निर्धारित। कुछ Azure सेवाएँ आपको सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक सेवा प्रमुख बनाया जाता है जो उस सदस्यता द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब संसाधन को हटाया जाता है, तो Azure स्वचालित रूप से आपके लिए पहचान को हटा देता है।
• उपयोगकर्ता-निर्धारित। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID द्वारा विश्वसनीय सदस्यता में एक सेवा प्रमुख बनाया जाएगा। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या अधिक उदाहरणों (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, पहचान उन संसाधनों से अलग से प्रबंधित की जाती है जो इसका उपयोग करती हैं।

प्रबंधित पहचान स्थायी क्रेडेंशियल्स (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से एक्सेस किया जा सके।

Enterprise Applications

यह केवल Azure में सेवा प्रमुखों को फ़िल्टर करने और उन अनुप्रयोगों की जांच करने के लिए एक तालिका है जो असाइन की गई हैं।

यह "अनुप्रयोग" का एक और प्रकार नहीं है, Azure में कोई वस्तु "Enterprise Application" नहीं है, यह केवल सेवा प्रमुखों, ऐप पंजीकरणों और प्रबंधित पहचान की जांच करने के लिए एक अमूर्तता है।

Administrative Units

प्रशासनिक इकाइयाँ एक संगठन के विशिष्ट भाग पर एक भूमिका से अनुमतियाँ देने की अनुमति देती हैं।

उदाहरण:

• परिदृश्य: एक कंपनी चाहती है कि क्षेत्रीय IT प्रशासक केवल अपने क्षेत्र के उपयोगकर्ताओं का प्रबंधन करें।
• कार्यान्वयन:
• प्रत्येक क्षेत्र के लिए प्रशासनिक इकाइयाँ बनाएं (जैसे, "उत्तरी अमेरिका AU", "यूरोप AU")।
• अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को भरें।
• AUs उपयोगकर्ताओं, समूहों, या उपकरणों को शामिल कर सकते हैं
• AUs डायनामिक सदस्यताओं का समर्थन करते हैं
• AUs AUs को शामिल नहीं कर सकते
• प्रशासक भूमिकाएँ असाइन करें:
• क्षेत्रीय IT स्टाफ को "उपयोगकर्ता प्रशासक" भूमिका दें, जो उनके क्षेत्र के AU तक सीमित हो।
• परिणाम: क्षेत्रीय IT प्रशासक अपने क्षेत्र के भीतर उपयोगकर्ता खातों का प्रबंधन कर सकते हैं बिना अन्य क्षेत्रों को प्रभावित किए।

Entra ID Roles & Permissions

• Entra ID का प्रबंधन करने के लिए कुछ निर्मित भूमिकाएँ हैं जिन्हें Entra ID प्रमुखों को Entra ID का प्रबंधन करने के लिए असाइन किया जा सकता है
• भूमिकाएँ https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference में जांचें
• EntraID द्वारा PRIVILEGED के रूप में चिह्नित भूमिकाएँ सावधानी से असाइन की जानी चाहिए क्योंकि Microsoft दस्तावेज़ों में समझाता है: विशेषाधिकार प्राप्त भूमिका असाइनमेंट का उपयोग सुरक्षित और इच्छित तरीके से नहीं किया गया तो विशेषाधिकार में वृद्धि हो सकती है।
• सबसे विशेषाधिकार प्राप्त भूमिका ग्लोबल एडमिनिस्ट्रेटर है
• भूमिकाएँ सूक्ष्म अनुमतियों को समूहित करती हैं और इन्हें उनके विवरण में पाया जा सकता है।
• यह कस्टम भूमिकाएँ बनाने के लिए संभव है जिनमें इच्छित अनुमतियाँ हों। हालांकि किसी कारण से सभी सूक्ष्म अनुमतियाँ प्रशासकों को कस्टम भूमिकाएँ बनाने के लिए उपलब्ध नहीं हैं।
• Entra ID में भूमिकाएँ पूरी तरह से स्वतंत्र होती हैं Azure में भूमिकाओं से। केवल संबंध यह है कि Entra ID में ग्लोबल एडमिनिस्ट्रेटर भूमिका वाले प्रमुख Azure में यूजर एक्सेस एडमिनिस्ट्रेटर भूमिका में वृद्धि कर सकते हैं।
• Entra ID भूमिकाओं में वाइल्डकार्ड का उपयोग करना संभव नहीं है।

Azure Roles & Permissions

• भूमिकाएँ प्रमुखों को स्कोप पर असाइन की जाती हैं: principal -[HAS ROLE]->(scope)
• भूमिकाएँ समूहों को असाइन की गई हैं जो समूह के सभी सदस्यों द्वारा विरासत में ली जाती हैं।
• जिस स्कोप पर भूमिका असाइन की गई थी, उसके आधार पर, भूमिका को स्कोप कंटेनर के भीतर अन्य संसाधनों पर विरासत में लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास सदस्यता पर एक भूमिका है, तो उसके पास उस भूमिका का अधिकार होगा सभी संसाधन समूहों पर जो सदस्यता के भीतर हैं और सभी संसाधनों पर जो संसाधन समूह के भीतर हैं।

Built-In roles

From the docs: Azure role-based access control (Azure RBAC) में कई Azure निर्मित भूमिकाएँ हैं जिन्हें आप उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान को असाइन कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप Azure संसाधनों तक पहुंच को नियंत्रित करते हैं। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी Azure कस्टम भूमिकाएँ बना सकते हैं।

निर्मित भूमिकाएँ केवल उन संसाधनों पर लागू होती हैं जिनके लिए वे निर्धारित हैं, उदाहरण के लिए, कंप्यूट संसाधनों पर निर्मित भूमिकाओं के 2 उदाहरण देखें:

ये भूमिकाएँ प्रबंधन समूहों, सदस्यताओं और संसाधन समूहों जैसे तार्किक कंटेनरों पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को उन कंटेनरों के भीतर संसाधनों पर अधिकार प्राप्त होंगे।

• यहाँ सभी Azure निर्मित भूमिकाओं की सूची पाएं।
• यहाँ सभी Entra ID निर्मित भूमिकाओं की सूची पाएं।

Custom Roles

• यह भी संभव है कि कस्टम भूमिकाएँ बनाई जाएँ
• ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूहों, सदस्यता और संसाधन समूहों) में हो सकती है
• यह संभव है कि कस्टम भूमिका के पास सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए
• अनुमतियों को बाहर करना संभव है
• एक प्रमुख के पास एक बाहर की गई अनुमति नहीं होगी भले ही अनुमति कहीं और दी जा रही हो
• वाइल्डकार्ड का उपयोग करना संभव है
• उपयोग किया गया प्रारूप JSON है
• actions संसाधनों पर प्रबंधन संचालन के लिए अनुमतियों को संदर्भित करता है, जैसे संसाधन परिभाषाओं और सेटिंग्स को बनाने, अपडेट करने या हटाने।
• dataActions संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जो आपको संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने या हटाने की अनुमति देती हैं।
• notActions और notDataActions भूमिका से विशिष्ट अनुमतियों को बाहर करने के लिए उपयोग किए जाते हैं। हालाँकि, वे उन्हें अस्वीकार नहीं करते, यदि एक अलग भूमिका उन्हें प्रदान करती है, तो प्रमुख के पास वे होंगी।
• assignableScopes उन स्कोपों की एक सूची है जहां भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।

कस्टम भूमिका के लिए अनुमतियों का JSON का उदाहरण:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

Permissions order

• किसी principal को किसी resource पर कुछ access प्राप्त करने के लिए उसे एक स्पष्ट भूमिका (role) दी जानी चाहिए (किसी भी तरह से) उसे वह अनुमति देने के लिए।
• एक स्पष्ट deny assignment की प्राथमिकता होती है उस भूमिका पर जो अनुमति देती है।

Global Administrator

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

Assignments Conditions & MFA

the docs के अनुसार: वर्तमान में, शर्तें उन अंतर्निहित या कस्टम भूमिका असाइनमेंट में जोड़ी जा सकती हैं जिनमें blob storage data actions या queue storage data actions हैं।

Deny Assignments

भूमिका असाइनमेंट की तरह, deny assignments का उपयोग Azure संसाधनों तक पहुँच को नियंत्रित करने के लिए किया जाता है। हालाँकि, deny assignments का उपयोग किसी resource तक पहुँच को स्पष्ट रूप से अस्वीकार करने के लिए किया जाता है, भले ही किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई हो। Deny assignments की प्राथमिकता भूमिका असाइनमेंट पर होती है, जिसका अर्थ है कि यदि किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई है लेकिन उसे deny assignment के माध्यम से स्पष्ट रूप से पहुँच से वंचित किया गया है, तो deny assignment की प्राथमिकता होगी।

भूमिका असाइनमेंट की तरह, deny assignments कुछ दायरे पर लागू होते हैं जो प्रभावित होने वाले principals और उन अनुमतियों को इंगित करते हैं जो अस्वीकृत की जा रही हैं। इसके अलावा, deny assignments के मामले में, यह संभव है कि deny को बच्चों के संसाधनों द्वारा विरासत में प्राप्त होने से रोका जा सके।

Azure Policies

Azure Policies नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके संसाधन विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको Azure में संसाधनों पर सेटिंग्स को लागू या ऑडिट करने की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी संसाधनों में ट्रैकिंग के लिए विशिष्ट टैग हों।

Azure Policies proactive हैं: वे अनुपालन न करने वाले संसाधनों के निर्माण या परिवर्तन को रोक सकती हैं। वे reactive भी हैं, जिससे आप मौजूदा अनुपालन न करने वाले संसाधनों को खोज और ठीक कर सकते हैं।

Key Concepts

1. Policy Definition: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
2. Policy Assignment: एक नीति को एक विशिष्ट दायरे (जैसे, सब्सक्रिप्शन, संसाधन समूह) पर लागू करना।
3. Initiatives: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
4. Effect: यह निर्दिष्ट करता है कि नीति को सक्रिय करने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।

कुछ उदाहरण:

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 policy json example:

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

Permissions Inheritance

Azure में permissions किसी भी भाग को हायरार्की में असाइन की जा सकती हैं। इसमें प्रबंधन समूह, सब्सक्रिप्शन, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। Permissions उन resources द्वारा inherited की जाती हैं जिनके लिए उन्हें असाइन किया गया था।

यह हायरार्किकल संरचना एक्सेस permissions के प्रबंधन को कुशल और स्केलेबल बनाती है।

Azure RBAC vs ABAC

RBAC (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: एक प्रिंसिपल को एक भूमिका असाइन करना ताकि उसे एक संसाधन पर एक्सेस मिल सके।
हालांकि, कुछ मामलों में आप और अधिक बारीक एक्सेस प्रबंधन प्रदान करना चाहते हैं या सौ से अधिक भूमिका असाइनमेंट्स के प्रबंधन को सरल करना चाहते हैं।

Azure ABAC (attribute-based access control) Azure RBAC पर आधारित है, जिसमें विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें जोड़ी जाती हैं। एक भूमिका असाइनमेंट शर्त एक अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है।
आप explicitly deny access को विशिष्ट संसाधनों के लिए शर्तों का उपयोग करके नहीं कर सकते।

References

• 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://abouttmc.com/glossary/azure-subscription/#:~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.
• https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource
• https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration