मार्गदर्शिका

एक संभावित रूप से समझौता किए गए EC2 इंस्टेंस को Auto Scaling समूह में न्यूनतम व्यवधान के साथ जांच की आवश्यकता है।

→ELB लक्ष्य समूह से डीरजिस्टर करें, Auto Scaling समूह से हटाएँ, और एक प्रतिबंधात्मक "फोरेंसिक" सुरक्षा समूह लागू करें जो फोरेंसिक वर्कस्टेशन एक्सेस को छोड़कर सभी ट्रैफिक को अस्वीकार करता है।

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

GuardDuty फाइंडिंग द्वारा ट्रिगर किए गए बहु-चरणीय घटना प्रतिक्रिया वर्कफ़्लो (जैसे, स्नैपशॉट, आइसोलेट, सूचित करें) को स्वचालित करें।

→विशिष्ट फाइंडिंग को कैप्चर करने और एक AWS Step Functions स्टेट मशीन को ट्रिगर करने के लिए एक EventBridge नियम का उपयोग करें। स्टेट मशीन त्रुटि हैंडलिंग और रिट्राई लॉजिक के साथ कार्यों के अनुक्रम को ऑर्केस्ट्रेट करती है।

क्यों: Step Functions बहु-चरणीय वर्कफ़्लो के लिए मजबूत ऑर्केस्ट्रेशन प्रदान करते हैं, विश्वसनीयता और स्टेट मैनेजमेंट सुनिश्चित करते हैं, जो एक एकल मोनोलिथिक Lambda फ़ंक्शन से बेहतर है।

साइडकार एजेंटों को तैनात किए बिना चल रहे ECS Fargate या EC2 कंटेनरों के भीतर रनटाइम खतरों (जैसे, क्रिप्टोक्यूरेंसी माइनिंग, विशेषाधिकार बढ़ाना) का पता लगाएं।

→Amazon GuardDuty ECS रनटाइम मॉनिटरिंग सक्षम करें। EC2 के लिए, GuardDuty सुरक्षा एजेंट को DaemonSet के रूप में तैनात करें। Fargate के लिए, स्वचालित एजेंट कॉन्फ़िगरेशन का उपयोग करें।

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

संदर्भ↗

एक विशिष्ट AWS Security Hub फाइंडिंग को स्वचालित रूप से ठीक करें, जैसे कि एक सार्वजनिक रूप से सुलभ S3 बकेट।

→एक EventBridge नियम बनाएँ जो विशिष्ट फाइंडिंग प्रकार (जैसे, `S3.1`) से मेल खाता हो और सुधार करने के लिए एक Lambda फ़ंक्शन या SSM ऑटोमेशन दस्तावेज़ को ट्रिगर करता हो।

क्यों: यह Security Hub स्वचालित प्रतिक्रिया के लिए मूल, इवेंट-ड्रिवन पैटर्न है, जो लगभग वास्तविक समय, लक्षित सुधार प्रदान करता है।

एक IAM एक्सेस की सार्वजनिक रूप से उजागर हो गई है। घटना को नियंत्रित करें और प्रभाव क्षेत्र का आकलन करें।

→1. उजागर एक्सेस की को निष्क्रिय करें। 2. सक्रिय STS सत्रों को अमान्य करने के लिए उपयोगकर्ता/भूमिका से एक deny-all इनलाइन नीति संलग्न करें। 3. की के साथ किए गए सभी API कॉलों के लिए CloudTrail लॉग की समीक्षा करें। 4. हमलावर द्वारा बनाए गए किसी भी अनधिकृत संसाधन या IAM प्रिंसिपल को मिटा दें।

क्यों: की को निष्क्रिय करने से भविष्य में इसका उपयोग बंद हो जाता है। deny-all नीति की को निष्क्रिय करने से *पहले* बनाए गए सक्रिय सत्रों को रद्द करने के लिए महत्वपूर्ण है। CloudTrail क्षति मूल्यांकन के लिए ऑडिट ट्रेल प्रदान करता है।

कंपनी-विशिष्ट या उद्योग-विशिष्ट खतरे की खुफिया जानकारी फ़ीड के साथ GuardDuty खतरे का पता लगाने की क्षमता बढ़ाएँ।

→दुर्भावनापूर्ण IP एड्रेस/CIDR की एक प्लेनटेक्स्ट फ़ाइल S3 पर अपलोड करें। GuardDuty में एक नया थ्रेट इंटेल सेट बनाएँ और सक्रिय करें, जो S3 फ़ाइल की ओर इशारा करता हो।

क्यों: यह आपको GuardDuty के प्रबंधित खतरे की खुफिया जानकारी को कस्टम IOCs के साथ बढ़ाने की अनुमति देता है, जिससे आपकी संसाधन इन निर्दिष्ट IPs के साथ संवाद करते समय फाइंडिंग उत्पन्न होती है।

सभी नेटवर्क कॉन्फ़िगरेशन पर विचार करते हुए, विशिष्ट पोर्ट पर इंटरनेट के लिए खुले नेटवर्क पथ वाले EC2 इंस्टेंस की पहचान करें।

→Amazon Inspector सक्षम करें और इसकी नेटवर्क रीचेबिलिटी फाइंडिंग की समीक्षा करें।

क्यों: Inspector IGWs से इंस्टेंस तक एक पूर्ण नेटवर्क पथ विश्लेषण करता है, सुरक्षा समूहों, NACLs, और रूट तालिकाओं का मूल्यांकन करके वास्तविक रीचेबिलिटी निर्धारित करता है। यह केवल व्यक्तिगत सुरक्षा समूह नियमों की जाँच करने से अधिक सटीक है।

सुरक्षा फाइंडिंग के पूर्ण दायरे की जांच करें, सभी संबंधित संस्थाओं और ऐतिहासिक व्यवहार की कल्पना करें।

→Amazon Detective का उपयोग करें। संबंधित API कॉलों, नेटवर्क कनेक्शनों और GuardDuty फाइंडिंग के व्यवहार ग्राफ़ और टाइमलाइन को देखने के लिए इकाई प्रोफ़ाइल (जैसे, एक EC2 इंस्टेंस या IAM भूमिका के लिए) पर नेविगेट करें।

क्यों: Detective स्वचालित रूप से CloudTrail, VPC Flow Logs, और GuardDuty से लॉग को सहसंबंधित करता है, प्रासंगिक विश्लेषण प्रदान करता है जो मैन्युअल लॉग सहसंबंध की तुलना में मूल कारण जांच को काफी तेज करता है।

अनुपालन को पूरा करने के लिए ऑडिट लॉग (जैसे, CloudTrail, VPC Flow Logs) को छेड़छाड़-प्रूफ, क्वेरी करने योग्य तरीके से दीर्घकालिक प्रतिधारण के लिए संग्रहीत करें।

→लॉग को S3 बकेट में S3 ऑब्जेक्ट लॉक के साथ कंप्लायंस मोड सक्षम करके डिलीवर करें। क्वेरी करने के लिए Amazon Athena का उपयोग करें।

क्यों: कंप्लायंस मोड में ऑब्जेक्ट लॉक रूट उपयोगकर्ता सहित किसी भी व्यक्ति द्वारा विलोपन या संशोधन को रोकता है, जिससे लॉग अपरिवर्तनीयता सुनिश्चित होती है। Athena संग्रहीत लॉग पर ऐड-हॉक SQL क्वेरी क्षमताएं प्रदान करता है।

संदर्भ↗

पूरे AWS Organization के लिए सभी प्रबंधन और डेटा इवेंट को केंद्रीय रूप से एकत्रित करें।

→प्रबंधन खाते में, एक CloudTrail संगठन ट्रेल बनाएँ। ऑब्जेक्ट-स्तर का डेटा कैप्चर करने के लिए, उच्च-मूल्य वाले संसाधनों के लिए विशिष्ट इवेंट प्रकारों (जैसे, S3 PutObject, Lambda Invoke) को लॉग करने के लिए उन्नत इवेंट सेलेक्टर का उपयोग करें।

क्यों: एक संगठन ट्रेल स्वचालित रूप से सभी सदस्य खातों के लिए इवेंट को लॉग करता है। उन्नत इवेंट सेलेक्टर केवल आवश्यक संसाधनों को लक्षित करके उच्च-मात्रा वाले डेटा इवेंट को लागत-प्रभावी ढंग से लॉग करने के लिए महत्वपूर्ण हैं।

पूरे संगठन से कई वर्षों के CloudTrail इवेंट पर जटिल, SQL-आधारित विश्लेषण करें।

→AWS CloudTrail Lake सक्षम करें और आवश्यक प्रतिधारण अवधि (7 साल तक) के साथ एक संगठन-स्तरीय इवेंट डेटा स्टोर बनाएँ। विश्लेषण के लिए बिल्ट-इन SQL क्वेरी एडिटर का उपयोग करें।

क्यों: CloudTrail Lake एक प्रबंधित, अपरिवर्तनीय डेटा स्टोर और क्वेरी इंजन प्रदान करता है जो विशेष रूप से CloudTrail इवेंट के लिए बनाया गया है, जिससे लॉग विश्लेषण के लिए S3, Glue, और Athena को प्रबंधित करने की आवश्यकता समाप्त हो जाती है।

खतरे की तलाश या समस्या निवारण के लिए एक VPC के भीतर संसाधनों द्वारा किए गए सभी DNS प्रश्नों की निगरानी करें।

→Route 53 Resolver DNS क्वेरी लॉगिंग सक्षम करें और इसे CloudWatch Logs, S3, या Kinesis Data Firehose पर लॉग भेजने के लिए कॉन्फ़िगर करें।

क्यों: यह आपके VPCs के भीतर DNS रिज़ॉल्यूशन गतिविधि में विस्तृत दृश्यता प्रदान करता है, पूछे गए डोमेन, स्रोत इंस्टेंस और प्रतिक्रिया को कैप्चर करता है, जो DNS-आधारित खतरों का पता लगाने के लिए महत्वपूर्ण है।

एक मानक स्कीमा का उपयोग करके विभिन्न AWS और तृतीय-पक्ष स्रोतों से सुरक्षा लॉग को डेटा लेक में केंद्रीकृत और सामान्य करें।

→Amazon Security Lake को तैनात करें। यह स्वचालित रूप से डेटा को Open Cybersecurity Schema Framework (OCSF) में एकत्र और सामान्य करता है और इसे S3 में Parquet प्रारूप में संग्रहीत करता है।

क्यों: Security Lake सुरक्षा डेटा लेक के निर्माण और प्रबंधन को स्वचालित करता है, जिससे सामान्यीकरण के लिए कस्टम ETL पाइपलाइन बनाने का परिचालन ओवरहेड कम हो जाता है।

SOC 2, PCI DSS, या HIPAA जैसे फ्रेमवर्क के खिलाफ अनुपालन ऑडिट के लिए साक्ष्य संग्रह को स्वचालित करें।

→AWS Audit Manager का उपयोग करें। एक पूर्व-निर्मित फ्रेमवर्क का चयन करें, जो स्वचालित रूप से AWS सेवाओं (CloudTrail, Config, Security Hub) से साक्ष्य एकत्र करता है और इसे विशिष्ट अनुपालन नियंत्रणों से मैप करता है।

क्यों: ऑडिट मैनेजर साक्ष्य संग्रह प्रक्रिया को स्वचालित और केंद्रीकृत करता है, अनुपालन ऑडिट की तैयारी और संचालन के लिए आवश्यक मैन्युअल प्रयास को काफी कम करता है।

सभी S3 बकेट में संवेदनशील डेटा (PII, PHI, वित्तीय) को स्वचालित रूप से खोजें और वर्गीकृत करें।

→Amazon Macie सक्षम करें और स्वचालित संवेदनशील डेटा खोज नौकरियों को कॉन्फ़िगर करें। सामान्य डेटा प्रकारों के लिए प्रबंधित डेटा पहचानकर्ताओं का उपयोग करें और मालिकाना स्वरूपों के लिए कस्टम डेटा पहचानकर्ता बनाएँ।

क्यों: Macie S3 डेटा वर्गीकरण के लिए एक प्रबंधित, स्केलेबल समाधान प्रदान करता है। ज्ञात गैर-संवेदनशील डेटा (जैसे, परीक्षण डेटा) के लिए फाइंडिंग को दबाने के लिए, Macie अनुमति सूचियों का उपयोग करें।

एक S3 बकेट पर कई सुरक्षा नियंत्रण लागू करें, जैसे कि एक विशिष्ट की के साथ SSE-KMS की आवश्यकता और HTTP अनुरोधों को अस्वीकार करना।

→कई `Deny` स्टेटमेंट और कंडीशन कीज़ के साथ एक बकेट नीति का उपयोग करें: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"`, और `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`।

क्यों: बकेट नीतियां बारीक-दानेदार, संसाधन-स्तर का नियंत्रण प्रदान करती हैं। Deny स्टेटमेंट में कई कंडीशन कीज़ का उपयोग करना एक बकेट पर स्तरित सुरक्षा मुद्रा लागू करने का मानक तरीका है।

यह सुनिश्चित करें कि सभी नए EBS वॉल्यूम एक विशिष्ट ग्राहक-प्रबंधित KMS की के साथ एन्क्रिप्टेड हैं, पूरे संगठन में।

→प्रत्येक क्षेत्र के लिए खाता सेटिंग्स में डिफ़ॉल्ट रूप से EBS एन्क्रिप्शन सक्षम करें, CMK निर्दिष्ट करें। एक SCP लागू करें जो `ec2:CreateVolume` को अस्वीकार करता है यदि `encrypted` पैरामीटर `false` है, एक निवारक गार्डरेल के रूप में।

क्यों: डिफ़ॉल्ट सेटिंग सुविधा प्रदान करती है, जबकि SCP एक कठोर प्रवर्तन गार्डरेल प्रदान करता है, जो EBS के लिए डेटा-एट-रेस्ट एन्क्रिप्शन के लिए रक्षा-इन-डेप्थ दृष्टिकोण बनाता है।

AWS KMS का उपयोग करके बड़े (> 4KB) डेटा ऑब्जेक्ट को एन्क्रिप्ट करें।

→एनवेलप एन्क्रिप्शन का उपयोग करें। एक प्लेनटेक्स्ट डेटा की और एक एन्क्रिप्टेड डेटा की प्राप्त करने के लिए `KMS:GenerateDataKey` कॉल करें। बड़े ऑब्जेक्ट को स्थानीय रूप से एन्क्रिप्ट करने के लिए प्लेनटेक्स्ट की का उपयोग करें। एन्क्रिप्टेड ऑब्जेक्ट और एन्क्रिप्टेड डेटा की को एक साथ संग्रहीत करें। प्लेनटेक्स्ट की को छोड़ दें।

क्यों: KMS एन्क्रिप्ट API की 4KB सीमा है। एनवेलप एन्क्रिप्शन किसी भी आकार के डेटा को एन्क्रिप्ट करने की अनुमति देता है जबकि छोटी डेटा की KMS द्वारा संरक्षित होती है, जिससे KMS के माध्यम से डेटा स्ट्रीम करने की तुलना में लागत और विलंबता कम होती है।

संदर्भ↗

DR या वैश्विक एप्लिकेशन स्थिरता के लिए कई AWS क्षेत्रों में एक ही एन्क्रिप्शन की का उपयोग करें।

→एक क्षेत्र में एक KMS मल्टी-रीजन प्राइमरी की बनाएँ और अन्य क्षेत्रों में प्रतिकृति की बनाएँ। एक क्षेत्र में एक की के साथ एन्क्रिप्ट किया गया डेटा दूसरे में प्रतिकृति के साथ डिक्रिप्ट किया जा सकता है।

क्यों: मल्टी-रीजन कीज़ समान की सामग्री और की आईडी साझा करते हैं, जिससे डिक्रिप्शन के लिए क्रॉस-रीजन API कॉलों के बिना क्रॉस-रीजन डेटा पोर्टेबिलिटी सक्षम होती है।

अनुप्रयोगों द्वारा उपयोग किए जाने वाले क्रेडेंशियल (जैसे, डेटाबेस पासवर्ड, API की) को सुरक्षित रूप से संग्रहीत और स्वचालित रूप से घुमाएं।

→क्रेडेंशियल को AWS Secrets Manager में संग्रहीत करें। एक कस्टम या AWS-प्रदान किए गए Lambda रोटेशन फ़ंक्शन का उपयोग करके स्वचालित रोटेशन कॉन्फ़िगर करें। अनुप्रयोग एक IAM भूमिका के माध्यम से रनटाइम पर रहस्यों को पुनः प्राप्त करते हैं।

क्यों: Secrets Manager सुरक्षित भंडारण, अभिगम नियंत्रण, ऑडिटिंग और स्वचालित रोटेशन सहित संपूर्ण गुप्त जीवनचक्र के लिए एक विशेष रूप से निर्मित सेवा है, जो हार्डकोडेड या पुराने क्रेडेंशियल के जोखिम को कम करती है।

वेबसाइटों के लिए सार्वजनिक TLS प्रमाणपत्र और आंतरिक माइक्रोसेवा संचार (mTLS) के लिए निजी प्रमाणपत्र दोनों का प्रबंधन करें।

→ELB/CloudFront के साथ एकीकृत मुफ्त सार्वजनिक प्रमाणपत्रों के लिए AWS Certificate Manager (ACM) का उपयोग करें। आंतरिक सेवाओं के लिए निजी प्रमाणपत्र जारी करने और प्रबंधित करने के लिए ACM Private CA का उपयोग करके एक निजी प्रमाणपत्र प्राधिकरण बनाएँ।

क्यों: यह सार्वजनिक और निजी PKI को अलग करता है, प्रत्येक उपयोग के मामले के लिए उपयुक्त उपकरण का उपयोग करता है। ACM सार्वजनिक प्रमाणपत्र जीवनचक्र को संभालता है, जबकि ACM Private CA एक पूरी तरह से प्रबंधित निजी PKI पदानुक्रम प्रदान करता है।

डेटा को एक निश्चित प्रतिधारण अवधि के लिए अपरिवर्तनीय रूप से संग्रहीत करें, जहां रूट उपयोगकर्ता भी इसे हटा नहीं सकता है।

→बकेट पर S3 ऑब्जेक्ट लॉक सक्षम करें। कंप्लायंस मोड के साथ वस्तुओं को प्रतिधारण अवधि के तहत रखें।

क्यों: कंप्लायंस मोड सबसे मजबूत WORM (Write-Once-Read-Many) नियंत्रण है, जो किसी भी उपयोगकर्ता द्वारा विलोपन को रोकता है। गवर्नेंस मोड को अधिकृत प्रिंसिपलों द्वारा बायपास किया जा सकता है।

अनिवार्य प्रतिधारण अवधि के लिए बैकअप को विलोपन (जैसे, रैंसमवेयर या समझौता किए गए क्रेडेंशियल के कारण) से सुरक्षित रखें।

→न्यूनतम प्रतिधारण अवधि के साथ कंप्लायंस मोड में AWS Backup Vault Lock सक्षम करें।

क्यों: कंप्लायंस मोड में वॉल्ट लॉक बैकअप वॉल्ट को WORM-अनुरूप बनाता है, जिससे किसी भी उपयोगकर्ता, रूट सहित, को प्रतिधारण अवधि समाप्त होने से पहले रिकवरी पॉइंट को हटाने से रोका जा सके।

अत्यधिक संवेदनशील डेटा को संसाधित करें जहां डेटा को कभी भी OS, हाइपरवाइजर, या AWS ऑपरेटरों के सामने उजागर नहीं किया जाना चाहिए।

→क्रिप्टोग्राफिक रूप से पृथक कंप्यूट वातावरण बनाने के लिए AWS Nitro Enclaves का उपयोग करें। यह सुनिश्चित करने के लिए KMS प्रमाणीकरण का उपयोग करें कि केवल सत्यापित एन्क्लेव ही डेटा को डिक्रिप्ट कर सकते हैं।

क्यों: नाइट्रो एन्क्लेव AWS पर डेटा-इन-यूज़ सुरक्षा का सबसे मजबूत स्तर प्रदान करते हैं, एक विश्वसनीय निष्पादन वातावरण बनाने के लिए हार्डवेयर-स्तर प्रमाणीकरण का उपयोग करते हैं।

एन्क्रिप्शन कीज़ के साथ AWS सेवाओं का उपयोग करें जो भौतिक रूप से ऑन-प्रिमाइसेस HSM में, AWS के बाहर संग्रहीत और प्रबंधित होती हैं।

→एक KMS एक्सटर्नल की स्टोर (XKS) कॉन्फ़िगर करें जो KMS से एक बाहरी की मैनेजर तक क्रिप्टोग्राफिक ऑपरेशन को प्रॉक्सी करता है।

क्यों: XKS ग्राहकों को संप्रभुता या अनुपालन आवश्यकताओं को पूरा करने के लिए AWS के बाहर अपनी की सामग्री पर नियंत्रण बनाए रखने की अनुमति देता है, जबकि अभी भी KMS-जागरूक AWS सेवाओं के साथ एकीकृत करता है।

निवारक और जासूसी नियंत्रणों के साथ पूरे संगठन में एक सख्त "कोई सार्वजनिक S3 बकेट नहीं" नीति लागू करें।

→प्रबंधन खाते से संगठन स्तर पर S3 ब्लॉक पब्लिक एक्सेस सक्षम करें। एक SCP के साथ पूरक करें जो `s3:PutBucketPolicy` जैसी कार्रवाइयों को अस्वीकार करता है यदि नीति सार्वजनिक पहुँच की अनुमति देती है। विचलन का पता लगाने के लिए AWS Config का उपयोग करें।

क्यों: यह स्तरित दृष्टिकोण एक डिफ़ॉल्ट ब्लॉक (संगठन सेटिंग), एक निवारक गार्डरेल जो गलत कॉन्फ़िगरेशन (SCP) को रोकता है, और निरंतर निगरानी (Config) के लिए एक जासूसी नियंत्रण प्रदान करता है।

केंद्रीकृत सुरक्षा उपकरण (जैसे, AWS Network Firewall) का उपयोग करके सभी इंटर-VPC और इंटरनेट-बाउंड ट्रैफिक का निरीक्षण करें।

→एक समर्पित निरीक्षण VPC बनाएँ। सभी VPCs को जोड़ने के लिए एक Transit Gateway का उपयोग करें। निरीक्षण VPC के माध्यम से सभी ट्रैफिक भेजने के लिए TGW रूट तालिकाओं को कॉन्फ़िगर करें। सममित रूटिंग के लिए TGW अटैचमेंट पर उपकरण मोड सक्षम करें।

क्यों: यह केंद्रीकृत ट्रैफिक निरीक्षण के लिए मानक हब-एंड-स्पोक मॉडल है, जो जटिल VPC पीयरिंग मेष के बिना स्केलेबिलिटी और सुसंगत नीति प्रवर्तन प्रदान करता है।

OWASP Top 10, बॉट्स और अकाउंट टेकओवर हमलों के खिलाफ एक वेब एप्लिकेशन (CloudFront/ALB पर) की रक्षा करें।

→AWS Managed Rules (जैसे, `AWSManagedRulesCommonRuleSet`), Bot Control प्रबंधित नियम समूह, और Account Takeover Prevention (ATP) प्रबंधित नियम समूह के साथ AWS WAF संलग्न करें।

क्यों: यह स्तरित दृष्टिकोण व्यापक सुरक्षा (सामान्य), स्वचालित ट्रैफिक डिटेक्शन (Bot Control), और विशिष्ट लॉगिन एंडपॉइंट सुरक्षा (ATP) के लिए कई प्रबंधित नियम समूहों का उपयोग करता है।

सेवा को इंटरनेट पर उजागर किए बिना ग्राहक VPCs से एक SaaS API सेवा तक सुरक्षित, निजी पहुँच प्रदान करें।

→एक Network Load Balancer (NLB) द्वारा समर्थित एक AWS PrivateLink एंडपॉइंट सेवा बनाएँ। ग्राहक सेवा तक पहुँचने के लिए अपने VPCs में इंटरफ़ेस VPC एंडपॉइंट बनाते हैं।

क्यों: PrivateLink AWS निजी बैकबोन पर ट्रैफिक रखता है, सार्वजनिक इंटरनेट से बचता है और जटिल VPC पीयरिंग, VPNs, या IP वाइटलिस्टिंग की आवश्यकता को समाप्त करता है। यह निजी SaaS कनेक्टिविटी के लिए मानक, स्केलेबल पैटर्न है।

S3 बकेट एक्सेस को प्रतिबंधित करें ताकि सामग्री केवल CloudFront वितरण के माध्यम से ही सुलभ हो।

→CloudFront Origin Access Control (OAC) का उपयोग करें। S3 बकेट नीति को अपडेट करें ताकि केवल CloudFront वितरण के सेवा प्रिंसिपल से पहुंच की अनुमति मिल सके, जो विशिष्ट वितरण ARN पर सशर्त हो।

क्यों: OAC वर्तमान अनुशंसित विधि है, जो पुराने Origin Access Identity (OAI) से बेहतर है। यह SSE-KMS सहित सभी S3 सुविधाओं का समर्थन करता है, और सुरक्षा सर्वोत्तम प्रथाओं का पालन करता है।

SSH/RDP पोर्ट खोले बिना या बैशन होस्ट का प्रबंधन किए बिना निजी सबनेट में EC2 इंस्टेंस तक सुरक्षित, ऑडिट करने योग्य शेल एक्सेस प्रदान करें।

→EC2 इंस्टेंस पर SSM एजेंट स्थापित करें। पहुँच के लिए AWS Systems Manager Session Manager का उपयोग करें। IAM नीतियां नियंत्रित करती हैं कि कौन सत्र शुरू कर सकता है। सत्र गतिविधि को CloudWatch Logs और S3 पर लॉग किया जा सकता है।

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

ज्ञात दुर्भावनापूर्ण डोमेन को हल करने से VPC संसाधनों को रोकने के लिए DNS-स्तर की फ़िल्टरिंग लागू करें।

→Route 53 Resolver DNS Firewall को प्रबंधित डोमेन सूचियों (मालवेयर, C2 के लिए) और कस्टम ब्लॉक सूचियों के साथ कॉन्फ़िगर करें। फ़ायरवॉल नियम समूह को VPCs के साथ संबद्ध करें।

क्यों: यह VPC स्तर पर एक केंद्रीकृत, प्रबंधित DNS फ़िल्टरिंग सेवा प्रदान करता है, जो होस्ट-आधारित एजेंटों की आवश्यकता के बिना सबसे शुरुआती बिंदु (DNS रिज़ॉल्यूशन) पर दुर्भावनापूर्ण गतिविधि को ब्लॉक करता है।

तीन-स्तरीय वेब एप्लिकेशन के लिए न्यूनतम-विशेषाधिकार नेटवर्क नियंत्रण लागू करें।

→प्रत्येक स्तर के लिए अलग सुरक्षा समूह बनाएँ। ALB SG `0.0.0.0/0` से इनबाउंड 443 की अनुमति देता है। App SG केवल ALB SG से इनबाउंड ट्रैफिक की अनुमति देता है। DB SG डेटाबेस पोर्ट पर केवल App SG से इनबाउंड ट्रैफिक की अनुमति देता है।

क्यों: स्रोत के रूप में सुरक्षा समूह संदर्भों का उपयोग गतिशील, IP-अज्ञेयवादी माइक्रोसेगमेंटेशन प्रदान करता है, यह सुनिश्चित करता है कि प्रत्येक स्तर को केवल उसके आसन्न, अधिकृत स्तर द्वारा ही एक्सेस किया जा सके।

EKS पर चलने वाले अनुप्रयोगों को साझा नोड IAM भूमिकाओं का उपयोग करने से बचते हुए, बारीक-दानेदार, पॉड-स्तर की AWS अनुमतियाँ प्रदान करें।

→EKS क्लस्टर पर सर्विस अकाउंट्स के लिए IAM भूमिकाएं (IRSA) सक्षम करें। एप्लिकेशन के लिए विशिष्ट अनुमतियों के साथ एक IAM भूमिका बनाएँ। एप्लिकेशन के Kubernetes सेवा खाते को IAM भूमिका ARN के साथ एनोटेट करें।

क्यों: IRSA उनके सेवा खाते के आधार पर सीधे पॉड को अस्थायी क्रेडेंशियल प्रदान करता है, पॉड स्तर पर न्यूनतम विशेषाधिकार लागू करता है और अत्यधिक अनुमेय नोड भूमिकाओं के सुरक्षा जोखिम को समाप्त करता है।

उपयोगकर्ता पहचान और डिवाइस सुरक्षा मुद्रा दोनों के आधार पर आंतरिक वेब अनुप्रयोगों तक VPN-रहित पहुँच प्रदान करें।

→AWS Verified Access को तैनात करें। कॉर्पोरेट IdP के साथ एक उपयोगकर्ता ट्रस्ट प्रदाता के रूप में और एक डिवाइस प्रबंधन समाधान के साथ एक डिवाइस ट्रस्ट प्रदाता के रूप में एकीकृत करें। प्रति-एप्लिकेशन पहुँच नीतियां बनाएँ।

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

डेवलपर्स को IAM भूमिकाएं बनाने की अनुमति दें लेकिन उन्हें ऐसी भूमिकाएं बनाने से रोकें जो उनके अपने विशेषाधिकारों को बढ़ा सकती हैं।

→एक अनुमतियाँ सीमा नीति बनाएँ जो अधिकतम अनुमत अनुमतियों को परिभाषित करती है। डेवलपर्स की IAM नीति में, `iam:CreateRole` अनुमति को `iam:PermissionsBoundary` कंडीशन की के माध्यम से इस विशिष्ट सीमा को संलग्न करने की आवश्यकता के लिए शर्त दें।

क्यों: अनुमतियाँ सीमाएँ एक IAM इकाई के पास हो सकने वाली अधिकतम अनुमतियाँ निर्धारित करती हैं। यह विशेषाधिकार वृद्धि को रोकता है यह सुनिश्चित करके कि कोई भी भूमिका जो एक डेवलपर बनाता है, सीमा द्वारा सीमित है, चाहे वे कोई भी पहचान नीति संलग्न करें।

संदर्भ↗

किसी भी सदस्य खाते (प्रशासकों सहित) में किसी भी उपयोगकर्ता को उच्च-जोखिम वाले कार्य करने से रोकें, जैसे CloudTrail को अक्षम करना या एक सामान्य S3 बकेट को हटाना।

→मूल या प्रासंगिक OU पर एक सर्विस कंट्रोल पॉलिसी (SCP) लागू करें जिसमें प्रतिबंधित कार्रवाइयों (जैसे, `cloudtrail:StopLogging`, `s3:DeleteBucket`) के लिए एक `Deny` स्टेटमेंट हो।

क्यों: SCPs AWS Organizations में अंतिम गार्डरेल हैं। वे एक खाते में सभी प्रिंसिपलों के लिए अधिकतम अनुमतियाँ निर्धारित करते हैं, और एक SCP में एक स्पष्ट Deny को खाते के भीतर किसी भी IAM नीति द्वारा ओवरराइड नहीं किया जा सकता है।

एक एप्लिकेशन या उपयोगकर्ता के लिए सुरक्षित, ऑडिट करने योग्य क्रॉस-अकाउंट एक्सेस प्रदान करें।

→लक्ष्य खाते में, एक ट्रस्ट नीति के साथ एक IAM भूमिका बनाएँ जो स्रोत खाता प्रिंसिपल ARN को निर्दिष्ट करती है। स्रोत खाते में, प्रिंसिपल को लक्ष्य भूमिका पर `sts:AssumeRole` अनुमति प्रदान करें। एप्लिकेशन अस्थायी क्रेडेंशियल प्राप्त करने के लिए STS AssumeRole का उपयोग करता है।

क्यों: यह क्रॉस-अकाउंट एक्सेस के लिए मानक पैटर्न है। यह अस्थायी, अल्पकालिक क्रेडेंशियल का उपयोग करता है और CloudTrail के माध्यम से दोनों खातों में पूरी तरह से ऑडिट करने योग्य है।

IAM Identity Center को एक बाहरी IdP (जैसे, Okta, Azure AD) के साथ एकीकृत करें और उपयोगकर्ता/समूह प्रावधान को स्वचालित करें।

→IAM Identity Center में बाहरी IdP को पहचान स्रोत के रूप में कॉन्फ़िगर करें। उपयोगकर्ताओं और समूहों को सिंक करने के लिए SCIM के माध्यम से स्वचालित प्रावधान सक्षम करें। सिंक्रनाइज़ किए गए समूहों को अनुमति सेट असाइन करें।

क्यों: SCIM (System for Cross-domain Identity Management) पहचानों का स्वचालित, लगभग वास्तविक समय तुल्यकालन प्रदान करता है, जिससे मैन्युअल उपयोगकर्ता प्रबंधन समाप्त हो जाता है और यह सुनिश्चित होता है कि AWS एक्सेस IdP द्वारा संचालित होता है।

टैग के आधार पर संसाधनों (जैसे, EC2) तक पहुंच प्रदान करें, जहां प्रिंसिपल केवल अपने स्वयं के टीम/विभाग के नाम से टैग किए गए संसाधनों का प्रबंधन कर सकते हैं।

→IAM प्रिंसिपलों (उपयोगकर्ताओं/भूमिकाओं) और संसाधनों (EC2 इंस्टेंस) दोनों को एक सामान्य की (जैसे, `Team`) के साथ टैग करें। एक एकल IAM नीति बनाएँ जो `aws:PrincipalTag/Team` की तुलना `aws:ResourceTag/Team` से करने वाली शर्त के साथ क्रियाओं की अनुमति देती है।

क्यों: Attribute-Based Access Control (ABAC) एक स्केलेबल अनुमतियाँ मॉडल प्रदान करता है जिसके लिए नए संसाधनों या टीमों को जोड़ने पर नीति अपडेट की आवश्यकता नहीं होती है। अनुमतियाँ टैग के आधार पर गतिशील रूप से निर्धारित की जाती हैं।

खाता B में एक प्रिंसिपल को खाता A में एक S3 ऑब्जेक्ट को पढ़ने की आवश्यकता है जो खाता A में एक KMS की के साथ एन्क्रिप्टेड है।

→तीन अनुमतियों की आवश्यकता है: 1) खाता A में S3 बकेट नीति को खाता B के प्रिंसिपल को अनुमति देनी चाहिए। 2) खाता A में KMS की नीति को `kms:Decrypt` के लिए खाता B के प्रिंसिपल को अनुमति देनी चाहिए। 3) खाता B में प्रिंसिपल को `s3:GetObject` और `kms:Decrypt` की अनुमति देने वाली एक IAM नीति की आवश्यकता है।

क्यों: KMS-एन्क्रिप्टेड डेटा तक पहुँचने के लिए डेटा सेवा (S3) और एन्क्रिप्शन सेवा (KMS) दोनों से अनुमतियों की आवश्यकता होती है। KMS की नीति एक संसाधन नीति है और क्रॉस-अकाउंट एक्सेस प्रदान करने के लिए महत्वपूर्ण है।

जब कई नीतियां (IAM, संसाधन, SCP, सीमा) लागू होती हैं तो अंतिम अनुमति परिणाम को समझें।

→मूल्यांकन तर्क यह है: किसी भी नीति में एक स्पष्ट Deny हमेशा किसी भी Allow को ओवरराइड करता है। यदि कोई Deny मौजूद नहीं है, तो किसी भी लागू नीति में एक स्पष्ट Allow पहुँच प्रदान करता है। प्रभावी अनुमतियाँ सभी लागू नीतियों का प्रतिच्छेदन हैं।

क्यों: यह एक मौलिक IAM अवधारणा है। एक स्पष्ट Deny सबसे शक्तिशाली कथन है और एक कठोर "नहीं" के रूप में कार्य करता है। इसे समझना पहुँच समस्याओं के निवारण की कुंजी है।

एक IAM उपयोगकर्ता या भूमिका को एक उच्च विशेषाधिकार प्राप्त भूमिका को एक AWS सेवा (जैसे, EC2) को पास करने से रोकें, जिससे उसके विशेषाधिकार बढ़ जाएंगे।

→उपयोगकर्ता/भूमिका की IAM नीति में `iam:PassRole` अनुमति का दायरा निर्धारित करें। `Resource` तत्व को केवल विशिष्ट, न्यूनतम-विशेषाधिकार भूमिका ARNs तक सीमित करें जिसे इकाई पास करने के लिए अधिकृत है।

क्यों: वाइल्डकार्ड (`"Resource": "*"`) के साथ `iam:PassRole` एक बड़ा विशेषाधिकार वृद्धि जोखिम है। इसे विशिष्ट, कम-विशेषाधिकार वाली भूमिकाओं तक सीमित करना एक महत्वपूर्ण सुरक्षा नियंत्रण है।

उपयोगकर्ताओं को MFA के साथ चुनौती दें केवल तभी जब लॉगिन प्रयास को जोखिम भरा माना जाए (जैसे, नया डिवाइस, असामान्य स्थान)।

→Cognito User Pool में उन्नत सुरक्षा सुविधाएँ सक्षम करें और जोखिम-आधारित MFA प्रवर्तन के साथ अनुकूली प्रमाणीकरण कॉन्फ़िगर करें।

क्यों: यह हर लॉगिन के लिए MFA की आवश्यकता से बेहतर उपयोगकर्ता अनुभव प्रदान करता है, जबकि केवल असामान्य साइन-इन प्रयासों पर चुनौतियों को लागू करके सुरक्षा बढ़ाता है।

निजी PKI का उपयोग करने वाले ऑन-प्रिमाइसेस सर्वर को दीर्घकालिक AWS क्रेडेंशियल के बिना AWS सेवाओं तक पहुँचने की अनुमति दें।

→IAM भूमिकाएं कहीं भी कॉन्फ़िगर करें। निजी CA प्रमाणपत्र का उपयोग करके एक ट्रस्ट एंकर बनाएँ। प्रमाणपत्रों को IAM भूमिकाओं में मैप करने वाले प्रोफाइल बनाएँ। सर्वर अस्थायी AWS क्रेडेंशियल प्राप्त करने के लिए अपने प्रमाणपत्रों का उपयोग करते हैं।

क्यों: यह मौजूदा PKI का लाभ उठाकर IAM भूमिकाओं को बाहरी वर्कलोड तक विस्तारित करता है, जिससे ऑन-प्रिमाइसेस पर AWS एक्सेस कीज़ को प्रबंधित करने की आवश्यकता समाप्त हो जाती है।

CloudFormation टेम्प्लेट में परिभाषित गैर-अनुपालन वाले संसाधनों की तैनाती को *प्रावधान से पहले* रोकें।

→AWS Control Tower सक्रिय नियंत्रण सक्षम करें। ये प्रावधान से पहले नीतियों (cfn-guard में लिखी गई) के खिलाफ संसाधन कॉन्फ़िगरेशन को मान्य करने के लिए CloudFormation हुक का उपयोग करते हैं।

क्यों: यह एक "शिफ्ट-लेफ्ट" नियंत्रण है जो स्रोत पर गलत कॉन्फ़िगरेशन को रोकता है, जो उन्हें तैनात किए जाने के बाद उनका पता लगाने और उन्हें ठीक करने से अधिक प्रभावी है।