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

Az - Basic Information

{{#include ../../../banners/hacktricks-training.md}}

Organization Hierarchy

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

Management Groups

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

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

Azure Subscriptions

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

Resource Groups

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

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

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

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

Entra ID (पूर्व में Azure Active Directory)

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

Entra Domain Services (पूर्व में 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 उपकरणों तक जोड़ें (बंद किया जा सकता है)

Note

याद रखें कि Azure संसाधनों को सूचीबद्ध करने के लिए उपयोगकर्ता को अनुमति का स्पष्ट अनुदान चाहिए।

Users Default Configurable Permissions

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

Tip

भले ही डिफ़ॉल्ट रूप से प्रतिबंधित हो, उपयोगकर्ता (सदस्य और अतिथि) जिनके पास अनुमतियाँ हैं, वे पिछले कार्य कर सकते हैं।

Groups

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

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

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

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

Service Principals

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

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

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

App Registrations

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

Key Components:

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

Default Consent Permissions

अनुप्रयोगों के लिए उपयोगकर्ता सहमति

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

प्रशासक सहमति अनुरोध: डिफ़ॉल्ट नहीं

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

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

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

Roles & Permissions

भूमिकाएँ प्रमुखों को स्कोप पर असाइन की जाती हैं: principal -[HAS ROLE]->(scope)

भूमिकाएँ समूहों को असाइन की जाती हैं और समूह के सभी सदस्यों द्वारा विरासत में प्राप्त की जाती हैं।

स्कोप के आधार पर जिस पर भूमिका असाइन की गई थी, भूमिका को स्कोप कंटेनर के भीतर अन्य संसाधनों पर विरासत में मिल सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास सब्सक्रिप्शन पर एक भूमिका है, तो उसके पास उस भूमिका का अधिकार होगा सभी संसाधन समूहों पर जो सब्सक्रिप्शन के भीतर हैं और संसाधनों पर जो संसाधन समूह के भीतर हैं।

Classic Roles

Owner	सभी संसाधनों तक पूर्ण पहुंच अन्य उपयोगकर्ताओं के लिए पहुंच प्रबंधित कर सकते हैं	सभी संसाधन प्रकार
Contributor	सभी संसाधनों तक पूर्ण पहुंच पहुंच प्रबंधित नहीं कर सकते	सभी संसाधन प्रकार
Reader	• सभी संसाधनों को देखें	सभी संसाधन प्रकार
User Access Administrator	सभी संसाधनों को देखें अन्य उपयोगकर्ताओं के लिए पहुंच प्रबंधित कर सकते हैं	सभी संसाधन प्रकार

Built-In roles

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

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

Disk Backup Reader	बैकअप वॉल्ट को डिस्क बैकअप करने की अनुमति प्रदान करता है।	3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
Virtual Machine User Login	पोर्टल में वर्चुअल मशीनों को देखें और एक सामान्य उपयोगकर्ता के रूप में लॉगिन करें।	fb879df8-f326-4884-b1cf-06f3ad86be52

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

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

Custom Roles

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

कस्टम भूमिका के लिए अनुमतियों का 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 प्राप्त करने के लिए उसे एक स्पष्ट भूमिका दी जानी चाहिए (किसी भी तरह से) उसे वह अनुमति देने के लिए।
• एक स्पष्ट deny role assignment की प्राथमिकता होती है उस भूमिका पर जो अनुमति देती है।

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

Global Administrator

Global Administrator एक भूमिका है Entra ID से जो Entra ID tenant पर पूर्ण नियंत्रण प्रदान करती है। हालाँकि, यह डिफ़ॉल्ट रूप से Azure resources पर कोई अनुमति नहीं देती है।

Global Administrator भूमिका वाले उपयोगकर्ताओं के पास 'User Access Administrator Azure भूमिका में Root Management Group में 'elevate' करने की क्षमता है। इसलिए Global Administrators सभी Azure subscriptions और management groups में access प्रबंधित कर सकते हैं।
यह elevation पृष्ठ के अंत में किया जा सकता है: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Azure Policies

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

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

Key Concepts

1. Policy Definition: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
2. Policy Assignment: एक नीति को एक विशिष्ट दायरे (जैसे, subscription, resource group) पर लागू करना।
3. Initiatives: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
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, जैसे स्टोरेज खाते या डेटाबेस, के पास सार्वजनिक endpoints नहीं होने चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हैं।
6. स्वचालित रूप से सुरक्षा सेटिंग्स लागू करना: नीतियों का उपयोग resources पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।

ध्यान दें कि Azure Policies को Azure की किसी भी स्तर पर जोड़ा जा सकता है, लेकिन वे आमतौर पर root management group या अन्य management groups में उपयोग की जाती हैं।

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

In Azure permissions are can be assigned to any part of the hierarchy. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are inherited by contained resources of the entity where they were assigned.

This hierarchical structure allows for efficient and scalable management of access permissions.

Azure RBAC vs ABAC

RBAC (role-based access control) is what we have seen already in the previous sections: Assigning a role to a principal to grant him access over a resource.
However, in some cases you might want to provide more fined-grained access management or simplify the management of hundreds of role assignments.

Azure ABAC (attribute-based access control) builds on Azure RBAC by adding role assignment conditions based on attributes in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can add a condition that requires an object to have a specific tag to read the object.
You cannot explicitly deny access to specific resources using conditions.

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

{{#include ../../../banners/hacktricks-training.md}}