Oracle Data Redaction ও Masking: সংবেদনশীল ডেটা সঠিক উপায়ে লুকানো

যে-ই আপনার ডেটাবেজে হাত দেয়, তার সবকিছু দেখার দরকার নেই। একজন সাপোর্ট এজেন্টের কাস্টমার শনাক্ত করা দরকার — পুরো কার্ড নম্বর পড়া নয়। একজন ডেভেলপারের টেস্ট করার জন্য বাস্তবসম্মত ডেটা দরকার — আপনার আসল কাস্টমারের বেতন বা ফোন নম্বর নয়। এনক্রিপশন এটা সমাধান করে না — অনুমোদিত ইউজার এখনও আসল মান দেখে। যা সমাধান করে তা হলো redaction আর masking: দুটি Oracle ফিচার যা যাদের দেখা উচিত নয় তাদের কাছ থেকে সংবেদনশীল ডেটা লুকিয়ে রাখে, অথচ যাদের দরকার তাদের জন্য ব্যবহারযোগ্য রাখে। এই গাইডে থাকছে পার্থক্য, কখন কোনটা ব্যবহার করবেন, আর এগুলো কীভাবে কাজ করে — কমান্ডসহ।

১. Redaction বনাম Masking বনাম Encryption: একটি নয়, তিনটি কাজ

এই তিনটি সবসময় গুলিয়ে ফেলা হয়, তাই পরিষ্কারভাবে আলাদা করে নিই — কারণ ভুলটা ব্যবহার করলে পরিশ্রম নষ্ট হয়।

Encryption (TDE) ডেটাকে ডিস্কে অপাঠ্য করে দেয়। কেউ ফাইল চুরি করলে সে শুধু ciphertext পায়। অনুমোদিত ইউজার আসল ডেটা স্বাভাবিকভাবেই দেখে। এটা স্টোরেজ পাহারা দেয়, স্ক্রিন নয়। (এটা পুরোপুরি আলোচনা করেছি TDE গাইডে।)

Redaction মান লুকায় স্ক্রিনে, query-time-এ, লাইভ ডেটাবেজে। ডিস্কের ডেটায় হাত পড়ে না; নির্দিষ্ট ইউজার শুধু একটি masked ফল দেখে — কার্ডের শেষ চার অঙ্ক, X দিয়ে ঢাকা বেতন। এটা মানুষ কী দেখে তা পাহারা দেয়।

Masking মানকে স্থায়ীভাবে বাস্তবসম্মত নকল দিয়ে বদলে দেয়, সাধারণত কপি বানানোর সময়। আসল ডেটা কখনও প্রোডাকশন ছাড়ে না। এটা ডেভেলপার ও অ্যানালিস্টদের হাতে তুলে দেওয়া কপিগুলো পাহারা দেয়।

Encryption রক্ষা করে ফাইল-চোরের বিরুদ্ধে। Redaction রক্ষা করে অতি-প্রিভিলেজধারীর চোখের বিরুদ্ধে। Masking রক্ষা করে সংবেদনশীল ডেটা টেস্ট সিস্টেমে ছড়িয়ে পড়ার বিরুদ্ধে। আলাদা হুমকি, আলাদা টুল।

২. Oracle Data Redaction কীভাবে কাজ করে

Data Redaction হলো ডায়নামিক — এটা ঘটে query চালানোর মুহূর্তে, আর সংরক্ষিত ডেটা কখনও বদলায় না। আপনি একটি টেবিল-কলামে একটি policy সংজ্ঞায়িত করেন যা বলে "এই ইউজারদের জন্য বেরোনোর পথে এই মানটি রূপান্তর করো।"

ইঞ্জিন query-র ফলাফল আটকে ইউজার দেখার আগেই রূপান্তরটি প্রয়োগ করে। অনুমোদিত ইউজার আর অ্যাপ্লিকেশন এখনও আসল মান পায়; redacted ইউজাররা masked সংস্করণ পায়। ডিস্কের ডেটার কিছুই বদলায় না।

আপনি DBMS_REDACT প্যাকেজ দিয়ে policy তৈরি করেন:

-- Show only the last 4 digits of the card number to non-privileged users
BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema => 'SALES',
    object_name   => 'CUSTOMERS',
    column_name   => 'CARD_NUMBER',
    policy_name   => 'redact_card',
    function_type => DBMS_REDACT.PARTIAL,
    function_parameters => 'VVVVVVVVVVVVVVVV,VVVV-VVVV-VVVV-VVVV,*,1,12',
    expression    => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') != ''APP_OWNER'''
  );
END;
/

expression-ই মূল চাবি — এটা ঠিক করে কে redacted হবে। এখানে অ্যাপ্লিকেশন ওনার ছাড়া সবাই masked কার্ড দেখে। আপনি এটা একজন ইউজার, একটি role, একটি application context, বা একটি client identifier-এর সঙ্গে বাঁধেন, যাতে একই কলাম অ্যাপকে আসল ডেটা আর সাপোর্ট লগইনকে masked ডেটা দেখায়।

৩. যেসব redaction ধরন বেছে নিতে পারেন

Oracle কয়েক ধরনের রূপান্তর দেয়, আর ব্যবহারযোগ্যতার জন্য সঠিকটা বাছাই জরুরি।

Full redaction একটি নির্দিষ্ট ডিফল্ট ফেরত দেয় — সংখ্যার জন্য শূন্য, টেক্সটের জন্য স্পেস। সরল আর সম্পূর্ণ।

Partial redaction মানের কিছু অংশ দৃশ্যমান রাখে, যেমন কার্ডের শেষ চার অঙ্ক বা ইমেইলের ডোমেইন। এটাই সবচেয়ে বেশি ব্যবহৃত হয় কারণ এটা কাজের থাকে — সাপোর্ট এখনও নিশ্চিত করতে পারে "৪৮২১-এ শেষ হওয়া কার্ড।"

Random redaction প্রতিবার আলাদা random মান ফেরত দেয়, যেখানে ফরম্যাটও কোনো প্যাটার্ন ফাঁস করা উচিত নয় সেখানে কাজের।

Regular-expression redaction একটি প্যাটার্ন প্রয়োগ করে, ইমেইল বা ID-র মতো কাঠামোবদ্ধ স্ট্রিংয়ের জন্য সুবিধাজনক যেখানে আপনি মাঝখানটা mask করে আকৃতি রাখতে চান।

শিল্পটা হলো ব্যক্তিকে রক্ষা করার মতো যথেষ্ট redact করা, অথচ বৈধ কাজের জন্য যথেষ্ট রেখে দেওয়া। সাপোর্টের যে ফিল্ড দরকার সেটায় full redaction শুধু বিরক্তিটা এদিক-ওদিক সরায়।

৪. Static Data Masking কীভাবে কাজ করে

Masking আলাদা প্রশ্নের উত্তর দেয়: "আসল কাস্টমার রেকর্ড হাতে না দিয়ে ডেভেলপারদের টেস্ট করার জন্য বাস্তবসম্মত ডেটা কীভাবে দেব?"

Static masking ডেটার একটি কপিতে সংবেদনশীল কলামগুলো স্থায়ীভাবে নতুন করে লেখে। নাম হয়ে যায় নকল-কিন্তু-বাস্তবসম্মত নাম, কার্ড নম্বর হয় বৈধ-ফরম্যাটের নকল, বেতন এলোমেলো হয়ে যায়। ফলটা প্রোডাকশনের মতোই দেখায় ও আচরণ করে — একই আকৃতি, একই বণ্টন — কিন্তু কোনো আসল ব্যক্তিগত ডেটা থাকে না।

গুরুত্বপূর্ণ ব্যাপার হলো, masking কপি বানানোর অংশ হিসেবেই ঘটে, তাই আসল মান কখনও টেস্ট বা অ্যানালিটিক্স পরিবেশে পৌঁছায় না। ওই নিচু পরিবেশ পরে breach হলেও চুরি করার মতো সংবেদনশীল কিছু থাকে না।

ভালো masking টেস্টিংয়ের যা দরকার তা বজায় রাখে: referential integrity (একই কাস্টমার সব টেবিলে সামঞ্জস্যপূর্ণভাবে মেলে), ফরম্যাট (masked ফোন নম্বরও বৈধ ফোন নম্বর), আর বণ্টন (যাতে পারফরম্যান্স টেস্ট বাস্তবসম্মতভাবে আচরণ করে)। এটা অন্ধ find-and-replace-এর চেয়ে অনেক বেশি।

৫. একটি বাস্তব উদাহরণ: সাপোর্ট ডেস্ক

একটা বাস্তব দৃশ্যে এগুলো কীভাবে মেলে, যা আমি একাধিকবার বানিয়েছি।

একটি ব্যাংকের সাপোর্ট টিমকে কাস্টমার সাহায্য করতে তাদের খুঁজে বের করতে হয়। তাদের পরিচয় নিশ্চিত করতে ও অ্যাকাউন্ট স্ট্যাটাস দেখতে হয়, কিন্তু পুরো কার্ড নম্বর, জাতীয় পরিচয়পত্র নম্বর, বা একটি সীমার বাইরের ব্যালেন্স দেখার কোনো দরকার তাদের নেই।

সমাধানটা স্তরে স্তরে সাজানো। TDE tablespace এনক্রিপ্ট করে, তাই চুরি যাওয়া datafile অকেজো। সংবেদনশীল কলামে Redaction policy সাপোর্ট স্টাফকে কার্ডের শুধু শেষ চার অঙ্ক আর X দিয়ে ঢাকা ID দেখায়, অথচ কোর ব্যাংকিং অ্যাপ্লিকেশন এখনও আসল মান দেখে। Access control নিশ্চিত করে সাপোর্ট যে টেবিল দরকার নেই তা query করতে পারবে না। আর একটি masked কপি টেস্ট পরিবেশে যায়, তাই ডেভেলপাররা কখনও আসল কাস্টমার স্পর্শ করে না।

প্রতিটি স্তর আলাদা দরজা বন্ধ করে। শুধু Redaction চুরি যাওয়া ফাইল ঠেকাত না; শুধু TDE কৌতূহলী সাপোর্ট এজেন্ট ঠেকাত না; শুধু masking প্রোডাকশন রক্ষা করত না। একসঙ্গে, তারা করে।

৬. Redaction যা করে না

এখানেই টিমগুলো ভুয়া নিরাপত্তাবোধে পড়ে, তাই একটা পরিষ্কার বক্তব্য দরকার।

Redaction একটি presentation-layer কন্ট্রোল। যথেষ্ট প্রিভিলেজধারী একজন ইউজার — একজন DBA, direct dictionary access আছে এমন কেউ, বা কিছু export path — এখনও নিচের আসল মানে পৌঁছাতে পারে। এটা সাধারণ ও application-level এক্সপোজার কমায়; উচ্চ-প্রিভিলেজধারী নাছোড় ইনসাইডারের বিরুদ্ধে এটা দেয়াল নয়।

এটা backup বা export-এ থাকা ডেটাও রক্ষা করে না — সেগুলোতে আসল, un-redacted মান থাকে (ঠিক এ কারণেই আপনার TDE আর সাবধানী export হ্যান্ডলিংও দরকার)।

তাই redaction সাধারণ ক্ষেত্রের জন্য সত্যিই কাজের একটি স্তর — সাপোর্ট এজেন্ট, read-only রিপোর্টিং ইউজার, যে থার্ড-পার্টি অ্যাপের সব দেখা উচিত নয় — কিন্তু এটার জায়গা defence-in-depth ডিজাইনের ভেতরে, কখনও একমাত্র তালা হিসেবে নয়। বৃহত্তর শৃঙ্খলাটা আমার ডেটাবেজ সিকিউরিটি গাইডে আছে।

৭. Redaction, masking, TDE ও access control একসঙ্গে

শক্তিশালী সিস্টেমগুলো এগুলোর একটা বেছে নেয় না — তারা স্তরে স্তরে সাজায়, প্রতিটি অন্যদের ফাঁক ঢাকে।

TDE সামলায় ফাইল-চুরির হুমকি। Access control ও least privilege ঠিক করে কে কী query করতে পারবে আদৌ। Redaction সীমিত করে অনুমোদিত-কিন্তু-অ-প্রিভিলেজধারী ইউজাররা স্ক্রিনে কোন সংবেদনশীল মান দেখবে। Masking আসল ডেটা non-production-এর বাইরে রাখে। Auditing লিপিবদ্ধ করে কে কী দেখল।

যেকোনো একটা সরান, একটা ফাঁক খুলে যায়: এনক্রিপ্ট করলেন কিন্তু redact করলেন না, সাপোর্ট পুরো কার্ড নম্বর দেখে; redact করলেন কিন্তু mask করলেন না, একটি টেস্ট-সিস্টেম breach প্রোডাকশন ডেটা ফাঁস করে; দুটোই করলেন কিন্তু auditing বাদ দিলেন, আপনি অ্যাক্সেস প্রমাণ বা তদন্ত করতে পারবেন না। স্তরগুলো একেকটা সস্তা আর একসঙ্গে শক্তিশালী।

৮. কমপ্লায়েন্সের দিক

নিয়ন্ত্রিত ক্লায়েন্টদের জন্য — ব্যাংকিং, স্বাস্থ্যসেবা, আর যে ফার্মাসিউটিক্যাল কোম্পানিগুলোর সঙ্গে কাজ করেছি — "এই ডেটা কে দেখতে পারে?" একটি ধারালো অডিট প্রশ্ন।

GDPR-এর data-minimisation নীতি আশা করে মানুষ শুধু তাদের কাজের জন্য প্রয়োজনীয় ব্যক্তিগত ডেটাই দেখবে — ঠিক যা redaction প্রয়োগ করে। PCI-DSS দাবি করে কার্ড নম্বর প্রদর্শনের সময় masked থাকবে, সর্বোচ্চ প্রথম ছয় আর শেষ চার অঙ্ক দেখাবে — টেক্সটবুক partial-redaction ব্যবহার। আর ডেভেলপারদের আসলের বদলে masked ডেটা দেওয়া হলো অডিটরদের দুশ্চিন্তার পরিসর ছোট করার একটি মানসম্মত উপায়।

"সংবেদনশীল কলাম অ-প্রিভিলেজধারী ইউজারদের জন্য redacted, প্রোডাকশন ডেটা নিচু পরিবেশে পৌঁছানোর আগেই masked, আর অ্যাক্সেস audited" — এটা বলতে পারা একটি শক্ত, সমর্থনযোগ্য উত্তর — আর এটাই সেই ধরনের কন্ট্রোল যা আমি নিয়ন্ত্রিত টিমদের এক্সপোজার অডিট ও হার্ডেনিংয়ের পাশাপাশি গড়ে তুলতে সাহায্য করি।

৯. Redaction ও masking-এ সাধারণ ভুল

• Redaction-কে encryption ভাবা — ধরে নেওয়া যে অ্যাপ স্ক্রিন redacted বলে চুরি যাওয়া backup নিরাপদ। নয়; backup-এ আসল মান আছে।
• অতিরিক্ত redact করা — এত বেশি লুকানো যে বৈধ কাজটাই অসম্ভব হয়ে যায়, ফলে মানুষ কম-নিরাপদ workaround খুঁজে নেয়।
• Masking যা referential integrity ভাঙে — একই "কাস্টমার" বিভিন্ন টেবিলে ভিন্ন নকল নামে masked, ফলে join আর টেস্ট ভেঙে পড়ে।
• Export ভুলে যাওয়া — স্ক্রিনে redact করছেন অথচ একটি রাতের export আসল ডেটা কোথাও অরক্ষিত জায়গায় পাঠাচ্ছে।
• Policy টেস্ট না করা — ধরে নেওয়া যে redaction expression সঠিক ইউজারদের লক্ষ্য করে; সবসময় আসল সাপোর্ট আর অ্যাপ লগইন দিয়ে টেস্ট করুন।

Redaction বাস্তবে সঠিকভাবে করা

কয়েকটা অভ্যাস redaction-কে যা কাজ করে তার থেকে আলাদা করে যা নীরবে ফাঁস করে বা মানুষকে বিরক্ত করে।

ব্যক্তি-username নয়, role আর context লক্ষ্য করুন। policy-কে একটা নামের তালিকার বদলে একটি role, একটি application context, বা একটি client identifier-এর সঙ্গে বাঁধুন — মানুষ চাকরি বদলায়, আর সাপোর্ট টিমে নতুন কেউ যোগ দেওয়ার দিনই username তালিকা বাসি হয়ে যায়।

অ্যাপ্লিকেশনের নিজের অ্যাকাউন্ট সবসময় ছাড় দিন। কোর অ্যাপ্লিকেশনের সাধারণত কাজ করতে আসল মান দরকার। অ্যাপ ওনার আর নির্দিষ্ট প্রিভিলেজড role — যাদের সত্যিই ডেটা দরকার — ছাড়া সবাইকে redact করুন।

আসল লগইন দিয়ে টেস্ট করুন। একজন আসল সাপোর্ট ইউজার আর একজন আসল অ্যাপ্লিকেশন ইউজার হিসেবে লগইন করে নিশ্চিত করুন প্রত্যেকে ঠিক যা দেখার কথা তা-ই দেখছে। সংজ্ঞায় ঠিক দেখানো policy-ও ভুল session লক্ষ্য করতে পারে।

পাশের দরজাগুলো বন্ধ করুন। যাচাই করুন রাতের export, রিপোর্টিং extract, আর BI connection নীরবে un-redacted মান কোথাও কম-সুরক্ষিত জায়গায় পাঠাচ্ছে কিনা। মূল স্ক্রিনে redaction-এর অর্থ সামান্যই যদি একটি রিপোর্ট প্রতি সকালে আসল ডেটা ইমেইল করে।

এভাবে করলে redaction হয়ে ওঠে একটি নীরব, নির্ভরযোগ্য কন্ট্রোল যা বেশিরভাগ ইউজার লক্ষই করে না — আর সেটাই তো আসল উদ্দেশ্য।

Frequently Asked Questions

Oracle-এ data redaction আর data masking-এর পার্থক্য কী?

Redaction সংবেদনশীল মান চলতি অবস্থায়, query-time-এ, লাইভ ডেটাবেজে লুকায় — সংরক্ষিত ডেটা অপরিবর্তিত, কিন্তু নির্দিষ্ট ইউজার একটি masked সংস্করণ দেখে। Masking সংবেদনশীল মানকে স্থায়ীভাবে বাস্তবসম্মত নকল দিয়ে বদলায়, সাধারণত টেস্টের জন্য কপি বানানোর সময়, যাতে আসল ডেটা কখনও প্রোডাকশন ছাড়ে না।

Data redaction কি একটি নিরাপত্তা সীমানা?

না। এটা presentation layer-এ সাধারণ এক্সপোজার কমায়, কিন্তু নাছোড় প্রিভিলেজধারী ইউজার এখনও নিচের ডেটায় পৌঁছাতে পারে, আর এটা export বা backup রক্ষা করে না। এটাকে access control, TDE ও auditing-এর পাশে একটি স্তর হিসেবে ব্যবহার করুন, একমাত্র সুরক্ষা হিসেবে নয়।

কখন redaction-এর বদলে masking ব্যবহার করব?

প্রোডাকশন ডেটা test, development বা analytics-এ কপি করার সময় static masking ব্যবহার করুন, যাতে সংবেদনশীল মান প্রোডাকশন ছাড়ার আগেই স্থায়ীভাবে বদলে যায়। যখন আসল ডেটা লাইভেই থাকতে হবে কিন্তু নির্দিষ্ট ইউজার শুধু একটি masked সংস্করণ দেখবে, তখন dynamic redaction ব্যবহার করুন।

Redaction কি সংরক্ষিত ডেটা বদলায়?

না। Dynamic Data Redaction ডিস্কের ডেটায় হাত দেয় না — এটা policy-র আওতাধীন ইউজারদের জন্য query ফলাফলে মান রূপান্তর করে। অনুমোদিত ইউজারদের জন্য আসল মান অটুট থাকে, এ কারণেই এটা স্বচ্ছ আর লাইভ সিস্টেমে সহজে যোগ করা যায়।

এটা TDE encryption-এর সঙ্গে কীভাবে সম্পর্কিত?

এগুলো আলাদা সমস্যার সমাধান করে আর একসঙ্গে ভালো কাজ করে। TDE ডেটা at rest এনক্রিপ্ট করে যাতে চুরি যাওয়া ফাইল অপাঠ্য হয়; redaction ও masking সীমিত করে কে সংবেদনশীল মান দেখবে। একটি শক্ত সেটআপ TDE দিয়ে এনক্রিপ্ট করে, সংবেদনশীল কলাম redact করে, non-production কপি mask করে, আর অ্যাক্সেস audit করে।