Oracle Transparent Data Encryption (TDE): ডেটা অ্যাট রেস্ট এনক্রিপ্ট করা

একটি চুরি হওয়া ল্যাপটপ, হারানো ব্যাকআপ টেপ, ডিকমিশন করা সার্ভার থেকে কপি করা একটি datafile — এগুলোর কোনোটিই আপনার ডেটাবেজ পড়তে পাসওয়ার্ড চায় না, যদি ফাইলগুলো প্লেইন টেক্সটে পড়ে থাকে। ঠিক এই ফাঁকটাই Oracle Transparent Data Encryption বন্ধ করে। TDE আপনার ডেটা অ্যাট রেস্ট এনক্রিপ্ট করে, যাতে যে-ই ফিজিক্যাল ফাইল হাতে পায় সে কেবল অপাঠ্য বাইট পায় — অথচ আপনার অ্যাপ্লিকেশন এক লাইন পরিবর্তন ছাড়াই চলতে থাকে। এই গাইড ব্যাখ্যা করে TDE আসলে কী রক্ষা করে, এর key কীভাবে কাজ করে, tablespace বনাম column এনক্রিপশনের পার্থক্য, সৎ পারফরম্যান্স খরচ, এবং RMAN ও Data Guard-এর সাথে এটি কীভাবে আচরণ করে — সেটআপ কমান্ডসহ।

১. Transparent Data Encryption কী?

Oracle TDE ডিস্কে সংরক্ষিত ডেটা — datafile, ব্যাকআপ ও export — স্বয়ংক্রিয়ভাবে এনক্রিপ্ট করে, যাতে যে ফিজিক্যাল ফাইল কপি করে সে অপাঠ্য ciphertext পায়, অথচ অনুমোদিত সেশন ডেটা পুরোপুরি স্বাভাবিকভাবে পড়ে। "Transparent" শব্দটাই মূল কথা — অ্যাপ্লিকেশন জানেও না যে এনক্রিপশন হচ্ছে।

কোনো কোড পরিবর্তন নেই, নতুন SQL নেই, ভিন্ন connection string নেই। একটি এনক্রিপ্টেড টেবিল কোয়েরি করা ডেভেলপার আগে যা দেখত ঠিক তা-ই দেখে। এনক্রিপশন-ডিক্রিপশন হয় স্টোরেজ স্তরে, ডিস্কে যাওয়া-আসার পথে।

এই ডিজাইনই TDE-কে ব্যবহারিক করে। অ্যাপ্লিকেশন-স্তরে এনক্রিপশন — নিজের কোডে ভ্যালু এনক্রিপ্ট করা — ডেটা রক্ষা করলেও তা অনুপ্রবেশকারী, indexing ও sorting ভাঙে, এবং প্রতিটি অ্যাপকে তা বাস্তবায়ন করতে হয়। TDE একটি অ্যাপও না ছুঁয়ে পুরো schema-র জন্য এনক্রিপশন অ্যাট রেস্ট দেয়।

২. TDE আসলে কী রক্ষা করে — আর কী করে না

এটিই সবচেয়ে গুরুত্বপূর্ণ অংশ, কারণ TDE-কে প্রায়ই "ডেটাবেজ রক্ষাকারী এনক্রিপশন" ভাবা হয়। এটি একটি নির্দিষ্ট জিনিস রক্ষা করে: স্টোরেজে অ্যাট রেস্ট থাকা ডেটা।

TDE আপনাকে রক্ষা করে:

• চুরি বা হারানো ব্যাকআপ টেপ বা ফাইল থেকে।
• সার্ভার, SAN বা snapshot থেকে datafile কপি করা থেকে।
• মুছে না-ফেলা ডিকমিশন করা ডিস্ক থেকে।
• ফাঁস হওয়া Data Pump export থেকে (export এনক্রিপশন ব্যবহারে)।

TDE আপনাকে রক্ষা করে না:

• বৈধ ডেটাবেজ ক্রেডেনশিয়াল থাকা আক্রমণকারীর থেকে — লগইন করা সেশনে ডেটা স্বচ্ছভাবে ডিক্রিপ্টেড।
• কম্প্রোমাইজড অ্যাপ্লিকেশন অ্যাকাউন্ট যা স্বাভাবিক কোয়েরি চালায়।
• অনুমোদিত ইউজার হিসেবে চলা SQL injection।

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

৩. TDE key কীভাবে কাজ করে: টু-টিয়ার মডেল

TDE একটি পরিষ্কার দুই-স্তরের key শ্রেণিবিন্যাস ব্যবহার করে, এবং এটি বুঝলে বাকি সব বোঝা সহজ।

নিচে থাকে data encryption key — প্রতি এনক্রিপ্টেড tablespace (বা column) প্রতি একটি। এগুলো AES দিয়ে আসলে আপনার ডেটা এনক্রিপ্ট করে। এরা ডেটাবেজের ভেতরে থাকে, কিন্তু নিজেরাই এনক্রিপ্টেড।

এদের এনক্রিপ্ট করে TDE master encryption key। একটিই master key, এবং এটি কখনো datafile-এ থাকে না। এটি থাকে keystore (আগে wallet) নামে একটি আলাদা, সুরক্ষিত জায়গায়।

আপনার ডেটা
   └─ এনক্রিপ্ট করে → Tablespace/Column key   (ডেটাবেজে, নিজেই এনক্রিপ্টেড)
                         └─ এনক্রিপ্ট করে → TDE Master Key   (KEYSTORE-এ, ডেটাবেজের বাইরে)

সৌন্দর্যটা এই: এনক্রিপ্টেড ডেটা পড়তে Oracle-এর tablespace key খুলতে master key দরকার। master key keystore-এ। তাই চোর যদি datafile চুরি করে কিন্তু keystore না নেয়, তার কাছে এনক্রিপ্টেড ডেটা ও এনক্রিপ্টেড key থাকে — কিন্তু খোলার কিছু নেই। তার কাছে অকেজো।

এর মানে master key রোটেট করা সস্তা। আপনি শুধু ছোট tablespace key পুনরায় এনক্রিপ্ট করেন, টেরাবাইট ডেটা নয়। কমপ্লায়েন্স-চালিত key রোটেশনের জন্য এটি সত্যিই চমৎকার।

৪. keystore (wallet): যেটা কখনো হারানো যাবে না

সবকিছু keystore-এর উপর নির্ভর করে। keystore হারালে বা করাপ্ট হলে এবং ব্যাকআপ না থাকলে, master key শেষ, tablespace key খোলা যায় না, এবং আপনার এনক্রিপ্টেড ডেটা অপুনরুদ্ধারযোগ্য — চিরতরে। কোনো সাপোর্ট টিকিট এটি ফেরায় না। এটাই পুরো সিকিউরিটি মডেল ঠিকঠাক কাজ করা।

তাই keystore আপনার সবচেয়ে গুরুত্বপূর্ণ ক্রেডেনশিয়ালের মতো যত্ন দাবি করে:

• ব্যাকআপ নিন — নিরাপদে, এবং ডেটাবেজ ব্যাকআপ থেকে আলাদাভাবে (এনক্রিপ্টেড ব্যাকআপের পাশে রাখা keystore পুরো উদ্দেশ্য নষ্ট করে)।
• শক্তিশালী পাসওয়ার্ড দিন, একই সার্ভারের টেক্সট ফাইলে নয়, secrets manager-এ রাখুন।
• keystore ডিরেক্টরিতে OS অ্যাক্সেস শুধু Oracle owner-এ সীমাবদ্ধ করুন।
• রিকভারি টেস্ট করুন — সংকটের আগেই restored keystore দিয়ে restored ডেটাবেজ খোলা অনুশীলন করুন।

এনক্রিপশন নিজে থেকে যত সমস্যা দেখেছি, তার চেয়ে বেশি প্রায়-বিপর্যয় দেখেছি ভুলভাবে সামলানো keystore থেকে। এনক্রিপশন মজবুত; key-এর চারপাশের অপারেশনাল শৃঙ্খলাতেই টিমরা আঘাত পায়।

৫. TDE সেটআপ: মূল ধাপ

সঠিক সিনট্যাক্স ভার্সনভেদে সামান্য বদলেছে (multitenant container context যোগ করে), কিন্তু আকৃতি সবসময় একই: keystore অবস্থানে ডেটাবেজ পয়েন্ট করুন, keystore তৈরি করুন, খুলুন, master key সেট করুন, তারপর এনক্রিপ্ট করুন।

-- 1) DB-কে জানান software keystore কোথায় (sqlnet.ora বা প্যারামিটারে)
--    যেমন WALLET_ROOT + TDE_CONFIGURATION=KEYSTORE_CONFIGURATION=FILE

-- 2) keystore তৈরি
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/oracle/wallet'
  IDENTIFIED BY "StrongKeystorePassw0rd!";

-- 3) খুলুন
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
  IDENTIFIED BY "StrongKeystorePassw0rd!";

-- 4) TDE master encryption key সেট করুন
ADMINISTER KEY MANAGEMENT SET KEY
  IDENTIFIED BY "StrongKeystorePassw0rd!" WITH BACKUP;

keystore খোলা ও master key সেট থাকলে এনক্রিপ্ট করুন। পরিষ্কার, আধুনিক পদ্ধতি হলো tablespace স্তরে এনক্রিপ্ট করা:

-- একটি নতুন tablespace এনক্রিপ্ট
CREATE TABLESPACE app_secure
  DATAFILE '/u02/oradata/app_secure01.dbf' SIZE 1G
  ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT);

-- অথবা একটি বিদ্যমান টেবিলের ডেটা এনক্রিপ্টেড tablespace-এ সরান
ALTER TABLE sales.customers MOVE TABLESPACE app_secure;

সেই মুহূর্ত থেকে সেই tablespace-এ লেখা প্রতিটি block এনক্রিপ্টেড, এবং পড়া প্রতিটি block ডিক্রিপ্টেড — অদৃশ্যভাবে। আপনার অ্যাপ্লিকেশন জানেও না।

৬. Tablespace বনাম Column এনক্রিপশন

TDE দুটি granularity দেয়, এবং পছন্দটা গুরুত্বপূর্ণ।

Tablespace এনক্রিপশন tablespace-এ সংরক্ষিত সবকিছু এনক্রিপ্ট করে। এটি সুপারিশকৃত ডিফল্ট: সহজ, indexing বা query optimization-এ বাধা দেয় না, এবং সব column, index এমনকি সেই ডেটার undo ও redo ঢাকে। সংবেদনশীল টেবিল এনক্রিপ্টেড tablespace-এ রাখুন, ব্যস।

Column এনক্রিপশন শুধু নির্দিষ্ট column এনক্রিপ্ট করে। শুনতে পরিপাটি — "শুধু কার্ড নম্বর এনক্রিপ্ট করো" — কিন্তু বাস্তব সীমাবদ্ধতা আসে। এনক্রিপ্টেড column কিছু index টাইপ বা foreign key-তে একইভাবে ব্যবহার করা যায় না, range scan সীমিত, এবং প্রতি-column overhead যোগ করে। একটি খুব সংকীর্ণ, অতি-সংবেদনশীল ফিল্ডের জন্য এর জায়গা আছে, তবে বেশিরভাগ ক্ষেত্রে tablespace এনক্রিপশন পরিষ্কার।

৭. TDE কি ডেটাবেজ ধীর করে?

সৎ উত্তর: সাধারণত সামান্য, তবে ব্লগের সংখ্যায় ভরসা না করে নিজের ওয়ার্কলোডে টেস্ট করুন।

তিনটি জিনিস খরচ কম রাখে। প্রথমত, আধুনিক CPU-তে হার্ডওয়্যার-অ্যাক্সেলারেটেড AES, তাই এনক্রিপশন নিজেই দ্রুত। দ্বিতীয়ত, TDE ডিস্ক থেকে buffer cache-এ পড়ার সময় block ডিক্রিপ্ট করে — কিন্তু cache-এ ঢোকার পর block ডিক্রিপ্টেড থাকে, তাই hot ডেটার বারবার পড়া পুনরায় ডিক্রিপ্ট করে না। তৃতীয়ত, এনক্রিপশন block স্তরে, প্রতি row নয়, তাই দক্ষ।

যেখানে অনুভব করবেন তা হলো cold ডেটা বারবার ডিস্ক থেকে পড়া ওয়ার্কলোড — cache-এ না-থাকা ডেটার বড় full scan, বা ইতিমধ্যে সীমায় থাকা I/O-বাউন্ড সিস্টেম। তখনও OLTP-তে সাধারণত single-digit CPU শতাংশ।

আমার নিয়ম: একটি কপিতে চালু করুন, আসল পিক ওয়ার্কলোড চালান, AWR দিয়ে তুলনা করুন। মাপুন, ধরে নেবেন না — একই শৃঙ্খলা যা আমি পারফরম্যান্স টিউনিংয়ে আনি।

৮. TDE ও RMAN ব্যাকআপ

একটি সূক্ষ্মতা জানার মতো। RMAN দিয়ে এনক্রিপ্টেড tablespace ব্যাকআপ নিলে ডেটা ব্যাকআপে এনক্রিপ্টেড থাকে — ঠিক যা আপনি চান, যেহেতু চুরি হওয়া ব্যাকআপ TDE-র মূল হুমকিগুলোর একটি।

কিন্তু এর মানে ব্যাকআপ শুধু keystore দিয়ে restore করা যায়। তাই আপনার RMAN ব্যাকআপ কৌশলে এখন একটি কঠিন নির্ভরতা: keystore ব্যাকআপের পাশাপাশি পুনরুদ্ধারযোগ্য হতে হবে, আলাদা ও নিরাপদে রাখা। যে RMAN ব্যাকআপ keystore হারানোয় ডিক্রিপ্ট করা যায় না, সেটা ব্যাকআপই নয়।

ডিফেন্স-ইন-ডেপথের জন্য RMAN ব্যাকআপ নিজেও এনক্রিপ্ট করতে পারেন (TDE থেকে স্বাধীন)। যেভাবেই হোক, শিক্ষা একই: আপনার key-রিকভারি প্ল্যান এখন আপনার ডিজাস্টার-রিকভারি প্ল্যানের অংশ। একসাথে টেস্ট করুন।

৯. Data Guard ও RAC-এর সাথে TDE

TDE Data Guard ও RAC-এর সাথে কাজ করে, কিন্তু ডেটাবেজ যেখানে খোলে সেখানে keystore উপলব্ধ থাকতে হবে।

Data Guard-এ standby-র একই master key দরকার, তাই keystore (বা এর key) standby সাইটে কপি করতে হবে। standby-তে পাঠানো redo এনক্রিপ্টেড change vector বহন করে, এবং standby তা প্রয়োগ করে — যা কেবল key থাকলেই সম্ভব।

RAC-এ প্রতিটি instance-কে keystore-এ পৌঁছাতে হয়, তাই সাধারণত এটি shared storage (ACFS)-এ থাকে বা প্রতিটি node-এ রেপ্লিকেট হয়। restart-এর পর মানুষ পাসওয়ার্ড না টাইপ করেই instance স্বয়ংক্রিয়ভাবে খুলতে পারে বলে auto-login keystore এখানে সাধারণ।

থিমটা বারবার আসে: এনক্রিপশন সহজ; key-কে প্রতিটি বৈধ instance-এ — এবং শুধু সেগুলোতে — নির্ভরযোগ্যভাবে উপলব্ধ রাখাই আসল ইঞ্জিনিয়ারিং।

১০. Auto-Login বনাম পাসওয়ার্ড-সুরক্ষিত keystore

পাসওয়ার্ড-সুরক্ষিত keystore প্রতিবার ডেটাবেজ চালু হলে পাসওয়ার্ড দিয়ে খুলতে হয় — নিরাপদ, কিন্তু এর মানে ডেটাবেজ এনক্রিপ্টেড ডেটায় পৌঁছানোর আগে কাউকে (বা পাসওয়ার্ড-ধারী স্ক্রিপ্টকে) এটি খুলতে হবে।

একটি auto-login keystore একটি বিশেষ লোকাল ফাইল ব্যবহার করে startup-এ পাসওয়ার্ড প্রম্পট ছাড়াই স্বয়ংক্রিয়ভাবে keystore খুলতে দেয়। সুবিধাজনক — unattended restart ও RAC-এর জন্য অপরিহার্য — কিন্তু auto-login ফাইল ফাইলের সাথে গেলে "ফাইল চুরি করো, কিছু পাবে না" গল্পটা সামান্য দুর্বল করে।

সাধারণ, বিচক্ষণ প্যাটার্ন: মসৃণ অপারেশনের জন্য auto-login keystore ব্যবহার করুন, কিন্তু auto-login ফাইল Oracle OS ইউজারে সীমাবদ্ধ রাখুন ও ব্যাকআপ সেট থেকে বাইরে, যাতে চুরি হওয়া ব্যাকআপ নিজে খুলতে না পারে। পছন্দ আপনার threat model-এর সাথে মেলান।

১১. যে TDE ভুলগুলো আমি দেখি

• keystore ব্যাকআপ নেই — বা এনক্রিপ্টেড ডেটাবেজের ঠিক পাশে ব্যাকআপ। দুটোই অপেক্ষমাণ বিপর্যয়।
• একই হোস্টের প্লেইন ফাইলে দুর্বল keystore পাসওয়ার্ড। key তার পাসওয়ার্ড যতটা নিরাপদ ততটাই।
• standby ভুলে যাওয়া — primary-তে TDE চালু, তারপর Data Guard switchover ব্যর্থ কারণ standby-তে key নেই।
• TDE = "আমরা নিরাপদ" ধরে নেওয়া — দুর্বল DB অ্যাকাউন্ট ও অডিটিং না রেখে সুরক্ষিত বোধ করা। এটি একটি স্তর মাত্র।
• tablespace যথেষ্ট হলে column এনক্রিপ্ট করা — কোনো বাস্তব লাভ ছাড়াই index ও query সীমাবদ্ধতা নেওয়া।
• কখনো রিকভারি টেস্ট না করা — keystore দিয়ে প্রথম restore যেন কোনো আসল আউটেজের সময় না হয়।

১২. TDE কোথায় খাপ খায়: এনক্রিপশন, masking ও অ্যাক্সেস কন্ট্রোল

TDE একটি ছোট টুলবক্সের একটি টুল, এবং কোনটা কী করে জানলে বৃথা পরিশ্রম এড়ানো যায়।

TDE (এনক্রিপশন অ্যাট রেস্ট) চুরি হওয়া ফাইল অপাঠ্য করে। অনুমোদিত ইউজাররা এখনো আসল ডেটা দেখে।

ডেটা masking / redaction নির্দিষ্ট ইউজারের জন্য সংবেদনশীল ভ্যালু নকল বা লুকানো দিয়ে বদলায় — ডেভেলপারকে বাস্তব-কিন্তু-নিরাপদ কপি দিতে, বা সাপোর্ট স্টাফের থেকে পুরো কার্ড নম্বর লুকাতে আদর্শ।

অ্যাক্সেস কন্ট্রোল ও অডিটিং ঠিক করে কে ডেটা দেখতে পারবে এবং কে কী করল তা রেকর্ড করে।

এরা পরিপূরক। একটি সুপরিচালিত সিস্টেম প্রায়ই TDE দিয়ে অ্যাট রেস্ট এনক্রিপ্ট করে, non-production কপিতে সংবেদনশীল ডেটা mask করে, least privilege প্রয়োগ করে, ও অ্যাক্সেস অডিট করে — প্রতিটি ভিন্ন দরজা বন্ধ করে।

১৩. কমপ্লায়েন্স দিক: অডিটররা কেন চায়

নিয়ন্ত্রিত ব্যবসার জন্য — ব্যাংকিং, স্বাস্থ্যসেবা, এবং যে ফার্মা ক্লায়েন্টদের সাথে কাজ করেছি — এনক্রিপশন অ্যাট রেস্ট প্রায়ই একটি কঠিন প্রয়োজন, ঐচ্ছিক নয়। GDPR একে স্বীকৃত সুরক্ষা মানে, PCI-DSS স্টোরেজে কার্ডধারীর ডেটা অপাঠ্য আশা করে, এবং স্বাস্থ্য ও ফার্মা রেগুলেটররা সুরক্ষিত ডেটা এনক্রিপ্টেড আশা করে।

TDE হলো Oracle-এ এই বক্স টিক দেওয়ার আদর্শ, যুক্তিযুক্ত উপায় — কারণ এটি স্বচ্ছ, অ্যাপ্লিকেশন পুনঃ-ইঞ্জিনিয়ার না করেই আপনি কমপ্লায়েন্স কন্ট্রোল পান। অডিটর যখন জিজ্ঞেস করে "ডেটা কি অ্যাট রেস্ট এনক্রিপ্টেড, এবং key কীভাবে ম্যানেজ হয়?", TDE প্লাস একটি ডকুমেন্টেড keystore-ম্যানেজমেন্ট প্রক্রিয়া একটি পরিষ্কার উত্তর।

সেই সমন্বয় — এনক্রিপশন এবং key-ম্যানেজমেন্ট শৃঙ্খলা — ঠিক তা-ই যা আমি নিয়ন্ত্রিত ক্লায়েন্টদের স্থাপন করতে সাহায্য করি, লগইন দিকের দরজাও বন্ধ রাখা বৃহত্তর এক্সপোজার ও হার্ডেনিং কাজের পাশাপাশি।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Oracle Transparent Data Encryption (TDE) কী?

TDE ডেটা অ্যাট রেস্ট — ডিস্কের datafile, ব্যাকআপ ও export — স্বয়ংক্রিয়ভাবে এনক্রিপ্ট করে, অ্যাপ্লিকেশন পরিবর্তন ছাড়াই। অনুমোদিত সেশন স্বাভাবিকভাবে পড়ে, আর যে ফিজিক্যাল ফাইল চুরি করে সে key না থাকায় শুধু অপাঠ্য ciphertext পায়।

TDE কী থেকে রক্ষা করে, আর কী থেকে না?

এটি ফিজিক্যাল ফাইল চুরি থেকে রক্ষা করে: চুরি ডিস্ক, হারানো ব্যাকআপ, কপি করা datafile, বা ফাঁস export। বৈধ ক্রেডেনশিয়াল থাকা আক্রমণকারীর থেকে রক্ষা করে না, কারণ তার কাছে ডেটা স্বচ্ছভাবে ডিক্রিপ্টেড। TDE অথেন্টিকেশন, অ্যাক্সেস কন্ট্রোল ও অডিটিংয়ের পাশাপাশি একটি স্তর।

TDE কি ডেটাবেজ ধীর করে?

সাধারণত সামান্য, কারণ Oracle হার্ডওয়্যার-অ্যাক্সেলারেটেড AES ব্যবহার করে, block স্তরে এনক্রিপ্ট করে, এবং ডিক্রিপ্টেড block buffer cache-এ রাখে যাতে বারবার পড়া পুনরায় ডিক্রিপ্ট না হয়। সামান্য CPU বৃদ্ধি আশা করুন ও নিজের ওয়ার্কলোডে টেস্ট করুন।

keystore (wallet) কী ও কেন গুরুত্বপূর্ণ?

keystore TDE master key ধরে রাখে। এটি ছাড়া ডেটাবেজ এনক্রিপ্টেড tablespace খুলতে পারে না, তাই হারালে ডেটা চিরতরে অপাঠ্য। ডেটাবেজ থেকে আলাদা ও নিরাপদে ব্যাকআপ নিন, শক্তিশালী পাসওয়ার্ড দিন।

TDE কি ডেটা masking-এর মতোই?

না। TDE ডেটা অ্যাট রেস্ট এনক্রিপ্ট করে যাতে চুরি ফাইল অপাঠ্য হয়, কিন্তু অনুমোদিত ইউজার আসল ভ্যালু দেখে। Masking/redaction নির্দিষ্ট ইউজারের জন্য সংবেদনশীল ভ্যালু নকল বা লুকানো দিয়ে বদলায়। এরা ভিন্ন সমস্যা সমাধান করে, প্রায়ই একসাথে ব্যবহৃত হয়।