एन्क्रिप्टेड ऑडिट लॉग: ऑफलाइन सत्यापन क्या साबित करता है?

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

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

सिफरटेक्स्ट में अखंडता ट्रेल हो सकती है

एन्क्रिप्टेड ऑडिट लॉग ऑफलाइन सत्यापन में मदद कर सकते हैं, क्योंकि सत्यापनकर्ता को किसी रिकॉर्ड को समझने की जरूरत नहीं होती। संग्रहीत बाइट्स का हैश निकालना ही काफी है। इसके लिए रिकॉर्ड का प्रारूप स्पष्ट होना चाहिए और ऐसा नियम होना चाहिए जो हर रिकॉर्ड को उससे पहले वाले रिकॉर्ड से जोड़ता हो।

एक सरल वैचारिक चेन इस तरह दिखती है:

record_1 = Encrypt(event_1)
link_1   = H(record_1)

record_2 = Encrypt(event_2)
link_2   = H(link_1 || record_2)

record_3 = Encrypt(event_3)
link_3   = H(link_2 || record_3)

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

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

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

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

वैध चेन निरंतरता साबित करती है, सच्चाई नहीं

हैश चेन अखंडता की एक सीमित विशेषता साबित करती है: बाद की कड़ियां पहले संग्रहीत बाइट्स पर निर्भर करती हैं। यह साबित नहीं करती कि सॉफ्टवेयर ने किसी कार्रवाई को सही ढंग से दर्ज किया, हर कार्रवाई दर्ज की, या किसी कर्मचारी ने साफ लेकिन भ्रामक इतिहास नहीं बनाया।

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

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

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

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

एजेंट की पहचान के साथ भी यही समस्या आती है। कोई रिकॉर्ड प्रोसेस, कोड-साइनिंग अथॉरिटी, सेशन या उपयोगकर्ता की मंजूरी की पहचान कर सकता है। ये अलग-अलग अभिनेताओं का वर्णन करते हैं। यदि रिकॉर्ड में «agent session 42» लिखा है, तो ऑडिटर को इसे «Alice ने किया» नहीं लिखना चाहिए, जब तक अलग रिकॉर्ड Alice की मंजूरी को उस सेशन से न जोड़ें। चेन बाइट्स को सुरक्षित रखती है। वह उन बाइट्स की जरूरत से ज्यादा व्यापक व्याख्या को ठीक नहीं करती।

पहला विश्वसनीय एंकर तय करता है कि सबूत कितनी दूर तक जाता है

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

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

व्यावहारिक चेकपॉइंट में भविष्य के समीक्षक के लिए दावे की पहचान करने लायक जानकारी होनी चाहिए। कम से कम यह जानकारी सुरक्षित रखें:

log identity: agent-actions-prod
checkpoint sequence: 18427
checkpoint digest: 7f...c2
record format version: 3
hash algorithm: SHA-256
checkpoint captured by: release-control process
checkpoint captured at: 2025-03-08T18:20:00Z

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

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

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

स्वतंत्र पक्ष से जुड़ने तक समय के फ़ील्ड केवल दावे हैं

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

टीमें अक्सर सीक्वेंस को समय समझ लेती हैं। चेन यह स्थापित कर सकती है कि चेन नियम के अनुसार रिकॉर्ड 108, रिकॉर्ड 107 के बाद आया। वह यह स्थापित नहीं कर सकती कि रिकॉर्ड 108 09:17 UTC पर हुआ, सिर्फ इसलिए कि रिकॉर्ड में ऐसा लिखा है। मोनोटोनिक काउंटरों की भी सीमा है: वे एक लॉग में क्रम दिखाते हैं, लेकिन यह नहीं बताते कि प्रविष्टियों के बीच वास्तविक कितना समय बीता।

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

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

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

ऑफलाइन सत्यापन में मूल सबूत की बाइट्स सुरक्षित रहनी चाहिए

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

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

सत्यापन प्रक्रिया में संग्रह, अखंडता जांच और सामग्री तक पहुंच अलग-अलग होनी चाहिए:

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

तीसरे चरण में कमांड-लाइन आर्टिफैक्ट महत्वपूर्ण होता है। Sallyport कमांड-लाइन टूल्स इंस्टॉल वाली मशीन पर ऑडिटर यह चला सकता है:

sp audit verify

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

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

टूटी हुई कड़ी बताती है कि कहां जांच करनी है, किसने किया यह नहीं

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

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

विफलता का पैटर्न संभावनाओं को सीमित कर सकता है:

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

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

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

डिलीशन और ट्रंकेशन के लिए अलग बचाव चाहिए

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

मान लीजिए किसी आर्काइव में रिकॉर्ड 1 से 500 तक हैं। हमलावर 451 से 500 तक के रिकॉर्ड हटा देता है और ऑडिटर को 1 से 450 तक के रिकॉर्ड देता है। पहले 450 रिकॉर्ड पूरी तरह सत्यापित हो सकते हैं। चेन में 451 की ओर इशारा करने वाला कोई अगला रिकॉर्ड नहीं है। समीक्षक को बाहरी अपेक्षा चाहिए कि इतिहास उससे आगे भी जाना चाहिए था।

यह अपेक्षा 500 पर रखे चेकपॉइंट, साइन किए गए दैनिक काउंट, आखिरी सीक्वेंस नंबर जानने वाले बाहरी सिस्टम या पूरे हुए एक्सपोर्ट रेंज दर्ज करने वाली रिटेंशन प्रक्रिया से आ सकती है। उपयोगी दावा विशिष्ट होना चाहिए: «आर्काइव में सीक्वेंस 500 तक का हर रिकॉर्ड शामिल है।» केवल चेन यह दावा सहारा देती है: «दिया गया आर्काइव सीक्वेंस 450 तक सुसंगत है।»

पहले दिए गए रिकॉर्ड से पहले का डिलीशन भी यही समस्या पैदा करता है। अगर समीक्षक को रिकॉर्ड 200 से शुरू होने वाली चेन मिलती है, तो वह यह नहीं जान सकता कि रिकॉर्ड 1 से 199 कभी मौजूद थे या नहीं। एक्सपोर्ट प्रारूप में स्पष्ट होना चाहिए कि यह शुरुआत से वर्तमान तक का पूरा आर्काइव है या सीमित अवधि का हिस्सा। सीमित हिस्सों को अपने शुरुआती चेकपॉइंट की जरूरत होती है। पूरे आर्काइव को भी विश्वसनीय शुरुआती मान या बाहरी कमिटमेंट चाहिए, अगर कोई हमलावर पूरी फ़ाइल बदल सकता है।

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

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

सत्यापनकर्ता को प्रारूप पता होना चाहिए, अनुमान नहीं लगाना चाहिए

क्रिप्टोग्राफिक एल्गोरिदम अस्पष्ट रिकॉर्ड प्रारूप की समस्या हल नहीं करते। सत्यापनकर्ता को ठीक-ठीक पता होना चाहिए कि लेखक किसी घटना को सिफरटेक्स्ट में कैसे बदलता है और अगला हैश निकालने के लिए मेटाडेटा, पिछले लिंक और सिफरटेक्स्ट को कैसे जोड़ता है।

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

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

वर्जनिंग में सावधानी चाहिए। अगर संस्करण 2 रिकॉर्ड एनवेलप बदलता है, तो सत्यापनकर्ता को बताना चाहिए कि उसने बदलाव के बाद संस्करण 2 के नियम लागू किए। सत्यापनकर्ता को चुपचाप किसी दूसरे पार्सर पर वापस नहीं जाना चाहिए। चुपचाप किया गया फॉलबैक संगतता सुविधा को ऐसे रास्ते में बदल देता है जिससे खराब सबूत को भी गलत तरीके से पास मिल सकता है।

National Institute of Standards and Technology का प्रकाशन FIPS 180-4 SHA-2 परिवार को निर्दिष्ट करता है और हैश फ़ंक्शन को एप्लिकेशन के इरादे पर नहीं, बल्कि बिट्स के क्रम पर परिभाषित करता है। यह सूखी तकनीकी बात व्यावहारिक चेतावनी देती है। अखंडता की विशेषता ठीक उन्हीं इनपुट बाइट्स से जुड़ी होती है। जो टीमें कहती हैं, «हम इवेंट का हैश निकालते हैं», उन्होंने अक्सर यह तय ही नहीं किया होता कि वे UTF-8 स्ट्रिंग, डेटाबेस रो, कंप्रेस्ड ऑब्जेक्ट या एन्क्रिप्टेड एनवेलप का हैश निकाल रही हैं। जब तक यह तय न हो, उनके पास दोहराया जा सकने वाला ऑडिट चेक नहीं है।

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

एजेंट लॉग को दो स्तर के सबूत चाहिए

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

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

Sallyport एक ही राइट-ब्लाइंड, एन्क्रिप्टेड और हैश-चेन वाले ऑडिट लॉग से Sessions जर्नल और Activity जर्नल तैयार करता है। इससे ऑडिटर को एक ही सुरक्षित इतिहास के दो दृश्य मिलते हैं और जांचने के लिए एक ही अखंडता ट्रेल बनी रहती है।

«राइट-ब्लाइंड» शब्द का अर्थ स्पष्ट होना चाहिए। इसका मतलब है कि ऑडिट सबूत जोड़ने वाले घटक के पास अपने सामान्य काम के दौरान पुराने रिकॉर्ड पढ़ने और दोबारा लिखने का आसान रास्ता नहीं होना चाहिए। इसका मतलब यह नहीं कि लॉग लिखने वाला झूठे बयान नहीं बना सकता। समझौता किया गया एजेंट हानिकारक कार्रवाई का अनुरोध कर सकता है। समझौता किया गया गेटवे गणितीय रूप से वैध चेन बनाए रखते हुए गलत डेटा दर्ज कर सकता है। यह डिजाइन दोबारा लिखे जाने के एक जोखिम को कम करता है, लेकिन सॉफ्टवेयर अखंडता, सेशन मंजूरी, जरूरत पड़ने पर एक्शन मंजूरी और रिमोट सिस्टम के सबूत से तुलना की जरूरत खत्म नहीं करता।

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

इस अलगाव से टीमें अखंडता पैकेज ऐसे सुरक्षा समीक्षक को भेज सकती हैं जिसे प्रोडक्शन सीक्रेट्स देखने की स्थायी अनुमति नहीं है। इससे घटना की जांच भी कम अव्यवस्थित होती है। पहले पता लगाएं कि दिया गया सबूत सुरक्षित है या नहीं। फिर घटनाओं को समझने के लिए जरूरी न्यूनतम डिक्रिप्शन एक्सेस दें।

ऑडिट का दावा उतना ही होना चाहिए जितना सबूत दिखा सके

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

ऐसी भाषा इस्तेमाल करें: «सत्यापनकर्ता ने सीक्वेंस 18,428 से 19,100 तक के रिकॉर्ड को सीक्वेंस 18,427 वाले चेकपॉइंट से जुड़ी लगातार सिफरटेक्स्ट चेन के रूप में स्वीकार किया। इस चेकपॉइंट को release-control process ने अलग से सुरक्षित रखा था।» यह बयान वही कहता है जिसका सबूत समर्थन करता है। अगर टीम के पास बाहरी रूप से साइन किया गया टाइमस्टैम्प भी है, तो उसे अलग से लिखें। अगर उसने कुछ कार्रवाइयों की तुलना प्रोवाइडर के इवेंट रिकॉर्ड से की है, तो वह भी अलग से लिखें।

जब तक एंकर किए गए अंतिम चेकपॉइंट या किसी अन्य स्वतंत्र स्रोत से दावा समर्थित न हो, «कुछ भी डिलीट नहीं किया गया» जैसे वाक्य से बचें। जब सबूत केवल स्थानीय प्रोसेस की पहचान करता हो, तब «एजेंट ने यह किया» न कहें। जब समीक्षा की जा रही मशीन की अपनी घड़ी ही एकमात्र स्रोत हो, तब «ठीक इसी समय» न कहें। ये कानूनी बारीकियां नहीं हैं। इनसे तय होता है कि घटना के अव्यवस्थित होने और सबके सरल जवाब चाहने पर कोई दूसरा इंजीनियर आपके निष्कर्ष को दोहरा पाएगा या नहीं।

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