Az - Basic Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
इसमें अन्य प्रबंधन समूह या सदस्यताएँ हो सकती हैं।
यह प्रबंधन समूह स्तर पर शासन नियंत्रण जैसे RBAC और Azure नीति लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा विरासत में लिया जा सकता है।
10,000 प्रबंधन समूह एकल निर्देशिका में समर्थित हो सकते हैं।
एक प्रबंधन समूह का पेड़ छह स्तर की गहराई तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
प्रत्येक प्रबंधन समूह और सदस्यता केवल एक माता-पिता का समर्थन कर सकती है।
कई प्रबंधन समूह बनाए जा सकते हैं, लेकिन केवल 1 मूल प्रबंधन समूह है।
मूल प्रबंधन समूह सभी अन्य प्रबंधन समूहों और सदस्यताओं को धारण करता है और इसे स्थानांतरित या हटाया नहीं जा सकता।
एकल प्रबंधन समूह के भीतर सभी सदस्यताओं को एक ही Entra ID टेनेट पर भरोसा करना चाहिए।
यह एक और तार्किक कंटेनर है जहां संसाधन (VMs, DBs…) चलाए जा सकते हैं और बिल किया जाएगा।
इसका माता-पिता हमेशा एक प्रबंधन समूह होता है (और यह मूल प्रबंधन समूह हो सकता है) क्योंकि सदस्यताएँ अन्य सदस्यताओं को नहीं रख सकती हैं।
यह केवल एक Entra ID निर्देशिका पर भरोसा करता है।
सदस्यता स्तर (या इसके किसी भी माता-पिता) पर लागू अनुमतियाँ सभी संसाधनों पर विरासत में ली जाती हैं।
From the docs: एक संसाधन समूह एक कंटेनर है जो एक Azure समाधान के लिए संबंधित संसाधनों को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं। सामान्यतः, संसाधनों को उसी संसाधन समूह में जोड़ें जो एक ही जीवन चक्र साझा करते हैं ताकि आप उन्हें आसानी से समूह के रूप में तैनात, अपडेट और हटा सकें।
सभी संसाधन को एक संसाधन समूह के भीतर होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
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 माइक्रोसॉफ्ट का व्यापक क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं की एक विस्तृत श्रृंखला प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढांचे बनाने और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
Entra ID एक क्लाउड-आधारित पहचान और पहुंच प्रबंधन सेवा है जिसे प्रमाणीकरण, प्राधिकरण और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी माइक्रोसॉफ्ट सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
Entra Domain Services Entra ID की क्षमताओं को बढ़ाता है, पारंपरिक Windows Active Directory वातावरण के साथ संगत प्रबंधित डोमेन सेवाएँ प्रदान करता है। यह LDAP, Kerberos, और NTLM जैसे विरासती प्रोटोकॉल का समर्थन करता है, जिससे संगठनों को क्लाउड में पुराने अनुप्रयोगों को माइग्रेट या चलाने की अनुमति मिलती है बिना ऑन-प्रिमाइसेस डोमेन नियंत्रकों को तैनात किए। यह सेवा केंद्रीकृत प्रबंधन के लिए समूह नीति का भी समर्थन करती है, जिससे यह उन परिदृश्यों के लिए उपयुक्त बनती है जहां विरासती या AD-आधारित कार्यभार को आधुनिक क्लाउड वातावरण के साथ सह-अस्तित्व में होना आवश्यक है।
नए उपयोगकर्ता
चयनित टेनेट से ईमेल नाम और डोमेन निर्दिष्ट करें
डिस्प्ले नाम निर्दिष्ट करें
पासवर्ड निर्दिष्ट करें
गुण निर्दिष्ट करें (पहला नाम, नौकरी का शीर्षक, संपर्क जानकारी…)
डिफ़ॉल्ट उपयोगकर्ता प्रकार “सदस्य” है
बाहरी उपयोगकर्ता
आमंत्रित करने के लिए ईमेल और डिस्प्ले नाम निर्दिष्ट करें (यह माइक्रोसॉफ्ट ईमेल नहीं हो सकता)
गुण निर्दिष्ट करें
डिफ़ॉल्ट उपयोगकर्ता प्रकार “अतिथि” है
आप उन्हें https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions पर देख सकते हैं, लेकिन अन्य क्रियाओं के बीच एक सदस्य सक्षम होगा:
सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं और उनके सार्वजनिक गुणों को पढ़ें
अतिथियों को आमंत्रित करें (बंद किया जा सकता है)
सुरक्षा समूह बनाएं
गैर-छिपे हुए समूह सदस्यताओं को पढ़ें
स्वामित्व वाले समूहों में अतिथियों को जोड़ें
नया अनुप्रयोग बनाएं (बंद किया जा सकता है)
Azure में 50 उपकरणों तक जोड़ें (बंद किया जा सकता है)
याद रखें कि Azure संसाधनों को सूचीबद्ध करने के लिए उपयोगकर्ता को अनुमति का स्पष्ट अनुदान चाहिए।
सदस्य (docs)
अनुप्रयोगों को पंजीकृत करें: डिफ़ॉल्ट हाँ
गैर-प्रशासक उपयोगकर्ताओं को टेनेट बनाने से रोकें: डिफ़ॉल्ट नहीं
सुरक्षा समूह बनाएं: डिफ़ॉल्ट हाँ
माइक्रोसॉफ्ट Entra प्रशासन पोर्टल तक पहुंच को प्रतिबंधित करें: डिफ़ॉल्ट नहीं
यह पोर्टल (केवल वेब) तक API पहुंच को प्रतिबंधित नहीं करता है
उपयोगकर्ताओं को लिंक्डइन के साथ कार्य या स्कूल खाता कनेक्ट करने की अनुमति दें: डिफ़ॉल्ट हाँ
उपयोगकर्ता को साइन इन रखने का विकल्प दिखाएं: डिफ़ॉल्ट हाँ
उपयोगकर्ताओं को उनके स्वामित्व वाले उपकरणों के लिए BitLocker कुंजी(ओं) को पुनर्प्राप्त करने से रोकें: डिफ़ॉल्ट नहीं (डिवाइस सेटिंग्स में जांचें)
अन्य उपयोगकर्ताओं को पढ़ें: डिफ़ॉल्ट हाँ (Microsoft Graph के माध्यम से)
अतिथि
अतिथि उपयोगकर्ता पहुंच प्रतिबंध
अतिथि उपयोगकर्ताओं को सदस्यों के समान पहुंच डिफ़ॉल्ट रूप से अतिथि उपयोगकर्ताओं को सभी सदस्य उपयोगकर्ता अनुमतियाँ प्रदान करता है।
अतिथि उपयोगकर्ताओं को निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित पहुंच है (डिफ़ॉल्ट) डिफ़ॉल्ट रूप से केवल उनके अपने उपयोगकर्ता प्रोफ़ाइल तक अतिथि पहुंच को प्रतिबंधित करता है। अन्य उपयोगकर्ताओं और समूह की जानकारी तक पहुंच अब अनुमति नहीं है।
अतिथि उपयोगकर्ता पहुंच उनकी अपनी निर्देशिका वस्तुओं की संपत्तियों और सदस्यताओं तक सीमित है सबसे प्रतिबंधात्मक है।
अतिथि आमंत्रित कर सकते हैं
संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित कर सकता है जिसमें अतिथि और गैर-प्रशासक शामिल हैं (सबसे समावेशी) - डिफ़ॉल्ट
सदस्य उपयोगकर्ता और विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं जिसमें सदस्य अनुमतियाँ हैं
केवल विशिष्ट प्रशासनिक भूमिकाओं में नियुक्त उपयोगकर्ता अतिथि उपयोगकर्ताओं को आमंत्रित कर सकते हैं
संगठन में कोई भी अतिथि उपयोगकर्ताओं को आमंत्रित नहीं कर सकता जिसमें प्रशासक शामिल हैं (सबसे प्रतिबंधात्मक)
बाहरी उपयोगकर्ता छोड़ें: डिफ़ॉल्ट सच
बाहरी उपयोगकर्ताओं को संगठन छोड़ने की अनुमति दें
भले ही डिफ़ॉल्ट रूप से प्रतिबंधित हो, उपयोगकर्ता (सदस्य और अतिथि) जिनके पास अनुमतियाँ हैं, वे पिछले कार्य कर सकते हैं।
यहां 2 प्रकार के समूह हैं:
सुरक्षा: इस प्रकार के समूह का उपयोग सदस्यों को अनुप्रयोगों, संसाधनों तक पहुंच देने और लाइसेंस असाइन करने के लिए किया जाता है। उपयोगकर्ता, उपकरण, सेवा प्रमुख और अन्य समूह सदस्य हो सकते हैं।
Microsoft 365: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को एक साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच प्रदान करता है। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
इसका एक ईमेल पता होगा जो EntraID टेनेट के डोमेन के साथ होगा।
यहां 2 प्रकार की सदस्यताएँ हैं:
नियुक्त: एक समूह में विशिष्ट सदस्यों को मैन्युअल रूप से जोड़ने की अनुमति देता है।
डायनामिक सदस्यता: नियमों का उपयोग करके सदस्यता को स्वचालित रूप से प्रबंधित करता है, जब सदस्यों के गुण बदलते हैं तो समूह में समावेश को अपडेट करता है।
एक Service Principal एक पहचान है जो अनुप्रयोगों, होस्टेड सेवाओं, और स्वचालित उपकरणों के साथ Azure संसाधनों तक पहुंच के लिए बनाई गई है। यह पहुंच सेवा प्रमुख को असाइन की गई भूमिकाओं द्वारा प्रतिबंधित होती है, जिससे आपको कौन से संसाधनों तक पहुंच प्राप्त है और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, हमेशा अनुशंसा की जाती है कि स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें बजाय कि उन्हें उपयोगकर्ता पहचान के साथ लॉगिन करने की अनुमति दें।
यह सेवा प्रमुख के रूप में सीधे लॉगिन करना संभव है एक गुप्त (पासवर्ड), एक प्रमाणपत्र, या तीसरे पक्ष के प्लेटफार्मों (जैसे Github Actions) के लिए संघीय पहुंच प्रदान करके।
यदि आप पासवर्ड प्रमाणीकरण चुनते हैं (डिफ़ॉल्ट), तो उत्पन्न पासवर्ड को सहेजें क्योंकि आप इसे फिर से एक्सेस नहीं कर पाएंगे।
यदि आप प्रमाणपत्र प्रमाणीकरण चुनते हैं, तो सुनिश्चित करें कि अनुप्रयोग के पास निजी कुंजी पर पहुंच होगी।
एक App Registration एक कॉन्फ़िगरेशन है जो एक अनुप्रयोग को Entra ID के साथ एकीकृत करने और क्रियाएँ करने की अनुमति देता है।
अनुप्रयोग ID (क्लाइंट ID): Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
Redirect URIs: URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
प्रमाणपत्र, गुप्त और संघीय क्रेडेंशियल्स: सेवा प्रमुख के रूप में लॉगिन करने के लिए एक गुप्त या प्रमाणपत्र उत्पन्न करना संभव है, या इसके लिए संघीय पहुंच प्रदान करना (जैसे Github Actions)।
यदि एक प्रमाणपत्र या गुप्त उत्पन्न किया जाता है, तो यह किसी व्यक्ति को CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन करने की अनुमति देता है, जब वह अनुप्रयोग ID, गुप्त या प्रमाणपत्र और टेनेट (डोमेन या ID) को जानता है।
API Permissions: निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच सकता है।
Authentication Settings: ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
Service Principal: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
सेवा प्रमुख सभी अनुरोधित अनुमतियाँ प्राप्त करेगा जिनके साथ इसे कॉन्फ़िगर किया गया था।
अनुप्रयोगों के लिए उपयोगकर्ता सहमति
उपयोगकर्ता सहमति की अनुमति न दें
सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
सत्यापित प्रकाशकों से चयनित अनुमतियों के लिए ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)
सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स के लिए या इस संगठन में पंजीकृत ऐप्स के लिए।
डिफ़ॉल्ट कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
offline_access - उन डेटा तक पहुंच बनाए रखें जिनका उपयोगकर्ताओं ने इसे पहुंच प्रदान किया है
openid - उपयोगकर्ताओं को साइन इन करें
profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
email - उपयोगकर्ता के ईमेल पते को देखें
अनुप्रयोगों के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)
सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच प्रदान करने के लिए सहमति दे सकते हैं।
प्रशासक सहमति अनुरोध: डिफ़ॉल्ट नहीं
उपयोगकर्ता उन ऐप्स के लिए प्रशासक सहमति का अनुरोध कर सकते हैं जिनके लिए वे सहमति नहीं दे सकते
यदि हाँ: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों पर सहमति दे सकते हैं
यह भी कॉन्फ़िगर करें कि क्या उपयोगकर्ताओं को ईमेल सूचनाएँ और समाप्ति अनुस्मारक प्राप्त होंगे
Azure Active Directory में प्रबंधित पहचानें अनुप्रयोगों की पहचान को स्वचालित रूप से प्रबंधित करने के लिए एक समाधान प्रदान करती हैं। ये पहचानें अनुप्रयोगों द्वारा Azure Active Directory (Azure AD) प्रमाणीकरण के साथ संगत संसाधनों से जोड़ने के लिए उपयोग की जाती हैं। यह कोड में क्लाउड क्रेडेंशियल्स को हार्डकोड करने की आवश्यकता को हटाने की अनुमति देता है क्योंकि अनुप्रयोग मेटाडेटा सेवा से संपर्क करके एक मान्य टोकन प्राप्त कर सकेगा ताकि Azure में निर्दिष्ट प्रबंधित पहचान के रूप में क्रियाएँ कर सके।
प्रबंधित पहचान के दो प्रकार हैं:
सिस्टम-निर्धारित। कुछ Azure सेवाएँ आपको सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो एक सेवा प्रमुख Entra ID टेनेट में बनाया जाता है जिसे उस सदस्यता द्वारा विश्वसनीय किया जाता है जहां संसाधन स्थित है। जब संसाधन को हटाया जाता है, तो Azure स्वचालित रूप से आपके लिए पहचान को हटा देता है।
उपयोगकर्ता-निर्धारित। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और एक सेवा प्रमुख EntraID में बनाई जाएगी जिसे सदस्यता द्वारा विश्वसनीय किया जाता है। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या अधिक उदाहरणों (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, पहचान का प्रबंधन उन संसाधनों से अलग किया जाता है जो इसका उपयोग करते हैं।
प्रबंधित पहचान स्थायी क्रेडेंशियल्स (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से जुड़े इसे एक्सेस किया जा सके।
यह केवल Azure में सेवा प्रमुखों को फ़िल्टर करने और जांचने के लिए एक तालिका है कि कौन से अनुप्रयोगों को असाइन किया गया है।
यह "अनुप्रयोग" का एक और प्रकार नहीं है, Azure में कोई वस्तु "Enterprise Application" नहीं है, यह केवल सेवा प्रमुखों, ऐप पंजीकरणों और प्रबंधित पहचान की जांच करने के लिए एक अमूर्तता है।
प्रशासनिक इकाइयाँ एक संगठन के विशिष्ट भाग पर एक भूमिका से अनुमतियाँ देने की अनुमति देती हैं।
उदाहरण:
परिदृश्य: एक कंपनी चाहती है कि क्षेत्रीय IT प्रशासक केवल अपने क्षेत्र के उपयोगकर्ताओं का प्रबंधन करें।
कार्यान्वयन:
प्रत्येक क्षेत्र के लिए प्रशासनिक इकाइयाँ बनाएं (जैसे, "उत्तरी अमेरिका AU", "यूरोप AU")।
अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को भरें।
AUs उपयोगकर्ताओं, समूहों, या उपकरणों को धारण कर सकते हैं
AUs डायनामिक सदस्यताओं का समर्थन करते हैं
AUs AUs को नहीं रख सकते
प्रशासक भूमिकाएँ असाइन करें:
क्षेत्रीय IT स्टाफ को "उपयोगकर्ता प्रशासक" भूमिका दें, जो उनके क्षेत्र के AU तक सीमित हो।
परिणाम: क्षेत्रीय IT प्रशासक अपने क्षेत्र के भीतर उपयोगकर्ता खातों का प्रबंधन कर सकते हैं बिना अन्य क्षेत्रों को प्रभावित किए।
Entra ID का प्रबंधन करने के लिए कुछ निर्मित भूमिकाएँ हैं जिन्हें Entra ID प्रमुखों को Entra ID का प्रबंधन करने के लिए असाइन किया जा सकता है
सबसे विशेषाधिकार प्राप्त भूमिका ग्लोबल एडमिनिस्ट्रेटर है
भूमिका के विवरण में इसके सूक्ष्म अनुमतियाँ देखी जा सकती हैं
भूमिकाएँ प्रमुखों को स्कोप पर असाइन की जाती हैं: principal -[HAS ROLE]->(scope)
भूमिकाएँ समूहों को असाइन की जाती हैं और समूह के सभी सदस्यों द्वारा विरासत में ली जाती हैं।
जिस स्कोप पर भूमिका असाइन की गई थी, उसके आधार पर, भूमिका को स्कोप कंटेनर के भीतर अन्य संसाधनों पर विरासत में लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास सदस्यता पर एक भूमिका है, तो उसके पास उस भूमिका का अधिकार होगा जो सदस्यता के भीतर सभी संसाधन समूहों और संसाधनों पर है।
Owner |
| सभी संसाधन प्रकार |
Contributor |
| सभी संसाधन प्रकार |
Reader | • सभी संसाधनों को देखें | सभी संसाधन प्रकार |
User Access Administrator |
| सभी संसाधन प्रकार |
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 निर्मित भूमिकाओं की सूची प्राप्त करें।
कस्टम भूमिकाएँ बनाना भी संभव है
ये एक स्कोप के भीतर बनाई जाती हैं, हालांकि एक भूमिका कई स्कोप (प्रबंधन समूह, सदस्यता और संसाधन समूह) में हो सकती है
यह संभव है कि सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए जो कस्टम भूमिका होगी
अनुमतियों को बाहर करना संभव है
एक प्रमुख जिसके पास बाहर की गई अनुमति है, वह इसे उपयोग नहीं कर सकेगा भले ही अनुमति कहीं और दी जा रही हो
वाइल्डकार्ड का उपयोग करना संभव है
उपयोग किया गया प्रारूप JSON है
actions संसाधन पर नियंत्रण क्रियाओं के लिए हैं
dataActions वस्तु के भीतर डेटा पर अनुमतियाँ हैं
कस्टम भूमिका के लिए अनुमतियों का JSON का उदाहरण:
किसी resource पर कुछ access पाने के लिए एक principal को उसे (किसी भी तरह से) वह अनुमति देने वाला एक स्पष्ट भूमिका दी जानी चाहिए।
एक स्पष्ट deny role assignment उस भूमिका पर प्राथमिकता रखता है जो अनुमति देती है।
Global Administrator एक भूमिका है जो Entra ID से 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 नियम हैं जो संगठनों को यह सुनिश्चित करने में मदद करते हैं कि उनके resources विशिष्ट मानकों और अनुपालन आवश्यकताओं को पूरा करते हैं। वे आपको Azure में resources पर सेटिंग्स को लागू या ऑडिट करने की अनुमति देते हैं। उदाहरण के लिए, आप अनधिकृत क्षेत्र में वर्चुअल मशीनों के निर्माण को रोक सकते हैं या सुनिश्चित कर सकते हैं कि सभी resources के पास ट्रैकिंग के लिए विशिष्ट टैग हों।
Azure Policies proactive हैं: वे अनुपालन न करने वाले resources के निर्माण या परिवर्तन को रोक सकती हैं। वे reactive भी हैं, जिससे आप मौजूदा अनुपालन न करने वाले resources को खोज और ठीक कर सकते हैं।
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, जैसे स्टोरेज खाते या डेटाबेस, के पास सार्वजनिक endpoints नहीं हों, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
स्वचालित रूप से सुरक्षा सेटिंग्स लागू करना: नीतियों का उपयोग resources पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन वे आमतौर पर root management group या अन्य management groups में उपयोग की जाती हैं।
Azure policy json example:
Azure में अनुमतियाँ किसी भी भाग को पदानुक्रम में सौंपा जा सकता है। इसमें प्रबंधन समूह, सदस्यताएँ, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। अनुमतियाँ उस इकाई के अंतर्गत संसाधनों द्वारा विरासत में ली जाती हैं जहाँ उन्हें सौंपा गया था।
यह पदानुक्रमित संरचना पहुँच अनुमतियों के कुशल और स्केलेबल प्रबंधन की अनुमति देती है।
RBAC (भूमिका-आधारित पहुँच नियंत्रण) वही है जो हमने पहले के अनुभागों में देखा है: एक संसाधन पर पहुँच प्रदान करने के लिए एक प्रिंसिपल को भूमिका सौंपना। हालांकि, कुछ मामलों में आप अधिक बारीक पहुँच प्रबंधन प्रदान करना चाहते हैं या सौ से अधिक भूमिका सौंपने के प्रबंधन को सरल करना चाहते हैं।
Azure ABAC (विशेषता-आधारित पहुँच नियंत्रण) Azure RBAC पर आधारित है, जिसमें विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका सौंपने की शर्तें जोड़ी जाती हैं। एक भूमिका सौंपने की शर्त एक अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका सौंपने में जोड़ सकते हैं ताकि अधिक बारीक पहुँच नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका सौंपने के हिस्से के रूप में दी गई अनुमतियों को फ़िल्टर करती है। उदाहरण के लिए, आप एक शर्त जोड़ सकते हैं जो एक वस्तु को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता होती है। आप **विशेष संसाधनों तक पहुँच को स्पष्ट रूप से नकार नहीं कर सकते शर्तों का उपयोग करके।
Azure में Privileged Identity Management (PIM) एक उपकरण है जो Azure Active Directory और Azure में विशेष पहुँच का प्रबंधन, नियंत्रण और निगरानी करता है। यह समय-सीमित विशेष पहुँच, अनुमोदन कार्यप्रवाहों को लागू करने, और अतिरिक्त प्रमाणीकरण की आवश्यकता प्रदान करके सुरक्षा को बढ़ाता है। यह दृष्टिकोण यह सुनिश्चित करके अनधिकृत पहुँच के जोखिम को कम करता है कि उच्चीकृत अनुमतियाँ केवल तभी दी जाती हैं जब आवश्यक हो और एक विशिष्ट अवधि के लिए।
OIDC में तीन प्रकार के टोकन होते हैं:
Access Tokens: क्लाइंट इस टोकन को संसाधन सर्वर को संसाधनों तक पहुँचने के लिए प्रस्तुत करता है। इसका उपयोग केवल उपयोगकर्ता, क्लाइंट, और संसाधन के एक विशिष्ट संयोजन के लिए किया जा सकता है और समाप्ति तक रद्द नहीं किया जा सकता - जो कि डिफ़ॉल्ट रूप से 1 घंटा है।
ID Tokens: क्लाइंट इस टोकन को प्राधिकरण सर्वर से प्राप्त करता है। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह उपयोगकर्ता और क्लाइंट के एक विशिष्ट संयोजन से बंधा होता है।
Refresh Tokens: क्लाइंट को एक्सेस टोकन के साथ प्रदान किया जाता है। इसका उपयोग नए एक्सेस और ID टोकन प्राप्त करने के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के एक विशिष्ट संयोजन से बंधा होता है और इसे रद्द किया जा सकता है। डिफ़ॉल्ट समाप्ति 90 दिन है निष्क्रिय रिफ्रेश टोकन के लिए और सक्रिय टोकन के लिए कोई समाप्ति नहीं।
शर्तीय पहुँच के लिए जानकारी JWT के अंदर संग्रहित होती है। इसलिए, यदि आप अनुमत IP पते से टोकन का अनुरोध करते हैं, तो वह IP टोकन में संग्रहित होगा और फिर आप उस टोकन का उपयोग गैर-अनुमत IP से संसाधनों तक पहुँचने के लिए कर सकते हैं।
जिस क्रिया को आप करना चाहते हैं उसके आधार पर एक्सेस टोकन का "aud" उस API URL से संपर्क करने के लिए अधिकृत होना चाहिए जिसे आप संपर्क करेंगे।
कमांड az account get-access-token --resource-type [...] निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप एक्सेस टोकन में एक विशिष्ट "aud" जोड़ेगा:
ध्यान दें कि निम्नलिखित केवल az account get-access-token द्वारा समर्थित APIs हैं लेकिन और भी हैं।
aad-graph (Azure Active Directory Graph API): इसका उपयोग विरासती Azure AD Graph API (अवशिष्ट) तक पहुँचने के लिए किया जाता है, जो अनुप्रयोगों को Azure Active Directory (Azure AD) में निर्देशिका डेटा पढ़ने और लिखने की अनुमति देता है।
https://graph.windows.net/
arm (Azure Resource Manager): इसका उपयोग Azure संसाधनों को Azure Resource Manager API के माध्यम से प्रबंधित करने के लिए किया जाता है। इसमें वर्चुअल मशीनों, स्टोरेज खातों, और अधिक जैसे संसाधनों को बनाने, अपडेट करने, और हटाने जैसी क्रियाएँ शामिल हैं।
https://management.core.windows.net/ or https://management.azure.com/
batch (Azure Batch Services): इसका उपयोग Azure Batch तक पहुँचने के लिए किया जाता है, जो क्लाउड में बड़े पैमाने पर समानांतर और उच्च-प्रदर्शन कंप्यूटिंग अनुप्रयोगों को कुशलता से सक्षम बनाता है।
https://batch.core.windows.net/
data-lake (Azure Data Lake Storage): इसका उपयोग Azure Data Lake Storage Gen1 के साथ बातचीत करने के लिए किया जाता है, जो एक स्केलेबल डेटा संग्रहण और विश्लेषण सेवा है।
https://datalake.azure.net/
media (Azure Media Services): इसका उपयोग Azure Media Services तक पहुँचने के लिए किया जाता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित मीडिया प्रसंस्करण और वितरण सेवाएँ प्रदान करता है।
https://rest.media.azure.net
ms-graph (Microsoft Graph API): इसका उपयोग Microsoft Graph API तक पहुँचने के लिए किया जाता है, जो Microsoft 365 सेवाओं के डेटा के लिए एकीकृत अंत बिंदु है। यह आपको Azure AD, Office 365, Enterprise Mobility, और सुरक्षा सेवाओं जैसी सेवाओं से डेटा और अंतर्दृष्टि तक पहुँचने की अनुमति देता है।
https://graph.microsoft.com
oss-rdbms (Azure Open Source Relational Databases): इसका उपयोग MySQL, PostgreSQL, और MariaDB जैसी ओपन-सोर्स रिलेशनल डेटाबेस इंजनों के लिए Azure Database सेवाओं तक पहुँचने के लिए किया जाता है।
https://ossrdbms-aad.database.windows.net
अलग-अलग तरीकों से एक्सेस टोकन अनुरोध करने और उनके साथ लॉगिन करने के लिए निम्नलिखित पृष्ठ देखें:
Az - Entra ID (formerly AzureAD - AAD)Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
