समूह नीतियों में खो जाने के लिए कैसे नहीं: हम उनकी ऑडिट करते हैं

स्थिति की कल्पना करें, आप एक बड़ी कंपनी की आईटी सेवा का प्रबंधन करते हैं, आपके पास सक्रिय निर्देशिका में कई डोमेन और कई हजार उपयोगकर्ता हैं। कम से कम कई सिस्टम प्रशासक आपके अधीनस्थ हैं, जिनमें से प्रत्येक अपने कर्तव्यों का पालन करता है। अचानक से किसी एक विभाग के कर्मचारी शिकायत करते हैं कि पुराने के समाप्त होने के बाद वे नए पासवर्ड के साथ नहीं आ सकते हैं - सिस्टम नए बनाए गए पासवर्ड को स्वीकार नहीं करता है। संबंधित विभाग की पासवर्ड नीति पर त्वरित नज़र डालने के बाद, आप समझते हैं कि पासवर्ड की लंबाई और जटिलता बदल दी गई है। यह पता लगाने के लिए कि यह किस कारण से हुआ, आप इवेंट लॉग में जाते हैं और समझते हैं कि इस बारे में कोई जानकारी नहीं है कि पासवर्ड पॉलिसी कब और किसके द्वारा बदली गई थी - लॉग पहले ही ओवरराइट हो चुके थे। नीति किसने बदली यह एक रहस्य बना रहेगा।

और यहां एक और उदाहरण है: व्यवस्थापक को अचानक पता चलता है कि उपयोगकर्ताओं में से कोई भी बिना किसी समस्या के अपनी मशीन पर सॉफ़्टवेयर स्थापित कर सकता है । और यह इस तथ्य के बावजूद कि ओयू के लिए समूह नीति में, जिसमें उपयोगकर्ता एक सदस्य है, इस तरह की स्थापना निषिद्ध थी। फिर, इस तरह की स्थापना को किसने और कब सक्षम किया, इसके बारे में जानकारी, घटना लॉग में मांगी जानी चाहिए, जो कि बिना सूचना के "शोर" के माध्यम से होती है।

यह सब एक अस्पष्ट निष्कर्ष की ओर जाता है। कंपनी की आईटी सेवा को समूह नीतियों में होने वाले परिवर्तनों पर ध्यान देना चाहिए। सूचना सुरक्षा प्रणाली में छेद के गठन को रोकने के लिए ऐसा करना आवश्यक है ("लापरवाह उपयोगकर्ता किस तरह का सॉफ़्टवेयर डालता है?") और व्यापार निरंतरता सुनिश्चित करें (जब एक ही समय में 200 लोग अपनी मशीनों में प्रवेश नहीं कर सकते, क्योंकि वे एक उपयुक्त के साथ आने में असमर्थ हैं। पासवर्ड)।
केवल व्यवहार में यह पता चलता है कि समूह नीतियों में परिवर्तन पर शायद ही कोई नियंत्रण करता है । और केवल जब कोई समस्या होती है या संदिग्ध गतिविधि का पता चलता है, तो समस्या के स्रोत की खोज घटना लॉग और साक्षात्कार सहयोगियों का विश्लेषण करके शुरू होती है।

हालांकि, न केवल समस्या के कारणों का पता लगाना महत्वपूर्ण है, बल्कि इसकी उपस्थिति को भी रोकना है। समूह नीतियों के मामले में, इसमें कोई संदेह नहीं है कि व्यवस्थापक यह जानना चाहेंगे कि पासवर्ड नीति को बदल दिया गया है और उन उपयोगकर्ताओं के कॉल के शाफ्ट से पहले आवश्यक कार्रवाई करें, जिनके काम में अब तेजी आ गई है।
ऐसी घटनाओं की तुरंत जांच और रोकथाम के लिए, आपको समूह नीतियों में होने वाले परिवर्तनों के बारे में पता होना चाहिए। आप नियमित रूप से इस समस्या को हल करने का प्रयास कर सकते हैं।

उदाहरण के लिए, इवेंट लॉग को मैन्युअल रूप से देखें। हालाँकि, भले ही हमने पहले ही ऑडिट सेट कर लिया हो और जर्नल में डेटा की संभावित ओवरराइटिंग का ध्यान रखा हो, लेकिन जर्नल की घटनाओं का प्रदर्शन उपयोगकर्ताओं की शिकायतें आने के बाद ही होगा। और यह केवल अपराधी को खोजने में मदद करेगा, और समस्या को रोकने में नहीं।

Windows Server 2008 R2 में, परिवर्तनों को ट्रैक करने (और समस्याओं को रोकने) की प्रक्रिया थोड़ी आसान है। अधिक सुविधाजनक ईवेंट व्यूअर के साथ, कुछ घटनाओं के लिए ईमेल अलर्ट कॉन्फ़िगर करना संभव है, जो आपको एक कदम आगे रहने की अनुमति देता है, क्योंकि अब अंतिम उपयोगकर्ता तक पहुंचने से पहले स्थिति को सही करने का अवसर है।

हालाँकि, Windows Server 2008 R2 में मानक ऑडिट क्षमताओं के विस्तार के साथ, कई आक्रामक कारक एक ही बार में उत्पन्न होते हैं। क्या घटनाओं का चयन करने के लिए? जब एक ही नंबर वाली घटनाओं में अलग-अलग ऑब्जेक्ट्स के बारे में जानकारी हो सकती है, तो अपनी सामग्री को जल्दी से कैसे फ़िल्टर करें (उदाहरण के लिए, इवेंट 4662 समूह नीति परिवर्तनों के लिए और सक्रिय निर्देशिका में अन्य ऑब्जेक्ट्स के लिए दोनों उत्पन्न होता है)? घटनाओं में केवल एक GUID होता है, एक विशिष्ट समूह नीति का नाम नहीं होता है, जो GUID'A मान्यता प्रक्रिया को पूरा करने के लिए आवश्यक घटना प्राप्त करने के बाद मजबूर करता है। लेकिन अगर दर्जनों ऐसे आयोजन हों तो क्या होगा?

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

बेशक, पूर्णकालिक ऑडिट प्रणाली के उपयोग से होने वाले परिवर्तनों पर कुछ नियंत्रण होता है, लेकिन फिर भी निम्नलिखित कमियों से बचा नहीं जा सकता है:

1. घटनाओं में परिवर्तन के बारे में जानकारी का विश्लेषण बल्कि श्रमसाध्य है, धारणा के लिए कुछ ज्ञान की आवश्यकता होती है, और उन लोगों को अपने मूल रूप में प्रस्तुत नहीं किया जा सकता है जो इन मुद्दों में बहुत अच्छी तरह से वाकिफ नहीं हैं (उदाहरण के लिए, शीर्ष प्रबंधन)
2. प्रत्येक डोमेन नियंत्रक पर सुरक्षा लॉग का मैन्युअल रूप से विश्लेषण किया जाना चाहिए
3. कोई डेटा समेकन नहीं
4. लॉग पुनर्लेखन - घटना हानि संभव
5. केवल परिवर्तन का तथ्य दर्ज किया गया है, वास्तव में क्या बदल गया है, इसके बारे में कोई स्पष्ट जानकारी नहीं है

और बहुत कुछ ...

आंशिक रूप से ऊपर बताई गई समस्याएँ विभिन्न लॉग प्रोसेसिंग विधियों (स्क्रिप्ट और उपयोगिताओं से शुरू होने की अनुमति देती हैं जो विशेष एसईएम समाधानों के लिए लॉग विश्लेषण की अनुमति देती हैं)। हालांकि, वे वर्णित सभी समस्याओं का समाधान नहीं करते हैं। उदाहरण के लिए, वे प्रत्येक परिवर्तन के लिए "पहले" और "बाद में" मूल्यों को नहीं दिखाते हैं, जिसके परिणामस्वरूप व्यवस्थापक को मैन्युअल रूप से समूह नीतियों की वर्तमान सेटिंग्स के साथ संग्रह को बनाए रखना होगा।

एक पूर्णकालिक ऑडिट प्रणाली के नुकसान और आईटी अवसंरचना प्रबंधन की बढ़ती आवश्यकता के कारण ऑडिट परिवर्तनों के लिए तृतीय-पक्ष विशेष समाधानों का उदय होता है। ऊपर वर्णित नियमित प्रणाली की कमियों के आधार पर, हम यह निर्धारित करेंगे कि समूह नीतियों के ऑडिटिंग के निर्णयों के तहत कौन-कौन सी विशेषताएं हैं :

• "पहले" और "बाद" परिवर्तनों के रूप में वस्तु के बदले हुए मूल्य का प्रदर्शन,
• परिवर्तनों की स्वचालित पीढ़ी जो समय की एक विशिष्ट अवधि में हुई है (उदाहरण के लिए, हर 12 घंटे या दिन),
• डेटा को फ़िल्टर करने और व्यक्तिगत नीतियों में बदलाव के बारे में जानकारी प्राप्त करने की क्षमता,
• प्रदान की गई जानकारी की अस्पष्ट दृश्यता (जो, क्या, कहाँ और कब बदली),
• एक विशेष रिपॉजिटरी (एक SQL डेटाबेस में, एक फ़ाइल सर्वर पर एक संग्रह में, या दोनों स्थानों पर एक बार) में ऑडिट डेटा स्टोर करने की क्षमता,
• समूह नीति बैकअप और पुनर्स्थापना।

हम लेख में इन समाधानों में से एक पर विचार करेंगे - हमारा कार्यक्रम नेटवर्क्स ग्रुप पॉलिसी चेंज रिपोर्टर , जो समूह नीतियों में परिवर्तन का ऑडिट करता है। सबसे पहले, हम आपको बताएंगे कि उत्पाद कैसे काम करता है।

1. डेटा संग्रह के दौरान, उत्पाद समूह नीतियों की वर्तमान स्थिति का स्नैपशॉट लेता है और उन सभी डोमेन नियंत्रकों से सुरक्षा लॉग से जानकारी एकत्र करता है जिसमें ऑडिट किया जाता है।
2. डेटा एकत्र करने के बाद, उन्हें निर्दिष्ट भंडारण स्थान में जोड़ा जाता है (उदाहरण के लिए, एक समर्पित फ़ाइल सर्वर के लिए), जिसके बाद उनका विश्लेषण किया जाता है। पाया गया परिवर्तन डेटाबेस (यदि यह उत्पाद से जुड़ा हुआ है) पर अपलोड किया जाता है, और निर्दिष्ट पते पर एक रिपोर्ट के रूप में भी भेजा जाता है। ई-मेल एड्रेस।
3. डेटा संग्रह का प्रारंभ कार्य शेड्यूलर पर आधारित है, जिसमें एक शेड्यूल किया गया कार्य बनाया जाता है (स्वचालित रूप से उत्पाद कॉन्फ़िगरेशन के दौरान), जो डेटा संग्रह शुरू करता है।
4. डिफ़ॉल्ट रूप से, रिपोर्ट दिन में एक बार (दोपहर 3 बजे) भेजी जाती है और इसमें पिछले 24 घंटों में बदलावों की जानकारी होती है। हालाँकि, रिपोर्ट भेजने की आवृत्ति और समय को आसानी से बदला जा सकता है। साथ ही, रिपोर्ट भेजना किसी भी समय मैन्युअल रूप से शुरू किया जा सकता है।

कार्य कार्यक्रम:

उत्पाद के परिणामों पर विचार करें, अर्थात्, इस लेख की शुरुआत में वर्णित परिदृश्य को पुन: पेश करें - कंपनी एन के मुख्य कार्यालय (केंद्रीय कार्यालय) के विभाजन पर लागू नीति को संपादित करें:

• 7 से 14 अक्षरों की न्यूनतम पासवर्ड लंबाई बदलें
• 45 दिनों से 20 तक अधिकतम पासवर्ड कम करें
• पासवर्ड जटिलता सक्षम करें (पासवर्ड जटिलता आवश्यकताओं को पूरा करें)
• उपयोगकर्ताओं को सॉफ़्टवेयर इंस्टॉल करने दें

इसलिए, डेटा संग्रह पूरा हो गया है, और हमें निम्नलिखित सामग्री की रिपोर्ट प्राप्त हुई है:



अधिक जानकारी



रिपोर्ट नेत्रहीन हमारे द्वारा किए गए परिवर्तनों को प्रदर्शित करती है। हमारे उदाहरण में, प्रशासक, जॉन स्मिथ ने गलती से अधिकतम पासवर्ड की आयु 45 से घटाकर 20 दिन कर दी, जिससे कुछ उपयोगकर्ताओं को पासवर्ड 25 दिन पहले समाप्त हो गया, इसके अलावा, न्यूनतम पासवर्ड की लंबाई 7 वर्णों से बढ़ गई - उपयोगकर्ताओं के लिए प्रतीक्षा करने वाली स्थिति की कल्पना करें?

जॉन स्मिथ ने ये बदलाव कार्यदिवस के अंत में रात 8:13 बजे के बाद किए थे, और रिपोर्ट तीन रातों में उत्पन्न हुई थी। इस प्रकार, सुबह में प्रशासक को सुबह के परिवर्तनों के बारे में पता था और समस्या में बदलने से पहले उन्हें ठीक करने में कामयाब रहे।
जैसा कि आप देख सकते हैं, रिपोर्ट में प्रत्येक परिवर्तन के लिए "पहले" और "बाद में" मान शामिल हैं। जो बदलाव की आलोचनात्मकता का आकलन करने के लिए बहुत सुविधाजनक है।

रिपोर्ट का ढांचा निम्नलिखित सिद्धांत पर बनाया गया है:

• किस प्रकार का परिवर्तन किया गया था (बदलें प्रकार)
• जब बदल गया
• जिसने बदल दिया
• जहां बदलाव हुआ, यानी किस डोमेन नियंत्रक पर (कहां बदला गया)
• कौन सी समूह नीति ऑब्जेक्ट बदली गई थी और कौन से परिवर्तन किए गए थे (समूह नीति ऑब्जेक्ट)

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

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



SQL रिपोर्टिंग सेवा (उन्नत रिपोर्ट) के आधार पर एक अलग आइटम को रिपोर्ट की लाइब्रेरी नोट किया जाना चाहिए:



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



यदि हम किसी विशिष्ट नीति सेटिंग में बदलाव के लिए इच्छुक हैं, तो हम उपयुक्त रिपोर्ट का उपयोग कर सकते हैं, उदाहरण के लिए, पॉलिसी सेटिंग्स में परिवर्तन जो प्रशासनिक टेम्पलेट परिवर्तन का हिस्सा हैं:



यह ध्यान देने योग्य है कि पुस्तकालय में शामिल प्रत्येक रिपोर्ट के लिए, एक सदस्यता को कॉन्फ़िगर किया जा सकता है जिसके अनुसार रिपोर्ट को निर्दिष्ट अनुसूची के अनुसार निर्दिष्ट ईमेल पते पर स्वचालित रूप से वितरित किया जाएगा।

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

डेटा अवधारण अवधि केवल कंपनी के आंतरिक लक्ष्यों द्वारा सीमित है। इस प्रकार, आप सुनिश्चित हो सकते हैं कि अतीत में किए गए किसी भी बदलाव के बारे में जानकारी जल्दी से प्राप्त की जा सकती है और उसका विश्लेषण किया जा सकता है। उदाहरण के लिए, पिछले एक वर्ष में पासवर्ड नीति में परिवर्तन के बारे में पूर्वव्यापी जानकारी प्राप्त करें। व्यक्तिगत उद्योगों के लिए सूचना सुरक्षा नियमों द्वारा ऐसी कई रिपोर्टों की आवश्यकता होती है।

यह भी जोड़ने योग्य है कि उत्पाद स्वचालित रूप से समूह नीतियों का बैकअप बनाता है, जिसका उपयोग बाद में किए गए परिवर्तनों को वापस करने और नीतियों को पुनर्स्थापित करने के लिए किया जा सकता है।

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

पुनश्च कार्यक्रम बुनियादी मुक्त और पूर्ण संस्करणों में उपलब्ध है। आप अपने मतभेदों से खुद को परिचित कर सकते हैं और हमारी वेबसाइट पर कार्यक्रम डाउनलोड कर सकते हैं।