पूरे संगठन में GuardDuty सक्षम करना

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

AWS Organizations आपको कई खातों को एक प्रबंधन खाते के अंतर्गत समूहित करने देता है, जिन्हें संगठनात्मक इकाइयों (OUs) में व्यवस्थित किया जाता है। यह बहु-खाता शासन का आधार है। GuardDuty सहित कई सुरक्षा सेवाएँ Organizations के साथ एकीकृत होकर प्रत्येक सदस्य खाते में केंद्रीय रूप से काम करती हैं।

शक्तिशाली प्रबंधन खाते से सुरक्षा चलाने के बजाय, आप GuardDuty के लिए एक अलग प्रत्यायोजित प्रशासक खाता निर्धारित करते हैं, जो सामान्यतः समर्पित सुरक्षा खाता होता है। यह खाता पूरे संगठन के लिए GuardDuty को कॉन्फ़िगर और देखता है तथा दैनिक कार्यों के लिए प्रबंधन खाते का उपयोग न करने की सर्वोत्तम प्रथा का पालन करता है।

Organizations का प्रबंधन खाता अत्यंत संवेदनशील होता है, इसलिए AWS इसे केवल बिलिंग और खाता-प्रबंधन के लिए रखने की सलाह देता है। सुरक्षा प्रशासन को अलग खाते को सौंपने से प्रभाव-क्षेत्र सीमित होता है और कर्तव्यों का पृथक्करण लागू होता है, जो Well-Architected की ऐसी सर्वोत्तम प्रथा है जिसे परीक्षा में महत्व दिया जाता है।

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

एक प्रमुख सुविधा स्वचालित सक्षमकरण है: संगठन में जोड़ा गया कोई भी नया खाता अपने-आप GuardDuty चालू कर लेता है। इससे वह सामान्य अंतराल समाप्त हो जाता है जिसमें नया बनाया गया खाता बिना निगरानी के रह जाता है। परीक्षा में इसे महत्वपूर्ण माना जाता है, क्योंकि संगठन के बढ़ने के साथ यह पहचान का कवरेज सुनिश्चित करता है।

प्रत्यायोजित प्रशासक सभी खातों के सभी निष्कर्ष एक ही दृश्य में देखता है। यह केंद्रीय दृश्य संगठन-व्यापी सुरक्षा संचालन टीम के लिए आवश्यक है, ताकि वह दर्जनों खातों में अलग-अलग लॉग इन किए बिना प्राथमिकता तय कर सके और प्रतिक्रिया दे सके। यह केंद्रीय सुरक्षा केंद्र एकत्रीकरण में भी निष्कर्ष भेजता है।

GuardDuty क्षेत्रीय सेवा है, इसलिए इसे पूरे संगठन में सक्षम करना प्रत्येक क्षेत्र में करना आवश्यक है। एक सामान्य गलती यह है कि इसे एक क्षेत्र में सक्षम करके पूरे विश्व में कवरेज मान ली जाए। पूरी गतिविधि को कवर करने के लिए इसे आपके द्वारा उपयोग किए जाने वाले प्रत्येक क्षेत्र में सक्षम करें, जिन क्षेत्रों में संसाधन होने की अपेक्षा नहीं है उनमें भी।

इसे सेट अप करने के लिए पहले Organizations में GuardDuty के लिए विश्वसनीय पहुँच सक्षम करनी होती है, फिर प्रत्यायोजित व्यवस्थापक पंजीकृत करना होता है। इसके बाद व्यवस्थापक सदस्यता और कॉन्फ़िगरेशन को केंद्रीकृत रूप से प्रबंधित करता है। यह एक बार किया जाने वाला सेटअप है, जिसका लाभ संगठन के बढ़ने के साथ मिलता है।

केंद्रीय कंसोल दृश्य के अलावा, संगठन अक्सर हर खाते के निष्कर्षों को Security Hub के एकत्रीकरण के माध्यम से या साझा S3 बकेट और EventBridge बस में निर्यात करके केंद्रीय सुरक्षा खाते तक भेजते हैं। इससे सुरक्षा संचालन टीम को पूरे खातों में फैला हुआ एक टिकाऊ रिकॉर्ड मिलता है। इस केंद्रीय प्रवाह का डिज़ाइन तैयार करना कई खातों से जुड़े परीक्षणों का एक नियमित विषय है।

Organizations के साथ एकीकरण से पहले, खातों को निमंत्रण के माध्यम से जोड़ा जाता था: व्यवस्थापक प्रत्येक सदस्य को निमंत्रण भेजता था और सदस्य को उसे स्वीकार करना पड़ता था। यह अभी भी काम करता है, लेकिन बड़े स्तर पर प्रभावी नहीं है और नए खातों को स्वतः सक्षम नहीं करता। प्रत्यायोजित व्यवस्थापक वाली संगठन विधि को प्राथमिकता दी जाती है, क्योंकि यह सदस्यता को केंद्रीकृत रूप से प्रबंधित करती है और नए सदस्यों को स्वतः सक्षम करती है; परीक्षण इसे आधुनिक सर्वोत्तम अभ्यास मानता है।

AWS Organizations और प्रत्यायोजित व्यवस्थापक (प्रबंधन खाते के बजाय एक समर्पित सुरक्षा खाता) के साथ GuardDuty को बड़े स्तर पर उपयोग करें। व्यवस्थापक सदस्य खातों में GuardDuty सक्षम करता है, नए खातों के लिए स्वतः-सक्षमीकरण का उपयोग करता है और सभी निष्कर्षों को केंद्रीय रूप से देखता है। याद रखें कि GuardDuty क्षेत्रीय सेवा है, इसलिए पूर्ण कवरेज के लिए इसे प्रत्येक क्षेत्र में सक्षम करें।