আপনার অ্যাপে রোল-ভিত্তিক অ্যাক্সেস কন্ট্রোল (RBAC) কীভাবে যোগ করবেন

রোল-ভিত্তিক অ্যাক্সেস কন্ট্রোল যোগ করতে প্রতিটি ব্যবহারকারীকে এক বা একাধিক রোল দিন (যেমন admin, editor, viewer), ঠিক করুন কোন রোল কোন কাজ করতে পারবে, এবং প্রতিটি অনুরোধে সেই অনুমতিগুলো সার্ভারে যাচাই করুন — শুধু বাটন লুকিয়ে নয়। এছাড়া নিশ্চিত করুন যে যে রেকর্ডটিতে প্রবেশ করা হচ্ছে সেটি ব্যবহারকারীর অ্যাকাউন্ট বা টিমের। প্রথমে ডাটাবেসে কয়েকটি নির্দিষ্ট রোল দিয়ে শুরু করুন, এবং পরীক্ষা করুন সরাসরি অন্য ব্যবহারকারীর ডাটায় পৌঁছানো যায় কি না।

প্রমাণীকরণ বনাম অনুমোদন

দুটি শব্দ প্রায়ই গুলিয়ে ফেলা হয়:

• প্রমাণীকরণ (Authentication) হলো আপনি কে? — লগইন করা। দেখুন আপনার অ্যাপে লগইন কীভাবে যোগ করবেন।
• অনুমোদন (Authorisation) হলো আপনি কী করতে পারেন? — লগইন করা ব্যবহারকারী কোন পেজ, রেকর্ড ও কাজে পৌঁছাতে পারবে।

RBAC অনুমোদনের সবচেয়ে সাধারণ উপায়। এটি গুরুত্বপূর্ণ: ২০২৬ সালের সেপ্টেম্বর পর্যন্ত Broken Access Control, OWASP Top 10:2025-এ ১ নম্বরে — যা ওয়েব অ্যাপ্লিকেশনের সবচেয়ে গুরুতর নিরাপত্তা ঝুঁকির বহুল ব্যবহৃত তালিকা। সাধারণ ব্যর্থতা হলো URL-এর ID বদলে অন্যের রেকর্ড পড়া, অথবা সাধারণ ব্যবহারকারীর admin-only API রুটে কল করা।

একটি মডেল বাছুন

বাস্তবে বেশিরভাগ অ্যাপ দুটি জিনিস মেশায়: রোল, কী ধরনের কাজ করা যাবে সেটির জন্য, আর মালিকানা, কোন রেকর্ডে সেই কাজ করা যাবে সেটির জন্য। "Editor-রা পোস্ট সম্পাদনা করতে পারে" একটি রোলের নিয়ম; "…তাদের নিজস্ব ওয়ার্কস্পেসের পোস্ট" একটি মালিকানার নিয়ম। আপনার দুটোই লাগবে।

আপনি যা ভাবেন তার চেয়ে সহজভাবে শুরু করুন। Admin, member ও viewer অনেক অ্যাপের জন্য যথেষ্ট। দশটি রোল, যা কেউ ব্যাখ্যা করতে পারে না, তা জট ছাড়ানোর চেয়ে পরে একটি রোল ভাগ করা সহজ।

কোড লেখার আগে রোল ডিজাইন করুন

আগে সাধারণ ভাষায় একটি অনুমতির টেবিল লিখুন। এটি একসঙ্গে AI-এর স্পেসিফিকেশন ও আপনার টেস্ট পরিকল্পনা হিসেবেও কাজ করে:

প্রান্তিক ক্ষেত্রগুলোও ঠিক করুন: শেষ owner কি চলে যেতে পারে? একজন admin কি owner-কে সরাতে পারে? সরানো ব্যবহারকারী কী দেখে?

ধাপে ধাপে

১. আগে কার্যকর লগইন থাকুক

RBAC প্রমাণীকরণের ওপরে বসে। সার্ভারকে প্রতিটি অনুরোধে নির্ভরযোগ্যভাবে জানতে হবে কে অনুরোধ করছে, একটি সেশন বা যাচাইকৃত টোকেন থেকে — কখনো ব্রাউজারের পাঠানো রিকোয়েস্ট বডির কোনো ব্যবহারকারী ID থেকে নয়।

২. ডাটাবেসে রোল সংরক্ষণ করুন

একটিমাত্র টিমের অ্যাপের জন্য ব্যবহারকারীর টেবিলে একটি role কলাম ঠিক আছে। টিমের জন্য একটি সদস্যপদের টেবিল ব্যবহার করুন:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

সাধারণ প্রোফাইল আপডেটে কোনো ব্যবহারকারীকে নিজের রোল বদলাতে দেবেন না। রোল বদলানো একটি নির্দিষ্ট, অনুমতি-যাচাইকৃত এন্ডপয়েন্টের মাধ্যমে হবে।

৩. সার্ভারে, একটিমাত্র জায়গায় অনুমতি যাচাই করুন

একটি হেল্পার লিখুন — যেমন can(user, 'projects.delete', project) — এবং যেকোনো API রুট, সার্ভার অ্যাকশন ও ব্যাকগ্রাউন্ড টাস্কে যা ডাটা পড়ে বা বদলায়, সেখানে এটি কল করুন। কোড জুড়ে ছড়ানো যাচাইয়ের চেয়ে একটিমাত্র কেন্দ্রীয় ফাংশন পর্যালোচনা ও পরীক্ষা করা সহজ। ডিফল্টভাবে প্রত্যাখ্যান করুন: কোনো নিয়ম অনুমতি না দিলে কাজটি বাতিল।

৪. প্রতিটি কোয়েরি সীমিত করুন

টিমের ডাটার প্রতিটি কোয়েরিতে টিম থাকতে হবে: where organization_id = :currentOrg, শুধু where id = :id নয়। এটিই থামায় কাউকে /projects/123 বদলে /projects/124 করে অন্য কোম্পানির প্রজেক্ট দেখা থেকে। অন্য টিমের রেকর্ডের জন্য "forbidden" নয়, "not found" ফেরত দিন, যাতে সেগুলো আছে তাও প্রকাশ না পায়।

৫. যেখানে দরকার সেখানে ডাটাবেস-স্তরের সুরক্ষা যোগ করুন

Postgres row-level security (RLS) ডাটাবেসকে দিয়ে দেয় কোন সারি কোন ব্যবহারকারী দেখতে পাবে তা বাস্তবায়ন করতে। ব্রাউজার সরাসরি ডাটাবেসের সঙ্গে কথা বললে (যেমন কিছু হোস্টেড ব্যাকএন্ডে) এটি অপরিহার্য, আর অন্যথায় সংবেদনশীল টেবিলের জন্য একটি কার্যকর দ্বিতীয় স্তর।

৬. ইন্টারফেসে রোল দেখান

এখন ব্যবহারকারী যা করতে পারবে না তা লুকান বা নিষ্ক্রিয় করুন, যাতে অ্যাপ বিভ্রান্তিকর না হয়। এটি শুধু ব্যবহারযোগ্যতার জন্য; সুরক্ষা দেয় সার্ভারের যাচাই।

৭. সংবেদনশীল কাজ লগ করুন

কে রোল বদলাল, ডাটা মুছল বা রেকর্ড রপ্তানি করল, এবং কখন — তা রেকর্ড করুন। একটি অডিট লগ সাপোর্টের প্রশ্ন ও ঘটনা বিশ্লেষণে সাহায্য করে।

৮. আক্রমণকারীর মতো পরীক্ষা করুন

প্রতিটি রোল দিয়ে লগইন করুন এবং অনুমতির টেবিলের প্রতিটি কাজ চেষ্টা করুন। তারপর যা কাজ করা উচিত নয় তা চেষ্টা করুন: viewer হিসেবে admin API রুটে কল করা, URL ও রিকোয়েস্টে ID বদলানো, শেষ owner হিসেবে নিজেকে সরানো। নিয়মগুলো স্থির হলে অনুমতির টেবিলের জন্য স্বয়ংক্রিয় টেস্ট লেখার মতো।

কাজে লাগানো যায় এমন প্রম্পট

RBAC যোগ করো। প্রতিষ্ঠানভিত্তিক রোল: owner, admin, member, viewer, memberships টেবিলে সংরক্ষিত। অনুমতিগুলো এই টেবিলে আছে: [আপনার টেবিল পেস্ট করুন]। একটি সার্ভার-সাইড can(user, action, resource) হেল্পার বানাও, ডিফল্টে প্রত্যাখ্যান করো, এবং প্রতিটি API রুটে ব্যবহার করো। প্রতিটি কোয়েরি organization_id দিয়ে সীমিত করো। UI-তে ব্যবহারকারী যা করতে পারবে না তা লুকাও, কিন্তু নিরাপত্তার জন্য সেটির ওপর কখনো নির্ভর করো না।

এই অ্যাপের প্রতিটি API রুট ও সার্ভার ফাংশন পর্যালোচনা করো। প্রতিটির জন্য তালিকা করো কোন ডাটা পড়ে বা বদলায়, ব্যবহারকারী লগইন করা কি না যাচাই করে কি না, তার রোল যাচাই করে কি না, এবং কোয়েরি তার প্রতিষ্ঠানে সীমিত করে কি না। যেখানে যাচাই নেই সেখানে ঠিক করো, আর তালিকাটি আমাকে দেখাও।

শুধু owner যেন রোল বদলাতে পারে, এমন একটি admin-only /admin পেজ যোগ করো। শেষ owner-কে সরানো বা অবনমিত করা আটকাও, প্রতিটি রোল বদলের জন্য কে ও কখন করেছে তা লগ করো, আর owner নয় এমন কাউকে রোল-বদল এন্ডপয়েন্ট প্রত্যাখ্যান করতে দাও।

সাধারণ ভুল

• শুধু ফ্রন্ট এন্ডে রোল যাচাই। API তবু যে কেউ কল করতে পারে।
• ক্লায়েন্টের দেওয়া ID বিশ্বাস করা — সেশনের বদলে রিকোয়েস্ট বডিতে userId বা role।
• সীমাহীন কোয়েরি যা শুধু রেকর্ড ID দিয়ে আনে।
• পেজে রোল যাচাই, কিন্তু API রুট, এক্সপোর্ট, ফাইল ডাউনলোড বা ওয়েবহুকে নয়।
• কোডে হার্ড-কোড করা ইমেইল দিয়ে admin (if email === 'me@...'), যা ভুলে যাওয়া সহজ এবং বদলানো কঠিন।
• খুব আগে অনেক রোল, যা ছয় মাস পরে কেউ ব্যাখ্যা করতে পারে না।
• পুরোনো সেশন: অবনমিত ব্যবহারকারী লগআউট না করা পর্যন্ত admin অধিকার রাখে। সংবেদনশীল কাজে ডাটাবেস থেকে রোল যাচাই করুন, বা রিফ্রেশ করুন।

RBAC চেকলিস্ট

• সাধারণ ভাষায় অনুমতির টেবিল লেখা, প্রান্তিক ক্ষেত্রগুলো ঠিক করা
• সার্ভার সেশন থেকে ব্যবহারকারীকে চেনে, কখনো রিকোয়েস্টের ডাটা থেকে নয়
• রোল ডাটাবেসে সংরক্ষিত; ব্যবহারকারী নিজের রোল বদলাতে পারে না
• একটিমাত্র কেন্দ্রীয় অনুমতি যাচাই, ডিফল্টে প্রত্যাখ্যান, প্রতিটি রুটে ব্যবহৃত
• প্রতিটি কোয়েরি ব্যবহারকারীর প্রতিষ্ঠান বা মালিকানায় সীমিত
• ব্রাউজার যেখানে ডাটাবেসে পৌঁছাতে পারে সেখানে row-level security
• UI ব্যবহারকারী যা করতে পারবে না তা লুকায় (শুধু ব্যবহারযোগ্যতার জন্য)
• সংবেদনশীল কাজ লগ করা
• প্রতিটি রোল পরীক্ষিত, সরাসরি API কল ও বদলানো ID সহ

অ্যাক্সেস কন্ট্রোল একটি দীর্ঘ তালিকার একটি আইটেম; বাকিটা জানতে AI দিয়ে বানানো অ্যাপের নিরাপত্তা চেকলিস্ট দেখুন। আপনি যদি আপনার নিজের কর্মীদের জন্য একটি টুল বানান, তাহলে কীভাবে একটি অভ্যন্তরীণ টুল বানাবেন দেখায় রোল কোথায় বসে।

Mythex-এ RBAC

Mythex আপনার অ্যাপের ব্যবহারকারীদের জন্য কোনো বিল্ট-ইন লগইন বা রোল সিস্টেম দেয় না। আপনি একটি অথ লাইব্রেরি বা প্রোভাইডার বেছে নেন এবং রোলগুলো বর্ণনা করেন, আর এজেন্ট সেগুলো আপনার কোডে ও প্রজেক্টের Postgres ডাটাবেসে যুক্ত করে (অ্যাপে লগইন যোগ করুন)। Mythex-এর নিজস্ব ওয়ার্কস্পেস রোল, যেমন Owner ও Member, নিয়ন্ত্রণ করে কে আপনার Mythex প্রজেক্ট সম্পাদনা করতে পারবে, প্রকাশিত অ্যাপটি কে ব্যবহার করতে পারবে তা নয়। বানানোর আগে অনুমতির টেবিল ঠিক করতে Plan mode ব্যবহার করুন, তারপর ওপরের রিভিউ প্রম্পট ব্যবহার করুন এবং পাবলিশ করার আগে Preview-তে প্রতিটি রোল পরীক্ষা করুন। ডক্সের নিরাপত্তা প্রম্পট পরবর্তী ধাপের জন্য কাজে লাগবে।

প্রশ্নোত্তর