सक्रिय निर्देशिका ऑडिट: लक्ष्य, एक नियमित ऑडिट प्रणाली की कमियों और उन्हें दूर करने के तरीके

प्रिय खाबरोवित्स,
हम आपके ध्यान में डॉन जोन्स, एमवीपी, एक शीर्षक विशेषज्ञ और संयुक्त राज्य अमेरिका में एक बहुत लोकप्रिय लेखक की पुस्तक का एक अंश रूसी में अनुवादित करते हैं।

तीन "ए" सक्रिय निर्देशिका सुरक्षा (ईडी) हैं - प्रमाणीकरण, प्राधिकरण, ऑडिट। इस पोस्ट में, हम डॉन जोंस की पुस्तक एक्टिव डायरेक्ट्री ट्रबलशूटिंग, ऑडिटिंग और बेस्ट प्रैक्टिसेज से एक अनुवाद, एडी ऑडिटिंग के लिए समर्पित करेंगे।

स्टाफ ऑडिट टूल के उद्देश्य

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

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

स्टाफ ऑडिट सिस्टम

अनुमतियाँ एक्सेस कंट्रोल लिस्ट (DACL) पर लागू होती हैं। प्रत्येक DACL में एक या अधिक अभिगम नियंत्रण तत्व (ACE) होते हैं। ऐसे प्रत्येक तत्व में उपयोगकर्ता या समूह के संबंध में अनुमतियों के एक निश्चित सेट की अनुमति या निषेध है। DACL मॉडल तीन A में "प्राधिकरण" का हिस्सा है: AD आपको प्रमाणित करता है और एक अद्वितीय सुरक्षा पहचानकर्ता (SID) युक्त सुरक्षा टोकन प्रदान करता है। इस SID की तुलना एक्सेस कंट्रोल लिस्ट (DACL) में ACE के साथ की जाती है, ताकि यह तय किया जा सके कि इन संसाधनों को एक्सेस करते समय आपके पास क्या अनुमतियाँ हैं।
ऑडिटिंग एक समान तरीके से काम करता है। ऑब्जेक्ट एक्सेस कंट्रोल लिस्ट (SACL) में एक या अधिक प्रविष्टियाँ होती हैं। प्रत्येक प्रविष्टि उपयोगकर्ता या समूह द्वारा की गई एक विशिष्ट गतिविधि के लिए एक विशिष्ट कार्रवाई को इंगित करती है। SACL एक विशिष्ट संसाधन, जैसे कि फ़ाइल या निर्देशिका ऑब्जेक्ट के लिए बाध्य है, और जब किसी संसाधन पर कोई विशिष्ट कार्य किया जाता है, तो उसे लॉग किया जाता है। डिफ़ॉल्ट रूप से, "सफलता" और / या "विफलता" प्रकार के कार्यों को लॉग करना संभव है। इसका मतलब है कि आप पत्रिका में रिकॉर्ड करने का विकल्प चुन सकते हैं जब कोई व्यक्ति अपनी अनुमतियों का सफलतापूर्वक उपयोग करता है या जब उसने ऐसा करने की कोशिश की थी और इससे इनकार किया गया था। चित्र 1 AD के लिए SACL कॉन्फ़िगरेशन दिखाता है। जैसा कि आप देख सकते हैं, यह संसाधन - यूनिट डोमेन नियंत्रक - कॉन्फ़िगर किया गया है ताकि "सभी" समूह के सदस्यों के कुछ प्रकार के सफल कार्यों को रिकॉर्ड किया जा सके। यही है, जब कोई इन कार्यों को सफलतापूर्वक करता है, तो एक जर्नल प्रविष्टि बनाई जाती है।


चित्र 1: AD में SACL।

ऑडिट के अधीन कौन सी क्रियाएं होती हैं, यह इस बात पर निर्भर करता है कि आप किन संसाधनों के साथ काम करते हैं। उदाहरण के लिए, चित्रा 2 फाइल सिस्टम के एसएसीएल को दिखाता है, और आप देख सकते हैं कि विभिन्न प्रकार की क्रियाएं उपलब्ध हैं।


चित्र 2: एसएसीएल फाइल सिस्टम।

यहां आप यह चुन सकते हैं कि ऑडिट के अधीन क्या है, उदाहरण के लिए, फ़ोल्डर बनाना, विशेषताएँ पढ़ना, फ़ाइलों को हटाना और इसी तरह। इस प्रकार, प्रत्येक संसाधन का अपना SACL हो सकता है। व्यवहार में, हम में से अधिकांश एसएसीएल को काफी उच्च पदानुक्रम स्तर पर असाइन करते हैं और इस प्रकार इन सेटिंग्स को विरासत के माध्यम से निचले स्तर की वस्तुओं को प्रचारित करने की अनुमति देते हैं। इसलिए, SACL को अपेक्षाकृत कम स्थानों पर प्रबंधित किया जाता है। लेकिन हमें अभी भी प्रत्येक सर्वर और मुख्य सिस्टम के लिए उन्हें कम से कम एक कॉन्फ़िगर करना होगा। इसका क्या मतलब है: प्रत्येक सर्वर को कम से कम प्रत्येक लॉजिकल ड्राइव के रूट पर ऑब्जेक्ट्स के लिए अपनी एक्सेस कंट्रोल सूची की आवश्यकता होगी, हमें AD रूट और इसी तरह एक अलग सूची की आवश्यकता होगी।
अन्य उत्पाद इस योजना के अंतर्गत आ सकते हैं। और वे गिर न सकें। उदाहरण के लिए, Exchange सर्वर ऑडिटिंग के लिए समान संरचना का उपयोग करता है, लेकिन SQL सर्वर और SharePoint नहीं करते हैं। हालाँकि, यहाँ हम विशेष रूप से AD पर विचार कर रहे हैं।
जब ऑडिट को जगह लेने के लिए कॉन्फ़िगर किया जाता है, तो विंडोज एक ऑडिट रिकॉर्ड बनाता है। इस तरह की सभी प्रविष्टियों को सुरक्षा ईवेंट लॉग में संग्रहीत किया जाता है, जिसे चित्र 3 में दिखाया गया है। इस तरह के लॉग के साथ समस्या यह है कि हर घटना वहां हो जाती है। हालाँकि सभी घटनाओं को एक स्थान पर रखना अच्छा लगता है, समस्या यह है कि जब आपको इससे अलग रिकॉर्ड निकालने की आवश्यकता होती है, तो यह समस्याग्रस्त हो जाती है। एक बार फिर, यह इस तथ्य के कारण है कि Microsoft के पास सक्रिय निर्देशिका ऑडिट प्रणाली के बजाय संकीर्ण दृष्टिकोण है।


अंजीर। 3: सुरक्षा ईवेंट लॉग।

प्रत्येक Windows सर्वर में डोमेन नियंत्रक सहित अपने स्वयं के सुरक्षा ईवेंट लॉग होते हैं। हालाँकि AD में ऑब्जेक्ट के लिए एक्सेस कंट्रोल लिस्ट को किसी भी डोमेन कंट्रोलर पर कॉन्फिगर किया जा सकता है और बाद में बाकी के लिए रिप्लाई किया जा सकता है, लेकिन इस एक्शन को प्रोसेस करने वाले डोमेन कंट्रोलर ही इसके बारे में लॉग एंट्री बनाएंगे। परिणामस्वरूप: एक केंद्रीय रूप से कॉन्फ़िगर की गई ऑडिट नीति है, हालांकि, ऑडिट लॉग अत्यधिक फैला हुआ है।
चित्रा 4. दिखाता है कि ये ऑडिट रिकॉर्ड कैसे दिखते हैं। उनमें अक्सर कच्चे सुरक्षा पहचानकर्ता और अन्य गैर-स्पष्ट जानकारी शामिल होती है। यह उदाहरण मूल Kerberos प्रोटोकॉल का उपयोग करके संसाधित किए गए सफल डोमेन कनेक्शन दिखाता है। उपयोगकर्ता नाम और डोमेन इस उदाहरण में रिक्त हैं, लेकिन वे आमतौर पर आबादी वाले हैं।


चित्र 4: उदाहरण ऑडिट रिकॉर्ड।

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


चित्र 5: नई और पुरानी पत्रिकाएँ।

एक्सेस कंट्रोल डिफरेंशियल एक्सेस लिस्ट (DACL) के विपरीत, ऑब्जेक्ट एक्सेस कंट्रोल लिस्ट (SACL) तुरंत ऑपरेटिंग सिस्टम द्वारा उपयोग नहीं किया जाता है। एसएसीएल बस इंगित करता है कि किन गतिविधियों का ऑडिट किया जाता है; ऑडिट सिस्टम को भी सक्षम होना चाहिए ताकि ईवेंट लॉग में रिकॉर्ड किए जा सकें। चित्रा 6 से पता चलता है कि यह आमतौर पर जीपीओ में कहां कॉन्फ़िगर किया गया है।
अधिकांश संगठन उच्च-स्तरीय GPO में ऑडिटिंग को कॉन्फ़िगर करेंगे, जैसे सभी डोमेन नियंत्रकों या यहां तक ​​कि डोमेन के सभी सर्वर पर लागू होते हैं। निर्दिष्ट GPO एक ऑडिट नीति स्थापित करने को संदर्भित करता है, जिसमें लॉगिन इवेंट / कनेक्शन, खाता प्रबंधन क्रियाओं, AD तक पहुंच और इतने पर ऑडिटिंग सक्षम करना शामिल है। वांछित लेखापरीक्षा घटनाओं को उत्पन्न करने के लिए SACL संसाधनों की तरह एक ऑडिट नीति को कॉन्फ़िगर किया जाना चाहिए।


अंजीर। 6: GPO में ऑडिटिंग कॉन्फ़िगर करें।

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


चित्र 7: GPO में ईवेंट लॉग को कॉन्फ़िगर करना।

एप्लिकेशन लॉग के विपरीत, जिसके साथ आप शांत हो सकते हैं जब यह ओवरराइट हो जाता है क्योंकि यह भरा हुआ है, सुरक्षा लॉग में इसकी अनुमति नहीं दी जा सकती है, क्योंकि महत्वपूर्ण जानकारी खो सकती है। इसलिए, आपको लॉग पर लोड के आधार पर, उचित लॉग आकार सेट करना होगा और लॉग को नियमित रूप से साफ़ और लॉग को साफ़ करने के लिए रूटीन सेट करना होगा।
नियमित रूप से विंडोज ईवेंट लॉग की आलोचना की जाती है कि वे बहुत बिखरे हुए हैं। उदाहरण के लिए, एक व्यवस्थापक एक समूह नियंत्रक पर समूह सदस्यता बदल सकता है, इस समूह में एक खाते का उपयोग करने के लिए दूसरे डोमेन नियंत्रक से जुड़ सकता है और इस समूह की सदस्यता को रीसेट करने के लिए एक तीसरे नियंत्रक से जुड़ सकता है। सभी तीन घटनाओं को तीन अलग-अलग सुरक्षा इवेंट लॉग में दर्ज किया जाएगा, जो इन घटनाओं के बीच संबंध स्थापित करने की प्रक्रिया को जटिल बनाता है।
Microsoft ने Windows Server 2008 में इस समस्या का जो समाधान प्रस्तावित किया था, वह था इवेंट फ़ॉरवर्डिंग। चित्र 8 दिखाता है कि कैसे व्यक्तिगत सर्वर केंद्रीय सर्वर पर घटनाओं को आगे बढ़ाते हैं, जो सभी घटनाओं को अपने लॉग में एकत्रित करता है।


अंजीर। 8: ईवेंट लॉग को अग्रेषित करना।

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

ऑडिटिंग परिवर्तन के लिए सामान्य व्यावसायिक लक्ष्य

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

नियमित ऑडिट टूल का नुकसान

दुर्भाग्य से, एक पूर्णकालिक ऑडिट प्रणाली ने खुद को बहुत अच्छी तरह से साबित नहीं किया है। अंततः, यह माइक्रोसॉफ्ट की गलती नहीं है - आखिरकार, उनका काम किसी भी व्यवसाय की आवश्यकता का अनुमान लगाना नहीं है, बल्कि एक ऐसा मंच प्रदान करना है जिस पर अन्य कंपनियां सॉफ्टवेयर विकसित कर सकती हैं जो व्यवसाय की विशिष्ट आवश्यकताओं को पूरा कर सकती हैं। यही उन्होंने किया। एक पूर्णकालिक ऑडिट प्रणाली एक मूल समाधान है जो सबसे छोटे संगठनों के लिए उपयुक्त है जो अतिरिक्त कार्यक्रमों को खरीदने के लिए मुश्किल से खर्च कर सकते हैं।
लक्ष्य # 1 - सभी घटनाओं का ऑडिट - विंडोज का उपयोग करने के लिए स्पष्ट रूप से संभव है, हालांकि आपको लॉग और सर्वर प्रदर्शन के आकार को ध्यान में रखना होगा। ईवेंट लॉग की नियमित वास्तुकला पारदर्शी नहीं है, क्योंकि हम इसे देखना चाहते हैं, और प्रति घंटे हजारों घटनाओं को रिकॉर्ड करना निश्चित रूप से सर्वर को प्रभावित करेगा।
लक्ष्य संख्या 2 - पत्रिका में परिवर्तन करने की क्षमता - प्रणाली में एक अड़चन। दुर्भाग्य से, प्रशासकों द्वारा लॉग को साफ करने की संभावना को बाहर करना लगभग असंभव है। आप ठीक-ट्यूनिंग विशेषाधिकारों द्वारा कर सकते हैं, पत्रिकाओं और इतने पर के साथ काम करने के लिए विशेष खाते बनाना, हालांकि, कई संगठनों के लिए यह मुश्किल और अव्यवहारिक है।
मान लीजिए आपने ऐसा किया। आपके पास लक्ष्य संख्या 3 है - रिपोर्ट, अलर्ट और फ़िल्टरिंग घटनाओं की केंद्रीकृत पीढ़ी। फ़ॉरवर्डिंग ईवेंट लॉग, भले ही ऐसा होता है, वास्तविक समय में प्रदर्शन नहीं किया जाता है, महत्वपूर्ण देरी संभव है। लेकिन यहां तक ​​कि अगर आप ईवेंट लॉग को रीडायरेक्ट करते हैं, तो सभी जानकारी एक ही स्थान पर आती है, जहां से इसे आदिम दृश्य दर्शक का उपयोग करके निकाला जा सकता है। चित्रा 9 मानक उपकरणों की फ़िल्टरिंग क्षमताओं को दर्शाता है, और वे निश्चित रूप से, आदिम हैं।


अंजीर। 9: स्थापित इवेंट लॉग फ़िल्टरिंग उपकरण।

जैसा कि चित्र में दिखाया गया है, आप ईवेंट प्रकार या विशेष विवरण में ईवेंट विवरण के साथ-साथ अन्य मानदंडों द्वारा फ़िल्टर कर सकते हैं। लेकिन विभिन्न संबंधित घटनाओं के बीच संबंध स्थापित करने की कोई संभावना नहीं है।
समस्याओं को हल करने के लिए इन घटनाओं के उपयोग के लिए - अच्छी तरह से, सौभाग्य! यह, ज़ाहिर है, संभव है, लेकिन आमतौर पर यह इस तरह दिखता है: "लॉग में देखें, देखें कि घटना के पहचानकर्ता का क्या मतलब है, और यह निर्धारित करें कि क्या यह वास्तविक समस्या से संबंधित है।" नियमित इवेंट व्यूअर के लिए "पिछले 4 घंटों में AD में सभी परिवर्तन" प्रश्न का उत्तर देना काफी मुश्किल है। यद्यपि इन परिवर्तनों से संबंधित घटनाओं को जर्नल में प्रदर्शित किया जाएगा - आपने उन्हें रिकॉर्ड करने के लिए एक ऑडिट नीति बनाई है - इवेंट लॉग का उद्देश्य परिवर्तनों को प्रबंधित करने या उन्हें ऑडिट करने के कार्य को पूरा करना नहीं है। यह इस शब्द के अर्थ में परिवर्तनों का ऑडिट नहीं है, बल्कि इस तथ्य का ऑडिट है कि किसी ने बदलाव किया है।
जैसा कि चित्र 10 में दिखाया गया है, AD Windows Server 2008 ने प्रत्येक परिवर्तन के "पहले" और "बाद" मूल्यों को रिकॉर्ड करना शुरू कर दिया, जो परिवर्तनों की ऑडिटिंग के लिए अधिक उपयुक्त बनाता है। हालांकि, यह फ़ंक्शन AD में बहुत आम नहीं है और एक बड़े लॉग में आवश्यक घटनाओं को ढूंढना अभी भी समस्याग्रस्त है।


चित्र 10: विंडोज सर्वर 2008 में बेहतर इवेंट व्यू।

अधिकांश अवसंरचनाओं में, एक प्रभावी ऑडिट नीति का तात्पर्य तृतीय-पक्ष समाधानों का उपयोग है।

तीसरे पक्ष की क्षमताएं

थर्ड-पार्टी ऑडिट टूल के कई फायदे हैं।
सबसे पहले, वे बेहतर (और तेज) एक केंद्रीकृत भंडार में विभिन्न सर्वर लॉग से जानकारी एकत्र करते हैं। अक्सर यह केंद्रीयकृत रिपॉजिटरी एसक्यूएल सर्वर डेटाबेस है, हालांकि व्यक्तिगत उपकरण वास्तविक समय की घटनाओं को एक बाहरी लॉगिंग तंत्र में भेज सकते हैं, जैसे कि एक syslog सर्वर, जैसा कि चित्र 11 में दिखाया गया है।


चित्र 11: syslog सर्वर पर ईवेंट अग्रेषित करना

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