ব্লগে ফিরে যান

হ্যাশ কখন ব্যক্তিগত ডেটা হয়? CJEU-এর SRB রায় এবং অ্যানালিটিক্সে পরিচয়

CJEU-এর EDPS বনাম SRB রায় শনাক্তযোগ্যতাকে একটি আপেক্ষিক, প্রসঙ্গনির্ভর পরীক্ষায় পরিণত করেছে। হ্যাশ-ভিত্তিক অ্যানালিটিক্সের জন্য এর অর্থ কী, এবং কেন প্রতিদিন ঘূর্ণায়মান সল্টেড হ্যাশ আদালতের ব্যাখ্যা ও EDPB-র কঠোরতর ব্যাখ্যা—দুটোতেই টিকে যায়, তা এখানে আলোচিত।

প্রতিটি অ্যানালিটিক্স ভেন্ডর যে প্রশ্ন এড়িয়ে যায় তা জিজ্ঞেস করা সহজ কিন্তু উত্তর দেওয়া কঠিন: আপনার ডেটাবেসের identifier কি ব্যক্তিগত ডেটা? ২০২৫ সালের ৪ সেপ্টেম্বর CJEU (ইউরোপীয় বিচার আদালত) বহু বছরের সবচেয়ে গুরুত্বপূর্ণ উত্তরটি দিয়েছে, এবং পুরো পরীক্ষাটিকে ডেটাকে বিচ্ছিন্নভাবে দেখার বদলে প্রসঙ্গকে কেন্দ্র করে নতুন করে গড়েছে।

EDPS বনাম SRB আসলে কী সিদ্ধান্ত দিয়েছে

মামলাটি — EDPS বনাম SRB, C-413/23 P — Banco Popular-এর সমাধান প্রক্রিয়া থেকে উদ্ভূত। Single Resolution Board (SRB) শেয়ারহোল্ডারদের মন্তব্য সংগ্রহ করে, প্রতিটি লেখকের পরিচয়কে একটি অ্যালফানিউমেরিক কোড দিয়ে প্রতিস্থাপন করে, এবং কোডকৃত মন্তব্যগুলো স্বাধীন মূল্যায়নকারী হিসেবে Deloitte-কে পাঠায়। কোড উল্টে দেওয়ার কোনো চাবি Deloitte-র কাছে ছিল না, লেখকদের কাছে পৌঁছানোর অন্য কোনো পথও ছিল না।

CJEU রায় দেয় যে ছদ্মনামকৃত (pseudonymised) ডেটা এটি স্পর্শ করা প্রতিটি পক্ষের জন্য স্বয়ংক্রিয়ভাবে ব্যক্তিগত ডেটা নয়। কোনো ডেটাসেট ব্যক্তিগত কি না তা মূল্যায়িত হয় ধারকের সাপেক্ষে — নির্দিষ্ট প্রাপকের অবস্থান থেকে, তার কাছে বাস্তবে উপলব্ধ প্রযুক্তিগত, সাংগঠনিক ও আইনি উপায়গুলো বিবেচনায় নিয়ে।

এটিই আপেক্ষিক (বা প্রসঙ্গগত) শনাক্তযোগ্যতার পরীক্ষা, এবং এটি Recital 26-এর "যুক্তিসঙ্গতভাবে ব্যবহৃত হওয়ার সম্ভাবনাযুক্ত উপায়"-এর কার্যকর ব্যাখ্যা। কন্ট্রোলারের হাতে যে ডেটা ব্যক্তিগত, তা এমন একজন প্রাপকের হাতে অ-ব্যক্তিগত হতে পারে যে সত্যিই কাউকে পুনঃশনাক্ত করতে পারে না।

EDPB-র সঙ্গে টানাপোড়েন

আদালত ভেন্ডরদের অবাধ ছাড় দেয়নি। ছদ্মনামকরণ বিষয়ে EDPB-র Guidelines 01/2025 ইচ্ছাকৃতভাবে কঠোরতর অবস্থান নেয়: যতক্ষণ যে কেউ — কন্ট্রোলার বা কোনো তৃতীয় পক্ষ — পুনঃশনাক্তের উপায় ধরে রাখে, ততক্ষণ ছদ্মনামকৃত ডেটা ব্যক্তিগত ডেটাই থাকে। বেনামিকরণ ও ছদ্মনামকরণ নিয়ে ২০২৬ সালের ফেব্রুয়ারির EDPB প্রতিবেদন আসলে বোর্ডের নিজস্ব অবস্থান ও আদালতের অবস্থানের মধ্যেকার ঠিক এই ফারাকটি নিয়েই কাজ।

ডেভেলপারদের জন্য বাস্তব ব্যাখ্যাটি রক্ষণশীল। শুধু আপনার সেবা একটি hashed মান উল্টাতে পারে না বলেই ধরে নেবেন না যে তা GDPR-র আওতার বাইরে। সঠিক প্রশ্ন হলো অতিরিক্ত তথ্য ধারণকারী যে কারো জন্য পুনঃশনাক্ত যুক্তিসঙ্গতভাবে সম্ভাব্য কি না — এবং সেই অতিরিক্ত তথ্য আদৌ এখনও আছে কি না।

কেন বেশিরভাগ অ্যানালিটিক্স হ্যাশ পরীক্ষায় ব্যর্থ হয়

কোনো identifier হ্যাশ করা মানে বেনামিকরণ নয়। একটি ইমেল ঠিকানার SHA-256 নির্ধারণবাদী (deterministic): একই ইমেল সবসময় একই digest দেয়। সম্ভাব্য ইমেলের তালিকা থাকা যে কেউ সেগুলো হ্যাশ করে মিলিয়ে নিতে পারে। এই হ্যাশ একটি স্থিতিশীল, সংযোগযোগ্য চাবি — সর্বোত্তম ক্ষেত্রে ছদ্মনামকরণ, এবং দুই ব্যাখ্যাতেই ব্যক্তিগত ডেটা, কারণ পুনঃশনাক্তের উপায় অনায়াসে উপলব্ধ।

একই ফাঁদ ধরে একটি hashed IP, একটি hashed device ID, কিংবা ছোট ও গণনাযোগ্য পরিসর থেকে নেওয়া কোনো input-এর যেকোনো digest-কে। নির্ধারণবাদিতা যোগ অনুমানযোগ্য input সমান পুনঃশনাক্ত। হ্যাশ ফাংশন বাইট বদলায়, সংযোগযোগ্যতা নয়।

কী একটি হ্যাশকে সত্যিই রক্ষণযোগ্য করে

দুটি বৈশিষ্ট্য একটি হ্যাশকে "ছদ্মনামকৃত ব্যক্তিগত ডেটা" থেকে "যুক্তিসঙ্গতভাবে পুনঃশনাক্ত-অযোগ্য"-র দিকে সরায়: একটি গোপন salt যা কখনো ডেটার পাশে সংরক্ষিত হয় না, এবং একটি input যা সম্পূর্ণভাবে অনুমান করা যায় না এবং সময় পেরিয়ে টিকে থাকে না। Monoid-এর পরিচয় মডেল ঠিক এর ওপরই গড়া:

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

কাঁচা IP ও User-Agent শুধু digest গণনার জন্য প্রয়োজনীয় সময়টুকু Worker-এর মেমরিতে থাকে; D1 হ্যাশ সংরক্ষণ করে, input কখনো নয়। SALT_SECRET সার্ভার-সাইডে রাখা হয় এবং কখনো ডেটার পাশে লেখা হয় না, তাই সংরক্ষিত হ্যাশের বিরুদ্ধে rainbow-table বা brute-force আক্রমণ কোনো অবলম্বন পায় না। আর যেহেতু তারিখ একটি input, একই দর্শকের digest প্রতি UTC মধ্যরাতে ঘুরে যায়। সম্পর্কযুক্ত করার মতো কোনো স্থিতিশীল, দিন-পেরোনো চাবি নেই।

এই গঠনকে দুটি পরীক্ষার মধ্য দিয়ে চালান। CJEU-র আপেক্ষিক মানদণ্ডে, সংরক্ষিত হ্যাশের কোনো প্রাপক — নিজের D1-তে কোয়েরি করা Monoid সহ — পুনঃশনাক্তের জন্য যুক্তিসঙ্গতভাবে সম্ভাব্য উপায় ধরে রাখে না, কারণ salt পৃথকীকৃত এবং input গণনাযোগ্য নয়। EDPB-র কঠোরতর "যে কেউ" মানদণ্ডে, প্রয়োজনীয় অতিরিক্ত তথ্য (কাঁচা IP, সঙ্গে UA, সঙ্গে সেই নির্দিষ্ট তারিখের গোপন salt) request সম্পন্ন হওয়ার পর কোথাও সংরক্ষিত থাকে না। পুনঃশনাক্তের উপায় কেবল সীমিত নয়; সেগুলোর অস্তিত্বই থাকে না।

নিজের স্ট্যাক কীভাবে নিরীক্ষা করবেন

এই রায় একটি সুনির্দিষ্ট চেকলিস্ট দেয় যা আপনি নির্ভরশীল যেকোনো অ্যানালিটিক্সে প্রয়োগ করতে পারেন:

  • hashed input কি গণনাযোগ্য? একটি ইমেল, একটি ফোন নম্বর, বা একটি কাঁচা IP হ্যাশ করে সম্ভাব্য তালিকার সঙ্গে মেলানো যায়। input পরিসর ছোট হলে, হ্যাশ বাস্তবে উল্টানো যায়।
  • একটি গোপন salt কি সংরক্ষিত ডেটা থেকে পৃথক? salt ছাড়া হ্যাশ, কিংবা একই স্টোরে থাকা salt-যুক্ত হ্যাশ, পুনঃশনাক্তের বিরুদ্ধে কোনো প্রকৃত বাধা দেয় না।
  • identifier কি সেশন পেরিয়ে টিকে থাকে? যে স্থিতিশীল চাবি একজন ব্যক্তির কার্যকলাপকে সপ্তাহজুড়ে সংযুক্ত করে, তা সব ব্যাখ্যাতেই ব্যক্তিগত ডেটা। প্রতিদিন ঘূর্ণায়মান চাবি কোনো প্রোফাইল জমাতে পারে না।

CJEU ছদ্মনামকরণকে নিরাপদ আশ্রয় ঘোষণা করেনি, এবং EDPB নিশ্চিত করছে যেন কেউ তা সেভাবে না পড়ে। টেকসই অবস্থান সেটিই যা জিততে কোনো ব্যাখ্যার দরকার পড়ে না: একটি গণনাযোগ্য-নয় input-এর ওপর সল্টেড, প্রতিদিন ঘূর্ণায়মান হ্যাশ কারো পক্ষেই যুক্তিসঙ্গতভাবে পুনঃশনাক্ত-যোগ্য নয়, কারণ এটি উল্টানোর জন্য প্রয়োজনীয় উপাদান কখনো রাখাই হয়নি।

সূত্র

Comments

Loading comments…