AWS - Basic Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AWS में एक root account है, जो आपकी organization के सभी खातों के लिए parent container है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप अलग-अलग AWS बुनियादी ढाँचे को अलग करने के लिए अन्य खाते बना सकते हैं।
यह सुरक्षा के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा (जब तक कि पुल विशेष रूप से बनाए नहीं गए हों), इसलिए इस तरह आप तैनाती के बीच सीमाएँ बना सकते हैं।
इसलिए, एक संगठन में दो प्रकार के खाते होते हैं (हम AWS खातों की बात कर रहे हैं, उपयोगकर्ता खातों की नहीं): एक एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।
प्रबंधन खाता (root account) वह खाता है जिसका उपयोग आप संगठन बनाने के लिए करते हैं। संगठन के प्रबंधन खाते से, आप निम्नलिखित कर सकते हैं:
संगठन में खाते बनाना
संगठन में अन्य मौजूदा खातों को आमंत्रित करना
संगठन से खातों को हटाना
आमंत्रण प्रबंधित करना
संगठन के भीतर संस्थाओं (roots, OUs, या खातों) पर नीतियाँ लागू करना
संगठन में सभी खातों के बीच सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करना।
इस root account/organization को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके root उपयोगकर्ता के रूप में लॉगिन करना संभव है।
प्रबंधन खाते की payer account की जिम्मेदारियाँ होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप संगठन के प्रबंधन खाते को नहीं बदल सकते।
सदस्य खाते संगठन में सभी अन्य खातों का निर्माण करते हैं। एक खाता एक समय में केवल एक संगठन का सदस्य हो सकता है। आप एक खाते पर नियंत्रण लागू करने के लिए एक नीति संलग्न कर सकते हैं।
सदस्य खातों को एक मान्य ईमेल पता का उपयोग करना चाहिए और एक नाम हो सकता है, सामान्यतः वे बिलिंग का प्रबंधन नहीं कर पाएंगे (लेकिन उन्हें इसके लिए पहुँच दी जा सकती है)।
खातों को Organization Units (OU) में समूहित किया जा सकता है। इस तरह, आप Organization Unit के लिए policies बना सकते हैं जो सभी बच्चों के खातों पर लागू होंगी। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।
एक सेवा नियंत्रण नीति (SCP) एक नीति है जो उन सेवाओं और क्रियाओं को निर्दिष्ट करती है जिन्हें उपयोगकर्ता और भूमिकाएँ उन खातों में उपयोग कर सकते हैं जिन पर SCP प्रभाव डालती है। SCPs IAM अनुमतियों की नीतियों के समान हैं, सिवाय इसके कि वे कोई अनुमतियाँ नहीं देतीं। इसके बजाय, SCPs एक संगठन, संगठनात्मक इकाई (OU), या खाते के लिए अधिकतम अनुमतियों को निर्दिष्ट करती हैं। जब आप अपने संगठन की जड़ या एक OU पर SCP संलग्न करते हैं, तो SCP सदस्य खातों में संस्थाओं के लिए अनुमतियों को सीमित करती है।
यह एकमात्र तरीका है कि रूट उपयोगकर्ता को कुछ करने से रोका जा सकता है। उदाहरण के लिए, इसका उपयोग उपयोगकर्ताओं को CloudTrail को निष्क्रिय करने या बैकअप हटाने से रोकने के लिए किया जा सकता है। इससे बचने का एकमात्र तरीका यह है कि मास्टर खाता भी समझौता किया जाए जो SCPs को कॉन्फ़िगर करता है (मास्टर खाता को अवरुद्ध नहीं किया जा सकता)।
ध्यान दें कि SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि s3:GetObject को अस्वीकार करने वाला SCP आपके खाते में एक सार्वजनिक S3 बकेट तक पहुँचने से लोगों को नहीं रोकेगा।
SCP उदाहरण:
रूट खाते को पूरी तरह से अस्वीकार करें
केवल विशिष्ट क्षेत्रों की अनुमति दें
केवल श्वेत-पत्रित सेवाओं की अनुमति दें
GuardDuty, CloudTrail, और S3 सार्वजनिक ब्लॉक एक्सेस को निष्क्रिय करने से अस्वीकार करें
सुरक्षा/घटना प्रतिक्रिया भूमिकाओं को हटाने या संशोधित करने से अस्वीकार करें।
बैकअप को हटाने से अस्वीकार करें।
IAM उपयोगकर्ताओं और एक्सेस कुंजियों को बनाने से अस्वीकार करें
JSON उदाहरण https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html में खोजें।
Amazon Resource Name वह विशिष्ट नाम है जो AWS के अंदर हर संसाधन का होता है, यह इस प्रकार से बना होता है:
Note that there are 4 partitions in AWS but only 3 ways to call them:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM वह सेवा है जो आपको अपने AWS खाते के भीतर प्रमाणीकरण, अधिकार और पहुँच नियंत्रण प्रबंधित करने की अनुमति देती है।
प्रमाणीकरण - एक पहचान को परिभाषित करने और उस पहचान के सत्यापन की प्रक्रिया। इस प्रक्रिया को पहचान और सत्यापन में विभाजित किया जा सकता है।
अधिकार - यह निर्धारित करता है कि एक पहचान एक प्रणाली के भीतर क्या पहुँच सकती है जब इसे प्रमाणित किया गया हो।
पहुँच नियंत्रण - सुरक्षित संसाधन तक पहुँच कैसे दी जाती है, इसकी विधि और प्रक्रिया।
IAM को इसकी क्षमता द्वारा परिभाषित किया जा सकता है कि यह आपके AWS खाते के भीतर पहचान के प्रमाणीकरण, अधिकार और पहुँच नियंत्रण तंत्रों का प्रबंधन, नियंत्रण और शासन कैसे करता है।
जब आप पहली बार एक Amazon Web Services (AWS) खाता बनाते हैं, तो आप एक सिंगल साइन-इन पहचान के साथ शुरू करते हैं जिसके पास खाते में सभी AWS सेवाओं और संसाधनों तक पूर्ण पहुँच होती है। यह AWS खाता रूट उपयोगकर्ता है और इसे उस ईमेल पते और पासवर्ड के साथ साइन इन करके एक्सेस किया जाता है जिसका उपयोग आपने खाता बनाने के लिए किया था।
ध्यान दें कि एक नया व्यवस्थापक उपयोगकर्ता के पास रूट उपयोगकर्ता की तुलना में कम अनुमतियाँ होंगी।
सुरक्षा के दृष्टिकोण से, अन्य उपयोगकर्ताओं को बनाना और इस एक का उपयोग करने से बचना अनुशंसित है।
एक IAM उपयोगकर्ता एक इकाई है जिसे आप AWS में उस व्यक्ति या एप्लिकेशन का प्रतिनिधित्व करने के लिए बनाते हैं जो इसका उपयोग AWS के साथ इंटरैक्ट करने के लिए करता है। AWS में एक उपयोगकर्ता का नाम और क्रेडेंशियल्स (पासवर्ड और दो तक पहुँच कुंजी) होते हैं।
जब आप एक IAM उपयोगकर्ता बनाते हैं, तो आप इसे अनुमतियाँ प्रदान करते हैं, इसे एक उपयोगकर्ता समूह का सदस्य बनाकर जो उपयुक्त अनुमति नीतियों से जुड़ा होता है (अनुशंसित), या सीधे उपयोगकर्ता पर नीतियाँ संलग्न करके।
उपयोगकर्ताओं के पास कंसोल के माध्यम से लॉगिन करने के लिए MFA सक्षम हो सकता है। MFA सक्षम उपयोगकर्ताओं के API टोकन MFA द्वारा सुरक्षित नहीं होते हैं। यदि आप MFA का उपयोग करके उपयोगकर्ताओं की API कुंजी की पहुँच को प्रतिबंधित करना चाहते हैं तो आपको नीति में यह इंगित करना होगा कि कुछ क्रियाएँ करने के लिए MFA की आवश्यकता है (उदाहरण यहाँ)।
एक्सेस कुंजी आईडी: 20 यादृच्छिक अपरकेस अल्फ़ान्यूमेरिक वर्ण जैसे AKHDNAPO86BSHKDIRYT
गुप्त एक्सेस कुंजी आईडी: 40 यादृच्छिक अपर और लोअरकेस वर्ण: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (खोई हुई गुप्त एक्सेस कुंजी आईडी को पुनः प्राप्त करना संभव नहीं है)।
जब भी आपको एक्सेस कुंजी बदलने की आवश्यकता हो तो आपको इस प्रक्रिया का पालन करना चाहिए: एक नई एक्सेस कुंजी बनाएं -> सिस्टम/एप्लिकेशन पर नई कुंजी लागू करें -> मूल को निष्क्रिय के रूप में चिह्नित करें -> परीक्षण करें और सत्यापित करें कि नई एक्सेस कुंजी काम कर रही है -> पुरानी एक्सेस कुंजी हटाएं
यह आपके मौजूदा तरीकों, जैसे पासवर्ड, के अतिरिक्त प्रमाणीकरण के लिए एक अतिरिक्त कारक बनाने के लिए उपयोग किया जाता है, इस प्रकार, प्रमाणीकरण का एक मल्टी-फैक्टर स्तर बनाता है। आप एक नि:शुल्क वर्चुअल एप्लिकेशन या एक भौतिक उपकरण का उपयोग कर सकते हैं। आप AWS में MFA सक्रिय करने के लिए मुफ्त में गूगल प्रमाणीकरण जैसे ऐप्स का उपयोग कर सकते हैं।
MFA शर्तों वाली नीतियाँ निम्नलिखित पर संलग्न की जा सकती हैं:
एक IAM उपयोगकर्ता या समूह
एक संसाधन जैसे Amazon S3 बकेट, Amazon SQS कतार, या Amazon SNS विषय
एक IAM भूमिका की ट्रस्ट नीति जिसे एक उपयोगकर्ता द्वारा ग्रहण किया जा सकता है
यदि आप CLI के माध्यम से पहुँच करना चाहते हैं एक संसाधन जो MFA की जाँच करता है तो आपको GetSessionToken कॉल करना होगा। यह आपको MFA के बारे में जानकारी के साथ एक टोकन देगा।
ध्यान दें कि AssumeRole क्रेडेंशियल्स में यह जानकारी नहीं होती।
As यहां कहा गया है, ऐसे कई अलग-अलग मामले हैं जहां MFA का उपयोग नहीं किया जा सकता।
एक IAM उपयोगकर्ता समूह एक ऐसा तरीका है जिससे एक समय में कई उपयोगकर्ताओं के लिए नीतियों को संलग्न किया जा सकता है, जिससे उन उपयोगकर्ताओं के लिए अनुमतियों का प्रबंधन करना आसान हो सकता है। भूमिकाएँ और समूह समूह का हिस्सा नहीं हो सकते।
आप एक पहचान-आधारित नीति को एक उपयोगकर्ता समूह में संलग्न कर सकते हैं ताकि उपयोगकर्ता समूह में सभी उपयोगकर्ताओं को नीति की अनुमतियाँ प्राप्त हों। आप एक उपयोगकर्ता समूह को एक Principal के रूप में नीति (जैसे कि संसाधन-आधारित नीति) में पहचान नहीं सकते क्योंकि समूह अनुमतियों से संबंधित होते हैं, प्रमाणीकरण से नहीं, और प्रिंसिपल प्रमाणीकरण किए गए IAM संस्थाएँ हैं।
यहां उपयोगकर्ता समूह की कुछ महत्वपूर्ण विशेषताएँ हैं:
एक उपयोगकर्ता समूह कई उपयोगकर्ताओं को शामिल कर सकता है, और एक उपयोगकर्ता कई समूहों का भाग हो सकता है।
उपयोगकर्ता समूहों को नेस्ट नहीं किया जा सकता; वे केवल उपयोगकर्ताओं को शामिल कर सकते हैं, अन्य उपयोगकर्ता समूहों को नहीं।
AWS खाते में सभी उपयोगकर्ताओं को स्वचालित रूप से शामिल करने वाला कोई डिफ़ॉल्ट उपयोगकर्ता समूह नहीं है। यदि आप ऐसा उपयोगकर्ता समूह चाहते हैं, तो आपको इसे बनाना होगा और प्रत्येक नए उपयोगकर्ता को इसमें असाइन करना होगा।
AWS खाते में IAM संसाधनों की संख्या और आकार, जैसे समूहों की संख्या, और एक उपयोगकर्ता जिस समूह का सदस्य हो सकता है, सीमित हैं। अधिक जानकारी के लिए, IAM और AWS STS कोटा देखें।
एक IAM भूमिका एक उपयोगकर्ता के समान है, क्योंकि यह एक पहचान है जिसमें अनुमति नीतियाँ होती हैं जो यह निर्धारित करती हैं कि यह AWS में क्या कर सकता है और क्या नहीं। हालाँकि, एक भूमिका के साथ कोई प्रमाणपत्र (पासवर्ड या एक्सेस कुंजी) नहीं होता है। एक व्यक्ति के साथ विशेष रूप से जुड़ने के बजाय, एक भूमिका को किसी भी व्यक्ति द्वारा अपनाने के लिए डिज़ाइन किया गया है जिसे इसकी आवश्यकता है (और जिसके पास पर्याप्त अनुमतियाँ हैं)। एक IAM उपयोगकर्ता एक भूमिका को अस्थायी रूप से एक विशिष्ट कार्य के लिए विभिन्न अनुमतियाँ लेने के लिए अपना सकता है। एक भूमिका को एक संघीय उपयोगकर्ता को असाइन किया जा सकता है जो IAM के बजाय एक बाहरी पहचान प्रदाता का उपयोग करके साइन इन करता है।
एक IAM भूमिका में दो प्रकार की नीतियाँ होती हैं: एक विश्वास नीति, जो खाली नहीं हो सकती, यह परिभाषित करती है कि कौन भूमिका को अपना सकता है, और एक अनुमति नीति, जो खाली नहीं हो सकती, यह परिभाषित करती है कि यह क्या एक्सेस कर सकता है।
AWS सुरक्षा टोकन सेवा (STS) एक वेब सेवा है जो अस्थायी, सीमित-विशेषाधिकार प्रमाणपत्रों के जारी करने की सुविधा प्रदान करती है। यह विशेष रूप से निम्नलिखित के लिए तैयार की गई है:
अस्थायी प्रमाणपत्र मुख्य रूप से IAM भूमिकाओं के साथ उपयोग किए जाते हैं, लेकिन इसके अन्य उपयोग भी हैं। आप अस्थायी प्रमाणपत्रों के लिए अनुरोध कर सकते हैं जिनमें आपके मानक IAM उपयोगकर्ता की तुलना में अधिक सीमित अनुमतियों का सेट होता है। यह आपको अनुमत नहीं किए गए कार्यों को गलती से करने से रोकता है। अस्थायी प्रमाणपत्रों का एक लाभ यह है कि वे एक निर्धारित समय के बाद स्वचालित रूप से समाप्त हो जाते हैं। आपके पास यह नियंत्रित करने की क्षमता है कि प्रमाणपत्र कितने समय तक मान्य हैं।
अनुमतियों को असाइन करने के लिए उपयोग की जाती हैं। 2 प्रकार हैं:
AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-निर्धारित)
ग्राहक प्रबंधित नीतियाँ: आपके द्वारा कॉन्फ़िगर की गई। आप AWS प्रबंधित नीतियों के आधार पर नीतियाँ बना सकते हैं (उनमें से एक को संशोधित करके और अपनी खुद की बनाकर), नीति जनरेटर का उपयोग करके (एक GUI दृश्य जो आपको अनुमतियाँ देने और अस्वीकार करने में मदद करता है) या अपनी खुद की लिखकर।
डिफ़ॉल्ट रूप से पहुँच अस्वीकृत है, यदि एक स्पष्ट भूमिका निर्दिष्ट की गई है तो पहुँच दी जाएगी। यदि एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा, AWS खाते की रूट सुरक्षा प्रमाणपत्रों का उपयोग करने वाले अनुरोधों को छोड़कर (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
The global fields that can be used for conditions in any service are documented here. The specific fields that can be used for conditions per service are documented here.
इस प्रकार की नीतियाँ प्रत्यक्ष रूप से एक उपयोगकर्ता, समूह या भूमिका को असाइन की जाती हैं। फिर, वे नीतियों की सूची में नहीं दिखाई देती हैं क्योंकि कोई अन्य उनका उपयोग कर सकता है। Inline policies उपयोगी होती हैं यदि आप एक नीति और उस पहचान के बीच एक सख्त एक-से-एक संबंध बनाए रखना चाहते हैं जिस पर इसे लागू किया गया है। उदाहरण के लिए, आप यह सुनिश्चित करना चाहते हैं कि एक नीति में अनुमतियाँ अनजाने में किसी अन्य पहचान को असाइन नहीं की गई हैं। जब आप एक inline policy का उपयोग करते हैं, तो नीति में अनुमतियाँ अनजाने में गलत पहचान से नहीं जुड़ सकती हैं। इसके अलावा, जब आप AWS प्रबंधन कंसोल का उपयोग करके उस पहचान को हटाते हैं, तो पहचान में निहित नीतियाँ भी हटा दी जाती हैं। इसका कारण यह है कि वे प्रमुख इकाई का हिस्सा हैं।
ये नीतियाँ हैं जिन्हें संसाधनों में परिभाषित किया जा सकता है। AWS के सभी संसाधन उनका समर्थन नहीं करते हैं।
यदि एक प्रमुख के पास उन पर स्पष्ट अस्वीकृति नहीं है, और एक संसाधन नीति उन्हें पहुँच प्रदान करती है, तो उन्हें अनुमति दी जाती है।
IAM सीमाएँ एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने के लिए उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को विभिन्न नीति द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन विफल हो जाएगा।
एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो यह संकेत करती है कि उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों का स्तर क्या हो सकता है। इसलिए, भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो, यदि सीमा संकेत करती है कि वह केवल S· बकेट पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
यह, SCPs और कम से कम विशेषाधिकार सिद्धांत का पालन करना उन तरीकों में से हैं जिनसे यह नियंत्रित किया जा सकता है कि उपयोगकर्ताओं के पास उनकी आवश्यकता से अधिक अनुमतियाँ नहीं हैं।
एक सत्र नीति एक नीति है जो तब सेट की जाती है जब किसी भूमिका को किसी तरह से ग्रहण किया जाता है। यह उस सत्र के लिए एक IAM सीमा की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है (अधिकतम अनुमतियाँ वे होती हैं जो भूमिका के पास होती हैं)।
यह सुरक्षा उपायों के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका ग्रहण करने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
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 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.
इसलिए, यदि किसी बिंदु पर आप त्रुटि का सामना करते हैं "... क्योंकि कोई सत्र नीति अनुमति नहीं देती है ...", और भूमिका को कार्रवाई करने की अनुमति है, तो इसका कारण है कि एक सत्र नीति इसे रोक रही है।
Identity federation AWS के लिए बाहरी पहचान प्रदाताओं से उपयोगकर्ताओं को सुरक्षित रूप से AWS संसाधनों तक पहुँचने की अनुमति देती है बिना AWS उपयोगकर्ता क्रेडेंशियल्स को एक मान्य IAM उपयोगकर्ता खाते से प्रदान किए। एक पहचान प्रदाता का उदाहरण आपका अपना कॉर्पोरेट Microsoft Active Directory (द्वारा SAML) या OpenID सेवाएँ (जैसे Google) हो सकता है। फिर संघीय पहुँच उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।
इस विश्वास को कॉन्फ़िगर करने के लिए, एक IAM पहचान प्रदाता उत्पन्न किया जाता है (SAML या OAuth) जो अन्य प्लेटफ़ॉर्म पर विश्वास करेगा। फिर, कम से कम एक IAM भूमिका (विश्वास करने वाली) पहचान प्रदाता को सौंपा जाता है। यदि विश्वसनीय प्लेटफ़ॉर्म से एक उपयोगकर्ता AWS तक पहुँचता है, तो वह उल्लेखित भूमिका के रूप में पहुँच रहा होगा।
हालांकि, आप आमतौर पर उपयोगकर्ता के समूह के आधार पर एक अलग भूमिका देना चाहेंगे तीसरे पक्ष के प्लेटफ़ॉर्म में। फिर, कई IAM भूमिकाएँ तीसरे पक्ष के पहचान प्रदाता पर विश्वास कर सकती हैं और तीसरा पक्ष का प्लेटफ़ॉर्म उपयोगकर्ताओं को एक भूमिका या दूसरी भूमिका ग्रहण करने की अनुमति देगा।
AWS IAM Identity Center (AWS सिंगल साइन-ऑन का उत्तराधिकारी) AWS पहचान और पहुँच प्रबंधन (IAM) की क्षमताओं का विस्तार करता है ताकि उपयोगकर्ताओं और उनके AWS खातों और क्लाउड अनुप्रयोगों तक पहुँच के प्रशासन को एक केंद्रीय स्थान में लाया जा सके।
लॉगिन डोमेन कुछ इस तरह होगा <user_input>.awsapps.com।
उपयोगकर्ताओं को लॉगिन करने के लिए, 3 पहचान स्रोत हैं जिनका उपयोग किया जा सकता है:
पहचान केंद्र निर्देशिका: नियमित AWS उपयोगकर्ता
सक्रिय निर्देशिका: विभिन्न कनेक्टर्स का समर्थन करता है
बाहरी पहचान प्रदाता: सभी उपयोगकर्ता और समूह एक बाहरी पहचान प्रदाता (IdP) से आते हैं
पहचान केंद्र निर्देशिका के सबसे सरल मामले में, पहचान केंद्र के पास उपयोगकर्ताओं और समूहों की एक सूची होगी और वह उन्हें संगठन के किसी भी खाते के लिए नीतियाँ सौंपने में सक्षम होगा।
एक पहचान केंद्र उपयोगकर्ता/समूह को एक खाते तक पहुँच देने के लिए एक SAML पहचान प्रदाता जो पहचान केंद्र पर विश्वास करता है, बनाया जाएगा, और एक भूमिका जो निर्दिष्ट नीतियों के साथ पहचान प्रदाता पर विश्वास करती है, गंतव्य खाते में बनाई जाएगी।
यह संभव है कि IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमतियाँ दी जाएं। जिन भूमिकाओं को AWS पहचान केंद्र में इनलाइन नीतियाँ दी गई हैं, वे इनलाइन नीति में AwsSSOInlinePolicy के रूप में ये अनुमतियाँ प्राप्त करेंगी।
इसलिए, भले ही आप AwsSSOInlinePolicy नामक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह यह नहीं दर्शाता कि इसकी समान अनुमतियाँ हैं।
एक उपयोगकर्ता (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, दूसरे उपयोगकर्ता (विश्वासित) को अपने खाते तक पहुँचने की अनुमति दे सकता है लेकिन केवल नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके पास हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके पास है और एक तीसरे पक्ष के AWS खाते के बीच। यह अनुशंसा की जाती है कि विश्वासित उपयोगकर्ता को निर्दिष्ट करें और कुछ सामान्य चीज़ न डालें क्योंकि यदि नहीं, तो अन्य प्रमाणित उपयोगकर्ता जैसे संघीय उपयोगकर्ता भी इस विश्वास का दुरुपयोग कर सकेंगे।
समर्थित नहीं:
विश्वास संबंध
AD प्रशासन केंद्र
पूर्ण PS API समर्थन
AD रीसाइक्ल बिन
समूह प्रबंधित सेवा खाते
स्कीमा एक्सटेंशन
OS या इंस्टेंस तक सीधी पहुँच नहीं
ऐप अस्थायी क्रेडेंशियल बनाने के लिए AssumeRoleWithWebIdentity का उपयोग करता है। हालाँकि, यह AWS कंसोल तक पहुँच प्रदान नहीं करता है, केवल AWS के भीतर संसाधनों तक पहुँच प्रदान करता है।
आप पासवर्ड नीति सेटिंग विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताओं को सेट कर सकते हैं।
आप "क्रेडेंशियल रिपोर्ट" डाउनलोड कर सकते हैं जिसमें वर्तमान क्रेडेंशियल्स के बारे में जानकारी होती है (जैसे उपयोगकर्ता निर्माण समय, क्या पासवर्ड सक्षम है...)। आप एक क्रेडेंशियल रिपोर्ट हर चार घंटे में एक बार उत्पन्न कर सकते हैं।
AWS पहचान और पहुँच प्रबंधन (IAM) AWS के सभी क्षेत्रों में बारीक पहुँच नियंत्रण प्रदान करता है। IAM के साथ, आप निर्दिष्ट कर सकते हैं कौन कौन सी सेवाओं और संसाधनों तक पहुँच सकता है, और किन शर्तों के तहत। IAM नीतियों के साथ, आप अपने कार्यबल और प्रणालियों के लिए अनुमतियों का प्रबंधन करते हैं ताकि कम से कम विशेषाधिकार अनुमतियाँ सुनिश्चित की जा सकें।
इस पृष्ठ पर आप कुंजियों के IAM ID प्रीफिक्स उनके स्वभाव के आधार पर पा सकते हैं:
ABIA | |
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 के माध्यम से AWS में प्रमाणित करने के लिए आपको स्थानीय क्रेडेंशियल्स की आवश्यकता होती है। डिफ़ॉल्ट रूप से आप उन्हें हाथ से ~/.aws/credentials में कॉन्फ़िगर कर सकते हैं या चलाकर aws configure।
उस फ़ाइल में आपके पास एक से अधिक प्रोफ़ाइल हो सकती हैं, यदि कोई प्रोफ़ाइल निर्दिष्ट नहीं की गई है तो aws cli का उपयोग करते समय, उस फ़ाइल में [default] नामक प्रोफ़ाइल का उपयोग किया जाएगा।
एक से अधिक प्रोफ़ाइल के साथ क्रेडेंशियल फ़ाइल का उदाहरण:
If you need to access different AWS accounts and your profile was given access to assume a role inside those accounts, you don't need to call manually STS every time (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) and configure the credentials.
आप ~/.aws/config फ़ाइल का उपयोग कर सकते हैं यह इंगित करने के लिए कि कौन से भूमिकाएँ ग्रहण करनी हैं, और फिर सामान्य रूप से --profile पैरामीटर का उपयोग करें (उपयोगकर्ता के लिए assume-role पारदर्शी तरीके से किया जाएगा)।
एक कॉन्फ़िग फ़ाइल का उदाहरण:
इस कॉन्फ़िग फ़ाइल के साथ आप aws cli का उपयोग कर सकते हैं जैसे:
यदि आप इसके लिए कुछ समान खोज रहे हैं लेकिन ब्राउज़र के लिए, तो आप विस्तार AWS Extend Switch Roles देख सकते हैं।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
