MySQL Security (সুরক্ষা ব্যবস্থা)

আপনি পৃথিবীর সেরা অ্যাপ বানালেন, কিন্তু হ্যাকার এক লাইনের কোড দিয়ে সব ইউজার ডেটা চুরি করে নিয়ে গেল—তাহলে সব পরিশ্রম বৃথা। ডেটাবেস সিকিউরিটি কোনো অপশনাল বিষয় নয়, এটি আবশ্যিক।

এই অধ্যায়ে আমরা শিখব কীভাবে ডেটাবেসকে হ্যাকারদের কবল থেকে রক্ষা করা যায়।

১৩.১ ইউজার এবং প্রিভিলেজ সিস্টেম (The Gatekeeper)

MySQL-এ ডিফল্টভাবে root ইউজার থাকে যার সব ক্ষমতা আছে। কিন্তু অ্যাপ্লিকেশনের জন্য কখনোই root ব্যবহার করবেন না।

💡 User তৈরি করার নিয়ম: user@host ফরমেটে ইউজার তৈরি হয়। এখানে host ঠিক করে দেয় ইউজার কোথা থেকে কানেক্ট করতে পারবে।

❌ খারাপ প্র্যাকটিস

CREATE USER 'shagor'@'%' IDENTIFIED BY 'Password123';

(সবাই কানেক্ট করতে পারবে)

✅ ভালো প্র্যাকটিস

CREATE USER 'shagor'@'192.168.1.10' IDENTIFIED BY 'StrongPass#99';

(শুধুমাত্র ওয়েব সার্ভারের আইপি থেকে কানেক্ট করতে পারবে)

১৩.২ GRANT Privileges (Principle of Least Privilege)

সবচেয়ে গুরুত্বপূর্ণ সিকিউারিটি রুল: "যার যতটুকু দরকার, তাকে ঠিক ততটুকুই দাও।"

❌ কখনোই করবেন না:

GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%';

(এটি করলে হ্যাকার অ্যাপ হ্যাক করতে পারলে পুরো ডেটাবেস মুছে দিতে পারে)

✅ প্রোডাকশন বেস্ট প্র্যাকটিস:

GRANT SELECT, INSERT, UPDATE, DELETE ON my_app_db.* TO 'app_user'@'192.168.1.10';

(অ্যাপ ইউজার শুধু ডেটা পড়তে ও লিখতে পারবে, কিন্তু টেবিল ড্রপ বা অল্টার করতে পারবে না)

১৩.৩ পারমিশন দেখা এবং বাতিল করা

🔍 পারমিশন চেক করা:

SHOW GRANTS FOR 'shagor'@'192.168.1.10';

⛔ পারমিশন কেড়ে নেওয়া (Revoke):

REVOKE UPDATE, DELETE ON my_app_db.* FROM 'shagor'@'192.168.1.10';
FLUSH PRIVILEGES;

(শেষে FLUSH PRIVILEGES দিতে ভুলবেন না)

১৩.৪ SQL Injection Prevention (ইন্টারভিউ হট টপিক)

SQL Injection হলো হ্যাকারদের সবচেয়ে প্রিয় অস্ত্র।

❌ ভালনারেবল কোড (কখনো করবেন না):

// Node.js Example
const query = "SELECT * FROM users WHERE email = '" + userInput + "'";

হ্যাকার যদি ইনপুট দেয়: ' OR 1=1 -- তখন কুয়েরি হয়ে যায়: SELECT * FROM users WHERE email = '' OR 1=1 --'

ফলাফল: 1=1 সবসময় সত্য, তাই ডেটাবেসের সব ইউজার লিক হয়ে যাবে!

✅ সমাধান: Prepared Statements

// ✅ Secure Way
const query = "SELECT * FROM users WHERE email = ?";
db.execute(query, [userInput]);

প্রিপেয়ারড স্টেটমেন্টে ডেটা এবং কুয়েরি লজিক আলাদাভাবে পাঠানো হয়। ডেটাবেস ইনপুটকে শুধুই "টেক্সট" হিসেবে দেখে, কুয়েরি কমান্ড হিসেবে নয়।

এখন হ্যাকার যা খুশি ইনপুট দিক, ডেটাবেস সেটাকে টেক্সট হিসেবেই খুঁজবে।

১৩.৫ MySQL কনফিগারেশন হার্ডেনিং (my.cnf)

সার্ভার লেভেলে কিছু কনফিগারেশন চেঞ্জ করে সিকিউরিটি বাড়ানো যায়।

🔒 Disable Remote Root Login: root যেন দূর থেকে লগইন করতে না পারে।

🌐 Bind Address:

bind-address = 127.0.0.1

(এটি সেট করলে বাইরের ইন্টারনেট থেকে কেউ সরাসরি পোর্টে হিট করতে পারবে না)

📁 Disable Symbolic Links: symbolic-links=0 (ফাইল সিস্টেম হ্যাক রোধ করে)

১৩.৬ পাসওয়ার্ড পলিসি এবং হ্যাশিং

এখানে দুটি বিষয় আছে: ১. ডেটাবেস ইউজারের পাসওয়ার্ড, ২. অ্যাপ ইউজারের পাসওয়ার্ড।

🔐 ডেটাবেস ইউজার (MySQL User)

শক্তিশালী পাসওয়ার্ড ব্যবহার করুন (Uppercase, Lowercase, Number, Symbol)

👤 অ্যাপ ইউজার (End User Password)

ডেটাবেসে কখনোই প্লেইন টেক্সট পাসওয়ার্ড রাখবেন না।

-- ❌ খারাপ
INSERT INTO users VALUES ('admin', '123456');

-- ✅ ভালো
INSERT INTO users VALUES ('admin', bcrypt_hash('123456'));

ব্যবহার করুন: bcrypt, Argon2, scrypt
বর্জন করুন: MD5, SHA1 (এগুলো ক্র্যাক করা খুব সহজ)

১৩.৭ নেটওয়ার্ক সিকিউরিটি (Firewall)

ডেটাবেস পোর্ট (3306) কখনোই পাবলিক ইন্টারনেটে ওপেন রাখা উচিত নয়।

UFW (Ubuntu Firewall) রুল:

# সব ব্লক করো
ufw deny 3306

# শুধু আমার অ্যাপ সার্ভারকে অনুমতি দাও
ufw allow from 123.45.67.89 to any port 3306

AWS বা ক্লাউডে Security Group ব্যবহার করে এটি নিশ্চিত করতে হয়।

১৩.৮ SSL/TLS এনক্রিপশন (Secure Transport)

অ্যাপ সার্ভার এবং ডেটাবেস সার্ভার যদি আলাদা নেটওয়ার্কে থাকে, তবে মাঝপথে কেউ ডেটা স্নিফ (Sniff) বা চুরি করতে পারে। তাই কানেকশন এনক্রিপ্ট করা জরুরি।

MySQL এ SSL এনফোর্স করা:

CREATE USER 'secure_user'@'%' IDENTIFIED BY 'pass' REQUIRE SSL;

এতে ক্লায়েন্ট সার্টিফিকেট ছাড়া কানেক্ট করতে পারবে না।

১৩.৯ এনক্রিপশন (Encryption at Rest)

খুবই সেনসিটিভ ডেটা (যেমন: NID, Credit Card Number) প্লেইন টেক্সটে রাখা উচিত নয়। ডেটাবেস অ্যাডমিনও যেন দেখতে না পারে।

AES এনক্রিপশন:

-- ইনসার্ট করার সময় এনক্রিপ্ট
INSERT INTO cards (pan) VALUES (AES_ENCRYPT('4444-5555', 'SecretKey'));

-- পড়ার সময় ডিক্রিপ্ট
SELECT AES_DECRYPT(pan, 'SecretKey') FROM cards;

⚠️ সতর্কতা: 'SecretKey' কখনোই ডেটাবেসে বা কোডে হার্ডকোড করবেন না। এটি এনভায়রনমেন্ট ভেরিয়েবল (.env) এ রাখুন।

১৩.১০ অডিট লগ (কে কী করল?)

ব্যাংকিং বা ফিনটেক অ্যাপে এটি বাধ্যতামূলক। কে কখন লগইন করেছে, কে টেবিল ড্রপ করার চেষ্টা করেছে—সব রেকর্ড থাকতে হবে।

MySQL Enterprise এ অডিট প্লাগিন আছে। ওপেন সোর্সে General Query Log অন করা যায় (তবে এতে ডিস্ক ভরে যেতে পারে, তাই সাবধানে)।

১৩.১১ কমন মিসকনফিগারেশন (বিপদের কারণ)

জুনিয়র ডেভেলপাররা প্রায়ই এই ভুলগুলো করে:

  • ❌পাবলিক পোর্ট: হ্যাকাররা সবসময় পোর্ট 3306 স্ক্যান করে। ওপেন পেলেই ব্রুট ফোর্স অ্যাটাক চালায়।
  • ❌Github-এ ক্রেডেনশিয়াল: .env ফাইল বা কনফিগের মধ্যে পাসওয়ার্ডসহ কোড গিটহাবে পুশ করে দেওয়া। (সবসময় .gitignore ব্যবহার করুন)।
  • ❌App as Root: অ্যাপ্লিকেশনে root ইউজার ব্যবহার করা।
  • ❌No Backups: র্যানসামওয়্যার অ্যাটাক হলে ব্যাকআপ ছাড়া বাঁচার উপায় নেই।

১৩.১২ Senior Level Checklist

প্রোডাকশনে যাওয়ার আগে এই চেকলিস্ট মিলিয়ে নিন:

  • ✓অ্যাপ্লিকেশনের জন্য আলাদা ইউজার এবং সীমিত পারমিশন আছে কি?
  • ✓রিমোট রুট লগইন বন্ধ করা আছে কি?
  • ✓ফায়ারওয়াল দিয়ে পোর্ট 3306 রেস্ট্রিক্ট করা আছে কি?
  • ✓ইউজার ইনপুট স্যানিটাইজ বা প্রিপেয়ারড স্টেটমেন্ট ব্যবহার হচ্ছে কি?
  • ✓সেনসিটিভ ডেটা (পাসওয়ার্ড, কার্ড) এনক্রিপ্ট বা হ্যাশ করা আছে কি?
  • ✓SSL কানেকশন এনাবল করা আছে কি?

🎯 অধ্যায় ১৩ এর সারাংশ (Summary)

এই অধ্যায়ে আমরা শিখলাম:

  • ✓Users: root ব্যবহার না করে স্পেসিফিক ইউজার তৈরি করা।
  • ✓Privileges: GRANT এবং REVOKE দিয়ে এক্সেস কন্ট্রোল করা।
  • ✓SQL Injection: Prepared Statement দিয়ে অ্যাপ সিকিউর করা।
  • ✓Network: ফায়ারওয়াল এবং SSL এর গুরুত্ব।
  • ✓Data Safety: পাসওয়ার্ড হ্যাশিং এবং ডেটা এনক্রিপশন।

✨ সিকিউরিটি কোনো গন্তব্য নয়, এটি একটি চলমান প্রক্রিয়া। পরবর্তী অধ্যায়ে আমরা শিখব Backup & Recovery—যেখানে আমরা শিখব হ্যাক বা ক্র্যাশ হওয়ার পর কীভাবে ডেটা ফিরিয়ে আনব।

প্রস্তুত তো? 🚀

🔒 কপিরাইট সুরক্ষিত কন্টেন্ট 🔒

কপি, স্ক্রিনশট, প্রিন্ট করা সম্পূর্ণ নিষিদ্ধ।