mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-07 10:50:33 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -1,58 +1,58 @@
|
||||
# AWS - Basic Information
|
||||
# AWS - मूल जानकारी
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Organization Hierarchy
|
||||
## संगठन पदानुक्रम
|
||||
|
||||
.png>)
|
||||
|
||||
### Accounts
|
||||
### खाते
|
||||
|
||||
AWS में एक **root account** है, जो आपके **organization** के लिए सभी खातों का **parent container** है। हालांकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप **अलग-अलग AWS** बुनियादी ढांचे को अलग करने के लिए **अन्य खाते बना सकते हैं**।
|
||||
AWS में एक **रूट खाता** होता है, जो आपके **संगठन** के सभी खातों के लिए **माता-पिता कंटेनर** है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप **विभिन्न AWS** अवसंरचनाओं को अलग करने के लिए **अन्य खाते बना सकते हैं**।
|
||||
|
||||
यह **security** के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि **एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा** (जब तक कि पुल विशेष रूप से बनाए नहीं गए हैं), इसलिए इस तरह आप तैनाती के बीच सीमाएँ बना सकते हैं।
|
||||
यह **सुरक्षा** के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि **एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा** (जब तक कि पुल विशेष रूप से बनाए नहीं गए हों), इसलिए इस तरह आप तैनातियों के बीच सीमाएँ बना सकते हैं।
|
||||
|
||||
इसलिए, एक संगठन में **दो प्रकार के खाते** होते हैं (हम AWS खातों की बात कर रहे हैं और उपयोगकर्ता खातों की नहीं): एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।
|
||||
इसलिए, एक संगठन में **दो प्रकार के खाते** होते हैं (हम AWS खातों की बात कर रहे हैं, उपयोगकर्ता खातों की नहीं): एक एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।
|
||||
|
||||
- **प्रबंधन खाता (root account)** वह खाता है जिसका उपयोग आप संगठन बनाने के लिए करते हैं। संगठन के प्रबंधन खाते से, आप निम्नलिखित कर सकते हैं:
|
||||
- **प्रबंधन खाता (रूट खाता)** वह खाता है जिसका उपयोग आप संगठन बनाने के लिए करते हैं। संगठन के प्रबंधन खाते से, आप निम्नलिखित कर सकते हैं:
|
||||
|
||||
- संगठन में खाते बनाएं
|
||||
- संगठन में अन्य मौजूदा खातों को आमंत्रित करें
|
||||
- संगठन से खातों को हटाएं
|
||||
- आमंत्रण प्रबंधित करें
|
||||
- संगठन के भीतर संस्थाओं (roots, OUs, या खातों) पर नीतियाँ लागू करें
|
||||
- संगठन में सभी खातों के बीच सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करें।
|
||||
- आप इस root account/organization को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके root उपयोगकर्ता के रूप में लॉगिन करना संभव है।
|
||||
- संगठन में खाते बनाना
|
||||
- संगठन में अन्य मौजूदा खातों को आमंत्रित करना
|
||||
- संगठन से खातों को हटाना
|
||||
- आमंत्रण प्रबंधित करना
|
||||
- संगठन के भीतर संस्थाओं (रूट, OU, या खाते) पर नीतियाँ लागू करना
|
||||
- संगठन में सभी खातों के बीच सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करना।
|
||||
- आप इस रूट खाते/संगठन को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके रूट उपयोगकर्ता के रूप में लॉगिन कर सकते हैं।
|
||||
|
||||
प्रबंधन खाते के पास **payer account** की जिम्मेदारियाँ होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप एक संगठन के प्रबंधन खाते को बदल नहीं सकते।
|
||||
प्रबंधन खाते की **भुगतानकर्ता खाते की जिम्मेदारियाँ** होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप संगठन के प्रबंधन खाते को बदल नहीं सकते।
|
||||
|
||||
- **सदस्य खाते** संगठन में बाकी सभी खातों का निर्माण करते हैं। एक खाता एक समय में केवल एक संगठन का सदस्य हो सकता है। आप एक खाते पर नियंत्रण लागू करने के लिए एक नीति संलग्न कर सकते हैं केवल उसी एक खाते पर।
|
||||
- सदस्य खातों को **एक मान्य ईमेल पता** का उपयोग करना चाहिए और एक **नाम** हो सकता है, सामान्यतः वे बिलिंग का प्रबंधन नहीं कर पाएंगे (लेकिन उन्हें इसके लिए पहुँच दी जा सकती है)।
|
||||
```
|
||||
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
|
||||
```
|
||||
### **Organization Units**
|
||||
### **संगठन इकाइयाँ**
|
||||
|
||||
खातों को **Organization Units (OU)** में समूहित किया जा सकता है। इस तरह, आप उस Organization Unit के लिए **policies** बना सकते हैं जो **सभी बच्चों के खातों पर लागू होंगी**। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।
|
||||
खातों को **संगठन इकाइयों (OU)** में समूहित किया जा सकता है। इस तरह, आप संगठन इकाई के लिए **नीतियाँ** बना सकते हैं जो **सभी बच्चों के खातों पर लागू होंगी**। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।
|
||||
```bash
|
||||
# You can get the root id from aws organizations list-roots
|
||||
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### Service Control Policy (SCP)
|
||||
### सेवा नियंत्रण नीति (SCP)
|
||||
|
||||
एक **सेवा नियंत्रण नीति (SCP)** एक नीति है जो उन सेवाओं और क्रियाओं को निर्दिष्ट करती है जिन्हें उपयोगकर्ता और भूमिकाएँ उन खातों में उपयोग कर सकते हैं जिन पर SCP प्रभाव डालता है। SCPs **IAM** अनुमतियों की नीतियों के समान हैं, सिवाय इसके कि वे **कोई अनुमतियाँ नहीं देतीं**। इसके बजाय, SCPs एक संगठन, संगठनात्मक इकाई (OU), या खाते के लिए **अधिकतम अनुमतियों** को निर्दिष्ट करती हैं। जब आप अपने संगठन की जड़ या एक OU पर SCP संलग्न करते हैं, तो **SCP सदस्य खातों में संस्थाओं के लिए अनुमतियों को सीमित करता है**।
|
||||
एक **सेवा नियंत्रण नीति (SCP)** एक नीति है जो उन सेवाओं और क्रियाओं को निर्दिष्ट करती है जिन्हें उपयोगकर्ता और भूमिकाएँ उन खातों में उपयोग कर सकते हैं जिन पर SCP प्रभाव डालती है। SCPs **IAM** अनुमतियों की नीतियों के समान हैं, सिवाय इसके कि वे **कोई अनुमतियाँ नहीं देतीं**। इसके बजाय, SCPs एक संगठन, संगठनात्मक इकाई (OU), या खाते के लिए **अधिकतम अनुमतियों** को निर्दिष्ट करती हैं। जब आप अपने संगठन की जड़ या एक OU पर SCP संलग्न करते हैं, तो **SCP सदस्य खातों में संस्थाओं के लिए अनुमतियों को सीमित करती है**।
|
||||
|
||||
यह **एकमात्र तरीका है कि** **यहाँ तक कि रूट उपयोगकर्ता को भी कुछ करने से रोका जा सकता है**। उदाहरण के लिए, इसका उपयोग उपयोगकर्ताओं को CloudTrail को निष्क्रिय करने या बैकअप हटाने से रोकने के लिए किया जा सकता है।\
|
||||
यह एकमात्र तरीका है कि **यहां तक कि रूट उपयोगकर्ता को कुछ करने से रोका जा सकता है**। उदाहरण के लिए, इसका उपयोग उपयोगकर्ताओं को CloudTrail को निष्क्रिय करने या बैकअप हटाने से रोकने के लिए किया जा सकता है।\
|
||||
इससे बचने का एकमात्र तरीका यह है कि **मास्टर खाता** भी समझौता किया जाए जो SCPs को कॉन्फ़िगर करता है (मास्टर खाता को अवरुद्ध नहीं किया जा सकता)।
|
||||
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि **SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं**, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि एक SCP `s3:GetObject` को अस्वीकार करने से लोगों को आपके खाते में **एक सार्वजनिक S3 बकेट** तक पहुँचने से नहीं रोका जाएगा।
|
||||
> ध्यान दें कि **SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं**, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि SCP द्वारा `s3:GetObject` को अस्वीकार करने से लोगों को आपके खाते में **एक सार्वजनिक S3 बकेट** तक पहुँचने से नहीं रोका जाएगा।
|
||||
|
||||
SCP उदाहरण:
|
||||
|
||||
- रूट खाते को पूरी तरह से अस्वीकार करें
|
||||
- केवल विशिष्ट क्षेत्रों की अनुमति दें
|
||||
- केवल श्वेतसूचीबद्ध सेवाओं की अनुमति दें
|
||||
- केवल श्वेत-पत्रित सेवाओं की अनुमति दें
|
||||
- GuardDuty, CloudTrail, और S3 सार्वजनिक ब्लॉक एक्सेस को निष्क्रिय करने से रोकें
|
||||
|
||||
- सुरक्षा/घटना प्रतिक्रिया भूमिकाओं को हटाने या
|
||||
@@ -66,43 +66,43 @@ SCP उदाहरण:
|
||||
|
||||
### ARN
|
||||
|
||||
**Amazon Resource Name** वह **विशिष्ट नाम** है जो AWS के अंदर हर संसाधन का होता है, यह इस तरह से बना होता है:
|
||||
**Amazon Resource Name** AWS के अंदर हर संसाधन का **विशिष्ट नाम** है, यह इस प्रकार से बना है:
|
||||
```
|
||||
arn:partition:service:region:account-id:resource-type/resource-id
|
||||
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
```
|
||||
Note that there are 4 partitions in AWS but only 3 ways to call them:
|
||||
ध्यान दें कि AWS में 4 विभाजन हैं लेकिन उन्हें कॉल करने के केवल 3 तरीके हैं:
|
||||
|
||||
- AWS Standard: `aws`
|
||||
- AWS China: `aws-cn`
|
||||
- AWS US public Internet (GovCloud): `aws-us-gov`
|
||||
- AWS Secret (US Classified): `aws`
|
||||
|
||||
## IAM - पहचान और पहुँच प्रबंधन
|
||||
## IAM - पहचान और पहुंच प्रबंधन
|
||||
|
||||
IAM वह सेवा है जो आपको अपने AWS खाते के भीतर **प्रमाणीकरण**, **अधिकार** और **पहुँच नियंत्रण** प्रबंधित करने की अनुमति देती है।
|
||||
IAM वह सेवा है जो आपको अपने AWS खाते के भीतर **प्रमाणीकरण**, **अधिकार** और **पहुंच नियंत्रण** प्रबंधित करने की अनुमति देती है।
|
||||
|
||||
- **प्रमाणीकरण** - एक पहचान को परिभाषित करने और उस पहचान के सत्यापन की प्रक्रिया। इस प्रक्रिया को पहचान और सत्यापन में विभाजित किया जा सकता है।
|
||||
- **अधिकार** - यह निर्धारित करता है कि एक पहचान एक प्रणाली के भीतर क्या पहुँच सकती है जब इसे प्रमाणित किया गया हो।
|
||||
- **पहुँच नियंत्रण** - सुरक्षित संसाधन तक पहुँच कैसे दी जाती है, इसकी विधि और प्रक्रिया।
|
||||
- **अधिकार** - यह निर्धारित करता है कि एक पहचान एक प्रणाली के भीतर क्या एक्सेस कर सकती है जब इसे इसके लिए प्रमाणित किया गया हो।
|
||||
- **पहुंच नियंत्रण** - यह सुरक्षित संसाधन तक पहुंच कैसे दी जाती है, इसकी विधि और प्रक्रिया
|
||||
|
||||
IAM को इसकी क्षमता द्वारा परिभाषित किया जा सकता है कि यह आपके AWS खाते के भीतर पहचान के प्रमाणीकरण, अधिकार और पहुँच नियंत्रण तंत्रों का प्रबंधन, नियंत्रण और शासन कर सकता है।
|
||||
IAM को इसकी पहचान के लिए आपके AWS खाते के भीतर संसाधनों के लिए प्रमाणीकरण, अधिकार और पहुंच नियंत्रण तंत्रों को प्रबंधित, नियंत्रित और शासित करने की क्षमता द्वारा परिभाषित किया जा सकता है।
|
||||
|
||||
### [AWS खाता रूट उपयोगकर्ता](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
|
||||
जब आप पहली बार एक Amazon Web Services (AWS) खाता बनाते हैं, तो आप एकल साइन-इन पहचान के साथ शुरू करते हैं जिसके पास खाते में सभी AWS सेवाओं और संसाधनों तक **पूर्ण पहुँच** होती है। यह AWS खाता _**रूट उपयोगकर्ता**_ है और इसे **उस ईमेल पते और पासवर्ड के साथ साइन इन करके एक्सेस किया जाता है जिसका उपयोग आपने खाता बनाने के लिए किया था**।
|
||||
जब आप पहली बार एक Amazon Web Services (AWS) खाता बनाते हैं, तो आप एक सिंगल साइन-इन पहचान के साथ शुरू करते हैं जिसके पास खाते में सभी AWS सेवाओं और संसाधनों तक **पूर्ण पहुंच** होती है। यह AWS खाता _**रूट उपयोगकर्ता**_ है और इसे **उस ईमेल पते और पासवर्ड के साथ साइन इन करके एक्सेस किया जाता है जिसका उपयोग आपने खाता बनाने के लिए किया था**।
|
||||
|
||||
ध्यान दें कि एक नया **व्यवस्थापक उपयोगकर्ता** के पास **रूट उपयोगकर्ता की तुलना में कम अनुमतियाँ होंगी**।
|
||||
|
||||
सुरक्षा के दृष्टिकोण से, अन्य उपयोगकर्ताओं को बनाना और इस एक का उपयोग करने से बचना अनुशंसित है।
|
||||
सुरक्षा के दृष्टिकोण से, अन्य उपयोगकर्ताओं को बनाना और इस उपयोगकर्ता का उपयोग करने से बचना अनुशंसित है।
|
||||
|
||||
### [IAM उपयोगकर्ता](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
|
||||
एक IAM _उपयोगकर्ता_ एक इकाई है जिसे आप AWS में **उस व्यक्ति या एप्लिकेशन का प्रतिनिधित्व करने के लिए बनाते हैं** जो इसका उपयोग **AWS के साथ बातचीत करने के लिए** करता है। AWS में एक उपयोगकर्ता का नाम और क्रेडेंशियल्स (पासवर्ड और दो तक पहुँच कुंजी) होता है।
|
||||
एक IAM _उपयोगकर्ता_ एक इकाई है जिसे आप AWS में **उस व्यक्ति या एप्लिकेशन का प्रतिनिधित्व करने के लिए बनाते हैं** जो इसका उपयोग **AWS के साथ बातचीत करने के लिए** करता है। AWS में एक उपयोगकर्ता का नाम और क्रेडेंशियल्स (पासवर्ड और अधिकतम दो एक्सेस कुंजी) होते हैं।
|
||||
|
||||
जब आप एक IAM उपयोगकर्ता बनाते हैं, तो आप इसे **अनुमतियाँ** प्रदान करते हैं, इसे एक **उपयोगकर्ता समूह का सदस्य बनाकर** जो उचित अनुमति नीतियों से जुड़ा होता है (अनुशंसित), या **सीधे उपयोगकर्ता पर नीतियाँ संलग्न करके**।
|
||||
जब आप एक IAM उपयोगकर्ता बनाते हैं, तो आप इसे **अनुमतियाँ** प्रदान करते हैं, जिससे यह एक **उपयोगकर्ता समूह का सदस्य बनता है** जिसमें उपयुक्त अनुमति नीतियाँ संलग्न होती हैं (अनुशंसित), या **प्रत्यक्ष रूप से नीतियाँ** उपयोगकर्ता से संलग्न करके।
|
||||
|
||||
उपयोगकर्ताओं के पास कंसोल के माध्यम से लॉगिन करने के लिए **MFA सक्षम** हो सकता है। MFA सक्षम उपयोगकर्ताओं के API टोकन MFA द्वारा सुरक्षित नहीं होते हैं। यदि आप **MFA का उपयोग करके उपयोगकर्ताओं की API कुंजियों की पहुँच को प्रतिबंधित करना चाहते हैं** तो आपको नीति में यह इंगित करना होगा कि कुछ क्रियाएँ करने के लिए MFA की आवश्यकता है (उदाहरण [**यहाँ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html))।
|
||||
उपयोगकर्ताओं के पास कंसोल के माध्यम से लॉगिन करने के लिए **MFA सक्षम** हो सकता है। MFA सक्षम उपयोगकर्ताओं के API टोकन MFA द्वारा सुरक्षित नहीं होते हैं। यदि आप **MFA का उपयोग करके उपयोगकर्ताओं की API कुंजियों की पहुंच को प्रतिबंधित करना चाहते हैं** तो आपको नीति में यह इंगित करना होगा कि कुछ क्रियाएँ करने के लिए MFA की आवश्यकता है (उदाहरण [**यहाँ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html))।
|
||||
|
||||
#### CLI
|
||||
|
||||
@@ -114,7 +114,7 @@ IAM को इसकी क्षमता द्वारा परिभाष
|
||||
|
||||
### MFA - मल्टी फैक्टर प्रमाणीकरण
|
||||
|
||||
यह आपके मौजूदा तरीकों, जैसे पासवर्ड, के अतिरिक्त **प्रमाणीकरण के लिए एक अतिरिक्त कारक बनाने** के लिए उपयोग किया जाता है, इस प्रकार, प्रमाणीकरण का एक मल्टी-फैक्टर स्तर बनता है।\
|
||||
यह आपके मौजूदा तरीकों के अलावा **प्रमाणीकरण के लिए एक अतिरिक्त कारक बनाने** के लिए उपयोग किया जाता है, जैसे पासवर्ड, इस प्रकार, प्रमाणीकरण का एक मल्टी-फैक्टर स्तर बनाना।\
|
||||
आप एक **नि:शुल्क वर्चुअल एप्लिकेशन या एक भौतिक उपकरण** का उपयोग कर सकते हैं। आप AWS में MFA सक्रिय करने के लिए मुफ्त में गूगल प्रमाणीकरण जैसे ऐप्स का उपयोग कर सकते हैं।
|
||||
|
||||
MFA शर्तों वाली नीतियाँ निम्नलिखित पर संलग्न की जा सकती हैं:
|
||||
@@ -123,39 +123,39 @@ MFA शर्तों वाली नीतियाँ निम्नलि
|
||||
- एक संसाधन जैसे Amazon S3 बकेट, Amazon SQS कतार, या Amazon SNS विषय
|
||||
- एक IAM भूमिका की ट्रस्ट नीति जिसे एक उपयोगकर्ता द्वारा ग्रहण किया जा सकता है
|
||||
|
||||
यदि आप **CLI के माध्यम से पहुँच** करना चाहते हैं एक संसाधन जो **MFA की जाँच करता है** तो आपको **`GetSessionToken`** कॉल करना होगा। यह आपको MFA के बारे में जानकारी के साथ एक टोकन देगा।\
|
||||
ध्यान दें कि **`AssumeRole` क्रेडेंशियल्स में यह जानकारी नहीं होती**।
|
||||
यदि आप **CLI के माध्यम से** एक संसाधन तक पहुँच प्राप्त करना चाहते हैं जो **MFA की जांच करता है** तो आपको **`GetSessionToken`** कॉल करने की आवश्यकता है। यह आपको MFA के बारे में जानकारी के साथ एक टोकन देगा।\
|
||||
ध्यान दें कि **`AssumeRole` क्रेडेंशियल्स में यह जानकारी नहीं होती है**।
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
As [**यहां कहा गया है**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), कई अलग-अलग मामले हैं जहां **MFA का उपयोग नहीं किया जा सकता**।
|
||||
जैसा कि [**यहां बताया गया है**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), ऐसे कई अलग-अलग मामले हैं जहां **MFA का उपयोग नहीं किया जा सकता**।
|
||||
|
||||
### [IAM उपयोगकर्ता समूह](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
एक IAM [उपयोगकर्ता समूह](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) एक ऐसा तरीका है जिससे **एक समय में कई उपयोगकर्ताओं के लिए नीतियों को संलग्न किया जा सकता है**, जिससे उन उपयोगकर्ताओं के लिए अनुमतियों का प्रबंधन करना आसान हो सकता है। **भूमिकाएँ और समूह समूह का हिस्सा नहीं हो सकते**।
|
||||
एक IAM [उपयोगकर्ता समूह](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) एक ऐसा तरीका है जिससे **एक समय में कई उपयोगकर्ताओं** के लिए नीतियों को **जोड़ना** आसान हो जाता है, जिससे उन उपयोगकर्ताओं के लिए अनुमतियों का प्रबंधन करना आसान हो जाता है। **भूमिकाएँ और समूह समूह का हिस्सा नहीं हो सकते**।
|
||||
|
||||
आप एक **पहचान-आधारित नीति को एक उपयोगकर्ता समूह में संलग्न कर सकते हैं** ताकि उपयोगकर्ता समूह में सभी **उपयोगकर्ताओं को नीति की अनुमतियाँ प्राप्त हों**। आप **एक उपयोगकर्ता समूह** को **`Principal`** के रूप में **नीति** (जैसे संसाधन-आधारित नीति) में पहचान नहीं सकते क्योंकि समूह अनुमतियों से संबंधित होते हैं, प्रमाणीकरण से नहीं, और प्रिंसिपल प्रमाणीकरण किए गए IAM संस्थाएँ हैं।
|
||||
आप एक **पहचान-आधारित नीति को एक उपयोगकर्ता समूह** से जोड़ सकते हैं ताकि उपयोगकर्ता समूह में सभी **उपयोगकर्ताओं को नीति की अनुमतियाँ प्राप्त हों**। आप **एक उपयोगकर्ता समूह** को **`Principal`** के रूप में **नीति** (जैसे संसाधन-आधारित नीति) में पहचान नहीं सकते क्योंकि समूह अनुमतियों से संबंधित होते हैं, प्रमाणीकरण से नहीं, और प्रिंसिपल प्रमाणीकरण किए गए IAM संस्थाएँ होती हैं।
|
||||
|
||||
यहां उपयोगकर्ता समूहों की कुछ महत्वपूर्ण विशेषताएँ हैं:
|
||||
उपयोगकर्ता समूहों की कुछ महत्वपूर्ण विशेषताएँ हैं:
|
||||
|
||||
- एक उपयोगकर्ता **समूह** में **कई उपयोगकर्ता हो सकते हैं**, और एक **उपयोगकर्ता** **कई समूहों का सदस्य हो सकता है**।
|
||||
- एक उपयोगकर्ता **समूह** में **कई उपयोगकर्ता** हो सकते हैं, और एक **उपयोगकर्ता** **कई समूहों** का **भाग हो सकता है**।
|
||||
- **उपयोगकर्ता समूहों को नेस्ट नहीं किया जा सकता**; वे केवल उपयोगकर्ताओं को शामिल कर सकते हैं, अन्य उपयोगकर्ता समूहों को नहीं।
|
||||
- **AWS खाते में सभी उपयोगकर्ताओं को स्वचालित रूप से शामिल करने वाला कोई डिफ़ॉल्ट उपयोगकर्ता समूह नहीं है**। यदि आप ऐसा उपयोगकर्ता समूह रखना चाहते हैं, तो आपको इसे बनाना होगा और प्रत्येक नए उपयोगकर्ता को इसमें असाइन करना होगा।
|
||||
- AWS खाते में सभी उपयोगकर्ताओं को स्वचालित रूप से शामिल करने वाला **कोई डिफ़ॉल्ट उपयोगकर्ता समूह नहीं है**। यदि आप ऐसा उपयोगकर्ता समूह रखना चाहते हैं, तो आपको इसे बनाना होगा और प्रत्येक नए उपयोगकर्ता को इसमें असाइन करना होगा।
|
||||
- AWS खाते में IAM संसाधनों की संख्या और आकार, जैसे समूहों की संख्या, और एक उपयोगकर्ता जिस समूह का सदस्य हो सकता है, सीमित हैं। अधिक जानकारी के लिए, [IAM और AWS STS कोटा](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) देखें।
|
||||
|
||||
### [IAM भूमिकाएँ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
एक IAM **भूमिका** एक **उपयोगकर्ता** के समान है, क्योंकि यह एक **पहचान है जिसमें अनुमति नीतियाँ होती हैं जो यह निर्धारित करती हैं कि** यह AWS में क्या कर सकता है और क्या नहीं। हालाँकि, एक भूमिका के साथ कोई **क्रेडेंशियल्स** (पासवर्ड या एक्सेस कुंजी) नहीं होते। एक व्यक्ति के साथ विशेष रूप से जुड़े होने के बजाय, एक भूमिका को **किसी भी व्यक्ति द्वारा अपनाने के लिए डिज़ाइन किया गया है जिसे इसकी आवश्यकता है (और जिसके पास पर्याप्त अनुमतियाँ हैं)**। एक **IAM उपयोगकर्ता एक भूमिका को अस्थायी रूप से** एक विशिष्ट कार्य के लिए विभिन्न अनुमतियाँ लेने के लिए अपना सकता है। एक भूमिका को एक [**संघीय उपयोगकर्ता**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) को असाइन किया जा सकता है जो IAM के बजाय एक बाहरी पहचान प्रदाता का उपयोग करके साइन इन करता है।
|
||||
एक IAM **भूमिका** एक **उपयोगकर्ता** के समान है, क्योंकि यह एक **पहचान है जिसमें अनुमति नीतियाँ होती हैं जो यह निर्धारित करती हैं कि** यह AWS में क्या कर सकता है और क्या नहीं। हालाँकि, एक भूमिका के साथ **कोई प्रमाण-पत्र** (पासवर्ड या एक्सेस कुंजी) नहीं होता है। एक व्यक्ति के साथ विशेष रूप से जुड़ने के बजाय, एक भूमिका को **किसी भी व्यक्ति द्वारा अपनाने के लिए डिज़ाइन किया गया है जिसे इसकी आवश्यकता है (और जिसके पास पर्याप्त अनुमतियाँ हैं)**। एक **IAM उपयोगकर्ता एक भूमिका को अस्थायी रूप से** एक विशिष्ट कार्य के लिए विभिन्न अनुमतियाँ लेने के लिए अपना सकता है। एक भूमिका को एक [**संघीय उपयोगकर्ता**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) को असाइन किया जा सकता है जो IAM के बजाय एक बाहरी पहचान प्रदाता का उपयोग करके साइन इन करता है।
|
||||
|
||||
एक IAM भूमिका में **दो प्रकार की नीतियाँ** होती हैं: एक **विश्वास नीति**, जो खाली नहीं हो सकती, यह परिभाषित करती है कि **कौन भूमिका को अपना सकता है**, और एक **अनुमति नीति**, जो खाली नहीं हो सकती, यह परिभाषित करती है कि **यह क्या एक्सेस कर सकता है**।
|
||||
|
||||
#### AWS सुरक्षा टोकन सेवा (STS)
|
||||
|
||||
AWS सुरक्षा टोकन सेवा (STS) एक वेब सेवा है जो **अस्थायी, सीमित-विशेषाधिकार क्रेडेंशियल्स** के **जारी करने** की सुविधा प्रदान करती है। यह विशेष रूप से निम्नलिखित के लिए तैयार की गई है:
|
||||
AWS सुरक्षा टोकन सेवा (STS) एक वेब सेवा है जो **अस्थायी, सीमित-विशेषाधिकार प्रमाण-पत्रों** के **जारी करने** की सुविधा प्रदान करती है। यह विशेष रूप से निम्नलिखित के लिए तैयार की गई है:
|
||||
|
||||
### [IAM में अस्थायी क्रेडेंशियल्स](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
### [IAM में अस्थायी प्रमाण-पत्र](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
**अस्थायी क्रेडेंशियल्स मुख्य रूप से IAM भूमिकाओं के साथ उपयोग की जाती हैं**, लेकिन इसके अन्य उपयोग भी हैं। आप अस्थायी क्रेडेंशियल्स का अनुरोध कर सकते हैं जिनमें आपके मानक IAM उपयोगकर्ता की तुलना में अधिक सीमित अनुमतियों का सेट होता है। यह **आपको** **अनुमत नहीं किए गए कार्यों को गलती से करने से रोकता है**। अस्थायी क्रेडेंशियल्स का एक लाभ यह है कि वे एक निर्धारित समय के बाद स्वचालित रूप से समाप्त हो जाते हैं। आपके पास यह नियंत्रित करने की क्षमता है कि क्रेडेंशियल्स कितने समय तक मान्य हैं।
|
||||
**अस्थायी प्रमाण-पत्र मुख्य रूप से IAM भूमिकाओं के साथ उपयोग किए जाते हैं**, लेकिन इसके अन्य उपयोग भी हैं। आप अस्थायी प्रमाण-पत्रों के लिए अनुरोध कर सकते हैं जिनमें आपके मानक IAM उपयोगकर्ता की तुलना में अधिक सीमित अनुमतियों का सेट होता है। यह **आपको** **अनजाने में उन कार्यों को करने से रोकता है जो अधिक सीमित प्रमाण-पत्रों द्वारा अनुमति नहीं दी गई हैं**। अस्थायी प्रमाण-पत्रों का एक लाभ यह है कि वे एक निर्धारित समय के बाद स्वचालित रूप से समाप्त हो जाते हैं। आपके पास यह नियंत्रित करने की क्षमता है कि प्रमाण-पत्र कितने समय तक मान्य हैं।
|
||||
|
||||
### नीतियाँ
|
||||
|
||||
@@ -167,7 +167,7 @@ AWS सुरक्षा टोकन सेवा (STS) एक वेब स
|
||||
- ग्राहक प्रबंधित नीतियाँ: आपके द्वारा कॉन्फ़िगर की गई। आप AWS प्रबंधित नीतियों के आधार पर नीतियाँ बना सकते हैं (उनमें से एक को संशोधित करके और अपनी खुद की बनाकर), नीति जनरेटर का उपयोग करके (एक GUI दृश्य जो आपको अनुमतियाँ देने और अस्वीकार करने में मदद करता है) या अपनी खुद की लिखकर।
|
||||
|
||||
**डिफ़ॉल्ट रूप से पहुँच** **अस्वीकृत** है, यदि एक स्पष्ट भूमिका निर्दिष्ट की गई है तो पहुँच दी जाएगी।\
|
||||
यदि **एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा**, AWS खाते की रूट सुरक्षा क्रेडेंशियल्स का उपयोग करने वाले अनुरोधों को छोड़कर (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
|
||||
यदि **एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा**, AWS खाते की रूट सुरक्षा प्रमाण-पत्रों का उपयोग करने वाले अनुरोधों को छोड़कर (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
@@ -190,33 +190,33 @@ AWS सुरक्षा टोकन सेवा (STS) एक वेब स
|
||||
]
|
||||
}
|
||||
```
|
||||
The [global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
The [specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
[वैश्विक फ़ील्ड जो किसी भी सेवा में शर्तों के लिए उपयोग की जा सकती हैं, यहाँ दस्तावेज़ित हैं](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
[विशिष्ट फ़ील्ड जो सेवा के अनुसार शर्तों के लिए उपयोग की जा सकती हैं, यहाँ दस्तावेज़ित हैं](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
|
||||
#### Inline Policies
|
||||
#### इनलाइन नीतियाँ
|
||||
|
||||
इस प्रकार की नीतियाँ **प्रत्यक्ष रूप से** एक उपयोगकर्ता, समूह या भूमिका को असाइन की जाती हैं। फिर, वे नीतियों की सूची में नहीं दिखाई देती हैं क्योंकि कोई अन्य उनका उपयोग कर सकता है।\
|
||||
Inline policies उपयोगी होती हैं यदि आप **एक नीति और उस पहचान के बीच एक सख्त एक-से-एक संबंध बनाए रखना चाहते हैं** जिस पर इसे लागू किया गया है। उदाहरण के लिए, आप यह सुनिश्चित करना चाहते हैं कि किसी नीति में अनुमतियाँ अनजाने में किसी अन्य पहचान को असाइन नहीं की गई हैं। जब आप एक inline policy का उपयोग करते हैं, तो नीति में अनुमतियाँ अनजाने में गलत पहचान से नहीं जुड़ सकतीं। इसके अलावा, जब आप AWS प्रबंधन कंसोल का उपयोग करके उस पहचान को हटाते हैं, तो पहचान में निहित नीतियाँ भी हटा दी जाती हैं। इसका कारण यह है कि वे प्रमुख इकाई का हिस्सा हैं।
|
||||
इनलाइन नीतियाँ उपयोगी होती हैं यदि आप **नीति और पहचान के बीच एक सख्त एक-से-एक संबंध बनाए रखना चाहते हैं**। उदाहरण के लिए, आप यह सुनिश्चित करना चाहते हैं कि नीति में अनुमतियाँ अनजाने में किसी अन्य पहचान को असाइन नहीं की गई हैं। जब आप एक इनलाइन नीति का उपयोग करते हैं, तो नीति में अनुमतियाँ अनजाने में गलत पहचान से नहीं जुड़ सकती हैं। इसके अलावा, जब आप AWS प्रबंधन कंसोल का उपयोग करके उस पहचान को हटाते हैं, तो पहचान में निहित नीतियाँ भी हटा दी जाती हैं। इसका कारण यह है कि वे प्रमुख इकाई का हिस्सा हैं।
|
||||
|
||||
#### Resource Bucket Policies
|
||||
#### संसाधन बाल्टी नीतियाँ
|
||||
|
||||
ये **नीतियाँ** हैं जिन्हें **संसाधनों** में परिभाषित किया जा सकता है। **AWS के सभी संसाधन उनका समर्थन नहीं करते**।
|
||||
ये **नीतियाँ** हैं जो **संसाधनों** में परिभाषित की जा सकती हैं। **AWS के सभी संसाधन उनका समर्थन नहीं करते**।
|
||||
|
||||
यदि किसी प्रमुख के पास उन पर स्पष्ट अस्वीकृति नहीं है, और एक संसाधन नीति उन्हें पहुँच प्रदान करती है, तो उन्हें अनुमति दी जाती है।
|
||||
|
||||
### IAM Boundaries
|
||||
### IAM सीमाएँ
|
||||
|
||||
IAM सीमाएँ **एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने के लिए** उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को **एक अलग नीति** द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन **विफल** हो जाएगा।
|
||||
IAM सीमाएँ **एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने के लिए** उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को **विभिन्न नीति** द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन **विफल** हो जाएगा।
|
||||
|
||||
एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो **यह संकेत करती है कि उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों का स्तर क्या हो सकता है**। इसलिए, **भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो**, यदि सीमा यह संकेत करती है कि वह केवल S· बकेट पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
|
||||
एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो **उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों के स्तर को इंगित करती है**। तो, **भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो**, यदि सीमा इंगित करती है कि वह केवल S· बाल्टियों को पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
|
||||
|
||||
**यह**, **SCPs** और **कम से कम विशेषाधिकार** सिद्धांत का पालन करना उन तरीकों में से हैं जिनसे यह नियंत्रित किया जा सकता है कि उपयोगकर्ताओं के पास उनकी आवश्यकताओं से अधिक अनुमतियाँ नहीं हैं।
|
||||
|
||||
### Session Policies
|
||||
### सत्र नीतियाँ
|
||||
|
||||
एक सत्र नीति एक **नीति है जो तब सेट की जाती है जब किसी भूमिका को किसी तरह से ग्रहण किया जाता है**। यह उस सत्र के लिए एक **IAM सीमा** की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि **उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है** (अधिकतम अनुमतियाँ वे होती हैं जो भूमिका के पास होती हैं)।
|
||||
एक सत्र नीति एक **नीति है जो तब सेट की जाती है जब किसी भूमिका को अपनाया जाता है**। यह उस सत्र के लिए एक **IAM सीमा** की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि **उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है** (अधिकतम अनुमतियाँ वे होती हैं जो भूमिका के पास होती हैं)।
|
||||
|
||||
यह **सुरक्षा उपायों** के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका ग्रहण करने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
|
||||
यह **सुरक्षा उपायों** के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका को अपनाने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
@@ -224,18 +224,18 @@ aws sts assume-role \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
नोट करें कि डिफ़ॉल्ट रूप से **AWS सत्रों में सत्र नीतियाँ जोड़ सकता है** जो तीसरे कारणों के कारण उत्पन्न होने वाले हैं। उदाहरण के लिए, [अप्रमाणित कॉग्निटो अनुमोदित भूमिकाओं](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) में डिफ़ॉल्ट रूप से (सुधारित प्रमाणीकरण का उपयोग करते हुए), AWS **सत्र नीति के साथ सत्र क्रेडेंशियल्स** उत्पन्न करेगा जो उस सत्र को पहुँचने वाली सेवाओं को सीमित करता है [**निम्नलिखित सूची**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)।
|
||||
|
||||
इसलिए, यदि किसी बिंदु पर आप त्रुटि का सामना करते हैं "... क्योंकि कोई सत्र नीति अनुमति नहीं देती है ...", और भूमिका को कार्रवाई करने की अनुमति है, तो इसका कारण है कि **एक सत्र नीति इसे रोक रही है**।
|
||||
इसलिए, यदि किसी बिंदु पर आप त्रुटि का सामना करते हैं "... क्योंकि कोई सत्र नीति अनुमति नहीं देती है ...", और भूमिका को क्रिया करने की अनुमति है, तो इसका मतलब है कि **एक सत्र नीति इसे रोक रही है**।
|
||||
|
||||
### पहचान संघ
|
||||
|
||||
पहचान संघ **AWS के लिए बाहरी पहचान प्रदाताओं से उपयोगकर्ताओं को सुरक्षित रूप से AWS संसाधनों तक पहुँचने की अनुमति देता है** बिना किसी मान्य IAM उपयोगकर्ता खाते से AWS उपयोगकर्ता क्रेडेंशियल प्रदान किए।\
|
||||
एक पहचान प्रदाता का उदाहरण आपका अपना कॉर्पोरेट **Microsoft Active Directory** (द्वारा **SAML**) या **OpenID** सेवाएँ (जैसे **Google**) हो सकता है। संघीय पहुँच फिर उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।
|
||||
पहचान संघ **AWS के लिए बाहरी पहचान प्रदाताओं से उपयोगकर्ताओं को सुरक्षित रूप से AWS संसाधनों तक पहुँचने की अनुमति देता है** बिना AWS उपयोगकर्ता क्रेडेंशियल्स को एक मान्य IAM उपयोगकर्ता खाते से प्रदान किए।\
|
||||
एक पहचान प्रदाता का उदाहरण आपके अपने कॉर्पोरेट **Microsoft Active Directory** (द्वारा **SAML**) या **OpenID** सेवाएँ (जैसे **Google**) हो सकता है। संघीय पहुँच फिर उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।
|
||||
|
||||
इस विश्वास को कॉन्फ़िगर करने के लिए, एक **IAM पहचान प्रदाता उत्पन्न किया जाता है (SAML या OAuth)** जो **अन्य प्लेटफ़ॉर्म** पर **विश्वास करेगा**। फिर, कम से कम एक **IAM भूमिका (विश्वास करने वाली) पहचान प्रदाता को सौंपा जाता है**। यदि विश्वसनीय प्लेटफ़ॉर्म से एक उपयोगकर्ता AWS तक पहुँचता है, तो वह उल्लेखित भूमिका के रूप में पहुँच रहा होगा।
|
||||
इस विश्वास को कॉन्फ़िगर करने के लिए, एक **IAM पहचान प्रदाता उत्पन्न किया जाता है (SAML या OAuth)** जो **अन्य प्लेटफ़ॉर्म** पर **विश्वास करेगा**। फिर, कम से कम एक **IAM भूमिका (विश्वास करने वाली) पहचान प्रदाता को सौंपा जाता है**। यदि विश्वसनीय प्लेटफ़ॉर्म से कोई उपयोगकर्ता AWS तक पहुँचता है, तो वह उल्लेखित भूमिका के रूप में पहुँच रहा होगा।
|
||||
|
||||
हालांकि, आप आमतौर पर **उपयोगकर्ता के समूह के आधार पर एक अलग भूमिका देना चाहेंगे** तीसरे पक्ष के प्लेटफ़ॉर्म में। फिर, कई **IAM भूमिकाएँ तीसरे पक्ष के पहचान प्रदाता पर विश्वास कर सकती हैं** और तीसरा पक्ष का प्लेटफ़ॉर्म उपयोगकर्ताओं को एक भूमिका या दूसरी भूमिका ग्रहण करने की अनुमति देगा।
|
||||
हालांकि, आप आमतौर पर **उपयोगकर्ता के समूह के आधार पर एक अलग भूमिका देना चाहेंगे** तीसरे पक्ष के प्लेटफ़ॉर्म में। फिर, कई **IAM भूमिकाएँ तीसरे पक्ष के पहचान प्रदाता पर विश्वास कर सकती हैं** और तीसरा पक्ष का प्लेटफ़ॉर्म उपयोगकर्ताओं को एक भूमिका या दूसरी भूमिका को मानने की अनुमति देगा।
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -259,14 +259,14 @@ AWS IAM पहचान केंद्र (AWS सिंगल साइन-ऑ
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
यह संभव है कि **IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमतियाँ दी जाएं**। उन खातों में बनाई गई भूमिकाएँ जिन्हें **AWS पहचान केंद्र में इनलाइन नीतियाँ दी गई हैं** इनलाइन नीति में **`AwsSSOInlinePolicy`** के रूप में ये अनुमतियाँ होंगी।
|
||||
यह संभव है कि **IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमतियाँ दी जाएं**। उन खातों में बनाई गई भूमिकाएँ जिन्हें **AWS पहचान केंद्र में इनलाइन नीतियाँ दी गई हैं** इन अनुमतियों को **`AwsSSOInlinePolicy`** नामक एक इनलाइन नीति में रखेंगे।
|
||||
|
||||
इसलिए, भले ही आप **`AwsSSOInlinePolicy`** नामक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह **यह नहीं दर्शाता कि इसकी समान अनुमतियाँ हैं**।
|
||||
इसलिए, भले ही आप **`AwsSSOInlinePolicy`** नामक एक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह **मतलब नहीं है कि इसकी समान अनुमतियाँ हैं**।
|
||||
|
||||
### क्रॉस खाता विश्वास और भूमिकाएँ
|
||||
|
||||
**एक उपयोगकर्ता** (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, **दूसरे उपयोगकर्ता** (विश्वासित) को **अपने खाते तक पहुँचने की अनुमति दे सकता है** लेकिन केवल **नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ**। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके पास हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके पास है और एक तीसरे पक्ष के AWS खाते के बीच।\
|
||||
यह अनुशंसा की जाती है कि **विश्वासित उपयोगकर्ता को निर्दिष्ट करें और कुछ सामान्य चीज़ न डालें** क्योंकि यदि नहीं, तो अन्य प्रमाणित उपयोगकर्ता जैसे संघीय उपयोगकर्ता भी इस विश्वास का दुरुपयोग कर सकेंगे।
|
||||
**एक उपयोगकर्ता** (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, **दूसरे उपयोगकर्ता** (विश्वासित) को **अपने खाते तक पहुँचने की अनुमति दे सकता है** लेकिन केवल **नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ**। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके हैं और एक तीसरे पक्ष के AWS खाते के बीच।\
|
||||
यह अनुशंसा की जाती है कि **विश्वासित उपयोगकर्ता को निर्दिष्ट करें और कुछ सामान्य चीज़ें न डालें** क्योंकि यदि नहीं, तो अन्य प्रमाणित उपयोगकर्ता जैसे संघीय उपयोगकर्ता भी इस विश्वास का दुरुपयोग कर सकेंगे।
|
||||
|
||||
### AWS सरल AD
|
||||
|
||||
@@ -286,14 +286,14 @@ AWS IAM पहचान केंद्र (AWS सिंगल साइन-ऑ
|
||||
|
||||
### अन्य IAM विकल्प
|
||||
|
||||
- आप **पासवर्ड नीति सेटिंग** विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताओं को सेट कर सकते हैं।
|
||||
- आप **पासवर्ड नीति सेटिंग** विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताओं को **सेट कर सकते हैं**।
|
||||
- आप **"क्रेडेंशियल रिपोर्ट" डाउनलोड कर सकते हैं** जिसमें वर्तमान क्रेडेंशियल्स के बारे में जानकारी होती है (जैसे उपयोगकर्ता निर्माण समय, क्या पासवर्ड सक्षम है...)। आप एक क्रेडेंशियल रिपोर्ट हर **चार घंटे** में एक बार उत्पन्न कर सकते हैं।
|
||||
|
||||
AWS पहचान और पहुँच प्रबंधन (IAM) **AWS के सभी क्षेत्रों में बारीक पहुँच नियंत्रण** प्रदान करता है। IAM के साथ, आप निर्दिष्ट कर सकते हैं **कौन कौन सी सेवाओं और संसाधनों तक पहुँच सकता है**, और किन शर्तों के तहत। IAM नीतियों के साथ, आप अपनी कार्यबल और प्रणालियों के लिए अनुमतियों का प्रबंधन करते हैं ताकि **कम से कम विशेषाधिकार अनुमतियाँ सुनिश्चित की जा सकें**।
|
||||
|
||||
### IAM ID उपसर्ग
|
||||
|
||||
[**इस पृष्ठ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) पर आप कुंजियों के **IAM ID उपसर्ग** उनकी प्रकृति के अनुसार पा सकते हैं:
|
||||
[**इस पृष्ठ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) पर आप कुंजियों के उपसर्गों को उनकी प्रकृति के आधार पर पा सकते हैं:
|
||||
|
||||
| ABIA | [AWS STS सेवा धारक टोकन](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
@@ -326,9 +326,9 @@ AWS पहचान और पहुँच प्रबंधन (IAM) **AWS क
|
||||
|
||||
### CLI प्रमाणीकरण
|
||||
|
||||
एक नियमित उपयोगकर्ता को CLI के माध्यम से AWS में प्रमाणीकरण करने के लिए **स्थानीय क्रेडेंशियल्स** होना आवश्यक है। डिफ़ॉल्ट रूप से, आप उन्हें **हाथ से** `~/.aws/credentials` में कॉन्फ़िगर कर सकते हैं या **चलाकर** `aws configure`।\
|
||||
एक नियमित उपयोगकर्ता को CLI के माध्यम से AWS में प्रमाणीकरण करने के लिए आपको **स्थानीय क्रेडेंशियल्स** की आवश्यकता होती है। डिफ़ॉल्ट रूप से आप उन्हें **हाथ से** `~/.aws/credentials` में कॉन्फ़िगर कर सकते हैं या **चलाकर** `aws configure`।\
|
||||
उस फ़ाइल में आपके पास एक से अधिक प्रोफ़ाइल हो सकती हैं, यदि **कोई प्रोफ़ाइल** निर्दिष्ट नहीं की गई है तो **aws cli** का उपयोग करते समय, उस फ़ाइल में **`[default]`** नामक प्रोफ़ाइल का उपयोग किया जाएगा।\
|
||||
एक से अधिक प्रोफ़ाइल के साथ क्रेडेंशियल फ़ाइल का उदाहरण:
|
||||
एक से अधिक प्रोफ़ाइल के साथ क्रेडेंशियल्स फ़ाइल का उदाहरण:
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
|
||||
@@ -339,7 +339,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
|
||||
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
|
||||
region = eu-west-2
|
||||
```
|
||||
यदि आपको **विभिन्न AWS खातों** तक पहुँचने की आवश्यकता है और आपके प्रोफ़ाइल को **उन खातों के अंदर एक भूमिका ग्रहण करने** की अनुमति दी गई है, तो आपको हर बार मैन्युअल रूप से STS को कॉल करने की आवश्यकता नहीं है (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) और क्रेडेंशियल्स को कॉन्फ़िगर करने की।
|
||||
यदि आपको **विभिन्न AWS खातों** तक पहुँचने की आवश्यकता है और आपके प्रोफ़ाइल को **उन खातों के भीतर एक भूमिका ग्रहण करने** की अनुमति दी गई है, तो आपको हर बार मैन्युअल रूप से STS को कॉल करने की आवश्यकता नहीं है (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) और क्रेडेंशियल्स को कॉन्फ़िगर करने की आवश्यकता नहीं है।
|
||||
|
||||
आप `~/.aws/config` फ़ाइल का उपयोग कर सकते हैं[ **यह इंगित करने के लिए कि कौन सी भूमिकाएँ ग्रहण करनी हैं**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), और फिर सामान्य रूप से `--profile` पैरामीटर का उपयोग करें (भूमिका ग्रहण करना उपयोगकर्ता के लिए पारदर्शी तरीके से किया जाएगा)।\
|
||||
एक कॉन्फ़िग फ़ाइल का उदाहरण:
|
||||
@@ -355,7 +355,7 @@ sts_regional_endpoints = regional
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
यदि आप इसके लिए कुछ **समान** खोज रहे हैं लेकिन **ब्राउज़र** के लिए, तो आप **एक्सटेंशन** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) देख सकते हैं।
|
||||
यदि आप इसके लिए कुछ **समान** खोज रहे हैं लेकिन **ब्राउज़र** के लिए, तो आप **विस्तार** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) देख सकते हैं।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
@@ -10,17 +10,17 @@ SAML के बारे में जानकारी के लिए कृ
|
||||
https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
{{#endref}}
|
||||
|
||||
**SAML** के माध्यम से **Identity Federation** को कॉन्फ़िगर करने के लिए आपको केवल एक **नाम** और **metadata XML** प्रदान करने की आवश्यकता है जिसमें सभी SAML कॉन्फ़िगरेशन (**endpoints**, **certificate** जिसमें सार्वजनिक कुंजी है) शामिल हैं।
|
||||
**SAML के माध्यम से एक पहचान संघ** को कॉन्फ़िगर करने के लिए आपको केवल एक **नाम** और **मेटाडेटा XML** प्रदान करने की आवश्यकता है जिसमें सभी SAML कॉन्फ़िगरेशन (**एंडपॉइंट्स**, **सार्वजनिक कुंजी के साथ प्रमाणपत्र**) शामिल हैं।
|
||||
|
||||
## OIDC - Github Actions Abuse
|
||||
|
||||
एक github action को Identity provider के रूप में जोड़ने के लिए:
|
||||
एक github क्रिया को पहचान प्रदाता के रूप में जोड़ने के लिए:
|
||||
|
||||
1. _Provider type_ के लिए, **OpenID Connect** चुनें।
|
||||
2. _Provider URL_ के लिए, `https://token.actions.githubusercontent.com` दर्ज करें।
|
||||
3. प्रदाता का थंबप्रिंट प्राप्त करने के लिए _Get thumbprint_ पर क्लिक करें।
|
||||
3. प्रदाता के थंबप्रिंट को प्राप्त करने के लिए _Get thumbprint_ पर क्लिक करें।
|
||||
4. _Audience_ के लिए, `sts.amazonaws.com` दर्ज करें।
|
||||
5. एक **नया भूमिका** बनाएं जिसमें **permissions** हों जो github action को चाहिए और एक **trust policy** जो प्रदाता पर भरोसा करती हो जैसे:
|
||||
5. एक **नया भूमिका** बनाएं जिसमें **permissions** हों जो github क्रिया को चाहिए और एक **trust policy** जो प्रदाता पर भरोसा करती हो जैसे:
|
||||
- ```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -44,9 +44,9 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
]
|
||||
}
|
||||
```
|
||||
6. पिछले नीति में ध्यान दें कि केवल एक **branch** को **repository** के **organization** से एक विशिष्ट **trigger** के साथ अधिकृत किया गया था।
|
||||
7. **role** का **ARN** जिसे github action **impersonate** करने में सक्षम होगा, वह "secret" होगा जिसे github action को जानने की आवश्यकता है, इसलिए इसे एक **secret** के अंदर एक **environment** में **store** करें।
|
||||
8. अंत में, AWS creds को कॉन्फ़िगर करने के लिए एक github action का उपयोग करें जो workflow द्वारा उपयोग किया जाएगा:
|
||||
6. पिछले नीति में ध्यान दें कि केवल एक **branch** को एक **organization** के **repository** से एक विशिष्ट **trigger** के साथ अधिकृत किया गया था।
|
||||
7. **ARN** उस **role** का होगा जिसे github क्रिया **impersonate** कर सकेगी, इसलिए इसे एक **secret** के अंदर एक **environment** में **store** करें।
|
||||
8. अंत में, कार्यप्रवाह द्वारा उपयोग किए जाने वाले AWS creds को कॉन्फ़िगर करने के लिए एक github क्रिया का उपयोग करें:
|
||||
```yaml
|
||||
name: "test AWS Access"
|
||||
|
||||
@@ -108,7 +108,7 @@ eksctl utils associate-iam-oidc-provider --cluster Testing --approve
|
||||
]
|
||||
}
|
||||
```
|
||||
यह नीति सही ढंग से संकेत कर रही है कि **केवल** **EKS क्लस्टर** जिसका **id** `20C159CDF6F2349B68846BEC03BE031B` है, वह भूमिका ग्रहण कर सकता है। हालाँकि, यह यह नहीं बता रहा है कि कौन सी सेवा खाता इसे ग्रहण कर सकता है, जिसका अर्थ है कि **कोई भी सेवा खाता जिसमें एक वेब पहचान टोकन है** वह भूमिका ग्रहण करने में **सक्षम होगा**।
|
||||
यह नीति सही ढंग से संकेत कर रही है कि **केवल** **EKS क्लस्टर** जिसका **id** `20C159CDF6F2349B68846BEC03BE031B` है, वह भूमिका ग्रहण कर सकता है। हालाँकि, यह यह नहीं बता रहा है कि कौन सी सेवा खाता इसे ग्रहण कर सकता है, जिसका अर्थ है कि **किसी भी सेवा खाते के पास एक वेब पहचान टोकन** होने पर वह भूमिका ग्रहण करने में **सक्षम** होगा।
|
||||
|
||||
**जिस सेवा खाते को भूमिका ग्रहण करने में सक्षम होना चाहिए,** उसे निर्दिष्ट करने के लिए, एक **शर्त** निर्दिष्ट करना आवश्यक है जहाँ **सेवा खाता नाम निर्दिष्ट किया गया है**, जैसे:
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user