RBAC ও ABAC: role, attribute ও tenant permission
RBAC, ABAC, and Tenant Authorization
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- RBAC ও ABAC তুলনা করা
- Tenant boundary প্রতিটি query-তে বজায় রাখা
- Permission change ও audit design করা
সমস্যা দিয়ে শুরু
একজন accountant নিজের কোম্পানির invoice export করতে পারেন। API-তে tenant_id বদলে আরেক কোম্পানির export queue করেন। Role ঠিকই accountant, কিন্তু tenant boundary ভেঙেছে। Role-based permission যথেষ্ট নয় যদি resource scope, membership এবং business attributes একসঙ্গে দেখা না হয়। Multi-tenant SaaS-এ একটি ভুল batch query হাজার customer-এর data প্রকাশ করতে পারে।
সহজ করে বুঝি
RBAC role দিয়ে permission সংগঠিত করে: accountant invoice দেখতে পারেন, manager approve করতে পারেন। ABAC user, resource এবং context-এর attributes দেখে: একই tenant, amount threshold বা workflow state। বাস্তবে দুইটি একসঙ্গে কাজে লাগে। Authenticated request-এর trusted tenant context server membership থেকে নিন। Client পাঠানো tenant identifier শুধু candidate; server যাচাই না করলে authority নয়।
পরিচিত একটি উপমা
একটি office building-এ manager badge সব company-এর দরজা খোলে না। Badge-এর role ছাড়াও কোন company, কোন floor এবং কোন সময়ে permission আছে তা দেখা হয়। একইভাবে role ও resource boundary দুইটি মিলেই access decision সম্পূর্ণ হয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD U[Authenticated user] --> M[Resolve verified membership] M --> T[Trusted tenant context] T --> Q[Tenant scoped query] Q --> P[Role and resource policy] P --> R[Allowed response]
User থেকে membership যাচাই করে tenant context স্থির হয়। Query সেই tenant-এর data-তেই সীমিত থাকে। Policy action-specific role ও resource attributes দেখে। Export job-এ tenant context explicit পাঠাতে হবে এবং worker query-তেও scope রাখতে হবে। Cache key ও file storage path-ও tenant-aware না হলে query ঠিক থেকেও leak হতে পারে।
PHP ও Laravel-এ প্রয়োগ
InvoicePolicy-এর update method fragment। User-এ tenant_id ও role আছে, Invoice-এ tenant_id/status আছে; strict types matched ধরে নেওয়া হয়েছে। বাস্তবে multi-membership table থাকলে active verified membership ব্যবহার করুন। Controller Gate::authorize দিয়ে policy enforce করবে।
use App\Models\Invoice;
use App\Models\User;
public function update(User $user, Invoice $invoice): bool
{
return $user->tenant_id === $invoice->tenant_id
&& $user->role === 'accountant'
&& $invoice->status === 'draft';
}সুবিধা, সীমাবদ্ধতা ও trade-off
RBAC explain ও audit সহজ করে, তবে অসংখ্য special-case role তৈরি হতে পারে। ABAC flexible, কিন্তু rule combination বোঝা ও test করা কঠিন। Tenant isolation-এর জন্য query scoping এবং policy defense in depth দেয়। Global scopes সুবিধাজনক হলেও admin bypass, console command এবং relationship query behavior বুঝতে হবে। Permission cache invalidation deliberate রাখুন।
সাধারণ ভুল
- tenant_id request field-কে trusted context ধরা।
- Super-admin bypass নিয়ম সব action-এ অযথা প্রয়োগ করা।
- Export এবং background job-এ tenant filter বাদ দেওয়া।
আরও একটু গভীরে
Authorization policy version বা membership change-এর পরে cached permission stale হতে পারে। High-risk action-এ execution-time check উপকারী। Database constraints cross-tenant association ঠেকাতে সাহায্য করে, কিন্তু application policy পুরোটা প্রকাশ করে না। Audit-এ actor, tenant, action, resource এবং result রাখুন। Denied attempt logging-এ rate control দিন, নইলে attacker log cost বাড়াতে পারে।
মনে রাখুন
Role বলে কী কাজ করা যায়; tenant ও resource attributes বলে কোথায় এবং কোন অবস্থায় তা করা যায়।
নিজে চেষ্টা করুন
দুটি tenant এবং তিন role-এর policy matrix লিখুন। একই role-এর user অন্য tenant-এর invoice update করতে পারেন না—এই Pest test যোগ করুন। Export job ও cache key-তে isolation test-এর আলাদা scenario দিন।
নিজের বোঝা যাচাই করুন
1. RBAC যথেষ্ট কখন?
Simple role-driven permission-এ সুবিধাজনক। Tenant ownership বা workflow condition থাকলে অতিরিক্ত resource/context check লাগে।
2. Tenant ID client দিলে?
Server membership দিয়ে যাচাই করতে হবে। User-controlled ID permission প্রমাণ করে না।
3. Global scope সব রক্ষা করে?
না। Scope bypass, raw query, queue ও admin path review করতে হয়। Policy এবং constraints-ও দরকার।
4. Permission cache ঝুঁকি কী?
Revoked role বা membership stale থাকতে পারে। Expiry ও invalidation policy business risk অনুযায়ী দিন।
5. Export-এ authorization কোথায়?
Request গ্রহণের সময় এবং durable tenant context অনুযায়ী execution path-এ। Long-running workflow-এ revoked permission handling স্পষ্ট রাখুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।