নকশায় নিরাপত্তা — authentication, OAuth 2.0-OIDC, encryption আর secrets

১ · নিরাপত্তা একটি নকশার গুণ — CIA triad আর threat modeling

একটি ব্যাংকের শাখার কথা ভাবুন। দরজায় গার্ড, কাউন্টারে ক্যাশিয়ার পরিচয়পত্র দেখেন, ভল্টের চাবি ম্যানেজারের কাছে, আর প্রতিটি লেনদেন খাতায় ওঠে। ভবন তৈরির পরে “একটা ভল্ট বসিয়ে দেব” চলে না — ভল্টের দেয়াল আর টাকার পথ শুরুর নকশাতেই ঠিক হয়। সফটওয়্যারেও তাই: কোন তথ্য কোথায় থাকবে, কে কোন পথে ঢুকবে, কোন সার্ভিস কাকে বিশ্বাস করবে — এগুলো architecture-এর সিদ্ধান্ত।

নিরাপত্তা আসলে তিনটি জিনিস রক্ষা করে, যাদের একসাথে বলে CIA triad:

সাথে আরও দুটি গুণ প্রায়ই লাগে: authenticity (যে দাবি করছে, সে-ই কি না) আর non-repudiation (করা কাজ পরে অস্বীকার করা যায় না)। CIA আর নেটওয়ার্কের দিক থেকে AAA-র বিস্তারিত আলোচনা Computer Networks কোর্সের নেটওয়ার্ক নিরাপত্তার ভিত্তি-তে আছে; এখানে আমরা দেখব নকশার টেবিলে এগুলো কীভাবে সিদ্ধান্তে বদলায়।

Threat modeling — চারটি প্রশ্ন

Threat modeling মানে নকশা থাকতেই কাঠামো মেনে ঝুঁকি খোঁজা। Adam Shostack-এর জনপ্রিয় করা কাঠামোয় চারটি প্রশ্ন: (১) আমরা কী বানাচ্ছি? (২) কী ভুল হতে পারে? (৩) তা নিয়ে কী করব? (৪) কাজটি কি ঠিকমতো হলো? প্রথম প্রশ্নের উত্তর হলো একটি data-flow diagram (DFD): কোন প্রক্রিয়া, কোন data store, কোন বাইরের পক্ষ, আর তাদের মাঝে কোন তীরে ডেটা চলে। তারপর আঁকুন trust boundary — যেখানে বিশ্বাসের মাত্রা বদলায়: ইন্টারনেট থেকে আপনার edge, edge থেকে ভেতরের নেটওয়ার্ক, একটি সার্ভিস থেকে database, এক tenant থেকে আরেক tenant. ঝুঁকি জন্মায় প্রায় সবসময় এই সীমানাগুলোতে।

দ্বিতীয় প্রশ্নের জন্য একটি চেকলিস্ট STRIDE — ১৯৯৯ সালের দিকে Microsoft-এ Loren Kohnfelder আর Praerit Garg-এর প্রস্তাব বলে পরিচিত। ছয়টি অক্ষর ছয় রকম ঝুঁকি, আর প্রতিটির বিপরীতে একটি রক্ষার গুণ। নিচে একটি কাল্পনিক অনলাইন বাজারের ছোট DFD — ব্রাউজার, gateway, Orders service আর database — ধরে ছয় অক্ষর একে একে প্রয়োগ করুন:

প্রতিটি অক্ষরের উত্তর একটি নকশার সিদ্ধান্ত — কোথায় যাচাই, কোথায় log, কোন চাবি কোথায়। STRIDE একমাত্র কাঠামো নয়; আসল কথা হলো প্রতিটি নতুন feature বা নতুন trust boundary এলেই প্রশ্নগুলো আবার করা।

২ · নকশার নীতি — defence in depth, least privilege আর zero trust

১৯৭৫ সালে Jerome Saltzer আর Michael Schroeder তাঁদের বিখ্যাত প্রবন্ধে কয়েকটি নকশা-নীতি লেখেন, যা আজও প্রায় হুবহু খাটে। তিনটি এই পর্বের মেরুদণ্ড:

• Defence in depth — স্তরে স্তরে প্রতিরক্ষা। একটি স্তর ভাঙলেও পরেরটি থামাবে। WAF একটি ক্ষতিকর অনুরোধ না চিনলেও gateway token যাচাই করবে, সার্ভিস ownership দেখবে, database-এর user-এর অধিকার সীমিত, আর ডিস্কের ডেটা এনক্রিপ্ট করা।
• Least privilege — যতটুকু দরকার, ততটুকুই। Reports service শুধু পড়তে পারে, লিখতে নয়; support কর্মী শুধু নিজের অঞ্চলের অর্ডার; CI pipeline শুধু একটি registry-তে push. ভুল বা চুরি হলেও ক্ষতির পরিধি — blast radius — ছোট থাকে।
• Complete mediation — প্রতিটি প্রবেশে যাচাই। আগের একবারের যাচাইয়ের ফল ধরে না রেখে প্রতিটি অনুরোধে অনুমতি দেখা। এরই আধুনিক রূপ zero trust.

পুরোনো নকশা ছিল দুর্গের মতো: বাইরে শক্ত দেয়াল (firewall, VPN), ভেতরে সবাই বিশ্বস্ত — একটি চুরি যাওয়া ল্যাপটপ বা দুর্বল সার্ভিস দিয়ে ঢুকলেই সব খোলা। Zero trust উল্টো কথা বলে: নেটওয়ার্কের কোথায় আছেন, তা দিয়ে বিশ্বাস নয়; প্রতিটি অনুরোধে পরিচয় (মানুষ বা সার্ভিস), ডিভাইসের অবস্থা আর অনুমতি যাচাই, আর ভেতরের traffic-ও এনক্রিপ্ট। মার্কিন NIST-এর SP 800-207 (২০২০) এই ধারণাকে একটি architecture হিসেবে লিখেছে; তবে zero trust কোনো একটি পণ্য নয়, ধীরে ধীরে নেওয়া একটি নকশা-দিক। Segmentation আর VPN-এর দিক থেকে আলোচনা CN কোর্সের segmentation আর zero trust অংশে।

Edge আর gateway প্রথম ছাঁকনি — তাদের কাজের ভাগ পর্ব ১১-এ। কিন্তু Orders service gateway-কে অন্ধভাবে বিশ্বাস করে না: কে ডাকছে তা mTLS-এর certificate-এ দেখে, আর ব্যবহারকারী এই অর্ডারের মালিক কি না নিজে মেলায়। Database-এর user শুধু দরকারি কাজ পারে; চাবি থাকে আলাদা ঘরে, আর তার প্রতিটি ব্যবহার audit log-এ ওঠে।

৩ · Authentication — password ঠিকভাবে রাখা, MFA আর passkey

Authentication প্রমাণ করে “আপনি কে”; authorization ঠিক করে “আপনি এটি করতে পারেন কি না”। HTTP-তে প্রথমটি ব্যর্থ হলে 401, দ্বিতীয়টি হলে 403 — পার্থক্যটি পর্ব ৮-এ দেখেছেন। পরিচয়ের প্রমাণ তিন রকম: যা আপনি জানেন (password), যা আপনার কাছে আছে (ফোন, security key), আর যা আপনি (আঙুলের ছাপ, মুখ)।

Password রাখার নিয়ম — কেন “ধীর” hash

সার্ভার কখনো password নিজে রাখবে না, এমনকি এনক্রিপ্ট করেও নয় — কারণ চাবি থাকলে উল্টো খোলা যায়। রাখবে একটি একমুখী password hash. কিন্তু SHA-256-এর মতো সাধারণ hash এখানে ভুল হাতিয়ার: এগুলো দ্রুত হওয়ার জন্যই বানানো, আর database চুরি হলে আক্রমণকারী একটি GPU-তে সেকেন্ডে বিলিয়ন অনুমান যাচাই করতে পারেন। তাই password-এর জন্য বানানো ইচ্ছাকৃত ধীর ফাংশন — Argon2id, bcrypt বা scrypt — যাদের কাজের পরিমাণ (work factor) আর Argon2id-এ memory-র পরিমাণ বাড়ানো যায়। Memory-নির্ভর বলে GPU-তে এদের সমান্তরালে চালানো অনেক কঠিন।

সাথে প্রতিটি ব্যবহারকারীর জন্য আলাদা এলোমেলো salt, hash-এর পাশে খোলাখুলি রাখা। Salt না থাকলে একই password-এর hash সবার জন্য এক — একটি অনুমান একসাথে লাখো মানুষের সাথে মেলানো যায়, আর আগে থেকে বানানো টেবিলও চলে। চাইলে একটি pepper-ও: সবার জন্য একটি গোপন চাবি, যা database-এ নয়, vault বা HSM-এ থাকে। লেখার সময়ে OWASP-এর Password Storage Cheat Sheet প্রথম পছন্দ হিসেবে Argon2id সুপারিশ করে (ন্যূনতম উদাহরণ হিসেবে প্রায় ১৯ MiB memory, ২ বার পুনরাবৃত্তি); না পেলে scrypt, পুরোনো ব্যবস্থায় bcrypt (cost অন্তত ১০; bcrypt input-এর প্রথম ৭২ byte-ই শুধু ব্যবহার করে, বাকিটা বাদ পড়ে), আর FIPS-এর বাধ্যবাধকতা থাকলে PBKDF2 —সংখ্যাগুলো সময়ের সাথে বদলায়, তাই নিজের সার্ভারে মেপে বেছে নিন। Hash-এর সাথে parameter-ও লেখা থাকে, তাই পরে শক্ত parameter-এ সরলে পরের login-এ নতুন করে hash করা যায়।

কত ধীর যথেষ্ট? নিচের হিসাব শুধু পাটিগণিত: প্রতিটি সম্ভাব্য password একবার করে চেষ্টা করতে কত সময় লাগে, ধরা যাক একটি GPU আর একজন ব্যবহারকারীর salt দেওয়া hash. সব হার ধরা যাক — মাত্রা বোঝার জন্য, নির্দিষ্ট হার্ডওয়্যারের মাপ নয়:

// Password storage cost model: pure arithmetic, no cracking code. Every rate is an ASSUMPTION (ধরা যাক).
// guesses/s = one attacker GPU testing candidates against ONE stolen, salted hash
const hashes = [  // name, guesses per second (assumed), server ms per login check (assumed)
  ["SHA-256 x1", 1e10, 0.001],             // fast hash: the WRONG tool for passwords
  ["bcrypt-10", 1e4, 60],
  ["bcrypt-12", 2.5e3, 240],               // +1 cost = 2x work, so cost 12 = 4x cost 10
  ["Argon2id-19M", 1e3, 50],               // memory-hard: GPUs gain much less
];
const spaces = [  // label, how many possible passwords (worst case: attacker tries all)
  ["8 lowercase", 26 ** 8], ["8 a-zA-Z0-9", 62 ** 8],
  ["12 a-zA-Z0-9", 62 ** 12], ["4 random words", 7776 ** 4],
];
function human(sec) {
  for (const [u, s] of [["yr", 31557600], ["day", 86400], ["hr", 3600], ["min", 60], ["s", 1]])
    if (sec >= s) { const v = sec / s;
      return (v >= 1e5 ? v.toExponential(1) : v.toFixed(v < 10 ? 1 : 0)) + " " + u; }
  return sec.toExponential(1) + " s";
}
console.log("Time to try the WHOLE space (1 GPU, 1 user's salted hash)");
console.log("space".padEnd(15) + "size".padStart(9) + hashes.map(h => h[0].padStart(13)).join(""));
for (const [label, n] of spaces)
  console.log(label.padEnd(15) + n.toExponential(1).padStart(9) + hashes.map(h => human(n / h[1]).padStart(13)).join(""));
console.log("\nServer side: login checks per second on ONE CPU core");
for (const [name, , ms] of hashes) console.log("  " + name.padEnd(14) + String(Math.floor(1000 / ms)).padStart(8) + " /s");
const users = 1e6;   // a stolen table of one million users
console.log("\nNo salt    : each guess is compared with all " + users.toExponential(0) + " hashes at once." +
  "\nUnique salt: the same work must be repeated for every user.");

Time to try the WHOLE space (1 GPU, 1 user's salted hash)
space               size   SHA-256 x1    bcrypt-10    bcrypt-12 Argon2id-19M
8 lowercase      2.1e+11         21 s      242 day       2.6 yr       6.6 yr
8 a-zA-Z0-9      2.2e+14       6.1 hr       692 yr      2768 yr      6919 yr
12 a-zA-Z0-9     3.2e+21     10223 yr   1.0e+10 yr   4.1e+10 yr   1.0e+11 yr
4 random words   3.7e+15      4.2 day     11586 yr     46343 yr    1.2e+5 yr

Server side: login checks per second on ONE CPU core
  SHA-256 x1     1000000 /s
  bcrypt-10           16 /s
  bcrypt-12            4 /s
  Argon2id-19M        20 /s

No salt    : each guess is compared with all 1e+6 hashes at once.
Unique salt: the same work must be repeated for every user.

Password-এর বাইরে — MFA আর passkey

Password যত ভালোভাবেই রাখুন, ব্যবহারকারী একই password অন্য সাইটে ব্যবহার করলে, বা প্রতারণামূলক পাতায় লিখে ফেললে, তা হাতছাড়া হয়। তাই দ্বিতীয় প্রমাণ — MFA (multi-factor authentication): SMS-এর OTP (সহজ, কিন্তু SIM বদলের প্রতারণায় দুর্বল), authenticator অ্যাপের TOTP (RFC 6238), বা hardware security key. NIST SP 800-63B-এর মতো নির্দেশিকা password-এর ক্ষেত্রেও কয়েকটি নকশার নিয়ম দেয়: জটিলতার জোরাজুরির চেয়ে দৈর্ঘ্য, নিয়ম করে জোর করে বদলানো নয়, আর ফাঁস হওয়া password-এর তালিকার সাথে মিলিয়ে দেখা।

সবচেয়ে শক্ত পথ passkey, যা W3C-এর WebAuthn মান (Level 1 সুপারিশ ২০১৯) আর FIDO2-এর ওপর দাঁড়িয়ে। ধারণাটি সরল: নিবন্ধনের সময় ডিভাইস একটি চাবি-জোড়া বানায়; private key ডিভাইসেই থাকে (আঙুলের ছাপ বা PIN দিয়ে খোলে), সার্ভার পায় শুধু public key. Login-এ সার্ভার একটি এলোমেলো challenge পাঠায়, ডিভাইস সই করে, সার্ভার মেলায়। সার্ভারে চুরি করার মতো গোপন কিছু নেই, আর স্বাক্ষর ওয়েবসাইটের domain-এ বাঁধা — নকল পাতায় কাজই করে না; তাই একে phishing-প্রতিরোধী বলা হয়। ফোন হারালে account ফেরানোর পথ (recovery) প্রায়ই সবচেয়ে দুর্বল জায়গা — সেটিও সমান যত্নে নকশা করুন। OS-এর দিক থেকে TOTP আর passkey-র বিস্তার OS কোর্সের password, MFA আর passkey অংশে।

৪ · Session বনাম token, আর JWT যাচাইয়ের নিয়ম

Login সফল হলে পরের প্রতিটি অনুরোধে আবার password চাওয়া যায় না; তাই সার্ভার একটি প্রমাণপত্র দেয়। দুই পথ — ব্রাউজারে একটি এলোমেলো session ID (তথ্য সার্ভারের store-এ), অথবা স্বাক্ষর করা JWT (তথ্য token-এর ভেতরে)। Cookie-র HttpOnly, Secure, SameSite flag, JWT-এর গঠন, HMAC বনাম asymmetric স্বাক্ষর আর logout-এর revocation সমস্যা পর্ব ১৫-এ বিস্তারিত — সেখানে নিজে HMAC-SHA256 লিখে test vector-ও মেলানো হয়েছে। এখানে আমরা নিরাপত্তার নকশার দিক থেকে একটি প্রশ্নে মন দেব: বহু সার্ভিসের সিস্টেমে একটি token গ্রহণের আগে যাচাইকারী ঠিক কী কী দেখবে?

নিচের কোডে একটি খেলনা token — স্বাক্ষরের জায়গায় FNV-1a দিয়ে বানানো একটি “MAC”, যা আসল cryptography নয়, শুধু যাচাইয়ের ক্রম দেখানোর জন্য। আসল কাজে পরীক্ষিত library আর KMS বা vault-এ রাখা চাবি:

// Toy signed token to show the CHECKS a verifier must make. The "MAC" below is FNV-1a: NOT real crypto.
// Real systems: a tested JWT library, HS256/ES256 keys from a KMS or vault (see lesson 15 for real HMAC).
function fnv(s) { let h = 0x811c9dc5; for (const ch of s) { h ^= ch.charCodeAt(0); h = Math.imul(h, 16777619) >>> 0; } return h; }
const toyMac = (key, msg) => fnv(key + fnv(key + msg).toString(36)).toString(36);   // NOT secure
const b64 = o => btoa(JSON.stringify(o)), unb64 = s => JSON.parse(atob(s));
const KEYS = { "k-2026-10": "demo-key-A" };         // kid -> key; the verifier owns this list
const sign = (h, p, key) => { const hp = b64(h) + "." + b64(p); return hp + "." + toyMac(key, hp); };
function verify(tok, now, expect) {
  const [h64, p64, sig] = tok.split("."), h = unb64(h64), p = unb64(p64);
  if (h.alg !== "HS256") return "REJECT alg " + h.alg + " not on allow-list";
  const key = KEYS[h.kid]; if (!key) return "REJECT unknown kid";
  if (toyMac(key, h64 + "." + p64) !== sig) return "REJECT bad signature";
  if (p.iss !== expect.iss) return "REJECT wrong issuer " + p.iss;
  if (p.aud !== expect.aud) return "REJECT token is for " + p.aud + ", not " + expect.aud;
  const LEEWAY = 60;                                  // seconds of allowed clock skew
  if (now > p.exp + LEEWAY) return "REJECT expired " + (now - p.exp) + " s ago";
  if (now + LEEWAY < p.nbf) return "REJECT not valid yet";
  return "ACCEPT sub=" + p.sub + " scope=" + p.scope;
}
const T0 = 1793000000, H = { alg: "HS256", kid: "k-2026-10" };
const base = { iss: "https://id.example", sub: "u-1042", aud: "orders", scope: "orders.read", nbf: T0, exp: T0 + 600 };
const good = sign(H, base, "demo-key-A");
const [gh, , gs] = good.split(".");
const cases = [
  ["valid, 2 min later", good, T0 + 120],
  ["payload edited: scope", gh + "." + b64({ ...base, scope: "orders.refund" }) + "." + gs, T0 + 120],
  ["header says alg none", b64({ alg: "none", kid: "k-2026-10" }) + "." + good.split(".")[1] + ".", T0 + 120],
  ["token for payments", sign(H, { ...base, aud: "payments" }, "demo-key-A"), T0 + 120],
  ["retired key k-2026-04", sign({ alg: "HS256", kid: "k-2026-04" }, base, "old-key"), T0 + 120],
  ["30 s past exp (skew)", good, T0 + 630],
  ["90 s past exp", good, T0 + 690],
];
for (const [label, tok, now] of cases) console.log(label.padEnd(23) + verify(tok, now, { iss: "https://id.example", aud: "orders" }));

valid, 2 min later     ACCEPT sub=u-1042 scope=orders.read
payload edited: scope  REJECT bad signature
header says alg none   REJECT alg none not on allow-list
token for payments     REJECT token is for payments, not orders
retired key k-2026-04  REJECT unknown kid
30 s past exp (skew)   ACCEPT sub=u-1042 scope=orders.read
90 s past exp          REJECT expired 90 s ago

৫ · Authorization — RBAC, ABAC, ReBAC আর প্রতিটি সার্ভিসে যাচাই

ব্যাংকের কাউন্টারের কথা আবার ভাবুন। ক্যাশিয়ার পরিচয়পত্র দেখে authentication সারলেন। তারপর প্রশ্ন: এই অ্যাকাউন্ট থেকে টাকা তোলার অধিকার কি আপনার আছে? আপনি গ্রাহক — এটুকু যথেষ্ট নয়; অ্যাকাউন্টটি আপনারই হতে হবে, আর বড় অঙ্কে ম্যানেজারের সই লাগবে। Authorization-এর তিনটি প্রধান মডেল এই তিন রকম প্রশ্নের মতো:

ReBAC-এর সবচেয়ে উদ্ধৃত উদাহরণ Google-এর Zanzibar paper (USENIX ATC, ২০১৯) — প্রকাশিত বর্ণনা অনুযায়ী একটি কেন্দ্রীয় ব্যবস্থা, যা “user U, document D-এর viewer” ধরনের সম্পর্ক জমা রাখে আর বহু পণ্যের অনুমতি-প্রশ্নের উত্তর দেয়। SpiceDB আর OpenFGA-র মতো open-source প্রকল্প নিজেদের Zanzibar-অনুপ্রাণিত বলে পরিচয় দেয়। নিয়মকে কোড থেকে আলাদা করে “policy as code” লেখার জন্য Open Policy Agent-এর মতো policy engine-ও প্রচলিত। মডেল যেটিই হোক, বাস্তবে প্রায় সবসময় মিশ্রণ: role দিয়ে মোটা ভাগ, তারপর attribute আর ownership দিয়ে সূক্ষ্ম যাচাই।

সবচেয়ে বড় ফাঁক — বস্তু-স্তরের যাচাই না থাকা

রিনা নিজের অর্ডার দেখছেন: GET /v1/orders/o-101. URL-এর শেষটা বদলে o-202 লিখলে কী হয়? সার্ভিস যদি শুধু দেখে “token বৈধ, role customer, customer অর্ডার পড়তে পারে” — তাহলে কারিমের অর্ডার রিনার পর্দায়। একে বলে BOLA (broken object level authorization), পুরোনো নাম IDOR. OWASP API Security Top 10-এর ২০১৯ আর ২০২৩ দুই সংস্করণেই এটি এক নম্বরে। প্রতিকার একটাই নিয়ম — object-level authorization: প্রতিটি অনুরোধে, প্রতিটি বস্তুর জন্য, ডেটা ফেরত দেওয়ার আগে সার্ভিস নিজে মেলাবে “এই বস্তুটি কি এই ব্যবহারকারীর (বা তাঁর tenant-এর)?” ID এলোমেলো (UUID) করা ভালো অভ্যাস, কিন্তু অনুমান কঠিন করা অনুমতির বিকল্প নয়।

নিচে একই সাতটি অনুরোধ দুই নিয়মে: শুধু RBAC, আর RBAC-এর পরে ABAC + ownership. ডিফল্ট উত্তর “না” (deny by default):

// RBAC vs ABAC (+ ownership) on the same requests — a fictional shop; deny by default
const users = { rina: { role: "customer" }, karim: { role: "customer" },
  sumi: { role: "support", region: "dhaka" }, admin1: { role: "admin" } };
const orders = { "o-101": { owner: "rina", region: "dhaka", amount: 1200 },
  "o-202": { owner: "karim", region: "ctg", amount: 8000 } };
const ROLE_PERMS = { customer: ["order:read"], support: ["order:read", "order:refund"], admin: ["*"] };
function rbac(u, action) {                         // only asks: does the ROLE have this action?
  const p = ROLE_PERMS[users[u].role] || [];
  return p.includes("*") || p.includes(action) ? ["ALLOW", "role " + users[u].role] : ["DENY", "role lacks " + action];
}
function abac(u, action, id, hour) {                // role AND attributes of user, object and context
  const [r, why] = rbac(u, action); if (r === "DENY") return [r, why];
  const usr = users[u], o = orders[id];
  if (!o) return ["DENY", "no such order"];
  if (usr.role === "customer" && o.owner !== u) return ["DENY", "not the owner (BOLA caught)"];
  if (usr.role === "support") {
    if (usr.region !== o.region) return ["DENY", "region " + o.region + " is not " + usr.region];
    if (hour < 9 || hour >= 18) return ["DENY", "outside shift 09-18"];
    if (action === "order:refund" && o.amount > 5000) return ["DENY", "refund > 5000 needs approval"];
  }
  return ["ALLOW", "all conditions met"];
}
const reqs = [["rina", "order:read", "o-101", 11], ["rina", "order:read", "o-202", 11],
  ["sumi", "order:refund", "o-101", 14], ["sumi", "order:refund", "o-101", 22],
  ["sumi", "order:refund", "o-202", 14], ["karim", "order:refund", "o-202", 10],
  ["admin1", "order:refund", "o-202", 3]];
console.log("user   action        order  hour  RBAC   ABAC+owner  reason");
for (const [u, a, id, h] of reqs) {
  const r = rbac(u, a)[0], [x, why] = abac(u, a, id, h);
  console.log(u.padEnd(7) + a.padEnd(14) + id.padEnd(7) + String(h).padStart(4) + "  " +
    r.padEnd(7) + x.padEnd(12) + why + (r !== x ? "   <-- differs" : ""));
}

user   action        order  hour  RBAC   ABAC+owner  reason
rina   order:read    o-101    11  ALLOW  ALLOW       all conditions met
rina   order:read    o-202    11  ALLOW  DENY        not the owner (BOLA caught)   <-- differs
sumi   order:refund  o-101    14  ALLOW  ALLOW       all conditions met
sumi   order:refund  o-101    22  ALLOW  DENY        outside shift 09-18   <-- differs
sumi   order:refund  o-202    14  ALLOW  DENY        region ctg is not dhaka   <-- differs
karim  order:refund  o-202    10  DENY   DENY        role lacks order:refund
admin1 order:refund  o-202     3  ALLOW  ALLOW       all conditions met

৬ · OAuth 2.0 আর OpenID Connect — কে কাকে কী অনুমতি দেয়

একটি কাল্পনিক হিসাবের অ্যাপ আপনার অনলাইন বাজারের অর্ডার-তালিকা পড়তে চায়। পুরোনো সমাধান ছিল অ্যাপকে নিজের password দেওয়া — তাতে অ্যাপ সব পারে, চিরকাল। OAuth 2.0 (RFC 6749, ২০১২) এই সমস্যার উত্তর: password নয়, একটি সীমিত, মেয়াদি, বাতিলযোগ্য অনুমতি — access token. বাড়ির চাবির বদলে “শুধু গ্যারেজ, শুধু আজ” লেখা একটি পাস।

চারটি ভূমিকা: resource owner (আপনি), client (হিসাবের অ্যাপ), authorization server (login আর token দেয়), আর resource server (যেমন Orders API, যেখানে ডেটা থাকে)। অনুমতির পরিধি লেখা থাকে scope-এ, যেমন orders.read. খেয়াল করুন, OAuth নিজে বলে না “ব্যবহারকারী কে” — সেটি বলে তার ওপরের স্তর OpenID Connect (OIDC, ২০১৪), যা যোগ করে একটি ID token: client-এর জন্য লেখা একটি JWT, যাতে sub, iss, aud (= client-এর ID), exp আর nonce.

Authorization code flow + PKCE

ব্রাউজার আর মোবাইল অ্যাপের জন্য আজকের মানক পথ authorization code flow, সাথে PKCE (RFC 7636, ২০১৫)। PKCE-র মূল ভাবনা: অ্যাপ শুরুতেই একটি গোপন এলোমেলো স্ট্রিং বানায় আর authorization server-কে দেখায় শুধু তার hash. পরে code ভাঙিয়ে token নেওয়ার সময় আসল স্ট্রিংটি দেখাতে হয়। পথে কেউ code দেখে ফেললেও স্ট্রিং ছাড়া তা অকেজো। নিচের verifier আর challenge RFC 7636-এর Appendix B-র প্রকাশিত উদাহরণ থেকে, code-টি RFC 6749-এর উদাহরণ থেকে, ছোট করে লেখা:

কোন flow কোথায়

• ব্রাউজারের single-page app আর মোবাইল অ্যাপ: authorization code + PKCE. এদের ভেতরে গোপন কিছু রাখা যায় না, তাই এরা “public client”. আগে চলত implicit flow — access token সরাসরি URL-এ ফেরত, ইতিহাস আর অন্য script-এর নাগালে। OAuth 2.0 Security Best Current Practice (লেখার সময়ে RFC 9700, ২০২৫) implicit flow আর password-দেওয়া grant ব্যবহার না করার পরামর্শ দেয়, আর সব client-এ PKCE-র সুপারিশ করে; খসড়া OAuth 2.1-এও এগুলো বাদ।
• সার্ভারে চলা ওয়েব অ্যাপ (confidential client): একই code flow, সাথে client-এর নিজের secret বা আরও ভালো, private key-এ সই করা পরিচয়; তবু PKCE.
• সার্ভিস থেকে সার্ভিসে, কোনো মানুষ নেই: client credentials grant — রাতের batch job নিজের পরিচয়ে token নেয়, নির্দিষ্ট scope আর aud-সহ। একই data center-এর ভেতরে অনেক সময় service mesh-এর mTLS পরিচয়ই যথেষ্ট (পর্ব ৪৭), আর ব্যবহারকারীর হয়ে ভেতরে কাজ চালাতে হলে token exchange-এর মতো পদ্ধতি।

৭ · Encryption — পথে, সংরক্ষণে আর envelope encryption

পথে (in transit): বাইরের প্রতিটি সংযোগ TLS-এ, আজ TLS 1.3 (RFC 8446, ২০১৮) পছন্দ — handshake, certificate আর বিশ্বাসের শিকল CN কোর্সের TLS 1.3 handshake আর বাস্তবে HTTPS অংশে। Edge-এ TLS শেষ হলে edge থেকে origin পর্যন্ত নতুন TLS, আর ভেতরে সার্ভিসে সার্ভিসে mTLS — দুই পক্ষই certificate দেখায়, ফলে সংযোগ এনক্রিপ্ট আর “কে ডাকছে” প্রমাণিত। হাজারো সার্ভিসের certificate হাতে বদলানো অসম্ভব, তাই service mesh বা SPIFFE-ধাঁচের workload পরিচয়-ব্যবস্থা ঘণ্টা বা দিনের মেয়াদি certificate নিজে থেকে ঘোরায়।

সংরক্ষণে (at rest): ডিস্ক, backup আর object store-এর ডেটা এনক্রিপ্ট। এটি ঠেকায় হারানো ডিস্ক, ফেলে দেওয়া backup বা ভুলে প্রকাশ্য snapshot — কিন্তু চলমান অ্যাপের BOLA নয়, কারণ অ্যাপ খোলা ডেটাই দেখে। তাই এটি অনুমতি-যাচাইয়ের বিকল্প নয়, আরেকটি স্তর।

Envelope encryption — খামের ভেতরে খাম

সব ডেটা একটি চাবিতে এনক্রিপ্ট করলে দুই সমস্যা: চাবি ফাঁস হলে সব খোলা, আর চাবি বদলাতে হলে টেরাবাইট ডেটা নতুন করে এনক্রিপ্ট। Envelope encryption এর সমাধান — দুই স্তরের চাবি। প্রতিটি ফাইল বা সারির জন্য একটি নতুন DEK (data encryption key), যা দিয়ে ডেটা স্থানীয়ভাবে AES-GCM-এর মতো authenticated encryption-এ বন্ধ হয়। তারপর DEK-কেই মোড়ানো (wrap) হয় একটি KEK (key encryption key) দিয়ে, যা কখনো KMS ছেড়ে বেরোয় না — প্রায়ই ভেতরে একটি HSM. ব্যাংকের লকারের মতো: আপনার বাক্সের চাবি আপনার কাছে, কিন্তু ভল্টের দরজা খোলে শুধু ম্যানেজারের চাবিতে, আর প্রতিবার খাতায় সই।

এবার key rotation-এর হিসাব। ৫,০০০টি ফাইল, আকার ১ KB থেকে ১৬ MB-এর মধ্যে এলোমেলো (seed নির্দিষ্ট); KEK v1 থেকে v2-তে বদলাই। “Encrypt” এখানে খেলনা XOR — আসল cryptography নয়, শুধু কোন চাবি কাকে মোড়ায় তার হিসাব:

// Envelope encryption key hierarchy — a SIMULATION. "wrap"/"encrypt" are toy XOR, NOT real crypto.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rand = mulberry32(52), N = 5000, WRAPPED = 64;           // ধরা যাক: wrapped DEK ~64 bytes
const toy = (key, x) => (x ^ key) >>> 0;                         // XOR twice = original (toy only!)
const kms = { v1: 0x5eed0001 }; let active = "v1", kmsCalls = 0;  // KEK never leaves the "KMS"
const kmsWrap = dek => { kmsCalls++; return { kek: active, w: toy(kms[active], dek) }; };
const kmsUnwrap = e => { kmsCalls++; return toy(kms[e.kek], e.w); };
const objects = [];
for (let i = 0; i < N; i++) {                                    // write path: fresh DEK per object
  const dek = Math.floor(rand() * 2 ** 32) >>> 0, size = Math.round(2 ** (10 + rand() * 14));  // 1 KB..16 MB
  objects.push({ size, check: toy(dek, i), env: kmsWrap(dek) });  // plaintext DEK is then forgotten
}
const dataBytes = objects.reduce((s, o) => s + o.size, 0);
const gb = b => (b / 2 ** 30).toFixed(2) + " GiB", mb = b => (b / 2 ** 20).toFixed(2) + " MiB";
console.log(N + " objects, data " + gb(dataBytes) + ", KMS calls for writes: " + kmsCalls);
kms.v2 = 0x5eed0002; active = "v2"; kmsCalls = 0;               // rotate the KEK
for (const o of objects) o.env = kmsWrap(kmsUnwrap(o.env));       // re-wrap every DEK, data untouched
console.log("Rotate KEK v1 -> v2: re-wrapped " + N + " DEKs = " + mb(N * WRAPPED) + ", KMS calls " + kmsCalls);
console.log("  versus re-encrypting all data: " + gb(dataBytes) + "  (" +
  Math.round(dataBytes / (N * WRAPPED)) + "x more bytes)");
const ok = objects.every((o, i) => toy(kmsUnwrap(o.env), o.check) === i);
console.log("All objects still decrypt after rotation: " + ok + "; old KEK v1 still needed: " +
  objects.some(o => o.env.kek === "v1"));
// blast radius: one DEK leaks (say, from a crash dump) -> only the object it encrypted is exposed
const leak = objects[7].size;                                    // object #7's DEK leaks
console.log("One leaked DEK exposes 1 object, " + (leak / 1024).toFixed(0) + " KiB = " +
  (100 * leak / dataBytes).toFixed(3) + "% of the data; the other " + (N - 1) + " stay sealed");

5000 objects, data 8.18 GiB, KMS calls for writes: 5000
Rotate KEK v1 -> v2: re-wrapped 5000 DEKs = 0.31 MiB, KMS calls 10000
  versus re-encrypting all data: 8.18 GiB  (27454x more bytes)
All objects still decrypt after rotation: true; old KEK v1 still needed: false
One leaked DEK exposes 1 object, 1765 KiB = 0.021% of the data; the other 4999 stay sealed

৮ · Secrets, ইনপুট, tenant আলাদা রাখা, audit আর privacy

Secrets — কোডে নয়, image-এ নয়, log-এ নয়

Database-এর password, API key, signing key — এগুলো secret. সবচেয়ে পরিচিত ভুল এদের কোডে, Git-এ, Docker image-এ বা খোলা config-এ রাখা; Git-এর ইতিহাস থেকে মোছাও কঠিন। নিয়মগুলো:

• এক জায়গায়, পাহারায়: একটি secrets manager (Vault-ধাঁচের বা cloud-এর), যেখানে কে কোনটি পড়বে তা নীতিতে লেখা আর প্রতিটি পড়া log হয়; অ্যাপ নিজের workload পরিচয় দেখিয়ে secret আনে।
• স্বল্পায়ু: short-lived credential — কিছু ব্যবস্থা প্রতিটি অ্যাপ-কপির জন্য আলাদা, এক ঘণ্টার database user বানিয়ে পরে নিজে মুছে দেয়; ফাঁস হলেও জানালা ছোট।
• ঘোরানো যায় এমন নকশা: পুরোনো আর নতুন দুটি secret একসাথে বৈধ থাকবে, যাতে rotation-এ downtime না হয় — JWT-এর kid-এর মতোই।
• Environment variable-ও সাবধানে: crash report বা env-এর dump-এ এগুলো বেরিয়ে আসে। Log-এ Authorization header, cookie আর password মাস্ক করা নিয়ম (পর্ব ৫০); CI pipeline-এর secret আর build-এর শিকল (supply chain) পর্ব ৫৩-এ।

ইনপুট যাচাই আর আউটপুট encoding — দুটি নকশার নিয়ম

Input validation মানে trust boundary-তেই schema মেলানো: ধরন, দৈর্ঘ্য, পরিসর, allow-list — “পরিমাণ ১ থেকে ১০০-এর পূর্ণসংখ্যা”। কিন্তু একা যথেষ্ট নয়, কারণ বৈধ নামেও (O'Brien) বিশেষ চিহ্ন থাকে। দ্বিতীয় নিয়ম: ডেটা কখনো কোডের সাথে মিশবে না। SQL-এ parameterized query — ডেটা আলাদা পথে যায়, তাই query-র অর্থ বদলাতে পারে না (DBMS কোর্সের parameterised query-র অংশ দেখুন)। HTML-এ দেখানোর সময় প্রসঙ্গ অনুযায়ী output encoding — HTML-এর লেখা, attribute, URL বা JavaScript-এর জন্য আলাদা নিয়ম, সাথে Content Security Policy; এতে XSS-এর ঝুঁকি কমে। আর সার্ভার যদি ব্যবহারকারীর দেওয়া URL থেকে কিছু আনে (ছবি, webhook), তাহলে গন্তব্যের allow-list আর ভেতরের ঠিকানায় যাওয়া নিষেধ — নইলে সার্ভার নিজেই ভেতরের দরজা খুলে দিতে পারে।

Multi-tenant isolation — এক ভবনে অনেক দোকান

একটি SaaS-এ শত শত প্রতিষ্ঠান (tenant) একই সফটওয়্যার আর প্রায়ই একই database ভাগ করে; এক দোকানের হিসাব আরেক দোকানে যাওয়াই এখানে সবচেয়ে বড় বিপর্যয়। Multi-tenancy-র তিন ধাপ: (ক) pool — সবার জন্য একই টেবিল, প্রতিটি সারিতে tenant_id, আর প্রতিটি query-তে বাধ্যতামূলক ছাঁকনি; PostgreSQL-এর মতো database-এ row-level security দিয়ে নিয়মটি database নিজেই প্রয়োগ করে (DBMS কোর্সের RLS অংশ)। (খ) bridge — প্রতি tenant-এর আলাদা schema. (গ) silo — বড় বা নিয়ন্ত্রিত গ্রাহকের জন্য আলাদা database বা পুরো আলাদা stack. যত আলাদা, তত নিরাপদ আর তত দামি। সাথে tenant-প্রতি DEK (অংশ ৭), cache key-তে tenant (পর্ব ১৭), আর tenant-প্রতি rate limit — যাতে একজনের ভিড়ে অন্যরা না ভোগেন।

Audit log — কে, কখন, কী

সাধারণ log সমস্যা খোঁজার জন্য; audit trail জবাবদিহির জন্য। সংবেদনশীল প্রতিটি কাজে — login, ভূমিকা বদল, refund, রোগীর রেকর্ড খোলা, চাবির ব্যবহার — লিখুন কে (মানুষ বা সার্ভিস), কখন, কোন বস্তু, কী ফল, কোন অনুরোধ-ID. নিয়ম তিনটি: append-only (কাজ যিনি করেন তিনি log মুছতে পারেন না), কারচুপি ধরা যায় এমন (প্রতিটি entry-তে আগেরটির hash), আর log-এ কোনো secret নয়। মুদি দোকানের বাকির খাতার মতো: পাতা ছেঁড়া যায় না, প্রতিটি লাইনে সই।

Privacy by design — কম রাখুন, ভাগ করে রাখুন

Privacy by design-এর মূল কথা: যে তথ্য রাখেননি, তা ফাঁসও হয় না। Data minimisation — শুধু দরকারি তথ্য, দরকারি সময় পর্যন্ত (retention-এর নিয়মসহ)। Data classification — প্রতিটি field-এ একটি শ্রেণি: প্রকাশ্য, ভেতরের, গোপন, সীমিত (জাতীয় পরিচয়পত্র নম্বর, স্বাস্থ্যতথ্য, card নম্বর)। শ্রেণি থেকেই নিয়ম আসে: কোনটি এনক্রিপ্ট, কোনটি log-এ মাস্ক, কোনটি test database-এ নকল ডেটায় বদলাবে। ইউরোপের GDPR (২০১৮ থেকে কার্যকর) “data protection by design and by default”-কে আইনি দায়িত্ব বানিয়েছে। বাংলাদেশে ব্যক্তিগত উপাত্ত সুরক্ষা নিয়ে আলাদা আইনের খসড়া ও প্রস্তাবিত কাঠামো কয়েক বছর ধরে আলোচনায়, আর এর অবস্থা সময়ের সাথে বদলাচ্ছে — কোনটি কার্যকর আর কোন খাতে নিয়ন্ত্রক সংস্থার আলাদা নির্দেশনা আছে, তা সরকারি সূত্রে যাচাই করে নিন।

৯ · AI-এর যুগে নিরাপত্তা নকশা যাচাই

নিরাপদ login-এর নকশা চাইলে AI প্রায়ই চমৎকার শোনানো একটি তালিকা দেয়: JWT, Redis, OAuth, microservices, WAF. শব্দগুলো ভুল নয়, কিন্তু নিরাপত্তা থাকে খুঁটিনাটিতে, আর ভুলও লুকায় সেখানেই:

AI-এর দেওয়া নিরাপত্তা নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Password-এর algorithm আর parameter OWASP-এর সর্বশেষ নথিতে মিলিয়েছি; নিজের সার্ভারে এক login-এর সময় মেপে capacity আর rate limit হিসাব করেছি
• Token-এর যাচাই-তালিকায় algorithm allow-list, kid, স্বাক্ষর, iss, aud, exp আছে — আর প্রতিটির জন্য একটি প্রত্যাখ্যানের test চালিয়েছি
• প্রতিটি endpoint-এ অন্য ব্যবহারকারী আর অন্য tenant-এর ID দিয়ে test করেছি; তালিকা-query-তে owner বা tenant-এর ছাঁকনি আছে
• কোনো secret কোড, image বা log-এ নেই (secret scanner চালিয়েছি); প্রতিটি secret-এর মেয়াদ আর rotation-এর পথ লেখা আছে
• KMS, identity provider আর secret manager বিকল বা ধীর হলে কী হয় — failure-mode review করেছি, আর fail open না fail closed তা প্রতিটি পথে ঠিক করেছি