অ্যাপ্লিকেশন লগে PII লুকিয়ে থাকে
অ্যাপ লগ ইঞ্জিনিয়ারিংয়ে সবচেয়ে উপেক্ষিত GDPR পৃষ্ঠগুলোর একটি। ইঞ্জিনিয়াররা আইন উপেক্ষা করেন বলে নয়। কারণ ব্যবহারকারীর বিবরণ দুর্ঘটনাক্রমে লগ ফাইলে প্রবেশ করে।
একটি একক JSON রিকোয়েস্ট লগে চারটি 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 ঝুঁকি বাড়ায়
টিমরা সব সময় লগ ফাইল বাইরের পক্ষের সাথে শেয়ার করে:
- পেন টেস্ট ফার্ম অ্যাপ আচরণ ম্যাপ করতে রেকর্ড পায়
- বাইরের পরামর্শদাতা ধীর জায়গা খুঁজতে লগ নমুনা ব্যবহার করেন
- লগ প্ল্যাটফর্ম (Elastic, Datadog, Splunk) পূর্ণ আউটপুট স্ট্রিম পায়
- SRE কন্ট্রাক্টর ইনসিডেন্টের সময় রেকর্ড অ্যাক্সেস করেন
- অন্য আইনি সত্তার ডেভ টিম ডিবাগিংয়ের জন্য ফাইল পায়
প্রতিটি শেয়ার GDPR আর্টিকেল ২৮ প্রশ্ন উত্থাপন করে। প্রাপক কি একজন প্রসেসর? কি কোনো Data Processing Agreement আছে? সেই ফাইলে ব্যবহারকারীর বিবরণ দেখার কি আইনি ভিত্তি আছে?
লগ প্ল্যাটফর্ম একটি সাধারণ ফাঁক। আসল ব্যবহারকারীর ইমেইল এবং IP সহ আউটপুট Elastic Cloud বা Datadog-এ পাঠানো একটি প্রক্রিয়াকরণ লিঙ্ক তৈরি করে। সেই লিঙ্কের জন্য DPA, স্ট্যান্ডার্ড ক্লজ এবং প্ল্যাটফর্ম EU-এর বাইরে থাকলে একটি ট্রান্সফার টুল দরকার। এর প্রতিটিতে সময় এবং আইনি পর্যালোচনা লাগে।
সহজ পথ: ফাইল আপনার সিস্টেম ছাড়ার আগে ব্যবহারকারীর বিবরণ সরিয়ে দিন। পূর্ণ আর্টিকেল ২৮ নিয়মের জন্য আমাদের কমপ্লায়েন্স ওভারভিউ পড়ুন।
কেন JSON কাঠামো সনাক্তকরণ কঠিন করে
JSON লগ ফাইলের কাঠামো ভিন্ন। সাধারণ টেক্সট স্ক্যানিং যথেষ্ট নয়।
নেস্টিং গভীরতা: ব্যবহারকারীর বিবরণ যেকোনো গভীরতায় দেখা যায়। ফিল্ড request.headers.x-forwarded-for-এ IP ঠিকানা থাকে। ফিল্ড response.body.errors[0].field_value-এ ব্যবহারকারীর ইনপুট থাকতে পারে। একটি ফ্ল্যাট টেক্সট স্ক্যান নেস্টেড পাথে লুকানো ফিল্ড মিস করে।
অসামঞ্জস্যপূর্ণ স্কিমা: প্রতিটি API এন্ডপয়েন্ট তার নিজস্ব আউটপুট আকার তৈরি করে। Auth ফাইল পেমেন্ট ফাইলের মতো দেখায় না। প্রোফাইল আপডেট ফাইল উভয়ের মতো দেখায় না। একটি স্থির-পাথ পদ্ধতি ব্যবহারকারীর বিবরণ মিস করে যা ত্রুটির প্রসঙ্গে অদ্ভুত পাথে দেখা যায়।
PII-এর সাথে মিশ্রিত প্রযুক্তিগত মান: স্ট্যাক ট্রেস, ত্রুটি কোড এবং টাইমস্ট্যাম্প অক্ষত থাকতে হবে। ব্যাপক মুছে দেওয়া প্রয়োজনীয় ফিল্ড মুছে ফাইল অকেজো করে দেয়।
সঠিক পদ্ধতি হলো বিষয়বস্তু-ভিত্তিক সনাক্তকরণ। ব্যবহারকারীর বিবরণ তারা কী — ইমেইল প্যাটার্ন, IP ফরম্যাট, named entity — সেটা দিয়ে খুঁজুন, কাঠামোতে কোথায় আছে সেটা দিয়ে নয়। এটি প্রতি-এন্ডপয়েন্ট সেটআপ ছাড়াই পরিবর্তনশীল স্কিমা সামলায়।
সামঞ্জস্যপূর্ণ প্রতিস্থাপন লগ কার্যকর রাখে
মূল প্রয়োজনীয়তা হলো রেফারেন্শিয়াল ইন্টিগ্রিটি। sarah.johnson@company.com যদি একটি রিকোয়েস্ট চেইনে ৪৭টি এন্ট্রিতে দেখা যায়, সব ৪৭টি অবশ্যই একই মানে ম্যাপ হতে হবে।
ম্যাপিং নিয়ম:
sarah.johnson@company.com→user1@example.com(ফাইল জুড়ে একই মান)82.123.45.67→192.0.2.1(RFC 5737 ডকুমেন্টেশন IP — স্পষ্টভাবে আসল নয়)+49 176 1234 5678→+49 XXX XXX XXXX(মাস্ক করা)
সেই ম্যাপিং দিয়ে একজন ডেভেলপার ৪৭টি এন্ট্রিতে user1@example.com ট্রেস করতে পারেন, রিকোয়েস্ট চেইন পুনর্গঠন করতে পারেন এবং বাগ ঠিক করতে পারেন — কোনো আসল ব্যবহারকারীর বিবরণ না দেখে।
এই মেটাডেটা ফিল্ডগুলো অপরিবর্তিত থাকে:
- টাইমস্ট্যাম্প (ব্যবহারকারীর তথ্য নয়)
- ত্রুটি কোড এবং ধরন (ব্যবহারকারীর তথ্য নয়)
- স্ট্যাক ট্রেস (প্রযুক্তিগত ID থাকতে পারে, ব্যবহারকারীর তথ্য নয়)
- HTTP মেথড, পাথ, স্ট্যাটাস কোড (ব্যবহারকারীর তথ্য নয়)
- মেট্রিক মান এবং লেটেন্সি ফিগার (ব্যবহারকারীর তথ্য নয়)
ফলাফল এমন একটি ফাইল যা ডিবাগ কাজের জন্য উপযোগী। এতে কোনো আসল ব্যবহারকারীর বিবরণ নেই। GDPR-এর অধীনে অ্যানোনিমাইজেশন এবং সিউডোনিমাইজেশনের পার্থক্যের জন্য আমাদের গ্লোসারি দেখুন।
ব্যবহারের ঘটনা: পেন টেস্ট লগ শেয়ারিং
একটি SaaS ফার্ম একটি বাইরের পেন টেস্ট টিমের সাথে ত্রৈমাসিক নিরাপত্তা পর্যালোচনা চালায়। সুযোগের জন্য auth প্রবাহ ম্যাপ করতে এবং ত্রুটির প্যাটার্ন বিশ্লেষণ করতে ৯০ দিনের প্রোডাকশন API আউটপুট দরকার ছিল।
কাঁচা ভলিউম: ১৮০ MB JSON ফাইল। PII গণনা: ৪,২০০ অনন্য ব্যবহারকারীর ইমেইল, ১,৮০০ অনন্য IP, ত্রুটির প্রসঙ্গে ৩৪০টি আংশিক অ্যাকাউন্ট নম্বর।
আগে ব্যবহারকারীর বিবরণ না সরিয়ে সেই ফাইলগুলো শেয়ার করলে প্রয়োজন হতো:
- পেন টেস্ট ফার্মের সাথে একটি DPA
- একটি GDPR আর্টিকেল ৪৬ ট্রান্সফার টুল (ফার্মটি EU-এর বাইরে ছিল)
- একটি ডেটা সাবজেক্ট নোটিস পর্যালোচনা
এর প্রতিটি আইনি কাজ এবং সময় যোগ করে।
PII স্ট্রিপিং প্রয়োগ করে:
- প্রক্রিয়ার সময়: ১৮০ MB-এর জন্য ২৫ মিনিট
- আউটপুট: ১৮০ MB কাঠামোগতভাবে একই ফাইল, সব ইমেইল এবং IP নিরাপদ মান দিয়ে প্রতিস্থাপিত
- ফলাফল: পেন টেস্ট টিম পূর্ণ প্রসঙ্গ পেয়েছে; কোনো আসল ব্যবহারকারীর বিবরণ তাদের কাছে পৌঁছায়নি
- GDPR ফলাফল: কোনো DPA দরকার নেই — স্ট্রিপ করা আউটপুট GDPR-এর অধীনে ব্যবহারকারীর তথ্য নয়
GDPR-এর অধীনে কোনটি বেনামী হিসেবে গণ্য হয় সে সম্পর্কে সাধারণ প্রশ্নের জন্য আমাদের FAQ দেখুন।
CI/CD-এ PII স্ট্রিপিং যুক্ত করা
যে টিমগুলো নিয়মিত আউটপুট শেয়ার করে তাদের জন্য এই ধাপ বিদ্যমান পাইপলাইনের মধ্যে চলতে পারে।
লগ রোটেশন:
- রোটেশন স্ক্রিপ্ট রাতে চলে
- আর্কাইভ করার বা যেকোনো লগ প্ল্যাটফর্মে পাঠানোর আগে স্ট্রিপিং ধাপ চলে
- স্ট্রিপ করা ফাইল বাইরের সিস্টেমে যায়
- মূল ফাইল পূর্ণ ধারণ সহ অভ্যন্তরীণ থাকে
প্রি-শেয়ারিং স্ক্রিপ্ট:
- ইঞ্জিনিয়ারকে একটি কন্ট্রাক্টরের সাথে নমুনা শেয়ার করতে হবে
- স্ক্রিপ্ট চালান:
input=raw-logs/ output=clean-logs/ clean-logs/ফোল্ডার শেয়ার করুন- ম্যানুয়াল PII পর্যালোচনা দরকার নেই
সাইডকার পদ্ধতি:
- সাইডকার ফরওয়ার্ড করার আগে আউটপুট স্ট্রিম স্ট্রিপ করে
- রিয়েল-টাইম স্ট্রিপিং লগ বিশ্লেষণের উপযোগিতা বজায় রাখে
- প্ল্যাটফর্ম কোনো আসল ব্যবহারকারীর বিবরণ পায় না
ধারণ নীতি ইন্টিগ্রেশন
GDPR আর্টিকেল ৫(১)(ই) স্টোরেজ সীমাবদ্ধতা প্রয়োজন। PII স্ট্রিপিং যেকোনো ধারণ নীতিতে মাপে:
- কাঁচা আউটপুট ৭ দিন রাখুন (দৈনন্দিন ডিবাগ কাজের জন্য)
- স্ট্রিপ করা ভার্সন ৯০ দিন রাখুন (ট্রেন্ড বিশ্লেষণ এবং ইনসিডেন্ট পর্যালোচনার জন্য)
- স্ট্রিপিং ধাপ ৭ম দিনে চলে
এটি স্টোরেজ সীমাবদ্ধতা পূরণ করে। দীর্ঘমেয়াদে কাঁচা আউটপুট রাখার ঝুঁকি দূর করে।