ডাটাবেসে ব্যবহারকারী এবং অনুমতি

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

MySQL এবং MariaDB

এখানে একটি ইউজার হলো “নাম ও হোস্ট”-এর জোড়া, আর এটাই বিভ্রান্তির মূল উৎস:

CREATE USER 'shop'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'shop'@'localhost';
FLUSH PRIVILEGES;

'shop'@'localhost' এবং 'shop'@'%' হলো ভিন্ন পাসওয়ার্ডসহ দুটি ভিন্ন ইউজার। প্রয়োজন ছাড়া % হোস্ট দিয়ে রেকর্ড তৈরি করবেন না: এটি যেকোনো ঠিকানা থেকে লগইনের সুযোগ দেয়।

স্ট্রাকচারের উপর অধিকার প্রয়োজন শুধু মাইগ্রেশনের সময়:

GRANT CREATE, ALTER, DROP, INDEX, REFERENCES ON shop.* TO 'shop_migrate'@'localhost';

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

যাচাই করুন:

SELECT user, host FROM mysql.user;
SHOW GRANTS FOR 'shop'@'localhost';

পাসওয়ার্ড পরিবর্তন ও ডিলিট:

ALTER USER 'shop'@'localhost' IDENTIFIED BY 'new-password';
DROP USER 'shop'@'localhost';

PostgreSQL

রোল এবং ডেটাবেস ও স্কিমার উপর তার অধিকার:

CREATE ROLE shop WITH LOGIN PASSWORD 'long-random-password';
CREATE DATABASE shop OWNER shop;
REVOKE ALL ON DATABASE shop FROM PUBLIC;

রিড-অনলি রোলের জন্য (রিপোর্ট, অ্যানালিটিক্স, মনিটরিং প্যানেল):

CREATE ROLE reader WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE shop TO reader;
GRANT USAGE ON SCHEMA public TO reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO reader;

শেষ লাইনটি বাধ্যতামূলক: এটি ছাড়া অধিকার দেওয়ার পরে তৈরি হওয়া টেবিলগুলো রোল দেখতে পাবে না, আর এক মাস পরে নতুন ডেটায় রিপোর্ট ভেঙে পড়বে।

যাচাই করুন:

\du
\l
\dp

যা অবশ্যই লকডাউন করতে হবে

• কোনো অ্যাপ্লিকেশন রোল সুপারইউজার নয়।
• প্রতিটি প্রজেক্টের নিজস্ব ডেটাবেস ও নিজস্ব ইউজার আছে।
• পাসওয়ার্ড দীর্ঘ ও র‍্যান্ডম, এবং ভিন্ন ভিন্ন প্রজেক্টের জন্য ভিন্ন।
• বাইরে থেকে লগইন শুধু যেসব ঠিকানার প্রয়োজন সেগুলোর জন্যই অনুমোদিত — রিমোট অ্যাক্সেস।
• MySQL-এ কোনো অ্যানোনিমাস ইউজার নেই এবং টেস্ট ডেটাবেস নেই: mariadb-secure-installation এটি করে দেয়।

সাধারণ ভুল

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