Az - Basic Information
Organization Hierarchy
Management Groups
यदि आपके संगठन में कई Azure subscriptions हैं, तो आपको उन subscriptions के लिए प्रवेश, नीतियों और अनुपालन को कुशलतापूर्वक प्रबंधित करने का तरीका चाहिए। Management groups subscriptions के ऊपर एक governance scope प्रदान करते हैं।
ध्यान दें कि एक ही डायरेक्टरी में 10,000 management groups को सपोर्ट किया जा सकता है और एक management group tree छह स्तरों की गहराई तक सपोर्ट कर सकता है।
From the docs: प्रत्येक डायरेक्टरी को एक शीर्ष-स्तरीय management group जिसे root management group कहा जाता है दिया जाता है। root management group को hierarchy में बनाया गया है ताकि सभी management groups और subscriptions इसमें शामिल हो सकें। यह root management group global policies और Azure role assignments को डायरेक्टरी स्तर पर लागू करने की अनुमति देता है। Azure AD Global Administrator को खुद को User Access Administrator role of this root group में elevate करना होगा। एक्सेस को elevate करने के बाद, एडमिनिस्ट्रेटर hierarchy को प्रबंधित करने के लिए किसी भी Azure role को अन्य डायरेक्टरी उपयोगकर्ताओं या समूहों को असाइन कर सकता है। एडमिनिस्ट्रेटर के रूप में, आप root management group के मालिक के रूप में अपने खाते को असाइन कर सकते हैं।
root management group को अन्य management groups के विपरीत स्थानांतरित या हटाया नहीं जा सकता।
Management groups आपको किसी भी प्रकार के subscriptions के बावजूद बड़े पैमाने पर एंटरप्राइज़-ग्रेड प्रबंधन प्रदान करते हैं। हालांकि, एक ही management group के भीतर सभी subscriptions को एक ही Azure Active Directory (Azure AD) tenant पर भरोसा करना चाहिए।
Azure Subscriptions
Azure में, एक subscription एक तार्किक कंटेनर के रूप में कार्य करता है जिसका उद्देश्य व्यवसाय या तकनीकी संसाधनों का प्रावधान करना है। यह कंटेनर संसाधनों के विवरण को बनाए रखता है जैसे कि वर्चुअल मशीन (VMs), डेटाबेस, आदि। जब एक Azure संसाधन, जैसे कि एक VM, बनाया जाता है, तो उसके साथ जुड़ी subscription निर्दिष्ट की जाती है। यह संरचना एक्सेस को सौंपने की सुविधा प्रदान करती है, जिसमें role-based access-control तंत्र का उपयोग किया जाता है।
Resource Groups
From the docs: एक resource group एक कंटेनर है जो एक Azure समाधान के लिए संबंधित संसाधनों को रखता है। resource group समाधान के लिए सभी संसाधनों को शामिल कर सकता है, या केवल उन संसाधनों को जिन्हें आप एक समूह के रूप में प्रबंधित करना चाहते हैं। सामान्यतः, उन संसाधनों को जोड़ें जो एक ही जीवनचक्र साझा करते हैं ताकि आप उन्हें आसानी से एक समूह के रूप में तैनात, अपडेट और हटा सकें।
सभी संसाधनों को एक resource group के अंदर होना चाहिए और वे केवल एक समूह से संबंधित हो सकते हैं और यदि एक resource group हटा दिया जाता है, तो उसके अंदर के सभी संसाधन भी हटा दिए जाते हैं।
Administrative Units
From the docs: Administrative units आपको अपने संगठन को किसी भी इकाई में विभाजित करने देती हैं, और फिर विशिष्ट प्रशासकों को असाइन करती हैं जो केवल उस इकाई के सदस्यों को प्रबंधित कर सकते हैं। उदाहरण के लिए, आप एक बड़े विश्वविद्यालय में प्रत्येक स्कूल के प्रशासकों को अनुमतियाँ सौंपने के लिए administrative units का उपयोग कर सकते हैं, ताकि वे केवल इंजीनियरिंग स्कूल में एक्सेस को नियंत्रित कर सकें, उपयोगकर्ताओं को प्रबंधित कर सकें, और नीतियाँ सेट कर सकें।
केवल उपयोगकर्ता, समूह और डिवाइस एक administrative unit के सदस्य हो सकते हैं।
इसलिए, एक Administrative unit में कुछ सदस्य होंगे और अन्य प्रमुखों को उस administrative unit पर अनुमतियाँ असाइन की जाएंगी जिन्हें वे administrative unit के सदस्यों को प्रबंधित करने के लिए उपयोग कर सकते हैं।
Azure vs Azure AD vs Azure AD Domain Services
यह ध्यान रखना महत्वपूर्ण है कि Azure AD एक सेवा है जो Azure के अंदर है। Azure Microsoft का क्लाउड प्लेटफ़ॉर्म है जबकि Azure AD Azure में एंटरप्राइज़ पहचान सेवा है। इसके अलावा, Azure AD Windows Active Directory जैसा नहीं है, यह एक पहचान सेवा है जो पूरी तरह से अलग तरीके से काम करती है। यदि आप अपने Windows Active Directory वातावरण के लिए Azure में एक Domain Controller चलाना चाहते हैं तो आपको Azure AD Domain Services का उपयोग करना होगा।
Principals
Azure विभिन्न प्रकार के principals का समर्थन करता है:
User: एक नियमित व्यक्ति जिसके पास एक्सेस के लिए क्रेडेंशियल्स होते हैं।
Group: एक प्रमुखों का समूह जिसे एक साथ प्रबंधित किया जाता है। अनुमतियाँ जो समूहों को दी जाती हैं वे उसके सदस्यों द्वारा विरासत में मिलती हैं।
Service Principal/Enterprise Applications: यह एक पहचान है जो एप्लिकेशन, होस्टेड सेवाओं, और स्वचालित उपकरणों के साथ Azure संसाधनों तक पहुंचने के लिए उपयोग के लिए बनाई जाती है। यह एक्सेस सेवा प्रमुख को असाइन किए गए भूमिकाओं द्वारा प्रतिबंधित है, जिससे आपको किस संसाधनों तक पहुंचा जा सकता है और किस स्तर पर नियंत्रण मिलता है। सुरक्षा कारणों से, यह हमेशा अनुशंसित है कि स्वचालित उपकरणों के साथ सेवा प्रमुखों का उपयोग करें बजाय इसके कि उन्हें उपयोगकर्ता पहचान के साथ लॉग इन करने की अनुमति दें।
जब एक service principal बनाते हैं तो आप पासवर्ड प्रमाणीकरण या प्रमाणपत्र प्रमाणीकरण के बीच चुन सकते हैं।
यदि आप पासवर्ड प्रमाणीकरण चुनते हैं (डिफ़ॉल्ट रूप से), उत्पन्न पासवर्ड को सहेजें क्योंकि आप इसे फिर से एक्सेस नहीं कर पाएंगे।
यदि आप प्रमाणपत्र प्रमाणीकरण चुनते हैं, तो सुनिश्चित करें कि एप्लिकेशन के पास निजी कुंजी पर एक्सेस होगा।
Managed Identity (Metadata Creds): Azure Active Directory में प्रबंधित पहचानें स्वचालित रूप से पहचान प्रबंधन के लिए एक समाधान प्रदान करती हैं। ये पहचानें एप्लिकेशन द्वारा Azure Active Directory (Azure AD) प्रमाणीकरण के साथ संगत संसाधनों से कनेक्ट करने के लिए उपयोग की जाती हैं। प्रबंधित पहचानें का उपयोग करके, एप्लिकेशन Azure AD टोकन को सुरक्षित कर सकते हैं जबकि सीधे क्रेडेंशियल्स को संभालने की आवश्यकता को समाप्त कर सकते हैं। प्रबंधित पहचानें दो प्रकार की होती हैं:
System-assigned. कुछ Azure सेवाएं आपको सीधे सेवा उदाहरण पर एक प्रबंधित पहचान सक्षम करने की अनुमति देती हैं। जब आप एक system-assigned प्रबंधित पहचान सक्षम करते हैं, तो Azure AD में एक पहचान बनाई जाती है। यह पहचान उस सेवा उदाहरण के जीवनचक्र से जुड़ी होती है। जब संसाधन हटा दिया जाता है, तो Azure स्वचालित रूप से आपके लिए पहचान को हटा देता है। डिज़ाइन द्वारा, केवल वह Azure संसाधन इस पहचान का उपयोग Azure AD से टोकन का अनुरोध करने के लिए कर सकता है।
User-assigned. आप एक प्रबंधित पहचान को एक स्टैंडअलोन Azure संसाधन के रूप में भी बना सकते हैं। आप एक user-assigned प्रबंधित पहचान बना सकते हैं और इसे एक या अधिक Azure सेवा उदाहरणों (कई संसाधनों) को असाइन कर सकते हैं। user-assigned प्रबंधित पहचान के लिए, पहचान उन संसाधनों से अलग से प्रबंधित की जाती है जो इसका उपयोग करते हैं।
Roles & Permissions
Roles को principals पर एक scope पर असाइन किया जाता है: principal -[HAS ROLE]->(scope)
Roles जो समूहों को असाइन की जाती हैं वे समूह के सभी सदस्यों द्वारा विरासत में मिलती हैं।
जिस scope पर role असाइन किया गया था, उसके आधार पर, role को अन्य संसाधनों में विरासत में मिल सकता है जो scope कंटेनर के अंदर हैं। उदाहरण के लिए, यदि एक उपयोगकर्ता A के पास subscription पर एक role है, तो उसके पास subscription के अंदर सभी resource groups पर वह role होगा और resource group के अंदर सभी संसाधनों पर भी।
Classic Roles
Owner |
| सभी संसाधन प्रकार |
Contributor |
| सभी संसाधन प्रकार |
Reader | • सभी संसाधनों को देखें | सभी संसाधन प्रकार |
User Access Administrator |
| सभी संसाधन प्रकार |
Built-In roles
From the docs: Azure role-based access control (Azure RBAC) में कई Azure built-in roles हैं जिन्हें आप उपयोगकर्ताओं, समूहों, सेवा प्रमुखों और प्रबंधित पहचानें को असाइन कर सकते हैं। Role assignments वह तरीका है जिससे आप Azure संसाधनों तक पहुंच को नियंत्रित करते हैं। यदि built-in roles आपके संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करते हैं, तो आप अपने स्वयं के Azure custom roles** बना सकते हैं।**
Built-In roles केवल उन संसाधनों पर लागू होते हैं जिनके लिए वे बनाए गए हैं, उदाहरण के लिए Compute संसाधनों पर Built-In roles के 2 उदाहरण देखें:
बैकअप वॉल्ट को डिस्क बैकअप करने की अनुमति प्रदान करता है। | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
पोर्टल में वर्चुअल मशीनों को देखें और एक नियमित उपयोगकर्ता के रूप में लॉगिन करें। | fb879df8-f326-4884-b1cf-06f3ad86be52 |
ये roles लॉजिक कंटेनरों (जैसे management groups, subscriptions और resource groups) पर भी असाइन किए जा सकते हैं और प्रभावित प्रमुखों के पास उन कंटेनरों के अंदर संसाधनों पर ये roles होंगे।
यहाँ सभी Azure built-in roles की सूची देखें।
यहाँ सभी Azure AD built-in roles की सूची देखें।
Custom Roles
Azure उपयोगकर्ता की आवश्यकताओं के साथ custom roles बनाने की अनुमति भी देता है।
Permission Denied
एक principal को किसी संसाधन पर कुछ एक्सेस प्राप्त करने के लिए उसे किसी भी तरह से उस अनुमति को प्रदान करने वाली एक स्पष्ट भूमिका की आवश्यकता होती है।
एक स्पष्ट deny role assignment उस भूमिका पर प्राथमिकता लेता है जो अनुमति प्रदान कर रही है।
Global Administrator
Global Administrator भूमिका वाले उपयोगकर्ताओं के पास 'root management group के लिए User Access Administrator Azure role में elevate करने की क्षमता होती है। इसका मतलब है कि एक Global Administrator सभी Azure subscriptions और management groups का एक्सेस प्रबंधित करने में सक्षम होगा। यह elevation पृष्ठ के अंत में किया जा सकता है: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure Policies
Azure policies Microsoft Azure में नियमों और विनियमों का एक सेट हैं, जो एक क्लाउड कंप्यूटिंग सेवा है, जो संगठनात्मक मानकों को प्रबंधित करने और बड़े पैमाने पर अनुपालन का आकलन करने में मदद करती है। ये नीतियाँ आपके Azure संसाधनों पर विभिन्न नियमों को लागू करती हैं, यह सुनिश्चित करते हुए कि वे कॉर्पोरेट मानकों और सेवा स्तर समझौतों के अनुरूप बने रहें।
Azure policies क्लाउड गवर्नेंस और सुरक्षा के लिए महत्वपूर्ण हैं, यह सुनिश्चित करने में मदद करती हैं कि संसाधनों का सही और कुशलता से उपयोग किया जा रहा है, और वे बाहरी विनियमों और आंतरिक नीतियों के अनुरूप हैं। कुछ उदाहरण:
विशिष्ट Azure क्षेत्रों के साथ अनुपालन सुनिश्चित करना: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात किए गए हैं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसका सारा डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हो।
नामकरण मानकों को लागू करना: नीतियाँ Azure संसाधनों के लिए नामकरण सम्मेलनों को लागू कर सकती हैं। यह संसाधनों को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है, जो बड़े वातावरण में सहायक होता है।
कुछ संसाधन प्रकारों को प्रतिबंधित करना: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति सेट की जा सकती है ताकि महंगे संसाधन प्रकारों, जैसे कि कुछ VM आकारों, के निर्माण को रोका जा सके, ताकि लागत को नियंत्रित किया जा सके।
टैगिंग नीतियों को लागू करना: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह सुनिश्चित कर सकती हैं कि कुछ टैग मौजूद हों, या सभी संसाधनों के लिए विशिष्ट मान हों। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों के वर्गीकरण के लिए उपयोगी है।
सार्वजनिक एक्सेस को सीमित करना: नीतियाँ यह सुनिश्चित कर सकती हैं कि कुछ संसाधनों, जैसे कि स्टोरेज अकाउंट्स या डेटाबेस, के पास सार्वजनिक एंडपॉइंट्स न हों, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
स्वचालित रूप से सुरक्षा सेटिंग्स लागू करना: नीतियाँ संसाधनों पर
Last updated
