আপনার লগ স্ট্যাকে নীরব GDPR ঝুঁকি
২০২৬ সালে আপডেট করা হয়েছে
বেশিরভাগ দল তাদের ডেটাবেস ব্যক্তিগত তথ্যের জন্য পরীক্ষা করে। কম দল একই কাজ তাদের লগ সিস্টেমের জন্য করে।
GDPR অনুচ্ছেদ ৫(১)(ই) আপনি কতক্ষণ ব্যক্তিগত তথ্য সংরক্ষণ করতে পারবেন তা সীমিত করে। ডেটাবেসের জন্য, দলগুলো নীতি নির্ধারণ করে এবং মুছে ফেলার কাজ চালায়। লগ ফাইলের জন্য, নিয়মটা সহজ: ডিবাগিংয়ের জন্য ৯০ দিন সব কিছু রাখো।
সমস্যা? সেই রেকর্ডে ব্যক্তিগত তথ্য আছে। রিকোয়েস্ট এন্ট্রিতে ব্যবহারকারীর ইমেইল থাকে। ত্রুটি ক্যাপচারে কাঁচা ইনপুট মান থাকে। অ্যাক্সেস এন্ট্রিতে IP ঠিকানা থাকে। এগুলোর প্রতিটি GDPR-এর অধীনে ব্যক্তিগত তথ্য হিসেবে গণ্য। আপনার দলের প্রতিটির জন্য একটি আইনগত ভিত্তি এবং ধারণ পরিকল্পনা প্রয়োজন।
আপনার লগ ফাইলে কী শেষ হয়
মানক ওয়েব অ্যাপ লগিং বিস্তৃত PII টেনে আনে।
অ্যাক্সেস রেকর্ড (nginx/Apache):
- IP ঠিকানা — EDPB গাইডেন্স অনুযায়ী ব্যক্তিগত তথ্য
- ইউজার-এজেন্ট স্ট্রিং — ডিভাইস ফিঙ্গারপ্রিন্টিং সক্ষম করতে পারে
- সেশন টোকেন — আউটপুটে লেখা হলে
অ্যাপ রেকর্ড (স্ট্রাকচার্ড JSON):
- ব্যবহারকারী আইডি এবং ইমেইল ঠিকানা
- ইনপুট ত্রুটি — প্রায়ই কাঁচা অবৈধ মান অন্তর্ভুক্ত করে, যা বাস্তব ব্যবহারকারীর তথ্য হতে পারে
- ব্যবসায়িক ইভেন্ট — গ্রাহক অ্যাকাউন্টের সাথে যুক্ত অর্ডার আইডি
- সার্চ কোয়েরি — নাম বা ঠিকানা থাকতে পারে
API গেটওয়ে রেকর্ড:
- অথ হেডার — কিছু সেটআপে আংশিকভাবে ক্যাপচার করা
- কোয়েরি প্যারাম — ব্যবহারকারী আইডি, নাম বা ইমেইল বহন করতে পারে
- রিকোয়েস্ট এবং রেসপন্স বডি — ডিবাগ-লেভেল সেটআপে উপস্থিত
ডেটাবেস অডিট এন্ট্রি:
email = 'user@example.com'-এর মতো WHERE ক্লজ সহ SQL কোয়েরি- কোয়েরি প্যারামে আক্ষরিক ব্যক্তিগত মান
এটি ইচ্ছাকৃতভাবে করা হয় না। এটি GDPR নয়, ডিবাগিংয়ের জন্য তৈরি লগিংয়ের পার্শ্ব প্রতিক্রিয়া।
IP ঠিকানায় EDPB গাইডেন্স
ইউরোপীয় ডেটা সুরক্ষা বোর্ড বলে IP ঠিকানা ব্যক্তিগত তথ্য। ISP সেগুলো গ্রাহকদের সাথে যুক্ত করতে পারে। একটি প্রতিষ্ঠানের মধ্যে, সেগুলো নির্দিষ্ট ব্যবহারকারীদের শনাক্ত করতে পারে।
প্রভাব সরাসরি। IP ঠিকানাসহ অ্যাক্সেস রেকর্ড ব্যক্তিগত রেকর্ড। ১২ মাস ধরে nginx আউটপুট রাখা মানে ১২ মাস ধরে ব্যক্তিগত তথ্য রাখা। এর জন্য অনুচ্ছেদ ৬-এর অধীনে একটি আইনগত ভিত্তি প্রয়োজন। এছাড়াও ধারণ কাল আপনার উল্লেখিত উদ্দেশ্যের সাথে মেলা দরকার।
বেশিরভাগ দল এই ধাপ এড়িয়ে যায়। "নিরাপত্তা বলে তাই আমরা ৯০ দিন রাখি" একটি নিয়মের কথা। এটি GDPR অনুচ্ছেদ ৫(১)(ই) পর্যালোচনা নয়। এটি একটি বিস্তৃত কার্যক্রমে কীভাবে ফিট করে তা জানতে আমাদের আইনি সম্মতি ওভারভিউ দেখুন।
সম্মতিতে পৌঁছানোর উপায়
বেশিরভাগ দলের জন্য ব্যবহারিক পথ হল ধারণ উইন্ডো কমানো নয়। দীর্ঘ উইন্ডোর জন্য পরিচালনাগত এবং নিরাপত্তার কারণগুলো বাস্তব। ভালো পথ হল দীর্ঘমেয়াদী সংরক্ষণের আগে রেকর্ড মাস্ক করা।
একটি স্তরযুক্ত মডেল ভালো কাজ করে।
০–৭ দিন: সক্রিয় ডিবাগিংয়ের জন্য সম্পূর্ণ কাঁচা রেকর্ড। বেশিরভাগ দলের জন্য সাত দিন যথেষ্ট সংক্ষিপ্ত।
৭–৯০ দিন: প্রবণতা বিশ্লেষণ এবং নিরাপত্তা পর্যালোচনার জন্য মাস্ক করা রেকর্ড। IP ঠিকানা বদলে দেওয়া হয়। ব্যবহারকারীর ইমেইল স্থিতিশীল টোকেন হয়। অ্যাকাউন্ট নম্বর মাস্ক করা হয়। মূল ক্ষেত্র — টাইমস্ট্যাম্প, ত্রুটি কোড, লেটেন্সি, এন্ডপয়েন্ট — অপরিবর্তিত রাখা হয়।
৯০+ দিন (প্রয়োজনে): শুধুমাত্র সমষ্টিগত আউটপুট। ইভেন্ট গণনা, ত্রুটির হার, লেটেন্সি রেঞ্জ। কোনো ব্যবহারকারী-স্তরের রেকর্ড থাকে না।
ব্যক্তিগত তথ্য সাত দিনে থামে। সমষ্টিগত আউটপুট কাউকে প্রকাশ না করে এগিয়ে যেতে পারে। আরও বিস্তারিত জানতে নিরাপত্তা ও সম্মতি দেখুন।
মনিটরিংয়ের জন্য কাঠামো অক্ষুণ্ণ রাখুন
ভালো মাস্কিং JSON কাঠামো অক্ষুণ্ণ রাখে। শুধু কন্টেন্ট বদলায়। এটি আউটপুট ডিবাগিং এবং অ্যালার্টের জন্য উপযোগী রাখে।
অপরিবর্তিত রাখা হয়:
- JSON কী এবং নেস্টিং
- টাইমস্ট্যাম্প এবং সময়ের ক্রম
- ত্রুটির ধরন এবং HTTP স্ট্যাটাস কোড
- HTTP মেথড, পাথ এবং লেটেন্সি মান
- ব্যবসায়িক ইভেন্টের ধরন
বদলে দেওয়া হয়:
- ইমেইল ঠিকানা → মূল অনুযায়ী স্থিতিশীল টোকেন (যেমন
user1@example.com) - IP ঠিকানা → RFC 5737 রেঞ্জ (
192.0.2.x) - অ্যাকাউন্ট নম্বর →
ACCT_XXXXX - ফোন নম্বর →
+XX XXX XXX XXXX - ত্রুটির টেক্সটে নাম →
[PERSON]
স্থিতিশীল টোকেন ট্রেস উপযোগী রাখে। ৪০টি এন্ট্রিতে user1@example.com-এর ট্রেস মূলটির মতোই কাজ করে। সমষ্টিগত মেট্রিক — ত্রুটির হার, লেটেন্সি, থ্রুপুট — একেবারেই ব্যক্তিগত তথ্যের প্রয়োজন নেই। pseudonymization এবং anonymization শব্দের জন্য শব্দকোষ দেখুন।
এটি ইন্টিগ্রেট করার তিনটি উপায়
তিনটি প্যাটার্ন বেশিরভাগ ইঞ্জিনিয়ারিং দলকে কভার করে।
বিকল্প ১ — পাইপলাইন মাস্কিং: Fluentd বা Logstash প্রেরণের আগে প্রতিটি লাইন ইন্টারসেপ্ট করে। একটি মাস্কিং ধাপ ইনলাইনে চলে। Elastic বা Datadog শুধুমাত্র পরিষ্কার রেকর্ড পায়। কোনো অ্যাপ কোড পরিবর্তনের প্রয়োজন নেই।
বিকল্প ২ — রাতের ব্যাচ: কাঁচা রেকর্ড স্থানীয় স্টোরেজে পৌঁছায়। একটি রাতের কাজ আগের দিনের আউটপুট মাস্ক করে এবং কাঁচা সংস্করণ মুছে দেয়। মাস্ক করা রেকর্ড দীর্ঘমেয়াদী স্টোরেজে যায়। কাঁচা আউটপুট কেবল সাত দিন রাখা হয়।
বিকল্প ৩ — শেয়ার-পূর্ব মাস্কিং: কাঁচা রেকর্ড কঠোর অ্যাক্সেস নিয়ন্ত্রণ সহ অভ্যন্তরীণ থাকে। পেন টেস্টার বা বাইরের ঠিকাদারদের সাথে শেয়ার করার আগে একটি মাস্কিং পাস চালান। বাহ্যিক পক্ষগুলো সর্বদা পরিষ্কার সংস্করণ পায়।
GDPR ডকুমেন্টের জন্য, মাস্কিং অনুচ্ছেদ ৩২-এর অধীনে একটি "প্রযুক্তিগত ব্যবস্থা"। অনুচ্ছেদ ৩০-এর অধীনে আপনার প্রক্রিয়াকরণ কার্যক্রমের রেকর্ডে (RoPA) টুল, এর সেটআপ এবং আপনার ধারণ নীতি রেকর্ড করুন। সাধারণ RoPA প্রশ্নের জন্য আমাদের FAQ দেখুন।
বাস্তব-বিশ্বের উদাহরণ চান? কংক্রিট বাস্তবায়নের বিস্তারিত জানতে কেস স্টাডি দেখুন। কোন প্ল্যানে বিল্ট-ইন মাস্কিং পাইপলাইন অন্তর্ভুক্ত তা দেখতে আমাদের মূল্য নির্ধারণ-ও পর্যালোচনা করুন।