মাল্টি-টেন্যান্ট SaaS অনুমতি সহজভাবে ব্যাখ্যা: সংগঠন, টিম, রোল ও মালিকানা নীতিসহ নিরাপদভাবে স্কেল করা যায় এমন চেকলিস্ট ও উদাহরণ।

অনুমতির সমস্যা সাধারণত ছোট ছোট বিরক্তি হিসেবে শুরু করে। একটি টিকিট আসে: “আমি অ্যাডমিন, কিন্তু ইনভয়েস দেখতে পারছি না।” আরেকটা: “আমার teammate কেন সেটিংস এডিট করতে পারছে?” মানুষ ক্লিক করে, অনুমান করে, এবং অনেক সময় একাধিক লোক একই “owner” লগইন শেয়ার করে কারণ তা ঘন্টা কাটানোর চেয়ে দ্রুত মনে হয়।
তখন ওয়ার্কঅ্যারাউন্ড জমে যায়। টিমগুলো এমন রোল তৈরি করে যেমন “Admin 2” বা “Manager (no delete)”。 ইঞ্জিনিয়াররা এককালীন চেক যোগ করে যেমন “if user is in Sales, allow export” কারণ তা আজকের বাগ ফিক্স করে। এক মাস পরে, কেউই বলতে পারে না কোন নিয়মগুলো উদ্দেশ্যমূলক আর কোনগুলো দুর্ঘটনাজনিত।
আরো খারাপ হয় যখন আপনি আরও কাস্টমার যুক্ত করেন। একটি রুল যা এক কোম্পানির জন্য ঠিক ছিল (“admins can see all data”) তা ভেঙে পড়ে যখন আপনার হাতে শত শত ভিন্ন প্রত্যাশার org আসে। কেউ চাইতে পারেন ডিপার্টমেন্টগুলোর মধ্যে কঠোর পৃথকীকরণ। কেউ চাইতে পারেন শেয়ার করা ওয়ার্কস্পেস। কেউ চাইতে পারেন কন্ট্রাক্টরকে কেবল একটি প্রজেক্টে অ্যাক্সেস দিতে এবং অন্যকিছু নয়। যদি আপনার মডেল স্পষ্ট না হয়, প্রতিটি নতুন কাস্টমার একটি নতুন exception হয়ে ওঠে।
লক্ষ্যটা সহজ: পূর্বানুমেয় অ্যাক্সেস নিয়ম যা এক মিনিটে বোঝানো যায়। উদাহরণ: “আপনার org ডেটার মালিক। টিম লোককে গ্রুপ করে। রোল কাজগুলো নির্ধারণ করে। রিসোর্স একটি org-কে প্রকাশ্যভাবে হার্ডবাইন্ড করে, কখনও কখনও একটি টিমকেও। শেয়ারিং কয়েকটি ডিফল্ট অনুসরণ করে।” যদি আপনি এটা সরলভাবে বলতে না পারেন, তা বানানো, টেস্ট করা এবং বদলানো কঠিন হবে।
একটি রাখা প্রতিশ্রুতি: কম রোল, স্পষ্ট মালিকানা, নিরাপদ ডিফল্ট। বাস্তব কাজের সাথে সংযুক্ত একটি ছোট রোল সেট দিয়ে শুরু করুন, প্রতিটি রিসোর্সের মালিকানা স্পষ্ট রাখুন, এবং ডিফল্ট হিসেবে ন্যূনতম অ্যাক্সেস দিন। তারপর উদ্দেশ্যপ্রণোদিতভাবে শেয়ারিং অনুমতি দিন, দুর্ঘটনায় নয়।
আপনার অ্যাপ যদি একাধিক কাস্টমার সার্ভ করে, নিয়ম লেখার আগে মানসিক মানচিত্র ঠিক করুন। মাল্টি-টেন্যান্ট SaaS অনুমতিতে অধিকাংশ বিভ্রান্তি আসে সংজ্ঞার ভিন্নতায়—একই শব্দ প্রোডাক্টের বিভিন্ন অংশে ভিন্ন অর্থে ব্যবহৃত হয়।
আপনার টেন্যান্ট বাউন্ডারি জন্য একটি অর্থ নির্ধারণ করুন এবং সেটায় আটকে থাকুন। অনেক প্রোডাক্ট “organization” ব্যবহার করে টেন্যান্ট হিসেবে: সমস্ত ডেটা একটি org-এর ভেতর থাকে, এবং স্পষ্টভাবে শেয়ারিং না বানালে কিছুই ওই লাইন পার হয় না।
একটি সহজ শব্দভাণ্ডার যা বড় হলে ও পরিষ্কার থাকবে:
"এক ব্যক্তি, বহু org" স্বাভাবিক। একজন কনসালট্যান্ট তিনটি কাস্টমার org-এ থাকতে পারে, প্রতিটিতে ভিন্ন রোল। এজন্যই “user” এবং “membership” আলাদা থাকা উচিত। সাধারণত আপনার চেকগুলো membership-এ নির্ভর করে, user-এ নয়।
টিম তখনই কাজে আসে যখন তা বাস্তব গ্রুপিং প্রতিফলিত করে, যেমন “Support” বা “Finance।” যখন টিম দ্বিতীয় অনুমতি সিস্টেম হয়ে যায় তখন তা গোলযোগ বাড়ায়। একটি সহজ পরীক্ষা: আপনি কি এক বাক্যে টিমটি ব্যাখ্যা করতে পারবেন, কোন নির্দিষ্ট ফিচার রুল উল্লেখ না করে?
উদাহরণ: Maria একবার লগইন করে, তারপর Org A এবং Org B-এর মধ্যে সুইচ করে। Org A-তে তিনি Finance-এ আছেন এবং ইনভয়েস দেখতেও পারেন। Org B-তে তিনি Viewer এবং কেবল প্রজেক্ট পড়তে পারেন। একই ইউজার, ভিন্ন memberships, ধারাবাহিক রিসোর্স টাইপ, স্পষ্ট সীমা।
মাল্টি-টেন্যান্ট SaaS অনুমতি তখনই বোঝার যোগ্য থাকে যখন আপনি তিনটি জিনিস আলাদা রাখেন:
RBAC (role-based access control) মানে: আপনি একটি ইউজারকে একটি রোল দেন, এবং সেই রোল অনুমোদিত অ্যাকশনগুলো দেয়। রোলের নামগুলোর মধ্যে দায়িত্ব বর্ণনা থাকা উচিত, অবস্থা নয়। “Billing Admin” স্পষ্ট। “Power User” সাধারণত বিতর্ক তৈরি করে।
Permissions-গুলোকে ক্রিয়াপদের মতো আচরণ করুন এবং প্রোডাক্ট জুড়ে সঙ্গত রাখুন:
তারপর একই ক্রিয়াকে বিভিন্ন জায়গায় প্রযোজ্য করার জন্য scope যোগ করুন। এভাবে আপনি ২০টি একটু ভিন্ন রোল তৈরির ঝামেলা এড়াবেন।
সাধারণ যে স্কোপগুলো পাঠযোগ্য থাকে:
যদি আপনি দেখেন নিজেকে এমন রোল বানাতে — “Project Editor” এবং “Project Editor (Own)” — এটি সাধারণত রোল সমস্যা নয়, বরং স্কোপ সমস্যা।
উদাহরণ: ஒரு CRM-এ, “Sales Rep” কে ডিল তৈরি ও সম্পাদনা করার অনুমতি দিন, কিন্তু স্কোপ সীমাবদ্ধ রাখুন “own items” এ। “Sales Manager” কে একই ক্রিয়াগুলো দিন কিন্তু “team-only” বা “org-wide” স্কোপ সহ। এতে আপনি কম রোল পাবেন, নিয়মগুলো স্পষ্ট থাকবে, এবং কেউ টিম বদলালে অপ্রত্যাশিতা কম হবে।
একটি ভালো ডিফল্ট: রোলগুলো ক্রিয়া দেয়, এবং ownership (বা assignment) ঠিক করে কোথায় সেই ক্রিয়াগুলো কাজ করবে।
যদি আপনার মডেল একটি কাস্টমারের জন্য কাজ করে কিন্তু দশে ভেঙে যায়, সম্ভবত আপনি “কারা দেখবে” ও “কারা করতে পারবে” এবং “কে মালিক” একত্র মিশিয়ে ফেলেছেন। এগুলো আলাদা রাখুন, সিস্টেমটা পূর্বানুমেয় থাকবে।
একটি নিয়ম সেট যা স্কেল করে:
উদাহরণ: Sam Org A এবং Org B-এ সদস্য। Org A-তে Sam একজন Member এবং নিজের রিপোর্ট তৈরি ও সম্পাদনা করতে পারে কিন্তু বিলিং পরিবর্তন করতে পারে না। Org B-তে Sam একজন Billing Manager এবং পেমেন্ট পদ্ধতি আপডেট ও ইনভয়েস ডাউনলোড করতে পারে, কিন্তু তখনও ব্যক্তিগত বা প্রাইভেট প্রজেক্ট দেখতে পারবে না যদি তাদের সদস্যপদ সেই ক্ষেত্র অন্তর্ভুক্ত না করে।
এতে বৃদ্ধি একধরনের ‘বোরিং’ হয়ে যায় — ভাল অর্থে। একটি নতুন org যোগ করা মানে কেবল membership ও রোল যোগ করা। মূল নিয়মগুলো একই থাকে।
একটি পৃষ্ঠার নথি লিখুন যা একজন সহকর্মী দুই মিনিটে পড়ে বুঝতে পারে। যদি আপনি কোড না খুলেই পারমিশন ব্যাখ্যা করতে পারেন, আপনি ভালো পথে আছেন।
এগুলোকে সীমিত রাখুন:
স্কোপ ব্যবহার করে রোল বিস্তার এড়ান। অনেক প্রোডাক্টে মাত্র তিনটি স্কোপই লাগে: own, team, org।
| Role | View | Edit | Invite users | Billing | Scope note |
|---|---|---|---|---|---|
| মালিক (Owner) | Yes | Yes | Yes | Yes | Org-wide, মালিকানা ট্রান্সফার করতে পারে |
| অ্যাডমিন (Admin) | Yes | Yes | Yes | No/Yes | Org-wide, মালিকানা পরিবর্তন নয় |
| সদস্য (Member) | Yes | Limited | No | No | Own + team (যেখানে অ্যাসাইন করা) |
| দর্শক (Viewer) | Yes | No | No | No | Read-only নির্দিষ্ট স্কোপে |
স্যানিটি চেক: এই পেজটা একজন নন-টেক সহকর্মীর কাছে দেখান এবং জিজ্ঞেস করুন, “একজন Support সদস্য কি Sales রিপোর্ট এডিট করতে পারে?” যদি তারা হেজিটেট করে, আপনার স্কোপ বা টিম সংজ্ঞা স্পষ্ট নয়।
পারমিশন বোঝার যোগ্য রাখতে, প্রতিটি রিসোর্সের মালিক কে তা নির্ধারণ করুন, তারপর শেয়ারিং অপশনগুলো সীমিত রাখুন।
অধিকাংশ রিসোর্সকে org-ওয়ান করা উচিত। কাস্টমাররা সাধারণত কোম্পানি হিসেবে চিন্তা করে: ইনভয়েস, প্রজেক্ট, কন্টাক্ট, টিকিট এবং অটোমেশনগুলো সংগঠনের মালিকানা — ব্যক্তির নয়।
টিম এখনও দরকারি হতে পারে, কিন্তু টিমকে একটি ওয়ার্কফ্লো লেবেল হিসেবে বিবেচনা করুন — রুটিং ও ভিজিবিলিটি ডিফল্ট ঠিক করতে, কঠিন নিরাপত্তা লজিক হিসেবে নয়। একটি টিম ট্যাগ ফিল্টার, ড্যাশবোর্ড, নোটিফিকেশন বা কিউ চালাতে পারে, এমনকি যখন অ্যাক্সেস রোল ও স্কোপ থেকে আসে।
ইউজার-ওয়ান রিসোর্সগুলো ব্যতিক্রম হওয়া উচিত: ড্রাফট, ব্যক্তিগত নোট, সেভড ভিউ, API টোকেন, বা ব্যক্তিগত সেটিংস — যেগুলো সত্যিই ব্যক্তিগত। কেউ বেরিয়ে গেলে কি হবে সেটাও নির্ধারণ করুন: মুছে ফেলা হবে, ট্রান্সফার করা হবে, না রেখে দেওয়া হবে?
শেয়ারিং নিয়মের একটি ছোট সেট যা পাঠযোগ্য থাকে:
যখন কেউ বলে “আমাকে অ্যাক্সেস দরকার,” জোর দিন যে কোন লেভেল: তাদের ব্যক্তিগত আইটেম, তাদের টিমের কাজ, না পুরো org। যদি তিনটোর মধ্যে না পড়ে, সাধারণত সেটা নির্দেশ করে আপনার স্কোপ অস্পষ্ট, নতুন শেয়ারিং মোড দরকার নয়।
উদাহরণ: একটি সাপোর্ট টিকিট org-owned হতে পারে (যাতে ম্যানেজাররা সব টিকিট রিপোর্ট করতে পারে), Support টিম-ট্যাগ থাকতে পারে (যাতে এটি সঠিক কিউতে দেখায়), এবং Jordan-কে অ্যাসাইন করা থাকতে পারে (প্রস্তুতিমূলকভাবে Jordan দায়িত্বশীল)। অ্যাসাইনমেন্ট অন্য অনুমোদিত রোলগুলোকে দেখার থেকে বাধা দেয় না।
অনুমতি প্রায়ই “মানুষ ইভেন্ট”-এ ভাঙ্গে: কাউকে আমন্ত্রণ করা, টিম বদলানো, বা অ্যাক্সেস সরিয়ে ফেলা। এই ফ্লোগুলোই নির্ধারণ করে আপনার মডেল পূর্বানুমেয় থাকে কি না।
আমন্ত্রণকে একটি সদস্যপদ তৈরি করার অনুরোধ হিসেবে আচরণ করুন, নিজে থেকেই অ্যাক্সেস নয়। আমন্ত্রণে থাকা উচিত স্পষ্ট: org, টিম (ঐচ্ছিক), এবং রোল যা স্বীকার করলে দেওয়া হবে।
নিয়ম কঠোর রাখুন:
অস্থায়ী অ্যাক্সেসও এখানে ফিট করে। “টেম্প ইউজার” রোল বানানোর বদলে, রোল গ্রান্টকে একটি শেষ দিনের তারিখ দেবার অপশন দিন। যখন তা আসে, অ্যাক্সেস аўটোমেটিক্যালি বাদ পড়বে এবং অডিট ট্রেইল পরিষ্কার থাকবে।
###Leaving/Join এবং মালিকানা না হারানো
যখন কেউ org ছেড়ে যায়, তাদের রিসোর্স নিয়ে অনুমান করবেন না। যদি আপনার নিয়ম “রিসোর্স org-owned” হয়, সেটাতেই লেগে থাকুন। ব্যক্তিটি ইতিহাসে কেবল ক্রিয়েটর হিসেবে থাকতে পারেন, কিন্তু org মালিক থাকা উচিত।
যদি আপনার কাছে ইউজার-ওয়ান রিসোর্স থাকে, সংবেদনশীল কিছুর জন্য অপসারণের আগে ট্রান্সফার বাধ্যতামূলক করুন (প্রজেক্ট, ডকুমেন্ট, API কী)।
একই লগইন বহু org-এ থাকতে পারে, কিন্তু অ্যাপে সবসময় একটি “কারেন্ট org” থাকতে হবে। UI-তে এটা স্পষ্ট করুন এবং প্রতিটি অ্যাকশনকে সেটির মধ্যে স্কোপ করুন।
ডিএক্টিভেশন সাধারণত ডিলিশনের চেয়ে ভালো। এটি এখনই অ্যাক্সেস বাদ দেয় এবং অতীত কার্যকলাপ অডিটেবল রাখে।
অধিকাংশ পারমিশন মডেল ব্যর্থ হয় কারণ তারা নিয়মের চেয়ে দ্রুত বেড়ে যায়। বুনিয়াদি রক্ষা করুন (tenant boundary, ownership, scope) এবং বাকিটা বিস্তারিত হিসেবে বিবেচনা করুন।
Role explosion ক্লাসিক ফাঁদ। একটি এজ কেস দেখলে আপনি নতুন রোল তৈরি করেন পরিবর্তে একটি স্পষ্ট পারমিশন বা স্কোপ রাখার। কয়েক মাস পর, কেউ জানে না “Manager Plus” মানে কি। যদি একটি বিশেষ কেস প্রায়ই লাগে, এটাকে প্রথম-শ্রেণীর পারমিশন বানান। যদি খুব ব্যতিক্রমী, অস্থায়ী গ্রান্ট দিয়ে হ্যান্ডেল করুন যা মেয়াদ শেষ হলে উঠে যায়।
Permission drift চুপচাপ কিন্তু খারাপ। কেউ “একটি ব্যতিক্রম” যোগ করে এবং একে ভুলে যায়। এক বছর পরে, লিখিত নীতি ও বাস্তব সিস্টেম ভিন্ন হয়ে পড়ে। নীতি প্রথমে আপডেট করুন, তারপর ইমপ্লেমেন্ট করুন।
Teams কে ভুয়া নিরাপত্তা সীমা বানানো নিয়মিত বিভ্রান্তি তৈরি করে। যদি রিসোর্সগুলো org-এর ভিতরে টিমগুলোর মধ্যে শেয়ার হতে পারে, সেটি স্পষ্টভাবে বলুন। না পারলে, কোডে জোর দিন, নামকরণে নয়।
শুরুতেই ধরা পড়বার সংকেত:
সাপোর্টকে সাহায্য করতে গেলে “তাদেরকে গ্লোবাল অ্যাডমিন দিন এক মিনিটের জন্য” একটি tenant leak হওয়ার অপেক্ষায়। স্পষ্ট, লগ করা অ্যাক্সেস পছন্দ করুন যার কঠোর স্কোপ (এক org, নির্দিষ্ট সময়, নির্দিষ্ট অ্যাকশন)।
প্রতি অনুরোধে প্রথমে সক্রিয় organization রেজল্ভ করুন (subdomain, header, session, বা route থেকে) এবং যা ম্যাচ করে না তা reject করুন।
org context-র পরে চেকগুলো একটি নির্দিষ্ট ক্রমে রাখুন: প্রথমে membership (তারা কি এই org-এর সদস্য?), তারপর role (এই org-এ তারা কি করতে পারে?), তারপর ownership বা sharing (এই রেকর্ডে তাদের কি অ্যাক্সেস আছে?)। যদি ownership চেক membership-এর আগে করেন, আপনি বিদ্যমান কী আছে তা সম্পর্কে তথ্য লিক করতে পারেন।
কিছু ইন্ড-টু-ইন্ড টেস্ট চালান বাস্তব অ্যাকাউন্ট ব্যবহার করে, শুধু ইউনিট টেস্ট নয়:
সেন্সিটিভ কাজগুলোর জন্য বেসিক অডিট ইভেন্ট যোগ করুন: রোল পরিবর্তন, সদস্যপদ অপসারণ, এক্সপোর্ট, ডিলেট, সেটিংস আপডেট। ডে-ওয়ান-এ পারফেক্ট থাকার দরকার নেই, কিন্তু “কে কী করলো, কখন” উত্তর দিতে পারবে।
ডিফল্টগুলো রিভিউ করুন। নতুন org ও নতুন সদস্যদের শুরুতেই ন্যূনতম অ্যাক্সেস দিন যা এখনও তাদের সফল হতে দেয়। সাপোর্ট ও সেলসের জন্য একটি ছোট ইনটার্নাল পারমিশন FAQ থাকাও সাহায্য করে, উদাহরণ: “একজন টিম লিড কি অন্য টিম দেখতে পারে?” এবং “কোনো ব্যবহারকারী অপসারণের পর কি হয়?”
একটি ছোট, বাস্তব সেটআপ দিয়ে শুরু করুন: একটি কাস্টমার কোম্পানি (এক org) দুইটি টিম সহ, Sales এবং Ops। সবাই একবার সাইন-ইন করে এবং তারপর তারা কোন org-এ আছে সেটা বেছে নেয়। Sales কে কাস্টমার রেকর্ড ও কোটস দরকার। Ops-কে বিলিং ও ইন্টারনাল সেটিংস দরকার।
টিমগুলোকে গ্রুপিং ও ওয়ার্কফ্লো হিসেবে রাখুন, প্রধান অনুমতি সুইচ হিসেবে নয়। তারা ডিফল্ট ও রুটিং প্রভাব ফেলতে পারে, কিন্তু একমাত্র গেট হতে দেয়া উচিত নয়।
একটি ছোট রোল সেট বেছে নিন এবং ফিচার আসলেও সেগুলো স্থির রাখুন: Admin, Member, Viewer। রোলের উত্তরটি: “এই org-এ তুমি কি করতে পারো?” স্কোপ উত্তরটি: “কোথায় তুমি তা করতে পারো?”
একটি মালিকানা নিয়ম যোগ করুন: প্রতিটি রিসোর্সের একটি org এবং একটি owner (প্রায়ই ক্রিয়েটর) থাকে। এডিট করা যাবে যদি তুমি Admin হও বা যদি তুমি owner হও এবং তোমার রোলে “edit own” থাকে। দেখা যাবে যদি তোমার রোলে “view” থাকে সেই রিসোর্স টাইপের জন্য।
উদাহরণ: একজন Sales Member একটি কোট তৈরি করে। অন্য একজন Sales Member সেটা দেখতে পারে, কিন্তু তখনই এডিট করতে পারবে যদি সেটা টিমের সাথে শেয়ার করা হয় বা reassigned করা হয়। একটি Ops Viewer কেবল তখনই দেখতে পারবে যদি আপনার নিয়ম Ops-কে Sales রিসোর্স দেখার অনুমতি দেয়।
আপনি যখন ২০০ কাস্টমার org অনবোর্ড করবেন, আপনি একই রোল ও একই মালিকানা নিয়ম পুনরায় ব্যবহার করবেন। আপনি membership পরিবর্তন করবেন, মডেল নয়।
সাপোর্ট রিকুয়েস্টগুলোর উত্তর এখন একটি চেকলিস্ট হয়ে যাবে: org ও রিসোর্স নিশ্চিত করুন, ব্যবহারকারীর রোল সেই org-এ চেক করুন, মালিকানা ও শেয়ারিং চেক করুন, তারপর রোল বদলান বা রিসোর্স শেয়ার করুন। এক-অফ exception এড়িয়ে চলুন এবং অডিট নোট রাখুন।
আপনার এক-পেজ মডেলকে একটি কন্ট্র্যাক্ট হিসেবে দেখুন। কেবল সেই নিয়মগুলো ইমপ্লিমেন্ট করুন যেগুলো আপনি প্রতিটি API কল ও প্রতিটি UI স্ক্রিনে পূরণ করতে পারবেন, নচেৎ পারমিশন “it depends” হয়ে যাবে।
ছোটে শুরু করুন: কয়েকটি রোল, স্পষ্ট স্কোপ, এবং সরল মালিকানা। যখন একটি নতুন অনুরোধ আসে (“Can we add an Editor-Manager role?”), প্রথমে ownership বা scope কঠোর করুন। নতুন রোল বিরল হওয়া উচিত।
প্রতিটি নতুন রিসোর্সের জন্য মূলগুলো সঙ্গত রাখুন:
org_id সংরক্ষণ করে (এবং প্রয়োজনে team_id)প্রান্তিক কেসগুলোতে পলিশ করার আগে বাস্তব ফ্লো গুলো টেস্ট করুন: আমন্ত্রণ, org সুইচ, অ্যাডমিন পেজ, এবং কেউ মাঝখানে অ্যাক্সেস হারালে কি হয় তা পরীক্ষা করুন।
যদি আপনি একটি চ্যাট-ভিত্তিক অ্যাপ বিল্ডার দিয়ে তৈরি করছেন, প্রথমে পারমিশন মডেলটি সহজ ভাষায় লিখে প্রোডাক্ট স্পেসের পাশে রাখলে সাহায্য করে। Koder.ai (koder.ai)-এ Planning Mode প্লাস স্ন্যাপশট ও রোলব্যাক এগুলো ট্রায়াল করার এবং নিশ্চিত করার ব্যবহারিক উপায় হতে পারে যে নিয়মগুলো ওয়েব, ব্যাকএন্ড এবং মোবাইলে একইভাবে কাজ করছে।