ایپلیکیشن لاگ میں PII چھپی ہے
انجینئرنگ میں App لاگ GDPR کی سب سے نظر انداز کی جانے والی سطحوں میں سے ایک ہیں۔ اس لیے نہیں کہ انجینئر قانون کو نظر انداز کرتے ہیں۔ بلکہ اس لیے کہ صارف کی تفصیلات لاگ فائلوں میں حادثاتی طور پر داخل ہو جاتی ہیں۔
ایک JSON request لاگ چار PII فیلڈز رکھ سکتا ہے:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
اس ایک اندراج میں ایک ای میل، ایک IP، اور ایک فون نمبر ہے۔ اسے روزانہ لاکھوں API کالز میں ضرب دیں۔ نتیجہ ایک بڑی PII سرگرمی ہے۔ اس کے لیے قانونی بنیاد، حدود، اور کنٹرول کی ضرورت ہے۔
تھرڈ پارٹی لاگ شیئرنگ GDPR خطرہ بڑھاتی ہے
ٹیمیں لاگ فائلیں باہر کے فریقوں کے ساتھ ہر وقت شیئر کرتی ہیں:
- Pen test فرمیں ایپ کے رویے کی mapping کے لیے ریکارڈ لیتی ہیں
- باہر کے مشیر سست جگہیں تلاش کرنے کے لیے لاگ samples استعمال کرتے ہیں
- لاگ پلیٹ فارم (Elastic، Datadog، Splunk) مکمل output streams وصول کرتے ہیں
- SRE ٹھیکیدار واقعات کے دوران ریکارڈ تک رسائی حاصل کرتے ہیں
- دوسرے قانونی اداروں میں dev ٹیمیں debugging کے لیے فائلیں وصول کرتی ہیں
ہر شیئرنگ GDPR آرٹیکل 28 سوالات اٹھاتی ہے۔ کیا وصول کنندہ ایک processor ہے؟ کیا Data Processing Agreement موجود ہے؟ کیا ان کے پاس ان فائلوں میں صارف کی تفصیلات دیکھنے کی قانونی بنیاد ہے؟
لاگ پلیٹ فارم ایک عام خلاء ہیں۔ Elastic Cloud یا Datadog کو اصل صارف ای میل اور IPs کے ساتھ output بھیجنا ایک processing لنک بناتا ہے۔ اس لنک کے لیے DPA، standard clauses، اور transfer tool کی ضرورت ہے اگر پلیٹ فارم EU سے باہر ہو۔
سادہ راستہ: فائلیں آپ کے سسٹم سے نکلنے سے پہلے صارف کی تفصیلات ہٹائیں۔
JSON ساخت detection کو کیوں مشکل بناتی ہے
JSON لاگ فائلیں ساخت میں مختلف ہوتی ہیں۔ عام متن اسکیننگ کافی نہیں ہے۔
Nesting گہرائی: صارف کی تفصیلات کسی بھی گہرائی میں ظاہر ہو سکتی ہیں۔ فیلڈ request.headers.x-forwarded-for IP پتے رکھتی ہے۔ فیلڈ response.body.errors[0].field_value صارف input رکھ سکتی ہے۔ ایک flat متن اسکین nested paths میں دفن فیلڈز کو چھوڑ دیتا ہے۔
متضاد schemas: ہر API endpoint اپنی output shape بناتا ہے۔ Auth فائلیں payment فائلوں جیسی نہیں لگتیں۔ ایک fixed-path نقطہ نظر عجیب paths پر error contexts میں ظاہر ہونے والی صارف تفصیلات چھوڑ دیتا ہے۔
PII کے ساتھ ملی تکنیکی قدریں: Stack traces، error codes، اور timestamps برقرار رہنے چاہئیں۔ ہر چیز کو اندھا دھند ہٹانا ضروری فیلڈز مٹا دیتا ہے اور فائل کو بیکار بنا دیتا ہے۔
صحیح نقطہ نظر content-based detection ہے۔ صارف تفصیلات کو ان کی اصلیت سے تلاش کریں — ای میل pattern، IP format، نامی entity — نہ کہ ساخت میں ان کے مقام سے۔ یہ variable schemas کو سنبھالتا ہے بغیر فی endpoint setup کے۔
مستقل Replacement لاگ کو مفید رکھتا ہے
aہم ضرورت referential integrity ہے۔ اگر sarah.johnson@company.com ایک request chain میں 47 اندراجات میں ظاہر ہوتا ہے، تو سبھی 47 کو ایک ہی قدر سے map کرنا چاہیے۔
Mapping قواعد:
sarah.johnson@company.com→user1@example.com(پوری فائل میں یکساں قدر)82.123.45.67→192.0.2.1(RFC 5737 documentation IP — واضح طور پر حقیقی نہیں)+49 176 1234 5678→+49 XXX XXX XXXX(masked)
اس mapping کے ساتھ، ایک developer user1@example.com کو 47 اندراجات میں trace کر سکتا ہے، request chain کو دوبارہ بنا سکتا ہے، اور bug ٹھیک کر سکتا ہے — بغیر کسی اصل صارف تفصیل کو دیکھے۔
یہ metadata فیلڈز بغیر تبدیلی کے رہتے ہیں:
- Timestamps (صارف ڈیٹا نہیں)
- Error codes اور اقسام (صارف ڈیٹا نہیں)
- Stack traces (tech IDs ہو سکتے ہیں، صارف ڈیٹا نہیں)
- HTTP طریقے، paths، status codes (صارف ڈیٹا نہیں)
- Metric قدریں اور latency اعداد (صارف ڈیٹا نہیں)
نتیجہ ایک فائل ہے جو debug کام کے لیے کام کرتی ہے۔ اس میں کوئی اصل صارف تفصیل نہیں ہے۔
استعمال کی صورت: Pen Test لاگ شیئرنگ
ایک SaaS فرم نے ایک باہر کی pen test ٹیم کے ساتھ سہ ماہی سیکیورٹی جائزہ چلایا۔ دائرے کے لیے auth flows کی mapping اور error patterns کے تجزیے کے لیے 90 دن کی production API output کی ضرورت تھی۔
خام حجم: 180 MB JSON فائلیں۔ PII تعداد: 4,200 منفرد صارف ای میل، 1,800 منفرد IPs، error contexts میں 340 جزوی اکاؤنٹ نمبر۔
صارف تفصیلات پہلے ہٹائے بغیر، ان فائلوں کو شیئر کرنے کے لیے درکار ہوتا:
- pen test فرم کے ساتھ ایک DPA
- ایک GDPR آرٹیکل 46 transfer tool (فرم EU سے باہر تھی)
- ایک data subject notice review
PII stripping لاگو کرنے کے ساتھ:
- پروسیس وقت: 180 MB کے لیے 25 منٹ
- آؤٹ پٹ: 180 MB کی ساختی طور پر یکساں فائلیں، تمام ای میل اور IPs محفوظ قدروں سے بدلے گئے
- نتیجہ: pen test ٹیم کو مکمل context ملا؛ کوئی اصل صارف تفصیل ان تک نہیں پہنچی
- GDPR نتیجہ: کوئی DPA درکار نہیں — stripped output GDPR کے تحت صارف ڈیٹا نہیں ہے
CI/CD میں PII Stripping کو شامل کرنا
ان ٹیموں کے لیے جو باقاعدگی سے output شیئر کرتی ہیں، یہ قدم موجودہ pipelines کے اندر چل سکتی ہے۔
لاگ rotation:
- Rotation script رات کو چلتا ہے
- Stripping قدم archiving یا کسی بھی لاگ پلیٹ فارم کو بھیجنے سے پہلے چلتا ہے
- Stripped فائلیں باہر کے سسٹمز کو جاتی ہیں
- اصل فائلیں مکمل رکھ رکھاؤ کے ساتھ اندرونی رہتی ہیں
Pre-sharing script:
- انجینئر کو ایک ٹھیکیدار کے ساتھ ایک sample شیئر کرنا ہے
- script چلاتا ہے:
input=raw-logs/ output=clean-logs/ clean-logs/فولڈر شیئر کرتا ہے- کوئی دستی PII review نہیں چاہیے
Sidecar نقطہ نظر:
- Sidecar forwarding سے پہلے output stream کو strip کرتا ہے
- ریئل ٹائم stripping لاگ تجزیے کے لیے utility برقرار رکھتی ہے
- پلیٹ فارم کو کوئی اصل صارف تفصیل نہیں ملتی
Retention Policy انٹیگریشن
GDPR آرٹیکل 5(1)(e) کے لیے storage limitation درکار ہے۔ PII stripping کسی بھی retention policy میں فٹ ہو جاتی ہے۔
- خام output 7 دنوں کے لیے رکھا جاتا ہے (روزانہ debug کام کے لیے)
- Stripped ورژن 90 دنوں کے لیے رکھے جاتے ہیں (رجحان تجزیہ اور واقعہ جائزے کے لیے)
- Stripping قدم 7ویں دن چلتی ہے
یہ storage limitation پورا کرتا ہے۔ خام output کو طویل مدت تک رکھنے کا خطرہ ختم کرتا ہے۔