Az - Basic Information

Support HackTricks

Organization Hierarchy

Management Groups

यदि आपकी संगठन के पास कई Azure सब्सक्रिप्शन हैं, तो आपको उन सब्सक्रिप्शन के लिए एक्सेस, नीतियों और अनुपालन को प्रभावी ढंग से प्रबंधित करने का एक तरीका चाहिए। प्रबंधन समूह सब्सक्रिप्शन के ऊपर एक शासन दायरा प्रदान करते हैं।

ध्यान दें कि 10,000 प्रबंधन समूह एक ही निर्देशिका में समर्थित हो सकते हैं और एक प्रबंधन समूह का पेड़ छह स्तर की गहराई तक का समर्थन कर सकता है।

From the docs: प्रत्येक निर्देशिका को एकल शीर्ष-स्तरीय प्रबंधन समूह कहा जाता है। रूट प्रबंधन समूह को इस तरह से बनाया गया है कि सभी प्रबंधन समूह और सब्सक्रिप्शन इसके ऊपर समाहित हो जाएं। यह रूट प्रबंधन समूह वैश्विक नीतियों और Azure भूमिका असाइनमेंट को निर्देशिका स्तर पर लागू करने की अनुमति देता है। Azure AD **ग्लोबल एडमिनिस्ट्रेटर को खुद को ऊंचा करना होगा इस रूट समूह के यूजर एक्सेस एडमिनिस्ट्रेटर भूमिका के लिए प्रारंभ में। एक्सेस को ऊंचा करने के बाद, व्यवस्थापक अन्य निर्देशिका उपयोगकर्ताओं या समूहों को पदानुक्रम प्रबंधित करने के लिए किसी भी Azure भूमिका को असाइन कर सकता है। व्यवस्थापक के रूप में, आप अपने खाते को रूट प्रबंधन समूह के मालिक के रूप में असाइन कर सकते हैं।

रूट प्रबंधन समूह नहीं हटाया या स्थानांतरित किया जा सकता, अन्य प्रबंधन समूहों के विपरीत।

प्रबंधन समूह आपको किसी भी प्रकार के सब्सक्रिप्शन के लिए एंटरप्राइज-ग्रेड प्रबंधन प्रदान करते हैं। हालाँकि, एक ही प्रबंधन समूह के भीतर सभी सब्सक्रिप्शन को एक ही Azure Active Directory (Azure AD) टेनेट पर भरोसा करना चाहिए।

Azure Subscriptions

Azure में, एक सब्सक्रिप्शन व्यवसाय या तकनीकी संसाधनों के प्रावधान के लिए एक तार्किक कंटेनर के रूप में कार्य करता है। यह कंटेनर संसाधनों के विवरण को बनाए रखता है जैसे वर्चुअल मशीन (VMs), डेटाबेस, आदि। Azure संसाधन के निर्माण पर, जैसे कि एक VM, इसके साथ संबंधित सब्सक्रिप्शन निर्दिष्ट किया जाता है। यह संरचना एक्सेस के प्रतिनिधित्व को सुविधाजनक बनाती है, भूमिका-आधारित एक्सेस-नियंत्रण तंत्र का उपयोग करते हुए।

Resource Groups

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

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

Administrative Units

From the docs: प्रशासनिक इकाइयाँ आपको अपनी संगठन को किसी भी इकाई में विभाजित करने देती हैं, और फिर विशिष्ट प्रशासकों को असाइन करती हैं जो केवल उस इकाई के सदस्यों का प्रबंधन कर सकते हैं। उदाहरण के लिए, आप प्रशासनिक इकाइयों का उपयोग प्रत्येक स्कूल के प्रशासकों को अनुमतियाँ सौंपने के लिए कर सकते हैं, ताकि वे केवल इंजीनियरिंग स्कूल में एक्सेस को नियंत्रित कर सकें, उपयोगकर्ताओं का प्रबंधन कर सकें, और नीतियाँ निर्धारित कर सकें।

केवल उपयोगकर्ता, समूह और डिवाइस एक प्रशासनिक इकाई के सदस्य हो सकते हैं।

इसलिए, एक प्रशासनिक इकाई कुछ सदस्यों को धारण करेगी और अन्य प्रिंसिपल को उस प्रशासनिक इकाई पर अनुमतियाँ असाइन की जाएंगी जिन्हें वे प्रशासनिक इकाई के सदस्यों का प्रबंधन करने के लिए उपयोग कर सकते हैं।

Azure vs Azure AD vs Azure AD Domain Services

यह ध्यान रखना महत्वपूर्ण है कि Azure AD एक सेवा है Azure के अंदरAzure माइक्रोसॉफ्ट का क्लाउड प्लेटफॉर्म है जबकि Azure AD Azure में एंटरप्राइज पहचान सेवा है। इसके अलावा, Azure AD Windows Active Directory की तरह नहीं है, यह एक पहचान सेवा है जो पूरी तरह से अलग तरीके से काम करती है। यदि आप अपने Windows Active Directory वातावरण के लिए Azure में डोमेन कंट्रोलर चलाना चाहते हैं, तो आपको Azure AD Domain Services का उपयोग करना होगा।

Principals

Azure विभिन्न प्रकार के प्रिंसिपल का समर्थन करता है:

  • User: एक नियमित व्यक्ति जिसके पास एक्सेस के लिए क्रेडेंशियल हैं।

  • Group: एक प्रिंसिपल का समूह जिसे एक साथ प्रबंधित किया जाता है। समूहों को दी गई अनुमतियाँ इसके सदस्यों द्वारा विरासत में ली जाती हैं

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

जब आप एक सेवा प्रिंसिपल बनाते हैं, तो आप पासवर्ड प्रमाणीकरण या प्रमाणपत्र प्रमाणीकरण के बीच चयन कर सकते हैं।

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

  • यदि आप प्रमाणपत्र प्रमाणीकरण चुनते हैं, तो सुनिश्चित करें कि अनुप्रयोग के पास निजी कुंजी पर एक्सेस होगा

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

  • System-assigned। कुछ Azure सेवाएँ आपको एक सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Azure AD में एक पहचान बनाई जाती है। यह पहचान उस सेवा उदाहरण के जीवनचक्र से जुड़ी होती है। जब संसाधन को हटाया जाता है, तो Azure स्वचालित रूप से आपके लिए पहचान को हटा देता है। डिज़ाइन के अनुसार, केवल वही Azure संसाधन इस पहचान का उपयोग करके Azure AD से टोकन का अनुरोध कर सकता है।

  • User-assigned। आप एक प्रबंधित पहचान को एक स्वतंत्र Azure संसाधन के रूप में भी बना सकते हैं। आप एक उपयोगकर्ता-निर्धारित प्रबंधित पहचान बना सकते हैं और इसे एक या अधिक उदाहरणों को असाइन कर सकते हैं (कई संसाधन)। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, पहचान उन संसाधनों से अलग प्रबंधित की जाती है जो इसका उपयोग करते हैं

Roles & Permissions

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

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

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

Classic Roles

Owner

  • सभी संसाधनों पर पूर्ण एक्सेस

  • अन्य उपयोगकर्ताओं के लिए एक्सेस प्रबंधित कर सकते हैं

सभी संसाधन प्रकार

Contributor

  • सभी संसाधनों पर पूर्ण एक्सेस

  • एक्सेस प्रबंधित नहीं कर सकते

सभी संसाधन प्रकार

Reader

• सभी संसाधनों को देखें

सभी संसाधन प्रकार

User Access Administrator

  • सभी संसाधनों को देखें

  • अन्य उपयोगकर्ताओं के लिए एक्सेस प्रबंधित कर सकते हैं

सभी संसाधन प्रकार

Built-In roles

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

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

डिस्क बैकअप करने के लिए बैकअप वॉल्ट को अनुमति प्रदान करता है।

3e5e47e6-65f7-47ef-90b5-e5dd4d455f24

पोर्टल में वर्चुअल मशीनों को देखें और एक नियमित उपयोगकर्ता के रूप में लॉगिन करें।

fb879df8-f326-4884-b1cf-06f3ad86be52

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

Custom Roles

Azure भी कस्टम भूमिकाएँ बनाने की अनुमति देता है जिनमें उपयोगकर्ता को आवश्यक अनुमतियाँ होती हैं।

Permission Denied

  • किसी प्रिंसिपल को किसी संसाधन पर कुछ एक्सेस प्राप्त करने के लिए उसे स्पष्ट रूप से एक भूमिका दी जानी चाहिए (किसी भी तरह से) उसे वह अनुमति देने के लिए

  • एक स्पष्ट अस्वीकृति भूमिका असाइनमेंट उस भूमिका पर प्राथमिकता लेती है जो अनुमति देती है।

Global Administrator

ग्लोबल एडमिनिस्ट्रेटर भूमिका वाले उपयोगकर्ताओं के पास रूट प्रबंधन समूह के लिए यूजर एक्सेस एडमिनिस्ट्रेटर Azure भूमिका को 'ऊंचा' करने की क्षमता होती है। इसका मतलब है कि एक ग्लोबल एडमिनिस्ट्रेटर सभी Azure सब्सक्रिप्शन और प्रबंधन समूहों के लिए एक्सेस प्रबंधित कर सकेगा। यह ऊंचाई पृष्ठ के अंत में की जा सकती है: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Azure Policies

Azure नीतियाँ Microsoft Azure में नियमों और विनियमों का एक सेट हैं, जो एक क्लाउड कंप्यूटिंग सेवा है, जो संगठनात्मक मानकों का प्रबंधन और प्रवर्तन करने में मदद करती हैं और बड़े पैमाने पर अनुपालन का आकलन करती हैं। ये नीतियाँ आपके Azure संसाधनों पर विभिन्न नियमों को लागू करती हैं, यह सुनिश्चित करते हुए कि वे संसाधन कॉर्पोरेट मानकों और सेवा स्तर के समझौतों के साथ अनुपालन में रहें।

Azure नीतियाँ क्लाउड शासन और सुरक्षा के लिए महत्वपूर्ण हैं, यह सुनिश्चित करने में मदद करती हैं कि संसाधनों का सही और प्रभावी ढंग से उपयोग किया जाए, और वे बाहरी विनियमों और आंतरिक नीतियों का पालन करें। कुछ उदाहरण:

  1. विशिष्ट Azure क्षेत्रों के साथ अनुपालन सुनिश्चित करना: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात हों। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसके सभी डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हों।

  2. नामकरण मानकों को लागू करना: नीतियाँ Azure संसाधनों के लिए नामकरण सम्मेलनों को लागू कर सकती हैं। यह संसाधनों को उनके नामों के आधार पर व्यवस्थित करने और आसानी से पहचानने में मदद करता है, जो बड़े वातावरण में सहायक होता है।

  3. कुछ संसाधन प्रकारों को प्रतिबंधित करना: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति सेट की जा सकती है ताकि कुछ महंगे संसाधन प्रकारों, जैसे कि कुछ VM आकारों, के निर्माण को रोकने के लिए लागत को नियंत्रित किया जा सके।

  4. टैगिंग नीतियों को लागू करना: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह सुनिश्चित कर सकती हैं कि सभी संसाधनों के लिए कुछ टैग मौजूद हों, या विशिष्ट मान हों। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणी के लिए उपयोगी है।

  5. संसाधनों के लिए सार्वजनिक एक्सेस को सीमित करना: नीतियाँ यह सुनिश्चित कर सकती हैं कि कुछ संसाधन, जैसे कि स्टोरेज खाते या डेटाबेस, सार्वजनिक एंडपॉइंट न हों, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।

  6. सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करना: नीतियों का उपयोग संसाधनों पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे कि सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।

ध्यान दें कि Azure नीतियाँ Azure पदानुक्रम के किसी भी स्तर पर संलग्न की जा सकती हैं, लेकिन ये आमतौर पर रूट प्रबंधन समूह या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।

Permissions Scope

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

यह पदानुक्रमित संरचना एक्सेस अनुमतियों के प्रभावी और स्केलेबल प्रबंधन की अनुमति देती है।

Azure RBAC vs ABAC

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

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

Default User Permissions

एक बुनियादी उपयोगकर्ता के पास AzureAD के कुछ हिस्सों को सूचीबद्ध करने के लिए कुछ डिफ़ॉल्ट अनुमतियाँ होंगी:

  • सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सब्सक्रिप्शन, और उनके सार्वजनिक गुणों को पढ़ें

  • मेहमानों को आमंत्रित करें (बंद किया जा सकता है)

  • सुरक्षा समूह बनाएं

  • गैर-छिपे हुए समूह की सदस्यताओं को पढ़ें

  • स्वामित्व वाले समूहों में मेहमान जोड़ें

  • नया अनुप्रयोग बनाएं (बंद किया जा सकता है)

  • Azure में 50 उपकरणों तक जोड़ें (बंद किया जा सकता है)

आप पूर्ण उपयोगकर्ताओं के डिफ़ॉल्ट अनुमतियों की सूची में देख सकते हैं। इसके अलावा, ध्यान दें कि उस सूची में आप मेहमानों के डिफ़ॉल्ट अनुमतियों की सूची भी देख सकते हैं।

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

Privileged Identity Management (PIM)

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

Authentication Tokens

OIDC में उपयोग किए जाने वाले तीन प्रकार के टोकन हैं:

  • Access Tokens: क्लाइंट इस टोकन को संसाधन सर्वर को संसाधनों तक पहुँचने के लिए प्रस्तुत करता है। इसका उपयोग केवल उपयोगकर्ता, क्लाइंट, और संसाधन के एक विशिष्ट संयोजन के लिए किया जा सकता है और समाप्ति तक रद्द नहीं किया जा सकता - जो डिफ़ॉल्ट रूप से 1 घंटा है। इसका पता लगाना कम है।

  • ID Tokens: क्लाइंट इस टोकन को प्राधिकरण सर्वर से प्राप्त करता है। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह उपयोगकर्ता और क्लाइंट के एक विशिष्ट संयोजन से बंद होता है।

  • Refresh Tokens: क्लाइंट को एक्सेस टोकन के साथ प्रदान किया जाता है। इसका उपयोग नए एक्सेस और ID टोकन प्राप्त करने के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के एक विशिष्ट संयोजन से बंद होता है और रद्द किया जा सकता है। डिफ़ॉल्ट समाप्ति 90 दिन है निष्क्रिय रिफ्रेश टोकन के लिए और सक्रिय टोकन के लिए कोई समाप्ति नहीं

शर्तीय एक्सेस के लिए जानकारी JWT के अंदर संग्रहित होती है। इसलिए, यदि आप अनुमत IP पते से टोकन का अनुरोध करते हैं, तो वह IP टोकन में संग्रहित होगा और फिर आप उस टोकन का उपयोग गैर-अनुमत IP से संसाधनों तक पहुँचने के लिए कर सकते हैं।

अगली पृष्ठ पर विभिन्न तरीकों से एक्सेस टोकन अनुरोध करने और उनके साथ लॉगिन करने के लिए सीखें:

Az - AzureAD (AAD)

सबसे सामान्य API एंडपॉइंट हैं:

  • Azure Resource Manager (ARM): management.azure.com

  • Microsoft Graph: graph.microsoft.com (Azure AD Graph जो कि अप्रचलित है वह graph.windows.net है)

References

Support HackTricks

Last updated