ऑडिट ट्रेल (audit trail) हा एक सुरक्षित, कालक्रमानुसार असलेला रेकॉर्ड आहे जो सिस्टममध्ये कोणी, काय, कुठे आणि कधी केले हे दर्शवतो आणि UK मध्ये कमकुवत ऑडिट ट्रेल दस्तऐवजीकरणामुळे १५% FCA अंमलबजावणी प्रकरणांमध्ये दोष आढळले आहेत, ज्यामध्ये अपुरी व्यवहार लॉगिंग आणि मॉनिटरिंगमुळे £५०० दशलक्षपेक्षा जास्त दंड आकारला गेला आहे. हे फायनान्समध्ये जितके महत्त्वाचे आहे तितकेच WiFi आणि नेटवर्क ॲक्सेसमध्ये देखील महत्त्वाचे आहे, कारण जर तुम्ही वापरकर्ता सेशन, ऑथेंटिकेशन इव्हेंट किंवा ॲडमिन बदलाची पुनर्रचना करू शकत नसाल, तर तुम्ही काय घडले हे सिद्ध करू शकत नाही.
तुम्ही गेस्ट WiFi, स्टाफ SSOs, शेअर केलेले ऑफिस फ्लोअर्स, स्टुडंट हाऊसिंग किंवा मल्टिपल टेनंट नेटवर्क असलेल्या हॉटेलशी संबंधित काम करत असल्यास, तुम्हाला कदाचित अशा प्रसंगाचा सामना करावा लागला असेल जिथे विचारलेला एक साधा प्रश्न एका कठीण तपासात बदलतो. ते डिव्हाइस कोणी कनेक्ट केले? वापरकर्त्याला चुकीच्या VLAN वर का ठेवण्यात आले? अयशस्वी लॉगइन खऱ्या कर्मचाऱ्याकडून झाले होते, जुन्या झालेल्या सर्टिफिकेटमुळे झाले होते की जुने क्रेडेंशियल्स पुन्हा वापरण्याचा प्रयत्न करणाऱ्या डिव्हाइसमुळे झाले होते?
तिथेच ऑडिट ट्रेल म्हणजे काय हा केवळ एक सैद्धांतिक कंप्लायन्स शब्द न राहता व्यावसायिकदृष्ट्या उपयुक्त ठरतो. व्यवहारात, हे एखाद्या इमारतीचे CCTV फुटेज आणि तिच्या ॲक्सेस कंट्रोल लॉगच्या डिजिटल समतुल्य आहे. तुम्हाला असा रेकॉर्ड हवा असतो जो तुम्हाला हालचालींचा माग घेण्यास, ओळख सत्यापित करण्यास आणि एखादी कृती कायदेशीर, अपघाती किंवा दुर्भावनापूर्ण होती हे सिद्ध करण्यास मदत करतो.
ऑडिट ट्रेल म्हणजे काय (What is an Audit Trail)
याची एक उपयुक्त व्याख्या खालीलप्रमाणे आहे. ऑडिट ट्रेल हा घटनांचा छेडछाड-मुक्त (tamper-evident), वेळेनुसार क्रमबद्ध केलेला रेकॉर्ड आहे जो तुम्हाला सुरुवातीपासून शेवटपर्यंतच्या क्रियेची पुनर्रचना करू देतो. IT सुरक्षेमध्ये, याचा सामान्यतः अर्थ वापरकर्ता, डिव्हाइस, सिस्टम किंवा व्यवहाराशी संबंधित एंट्रीजचा क्रम असा होतो. आयडेंटिटी-आधारित WiFi मध्ये, याचा अर्थ तुम्ही सुरुवातीच्या ऑथेंटिकेशनपासून ते पॉलिसी असाइनमेंट, सेशन क्रियाकलाप, ॲक्सेस स्थितीतील बदल आणि शेवटी डिस्कनेक्ट होण्यापर्यंतच्या कनेक्शनचा मागोवा घेऊ शकता.
एखाद्या सामान्य घटनेचा विचार करा. एक व्हेन्यू मॅनेजर सांगतो की एका पाहुण्याला नकळत प्रतिबंधित नेटवर्कवर ठेवण्यात आले होते. एक सुरक्षा विश्लेषक स्टाफ डिव्हाइसवरून वारंवार ऑथेंटिकेशन अयशस्वी झाल्याचे पाहतो. एक ऑडिटर पुरावा मागतो की केवळ अधिकृत वापरकर्त्यांनीच विशिष्ट सेवेचा वापर केला आहे. तुमच्याकडे विसंगत टाइमस्टॅम्प असलेले काही सामान्य लॉग्स असल्यास, तुम्ही फक्त अंदाज लावत आहात. जर तुमच्याकडे योग्य ऑडिट ट्रेल असेल, तर तुम्ही पुराव्यासह उत्तर देऊ शकता.
सिस्टम लॉग इव्हेंट रेकॉर्ड करतो. ऑडिट ट्रेल तुम्हाला त्या घटनांची कथा एका खात्रीशीर क्रमाने सांगू देतो.
नेटवर्क टीम्ससाठी, महत्त्वाचा भाग शब्दकोशातील अर्थ नाही. तर रेकॉर्डने काही मूलभूत प्रश्नांची उत्तरे स्पष्टपणे दिली पाहिजेत ही व्यावहारिक गरज आहे:
कोणी कृती केली
एक वास्तविक ओळख (real identity), सर्व्हिस अकाउंट किंवा डिव्हाइस आयडेंटिटीकाय घडले
लॉगइन, अयशस्वी ऑथेंटिकेशन, रोल बदलणे, पॉलिसी पुश, सर्टिफिकेट जारी करणे, डिस्कनेक्ट, ॲडमिन संपादन (admin edit)कुठे घडले
संबंधित सिस्टीम, SSID, कंट्रोलर, ॲप्लिकेशन, टेनंट किंवा रिसोर्सते कधी घडले
तुमच्या इतर नेटवर्क पर्यावरणाशी जुळणारा एक विश्वासार्ह टाईमस्टॅम्पते यशस्वी झाले की नाही
यशस्वी, अपयशी, टाईमआऊट, नाकारले गेलेले, किंवा अंशतः पूर्ण झालेले
आधुनिक WiFi वातावरणात, हे महत्त्वाचे आहे कारण ॲक्सेस कंट्रोल आता फक्त "वापरकर्त्याने योग्य पासवर्ड टाईप केला का?" एवढ्यापुरता मर्यादित राहिलेला नाही. हे आयडेंटिटी, पोश्चर, फेडरेशन, रोमिंग, सेगमेंटेशन, टेनंट बाउंड्रीज आणि वेगाने होणारे पॉलिसीचे निर्णय यावर अवलंबून असते. ऑडिट ट्रेलशिवाय, झिरो - ट्रस्टच्या दाव्यांचे समर्थन करणे कठीण आहे.
ऑडिट ट्रेल्स व्यवसायासाठी का आवश्यक आहेत
ऑडिट ट्रेल्सकडे दुर्लक्ष करणे हा एक व्यावसायिक धोका आहे, केवळ एक तांत्रिक त्रुटी नाही. UK मध्ये, Companies Act 1985 पासून ऑडिट ट्रेल्स हा आर्थिक प्रशासनाचा एक महत्त्वाचा पाया राहिला आहे, आणि FCA ने त्यांच्या 2022/23 च्या अहवालात नमूद केले आहे की ऑडिट ट्रेल दस्तऐवजीकरणातील अपयशामुळे 15% अंमलबजावणी प्रकरणांमध्ये भर पडली, ज्यामुळे अपुऱ्या ट्रान्झॅक्शन लॉगिंग आणि मॉनिटरिंगसाठी £500 दशलक्ष पेक्षा जास्त दंड आकारला गेला. GDPR नंतर ॲक्सेस कंट्रोलमध्ये अपुऱ्या ऑडिट ट्रेल्समुळे 68% दंड आकारण्यात आल्याचे ICO ने देखील नोंदवले आहे, ज्याचा सारांश या ऑडिट ट्रेल ओव्हरव्ह्यूमध्ये दिला आहे.
हा झाला नियामक बाजूचा भाग. ऑपरेशनल बाजूचा विचार केल्यास, कमकुवत ऑडिडेबिलिटीमुळे छुपे नुकसान होते. सुरक्षा टीम्सना तपास करण्यासाठी जास्त वेळ खर्च करावा लागतो. नेटवर्क इंजिनियर्स चुकीच्या बदलाचा नेमका स्रोत शोधू शकत नाहीत. युझरची तक्रार वैध आहे की नाही हे सिद्ध करण्यासाठी व्हेन्यू ऑपरेटर्सना संघर्ष करावा लागतो. फायनान्स आणि कंप्लायन्स टीम्स शेवटी स्क्रीनशॉट्स, एक्सपोर्ट्स आणि काय घडले याच्या कोणाच्या तरी आठवणीवर अवलंबून राहतात.
सुरक्षा संरक्षण
आयडेंटिटी - आधारित नेटवर्कमध्ये, गैरवापराची सुरुवातीची चिन्हे शोधण्यासाठी ऑडिट ट्रेल्स ही पहिली जागा असते. जेव्हा रेकॉर्ड योग्यरित्या स्ट्रक्चर केलेले असतात, तेव्हा वारंवार अयशस्वी ऑथेंटिकेशन्स, ॲक्सेस रोलमध्ये अचानक झालेले बदल, वेगवेगळ्या लोकेशन्समध्ये असामान्य रोमिंग वर्तन, किंवा सामान्य वेळेव्यतिरिक्त ॲडमिनने पॉलिसीमध्ये केलेले बदल हे सर्व स्पष्टपणे दिसून येतात.
घटना घडून गेल्यानंतर शेअर्ड पासवर्डवरून तुम्हाला काहीच माहिती मिळत नाही. परंतु युझर - बाउंड इव्हेंट ट्रेल तुम्हाला बरीच माहिती देतो.
- गेस्ट नेटवर्क्सना याचा फायदा होतो कारण तुम्ही एका खऱ्या परत आलेल्या पाहुण्याला संशयास्पद रिपीट कनेक्शन पॅटर्नपासून वेगळे ओळखू शकता.
- स्टाफ ॲक्सेसचे मॉनिटरिंग करणे सोपे होते कारण SSO इव्हेंट्स एखाद्या विशिष्ट नावाच्या आयडेंटिटीशी जोडले जाऊ शकतात.
- मल्टी - टेनंट नेटवर्क्स अधिक सुरक्षित होतात कारण आयसोलेशनचे नियम अपेक्षेप्रमाणे लागू झाले आहेत की नाही हे तुम्ही पडताळून पाहू शकता.
डिजिटल फॉरेन्सिक्स
एखाद्या घटनेदरम्यान, सर्वात वाईट परिणाम "आम्हाला संशयास्पद क्रियाकलाप आढळले" हा नसतो. सर्वात वाईट परिणाम म्हणजे "आम्ही काय घडले हे सिद्ध करू शकत नाही". Audit trails हे तुमचे पुनर्रचना स्तर (reconstruction layer) आहेत. ते तुम्हाला टाइमलाइन तयार करण्यात, बदलांचा परस्परसंबंध जोडण्यात आणि मुख्य कारणांना इतर निरर्थक गोष्टींपासून वेगळे करण्यास मदत करतात.
व्यावहारिक नियम: जर तुमचे नेटवर्क प्लॅटफॉर्म एकाच टाइमलाइनमध्ये आयडेंटिटी इव्हेंट्स, पॉलिसी निर्णय आणि ॲडमिन बदल दाखवू शकत नसेल, तर तुमची फॉरेन्सिक प्रक्रिया अपेक्षेपेक्षा संथ होणार आहे.
हे सायबर घटनांच्या पलीकडेही महत्त्वाचे आहे. फ्रॉड टीम्स, अंतर्गत ऑडिट आणि कंप्लायन्स कर्मचारी हे सर्व ट्रॅक करण्यायोग्य रेकॉर्डवर अवलंबून असतात. जर तुमच्या संस्थेला आर्थिक नियंत्रणे आणि तपासाभोवती तज्ज्ञांच्या मदतीची आवश्यकता असेल, तर लॉगिंग आणि गव्हर्नन्स एकमेकांशी संबंधित असताना detect fraud with Lighthouse Consultants हा एक व्यावहारिक बाह्य पर्याय आहे.
नियामक अनुपालन (Regulatory compliance)
बरेच संघ audit trails कडे पुरावा म्हणून पाहतात जो केवळ ऑडिटरने विचारल्यावरच गोळा करायचा असतो. हा चुकीचा दृष्टिकोन आहे. चांगल्या audit trails सातत्याने तयार केल्या जातात जेणेकरून प्रश्न विचारला जाण्यापूर्वीच पुरावा उपलब्ध असेल.
WiFi आणि ॲक्सेस प्लॅटफॉर्मसाठी, कंप्लायन्स सहसा यावर अवलंबून असतो की तुम्ही हे दाखवू शकता का की कोणाचे प्रमाणीकरण (authenticated) झाले, कोणता डेटा प्रोसेस झाला, कोणत्या प्रशासकाने बदल केला आणि ते कधी घडले. जर ते रेकॉर्ड अपूर्ण किंवा बदलता येण्यासारखे असतील, तर कंप्लायन्सची स्थिती वेगाने कमकुवत होते.
ऑपरेशनल ट्रबलशूटिंग
प्रत्येक audit trail चा वापर केवळ मोठ्या घटनांसाठीच होतो असे नाही. अनेक वापराच्या केसेस दैनंदिन इंजिनिअरिंग समस्यांशी संबंधित असतात.
एखादा युझर सांगतो की त्यांना सुरक्षित SSID वरून काढून टाकण्यात आले. एखादा भाडेकरू म्हणतो की त्यांचे डिव्हाइस चुकीच्या प्रोफाइलवर गेले. एखादे ठिकाण रिपोर्ट करते की ऑनबोर्डिंग काल सुरू होते आणि आज अयशस्वी होत आहे. Audit trail सहसा याचे उत्तर लवकर दाखवते: एक्स्पायर झालेली आयडेंटिटी, नाकारलेले पॉलिसी मॅपिंग, अयशस्वी डिरेक्टरी सिंक, सर्टिफिकेट विसंगती, किंवा कॉन्फिगरेशनमधील बदल ज्याने ॲक्सेस लॉजिक बदलले.
म्हणूनच परिपक्व टीम्स audit trails कडे मृत आर्काइव्ह म्हणून पाहत नाहीत. ते त्याकडे थेट ऑपरेशनल डेटा म्हणून पाहतात.
प्रभावी Audit Trail चे मुख्य घटक
Audit trail केवळ प्रत्येक इव्हेंटच्या संरचनेइतकीच चांगली असते. जर नोंदी अस्पष्ट, बदलता येण्यासारख्या किंवा विसंगत असतील, तर तपासादरम्यान ती टिकून राहणार नाही. चांगली ऑडिटेबिलिटी एका रेसिपीसारखी काम करते. एक जरी आवश्यक घटक वगळला, तरी निकाल अविश्वसनीय ठरतो.
UK Data Protection Act 2018 अंतर्गत, ऑडिट ट्रेल्स टेम्पर-एव्हिडेंट (हस्तक्षेप स्पष्टपणे समजणारा) असणे आवश्यक आहे. NIST SP 800-53 Rev. 5 मध्ये प्रतिबिंबित केलेले आणि UK NCSC-संरेखित सरावामध्ये स्वीकारलेले तांत्रिक मार्गदर्शन WORM स्टोरेज किंवा SHA-256 सारख्या क्रिप्टोग्राफिक हॅशिंगचा वापर करून अपरिवर्तनीय लॉगिंगकडे निर्देश करते. त्याच स्त्रोताचा सारांश दर्शवतो की UK ICO अंमलबजावणीमध्ये £18M ब्रिटिश एअरवेज दंड समाविष्ट होता, जेथे ट्रेल उपलब्ध नसल्यामुळे घटना प्रतिसादास 72 तास उशीर झाला होता. यामधील मूळ संदर्भ ऑडिट ट्रेलसाठी NIST ग्लॉसरी नोंद हा आहे.
घटना स्वतः
स्पष्ट परंतु अनेकदा दुर्लक्षित केलेल्या मुद्द्यापासून सुरुवात करूया. प्रत्येक नोंदणीमध्ये अर्थपूर्ण घटनेचे वर्णन असणे आवश्यक आहे.
याचा अर्थ केवळ "प्रमाणीकरण (authentication) झाले" असे नाही, तर कोणत्या प्रकारचे प्रमाणीकरण, कोणत्या ओळख स्त्रोताच्या (identity source) विरोधात, कोणत्या नेटवर्क संदर्भासाठी आणि काय परिणामासह झाले हे दर्शवणे आवश्यक आहे. प्रशासक (admin) कृतींच्या बाबतीतही हेच लागू होते. "सेटिंग्ज बदलल्या" हे जवळजवळ निरुपयोगी आहे. "नामित admin खात्याद्वारे SSID पॉलिसी कर्मचारी प्रवेशावरून अतिथी प्रवेशामध्ये बदलली" ही माहिती उपयुक्त आहे.
मजबूत घटना रेकॉर्डमध्ये खालील बाबी कॅप्चर केल्या पाहिजेत:
- वापरकर्त्याची ओळख (User identity) जसे की नामित वापरकर्ता, सेवा खाते किंवा डिव्हाइस प्रमाणपत्र विषय
- केलेली कृती जसे की लॉगिन, लॉगआउट, नावनोंदणी, भूमिका वाटप, पॉलिसी अपडेट किंवा रद्दीकरण
- प्रभावित स्त्रोत जसे की SSID, भाडेकरू (tenant), वापरकर्ता गट, प्रवेश प्रोफाइल किंवा कंट्रोलर ऑब्जेक्ट
- परिणाम ज्यामध्ये यश, नकार, अपयशाचे कारण किंवा टाइमआउट समाविष्ट आहे
- स्त्रोत संदर्भ (Source context) जसे की डिव्हाइस प्रकार, प्रमाणीकरण स्त्रोत किंवा मूळ सिस्टीम
वेळ आणि क्रम
तुम्ही WiFi कंट्रोलर्स, ओळख प्रदाते (identity providers), फायरवॉल आणि SIEM टूल्समध्ये परस्पर संबंध स्थापित करेपर्यंत टाइमस्टॅम्प सोपे वाटतात. तुमचे वेळ स्त्रोत संरेखित नसल्यास, तपासणी गुंतागुंतीची बनते.
जेव्हा अनेक कृती एकाच वेळी घडतात तेव्हा मिलिसेकंद अचूकता महत्त्वाची ठरू शकते. एक अयशस्वी SSO, पुन्हा प्रयत्न, पॉलिसी शोधणे आणि सत्र स्वीकृती हे सर्व क्षणभरात घडू शकतात. अचूक क्रमाशिवाय, विश्लेषक कोणती घटना कशामुळे घडली हे सांगू शकत नाहीत.
लॉग्सचा क्रम आत्मविश्वासाने ठरवता येत नसेल, तर लोक अपूर्ण पुराव्यांवरून निष्कर्षाचा अंदाज लावू लागतात. खराब घटना अहवाल येथूनच तयार होतात.
अखंडता आणि अपरिवर्तनीयता (Integrity and immutability)
नोटीस न देता संपादित केला जाऊ शकणारा लॉग हा ऑडिट ट्रेल नाही. ती एक टिपण घेण्याची सिस्टीम आहे.
टेम्पर एव्हिडन्स (हस्तक्षेप पुरावा) रेकॉर्डला विश्वासार्हता देतो. व्यवहारात, टीम्स सहसा अपेंड-ओनली स्टोरेज, नियंत्रित एक्सपोर्ट पाथ, क्रिप्टोग्राफिक हॅशिंग, कठोर भूमिका वेगळे करणे आणि केंद्रीय धारणा (retention) नियंत्रणांद्वारे हे लागू करतात. याचा उद्देश अगदी स्पष्ट आहे: जर कोणी रेकॉर्डमध्ये बदल केला, तर तुम्ही तो शोधू शकता.
प्रशासक (admin) कृतींसाठी हे विशेषतः महत्वाचे आहे. सर्वात जास्त विशेषाधिकार असलेल्या लोकांचे बदल स्वतंत्रपणे रेकॉर्ड केले नसल्यास ते सर्वात मोठा धोका निर्माण करतात.
आधी आणि नंतरचा संदर्भ
नेटवर्क ॲक्सेस कंट्रोलसाठी, सर्वात महत्त्वाचे फील्ड म्हणजे चेंज कॉन्टेक्स्ट. आधीची स्थिती काय होती आणि नवीन स्थिती काय आहे?
हे खालील गोष्टींसाठी महत्त्वाचे आहे:
- पाहुण्यांमधून कर्मचाऱ्यांमध्ये बदलणारे भूमिका बदल (Role changes)
- शेअर केलेल्या मालमत्तांसाठी भाडेकरू मॅपिंग संपादने (Tenant mapping edits)
- VLAN, ACL किंवा सेशन वर्तन बदलणारे पॉलिसी अपडेट्स
- प्रमाणपत्र जारी करणे, नूतनीकरण आणि रद्द करणे यासारख्या प्रमाणपत्र लाइफसायकल इव्हेंट्स
तुम्ही झिरो-ट्रस्ट मॉडेल तयार करत असल्यास, तुमचा ऑडिट ट्रेल त्याच पातळीवरील उत्तरदायित्वास समर्थन देणारा असावा. त्या ऑपरेशनल विचारसरणीसाठी एक चांगला संदर्भ बिंदू म्हणजे झिरो ट्रस्ट नेटवर्क ॲक्सेस वरील हा लेख आहे.
WiFi आणि नेटवर्क ॲक्सेसमधील ऑडिट ट्रेलची उदाहरणे
ऑडिट ट्रेल व्यावहारिक बनवण्याचा सर्वात वेगवान मार्ग म्हणजे वास्तविक इव्हेंटचे अनुक्रम पाहणे. WiFi आणि नेटवर्क ॲक्सेसमध्ये, मूल्य एका लॉग लाइनमध्ये नसते. ते संपूर्ण सेशनचे स्पष्टीकरण देणाऱ्या रेकॉर्डच्या साखळीत असते.
उदाहरण एक, हॉटेलमधील गेस्ट WiFi
एक पाहुणा येतो, वेन्यू SSID शी कनेक्ट करतो, पासवर्डशिवाय ऑथेंटिकेशन पूर्ण करतो आणि इंटरनेट ॲक्सेस मिळवतो. नंतर, रिसेप्शन रिपोर्ट करते की पाहुणा म्हणतोय की नेटवर्क वारंवार खंडित होत होते.
त्या सेशनसाठी उपयुक्त ऑडिट ट्रेल काहीसा असा दिसू शकतो:
| इव्हेंट वेळ | ओळख (Identity) | कृती (Action) | रिसोर्स (Resource) | परिणाम (Outcome) |
|---|---|---|---|---|
| 08:14:22 | गेस्ट युझर रेकॉर्ड | असोसिएशन रिक्वेस्ट | गेस्ट SSID | स्वीकृत |
| 08:14:24 | गेस्ट युझर रेकॉर्ड | ऑथेंटिकेशन चॅलेंज पूर्ण | गेस्ट ॲक्सेस सर्व्हिस | यशस्वी |
| 08:14:25 | गेस्ट युझर रेकॉर्ड | ॲक्सेस पॉलिसी नियुक्त | गेस्ट नेटवर्क भूमिका | यशस्वी |
| 08:14:26 | डिव्हाइस सेशन | सेशन सुरू झाले | वेन्यू WiFi सर्व्हिस | यशस्वी |
| 08:37:10 | डिव्हाइस सेशन | पुन्हा ऑथेंटिकेशनचा प्रयत्न | गेस्ट ॲक्सेस सर्व्हिस | टाइमआउट |
| 08:37:14 | डिव्हाइस सेशन | सेशन पुन्हा सुरू झाले | गेस्ट नेटवर्क भूमिका | यशस्वी |
| 09:02:41 | डिव्हाइस सेशन | डिस्कनेक्ट | गेस्ट SSID | क्लायंटद्वारे सुरू केलेले |
तो अनुक्रम इंजिनियरला अनेक प्रश्नांची उत्तरे पटकन देण्यास मदत करतो. पाहुण्याने ऑथेंटिकेशन केले का? होय. ॲक्सेस मंजूर झाला का? होय. पॉलिसी बदलल्यामुळे कनेक्शन तुटले का? नाही. पुन्हा ऑथेंटिकेशन दरम्यान टाइमआउट झाला का? होय. यामुळे ट्रबलशूटिंग लगेच सोपे होते.
उदाहरण दोन, मल्टी-टेनंट इमारतीमधील कर्मचाऱ्यांचा प्रवेश
आता दुसरी परिस्थिती पाहू. सामायिक व्यावसायिक मालमत्तेमधील एक कर्मचारी कॉर्पोरेट SSO चा वापर करून कनेक्ट होतो. नंतर, सुरक्षा टीमला हे जाणून घ्यायचे आहे की वापरकर्त्याचा अंतर्गत ॲप्लिकेशनवरील प्रवेश थोड्या वेळासाठी का बंद झाला.
त्याचा ऑडिट ट्रेल या स्वरूपात असू शकतो:
user=j.smith
action=authentication_request
identity_source=corporate_directory
resource=staff_secure_ssid
outcome=success
user=j.smith
action=certificate_validated
identity_source=enterprise_ca
resource=network_access_policy
outcome=success
user=j.smith
action=role_assignment
resource=tenant_staff_profile
outcome=success
admin=directory_sync_service
action=group_membership_update
resource=tenant_staff_profile
outcome=success
user=j.smith
action=reauthorisation
resource=application_access_segment
outcome=denied
ही एक वेगळीच कथा सांगते. WiFi कनेक्शन स्वतःमध्ये अगदी व्यवस्थित असू शकत होते. ही समस्या कदाचित ग्रुप मेंबरशिप किंवा ऑथोरायझेशन स्थिती बदलल्यामुळे आली असावी जी सुरुवातीच्या प्रवेशानंतर बदलली होती. ऑडिट ट्रेल नसता, तर नेटवर्क टीमने चुकीच्या पद्धतीने वायरलेस लेयरला दोष दिला असता.
चांगले ऑडिट ट्रेल काय दर्शवतात
या उदाहरणांचा उद्देश फॉरमॅटिंग दाखवणे हा नाही. भिन्न सिस्टीम्स syslog, JSON, CEF, API इव्हेंट्स किंवा प्रोप्रायटरी रेकॉर्ड्स जनरेट करतात. महत्त्वाची गोष्ट म्हणजे तो ऑडिट ट्रेल प्रत्यक्ष निर्णय घेण्यास मदत करण्याइतका स्पष्ट असावा.
यामध्ये तीन गुण शोधणे आवश्यक आहे:
- सत्र सातत्य (Session continuity) जेणेकरून एका वापरकर्त्याच्या सुरुवातीपासून शेवटपर्यंतच्या प्रवासाचा मागोवा घेता येईल
- ओळख स्पष्टता (Identity clarity) जेणेकरून नामांकित वापरकर्ते, अतिथी, डिव्हाइसेस आणि सेवांची गल्लत होणार नाही
- प्रशासकीय शोधक्षमता (Administrative traceability) जेणेकरून इंजिनिअर्स, हेल्प डेस्क कर्मचारी आणि ऑटोमेशन द्वारे केलेले बदल स्पष्ट दिसतील
एंटरप्राइझ WiFi मध्ये, कमजोर ऑडिट ट्रेल सामान्यतः एका सिस्टीममधून दुसऱ्या सिस्टीमकडे डेटा ट्रान्सफर होताना अपयशी ठरतात. ऑथेंटिकेशन एका ठिकाणी लॉग केले जाते, पॉलिसी निर्णय दुसऱ्या ठिकाणी आणि ॲडमिन बदल इतर कोठे तरी. मजबूत ऑडिट ट्रेल या सर्व तुकड्यांना एकत्र जोडतात.
ऑडिट ट्रेल डेटा सुरक्षितपणे व्यवस्थापित करणे
ऑडिट डेटा गोळा करणे हा सोपा भाग आहे. तो उपयुक्त, सुरक्षित आणि शोधण्यायोग्य ठेवणे हे खरे कठीण काम आहे. आव्हान म्हणजे पुराव्याचा दर्जा आणि स्टोरेजचा खर्च, गोपनीयतेच्या बाबी आणि ऑपरेशनल ओव्हरहेड यांच्यात समतोल राखणे.
पहिला निर्णय धारणा कालावधीचा (retention) असतो. जर डेटा खूप कमी काळासाठी ठेवला, तर समस्या समोर येण्यापूर्वीच तुम्ही पुरावे गमावून बसाल. जर प्रत्येक गोष्ट कायमस्वरूपी आणि कोणत्याही संरचनेशिवाय साठवली, तर तुम्ही एक मोठा डेटाचा ढीग तयार कराल जो कोणीही पटकन शोधू शकणार नाही. याचे उत्तर तुमच्या नियामक जबाबदाऱ्या, इन्सिडेंट रिस्पॉन्सच्या गरजा आणि ऐतिहासिक प्रवेश रेकॉर्ड्सचे व्यावसायिक मूल्य यावर आधारित असावे.
स्टोरेज आणि प्रवेश नियंत्रण
ऑडिट ट्रेल्स स्वतः संवेदनशील असतात. त्यामध्ये बऱ्याचदा युझरनेम्स, ॲक्सेस पॅटर्न्स, ॲडमिन कृती आणि सिस्टम स्ट्रक्चर उघड होते. त्यांना केवळ इंजिनीअरिंग एक्झॉस्ट म्हणून न पाहता, सुरक्षित ऑपरेशनल डेटासारखे हाताळा.
योग्य दृष्टिकोनामध्ये सहसा खालील गोष्टींचा समावेश होतो:
- मर्यादित ॲक्सेस जेणेकरून केवळ अधिकृत ॲडमिन, सिक्युरिटी ॲनालिस्ट आणि ऑडिटर्स लॉग्स पाहू किंवा एक्स्पोर्ट करू शकतात
- कर्तव्यांचे विभाजन (Separation of duties) जेणेकरून बदल करणारी व्यक्ती हीच त्याचा रेकॉर्ड तपासणारी किंवा डिलीट करणारी एकमेव व्यक्ती नसेल
- केंद्रीय धारणा नियम (Central retention rules) जेणेकरून स्थानिक डिव्हाइसेस पुराव्याचे एकमेव स्त्रोत बनणार नाहीत
- नियंत्रित एक्स्पोर्ट्स जेणेकरून तपासणी दरम्यान संवेदनशील लॉग डेटाच्या प्रती प्रशासनाशिवाय इतरत्र पसरणार नाहीत
असे वातावरण जिथे ॲक्सेस आणि ऑक्युपन्सी डेटा एकमेकांशी जोडलेला असतो, तिथे प्रॉपर्टी टीम्सना बऱ्याचदा शेजारील ऑपरेशनल कंट्रोल्सची देखील आवश्यकता असते. याचे एक संबंधित उदाहरण म्हणजे Nimbio सह प्रॉपर्टी ॲक्सेस व्यवस्थापित करणे , विशेषतः जिथे गेस्ट जर्नी आणि बिल्डिंग ॲक्सेस प्रक्रिया एकमेकांना छेदतात.
सामान्य ऑडिट लॉग फॉरमॅट्सची तुलना
| Format | Structure | Best For | Key Advantage |
|---|---|---|---|
| Syslog | प्लेन टेक्स्ट, इव्हेंट ओरिएंटेड | नेटवर्क डिव्हाइसेस, कंट्रोलर्स, फायरवॉल्स | इन्फ्रास्ट्रक्चर टूल्समध्ये व्यापक सपोर्ट |
| JSON | स्ट्रक्चर्ड की-व्हॅल्यू फॉरमॅट | मॉडर्न प्लॅटफॉर्म्स, APIs, क्लाउड लॉगिंग | सुलभ पार्सिंग आणि समृद्ध संदर्भ |
| CEF | नॉर्मलाइज्ड इव्हेंट फॉरमॅट | SIEM इंजेक्शन आणि क्रॉस-व्हेंडर कोरिलेशन | सुसंगत सुरक्षा इव्हेंट हाताळणी |
व्हॉल्यूमपेक्षा शोधयोग्यता अधिक महत्त्वाची आहे
वास्तविक घटनेच्या वेळी, जर टीम लॉग्स वेगाने शोधू शकत नसेल, तर तुम्ही किती लॉग्स राखून ठेवले आहेत याने कोणावरही प्रभाव पडत नाही. रॉ इव्हेंट्स स्वस्त स्टोरेजमध्ये टाकून देण्यापेक्षा इंडेक्सिंग, नॉर्मलायझेशन आणि योग्य फील्ड नेमिंग अधिक महत्त्वाचे ठरते.
ऑपरेशनल सल्ला: तुम्ही जे शोधू शकता ते राखून ठेवा. तुम्ही जे रिस्टोर करू शकता ते आर्काइव्ह करा. या दोन गोष्टींमध्ये गल्लत करू नका.
ऑडिट डेटाचे केंद्रीकरण करणे हा संस्थांसाठी प्राथमिक फायदा ठरतो. यामुळे ॲक्सेस कंट्रोल सोपे होते, कोरिलेशनचा वेग वाढतो आणि स्थानिक सिस्टीम रोल ओव्हर किंवा रीबिल्ड झाल्यावर रेकॉर्ड गमावण्याचा धोका कमी होतो. जर तुम्ही ऑपरेशनल आणि युझर डेटा हाताळण्याबाबत व्यापक प्लॅटफॉर्म कंट्रोल्सचे पुनरावलोकन करत असाल, तर डेटा आणि सुरक्षा पद्धतींचे हे विहंगावलोकन एक उपयुक्त संदर्भ बिंदू आहे.
तुमच्या एंटरप्राइझमध्ये ऑडिट ट्रेल्स लागू करणे
सर्वात प्रभावी ऑडिट ट्रेल प्रोग्राम हे ॲक्सेस आर्किटेक्चरचा एक भाग म्हणून डिझाइन केले जातात, ते डिप्लॉयमेंटनंतर जोडले जात नाहीत. जर तुमचे नेटवर्क, आयडेंटिटी प्लॅटफॉर्म आणि सिक्युरिटी टूल्स हे सर्व कोणत्याही सामायिक संरचनेशिवाय स्वतंत्रपणे लॉग्स तयार करत असतील, तर तुम्हाला विश्वासार्ह पुराव्यांच्या साखळीऐवजी केवळ तुकड्यांमध्ये माहिती मिळेल.
केंद्रीकरण (centralisation) पासून सुरुवात करा. नेटवर्क ऍक्सेस इव्हेंट्स, ॲडमिन कृती, आयडेंटिटी इव्हेंट्स आणि प्लॅटफॉर्म-पातळीवरील बदल एकाच विश्लेषणात्मक लेयरमध्ये पाठवा, सहसा SIEM किंवा लॉग मॅनेजमेंट प्लॅटफॉर्मवर. Splunk, Microsoft Sentinel, Elastic, IBM QRadar आणि यांसारखी टूल्स यासाठी सामान्यतः वापरली जातात कारण ते वायरलेस, डिरेक्टरी, एंडपॉईंट आणि ॲप्लिकेशन डेटामध्ये परस्परसंबंध शोधण्याची परवानगी देतात.
ऑपरेशन्सना अनुकूल असणारे लॉगिंग मॉडेल निवडा
एक विकेंद्रीकृत मॉडेल लहान वातावरणात काम करू शकते, परंतु एकापेक्षा जास्त टीम्स एकाच ऍक्सेस फ्लोचा वापर करू लागल्या की ते निकामी ठरते. एंटरप्राइझ WiFi मध्ये, एका युझर सेशनमध्ये वायरलेस कंट्रोलर, आयडेंटिटी प्रोव्हाइडर, सर्टिफिकेट सर्व्हिस, पॉलिसी इंजिन आणि क्लाउड डॅशबोर्ड यांचा समावेश असू शकतो. जर प्रत्येकाने स्वतःचा इतिहास वेगवेगळ्या रिटेंशन आणि ऍक्सेस नियंत्रणांसह ठेवला, तर तपास यंत्रणा लगेचच संथ होते.
एक केंद्रीकृत मॉडेल सहसा अधिक चांगले कार्य करते कारण ते तुम्हाला खालील गोष्टी प्रदान करते:
- सेशन आणि ॲडमिन ॲक्टिव्हिटीसाठी एकच सर्च पॉइंट
- सिस्टम्स दरम्यान सुसंगत रिटेंशन
- संशयास्पद ऍक्सेस पॅटर्नसाठी अधिक सुलभ अलर्टिंग
- ऑडिट आणि इन्सिडेंट रिस्पॉन्स दरम्यान अधिक सुस्पष्ट पुरावे हाताळणी
याचा अर्थ असा नाही की प्रत्येक रॉ इव्हेंट कायमचा एकाच ठिकाणी राहिला पाहिजे. याचा अर्थ असा आहे की तुमचे महत्त्वाचे ऑडिट रेकॉर्ड अशा प्रकारे गोळा आणि जतन केले पाहिजेत जेणेकरून त्यांची सुरक्षित साखळी (chain of custody) अखंड राहील.
ऑडिट ट्रेल्सना ऍक्सेस पॉलिसीशी जोडा
बऱ्याच अंमलबजावणी या क्षेत्रात अपुऱ्या पडतात. टीम्स ऑथेंटिकेशन इव्हेंट्स लॉग करतात, परंतु ते त्यांच्याशी जोडलेले पॉलिसी निर्णय लॉग करत नाहीत. यामुळे "युझरने साइन इन केले" आणि "युझरला हे करण्याची परवानगी दिली गेली" यामध्ये तफावत निर्माण होते.
एक प्रगल्भ डिझाइन दोन्ही रेकॉर्ड करते. त्यात आयडेंटिटी, ऍक्सेस निर्णय, रोल असाइनमेंट आणि त्या परिणामांवर परिणाम करणारे प्रशासकीय बदल दिसले पाहिजेत. जर तुम्ही व्यापक एंटरप्राइझ स्थितीमध्ये ऍक्सेस अंमलबजावणी कशी बसते याचे पुनरावलोकन करत असाल, तर network access control solutions चे हे मार्गदर्शक एक मजबूत सुरुवात आहे.
ऑडिट रेकॉर्डसाठी मजबूत अखंडता मॉडेल्समध्येही वाढती स्वारस्य आहे, विशेषतः जिथे अनेक संस्था ट्रस्ट बाउंड्रीज सामायिक करतात. अशा प्रकरणांमध्ये, टीम्स कधीकधी blockchain solutions for enterprises सारख्या अपेंड-ओन्ली आणि डिस्ट्रिब्युटेड व्हेरिफिकेशन पद्धतींचा शोध घेतात, लॉगिंगला पर्याय म्हणून नाही तर निवडक रेकॉर्ड्ससाठी जोडलेला अखंडता स्तर म्हणून.
प्रॉडक्शनमध्ये टिकून राहणाऱ्या सर्वोत्तम पद्धती
ज्या टीम्स हे चांगल्या प्रकारे करतात त्या सहसा साध्या गोष्टींमध्ये शिस्तबद्ध असतात. त्या फील्ड्सचे मानकीकरण करतात, वेळ सिंकमध्ये ठेवतात, ॲडमिन लॉग्सचे आक्रमकपणे संरक्षण करतात आणि एखादी घटना घडण्यापूर्वी पुनर्प्राप्तीची (retrieval) चाचणी घेतात.
एक व्यावहारिक चेकलिस्ट:
- ऑथेंटिकेशन सोर्स, पॉलिसी रिझल्ट आणि ॲडमिन कृतींसह आयडेंटिटी-समृद्ध इव्हेंट्स लॉग करा
- वायरलेस, आयडेंटिटी आणि सिक्युरिटी सिस्टम्समध्ये वेळ सिंक्रोनाइझ करा
- फक्त जोडण्याची (append-only) नियंत्रणे आणि प्रतिबंधित विशेषाधिकारांसह लॉग सुरक्षित ठेवा
- महत्त्वाचे फील्ड्स सामान्य (normalise) करा जेणेकरून वेगवेगळ्या व्हेंडर्सवर शोध घेणे सोपे होईल
- युझरच्या नमुना प्रवासाची पुनर्रचना करून तपासांची नियमित चाचणी घ्या
- दस्तऐवज मालकी निश्चित करा जेणेकरून धारणा (retention), पुनरावलोकन आणि निर्यात नियंत्रणांसाठी कोणीतरी जबाबदार असेल
नमुना पॉलिसीचे स्निपेट्स
धारणा (retention) विधान साधे असू शकते:
नेटवर्क प्रवेश, ओळख इव्हेंट्स आणि प्रशासकीय क्रियांसाठी सुरक्षा-संबंधित ऑडिट रेकॉर्ड लागू कायदेशीर, नियामक आणि ऑपरेशनल आवश्यकतांनुसार केंद्रीय स्तरावर जतन केले जाणे आवश्यक आहे. सक्रिय धारणा कालावधी दरम्यान रेकॉर्ड शोधण्यायोग्य राहिले पाहिजेत आणि अनधिकृत बदल किंवा हटवण्यापासून सुरक्षित राहिले पाहिजेत.
प्रवेश नियंत्रण विधान देखील तितकेच स्पष्ट असावे:
ऑडिट ट्रेल डेटाचा प्रवेश केवळ परिभाषित ऑपरेशनल, सुरक्षा, अनुपालन किंवा तपासणीची आवश्यकता असलेल्या अधिकृत कर्मचाऱ्यांपुरता मर्यादित आहे. विशेषाधिकार प्राप्त प्रशासक मंजूर धारणा प्रक्रियांच्या व्यतिरिक्त ऑडिट रेकॉर्डमध्ये बदल करू शकत नाहीत किंवा ते हटवू शकत नाहीत.
ह्या काही आकर्षक पॉलिसीज नाहीत. त्या अंमलात आणण्यायोग्य असल्यामुळे प्रभावी आहेत.
ऑडिट ट्रेल्सबद्दल वारंवार विचारले जाणारे प्रश्न
ऑडिट ट्रेल आणि सिस्टम लॉगमध्ये काय फरक आहे
एक सिस्टम लॉग हा सहसा डिव्हाइस, ॲप्लिकेशन किंवा सेवेद्वारे व्युत्पन्न केलेल्या इव्हेंट्सचा कच्चा रेकॉर्ड असतो. एक ऑडिट ट्रेल म्हणजे युझरची कृती, प्रशासकीय बदल किंवा व्यावसायिक प्रक्रियेशी जोडलेल्या त्या इव्हेंट्सचा पुनर्बांधणी करण्यायोग्य क्रम असतो.
दुसऱ्या शब्दांत सांगायचे तर, लॉग हे साहित्य आहेत. ऑडिट ट्रेल ही पुराव्याची साखळी आहे जी तुम्ही वापरू शकता.
आम्ही ऑडिट ट्रेल डेटा किती काळ ठेवला पाहिजे
प्रत्येक संस्थेला लागू पडेल असा एकच सार्वत्रिक कालावधी नाही. धारणा ही तुमच्या पर्यावरणातील सर्वात कडक लागू कायदेशीर, नियामक, करारात्मक आणि तपासणीच्या आवश्यकतेनुसार असावी.
व्यावहारिक दृष्टिकोनातून, हे सोपे ठेवा. सिस्टम श्रेणीनुसार धारणा परिभाषित करा, कारणाचे दस्तऐवजीकरण करा आणि आपण दावा करत असलेल्या कालावधीसाठी डेटा अद्याप शोधण्यायोग्य असल्याची खात्री करा.
ऑडिट ट्रेल्समध्ये फेरबदल केले जाऊ शकतात का
त्यांना लक्ष्य केले जाऊ शकते, म्हणूनच छेडछाडीचा पुरावा (tamper evidence) असणे महत्त्वाचे ठरते. एक विश्वासार्ह ऑडिट ट्रेल अशी नियंत्रणे वापरते जी अनधिकृत बदल शोधण्यायोग्य बनवतात, जसे की केवळ-जोडण्याची (append-only) हाताळणी, क्रिप्टोग्राफिक अखंडता तपासणी, कठोर परवानग्या आणि केंद्रीकृत धारणा.
जर एखादा प्लॅटफॉर्म महत्त्वाच्या प्रवेश रेकॉर्डचे मूक संपादन किंवा डिलीट करण्याची अनुमती देत असेल, तर ते अद्याप लॉग तयार करत असू शकते, परंतु ते तुम्हाला विश्वसनीय पुरावे देत नाही.
नेटवर्क टीमने सर्वात आधी कशाला प्राधान्य दिले पाहिजे
ओळख इव्हेंट्स, प्रशासकीय बदल आणि प्रवेश निर्णयांसह प्रारंभ करा. हे तीन प्रकार एंटरप्राइझ WiFi वातावरणातील बहुतेक त्रासदायक प्रश्नांचे निराकरण करतात.
जर तुम्ही फक्त कनेक्शनच्या प्रयत्नांची नोंद ठेवली, तर तुम्हाला केवळ एक डिव्हाइस उपस्थित झाल्याचे समजेल. ते कोणाचे होते, त्याला कोणती पॉलिसी लागू झाली, किंवा ॲडमिनच्या बदलामुळे हा परिणाम झाला का, हे तुम्हाला समजणार नाही.
जर तुम्ही सामायिक केलेले WiFi पासवर्ड बदलत असाल, अतिथींच्या प्रवेशाचे आधुनिकीकरण करत असाल, किंवा कर्मचारी आणि भाडेकरूंच्या कनेक्टिव्हिटीचे ऑडिट करणे सोपे करण्याचा प्रयत्न करत असाल, तर Purple चा जवळून विचार करणे योग्य ठरेल. त्याचा ओळख-आधारित दृष्टिकोन संस्थांना मूलभूत कनेक्शन लॉग्जवरून अतिथी ऑथेंटिकेशन, कर्मचारी प्रवेश आणि मल्टी-टेनंट नेटवर्क ॲक्टिव्हिटीच्या अधिक स्पष्ट, अधिक सुरक्षित रेकॉर्डकडे जाण्यास मदत करतो.
