hacktricks-cloud/src/pentesting-cloud/aws-security/aws-basic-information

AWS - मूल जानकारी

{{#include ../../../banners/hacktricks-training.md}}

संगठन पदानुक्रम

खाते

AWS में एक रूट खाता होता है, जो आपके संगठन के सभी खातों के लिए माता-पिता कंटेनर है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप विभिन्न AWS अवसंरचनाओं को अलग करने के लिए अन्य खाते बना सकते हैं।

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

इसलिए, एक संगठन में दो प्रकार के खाते होते हैं (हम AWS खातों की बात कर रहे हैं, उपयोगकर्ता खातों की नहीं): एक एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।

• प्रबंधन खाता (रूट खाता) वह खाता है जिसका उपयोग आप संगठन बनाने के लिए करते हैं। संगठन के प्रबंधन खाते से, आप निम्नलिखित कर सकते हैं:

• संगठन में खाते बनाना

• संगठन में अन्य मौजूदा खातों को आमंत्रित करना

• संगठन से खातों को हटाना

• आमंत्रण प्रबंधित करना

• संगठन के भीतर संस्थाओं (रूट, OU, या खाते) पर नीतियाँ लागू करना

• संगठन में सभी खातों के बीच सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करना।

• आप इस रूट खाते/संगठन को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके रूट उपयोगकर्ता के रूप में लॉगिन कर सकते हैं।

प्रबंधन खाते की भुगतानकर्ता खाते की जिम्मेदारियाँ होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप संगठन के प्रबंधन खाते को बदल नहीं सकते।

• सदस्य खाते संगठन में बाकी सभी खातों का निर्माण करते हैं। एक खाता एक समय में केवल एक संगठन का सदस्य हो सकता है। आप एक खाते पर नियंत्रण लागू करने के लिए एक नीति संलग्न कर सकते हैं केवल उसी एक खाते पर।
• सदस्य खातों को एक मान्य ईमेल पता का उपयोग करना चाहिए और एक नाम हो सकता है, सामान्यतः वे बिलिंग का प्रबंधन नहीं कर पाएंगे (लेकिन उन्हें इसके लिए पहुँच दी जा सकती है)।

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

संगठन इकाइयाँ

खातों को संगठन इकाइयों (OU) में समूहित किया जा सकता है। इस तरह, आप संगठन इकाई के लिए नीतियाँ बना सकते हैं जो सभी बच्चों के खातों पर लागू होंगी। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

सेवा नियंत्रण नीति (SCP)

एक सेवा नियंत्रण नीति (SCP) एक नीति है जो उन सेवाओं और क्रियाओं को निर्दिष्ट करती है जिन्हें उपयोगकर्ता और भूमिकाएँ उन खातों में उपयोग कर सकते हैं जिन पर SCP प्रभाव डालती है। SCPs IAM अनुमतियों की नीतियों के समान हैं, सिवाय इसके कि वे कोई अनुमतियाँ नहीं देतीं। इसके बजाय, SCPs एक संगठन, संगठनात्मक इकाई (OU), या खाते के लिए अधिकतम अनुमतियों को निर्दिष्ट करती हैं। जब आप अपने संगठन की जड़ या एक OU पर SCP संलग्न करते हैं, तो SCP सदस्य खातों में संस्थाओं के लिए अनुमतियों को सीमित करती है।

यह एकमात्र तरीका है कि यहां तक कि रूट उपयोगकर्ता को कुछ करने से रोका जा सकता है। उदाहरण के लिए, इसका उपयोग उपयोगकर्ताओं को CloudTrail को निष्क्रिय करने या बैकअप हटाने से रोकने के लिए किया जा सकता है।
इससे बचने का एकमात्र तरीका यह है कि मास्टर खाता भी समझौता किया जाए जो SCPs को कॉन्फ़िगर करता है (मास्टर खाता को अवरुद्ध नहीं किया जा सकता)।

Warning

ध्यान दें कि SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि SCP द्वारा s3:GetObject को अस्वीकार करने से लोगों को आपके खाते में एक सार्वजनिक S3 बकेट तक पहुँचने से नहीं रोका जाएगा।

SCP उदाहरण:

• रूट खाते को पूरी तरह से अस्वीकार करें

• केवल विशिष्ट क्षेत्रों की अनुमति दें

• केवल श्वेत-पत्रित सेवाओं की अनुमति दें

• GuardDuty, CloudTrail, और S3 सार्वजनिक ब्लॉक एक्सेस को निष्क्रिय करने से रोकें

• सुरक्षा/घटना प्रतिक्रिया भूमिकाओं को हटाने या

संशोधित करने से रोकें।

• बैकअप को हटाने से रोकें।
• IAM उपयोगकर्ताओं और एक्सेस कुंजियों को बनाने से रोकें

JSON उदाहरण https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html में खोजें

ARN

Amazon Resource Name AWS के अंदर हर संसाधन का विशिष्ट नाम है, यह इस प्रकार से बना है:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

ध्यान दें कि 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 वह सेवा है जो आपको अपने AWS खाते के भीतर प्रमाणीकरण, अधिकार और पहुंच नियंत्रण प्रबंधित करने की अनुमति देती है।

• प्रमाणीकरण - एक पहचान को परिभाषित करने और उस पहचान के सत्यापन की प्रक्रिया। इस प्रक्रिया को पहचान और सत्यापन में विभाजित किया जा सकता है।
• अधिकार - यह निर्धारित करता है कि एक पहचान एक प्रणाली के भीतर क्या एक्सेस कर सकती है जब इसे इसके लिए प्रमाणित किया गया हो।
• पहुंच नियंत्रण - यह सुरक्षित संसाधन तक पहुंच कैसे दी जाती है, इसकी विधि और प्रक्रिया

IAM को इसकी पहचान के लिए आपके AWS खाते के भीतर संसाधनों के लिए प्रमाणीकरण, अधिकार और पहुंच नियंत्रण तंत्रों को प्रबंधित, नियंत्रित और शासित करने की क्षमता द्वारा परिभाषित किया जा सकता है।

AWS खाता रूट उपयोगकर्ता

जब आप पहली बार एक Amazon Web Services (AWS) खाता बनाते हैं, तो आप एक सिंगल साइन-इन पहचान के साथ शुरू करते हैं जिसके पास खाते में सभी AWS सेवाओं और संसाधनों तक पूर्ण पहुंच होती है। यह AWS खाता रूट उपयोगकर्ता है और इसे उस ईमेल पते और पासवर्ड के साथ साइन इन करके एक्सेस किया जाता है जिसका उपयोग आपने खाता बनाने के लिए किया था।

ध्यान दें कि एक नया व्यवस्थापक उपयोगकर्ता के पास रूट उपयोगकर्ता की तुलना में कम अनुमतियाँ होंगी।

सुरक्षा के दृष्टिकोण से, अन्य उपयोगकर्ताओं को बनाना और इस उपयोगकर्ता का उपयोग करने से बचना अनुशंसित है।

IAM उपयोगकर्ता

एक IAM उपयोगकर्ता एक इकाई है जिसे आप AWS में उस व्यक्ति या एप्लिकेशन का प्रतिनिधित्व करने के लिए बनाते हैं जो इसका उपयोग AWS के साथ बातचीत करने के लिए करता है। AWS में एक उपयोगकर्ता का नाम और क्रेडेंशियल्स (पासवर्ड और अधिकतम दो एक्सेस कुंजी) होते हैं।

जब आप एक IAM उपयोगकर्ता बनाते हैं, तो आप इसे अनुमतियाँ प्रदान करते हैं, जिससे यह एक उपयोगकर्ता समूह का सदस्य बनता है जिसमें उपयुक्त अनुमति नीतियाँ संलग्न होती हैं (अनुशंसित), या प्रत्यक्ष रूप से नीतियाँ उपयोगकर्ता से संलग्न करके।

उपयोगकर्ताओं के पास कंसोल के माध्यम से लॉगिन करने के लिए MFA सक्षम हो सकता है। MFA सक्षम उपयोगकर्ताओं के API टोकन MFA द्वारा सुरक्षित नहीं होते हैं। यदि आप MFA का उपयोग करके उपयोगकर्ताओं की API कुंजियों की पहुंच को प्रतिबंधित करना चाहते हैं तो आपको नीति में यह इंगित करना होगा कि कुछ क्रियाएँ करने के लिए MFA की आवश्यकता है (उदाहरण यहाँ)।

CLI

• एक्सेस कुंजी आईडी: 20 यादृच्छिक अपरकेस अल्फ़ान्यूमेरिक वर्ण जैसे AKHDNAPO86BSHKDIRYT
• गुप्त एक्सेस कुंजी आईडी: 40 यादृच्छिक अपर और लोअरकेस वर्ण: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (खोई हुई गुप्त एक्सेस कुंजी आईडी को पुनः प्राप्त करना संभव नहीं है)।

जब भी आपको एक्सेस कुंजी बदलने की आवश्यकता हो तो आपको इस प्रक्रिया का पालन करना चाहिए:
&#xNAN;Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key

MFA - मल्टी फैक्टर प्रमाणीकरण

यह आपके मौजूदा तरीकों के अलावा प्रमाणीकरण के लिए एक अतिरिक्त कारक बनाने के लिए उपयोग किया जाता है, जैसे पासवर्ड, इस प्रकार, प्रमाणीकरण का एक मल्टी-फैक्टर स्तर बनाना।
आप एक नि:शुल्क वर्चुअल एप्लिकेशन या एक भौतिक उपकरण का उपयोग कर सकते हैं। आप AWS में MFA सक्रिय करने के लिए मुफ्त में गूगल प्रमाणीकरण जैसे ऐप्स का उपयोग कर सकते हैं।

MFA शर्तों वाली नीतियाँ निम्नलिखित पर संलग्न की जा सकती हैं:

• एक IAM उपयोगकर्ता या समूह
• एक संसाधन जैसे Amazon S3 बकेट, Amazon SQS कतार, या Amazon SNS विषय
• एक IAM भूमिका की ट्रस्ट नीति जिसे एक उपयोगकर्ता द्वारा ग्रहण किया जा सकता है

यदि आप CLI के माध्यम से एक संसाधन तक पहुँच प्राप्त करना चाहते हैं जो MFA की जांच करता है तो आपको GetSessionToken कॉल करने की आवश्यकता है। यह आपको MFA के बारे में जानकारी के साथ एक टोकन देगा।
ध्यान दें कि AssumeRole क्रेडेंशियल्स में यह जानकारी नहीं होती है।

aws sts get-session-token --serial-number <arn_device> --token-code <code>

जैसा कि यहां बताया गया है, ऐसे कई अलग-अलग मामले हैं जहां MFA का उपयोग नहीं किया जा सकता।

IAM उपयोगकर्ता समूह

एक IAM उपयोगकर्ता समूह एक ऐसा तरीका है जिससे एक समय में कई उपयोगकर्ताओं के लिए नीतियों को जोड़ना आसान हो जाता है, जिससे उन उपयोगकर्ताओं के लिए अनुमतियों का प्रबंधन करना आसान हो जाता है। भूमिकाएँ और समूह समूह का हिस्सा नहीं हो सकते।

आप एक पहचान-आधारित नीति को एक उपयोगकर्ता समूह से जोड़ सकते हैं ताकि उपयोगकर्ता समूह में सभी उपयोगकर्ताओं को नीति की अनुमतियाँ प्राप्त हों। आप एक उपयोगकर्ता समूह को Principal के रूप में नीति (जैसे संसाधन-आधारित नीति) में पहचान नहीं सकते क्योंकि समूह अनुमतियों से संबंधित होते हैं, प्रमाणीकरण से नहीं, और प्रिंसिपल प्रमाणीकरण किए गए IAM संस्थाएँ होती हैं।

उपयोगकर्ता समूहों की कुछ महत्वपूर्ण विशेषताएँ हैं:

• एक उपयोगकर्ता समूह में कई उपयोगकर्ता हो सकते हैं, और एक उपयोगकर्ता कई समूहों का भाग हो सकता है।
• उपयोगकर्ता समूहों को नेस्ट नहीं किया जा सकता; वे केवल उपयोगकर्ताओं को शामिल कर सकते हैं, अन्य उपयोगकर्ता समूहों को नहीं।
• AWS खाते में सभी उपयोगकर्ताओं को स्वचालित रूप से शामिल करने वाला कोई डिफ़ॉल्ट उपयोगकर्ता समूह नहीं है। यदि आप ऐसा उपयोगकर्ता समूह रखना चाहते हैं, तो आपको इसे बनाना होगा और प्रत्येक नए उपयोगकर्ता को इसमें असाइन करना होगा।
• AWS खाते में IAM संसाधनों की संख्या और आकार, जैसे समूहों की संख्या, और एक उपयोगकर्ता जिस समूह का सदस्य हो सकता है, सीमित हैं। अधिक जानकारी के लिए, IAM और AWS STS कोटा देखें।

IAM भूमिकाएँ

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

एक IAM भूमिका में दो प्रकार की नीतियाँ होती हैं: एक विश्वास नीति, जो खाली नहीं हो सकती, यह परिभाषित करती है कि कौन भूमिका को अपना सकता है, और एक अनुमति नीति, जो खाली नहीं हो सकती, यह परिभाषित करती है कि यह क्या एक्सेस कर सकता है।

AWS सुरक्षा टोकन सेवा (STS)

AWS सुरक्षा टोकन सेवा (STS) एक वेब सेवा है जो अस्थायी, सीमित-विशेषाधिकार प्रमाण-पत्रों के जारी करने की सुविधा प्रदान करती है। यह विशेष रूप से निम्नलिखित के लिए तैयार की गई है:

IAM में अस्थायी प्रमाण-पत्र

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

नीतियाँ

नीति अनुमतियाँ

अनुमतियों को असाइन करने के लिए उपयोग की जाती हैं। 2 प्रकार हैं:

• AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-कॉन्फ़िगर की गई)
• ग्राहक प्रबंधित नीतियाँ: आपके द्वारा कॉन्फ़िगर की गई। आप AWS प्रबंधित नीतियों के आधार पर नीतियाँ बना सकते हैं (उनमें से एक को संशोधित करके और अपनी खुद की बनाकर), नीति जनरेटर का उपयोग करके (एक GUI दृश्य जो आपको अनुमतियाँ देने और अस्वीकार करने में मदद करता है) या अपनी खुद की लिखकर।

डिफ़ॉल्ट रूप से पहुँच अस्वीकृत है, यदि एक स्पष्ट भूमिका निर्दिष्ट की गई है तो पहुँच दी जाएगी।
यदि एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा, AWS खाते की रूट सुरक्षा प्रमाण-पत्रों का उपयोग करने वाले अनुरोधों को छोड़कर (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

वैश्विक फ़ील्ड जो किसी भी सेवा में शर्तों के लिए उपयोग की जा सकती हैं, यहाँ दस्तावेज़ित हैं.
विशिष्ट फ़ील्ड जो सेवा के अनुसार शर्तों के लिए उपयोग की जा सकती हैं, यहाँ दस्तावेज़ित हैं.

इनलाइन नीतियाँ

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

संसाधन बाल्टी नीतियाँ

ये नीतियाँ हैं जो संसाधनों में परिभाषित की जा सकती हैं। AWS के सभी संसाधन उनका समर्थन नहीं करते।

यदि किसी प्रमुख के पास उन पर स्पष्ट अस्वीकृति नहीं है, और एक संसाधन नीति उन्हें पहुँच प्रदान करती है, तो उन्हें अनुमति दी जाती है।

IAM सीमाएँ

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

एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों के स्तर को इंगित करती है। तो, भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो, यदि सीमा इंगित करती है कि वह केवल S· बाल्टियों को पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।

यह, SCPs और कम से कम विशेषाधिकार सिद्धांत का पालन करना उन तरीकों में से हैं जिनसे यह नियंत्रित किया जा सकता है कि उपयोगकर्ताओं के पास उनकी आवश्यकताओं से अधिक अनुमतियाँ नहीं हैं।

सत्र नीतियाँ

एक सत्र नीति एक नीति है जो तब सेट की जाती है जब किसी भूमिका को अपनाया जाता है। यह उस सत्र के लिए एक IAM सीमा की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है (अधिकतम अनुमतियाँ वे होती हैं जो भूमिका के पास होती हैं)।

यह सुरक्षा उपायों के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका को अपनाने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

नोट करें कि डिफ़ॉल्ट रूप से AWS सत्रों में सत्र नीतियाँ जोड़ सकता है जो तीसरे कारणों के कारण उत्पन्न होने वाले हैं। उदाहरण के लिए, अप्रमाणित कॉग्निटो अनुमोदित भूमिकाओं में डिफ़ॉल्ट रूप से (सुधारित प्रमाणीकरण का उपयोग करते हुए), AWS सत्र नीति के साथ सत्र क्रेडेंशियल्स उत्पन्न करेगा जो उस सत्र को पहुँचने वाली सेवाओं को सीमित करता है निम्नलिखित सूची।

इसलिए, यदि किसी बिंदु पर आप त्रुटि का सामना करते हैं "... क्योंकि कोई सत्र नीति अनुमति नहीं देती है ...", और भूमिका को क्रिया करने की अनुमति है, तो इसका मतलब है कि एक सत्र नीति इसे रोक रही है।

पहचान संघ

पहचान संघ AWS के लिए बाहरी पहचान प्रदाताओं से उपयोगकर्ताओं को सुरक्षित रूप से AWS संसाधनों तक पहुँचने की अनुमति देता है बिना AWS उपयोगकर्ता क्रेडेंशियल्स को एक मान्य IAM उपयोगकर्ता खाते से प्रदान किए।
एक पहचान प्रदाता का उदाहरण आपके अपने कॉर्पोरेट Microsoft Active Directory (द्वारा SAML) या OpenID सेवाएँ (जैसे Google) हो सकता है। संघीय पहुँच फिर उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।

इस विश्वास को कॉन्फ़िगर करने के लिए, एक IAM पहचान प्रदाता उत्पन्न किया जाता है (SAML या OAuth) जो अन्य प्लेटफ़ॉर्म पर विश्वास करेगा। फिर, कम से कम एक IAM भूमिका (विश्वास करने वाली) पहचान प्रदाता को सौंपा जाता है। यदि विश्वसनीय प्लेटफ़ॉर्म से कोई उपयोगकर्ता AWS तक पहुँचता है, तो वह उल्लेखित भूमिका के रूप में पहुँच रहा होगा।

हालांकि, आप आमतौर पर उपयोगकर्ता के समूह के आधार पर एक अलग भूमिका देना चाहेंगे तीसरे पक्ष के प्लेटफ़ॉर्म में। फिर, कई IAM भूमिकाएँ तीसरे पक्ष के पहचान प्रदाता पर विश्वास कर सकती हैं और तीसरा पक्ष का प्लेटफ़ॉर्म उपयोगकर्ताओं को एक भूमिका या दूसरी भूमिका को मानने की अनुमति देगा।

IAM पहचान केंद्र

AWS IAM पहचान केंद्र (AWS सिंगल साइन-ऑन का उत्तराधिकारी) AWS पहचान और पहुँच प्रबंधन (IAM) की क्षमताओं का विस्तार करता है ताकि उपयोगकर्ताओं और उनके AWS खातों और क्लाउड अनुप्रयोगों तक पहुँच के प्रशासन को एक केंद्रीय स्थान में लाया जा सके।

लॉगिन डोमेन कुछ इस तरह होगा <user_input>.awsapps.com।

उपयोगकर्ताओं को लॉगिन करने के लिए, 3 पहचान स्रोतों का उपयोग किया जा सकता है:

• पहचान केंद्र निर्देशिका: नियमित AWS उपयोगकर्ता
• सक्रिय निर्देशिका: विभिन्न कनेक्टर्स का समर्थन करता है
• बाहरी पहचान प्रदाता: सभी उपयोगकर्ता और समूह एक बाहरी पहचान प्रदाता (IdP) से आते हैं

पहचान केंद्र निर्देशिका के सबसे सरल मामले में, पहचान केंद्र के पास उपयोगकर्ताओं और समूहों की एक सूची होगी और वह उन्हें संगठन के किसी भी खाते के लिए नीतियाँ सौंपने में सक्षम होगा।

एक पहचान केंद्र उपयोगकर्ता/समूह को एक खाते तक पहुँच देने के लिए एक SAML पहचान प्रदाता जो पहचान केंद्र पर विश्वास करता है, बनाया जाएगा, और एक भूमिका जो निर्दिष्ट नीतियों के साथ पहचान प्रदाता पर विश्वास करती है, गंतव्य खाते में बनाई जाएगी।

AwsSSOInlinePolicy

यह संभव है कि IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमतियाँ दी जाएं। उन खातों में बनाई गई भूमिकाएँ जिन्हें AWS पहचान केंद्र में इनलाइन नीतियाँ दी गई हैं इन अनुमतियों को AwsSSOInlinePolicy नामक एक इनलाइन नीति में रखेंगे।

इसलिए, भले ही आप AwsSSOInlinePolicy नामक एक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह मतलब नहीं है कि इसकी समान अनुमतियाँ हैं।

क्रॉस खाता विश्वास और भूमिकाएँ

एक उपयोगकर्ता (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, दूसरे उपयोगकर्ता (विश्वासित) को अपने खाते तक पहुँचने की अनुमति दे सकता है लेकिन केवल नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके हैं और एक तीसरे पक्ष के AWS खाते के बीच।
यह अनुशंसा की जाती है कि विश्वासित उपयोगकर्ता को निर्दिष्ट करें और कुछ सामान्य चीज़ें न डालें क्योंकि यदि नहीं, तो अन्य प्रमाणित उपयोगकर्ता जैसे संघीय उपयोगकर्ता भी इस विश्वास का दुरुपयोग कर सकेंगे।

AWS सरल AD

समर्थित नहीं:

• विश्वास संबंध
• AD प्रशासन केंद्र
• पूर्ण PS API समर्थन
• AD रीसाइक्ल बिन
• समूह प्रबंधित सेवा खाते
• स्कीमा एक्सटेंशन
• OS या उदाहरणों तक सीधी पहुँच नहीं

वेब संघ या OpenID प्रमाणीकरण

ऐप अस्थायी क्रेडेंशियल बनाने के लिए AssumeRoleWithWebIdentity का उपयोग करता है। हालाँकि, यह AWS कंसोल तक पहुँच प्रदान नहीं करता है, केवल AWS के भीतर संसाधनों तक पहुँच प्रदान करता है।

अन्य IAM विकल्प

• आप पासवर्ड नीति सेटिंग विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताओं को सेट कर सकते हैं।
• आप "क्रेडेंशियल रिपोर्ट" डाउनलोड कर सकते हैं जिसमें वर्तमान क्रेडेंशियल्स के बारे में जानकारी होती है (जैसे उपयोगकर्ता निर्माण समय, क्या पासवर्ड सक्षम है...)। आप एक क्रेडेंशियल रिपोर्ट हर चार घंटे में एक बार उत्पन्न कर सकते हैं।

AWS पहचान और पहुँच प्रबंधन (IAM) AWS के सभी क्षेत्रों में बारीक पहुँच नियंत्रण प्रदान करता है। IAM के साथ, आप निर्दिष्ट कर सकते हैं कौन कौन सी सेवाओं और संसाधनों तक पहुँच सकता है, और किन शर्तों के तहत। IAM नीतियों के साथ, आप अपनी कार्यबल और प्रणालियों के लिए अनुमतियों का प्रबंधन करते हैं ताकि कम से कम विशेषाधिकार अनुमतियाँ सुनिश्चित की जा सकें।

IAM ID उपसर्ग

इस पृष्ठ पर आप कुंजियों के उपसर्गों को उनकी प्रकृति के आधार पर पा सकते हैं:

ABIA	AWS STS सेवा धारक टोकन
ACCA	संदर्भ-विशिष्ट क्रेडेंशियल
AGPA	उपयोगकर्ता समूह
AIDA	IAM उपयोगकर्ता
AIPA	अमेज़न EC2 उदाहरण प्रोफ़ाइल
AKIA	पहुँच कुंजी
ANPA	प्रबंधित नीति
ANVA	प्रबंधित नीति में संस्करण
APKA	सार्वजनिक कुंजी
AROA	भूमिका
ASCA	प्रमाणपत्र
ASIA	अस्थायी (AWS STS) पहुँच कुंजी आईडी इस उपसर्ग का उपयोग करती हैं, लेकिन केवल गुप्त पहुँच कुंजी और सत्र टोकन के संयोजन में अद्वितीय होती हैं।

खातों का ऑडिट करने के लिए अनुशंसित अनुमतियाँ

निम्नलिखित विशेषाधिकार विभिन्न मेटाडेटा के पढ़ने की पहुँच प्रदान करते हैं:

• arn:aws:iam::aws:policy/SecurityAudit
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
• codebuild:ListProjects
• config:Describe*
• cloudformation:ListStacks
• logs:DescribeMetricFilters
• directconnect:DescribeConnections
• dynamodb:ListTables

विविध

CLI प्रमाणीकरण

एक नियमित उपयोगकर्ता को CLI के माध्यम से AWS में प्रमाणीकरण करने के लिए आपको स्थानीय क्रेडेंशियल्स की आवश्यकता होती है। डिफ़ॉल्ट रूप से आप उन्हें हाथ से ~/.aws/credentials में कॉन्फ़िगर कर सकते हैं या चलाकर aws configure।
उस फ़ाइल में आपके पास एक से अधिक प्रोफ़ाइल हो सकती हैं, यदि कोई प्रोफ़ाइल निर्दिष्ट नहीं की गई है तो aws cli का उपयोग करते समय, उस फ़ाइल में [default] नामक प्रोफ़ाइल का उपयोग किया जाएगा।
एक से अधिक प्रोफ़ाइल के साथ क्रेडेंशियल्स फ़ाइल का उदाहरण:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
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/config फ़ाइल का उपयोग कर सकते हैं यह इंगित करने के लिए कि कौन सी भूमिकाएँ ग्रहण करनी हैं, और फिर सामान्य रूप से --profile पैरामीटर का उपयोग करें (भूमिका ग्रहण करना उपयोगकर्ता के लिए पारदर्शी तरीके से किया जाएगा)।
एक कॉन्फ़िग फ़ाइल का उदाहरण:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

इस कॉन्फ़िग फ़ाइल के साथ आप aws cli का उपयोग कर सकते हैं जैसे:

aws --profile acc2 ...

यदि आप इसके लिए कुछ समान खोज रहे हैं लेकिन ब्राउज़र के लिए, तो आप विस्तार AWS Extend Switch Roles देख सकते हैं।

संदर्भ

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
• https://aws.amazon.com/iam/
• https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

{{#include ../../../banners/hacktricks-training.md}}