Azure Fundamentals · पाठ

उपयोगकर्ता, समूह और भूमिका असाइनमेंट

Entra ID में उपयोगकर्ता और समूह बनाएँ, Azure संसाधनों तक पहुँच नियंत्रित करने के लिए अंतर्निहित RBAC भूमिकाएँ असाइन करें और न्यूनतम विशेषाधिकार का सिद्धांत लागू करें।

पाठ 2, कुल 4 में से13 चरण

उपयोगकर्ता, समूह और भूमिका असाइनमेंट, CoddyKit पर Azure Fundamentals का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Azure Fundamentals सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

Azure RBAC: भूमिका-आधारित पहुँच नियंत्रण

Azure Role-Based Access Control (RBAC) वह प्राधिकरण प्रणाली है जो नियंत्रित करती है कि Azure resources पर कौन क्या कर सकता है। अनुमतियाँ सीधे व्यक्तियों को देने के बजाय, आप किसी विशिष्ट scope पर security principals (उपयोगकर्ता, समूह, service principals या managed identities) को roles देते हैं। यह अलगाव आपके संगठन के बढ़ने पर अनुमतियों को प्रबंधित करने योग्य बनाए रखता है।

RBAC की तीन अवधारणाएँ

हर RBAC assignment में तीन घटक होते हैं। security principal वह होता है जिसे पहुँच मिलती है (उपयोगकर्ता, समूह या managed identity)। role definition बताती है कि कौन-सी actions अनुमत हैं (जैसे VMs पढ़ना या storage में लिखना)। scope बताता है कि पहुँच कहाँ लागू होती है — सबसे व्यापक से सबसे सीमित क्रम में: management group, subscription, resource group या individual resource। scope hierarchy में पहुँच नीचे की ओर विरासत में मिलती है।

# View all role assignments in a subscription
az role assignment list \
  --output table

# Check your own permissions on a resource
az role assignment list \
  --assignee <your-user-principal-name> \
  --output table

Built-In Roles का अवलोकन

Azure सैकड़ों built-in roles प्रदान करता है। सभी resource types में सबसे अधिक उपयोग की जाने वाली चार भूमिकाएँ हैं: Owner — अन्य लोगों को roles देने की क्षमता सहित पूर्ण पहुँच; Contributor — resources बनाने और प्रबंधित करने की पूर्ण पहुँच, लेकिन दूसरों को पहुँच देने की अनुमति नहीं; Reader — केवल देखने की पहुँच; और User Access Administrator — स्वयं resources में योगदान किए बिना role assignments प्रबंधित करने की क्षमता।

# List all built-in roles
az role definition list \
  --custom-role-only false \
  --query '[].{Name:roleName, Id:name}' \
  --output table | head -20

भूमिका देना

role assignment निर्दिष्ट security principal को निर्दिष्ट scope पर role definition में दी गई अनुमतियाँ प्रदान करता है। role assignments सभी child scopes तक पहुँचते हैं — resource group स्तर पर Contributor देने से उस समूह के प्रत्येक resource पर Contributor पहुँच मिलती है। subscription स्तर पर देने से उस subscription के सभी resource groups में Contributor पहुँच मिलती है।

# Assign Contributor role to a user at resource group scope
az role assignment create \
  --assignee alice@yourcompany.com \
  --role Contributor \
  --resource-group myRG

# Assign Reader role to a group at subscription scope
az role assignment create \
  --assignee-object-id <group-object-id> \
  --role Reader \
  --scope /subscriptions/<subscription-id>

न्यूनतम विशेषाधिकार का सिद्धांत

न्यूनतम विशेषाधिकार का सिद्धांत कहता है कि प्रत्येक पहचान के पास अपना कार्य करने के लिए आवश्यक न्यूनतम अनुमतियाँ ही होनी चाहिए। Azure RBAC में इसका अर्थ है: जहाँ लिखने की आवश्यकता नहीं हो वहाँ Contributor के बजाय Reader को प्राथमिकता दें, subscription scope के बजाय resource-group scope चुनें, और जहाँ संभव हो वहाँ व्यापक Contributor role के बजाय विशिष्ट resource-level roles (जैसे Storage Blob Data Contributor) का उपयोग करें।

कस्टम Role Definitions

जब कोई built-in role आपकी requirements से पूरी तरह मेल नहीं खाता, तब आप custom role बना सकते हैं। custom role definition में Actions (अनुमत control-plane operations), NotActions (अनुमत समूह से बाहर रखी गई actions), DataActions (resources पर data-plane operations, जैसे blob content पढ़ना) और AssignableScopes (वे subscriptions या management groups जहाँ role दिया जा सकता है) का समूह निर्दिष्ट होता है।

{
  'Name': 'VM Operator',
  'Description': 'Can start, stop, and restart VMs but not delete or reconfigure them',
  'Actions': [
    'Microsoft.Compute/virtualMachines/start/action',
    'Microsoft.Compute/virtualMachines/restart/action',
    'Microsoft.Compute/virtualMachines/deallocate/action',
    'Microsoft.Compute/virtualMachines/read'
  ],
  'NotActions': [],
  'AssignableScopes': ['/subscriptions/<subscription-id>']
}

भूमिका देने का विस्तार करने के लिए समूह

व्यक्तिगत उपयोगकर्ताओं के बजाय groups को roles देना एक सर्वोत्तम अभ्यास है। जब कोई नया developer DevTeam में शामिल होता है, तो आप उसे Entra ID के DevTeam security group में जोड़ते हैं — वह समूह को मिली सभी role assignments अपने-आप प्राप्त कर लेता है और किसी Azure RBAC बदलाव की आवश्यकता नहीं होती। यह एकल प्रबंधन बिंदु बिखरे हुए व्यक्तिगत assignments को रोकता है, जिन्हें कर्मचारी के संगठन छोड़ने पर audit करना या रद्द करना कठिन हो जाता है।

# Create a group and assign a role to it
az ad group create \
  --display-name 'DevTeam' \
  --mail-nickname DevTeam

# Assign role to the group
az role assignment create \
  --assignee-object-id <group-object-id> \
  --role Contributor \
  --resource-group dev-rg

स्वचालन के लिए Service Principals

service principal applications, scripts और automation tools द्वारा Azure में प्रमाणीकरण करने और resources तक पहुँचने के लिए उपयोग की जाने वाली पहचान है। उपयोगकर्ता की पहचान के विपरीत, service principals में इंटरैक्टिव sign-in की क्षमता नहीं होती। आप उन्हें Entra ID में App Registrations से बनाते हैं और फिर उपयुक्त scope पर RBAC roles देते हैं — उदाहरण के लिए, infrastructure deploy करने के लिए किसी CI/CD pipeline को एक ही resource group पर Contributor पहुँच देना।

# Create a service principal and assign Contributor to a resource group
az ad sp create-for-rbac \
  --name myCICDprincipal \
  --role Contributor \
  --scopes /subscriptions/<sub-id>/resourceGroups/myRG

Deny Assignments

Deny assignments security principals के लिए विशिष्ट actions को रोकते हैं, भले ही कोई role assignment सामान्यतः उन actions की अनुमति देता हो। role assignments के विपरीत, deny assignments सीधे administrators द्वारा नहीं बनाए जा सकते — उपयोगकर्ताओं को protected resources में बदलाव करने से रोकने के लिए Azure Blueprints या managed applications इन्हें जोड़ते हैं। deny assignment किसी भी मेल खाती role assignment पर प्राथमिकता रखता है।

# List deny assignments in a resource group
az role assignment list \
  --include-deny-assignments \
  --resource-group myRG \
  --query '[?type==`Microsoft.Authorization/denyAssignments`]'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) Entra ID P2 की ऐसी सुविधा है जो just-in-time privileged access प्रदान करती है। Owner या Global Administrator role को स्थायी रूप से देने के बजाय, आप उपयोगकर्ताओं को उस role के लिए eligible बनाते हैं। आवश्यकता पड़ने पर वे सीमित समयावधि (जैसे 1–8 घंटे) के लिए assignment सक्रिय करते हैं; इसमें वैकल्पिक रूप से approval workflow और औचित्य आवश्यक किया जा सकता है। इससे अत्यधिक अधिकार वाले खातों से उत्पन्न स्थायी attack surface बहुत कम हो जाता है।

निरंतर शासन के लिए Access Reviews

Access Reviews (Entra ID P2) समय-समय पर होने वाली स्वचालित reviews हैं, जिनमें resource owners या managers से पूछा जाता है कि क्या उनकी टीम के सदस्यों को अभी भी वर्तमान role assignments की आवश्यकता है। reviewers review interface से सीधे निरंतर पहुँच को स्वीकृत या अस्वीकृत कर सकते हैं। इससे role changes, projects के पूरा होने या कर्मचारियों के जाने के बाद बची हुई पुरानी अनुमतियों का पता चलता है — regulatory compliance programmes के लिए यह एक महत्वपूर्ण requirement है।

त्वरित जाँच

इस पाठ में Microsoft Azure Fundamentals (AZ-900) की अवधारणाओं के बारे में अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पाठ का पुनरावलोकन

इस पाठ में आपने सीखा: Azure RBAC किसी विशिष्ट scope पर security principals को roles देता है, न्यूनतम विशेषाधिकार के सिद्धांत का अर्थ केवल आवश्यक न्यूनतम अनुमतियाँ देना है, और PIM स्थायी assignment के बजाय उच्च-विशेषाधिकार वाली roles के लिए just-in-time activation प्रदान करता है। अब हम Entra ID में Multi-Factor Authentication और Conditional Access का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Azure Fundamentals सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 30
पाठ: 120

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “उपयोगकर्ता, समूह और भूमिका असाइनमेंट” पाठ निःशुल्क है?

हाँ—“उपयोगकर्ता, समूह और भूमिका असाइनमेंट” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Azure Fundamentals पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“उपयोगकर्ता, समूह और भूमिका असाइनमेंट” में मैं क्या सीखूँगा?

Entra ID में उपयोगकर्ता और समूह बनाएँ, Azure संसाधनों तक पहुँच नियंत्रित करने के लिए अंतर्निहित RBAC भूमिकाएँ असाइन करें और न्यूनतम विशेषाधिकार का सिद्धांत लागू करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Azure Fundamentals का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Azure Fundamentals शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Azure Fundamentals शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।

“उपयोगकर्ता, समूह और भूमिका असाइनमेंट” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Azure Fundamentals पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Azure Fundamentals पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← Azure Fundamentals पर वापस जाएँ