आपके लॉग स्टैक में छिपा GDPR जोखिम
2026 के लिए अपडेट किया गया
अधिकांश टीमें व्यक्तिगत जानकारी के लिए अपना डेटाबेस जाँचती हैं। कम लोग अपने लॉग सिस्टम के लिए ऐसा करते हैं।
GDPR अनुच्छेद 5(1)(e) व्यक्तिगत जानकारी को कितने समय तक संग्रहीत किया जा सकता है, उसे सीमित करता है। डेटाबेस के लिए, टीमें नीतियाँ निर्धारित करती हैं और deletion जॉब चलाती हैं। लॉग फाइलों के लिए, नियम सरल लगता है: debugging के लिए सब कुछ 90 दिनों तक रखें।
समस्या? वे रिकॉर्ड व्यक्तिगत जानकारी रखते हैं। Request प्रविष्टियाँ उपयोगकर्ता ईमेल रखती हैं। Error captures raw input मूल्य रखते हैं। Access प्रविष्टियाँ IP पते रखती हैं। इनमें से प्रत्येक GDPR के तहत व्यक्तिगत जानकारी है। आपकी टीम को प्रत्येक के लिए एक वैध आधार और अवधारण योजना की जरूरत है।
आपकी लॉग फाइलों में क्या जाता है
मानक वेब ऐप लॉगिंग PII की एक विस्तृत श्रृंखला खींचती है।
Access रिकॉर्ड (nginx/Apache):
- IP पते — EDPB मार्गदर्शन के अनुसार व्यक्तिगत जानकारी
- User-agent strings — device fingerprinting सक्षम कर सकते हैं
- Session tokens — यदि आउटपुट में लिखे जाएँ
ऐप रिकॉर्ड (structured JSON):
- User ID और ईमेल पते
- Input errors — अक्सर raw अमान्य मूल्य शामिल होते हैं जो वास्तविक उपयोगकर्ता जानकारी हो सकती है
- Business events — ग्राहक खातों से जुड़े order ID
- खोज queries — नाम या पते हो सकते हैं
API gateway रिकॉर्ड:
- Auth headers — कुछ सेटअप में आंशिक रूप से captured
- Query params — user ID, नाम या ईमेल हो सकते हैं
- Request और response bodies — debug-स्तर सेटअप में मौजूद
Database audit प्रविष्टियाँ:
email = 'user@example.com'जैसे WHERE खंडों के साथ SQL queries- Query params में literal व्यक्तिगत मूल्य
यह जानबूझकर नहीं होता। यह debugging के लिए बनाए लॉगिंग का एक दुष्प्रभाव है — GDPR के लिए नहीं।
IP पते पर EDPB मार्गदर्शन
European Data Protection Board कहता है कि IP पते व्यक्तिगत जानकारी हैं। ISP उन्हें ग्राहकों से जोड़ सकते हैं। एक संगठन के भीतर, वे विशिष्ट उपयोगकर्ताओं की पहचान कर सकते हैं।
प्रभाव सीधा है। IP पते वाले Access रिकॉर्ड व्यक्तिगत रिकॉर्ड हैं। nginx आउटपुट को 12 महीने रखने का मतलब है व्यक्तिगत जानकारी को 12 महीने रखना। इसके लिए अनुच्छेद 6 के तहत वैध आधार चाहिए। यह एक व्यापक कार्यक्रम में कैसे फिट होता है, इसके लिए हमारा कानूनी अनुपालन अवलोकन देखें।
अनुपालन तक कैसे पहुँचें
अधिकांश टीमों के लिए व्यावहारिक मार्ग अवधारण windows काटना नहीं है। लंबी windows के लिए परिचालन और सुरक्षा कारण वास्तविक हैं। बेहतर मार्ग है दीर्घकालिक स्टोरेज से पहले रिकॉर्ड mask करना।
एक tiered मॉडल अच्छी तरह काम करता है।
0-7 दिन: सक्रिय debugging के लिए पूरे raw रिकॉर्ड।
7-90 दिन: trend विश्लेषण और सुरक्षा समीक्षा के लिए Masked रिकॉर्ड। IP पते बदले जाते हैं। उपयोगकर्ता ईमेल stable टोकन बनते हैं। खाता संख्याएँ masked होती हैं। Timestamps, error कोड, latency, endpoints — सब जैसे हैं वैसे रहते हैं।
90+ दिन (यदि जरूरी हो): केवल समग्र आउटपुट। Event गिनती, error दरें, latency ranges। कोई user-level रिकॉर्ड नहीं रहते।
व्यक्तिगत जानकारी सात दिनों पर रुकती है। अधिक विवरण के लिए Security & Compliance देखें।
Monitoring के लिए संरचना बरकरार रखें
अच्छी masking JSON संरचना को बरकरार रखती है। यह केवल सामग्री बदलती है। यह आउटपुट को debugging और alerts के लिए उपयोगी रखती है।
जैसे हैं वैसे रखें:
- JSON keys और nesting
- Timestamps और समय क्रम
- Error प्रकार और HTTP status codes
- HTTP methods, paths और latency मूल्य
- Business event प्रकार
बदलें:
- ईमेल पते → मूल के अनुसार stable टोकन (जैसे
user1@example.com) - IP पते → RFC 5737 ranges (
192.0.2.x) - खाता संख्याएँ →
ACCT_XXXXX - फोन नंबर →
+XX XXX XXX XXXX - error text में नाम →
[PERSON]
Stable टोकन traces को उपयोगी रखते हैं। user1@example.com के लिए 40 प्रविष्टियों में trace मूल जैसा ही काम करता है। Pseudonymization और anonymization शर्तों के लिए Glossary देखें।
इसे एकीकृत करने के तीन तरीके
तीन पैटर्न अधिकांश इंजीनियरिंग टीमों को कवर करते हैं।
विकल्प 1 — Pipeline masking: Fluentd या Logstash प्रत्येक line को आगे भेजने से पहले intercept करता है। एक masking चरण inline चलता है। Elastic या Datadog को केवल साफ रिकॉर्ड मिलते हैं। कोई ऐप code बदलाव नहीं चाहिए।
विकल्प 2 — Nightly batch: Raw रिकॉर्ड local storage में जाते हैं। एक nightly जॉब पिछले दिन के आउटपुट को mask करता है और raw संस्करण हटाता है। Masked रिकॉर्ड दीर्घकालिक storage में जाते हैं। Raw आउटपुट केवल सात दिनों तक रखा जाता है।
विकल्प 3 — Pre-share masking: Raw रिकॉर्ड सख्त access नियंत्रणों के साथ आंतरिक रहते हैं। Pen testers या बाहरी ठेकेदारों के साथ साझा करने से पहले एक masking pass चलाएँ। बाहरी पक्षों को हमेशा साफ संस्करण मिलते हैं।
GDPR दस्तावेज़ीकरण के लिए, masking अनुच्छेद 32 के तहत एक "तकनीकी उपाय" है। अनुच्छेद 30 के तहत अपने Records of Processing Activities (RoPA) में टूल, इसकी सेटअप और अवधारण नीति रिकॉर्ड करें। सामान्य RoPA प्रश्नों के लिए हमारा FAQ देखें।
एक वास्तविक दुनिया का उदाहरण चाहते हैं? ठोस कार्यान्वयन विवरण के लिए case studies देखें। आप हमारी pricing भी देख सकते हैं कि कौन सी योजना built-in masking pipeline शामिल करती है।