Az - Basic Information
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 माइक्रोसॉफ्ट का व्यापक क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो एक विस्तृत श्रृंखला की सेवाएँ प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता, और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे बनाने, और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए उपकरण प्रदान करता है ताकि वे अनुप्रयोगों और सेवाओं को निर्बाध रूप से बना, तैनात और प्रबंधित कर सकें, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
Entra ID (formerly Azure Active Directory)
Entra ID एक क्लाउड-आधारित पहचान और पहुंच प्रबंधन सेवा है जिसे प्रमाणीकरण, प्राधिकरण, और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure, और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी माइक्रोसॉफ्ट सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (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 उपकरणों तक जोड़ें (बंद किया जा सकता है)
याद रखें कि Azure संसाधनों को सूचीबद्ध करने के लिए उपयोगकर्ता को अनुमति का स्पष्ट अनुदान चाहिए।
Users Default Configurable Permissions
सदस्य (docs)
अनुप्रयोगों को पंजीकृत करें: डिफ़ॉल्ट हाँ
गैर-प्रशासक उपयोगकर्ताओं को टेनेट बनाने से रोकें: डिफ़ॉल्ट नहीं
सुरक्षा समूह बनाएं: डिफ़ॉल्ट हाँ
माइक्रोसॉफ्ट Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट नहीं
यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट हाँ
उपयोगकर्ता को साइन इन रखने का विकल्प दिखाएँ: डिफ़ॉल्ट हाँ
उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट हाँ (माइक्रोसॉफ्ट ग्राफ के माध्यम से)
अतिथि
अतिथि उपयोगकर्ता पहुंच प्रतिबंध
अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच डिफ़ॉल्ट रूप से अतिथि उपयोगकर्ताओं को सभी सदस्य उपयोगकर्ता अनुमतियाँ प्रदान करता है।
अतिथि उपयोगकर्ताओं को निर्देशिका वस्तुओं की गुणों और सदस्यताओं तक सीमित पहुंच डिफ़ॉल्ट रूप से केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक अतिथि पहुंच को सीमित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
अतिथि उपयोगकर्ता पहुंच उनके अपने निर्देशिका वस्तुओं की गुणों और सदस्यताओं तक सीमित है सबसे प्रतिबंधात्मक है।
अतिथि आमंत्रित कर सकते हैं
संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट
सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ शामिल हैं
केवल विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं
संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित नहीं कर सकता जिसमें प्रशासक शामिल हैं (सबसे प्रतिबंधात्मक)
बाहरी उपयोगकर्ता छोड़ें: डिफ़ॉल्ट सच
बाहरी उपयोगकर्ताओं को संगठन छोड़ने की अनुमति दें
यहां तक कि यदि डिफ़ॉल्ट रूप से प्रतिबंधित है, तो उपयोगकर्ता (सदस्य और अतिथि) जिनके पास अनुमतियाँ दी गई हैं, वे पिछले कार्य कर सकते हैं।
Groups
यहां 2 प्रकार के समूह हैं:
सुरक्षा: इस प्रकार के समूह का उपयोग सदस्यों को अनुप्रयोगों, संसाधनों तक पहुंच देने और लाइसेंस असाइन करने के लिए किया जाता है। उपयोगकर्ता, उपकरण, सेवा प्रमुख और अन्य समूह सदस्य हो सकते हैं।
Microsoft 365: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को एक साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच देने के लिए। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
इसका एक ईमेल पता होगा जो EntraID टेनेट के डोमेन के साथ होगा।
यहां 2 प्रकार की सदस्यताएँ हैं:
नियुक्त: एक समूह में विशिष्ट सदस्यों को मैन्युअल रूप से जोड़ने की अनुमति देता है।
डायनामिक सदस्यता: नियमों का उपयोग करके सदस्यता को स्वचालित रूप से प्रबंधित करता है, जब सदस्यों के गुण बदलते हैं तो समूह में समावेश को अपडेट करता है।
Service Principals
एक Service Principal एक पहचान है जो अनुप्रयोगों, होस्टेड सेवाओं, और स्वचालित उपकरणों के साथ Azure संसाधनों तक पहुंच के लिए उपयोग के लिए बनाई गई है। यह पहुंच सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित होती है, जिससे आपको कौन से संसाधनों तक पहुंच प्राप्त है और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।
यह सेवा प्रमुख के रूप में सीधे लॉगिन करना संभव है एक गुप्त (पासवर्ड), एक प्रमाणपत्र, या तीसरे पक्ष के प्लेटफार्मों (जैसे Github Actions) के लिए संघीय पहुंच प्रदान करके।
यदि आप पासवर्ड प्रमाणीकरण चुनते हैं (डिफ़ॉल्ट), तो उत्पन्न पासवर्ड को सहेजें क्योंकि आप इसे फिर से एक्सेस नहीं कर पाएंगे।
यदि आप प्रमाणपत्र प्रमाणीकरण चुनते हैं, तो सुनिश्चित करें कि अनुप्रयोग के पास निजी कुंजी पर पहुंच होगी।
App Registrations
एक App Registration एक कॉन्फ़िगरेशन है जो एक अनुप्रयोग को Entra ID के साथ एकीकृत करने और क्रियाएँ करने की अनुमति देता है।
Key Components:
Application ID (Client ID): Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
Redirect URIs: URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
Certificates, Secrets & Federated Credentials: यह संभव है कि एक गुप्त या प्रमाणपत्र उत्पन्न किया जाए ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
यदि एक प्रमाणपत्र या गुप्त उत्पन्न किया जाता है, तो यह संभव है कि एक व्यक्ति सेवा प्रमुख के रूप में लॉगिन करे CLI उपकरणों के साथ अनुप्रयोग ID, गुप्त या प्रमाणपत्र और टेनेट (डोमेन या ID) को जानकर।
API Permissions: निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच सकता है।
Authentication Settings: ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
Service Principal: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
सेवा प्रमुख सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनके साथ इसे कॉन्फ़िगर किया गया था।
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 का प्रबंधन करने के लिए असाइन किया जा सकता है
सबसे विशेषाधिकार प्राप्त भूमिका ग्लोबल एडमिनिस्ट्रेटर है
भूमिका के विवरण में इसके सूक्ष्म अनुमतियाँ देखी जा सकती हैं
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 उदाहरणों की जांच करें:
डिस्क बैकअप करने के लिए बैकअप वॉल्ट को अनुमति प्रदान करता है।
3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
पोर्टल में वर्चुअल मशीनों को देखें और एक सामान्य उपयोगकर्ता के रूप में लॉगिन करें।
fb879df8-f326-4884-b1cf-06f3ad86be52
ये भूमिकाएँ तार्किक कंटेनरों (जैसे प्रबंधन समूह, सदस्यताएँ और संसाधन समूह) पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को उन कंटेनरों के भीतर संसाधनों पर अधिकार प्राप्त होंगे।
यहां सभी Azure निर्मित भूमिकाओं की सूची प्राप्त करें।
यहां सभी Entra ID निर्मित भूमिकाओं की सूची प्राप्त करें।
Custom Roles
यह भी संभव है कि कस्टम भूमिकाएँ बनाई जाएँ
ये एक स्कोप के भीतर बनाई जाती हैं, हालांकि एक भूमिका कई स्कोप (प्रबंधन समूह, सदस्यता और संसाधन समूह) में हो सकती है
यह संभव है कि कस्टम भूमिका के पास सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए
अनुमतियों को बाहर करना संभव है
एक प्रमुख जिसके पास एक बाहर की गई अनुमति है, वह इसे उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
वाइल्डकार्ड का उपयोग करना संभव है
उपयोग किया गया प्रारूप JSON है
actionsसंसाधन पर नियंत्रण क्रियाओं के लिए हैंdataActionsवस्तु के भीतर डेटा पर अनुमतियाँ हैं
Example of permissions JSON for a custom role:
Permissions order
किसी resource पर कुछ access पाने के लिए एक principal को उसे (किसी भी तरह) वह अनुमति देने वाला एक स्पष्ट भूमिका दी जानी चाहिए।
एक स्पष्ट deny role assignment उस भूमिका पर प्राथमिकता रखता है जो अनुमति देती है।
Global Administrator
Global Administrator एक भूमिका है जो Entra ID tenant पर पूर्ण नियंत्रण प्रदान करती है। हालाँकि, यह डिफ़ॉल्ट रूप से Azure resources पर कोई अनुमति नहीं देती है।
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
Azure Policies
Azure Policies नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके resources विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। ये आपको Azure में resources पर सेटिंग्स को लागू या ऑडिट करने की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी resources ट्रैकिंग के लिए विशिष्ट टैग रखते हैं।
Azure Policies proactive हैं: ये अनुपालन न करने वाले resources के निर्माण या परिवर्तन को रोक सकती हैं। ये reactive भी हैं, जो आपको मौजूदा अनुपालन न करने वाले resources को खोजने और ठीक करने की अनुमति देती हैं।
Key Concepts
Policy Definition: एक नियम, जो JSON में लिखा गया है, जो यह निर्दिष्ट करता है कि क्या अनुमति है या आवश्यक है।
Policy Assignment: एक विशेष दायरे (जैसे, subscription, resource group) पर नीति का अनुप्रयोग।
Initiatives: नीतियों का एक संग्रह जो व्यापक प्रवर्तन के लिए एक साथ समूहित किया गया है।
Effect: यह निर्दिष्ट करता है कि नीति सक्रिय होने पर क्या होता है (जैसे, "Deny," "Audit," या "Append")।
कुछ उदाहरण:
विशिष्ट Azure क्षेत्रों के साथ अनुपालन सुनिश्चित करना: यह नीति सुनिश्चित करती है कि सभी resources विशिष्ट Azure क्षेत्रों में तैनात हैं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसका सारा डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हो।
नामकरण मानकों को लागू करना: नीतियाँ Azure resources के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में resources को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
कुछ resource प्रकारों को प्रतिबंधित करना: यह नीति कुछ प्रकार के resources के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति को महंगे resource प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकने के लिए सेट किया जा सकता है, ताकि लागत को नियंत्रित किया जा सके।
टैगिंग नीतियों को लागू करना: टैग Azure resources के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो resource प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि सभी resources के लिए कुछ टैग मौजूद होने चाहिए, या उनके पास विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या resources की श्रेणीबद्धता के लिए उपयोगी है।
resources के लिए सार्वजनिक पहुंच को सीमित करना: नीतियाँ यह लागू कर सकती हैं कि कुछ resources, जैसे स्टोरेज खाते या डेटाबेस, सार्वजनिक एंडपॉइंट न रखें, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हैं।
स्वचालित रूप से सुरक्षा सेटिंग्स लागू करना: नीतियों का उपयोग resources पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये आम तौर पर root management group या अन्य management groups में उपयोग की जाती हैं।
Azure policy json example:
Permissions Inheritance
Azure में अनुमतियाँ किसी भी भाग को पदानुक्रम में सौंपा जा सकता है। इसमें प्रबंधन समूह, सदस्यताएँ, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। अनुमतियाँ विरासत में मिलती हैं उन संसाधनों द्वारा जो उस इकाई में हैं जहाँ उन्हें सौंपा गया था।
यह पदानुक्रमित संरचना पहुँच अनुमतियों के कुशल और स्केलेबल प्रबंधन की अनुमति देती है।
Azure RBAC vs ABAC
RBAC (भूमिका-आधारित पहुँच नियंत्रण) वही है जो हमने पहले के अनुभागों में देखा है: एक संसाधन पर पहुँच प्रदान करने के लिए एक प्रिंसिपल को एक भूमिका सौंपना। हालांकि, कुछ मामलों में आप और अधिक बारीक पहुँच प्रबंधन प्रदान करना चाहते हैं या सौ की संख्या में भूमिका सौंपने के प्रबंधन को सरल करना चाहते हैं।
Azure ABAC (गुण-आधारित पहुँच नियंत्रण) Azure RBAC पर आधारित है, जिसमें विशिष्ट क्रियाओं के संदर्भ में गुणों के आधार पर भूमिका सौंपने की शर्तें जोड़ी जाती हैं। एक भूमिका सौंपने की शर्त एक अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका सौंपने में जोड़ सकते हैं ताकि अधिक बारीक पहुँच नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका सौंपने के हिस्से के रूप में दी गई अनुमतियों को फ़िल्टर करती है। उदाहरण के लिए, आप एक शर्त जोड़ सकते हैं जो एक वस्तु को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता होती है। आप विशिष्ट संसाधनों तक पहुँच को स्पष्ट रूप से निषेध नहीं कर सकते शर्तों का उपयोग करके।
