Authorization model — RBAC, ABAC আর least privilege বাস্তবে

১ · পরিচয় জানা হলো, এবার অনুমতি — subject, object আর action

একটি কাল্পনিক অনলাইন বাজারের কথা ভাবুন। Support কর্মী রিনা নিজের password আর MFA দিয়ে ঠিকমতো login করলেন। Login-এ কোনো ভুল নেই। কিন্তু তাঁর পর্দায় এমন এক গ্রাহকের অর্ডারও খুলে গেল, যাঁর সঙ্গে তাঁর কোনো কাজ নেই। সিস্টেম জানত ইনি রিনা, কিন্তু জিজ্ঞেস করেনি রিনা এই অর্ডার দেখতে পারেন কি না।

পর্ব ১৫ থেকে ১৮ পর্যন্ত বিষয় ছিল authentication, অর্থাৎ “আপনি কে”. এই পর্বের প্রশ্ন authorization, অর্থাৎ “আপনি এখানে কী করতে পারেন”. দুটি আলাদা প্রশ্ন, আর একটির উত্তর অন্যটিকে দেয় না। OWASP Top 10-এর ২০২১ আর ২০২৫ সংস্করণে broken access control প্রথম স্থানে আছে, তাই ভুলটি বিরল নয়।

প্রতিটি অনুমতির সিদ্ধান্ত তিনটি জিনিস নিয়ে। Subject হলো যিনি কাজ চাইছেন: মানুষ, প্রোগ্রাম বা service. Object হলো যার ওপর কাজ হবে: ফাইল, অর্ডার, API, database-এর সারি। Action হলো কাজটি: পড়া, লেখা, মুছে ফেলা, অনুমোদন করা। এই পুরো ব্যবস্থার নাম access control.

Access matrix — এক ছকে সব নিয়ম

সব নিয়ম একটি ছকে লেখা যায়। সারিতে subject, কলামে object, ঘরে অনুমতি। Butler Lampson ১৯৭১ সালের “Protection” লেখায় এই ধারণাটি স্পষ্ট করেন। একে বলে access control matrix. OS-এর দিক থেকে এর পূর্ণ আলোচনা, domain আর revocation আছে Operating Systems-এর protection পর্বে. এখানে শুধু ব্যবহারিক সারকথা।

৫০০ জন মানুষ আর ১০,০০০টি বস্তু হলে ছকে ঘর ৫০০ × ১০,০০০ = ৫০,০০,০০০টি, যার বেশিরভাগ ফাঁকা। তাই পুরো ছক কেউ রাখে না। দুভাবে ভাগ করে রাখা হয়।

২ · DAC আর MAC — মালিকের ইচ্ছা, না প্রতিষ্ঠানের নিয়ম

পরের প্রশ্ন: অনুমতি দেওয়ার ক্ষমতা কার হাতে? Discretionary access control (DAC)-এ বস্তুর মালিক ঠিক করেন। নিজের খাতা কাকে দেখাবেন, সেটি আপনার ইচ্ছা। Cloud drive-এ নিজের ফাইল শেয়ার করা এই ধরনের। DAC সহজ, কিন্তু দুর্বলতা হলো আপনার নামে চলা যেকোনো প্রোগ্রাম আপনার সব অধিকার পায়। ক্ষতিকর একটি প্রোগ্রামও আপনার ফাইল অন্যকে দিয়ে দিতে পারে।

Mandatory access control (MAC)-এ নিয়ম ঠিক করে সিস্টেম, ব্যবহারকারী নন। সরকারি গোপন নথির কথা ভাবুন: নথিতে security label বসানো, কর্মকর্তার আছে অনুমোদনের স্তর, আর নথির মালিক হলেও নিজের ইচ্ছায় বাইরের কাউকে দেওয়া যায় না। Linux-এর SELinux আর AppArmor এই ধারণার বাস্তব রূপ, যা পর্ব ৩০-এ আসবে।

MAC-এর দুটি ক্লাসিক মডেল একে অপরের আয়না। Bell-LaPadula (১৯৭৩, যুক্তরাষ্ট্রের সামরিক প্রয়োজনে MITRE-তে তৈরি) গোপনীয়তা রক্ষা করে: ওপরে পড়া নিষেধ, নিচে লেখা নিষেধ। Biba (১৯৭৭) অখণ্ডতা রক্ষা করে: নিচে পড়া নিষেধ, ওপরে লেখা নিষেধ।

যুক্তিটি সহজ। “Secret” স্তরের কর্মকর্তা “Top Secret” পড়তে পারবেন না, এটি স্বাভাবিক। কিন্তু তিনি “Public” নথিতে লিখতেও পারবেন না, কারণ মাথার গোপন তথ্য লিখে দিলেই তা নিচে ফাঁস হবে। Biba উল্টো দিকে ভাবে: হাসপাতালের অফিসিয়াল রোগীর ফাইলে যাচাইহীন তথ্য যেন না ঢোকে। যাচাইহীন তথ্য পড়ে তার ভিত্তিতে বিশ্বাসযোগ্য নথি লিখলে ভুল ওপরে উঠে যায়। ইন্টারনেট থেকে নামানো ফাইল যেন system ফাইল বদলাতে না পারে, এটিও একই চিন্তা।

৩ · RBAC — মানুষকে নয়, পদকে অনুমতি

একটি গার্মেন্টস কারখানায় লাইন সুপারভাইজার বদলান, কিন্তু “লাইন সুপারভাইজার” পদের দায়িত্ব একই থাকে। Role-based access control (RBAC) এই পর্যবেক্ষণের ওপর দাঁড়িয়ে। অনুমতি বসে role-এ, মানুষ বসেন role-এ। মানুষ আর অনুমতি সরাসরি জোড়া থাকে না।

NIST মডেলের চারটি স্তর

Ferraiolo ও Kuhn ১৯৯২ সালে RBAC-এর আনুষ্ঠানিক ধারণা দেন, Sandhu ও সহলেখকদের ১৯৯৬ সালের RBAC96 সেটিকে বিস্তৃত করে, আর ২০০০ সালের NIST মডেল থেকে আসে ANSI/INCITS 359 standard (২০০৪, পরে সংশোধিত)। এর স্তরগুলো একটির ওপর আরেকটি:

নিচের stepper একটি অনুরোধ অনুসরণ করে: রিনা order.read চাইছেন। লক্ষ করুন, তাঁর নিজের role-এ এই অনুমতি নেই, এটি আসছে উত্তরাধিকার থেকে।

subject = rina
action  = order.read
object  = order:1042

rina  -> support
kamal -> lead
mitu  -> finance
tareq -> (কোনো role নেই)

support -> viewer
কার্যকর role = { support, viewer }

support -> ticket.reply
viewer  -> order.read
কার্যকর অনুমতি = { ticket.reply, order.read }

ALLOW  rina order.read
কারণ: support -> viewer -> order.read

order.read = "অর্ডার পড়া যায়"
কিন্তু order:1042 কি রিনার টিকিটের অর্ডার?
RBAC এই প্রশ্ন করেনি

এবার একই খেলনা ডেটায় পুরো ছক চালিয়ে দেখুন। কেউ “সুবিধার জন্য” lead-এর উত্তরাধিকারে finance জুড়ে দিয়েছেন। Policy-র লিখিত প্রত্যাশার সঙ্গে প্রতিটি ঘর মেলানো হচ্ছে। সবকিছু memory-র ভেতরের toy ডেটা।

// Toy RBAC on in-memory data. No real system is touched.
const perms = {
  viewer: ['order.read'], support: ['ticket.reply'],
  lead: ['refund.approve'], finance: ['invoice.read', 'report.export'],
};
// senior role -> junior roles. "lead -> finance" was added "for convenience".
const inherits = { support: ['viewer'], lead: ['support', 'finance'], finance: ['viewer'] };
const userRoles = { rina: ['support'], kamal: ['lead'], mitu: ['finance'], tareq: [] };

function effective(role, seen = new Set()) {
  if (seen.has(role)) return new Set();          // a cycle must not hang the check
  seen.add(role);
  const out = new Set(perms[role] || []);
  for (const j of inherits[role] || []) for (const p of effective(j, seen)) out.add(p);
  return out;
}
function check(user, perm) {
  for (const r of userRoles[user] || []) if (effective(r).has(perm)) return true;
  return false;                                  // deny by default
}
// Test matrix: what the policy document says each user MUST get.
const actions = ['order.read', 'ticket.reply', 'refund.approve', 'invoice.read', 'report.export'];
const expected = { rina: 'YYNNN', kamal: 'YYYNN', mitu: 'YNNYY', tareq: 'NNNNN' };

let fails = 0;
console.log('user   ' + actions.map((a, i) => 'a' + (i + 1)).join('  '));
for (const u of Object.keys(expected)) {
  const row = actions.map((a, i) => {
    const got = check(u, a) ? 'Y' : 'N', bad = got !== expected[u][i];
    if (bad) { fails++; console.log('  FAIL ' + u + ' ' + a + ': want ' + expected[u][i] + ', got ' + got); }
    return got + (bad ? '!' : ' ');
  });
  console.log(u.padEnd(7) + row.join('  '));
}
console.log('cells tested:', 4 * actions.length, ' failed:', fails);

৪ · ABAC — পদ যথেষ্ট না হলে বৈশিষ্ট্য আর পরিস্থিতি

প্রতিষ্ঠান বড় হলে RBAC-এর একটি রোগ দেখা দেয়। “ঢাকা শাখার সিনিয়র হিসাবরক্ষক”, “চট্টগ্রাম শাখার জুনিয়র হিসাবরক্ষক”, প্রতিটি মিশ্রণের জন্য একটি করে নতুন role তৈরি হয়। একে বলে role explosion. ৬টি বিভাগ, ৮টি শাখা আর ৩টি পদমর্যাদা হলে সম্ভাব্য role ৬ × ৮ × ৩ = ১৪৪টি, আর ব্যতিক্রম যোগ হলে আরও। অথচ মূল তথ্য মাত্র ৬ + ৮ + ৩ = ১৭টি মান। গুণ থেকে যোগে নামার এই চিন্তাই attribute-based access control (ABAC).

NIST SP 800-162 (Hu ও সহলেখক, জানুয়ারি ২০১৪) ABAC-কে এভাবে বোঝায়: subject, object, চাওয়া কাজ আর কখনো পরিবেশের attribute মিলিয়ে policy-র নিয়মে সিদ্ধান্ত। তাই নিয়ম লেখা হয় মানুষের তালিকায় নয়, শর্তে: “কর্মীর বিভাগ আর নথির বিভাগ এক হলে পড়া যাবে।”

অনেক নিয়ম একসাথে মিললে কী হবে? সবচেয়ে প্রচলিত উত্তর deny overrides: একটি deny মিললে সব permit বাতিল। আর কিছুই না মিললে ফল default deny. নিচের সিদ্ধান্তে রিনা (HR বিভাগ) রাত ৯টায় বেতনের ফাইল চাইছেন। দেখবেন permit মিলেও শেষ ফল আলাদা হয়।

// Toy ABAC on in-memory data. The hour comes from a simulated clock.
const policies = [
  { id: 'P1', effect: 'permit', why: 'same department',
    when: (s, o, a) => a === 'read' && s.dept === o.dept },
  { id: 'P2', effect: 'permit', why: 'auditor reads non-secret',
    when: (s, o, a) => a === 'read' && s.role === 'auditor' && o.level <= 2 },
  { id: 'D1', effect: 'deny', why: 'payroll only 09-18',
    when: (s, o, a, e) => o.type === 'payroll' && (e.hour < 9 || e.hour >= 18) },
  { id: 'D2', effect: 'deny', why: 'level 3 needs MFA',
    when: (s, o, a, e) => o.level >= 3 && !e.mfa },
];
function decide(s, o, a, e) {
  const hits = policies.filter(p => p.when(s, o, a, e));
  const deny = hits.find(p => p.effect === 'deny');   // deny overrides permit
  if (deny) return `DENY  by ${deny.id} (${deny.why})`;
  const ok = hits.find(p => p.effect === 'permit');
  if (ok) return `ALLOW by ${ok.id} (${ok.why})`;
  return 'DENY  by default (no rule matched)';
}
const rina = { name: 'rina', dept: 'hr', role: 'staff' };
const mitu = { name: 'mitu', dept: 'finance', role: 'staff' };
const asif = { name: 'asif', dept: 'audit', role: 'auditor' };
const salary = { id: 'salary-oct', dept: 'hr', type: 'payroll', level: 3 };
const policyDoc = { id: 'leave-policy', dept: 'hr', type: 'doc', level: 1 };

const cases = [
  [rina, salary, 'read', { hour: 11, mfa: true }],
  [rina, salary, 'read', { hour: 21, mfa: true }],
  [rina, salary, 'read', { hour: 11, mfa: false }],
  [mitu, salary, 'read', { hour: 11, mfa: true }],
  [asif, policyDoc, 'read', { hour: 10, mfa: false }],
  [rina, policyDoc, 'delete', { hour: 10, mfa: true }],
];
for (const [s, o, a, e] of cases)
  console.log(`${s.name} ${a} ${o.id} @${e.hour}h mfa=${e.mfa}`.padEnd(38), decide(s, o, a, e));

৫ · ReBAC — সম্পর্কের পথ ধরে অনুমতি

Cloud drive-এ ফোল্ডার শেয়ার করলে ভেতরের সব ফাইল শেয়ার হয়। দলের সদস্য হলে দলের ফোল্ডার দেখা যায়। এখানে পদ বা বিভাগ নয়, প্রশ্নটি হলো এই মানুষের সঙ্গে এই বস্তুর সম্পর্কের কোনো পথ আছে কি না। এটি relationship-based access control (ReBAC). মহল্লার পরিচয়ের মতো: “আমি রহিমের ভাই, রহিম এই দোকানের মালিক”, এই শিকল ধরেই দরজা খোলে।

ReBAC-এর সবচেয়ে পরিচিত প্রকাশিত নকশা Google-এর “Zanzibar: Google's Consistent, Global Authorization System” (Pang ও সহলেখক, USENIX ATC ২০১৯)। পেপার অনুযায়ী Calendar, Drive, YouTube-সহ শত শত service-এর জন্য এটি trillion-সংখ্যক ACL সামলায়, প্রতি সেকেন্ডে কয়েক মিলিয়ন অনুরোধে। মূল ধারণাটি সরল: প্রতিটি তথ্য একটি relation tuple, অর্থাৎ “এই বস্তুর, এই সম্পর্কে, এই ব্যক্তি”. SpiceDB ও OpenFGA-র মতো কিছু open source প্রকল্প এই নকশায় অনুপ্রাণিত, উদাহরণ হিসেবে নাম দুটি জেনে রাখা যায়।

// Toy ReBAC: facts are tuples [object, relation, who]. In memory only.
const tuples = [
  ['folder:reports', 'owner', 'user:anika'],
  ['folder:reports', 'viewer', 'group:finance#member'],
  ['group:finance', 'member', 'user:bashir'],
  ['doc:q3', 'parent', 'folder:reports'],
  ['doc:q3', 'editor', 'user:chandra'],
  ['doc:hr-plan', 'parent', 'folder:hr'],
];
const implied = { viewer: 'editor', editor: 'owner' };  // an owner can edit, an editor can view

function check(obj, rel, user, path = []) {
  if (path.length > 8) return null;                     // limit the walk, fail closed
  const trail = [...path, `${obj}#${rel}`];
  const next = [];                                      // places to walk next
  for (const [o, r, who] of tuples) {
    if (o === obj && r === rel && who === user) return [...trail, user];
    if (o === obj && r === rel && who.includes('#')) next.push(who.split('#'));
    if (o === obj && r === 'parent') next.push([who, rel]);   // inherit from the folder
  }
  if (implied[rel]) next.push([obj, implied[rel]]);
  for (const [o, r] of next) {
    const hit = check(o, r, user, trail);
    if (hit) return hit;
  }
  return null;
}
const asks = [['doc:q3', 'viewer', 'user:bashir'], ['doc:q3', 'editor', 'user:anika'],
  ['doc:q3', 'viewer', 'user:chandra'], ['doc:q3', 'editor', 'user:bashir'],
  ['doc:hr-plan', 'viewer', 'user:bashir']];
for (const [o, r, u] of asks) {
  const p = check(o, r, u);
  console.log(`${u} ${r} ${o}: ${p ? 'ALLOW' : 'DENY'}`);
  if (p) console.log('   ' + p.join(' <- '));
}

৬ · Multi-tenant isolation — এক ভবনে অনেক ভাড়াটিয়া

একটি SaaS পণ্যে একই software, একই database অনেক প্রতিষ্ঠান ব্যবহার করে। এটি multi-tenancy, আর প্রতিটি প্রতিষ্ঠান একটি tenant. ফ্ল্যাটবাড়ির মতো: ছাদ, লিফট, পানির ট্যাংক অভিন্ন, কিন্তু আপনার চাবিতে পাশের ফ্ল্যাট খোলা চলবে না। এখানে একটি ভুল মানে এক গ্রাহকের ডেটা অন্য গ্রাহকের কাছে, যা সাধারণ বাগ নয়, পুরো পণ্যের বিশ্বাসের প্রশ্ন।

-- অনিরাপদ নকশা: যেকোনো tenant-এর অর্ডার আসতে পারে
SELECT * FROM orders WHERE id = :order_id;

-- নিরাপদ নকশা: tenant আসে যাচাই করা session থেকে, request থেকে নয়
SELECT * FROM orders
WHERE id = :order_id AND tenant_id = :tenant_from_session;

• Tenant-এর উৎস: যাচাই করা session বা token, কখনো URL, form বা header-এর ব্যবহারকারী-লিখিত মান নয়।
• এক জায়গায় ছাঁকনি: প্রতিটি query-তে হাতে শর্ত লিখলে একদিন ভুল হবেই। Data layer বা database-এর row-level security ব্যবহার করুন; দেখুন DBMS কোর্সের cloud database পর্ব.
• ভুলে যাওয়া পথ: Cache key, background job, CSV export, search index আর log-এও tenant লাগবে। ফাঁস প্রায়ই মূল পাতায় নয়, এসব পাশের পথে হয়।
• Support-এর বিশেষ ক্ষমতা: গ্রাহকের ডেটা দেখার অভ্যন্তরীণ tool-এ সময়সীমা, কারণ লেখা আর log বাধ্যতামূলক রাখুন।

৭ · সিদ্ধান্ত আর প্রয়োগ আলাদা — PDP, PEP আর policy as code

কোডের একশ জায়গায় ছড়ানো if (user.isAdmin) একটি বড় ঝুঁকি। একটি জায়গায় ভুলে গেলেই ফাঁক, আর নিয়ম বদলালে একশ জায়গা বদলাতে হয়। তাই নকশায় দুটি কাজ আলাদা করা হয়। দরজায় দাঁড়িয়ে আটকানো, আর নিয়ম দেখে সিদ্ধান্ত নেওয়া। অফিসের দারোয়ান নিজে নিয়ম বানান না; তিনি খাতায় দেখেন বা ফোন করে জেনে নেন।

তিনটি নিয়ম যা কোনো মডেলেই বদলায় না

• Deny by default: কোনো নিয়ম না মিললে, বা engine-এ ত্রুটি হলে, ফল deny. এটি পর্ব ০৩-এর default deny, যা ভুলকে নিরাপদ দিকে ঠেলে দেয়।
• Server-এ যাচাই: Button লুকানো শুধু সুবিধা, নিরাপত্তা নয়। প্রতিটি API অনুরোধে আলাদা যাচাই লাগে, যাকে পর্ব ০৩-এ বলা হয়েছে complete mediation.
• একটি কেন্দ্রীয় পথ: সব যাচাই একটি library বা service দিয়ে যাক। নতুন endpoint-এ যাচাই ভুলে গেলে framework নিজেই আটকাবে, এমন নকশা সবচেয়ে ভালো। এই ধারণাই reference monitor.

Policy as code

নিয়ম যদি ফাইলে লেখা কোড হয়, তবে সেটি review করা যায়, test করা যায়, পুরোনো সংস্করণে ফেরা যায়। এই চর্চা policy as code. দুটি পরিচিত উদাহরণ Open Policy Agent (OPA), যার ভাষা Rego, আর Cedar, যা AWS থেকে শুরু হওয়া একটি open source ভাষা। এগুলো উদাহরণ মাত্র, কোনো সুপারিশ নয়। নিচের দুটি ফাইল একই ধারণা দেখায়। এগুলো এখানে চালানো হয়নি; ব্যবহারের আগে official doc-এর সঙ্গে মিলিয়ে নিন, কারণ syntax version-ভেদে বদলাতে পারে।

package bazar.authz

import rego.v1

default allow := false

allow if {
    input.action == "order.read"
    "support" in input.subject.roles
    input.subject.tenant == input.resource.tenant
}

permit (
    principal in Role::"support",
    action == Action::"orderRead",
    resource
)
when { principal.tenant == resource.tenant };

forbid (principal, action, resource)
when { resource.level >= 3 && !context.mfa };

৮ · প্রমাণ চাই — test ছক, সিদ্ধান্তের log আর confused deputy

Authorization test মানে একটি ছক

সাধারণ test দেখে কাজটি হয় কি না। Authorization test দেখে যার পারার কথা নয়, সে পারে না তো। পদ্ধতিটি সরল: সারিতে role, কলামে action, প্রতিটি ঘরে প্রত্যাশিত ফল, যেমনটি rbac_matrix.js-এ দেখলেন।

Login করা ছাড়া, ভুল role, ভুল tenant, মেয়াদ শেষ হওয়া session, এই নেতিবাচক ঘরগুলোই বেশি জরুরি। এসব পরীক্ষা আপনার নিজের test পরিবেশে চলবে। চালু কোনো সিস্টেমে লিখিত অনুমতি ছাড়া অন্যের ডেটায় চেষ্টা করা অপরাধ হতে পারে; সীমা দেখুন পর্ব ০৬-এ।

সিদ্ধান্তের log

“কে এই ফাইল দেখেছিল?” তদন্তের প্রথম প্রশ্ন। তাই decision log শুধু “denied” লেখা নয়; কে, কী, কোন বস্তু, কোন নিয়ম, কোন policy সংস্করণ, সবই রাখতে হবে। সাধারণ audit log-এর সঙ্গে পার্থক্য হলো, এখানে সিদ্ধান্তের কারণ থাকে।

{
  "time": "2026-10-20T21:04:11Z",
  "request_id": "req-example-8841",
  "subject": "user-1042",
  "tenant": "tenant-demo",
  "action": "record.read",
  "object": "salary-oct",
  "decision": "deny",
  "rule": "D1",
  "policy_version": "2026-10-18",
  "source_ip": "203.0.113.10"
}

এই log থেকে যা নজরে রাখা যায়: একজন subject অল্প সময়ে অনেক ভিন্ন object-এ deny পাচ্ছেন, অন্য tenant-এর বস্তুতে যেকোনো চেষ্টা, role-এর হঠাৎ পরিবর্তন, আর অস্বাভাবিক সময়ে ব্যাপক export. Log-এ password, token বা ডেটার মূল বিষয় লিখবেন না। Log জমা করার কাঠামো দেখুন centralized logging পর্বে; নিরাপত্তার দিকটি আসবে পর্ব ৫৫-এ।

Confused deputy — আপনার ক্ষমতায় অন্যের কাজ

একটি প্রোগ্রামের নিজের অনেক অধিকার আছে, আর সে ব্যবহারকারীর হয়ে কাজ করে। ব্যবহারকারী তাকে এমন কাজ করালেন, যা নিজে পারতেন না, এই সমস্যার নাম confused deputy. নামটি Norm Hardy-র ১৯৮৮ সালের লেখা থেকে; মূল ঘটনা আর capability দিয়ে সমাধান আছে protection পর্বে. ভাবুন, অফিসের পিয়নের কাছে সব ঘরের চাবি আছে। কেউ পিয়নকে বলল, “ওই ফাইলটা এনে দিন।” পিয়ন জানতে চাইলেন না ফাইলটি ওই মানুষের জন্য কি না।

আজকের রূপ: একটি report service-এর database-এর পুরো অধিকার আছে, আর সে ব্যবহারকারীর দেওয়া report নম্বর দেখে ফাইল বের করে। Service-এর নিজের অনুমতি যাচাই হলো, কিন্তু ব্যবহারকারীর অনুমতি নয়। প্রতিরক্ষা তিনটি: কার হয়ে কাজ হচ্ছে সেই পরিচয় সঙ্গে নেওয়া ও সেই অনুমতিতে যাচাই, service-এর নিজের অধিকার ছোট রাখা, আর নাম নয় বরং সীমিত capability দেওয়া। Cross-account access-এ একটি cloud vendor-এর doc এই সমস্যার জন্যই external ID ব্যবহারের কথা বলে। URL আনার service-এর ক্ষেত্রে পর্ব ৪২ (SSRF) আর AI agent-এর ক্ষেত্রে পর্ব ৫১ একই সমস্যার দুটি নতুন চেহারা।

৯ · মানুষ বদলায়, অনুমতি থেকে যায় — joiner, mover, leaver

নকশা যত ভালোই হোক, least privilege একদিনের কাজ নয়। মানুষ চাকরিতে আসেন, বিভাগ বদলান, চলে যান। সেই তিন মুহূর্তের প্রক্রিয়াকে বলে joiner-mover-leaver (JML). সবচেয়ে অবহেলিত হলো mover: নতুন অনুমতি সবাই চায়, পুরোনোটি কেউ ফেরত দিতে বলে না। ধীরে ধীরে অনুমতি জমে যাওয়াকে বলে privilege creep. দশ বছরের পুরোনো কর্মীর account প্রায়ই পুরো অফিসের চাবির গোছা হয়ে দাঁড়ায়।

এই একই হিসাব একটি ছোট report চালিয়ে দেখুন। Toy ডেটায় TODAY = 400, যা উপরের দিন ৪০০-র সঙ্গে মেলে।

// Toy role-count and access-review report. All data is invented; day numbers are simulated.
const dept = 6, branch = 8, grade = 3;
console.log(`roles if every mix is one role: ${dept} x ${branch} x ${grade} = ${dept * branch * grade}`);
console.log(`attribute values to keep instead: ${dept} + ${branch} + ${grade} = ${dept + branch + grade}`);

const TODAY = 400, STALE_DAYS = 90;
// user, permission, day last used (null = never used)
const grants = [
  ['rina', 'order.read', 395], ['rina', 'invoice.read', 398], ['rina', 'report.export', 390],
  ['rina', 'ticket.reply', 198], ['rina', 'refund.approve', 288], ['rina', 'refund.create', 285],
  ['mitu', 'invoice.read', 399], ['mitu', 'report.export', 370], ['mitu', 'user.admin', null],
  ['kamal', 'order.read', 397], ['kamal', 'ticket.reply', 396], ['kamal', 'refund.approve', 392],
];
const toxic = [['refund.create', 'refund.approve']];      // separation of duties
let unused = 0;
const byUser = {};
for (const [u, p, last] of grants) {
  (byUser[u] ||= []).push(p);
  const age = last === null ? Infinity : TODAY - last;
  if (age > STALE_DAYS) {
    unused++;
    const said = last === null ? 'never used' : `last used ${age} days ago`;
    console.log(`REVIEW ${u.padEnd(6)} ${p.padEnd(15)} ${said}`);
  }
}
for (const [u, ps] of Object.entries(byUser))
  for (const [a, b] of toxic)
    if (ps.includes(a) && ps.includes(b)) console.log(`SOD    ${u}: holds both ${a} and ${b}`);
const pct = (100 * unused / grants.length).toFixed(1);
console.log(`unused: ${unused} of ${grants.length} grants (${pct}%), window ${STALE_DAYS} days`);

ভালো access review কেমন

• যিনি কাজ জানেন, তিনিই যাচাই করেন: ব্যবস্থাপক বা তথ্যের মালিক, IT একা নয়।
• প্রমাণ সামনে থাকে: শেষ ব্যবহারের তারিখ, role-এর অর্থ সহজ ভাষায়। নইলে ৪০০ সারিতে সবাই “approve all” চাপেন, যাকে বলে rubber-stamping.
• ঝুঁকি অনুযায়ী ঘন ঘন: admin আর আর্থিক অনুমতি বেশি ঘন, সাধারণ পড়ার অনুমতি কম। পর্ব ২০-এ privileged account-এর আলাদা ব্যবস্থা আসবে।
• মেয়াদ দিয়ে শুরু: সাময়িক অনুমতি শুরু থেকেই মেয়াদসহ দিলে পরে সরাতে মনে রাখতে হয় না।
• ফল বাস্তবায়ন: “সরান” লেখা হলেই কাজ শেষ নয়, সত্যিই সরেছে কি না যাচাই। NIST SP 800-53 Rev. 5-এর AC-2 আর AC-6(7) এই পর্যালোচনার কথা বলে।

১০ · AI-এর যুগে authorization

AI endpoint লিখে দেয় দ্রুত, আর সেই কোড চলেও। কিন্তু authorization-এর ভুল চলার সময় কোনো error দেয় না; সবার জন্য খোলা endpoint দিব্যি কাজ করে। তাই AI-এর কোডে এই অংশটি সবচেয়ে আগে পড়ুন। AI-এর উত্তরে থাকা CVE নম্বর বা standard-এর ধারা মূল উৎসে মিলিয়ে নিন, কারণ AI সেগুলো বানিয়েও বলতে পারে।

AI agent-ও একটি subject

যে AI agent আপনার হয়ে email পড়ে, ফাইল খোলে বা API ডাকে, সে-ই আজকের সবচেয়ে সহজ confused deputy. ডেটার ভেতরের লেখা তাকে ভুল কাজে নিতে পারে (পর্ব ৫১)। তাই তাকে আলাদা পরিচয়, সরু scope আর ছোট মেয়াদের অনুমতি দিন, ঝুঁকির কাজে মানুষের অনুমোদন রাখুন, আর তার প্রতিটি সিদ্ধান্ত log করুন।

AI-এর authorization কোড হাতে পেলে

• প্রতিটি endpoint-এ server-পাশের যাচাই নিজের চোখে দেখেছি
• Object-স্তরে মালিকানা আর tenant শর্ত আছে, শুধু login নয়
• অজানা অবস্থায় আর ত্রুটিতে ফল deny
• Role-action ছকের নেতিবাচক test চালিয়েছি, নিজের test পরিবেশে
• Error ঠিক করতে * বা admin দেওয়া হয়নি, বা কোনো check বন্ধ করা হয়নি
• Prompt-এ কোনো secret বা ব্যক্তিগত ডেটা যায়নি
• কোড বদলের diff নিজে পড়েছি, উল্লেখ করা standard মূল উৎসে মিলিয়েছি