Hindi - Ht Cloud

AWS - Basic Information

AWS हैकिंग सीखें शुरुआत से लेकर एक्सपर्ट तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

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

खाते

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

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

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

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

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

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

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

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

  • संगठन के भीतर इकाइयों (रूट्स, OUs, या खाते) पर नीतियां लागू करें

  • संगठन के सभी खातों में सेवा कार्यक्षमता प्रदान करने के लिए समर्थित 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 को कॉन्फ़िगर करता है (मास्टर खाते को ब्लॉक नहीं किया जा सकता)।

ध्यान दें कि 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 मानक: aws

  • AWS चीन: aws-cn

  • AWS अमेरिका सार्वजनिक इंटरनेट (GovCloud): aws-us-gov

  • AWS गुप्त (US वर्गीकृत): 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

  • पहुँच कुंजी ID: 20 यादृच्छिक अपरकेस अल्फ़ान्यूमेरिक अक्षर जैसे AKHDNAPO86BSHKDIRYT

  • गुप्त पहुँच कुंजी ID: 40 यादृच्छिक अपर और लोअरकेस अक्षर: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (खोई हुई गुप्त पहुँच कुंजी ID को पुनः प्राप्त करना संभव नहीं है)।

जब भी आपको पहुँच कुंजी बदलने की आवश्यकता हो तो आपको यह प्रक्रिया अनुसरण करनी चाहिए: नई पहुँच कुंजी बनाएँ -> सिस्टम/एप्लिकेशन में नई कुंजी लागू करें -> मूल को निष्क्रिय के रूप में चिह्नित करें -> नई पहुँच कुंजी काम कर रही है इसकी जाँच और सत्यापन करें -> पुरानी पहुँच कुंजी हटा दें

MFA - बहु कारक प्रमाणीकरण

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

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>

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

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

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

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

  • एक उपयोगकर्ता समूह में कई उपयोगकर्ता हो सकते हैं, और एक उपयोगकर्ता कई समूहों का हिस्सा हो सकता है।

  • उपयोगकर्ता समूहों को नेस्टेड नहीं किया जा सकता; वे केवल उपयोगकर्ताओं को ही समाविष्ट कर सकते हैं, अन्य उपयोगकर्ता समूहों को नहीं।

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

  • AWS खाते में IAM संसाधनों की संख्या और आकार, जैसे कि समूहों की संख्या, और एक उपयोगकर्ता के सदस्य होने वाले समूहों की संख्या, सीमित हैं। अधिक जानकारी के लिए, IAM और AWS STS कोटा देखें।

IAM रोल्स

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

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

AWS Security Token Service (STS)

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

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

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

नीतियाँ

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

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

  • AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-कॉन्फ़िगर)

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

डिफ़ॉल्ट एक्सेस इनकार किया जाता है, एक्सेस तब दिया जाएगा जब एक स्पष्ट रोल निर्दिष्ट किया गया हो। यदि एकल "इनकार" मौजूद है, तो यह "अनुमति" को ओवरराइड कर देगा, 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 बाउंड्रीज का उपयोग उन अनुमतियों को सीमित करने के लिए किया जा सकता है जिन तक एक यूजर या भूमिका को पहुँच होनी चाहिए। इस तरह, यहां तक कि अगर एक अलग सेट की अनुमतियाँ यूजर को अलग पॉलिसी द्वारा दी जाती हैं, तो भी ऑपरेशन असफल हो जाएगा अगर वह उनका उपयोग करने की कोशिश करता है।

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

यह, 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 कहा जाता है, तो इसका मतलब यह नहीं है कि इसमें समान अनुमतियाँ हैं।

क्रॉस अकाउंट ट्रस्ट्स और भूमिकाएँ

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

AWS सिंपल AD

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

  • ट्रस्ट संबंध

  • AD प्रशासन केंद्र

  • पूर्ण PS API समर्थन

  • AD रीसायकल बिन

  • समूह प्रबंधित सेवा खाते

  • स्कीमा एक्सटेंशन

  • ओएस या इंस्टेंसेज तक सीधी पहुँच नहीं

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

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

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

[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 ...

यदि आप browser के लिए कुछ similar ढूंढ रहे हैं, तो आप extension AWS Extend Switch Roles की जाँच कर सकते हैं।

संदर्भ

AWS हैकिंग सीखें शुरुआत से लेकर एक्सपर्ट तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

  • यदि आप HackTricks में अपनी कंपनी का विज्ञापन देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं, तो SUBSCRIPTION PLANS देखें!

  • official PEASS & HackTricks swag प्राप्त करें।

  • The PEASS Family की खोज करें, हमारा एक्सक्लूसिव NFTs संग्रह।

  • 💬 Discord group में शामिल हों या telegram group में या Twitter पर 🐦 @carlospolopm को फॉलो करें।

  • HackTricks के github repos और HackTricks Cloud में PRs सबमिट करके अपनी हैकिंग ट्रिक्स शेयर करें।

PreviousAWS PentestingNextAWS - Federation Abuse

Last updated