ডেটাবেস নিরাপত্তা — SQL injection প্রতিরোধ, privilege আর encryption

১ · নিরাপত্তা আসলে কী রক্ষা করে — CIA triad আর threat model

পর্ব ৪৯-এ দেখেছেন, অ্যাপ কীভাবে driver দিয়ে ডেটাবেসে কোয়েরি পাঠায়; পর্ব ৫০-এ দেখেছেন ORM. এবার প্রশ্ন: এই পথে কী কী ভুল হতে পারে, আর ভুল হলে ক্ষতি কতটা সীমিত রাখা যায়? ডেটাবেস নিরাপত্তার আলোচনা সাধারণত তিনটি শব্দ দিয়ে শুরু হয়, যাদের একসাথে বলে CIA triad:

তিনটি একে অপরকে টানে। সব কলাম encrypt করলে গোপনীয়তা বাড়ে, কিন্তু key হারালে ডেটা চিরতরে অপ্রাপ্য। তাই নিরাপত্তা মানে “সব বন্ধ করা” নয়; মানে ঝুঁকি বুঝে প্রতিটি স্তরে সঠিক পরিমাণ পাহারা।

ঝুঁকি বুঝতে প্রথম কাজ একটি threat model: কে ক্ষতি করতে পারে, কোন পথে, আর কী হারাতে পারি। ডেটাবেসের জন্য তিন রকম উৎস প্রায় সবসময় থাকে:

• বাইরের লোক: ইন্টারনেটে খোলা ডেটাবেস পোর্ট খোঁজা স্বয়ংক্রিয় স্ক্যানার, চুরি যাওয়া password দিয়ে লগইনের চেষ্টা, ওয়েবসাইটের ফর্মে উল্টাপাল্টা ইনপুট।
• ভেতরের লোক: কৌতূহলী কর্মী যিনি পরিচিত কারও তথ্য দেখেন, বিদায়ী কর্মী যাঁর অ্যাকাউন্ট বন্ধ হয়নি, আর সবচেয়ে বেশি — সৎ মানুষের ভুল: production-এ ভুল টেবিলে DELETE, ভুল জায়গায় পাঠানো backup.
• আক্রান্ত অ্যাপ বা যন্ত্র: ওয়েব অ্যাপে একটি বাগ, পুরোনো একটি library, কোনো ডেভেলপারের ল্যাপটপে রাখা connection string, বা GitHub-এ ভুল করে তোলা password. এখানে আক্রমণকারী অ্যাপের পরিচয়েই ডেটাবেসে কথা বলে।

এই পর্বের উদাহরণগুলো সব নিজেদের বানানো ছোট টেবিলে। উদ্দেশ্য একটাই: আপনার নিজের অ্যাপ আর ডেটাবেস কীভাবে নিরাপদ রাখবেন, তা বোঝা।

২ · SQL injection — ডেটা আর কোড যখন একই লেখায় মিশে যায়

অ্যাপ ডেটাবেসকে যা পাঠায়, তা একটি লেখা — SQL. সমস্যা শুরু হয় যখন ডেভেলপার এই লেখা বানান স্ট্রিং জোড়া দিয়ে: SQL-এর একটি টুকরো, তার সাথে ফর্মে ব্যবহারকারী যা লিখেছেন, তারপর আবার SQL-এর টুকরো। তখন ডেটা (ব্যবহারকারীর লেখা) আর কোড (প্রোগ্রামারের লেখা SQL) একই লেখায় মিশে যায়, আর DBMS-এর কাছে আলাদা করে চেনার কোনো উপায় থাকে না কোনটি কার।

SQL-এ লেখা মান থাকে একক উদ্ধৃতিচিহ্নের ভেতরে — string literal, যেমন 'Dhaka'. ইনপুটে নিজেই যদি একটি ' থাকে, জোড়া লেখায় সেটি literal-কে আগেভাগে বন্ধ করে দেয়, আর ইনপুটের বাকি অংশ আর মান থাকে না — DBMS সেটিকে SQL হিসেবে পড়ে। একেই বলে SQL injection: বাইরের লেখা কোয়েরির গঠনে ঢুকে পড়া। কেউ ইচ্ছা করে লেখা সাজিয়ে পাঠালে কোয়েরির শর্তই বদলে যেতে পারে — যে সারি দেখার কথা নয় তা দেখা, যে সারি বদলানোর কথা নয় তা বদলানো বা মোছা। ক্ষতি কতটা হবে, তা নির্ভর করে অ্যাপের ডেটাবেস অ্যাকাউন্টের অধিকারের ওপর (অংশ ৫)।

পদ্ধতিটি বুঝতে আক্রমণের দরকার নেই — একটি সৎ নামই যথেষ্ট। সিলেটের একজন গ্রাহকের নাম Shamim O'Brien; নামের ভেতরেই একটি '. নিচের ডায়াগ্রামে একই খোঁজ দুই পদ্ধতিতে দেখুন:

এই পর্বের লাইভ SQL চলে দোকানের ডেটাবেসে (db-shop): customers (customer_id, name, city, phone, joined_on — ৮ জন; phone-এ UNIQUE, Tanvir-এর phone NULL), categories, products (product_id, name, category_id, price, stock), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার) আর order_items (order_id, product_id, quantity, unit_price). প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়; প্রথম ত্রুটিতে রানার থেমে যায়। নমুনা ডেটা দেখতে এডিটরের নিচের বাক্সটি খুলুন।

হাতে SQL লিখলে নিয়মটি সহজ: literal-এর ভেতরে ' লিখতে হয় পরপর দুবার — ''. এটি SQL standard-এর escape নিয়ম, সব বড় DBMS-এ চলে। প্রথম INSERT নিয়ম মেনে, শেষটি নিয়ম ভেঙে:

INSERT INTO customers (customer_id, name, city, phone, joined_on)
VALUES (9, 'Shamim O''Brien', 'Sylhet', NULL, '2025-10-20');
SELECT customer_id, name, length(name) AS len
FROM customers WHERE name LIKE '%''%';
-- উদ্ধৃতিচিহ্ন দুবার না লিখলে স্ট্রিং মাঝপথে শেষ হয়
INSERT INTO customers (customer_id, name, city, phone, joined_on)
VALUES (10, 'Shamim O'Brien', 'Sylhet', NULL, '2025-10-20');

এবার একই জিনিস একটি অ্যাপের ভেতর থেকে। নিচের Python প্রোগ্রাম (stdlib-এর sqlite3, মেমরিতে একটি ছোট নিজস্ব টেবিল) দুটি খোঁজ-ফাংশন বানায় — একটি জোড়া দিয়ে, একটি placeholder দিয়ে — আর দুটি নাম দিয়ে চালায়:

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, city TEXT)")
db.executemany("INSERT INTO customers (name, city) VALUES (?, ?)",
    [("Rahim Uddin", "Dhaka"), ("Shamim O'Brien", "Sylhet"), ("Karima Begum", "Chattogram")])

def find_glued(name):      # DON'T: input becomes part of the SQL text
    sql = "SELECT id, city FROM customers WHERE name = '" + name + "'"
    return db.execute(sql).fetchall()

def find_bound(name):      # DO: fixed SQL text, value sent separately
    return db.execute("SELECT id, city FROM customers WHERE name = ?", (name,)).fetchall()

for name in ["Rahim Uddin", "Shamim O'Brien"]:
    try:
        glued = find_glued(name)
    except sqlite3.Error as e:
        glued = "ERROR: " + str(e)
    print(repr(name), "| glued:", glued, "| bound:", find_bound(name))

৩ · প্রতিরোধ — parameterised query, allow-list আর নিরাপদ dynamic SQL

প্রধান প্রতিরোধ: parameterised query

Parameterised query-তে SQL-এর লেখায় মানের জায়গায় placeholder থাকে — ? (SQLite, JDBC, MySQL), $1 (PostgreSQL), বা :name / %s (কিছু driver). মানগুলো যায় আলাদা তালিকায়। সার্ভার যখন লেখাটি আগে parse করে রাখে আর পরে বারবার আলাদা মান দিয়ে চালায়, তাকে বলে prepared statement (পর্ব ৪৯)। সব জনপ্রিয় ভাষায় একই ধারণা:

# sqlite3: ?   ·   psycopg (PostgreSQL): %s — দুটিই placeholder
cur.execute("SELECT id, city FROM customers WHERE name = ?", (name,))

# ভুল: f-string বা + দিয়ে জোড়া, placeholder-এর মতো দেখালেও
cur.execute(f"SELECT id, city FROM customers WHERE name = '{name}'")

String sql = "SELECT id, city FROM customers WHERE name = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setString(1, name);              // ১ নম্বর ? = name
    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) { /* ... */ }
    }
}

const { rows } = await pool.query(
  'SELECT id, city FROM customers WHERE name = $1',
  [name]                                // $1 = name
);

$st = $pdo->prepare('SELECT id, city FROM customers WHERE name = :name');
$st->execute(['name' => $name]);
$rows = $st->fetchAll();

কেন এটি “মূল থেকে” সমাধান? কারণ গঠন আর মান দুটি আলাদা চ্যানেলে যায়। মানের ভেতরে কী আছে — ', ;, --, বাংলা অক্ষর, emoji — তা দেখার প্রয়োজনই পড়ে না, কোনো তালিকা মেলাতে হয় না। “খারাপ অক্ষর খুঁজে বাদ দাও” ধরনের পদ্ধতি কোনো না কোনো রূপ বাদ রাখবেই; placeholder সেই খেলাতেই নামে না।

ORM আর query builder — সঠিকভাবে ব্যবহার করলে

পর্ব ৫০-এর ORM (SQLAlchemy, Django ORM, Hibernate, Eloquent) নিজে থেকেই placeholder দিয়ে SQL বানায়: select(Customer).where(Customer.name == name) নিরাপদ। বিপদ ORM-এর “কাঁচা SQL” দরজায়: SQLAlchemy-র text(), Django-র raw() বা extra(), Hibernate-এর HQL/native query — এগুলোর ভেতরে f-string বা জোড়া দিলে ORM কোনো রক্ষা করে না। নিয়ম একই: কাঁচা SQL-এও bind parameter — text("… WHERE name = :n")-এর সাথে {"n": name}.

যা placeholder হতে পারে না — identifier আর allow-list

Placeholder শুধু মানের জায়গায় বসে। টেবিল বা কলামের নাম (identifier), ASC/DESC, SQL-এর কোনো keyword — এগুলো কোয়েরির গঠনের অংশ, তাই parse-এর আগেই জানা চাই। অথচ “দাম অনুযায়ী সাজাও” বা “নাম অনুযায়ী সাজাও” — এমন বোতাম প্রায় প্রতিটি অ্যাপে আছে। সমাধান allow-list: ব্যবহারকারী শুধু একটি চাবি পাঠান, আর কোডে প্রোগ্রামারের লেখা একটি তালিকা থেকে আসল SQL-এর টুকরো বেছে নেওয়া হয়। তালিকায় না থাকলে সোজা প্রত্যাখ্যান। নিচের প্রোগ্রামে এটি, সাথে একটি নীরব ফাঁদ:

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT, city TEXT)")
db.executemany("INSERT INTO customers (name, city) VALUES (?, ?)",
    [("Rahim Uddin", "Dhaka"), ("Shamim O'Brien", "Sylhet"), ("Karima Begum", "Chattogram")])

# 1) a placeholder is a VALUE, not a column: ORDER BY 'name' sorts nothing
print([r[0] for r in db.execute("SELECT name FROM customers ORDER BY ?", ("name",))])

# 2) identifiers come from an allow-list written by the programmer
SORTS = {"name": "name", "city": "city", "newest": "id DESC"}
def list_customers(sort_key):
    if sort_key not in SORTS:
        raise ValueError("unknown sort key: " + repr(sort_key))
    return [r[0] for r in db.execute("SELECT name FROM customers ORDER BY " + SORTS[sort_key])]

print(list_customers("city"))
try:
    list_customers("phone")
except ValueError as e:
    print(e)

Stored procedure-এর ভেতরে dynamic SQL

পর্ব ২৮-এ দেখেছেন, stored procedure-এর ভেতরে চলার সময় SQL বানানো যায় — dynamic SQL. procedure থাকলেই নিরাপদ নয়: ভেতরে EXECUTE 'SELECT … ORDER BY ' || sort_col লিখলে একই জোড়ার সমস্যা ডেটাবেসের ভেতরে চলে আসে। PostgreSQL-এর নিরাপদ পথ তিনটি অংশে: allow-list, identifier-এর জন্য format('%I', …) (বা quote_ident), আর মানের জন্য EXECUTE … USING:

CREATE FUNCTION products_sorted(sort_col text, max_rows int)
RETURNS SETOF products
LANGUAGE plpgsql AS $$
BEGIN
  IF sort_col NOT IN ('name', 'price', 'stock') THEN      -- allow-list
    RAISE EXCEPTION 'sort column not allowed: %', sort_col;
  END IF;
  RETURN QUERY EXECUTE
    format('SELECT * FROM products ORDER BY %I LIMIT $1', sort_col)  -- %I = identifier
    USING max_rows;                                        -- মান = parameter
END;
$$;

%I নামটিকে প্রয়োজনে double quote-এ মুড়ে নিরাপদ identifier বানায় (quoted identifier); %L একটি মানকে নিরাপদ literal বানায়, কিন্তু মানের জন্য USING আরও ভালো। অন্য DBMS-এ একই কাজ: SQL Server-এ sp_executesql (parameter-সহ) আর identifier-এর জন্য QUOTENAME(); MySQL-এ PREPARE … FROM আর EXECUTE … USING @v. procedure-টি SECURITY DEFINER হলে (মালিকের অধিকারে চলে) সতর্কতা আরও বেশি দরকার, কারণ ভুলের ক্ষতি হবে মালিকের অধিকার পর্যন্ত; PostgreSQL ডকুমেন্টেশন এমন function-এ search_path নির্দিষ্ট করে দিতেও বলে।

সহায়ক স্তর: input validation আর নিরাপদ ত্রুটি-বার্তা

Input validation — “মোবাইল নম্বর ১১ অঙ্কের, 01 দিয়ে শুরু”, “পরিমাণ ১ থেকে ১০০” — ভালো অভ্যাস: ভুল ডেটা আগেই আটকায়, ব্যবহারকারীকে স্পষ্ট বার্তা দেয়। কিন্তু এটি injection-এর সমাধান নয়। নাম, ঠিকানা, মন্তব্যের মতো মুক্ত লেখায় ' বৈধ (O'Brien!), আর একটি ফর্মে validation ভুলে গেলেই ফাঁক। তাই validation হলো defence in depth-এর একটি স্তর — placeholder-এর পাশে, বদলে নয়।

ত্রুটি-বার্তাও তথ্য ফাঁস করে। ডেটাবেসের কাঁচা বার্তা — টেবিলের নাম, কলামের নাম, SQL-এর টুকরো, DBMS-এর সংস্করণ — ব্যবহারকারীর পর্দায় দেখালে schema-র মানচিত্র বাইরে চলে যায়। নিয়ম: ব্যবহারকারী দেখবেন সাধারণ বার্তা আর একটি রেফারেন্স কোড (“কিছু সমস্যা হয়েছে, কোড E-7F3A”); পুরো বিবরণ যাবে সার্ভারের log-এ, যা শুধু দলের লোক পড়েন।

৪ · Authentication — ডেটাবেসে কে ঢুকছেন

নিরাপত্তার দুটি আলাদা প্রশ্ন আছে, যা প্রায়ই গুলিয়ে যায়। Authentication: “আপনি কে?” — পরিচয় প্রমাণ। Authorization: “আপনি কী করতে পারেন?” — অধিকার। এই অংশ প্রথমটি নিয়ে।

• প্রত্যেকের আলাদা অ্যাকাউন্ট। পাঁচজন ডেভেলপার একটি “admin” password ভাগ করে নিলে audit log-এ শুধু “admin” লেখা থাকবে — কে করলেন, জানার উপায় নেই; কেউ চাকরি ছাড়লে সবার password বদলাতে হয়। মানুষ প্রতি একটি, অ্যাপ বা সার্ভিস প্রতি একটি অ্যাকাউন্ট।
• শক্ত password, নিরাপদ পদ্ধতিতে যাচাই। অ্যাপের অ্যাকাউন্টে লম্বা, এলোমেলো password (মানুষকে মনে রাখতে হয় না)। PostgreSQL ১০ থেকে SCRAM-SHA-256 আছে, আর ১৪ থেকে এটিই ডিফল্ট: সার্ভার password নিজে রাখে না, আর নেটওয়ার্কে password যায় না — দুই পক্ষ একটি challenge-response বিনিময়ে প্রমাণ করে যে দুজনেই একই গোপন জিনিস জানে। পুরোনো MD5 পদ্ধতি এড়িয়ে চলুন; সাম্প্রতিক সংস্করণে (PostgreSQL ১৮) এটিকে deprecated ঘোষণা করা হয়েছে। MySQL ৮-এর ডিফল্ট caching_sha2_password.
• কোথা থেকে ঢোকা যাবে, তা-ও নিয়ম। ডেটাবেসের পোর্ট (PostgreSQL 5432, MySQL 3306) কখনো সরাসরি ইন্টারনেটে খোলা রাখবেন না; শুধু অ্যাপ সার্ভারের ঠিকানা থেকে। PostgreSQL-এ এই নিয়ম pg_hba.conf-এ — ওপর থেকে প্রথম মেলা লাইনটিই প্রযোজ্য।
• গোপন তথ্য কোডে নয়। connection string-এর password কোডে বা Git-এ নয় — environment variable বা একটি secrets manager-এ। নির্দিষ্ট সময় পরপর, আর কেউ চলে গেলে বা ফাঁসের সন্দেহ হলে সঙ্গে সঙ্গে, password বদলান (rotation).

# TYPE    DATABASE  USER         ADDRESS        METHOD
hostssl   shop      app_web      10.0.1.0/24    scram-sha-256
hostssl   shop      +shop_admin  10.0.9.5/32    scram-sha-256
host      all       all          0.0.0.0/0      reject

প্রথম লাইন: শুধু TLS সংযোগে (hostssl), শুধু shop ডেটাবেসে, শুধু app_web, শুধু অ্যাপ সার্ভারের নেটওয়ার্ক থেকে। দ্বিতীয়: +shop_admin মানে ঐ role-এর সদস্যরা, একটি নির্দিষ্ট অ্যাডমিন যন্ত্র থেকে। শেষ লাইন বাকি সব বাতিল করে। SQLite-এর কোনো ব্যবহারকারী বা password নেই — সেখানে পাহারা হলো ফাইলের অধিকার: যে প্রক্রিয়া ফাইলটি পড়তে পারে, সে সব ডেটা পড়তে পারে।

৫ · Authorization — role, GRANT, REVOKE আর least privilege

লগইনের পরে প্রশ্ন: এই অ্যাকাউন্ট কোন টেবিলে কী করতে পারবে? SQL-এর উত্তর privilege — একটি নির্দিষ্ট বস্তুর ওপর একটি নির্দিষ্ট কাজের অনুমতি: SELECT, INSERT, UPDATE, DELETE (টেবিল, view বা নির্দিষ্ট কলামে), EXECUTE (function-এ), USAGE (schema-য়), CREATE, CONNECT ইত্যাদি। দেওয়া হয় GRANT দিয়ে, ফেরানো হয় REVOKE দিয়ে। আধুনিক DBMS-এ অধিকার সরাসরি মানুষকে না দিয়ে দেওয়া হয় role-কে — “কাজের পদ”, যেমন “শুধু পড়ে”, “অর্ডার লেখে”, “অ্যাডমিন” — আর মানুষ বা অ্যাপকে সেই role-এর সদস্য করা হয়। PostgreSQL-এ user আর role একই জিনিস (LOGIN-ওয়ালা role = user); MySQL-এ role এসেছে ৮.০-তে।

পেছনের নীতিটির নাম principle of least privilege: প্রতিটি অ্যাকাউন্ট পাবে কাজের জন্য যতটুকু দরকার, ঠিক ততটুকু — তার বেশি নয়। অংশ ২-এর বাগটি যদি কোনোদিন থেকে যায়, ক্ষতির সীমা ঠিক করে দেবে এই নীতি। নিচের ডায়াগ্রামে PostgreSQL-এ একটি অধিকারের শিকল ধাপে ধাপে দেখুন:

CREATE ROLE app_web LOGIN;
\password app_web       -- psql-এ, log-এ password যায় না

app_web কোনো টেবিলে কিছুই পারে না

CREATE ROLE shop_read NOLOGIN;
GRANT USAGE ON SCHEMA public TO shop_read;
GRANT SELECT ON products, categories,
      customers_public TO shop_read;

CREATE ROLE shop_write NOLOGIN;
GRANT shop_read TO shop_write;
GRANT SELECT, INSERT, UPDATE
      ON orders, order_items TO shop_write;

GRANT shop_write TO app_web;

app_web ⊃ shop_write ⊃ shop_read

SELECT name, city FROM customers_public;  -- ✓
INSERT INTO orders …;                     -- ✓
SELECT phone FROM customers;
ERROR: permission denied for table customers
DROP TABLE orders;
ERROR: must be owner of table orders

REVOKE shop_write FROM app_web;
GRANT  shop_read  TO   app_web;   -- শুধু পড়া

INSERT INTO orders …;
ERROR: permission denied for table orders

বাস্তবে সাধারণত অন্তত তিনটি আলাদা role থাকে: অ্যাপ (শুধু নিজের টেবিলে পড়া-লেখা, কোনো DDL নয়), রিপোর্ট বা analyst (শুধু পড়া, সম্ভব হলে replica-য়), আর অ্যাডমিন/migration (DDL, শুধু deploy-এর সময়, আলাদা অ্যাকাউন্টে)। টেবিলের মালিক কোনো অ্যাপের অ্যাকাউন্ট নয়। কলাম ধরে অধিকারও দেওয়া যায়, PostgreSQL আর MySQL দুটিতেই:

-- কলাম-স্তরের অধিকার: phone ছাড়া পড়া, শুধু city বদলানো
GRANT SELECT (customer_id, name, city), UPDATE (city)
      ON customers TO support_team;

REVOKE ALL ON customers FROM PUBLIC;          -- "সবাই" থেকে সব ফেরানো
CREATE ROLE report_bot LOGIN IN ROLE shop_read;

-- কে কী পেয়েছে, দেখা
SELECT grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_name = 'orders';

CREATE USER 'app_web'@'10.0.1.%' IDENTIFIED BY '…';   -- কোথা থেকে, তা-ও অংশ
CREATE ROLE 'shop_read', 'shop_write';
GRANT SELECT ON shop.products TO 'shop_read';
GRANT SELECT (customer_id, name, city) ON shop.customers TO 'shop_read';
GRANT 'shop_read' TO 'shop_write';
GRANT INSERT, UPDATE ON shop.orders TO 'shop_write';
GRANT 'shop_write' TO 'app_web'@'10.0.1.%';
SET DEFAULT ROLE ALL TO 'app_web'@'10.0.1.%';   -- না দিলে লগইনে role সক্রিয় হয় না
SHOW GRANTS FOR 'app_web'@'10.0.1.%';

PostgreSQL-এ PUBLIC মানে “সব role”. ১৫-এর আগের সংস্করণে public schema-য় সবাই টেবিল বানাতে পারত; নতুন ডেটাবেসে এটি আর ডিফল্ট নয়, পুরোনো ডেটাবেসে REVOKE CREATE ON SCHEMA public FROM PUBLIC চালিয়ে নিন।

View দিয়ে কলাম লুকানো

কলাম-স্তরের GRANT-এর আরেকটি পরিচিত পথ view (পর্ব ২৪): শুধু দরকারি কলামগুলো নিয়ে একটি view বানিয়ে সেটির ওপর SELECT দেওয়া, মূল টেবিলের ওপর নয়। PostgreSQL-এ ডিফল্টে view চলে তার মালিকের অধিকারে, তাই পড়ুয়াকে মূল টেবিলের অধিকার দিতে হয় না (১৫ থেকে security_invoker দিয়ে উল্টোটাও বেছে নেওয়া যায়)। SQLite-এ অধিকার নেই, কিন্তু ধারণাটি দেখা যায় — সাপোর্ট টিমের জন্য phone ছাড়া গ্রাহকের তালিকা:

CREATE VIEW customers_public AS
SELECT customer_id, name, city FROM customers;
SELECT * FROM customers_public WHERE city = 'Dhaka';
-- view-এ phone কলামটিই নেই
SELECT name, phone FROM customers_public;

৬ · Row-level security — প্রতিটি দোকান শুধু নিজের সারি

কলাম লুকানো গেল; সারি? ধরুন আপনি দোকানের হিসাবের একটি অনলাইন সফটওয়্যার চালান, যেটি ঢাকা, খুলনা, সিলেটের শত শত দোকান ব্যবহার করে — সবার ডেটা একই টেবিলে, একটি shop_id কলাম দিয়ে আলাদা। একে বলে multi-tenant নকশা। সবচেয়ে বড় ভয়: কোনো একটি কোয়েরিতে WHERE shop_id = … লিখতে ভুলে গেলে এক দোকান অন্য দোকানের বিক্রি দেখে ফেলবে। Row-level security (RLS) এই শর্তটি অ্যাপের প্রতিটি কোয়েরি থেকে সরিয়ে টেবিলের নিজের নিয়মে বসায় — PostgreSQL-এ ৯.৫ (২০১৬) থেকে:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
ALTER TABLE orders FORCE ROW LEVEL SECURITY;   -- টেবিলের মালিকও নিয়মের অধীনে

CREATE POLICY shop_isolation ON orders
  USING      (shop_id = current_setting('app.shop_id')::int)   -- কোন সারি দেখা/বদলানো যাবে
  WITH CHECK (shop_id = current_setting('app.shop_id')::int);  -- নতুন/বদলানো সারি কেমন হতে হবে

-- অ্যাপ প্রতিটি transaction-এর শুরুতে, লগইন করা দোকানের id বসায়
BEGIN;
SET LOCAL app.shop_id = '42';
SELECT order_id, status FROM orders;   -- DBMS নিজে যোগ করে: AND shop_id = 42
COMMIT;

খুঁটিনাটিগুলো জরুরি। RLS চালু থাকলে কোনো policy না থাকলে কোনো সারিই দেখা যায় না — ভুল হলে দরজা বন্ধ থাকে, খোলা নয়। superuser আর BYPASSRLS-ওয়ালা role নিয়ম এড়ায়, আর টেবিলের মালিকও এড়ায় যদি না FORCE দেওয়া থাকে — তাই অ্যাপ কখনো মালিক বা superuser হিসেবে সংযোগ করবে না। SET LOCAL মানটি শুধু ঐ transaction পর্যন্ত রাখে; connection pool-এ (পর্ব ৪৯) একটি সংযোগ পরের অনুরোধে অন্য দোকানের কাজে গেলে পুরোনো মান থেকে যাওয়ার ঝুঁকি এভাবে কমে। আর সীমাটি সৎভাবে মনে রাখুন: RLS অ্যাপের ভুলে-যাওয়া WHERE-এর বিরুদ্ধে শক্ত পাহারা; কিন্তু অ্যাপ নিজেই যদি যেকোনো SQL চালানোর মতো আক্রান্ত হয়, সে app.shop_id-ও বদলাতে পারে। তখন বাঁচায় অন্য স্তরগুলো।

SQLite-এ RLS নেই, কিন্তু মূল ধারণাটি — “বর্তমান ব্যবহারকারী একটি জায়গায় লেখা, আর view সেই অনুযায়ী সারি ছাঁকে” — দেখা যায়। এখানে app_session টেবিলটি PostgreSQL-এর app.shop_id-এর ভূমিকা নিচ্ছে, আর গ্রাহকেরা tenant:

CREATE TABLE app_session (customer_id INTEGER NOT NULL);
INSERT INTO app_session VALUES (1);          -- লগইন: Rahim
CREATE VIEW my_orders AS
SELECT o.order_id, o.order_date, o.status
FROM orders o JOIN app_session s ON s.customer_id = o.customer_id;
SELECT * FROM my_orders;
UPDATE app_session SET customer_id = 2;      -- লগইন: Karima
SELECT * FROM my_orders;

৭ · Encryption আর password hashing

অধিকার ঠিক করে দেয় কে ডেটাবেসের ভেতর দিয়ে কী পড়বে। কিন্তু ডেটা ডেটাবেসের বাইরেও থাকে — নেটওয়ার্কের তারে, ডিস্কে, backup ফাইলে। সেখানে পাহারা encryption: key ছাড়া পড়া যায় না এমন রূপে বদলে রাখা।

PostgreSQL-এর মূল সংস্করণে TDE নেই — সাধারণত ডিস্ক-স্তরের encryption ব্যবহার হয়, কিছু বাণিজ্যিক সংস্করণে TDE আছে। কলাম-স্তরের encryption রাখুন সবচেয়ে স্পর্শকাতর অল্প কয়েকটি কলামে: NID নম্বর, ব্যাংক অ্যাকাউন্ট, স্বাস্থ্যের তথ্য। সবচেয়ে ভালো হলো অ্যাপেই encrypt করা, যাতে key কখনো ডেটাবেসে না যায় — key থাকবে আলাদা key management সেবায়। ডেটাবেসে encrypt করলে (যেমন pgp_sym_encrypt) key কোয়েরির সাথে যায়, আর statement log চালু থাকলে log-এ উঠে যেতে পারে।

Password — encrypt নয়, hash

ব্যবহারকারীর password কখনো সাধারণ লেখায় জমা রাখবেন না, encrypt করেও নয় — encrypt মানে key থাকলে ফেরত পড়া যায়। জমা রাখুন password hash: একমুখী একটি হিসাব, যার ফল থেকে password ফেরত পাওয়া যায় না; লগইনের সময় নতুন করে hash বানিয়ে মেলানো হয়। তিনটি শর্ত: প্রতিটি ব্যবহারকারীর আলাদা এলোমেলো salt (একই password-এর hash আলাদা হয়, আগে-বানানো তালিকা অকেজো), ইচ্ছা করে ধীর আর মেমরি-খেকো অ্যালগরিদম (লাখো অনুমান যাচাই ব্যয়বহুল হয়), আর প্রমাণিত library. SHA-256 বা MD5 একা চলবে না — এগুলো দ্রুত হওয়ার জন্যই বানানো। এখনকার পছন্দ Argon2id, বা পুরোনো ও পরীক্ষিত bcrypt; scrypt আর PBKDF2-ও চলে। কাজটি অ্যাপে হয়, ডেটাবেস শুধু ফলটি রাখে:

from argon2 import PasswordHasher
ph = PasswordHasher()                       # salt নিজেই বানায়, hash-এর ভেতরে রাখে

stored = ph.hash("Shapla#2025")             # '$argon2id$v=19$m=65536,t=3,p=4$...'
cur.execute("UPDATE staff SET pw_hash = ? WHERE username = ?", (stored, "rahim"))

ph.verify(stored, "Shapla#2025")            # True; ভুল হলে VerifyMismatchError

৮ · Audit, backup আর defence in depth

কোনো পাহারাই নিখুঁত নয়, তাই দুটি প্রশ্নের উত্তর তৈরি রাখতে হয়: কিছু ঘটলে জানব কীভাবে? আর ঘটে গেলে ফিরব কীভাবে? প্রথমটির উত্তর audit log — কে, কখন, কোন সারিতে কী করল। পর্ব ২৯-এর trigger দিয়ে ছোট একটি audit ব্যবস্থা: গ্রাহকের phone বদলালে বা গ্রাহক মুছলে লেখা থাকবে। খেয়াল করুন, log নিজেও স্পর্শকাতর — তাই পুরো নম্বর নয়, শুধু শেষ তিন অঙ্ক রাখা হচ্ছে। এই এডিটরে আগে থেকে একটি খালি audit_log টেবিল আছে (log_id, table_name, action, row_id, detail, at — শেষটির DEFAULT লেখার মুহূর্তের সময়):

CREATE TRIGGER trg_audit_phone AFTER UPDATE OF phone ON customers
WHEN NEW.phone IS NOT OLD.phone
BEGIN
  INSERT INTO audit_log (table_name, action, row_id, detail)
  VALUES ('customers', 'UPDATE phone', OLD.customer_id,
    coalesce('…' || substr(OLD.phone, -3), 'none') || ' -> …' || substr(NEW.phone, -3));
END;
CREATE TRIGGER trg_audit_delete AFTER DELETE ON customers
BEGIN
  INSERT INTO audit_log (table_name, action, row_id) VALUES ('customers', 'DELETE', OLD.customer_id);
END;
UPDATE customers SET phone = '01711999999' WHERE customer_id = 1;
UPDATE customers SET phone = '01511000555' WHERE customer_id = 5;
DELETE FROM customers WHERE customer_id = 5;
SELECT log_id, action, row_id, detail, at IS NOT NULL AS has_time FROM audit_log;

বড় সিস্টেমে trigger-এর পাশাপাশি DBMS-এর নিজের audit ব্যবস্থা থাকে। PostgreSQL-এ pgaudit extension নির্দিষ্ট শ্রেণির স্টেটমেন্ট — DDL, role-এর বদল, লেখা, পড়া — সার্ভারের log-এ লেখে; সাথে log_connections দিয়ে প্রতিটি লগইন। log পাঠাতে হয় এমন জায়গায়, যেখানে ডেটাবেসের অ্যাডমিনও মুছতে পারেন না — নইলে log প্রমাণ হিসেবে দুর্বল।

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'ddl, role, write'      # টেবিল বদল, অধিকার বদল, সব লেখা
log_connections = on
log_disconnections = on

দ্বিতীয় প্রশ্ন — ফিরব কীভাবে — তার উত্তর backup. এটি শুধু ডিস্ক নষ্ট হওয়ার জন্য নয়, নিরাপত্তারও অংশ: কেউ ডেটা মুছে দিলে, ভুল UPDATE-এ হাজার সারি নষ্ট হলে, বা ransomware সার্ভারের ফাইল encrypt করে মুক্তিপণ চাইলে — ভালো backup-ই শেষ ভরসা। শর্ত তিনটি: অন্তত একটি কপি মূল সিস্টেম থেকে আলাদা আর মুছতে-না-পারা জায়গায় (যে অ্যাকাউন্ট ডেটাবেস চালায়, সে যেন backup মুছতে না পারে), backup নিজেও encrypt করা, আর নিয়মিত ফিরিয়ে এনে পরীক্ষা — কখনো restore না-করা backup আসলে একটি আশা মাত্র। নির্দিষ্ট মুহূর্তে ফেরার point-in-time recovery, replication আর তাদের সীমা বিস্তারিত পর্ব ৫২-এ।

এবার সব স্তর একসাথে। ধরুন একটি পুরোনো রিপোর্ট পাতায় কোনোভাবে স্ট্রিং জোড়া থেকে গেছে। স্তরগুলো থাকলে ক্ষতি কতদূর যায়, ধাপে ধাপে দেখুন:

৯ · Privacy, আইন আর test-এর জন্য masked ডেটা

নিরাপত্তা জিজ্ঞেস করে “কে পড়তে পারে”; privacy জিজ্ঞেস করে আরও আগের প্রশ্ন — “এই ডেটা আদৌ রাখা উচিত কি?” কোনো মানুষকে চেনা যায় এমন তথ্যকে বলে personal data — নাম, ফোন, NID, ঠিকানা, এমনকি অর্ডারের ইতিহাস। ইউরোপীয় ইউনিয়নের GDPR (২০১৬-এ গৃহীত, ২০১৮-এর মে থেকে প্রযোজ্য) এ বিষয়ে সবচেয়ে প্রভাবশালী আইন; তার মূলনীতিগুলো ডেটাবেস ডিজাইনে সরাসরি প্রভাব ফেলে:

• Data minimisation: শুধু যা দরকার, তাই সংগ্রহ। ডেলিভারির জন্য জন্মতারিখ লাগে না — কলামটিই রাখবেন না। যে ডেটা নেই, তা ফাঁসও হয় না।
• Purpose limitation: যে কাজের জন্য নেওয়া, সেই কাজেই ব্যবহার।
• Storage limitation (retention): নির্দিষ্ট সময় পরে মুছে ফেলা বা নাম-পরিচয়হীন করা। প্রতিটি টেবিলের জন্য একটি লেখা নিয়ম আর একটি নিয়মিত চলা কাজ।
• Integrity and confidentiality, accountability: উপযুক্ত নিরাপত্তা, আর প্রমাণ করতে পারা যে নিয়ম মানা হচ্ছে — এখানে audit log কাজে লাগে।

বাংলাদেশে ব্যক্তিগত তথ্য সুরক্ষা নিয়ে আলাদা আইনের খসড়া কয়েক বছর ধরে আলোচনায় ছিল, আর এর অবস্থা সাম্প্রতিক সময়ে বদলেছে বলে জানা যায়। কোনটি কার্যকর আর কোন ধারা আপনার প্রতিষ্ঠানে প্রযোজ্য — সরকারের অফিসিয়াল সূত্র থেকে সর্বশেষ অবস্থা অবশ্যই যাচাই করে নিন; ব্যাংক, টেলিকম বা স্বাস্থ্যের মতো খাতে নিয়ন্ত্রক সংস্থার আলাদা নির্দেশনাও থাকতে পারে।

Dev আর test-এর জন্য masked কপি

একটি খুব সাধারণ ফাঁস হয় নিরাপত্তার মূল দরজা দিয়ে নয়, পাশের দরজা দিয়ে: production-এর পুরো কপি কোনো ডেভেলপারের ল্যাপটপে, test সার্ভারে, বা বাইরের কোনো প্রতিষ্ঠানের হাতে। নিয়ম: test-এর ডেটা হবে masked — গঠন আর বৈশিষ্ট্য (শহর, তারিখের ধরন, NULL কোথায়) একই, কিন্তু মানুষ চেনা যায় না:

CREATE TABLE customers_test AS
SELECT customer_id,
       'Customer ' || customer_id AS name,
       city,
       CASE WHEN phone IS NULL THEN NULL
            ELSE substr(phone, 1, 3) || '*****' || substr(phone, -3) END AS phone,
       substr(joined_on, 1, 7) || '-01' AS joined_on
FROM customers;
SELECT * FROM customers_test;
-- আসল ফোন নম্বর কি কোনোটি চুইয়ে এসেছে?
SELECT COUNT(*) AS leaked FROM customers_test t JOIN customers c ON c.phone = t.phone;

শেষ একটি বাস্তব প্রশ্ন: গ্রাহক তাঁর তথ্য মুছতে বললেন, কিন্তু হিসাবের আইনে অর্ডারগুলো কয়েক বছর রাখতে হবে। উপায় হলো সারি না মুছে ব্যক্তিগত অংশটুকু মুছে দেওয়া:

UPDATE customers
SET name = 'Deleted customer #' || customer_id, phone = NULL, city = NULL
WHERE customer_id = 4;
SELECT c.customer_id, c.name, c.phone, COUNT(o.order_id) AS orders
FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id
WHERE c.customer_id = 4
GROUP BY c.customer_id;

১০ · AI-এর যুগে ডেটাবেস নিরাপত্তা

AI কোড-সহকারী মুহূর্তে ডেটাবেসের কোড লিখে দেয়, আর সেটি সাধারণত চলে। কিন্তু নিরাপত্তার ভুল চলার সময় দেখা যায় না — দেখা যায় দুর্ঘটনার পরে। AI-এর লেখা কোডে বারবার যা দেখা যায়:

AI-এর দেওয়া ডেটাবেস কোড চালু করার আগে — চেকলিস্ট

• প্রতিটি কোয়েরিতে মান placeholder দিয়ে যাচ্ছে; identifier এসেছে allow-list থেকে
• ', খালি লেখা, খুব লম্বা লেখা আর বাংলা নাম দিয়ে নমুনা ডেটায় চালিয়ে দেখেছি
• অ্যাপের ডেটাবেস অ্যাকাউন্টের অধিকারের তালিকা দেখেছি — DDL নেই, দরকারের বাইরে টেবিল নেই
• কোডে বা Git-এ কোনো password, key বা connection string নেই; TLS যাচাই চালু
• password-এর জন্য argon2/bcrypt, আর স্পর্শকাতর কলাম log-এ বা ত্রুটি-বার্তায় যাচ্ছে না
• নমুনা বা test ডেটায় কোনো আসল মানুষের তথ্য নেই