ভূমিকা ও অনুমতি: ব্যবসায়িক উদাহরণের সঙ্গে স্পষ্ট নিয়ম

প্রকৃত সমস্যা: এমন ডেটা দেখা যা দেখা উচিত নয়

কাজে একটি “ডেটা লিক” প্রায়ই নীরসভাবে দেখা যায়। একজন সাপোর্ট এজেন্ট গ্রাহক প্রোফাইল খুললে পুরো পেমেন্ট ইতিহাস দেখে ফেলে। একজন ক্লায়েন্ট লগইন করে দেখল ভিতরকার নোট যেমন “অভিযোগ করলে ২০% অফার কর” বা চালানের প্রকৃত খরচ ও মার্জিন। কাউকে পাসওয়ার্ড চুরি করে নি—অ্যাপটাই ভুল জিনিসটা দেখিয়ে দিয়েছে।

বেশিরভাগ লিক দুর্ঘটনাজনিত। অনুমতিগুলো পরে যোগ হয়, নতুন স্ক্রীন দ্রুত চালু করা হয়, বা কেউ পরীক্ষার জন্য “পর্যাপ্ত” বলা একটি পুরোনো রোল কপি করে ফেলে। তারপর একটি ছোট পরিবর্তন, যেমন একটি নতুন ফিল্ড টেবিলে যোগ করা, চুপিচুপি সবার কাছে দৃশ্যমান হয়ে যায়।

সেজন্য ভূমিকা ও অনুমতিকে অ্যাপে প্রথম শ্রেণীর অংশ বানানো উচিত, শেষ মূহুর্তের চেকবক্স নয়। বেশিরভাগ ছোট ব্যবসায় একই চার ধরণের রোল দেখা যায়: Owner, Manager, Staff, এবং Client।

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

আপনি যদি দ্রুত একটি নো-কোড প্ল্যাটফর্মে যেমন AppMaster (appmaster.io) এ তৈরি করেন, তাহলে এটা আরও বেশি গুরুত্বপূর্ণ। গতি ভালো, কিন্তু একই সঙ্গে যদি অ্যাক্সেস প্রথম থেকেই ডিজাইন না করা থাকে তাহলে ব্যক্তিগত নোট, মূল্য নির্ধারণের নিয়ম, বা অন্য গ্রাহকদের রেকর্ড সহজেই উন্মোচিত হতে পারে।

ভূমিকা, অনুমতি এবং স্কোপ: সহজ সংজ্ঞা

রোল এবং অনুমতিগুলোই নিয়ম নির্ধারন করে যে অ্যাপের ভেতরে কে কী করতে পারবে।

• একটি রোল হলো কাজের লেবেল যেমন Owner, Manager, Staff, বা Client।
• অনুমতিগুলো হলো সেই নির্দিষ্ট ক্রিয়াগুলো যা ওই রোল করতে পারে।

একটি অ্যাক্সেস লেভেল হলো ঐ নিয়মগুলির ব্যবহারিক ফলাফল। দুইজনই “Staff” হতে পারে, কিন্তু একজনের উচ্চতর অ্যাক্সেস লেভেল থাকে কারণ সে রিফান্ড অনুমোদন করতে পারে আর অন্যজন পারে না।

ভুল প্রতিরোধের একটি নির্ভরযোগ্য উপায় হলো সর্বনিম্ন অ্যাক্সেস দিয়ে শুরু করা, তারপর কেবল যা দরকার তা যোগ করা। কেউ যদি কখনও ইনভয়েস সম্পাদনা না করে, তখন "হয়তো আরেকটু দেওয়া যাক" বলে এডিট রাইট দেবেন না। পরে অ্যাক্সেস যোগ করা সহজ—একটি ডেটা লিকই অনুলিপি করা কঠিন।

বেশিরভাগ অনুমতি কয়েকটি ক্রিয়ায় সঙ্কীর্ণ: view, create, edit, delete, এবং কয়েকটি উচ্চ-ঝুঁকিপূর্ণ কাজ যেমন export বা approve।

স্কোপ আরেকটি প্রশ্নের উত্তর দেয়: "তারা কোন রেকর্ডগুলিতে সেই কাজগুলো করতে পারবে?" কেও হয়তো ইনভয়েস দেখতে পারবে, কিন্তু কেবল তাদের নিজের, সবার নয়।

সাধারণ স্কোপ প্যাটার্নগুলো:

• নিজের রেকর্ড (শুধু তারা যে আইটেমগুলি তৈরি করেছে বা যেগুলো তাদের কাজ হিসেবে দেওয়া হয়েছে)
• টিম বা লোকেশন (তাদের শাখা, ডিপার্টমেন্ট, বা প্রজেক্ট)
• পুরো কোম্পানি (ব্যবসার সব রেকর্ড)

একজন সেলস রিপ তাদের নিজস্ব কোট তৈরি ও দেখতে পারে, কিন্তু পুরো গ্রাহক তালিকা রপ্তানি করতে পারবে না। একজন সেলস ম্যানেজার পুরো টিমের কোট দেখতে পারে এবং ডিসকাউন্ট অনুমোদন করতে পারে। Owner সবকিছু দেখতে পারে এবং একাউন্টিংয়ের জন্য রিপোর্ট রপ্তানি করতে পারে।

Owner, Manager, Staff, এবং Client সাধারণত কী প্রয়োজন

বেশিরভাগ অ্যাপে একই চারটি ব্যবহারকারী গোষ্ঠী হয়ে থাকে। বিস্তারিত আলাদা হবে, কিন্তু প্যাটার্ন থাকবে। যদি আপনি পরিষ্কার রোল ও অনুমতি দিয়ে শুরু করেন, পরে অনেক অস্বস্তিকর “কেন তারা এটা দেখছে?” মুহূর্ত এড়ানো যায়।

Owner সাধারণত পুরো ব্যবসার উপর পূর্ণ দৃশ্যমানতা প্রয়োজন। এতে বিলিং, সিকিউরিটি সেটিংস (পাসওয়ার্ড নিয়ম ও MFA মতো), এবং অডিট হিস্ট্রি অন্তর্ভুক্ত থাকে যাতে তারা দেখতে পারে কে কী এবং কখন বদলেছে।

Manager কে পুরো প্রশাসক বানানো ছাড়াই একটি টিম চালাতে হবে। তাদের সাধারণত ওভারসাইটের প্রয়োজন (তাদের ডিপার্টমেন্টে সবকিছু দেখা), অনুমোদন (ডিসকাউন্ট, রিফান্ড, ছুটি, কনটেন্ট পরিবর্তন) এবং রিপোর্ট পড়া। তাদের সীমিত অ্যাডমিন কাজের প্রয়োজন হতে পারে, যেমন স্টাফ আমন্ত্রণ বা পাসওয়ার্ড রিসেট, কিন্তু বিলিং বা গ্লোবাল সিকিউরিটি কন্ট্রোলের অ্যাক্সেস থাকা উচিত নয়।

Staff দ্রুত দৈনন্দিন কাজ করতে পারা উচিত, ঝুঁকি কমিয়ে। একটা নিরাপদ ডিফল্ট হলো “শুধু যা আমার কাছে নির্ধারিত।” একটি সাপোর্ট এজেন্ট কেবল তাদের টিকেট দেখবে, একটি ডিসপ্যাচার কেবল আজকের রুট দেখবে, এবং একজন সেলসপারসন কেবল তাদের লিড। রপ্তানি এবং বাল্ক ডাউনলোড ডিফল্টভাবে বন্ধ থাকা উচিত এবং শুধুমাত্র প্রকৃত প্রয়োজন দেখা গেলে অন করা উচিত।

Client কেবল তাদের নিজের ডেটা দেখবে, এমনকি যদি একাধিক মানুষ একই অ্যাকাউন্ট ব্যবহার করে। তাদের সীমিত ক্রিয়াগুলি করতে দিন (রিকোয়েস্ট তৈরি করা, চালান পরিশোধ করা, প্রোফাইল আপডেট করা), কিন্তু ইন্টারনাল নোট, স্টাফ কমেন্ট এবং স্টাফ-ওয়ান স্ট্যাটাস গোপন রাখুন।

একটি সাধারণ ডিফল্ট যা অনেক ব্যবসায় কাজ করে:

• Owner: সবকিছু, বিলিং, সিকিউরিটি, এবং অডিট লোগ সহ
• Manager: টিম ডেটা, অনুমোদন, রিপোর্টিং, সীমিত ইউজার ম্যানেজমেন্ট
• Staff: কেবল নির্ধারিত রেকর্ড, কোন বাল্ক এক্সপোর্ট নেই, কোন অ্যাডমিন সেটিংস নেই
• Client: কেবল তাদের রেকর্ড, ইন্টারনাল নোট নেই, সীমিত ক্রিয়াগুলি

স্ক্রীনের বদলে ডেটা টাইপ অনুযায়ী অ্যাক্সেস ভাগ করুন

অনেক দল স্ক্রীন অনুযায়ী রোল ও অনুমতি সেট করে: “স্টাফ অর্ডার পেজ খুলতে পারবে, ক্লায়েন্ট পারবে না।” এটা সহায়ক, কিন্তু প্রকৃত ঝুঁকি মিস করে। একই ডেটা সার্চ, মন্তব্য, নোটিফিকেশন, রপ্তানি, এবং অ্যাটাচমেন্টেও দেখা যায়।

মেন্যুকে না দেখে আপনার ডেটা এরিয়া তালিকা করে শুরু করুন। উচ্চ-প্রভাব ক্ষেত্রগুলোর মধ্যে সাধারণত গ্রাহক কনট্যাক্ট, অর্ডার ও ডেলিভারি স্ট্যাটাস, চালান ও পেমেন্ট স্ট্যাটাস, বেতন ও HR নোট, এবং ইন্টারনাল নোট বা অ্যানালিটিক্স থাকে।

তারপর প্রতিটি রোলে প্রতিটি ডেটা টাইপে কি করা যায় তা সিদ্ধান্ত নিন: view, create, edit, delete, approve, এবং share। এখানেই ফিল্ড-লেভেল নিয়মগুলো গুরুত্বপূর্ণ। একই অবজেক্টের প্রায়ই পাবলিক ভিউ ও ইন্টারনাল ভিউ লাগে।

উদাহরণ: একটি অর্ডারে গ্রাহকের নাম, ডেলিভারি ঠিকানা, মূল্য, ইন্টারনাল মার্জিন, এবং একটি ইন্টারনাল নোট থাকতে পারে যেমন “গ্রাহক অনেক অভিযোগ করে, ডিসকাউন্ট দিন।” ক্লায়েন্ট ঠিকানা ও স্ট্যাটাস দেখতে পারে, কিন্তু মার্জিন বা ইন্টারনাল নোট কখনোই দেখতে পারবে না। ম্যানেজার সব ফিল্ড সহ ডিসকাউন্ট অনুমোদন করতে পারে। স্টাফ সেই ফিল্ডগুলো দেখবে যা ডেলিভারি করতে প্রয়োজন, কিন্তু ফাইন্যান্স ডিটেইল না।

ফাইল এবং অ্যাটাচমেন্ট অতিরিক্ত সতর্কতার দাবি করে। চুক্তি, আইডি, রসিদ, এবং স্ক্রিনশট প্রায়ই ফর্ম ফিল্ডের চাইতে বেশি সংবেদনশীল তথ্য ধারণ করে। এগুলোকে আলাদা অনুমতিতে ধরুন: কে আপলোড করতে পারে, কে ডাউনলোড করতে পারে, এবং কে ফাইল প্রিভিউ দেখতে পারে। নির্ধারণ করুন অ্যাটাচমেন্ট প্যারেন্ট রেকর্ড (যেমন ইনভয়েস) থেকে অ্যাক্সেস ইনহেরিট করবে কি না, নাকি আলাদা নিয়ম প্রযোজ্য হবে।

সবশেষে, রপ্তানি ও বাল্ক অ্যাকশনগুলোকে "অন্তর্ভুক্ত" ধরে নিবেন না কেবল কারণ কেউ একটি তালিকা দেখতে পারে। সেগুলো স্পষ্ট করুন: CSV/PDF এ রপ্তানি, অ্যাটাচমেন্ট বাল্ক ডাউনলোড, বাল্ক স্ট্যাটাস পরিবর্তন (অনুমোদন, বাতিল, রিফান্ড), বাল্ক মেসেজিং (ইমেইল/SMS/Telegram), এবং এডমিন কাজগুলোর মতো রেকর্ড পুনঃবন্টন।

ব্যবসায়িক উদাহরণ ১: সেলস ও ইনভয়েসিং অ্যাপ

ধরুন একটি ছোট সার্ভিস ব্যবসা: Owner প্রজেক্ট বিক্রি করেন, ম্যানেজার নিয়মিত কাজ তদারকি করেন, স্টাফ কাজ করে, আর ক্লায়েন্ট কোট অনুমোদন ও চালান পরিশোধ করে। অস্বস্তিকর ভুল এড়ানোর দ্রুততম উপায় হলো কেউ লগইন করার আগেই রোল ও অনুমতিতে একমত হওয়া।

শুরু করুন মানি ডিটেইল দিয়ে। মূল্য নির্ধারণ অনেক সময় বেশ কয়েকজনের কাছে দেখা যায় কিন্তু লাভ-হিসাব দেখা যাবে না। একটি প্রচলিত নিয়ম: স্টাফরা কী চার্জ করতে হবে তা দেখতে পাবে, কিন্তু কেন সেই দাম রাখা হয়েছে তা তারা দেখবে না। একজন টেকনিশিয়ান ইনভয়েস লাইনের আইটেমগুলো দেখতে পারেন ব্যাখ্যার জন্য, কিন্তু তারা ইন্টারনাল মার্জিন, সরবরাহকারীর খরচ, বা ডিল জিততে দেওয়া বিশেষ ডিসকাউন্ট দেখতে পারবেন না।

ক্লায়েন্ট ডেটা আরেকটি হটস্পট। অনেক দল চান একাধিক মানুষ যোগাযোগের বিবরণ দেখতে পারে (যাতে সঠিক ব্যক্তিকে কল করা যায়), কিন্তু কেবলই কয়েকজন_EDIT করতে পারে। না হলে দুর্ঘটনায় বিলিং ইমেইল ব্যক্তিগত ইমেইলে বদলে যেতে পারে এবং চালান একাউন্টিংতে পৌঁছানো বন্ধ হয়ে যায়।

একটি সরল সেটআপ যা অনেক টিমের জন্য ভাল কাজ করে:

• Owner: সবকিছু দেখে, মার্জিন ও ডিসকাউন্ট ইতিহাস সহ, এবং পেমেন্ট স্ট্যাটাস পরিবর্তন করতে পারে
• Manager: কোট ও ইনভয়েস তৈরি করতে পারে, ডিসকাউন্ট অনুমোদন করতে পারে, এবং ক্লায়েন্ট কনট্যাক্ট সম্পাদনা করতে পারে
• Staff: নির্ধারিত ক্লায়েন্ট ডিটেইল ও ইনভয়েস লাইনের আইটেম দেখতে পারে, কিন্তু প্রাইসিং নিয়ম সম্পাদনা বা মার্জিন দেখতে পারবেন না
• Client: কেবল তাদের কোট ও ইনভয়েস দেখতে এবং পে বা পরিবর্তনের অনুরোধ করতে পারে

উচ্চ-ঝুঁকিপূর্ণ কাজগুলো লক করে দিন। একটি ইনভয়েসকে পেইড হিসেবে চিহ্নিত করা, রিফান্ড ইস্যু করা, বা পেমেন্ট মেথড বদলানো Owner (বা নির্ভরযোগ্য ফাইন্যান্স রোল) পর্যন্ত সীমাবদ্ধ রাখুন।

ব্যবসায়িক উদাহরণ ২: ইন্টারনাল নোটসহ সাপোর্ট ডেস্ক

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

একটি ছোট ই-কমার্স ব্যবসার শেয়ার করা সাপোর্ট ইনবক্স কল্পনা করুন। একটি টিকেটে গ্রাহকের মেসেজ, অর্ডার ডিটেইল, শিপিং স্ট্যাটাস, এবং ইন্টারনাল নোট থাকতে পারে যেমন “সম্ভাব্য ফ্রড, ID যাচাই করুন” বা “VIP, অগ্রাধিকার দিন।” ওই ইন্টারনাল প্রাসঙ্গিকতা টিমকে সাহায্য করে, কিন্তু ক্লায়েন্ট কখনোই তা দেখতে পারবে না।

একটি পরিষ্কার বিভাজন যা সংবেদনশীল ডেটা নিরাপদ রাখে:

• Client: তাদের নিজস্ব মেসেজ, পাবলিক স্ট্যাটাস আপডেট, এবং চূড়ান্ত সমাধান দেখবে। কোনো ইন্টারনাল ট্যাগ বা স্টাফ-ওয়ান নোট থাকবে না।
• Staff agent: গ্রাহকের মেসেজ এবং সমস্যা সমাধানে প্রয়োজনীয় কাস্টমার ডেটা যেমন অর্ডার ইতিহাস দেখবে। ইন্টারনাল নোট ও ট্যাগ যোগ করতে পারবে।
• Manager: স্টাফ যে সবকিছু দেখে তা দেখতে পারবে, সঙ্গে পুনর্নিয়োগ নিয়ন্ত্রণ ও SLA ওভাররাইডের ক্ষমতা থাকবে।
• Owner/admin: পুরো ব্যবসার সব টিকেট এবং উচ্চ-স্তরের রিপোর্টিং দেখতে পারবে।

ক্লায়েন্ট PII (ব্যক্তিগত পরিচয়যোগ্য তথ্য) পরবর্তী ফাঁদ। সাপোর্ট প্রায়ই ফোন নম্বর বা ঠিকানার দরকার হয়, কিন্তু সেটা সব টিকেটে দেখাবেন না। একটি ভাল নিয়ম: সংবেদনশীল ফিল্ডগুলো কেবল তখন দেখান যখন ওয়ার্কফ্লো তা প্রয়োজন করে। উদাহরণস্বরূপ, এজেন্ট “shipping issue” নির্বাচন করার পরে ঠিকানাটি দেখান, এবং টিকেট ক্লোজ হলে আবার লুকিয়ে দিন।

ইন্টারনাল মেট্রিক্স ক্লায়েন্ট অভিজ্ঞতা থেকে আলাদা রাখুন। “টাইম টু ফার্স্ট রিপ্লাই,” “এজেন্ট স্কোর,” বা “লিগ্যালকে এসকলেটেড” সব স্টাফ ও ম্যানেজার ভিউতে রাখুন।

ব্যবসায়িক উদাহরণ ৩: অপারেশন ও ডেলিভারি ট্র্যাকিং

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

প্রতিটি গ্রুপ দৈনন্দিনে কী প্রয়োজন তা আলাদা করে শুরু করুন।

Staff (পিকার ও ড্রাইভার) সাধারণত একটা টাস্ক-ফোকাসড ভিউ প্রয়োজন। একজন ড্রাইভার অ্যাপ খুললে কেবল আজকের নির্ধারিত কাজগুলো দেখতে চাইবে, স্টপ অর্ডার, স্টপের যোগাযোগের বিবরণ, এবং ডেলিভারি নির্দেশনা। তারা পুরো গ্রাহক তালিকা ব্রাউজ করতে বা অন্য ড্রাইভারদের কাজ দেখতে পাবে না। যদি শিফট কভার করতে হয়, ম্যানেজার একটি জব রি-অ্যাসাইন করবে, ব্যাপক অ্যাক্সেস দেওয়ার পরিবর্তে।

Managers আরো বিস্তৃত অপারেশনাল চিত্র দেখতে চান। তারা সব টিমের শিডিউল, ইনভেন্টরি কাউন্ট, এবং কোন জিনিস গলতে কোথায় সমস্যা হচ্ছে (বিলম্বিত ডেলিভারি, ব্যর্থ ড্রপ, ক্ষতিগ্রস্ত আইটেম, অনুপস্থিত স্বাক্ষর) দেখতে চান। তাদের এক্সসেপশন সমাধান করার টুলও প্রয়োজন: স্টপ পুনর্বণ্টন, রুট বিভক্ত করা, বা ইনভেন্টরি এডজাস্টমেন্ট অনুমোদন করা।

Clients সর্বনিম্ন ভিউ পাবে: কেবল তাদের নিজস্ব ডেলিভারি স্ট্যাটাস। তারা ETA ট্র্যাক করতে পারবে, ডেলিভারি প্রুফ দেখবে, এবং আপডেট পাবে যেমন “out for delivery” বা “delayed।” তারা অন্য গ্রাহক, পুরো দিনের রুট ম্যাপ, বা ইন্টারনাল এক্সসেপশন নোট কখনো দেখতে পারবে না।

এখানে একটি সহজ উপায় হলো অ্যাসাইনমেন্ট ও গ্রাহক অ্যাকাউন্ট অনুসারে ডেটা স্কোপ করা। উদাহরণস্বরূপ, একটি Delivery Job রেকর্ড পড়তে পারবে কেবল (1) নির্ধারিত স্টাফ সদস্য, (2) ম্যানেজাররা, এবং (3) সেই অর্ডারের সাথে যুক্ত ক্লায়েন্ট।

ধাপে ধাপে: কিভাবে রোল ও অনুমতি ডিজাইন করবেন

সহজ ভাষায় আপনার ইউজার গ্রুপগুলোর নামকরণ দিয়ে শুরু করুন। “Owner”, “Manager”, “Staff”, এবং “Client” একটি ভালো শুরু, কিন্তু শুধুমাত্র তখনই যদি তা আপনার ব্যবসার কাজের সাথে মেলে। প্রতিটি গ্রুপের জন্য এক বাক্যে লিখুন সাফল্য কেমন দেখায়, যেমন “Managers টিম বরাদ্দ করতে ও পারফরম্যান্স দেখতে পারবে, কিন্তু পে-রোল দেখতে পারবে না।”

এরপর, ডেটা এরিয়াগুলোতে অ্যাকশন ম্যাপ করুন। প্রথমে স্ক্রীন না ভেবে ডেটা কী আছে তা ভাবুন, এবং মানুষগুলো তা নিয়ে কি করতে পারবে। কাগজে একটি সিম্পল গ্রিড যথেষ্ট:

• আপনার রোলগুলো এবং ডেটা এরিয়া তালিকাভুক্ত করুন (গ্রাহক, অর্ডার, চালান, টিকেট, রিপোর্ট)।
• প্রতিটি রোলের জন্য তাদের দরকারি ক্রিয়াগুলো লিখুন (view, create, edit, approve, export)।
• প্রতিটি ক্রিয়ার জন্য স্কোপ নির্ধারণ করুন (own, team, all)।
• “টিম” স্পষ্টভাবে সংজ্ঞায়িত করুন (শাখা, অঞ্চল, প্রজেক্ট, বা সরাসরি রিপোর্টরা)।
• কোনো “কখনো নয়” আইটেম চিহ্নিত করুন (উদাহরণ: ক্লায়েন্ট কখনোই ইন্টারনাল নোট দেখতে পারবে না)।

তারপর আপনার খসড়া বাস্তব কাজ ব্যবহার করে পরীক্ষা করুন, অনুমান নয়। সাধারণ ফ্লোগুলো অনুসরণ করুন যেমন “অর্ডার তৈরি করা”, “একটি টিকেট সমাধান করা”, এবং “রিপোর্ট ডাউনলোড করা”। যদি কোনো কাজ আপনাকে বিস্তৃত অ্যাক্সেস দিতে বাধ্য করে, সম্ভবত একটি অনুপস্থিত অনুমতি আছে (যেমন “টোটাল দেখতে পারবেন” কিন্তু “রপ্তানি” নয়)।

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

দুর্ঘটনাজনিত ডেটা লিকের সাধারণ ভুলগুলো

ছোট টিমে বেশিরভাগ ডেটা লিক হ্যাক নয়—এগুলো ঘটে যখন অ্যাপ কৌতূহলের চেয়ে বেশি অ্যাক্সেস দিয়ে দেয়। রোল ও অনুমতি একবার সেট করে আর কখনো যাচাই না করাটা ব্যর্থতার প্রধান কারণ।

একটি সাধারণ প্যাটার্ন হলো কাউকে "সেটআপের জন্য" ফুল অ্যাডমিন দেয়া। তৎক্ষণাত চাপ চলে যায়, কিন্তু অ্যাক্সেস থেকেই যায়। কয়েক সপ্তাহ পরে সেই ব্যক্তি রিপোর্ট করতে “সহায়তার জন্য” পুরো গ্রাহক তালিকা এক্সপোর্ট করে এবং গোপন ডেটা একটি স্প্রেডশিটে পড়ে।

আবার দেখা যায় এমন ভুলগুলো:

• সমাধান হিসেবে “Admin” ডিফল্ট রোল বানিয়ে ফেলা
• সীমাহীন রপ্তানি অনুমতি দেওয়া (গ্রাহক, কন্ট্যাক্ট, পেআউট, ইনভয়েস) এবং অডিট না করা
• শিফট টিমের মধ্যে এক লগইন শেয়ার করা, ফলে বলা যায় না কে কি দেখেছে বা বদলেছে
• প্রধান স্ক্রীনগুলো সুরক্ষিত রেখে পাশের দরজাগুলো ভুলে যাওয়া: মোবাইল ভিউ, PDF, ইমেইল নোটিফিকেশন, অ্যাটাচমেন্ট, এবং অটো-ফিল ফর্ম
• অফবোর্ডিং না করা: প্রাক্তন কর্মীরা অ্যাপ, ইমেইল ইনবক্স, অথবা ফোনে সেভ করা সেশন জীবিত রেখে দেয়

পার্শ্ব দরজাগুলো সবচেয়ে ছলনাময়। আপনি স্টাফকে একটি কন্ট্রাক্ট স্ক্রীন দেখতে বন্ধ করে দিলেন, কিন্তু একই কাউকে PDF এটাচমেন্ট ইমেইল করে দিয়েছেন। অথবা মোবাইল লেআউটটি এমন অতিরিক্ত ফিল্ড দেখাচ্ছে যা ডেস্কটপে লুকানো ছিল।

একটি বাস্তবসম্মত সমাধান হলো রপ্তানি ও ডাউনলোডকে আলাদা অনুমতিতে ধরা, না যে সেটি সাধারণ "view" অধিকারের অংশ। যদি কোনো রোল একটি তালিকা দেখতে চায়, একটি ফিল্টার করা ভিউ দিন সম্পূর্ণ এক্সপোর্টের বদলে।

বাস্তব আমন্ত্রণের আগে দ্রুত চেকলিস্ট

প্রকৃত ব্যবহারকারীদের আমন্ত্রণ দেওয়ার আগে ধরে নিন কেউ ভুল বাটনে ক্লিক করবে, স্ক্রিন শেয়ার করবে, বা এমন একটি ফাইল ডাউনলোড করবে যা উঁচু ঝুঁকির। কয়েকটি চেক এখনই পেইনফুল ক্লিনআপ প্রতিরোধ করতে পারে।

ডিফল্টস দিয়ে শুরু করুন। একটি নতুন ইউজার তৈরি হলে তারা স্বয়ংক্রিয়ভাবে সর্বনিম্ন রোলে নেমে যাবে, টাকা, রপ্তানি, বা অ্যাডমিন সেটিংসে কোন অ্যাক্সেস থাকবে না। যদি কারো বেশি দরকার হয়, তা একটি যুগোপযোগী পরিবর্তন করুন।

এরপর ক্লায়েন্ট অভিজ্ঞতা একজন অচেনা হিসেবে পরীক্ষা করুন। ক্লায়েন্টরা কখনোই তাদের নিজের রেকর্ড ছাড়া আর কিছু দেখতে পারবে না, এমনকি যদি তারা URL পরিবর্তন করে, সার্চ করে, বা ফিল্টার করে। একটি দ্রুত পরীক্ষা হলো Client A হিসেবে লগইন করে Client B কে নাম, ইনভয়েস নম্বর, বা টিকেট আইডি দিয়ে খোঁজা চেষ্টা করা।

পাঁচটি দ্রুত চেক যা বেশিরভাগ লিক ধরবে:

• সংবেদনশীল ফিল্ড ডিফল্টভাবে লুকিয়ে রাখুন (বেতন, খরচ/мар্জিন, ব্যক্তিগত আইডি, ইন্টারনাল নোট)
• রপ্তানি ও বাল্ক অ্যাকশন লকডাউন করুন
• যেখানে ভুল ব্যয়সাপেক্ষ সেখানে অনুমোদন যোগ করুন (রিফান্ড, পেআউট, রোল পরিবর্তন)
• স্কোপ সর্বত্র প্রয়োগ হচ্ছে কি না নিশ্চিত করুন (স্ক্রিন, সার্চ ফলাফল, API রেসপন্স)
• নিশ্চিত করুন আপনি চেঞ্জ অডিট করতে পারবেন: কে কী ও কখন বদলেছে, রোল আপডেট ও পেমেন্ট ক্রিয়াসহ

একটি “দুর্ঘটনা পরীক্ষা” করুন। একজন টিমমেটকে স্টাফ একাউন্ট নিয়ে একটি বাস্তব টাস্ক সম্পন্ন করতে বলুন, তারপর একই টাস্ক ক্লায়েন্ট একাউন্ট দিয়ে চেষ্টা করুন। যদি ক্লায়েন্ট ইন্টারনাল মূল্য দেখতে পারে, পুরো গ্রাহক তালিকা ডাউনলোড করতে পারে, বা একটি রিফান্ড টিগার করতে পারে, আপনার অনুমতিগুলো অতিরিক্ত প্রশস্ত।

একটি বাস্তবধর্মী দৃশ্য: একই অ্যাপ স্টাফ ও ক্লায়েন্ট উভয়ের দ্বারা ব্যবহৃত

একটি সাধারণ অনুরোধ শুরু হয় এভাবে: ক্লায়েন্ট একটি পোর্টাল চান “স্ট্যাটাস চেক” করার জন্য, কিন্তু আপনার স্টাফ একই সিস্টেম ব্যবহার করে কাজ চালায়। পরিষ্কার রোল ও অনুমতি ছাড়া পোর্টালটি ইন্টারনাল নোট, অন্য ক্লায়েন্টের অর্ডার, বা স্টাফ-ওয়ান মূল্য উন্মোচিত করতে পারে।

একটি কাস্টম প্রিন্টিং কোম্পানির উদাহরণ কল্পনা করুন। একটি অর্ডার কোট থেকে প্রোডাকশন, ডেলিভারি এবং ইনভয়েসিং—সবই একটি অ্যাপের ভিতরে চলে।

এই ফ্লোতে প্রতিটি রোল কী দেখা উচিত:

• Owner: সবকিছু, মার্জিন, স্টাফ পারফরম্যান্স, এবং সব ক্লায়েন্ট অ্যাকাউন্ট
• Manager: তাদের টিমের সব অর্ডার, ইন্টারনাল নোট, এবং ডিসকাউন্ট ও রিফান্ড অনুমোদনের ক্ষমতা
• Staff: কেবল তাদের নির্ধারিত অর্ডার, পরবর্তী ধাপ সম্পন্ন করার নির্দেশ, এবং কাজের জন্য প্রয়োজনীয় কনট্যাক্ট ডিটেইল
• Client: কেবল তাদের অর্ডার, উচ্চ-স্তরের স্ট্যাটাস (Approved, In production, Shipped), ডেলিভারি প্রুফ, এবং তাদের দেওয়ার মতো চালান

দুইটি এজ কেস সাধারণত মডেল ভেঙে দেয়।

প্রথমত, একজন ম্যানেজার অস্থায়ীভাবে অন্য টিম কভার করে। তাকে Owner এ রূপান্তর করবেন না। বরং একটি সময়-সীমাবদ্ধ স্কোপ দিন, যেমন Team B অর্ডার দেখার অ্যাক্সেস ৭ দিনের জন্য। কভার শেষ হলে অ্যাক্সেস বাতিল হয়ে যাক।

দ্বিতীয়ত, একটি VIP ক্লায়েন্ট “বেশি দৃশ্যমানতা” চায়। আরও কনটেক্সট দিন কিন্তু বেশি ডেটা দেবেন না। একটি বড়ো টাইমলাইন বা ডেডিকেটেড মেসেজ থ্রেড দেখান, কিন্তু ইন্টারনাল নোট (যেমন “ক্লায়েন্ট পেমেন্টে দেরি করে” বা “আমাদের ভুলে পুনঃপ্রিন্ট”) কেবল স্টাফ-ওয়ান রাখুন।

দায়িত্ব পরিবর্তিত হয়, তাই অ্যাক্সেসকে একবারে সেট করা বস্তু নয়, নিয়মিত পর্যালোচনার বিষয়ে পরিণত করুন। কেউ রোল পরিবর্তন করলে পুরনো দরকারি পারমিশনগুলো সরিয়ে দিন, তারপর নতুন কাজে সর্বনিম্ন সেট যোগ করুন।

পরবর্তী ধাপ: স্পষ্ট অ্যাক্সেস পলিসি নির্ধারণ ও বাস্তবায়ন

ছোট থেকে শুরু করুন। সবচেয়ে গুরুত্বপূর্ণ একটি ওয়ার্কফ্লো বেছে নিন, যেমন “ইনভয়েস তৈরি ও পেমেন্ট নেওয়া” বা “সাপোর্ট টিকেট লগ করা ও উত্তর দেওয়া।” প্রথমে সেই একক ফ্লোয়ের জন্য রোল ও অনুমতি নির্ধারণ করুন, তারপর বিস্তার করুন।

নিয়মগুলো একটী সরল টেবিলে রাখুন এবং এটাকে একটি জীবন্ত ডকুমেন্ট হিসেবে বিবেচনা করুন: রোল, তারা কী করতে পারবে, কী করতে পারবে না, এবং কোনো সীমা (যেমন “শুধু তাদের নিজস্ব রেকর্ড” বা “শুধু তাদের লোকেশন”)। যখন কেউ জিজ্ঞেস করে, “স্টাফ ক্লায়েন্ট ফোন নম্বর দেখতে পারবে কি?” টেবিলটি কয়েক সেকেন্ডে উত্তর দেবে।

একটি বাস্তবায়ন পরিকল্পনা:

• প্রথম ওয়ার্কফ্লোয়ের জন্য টেবিল খসড়া করুন (Owner, Manager, Staff, Client)
• প্রতিটি নিয়মকে নির্দিষ্ট ডেটা (ফিল্ড সহ) ও ক্রিয়ার সাথে ম্যাপ করুন (view, edit, export, delete)
• প্রতিটি রোলে ডেমো একাউন্ট তৈরি করে বাস্তব কাজগুলো টেস্ট করুন
• একটি ছোট গ্রুপকে লঞ্চ করুন, তারপর বিস্তার করুন যদি অবাক করা কিছু না পাওয়া যায়
• প্রত্যেক ত্রৈমাসিকে বা সংগঠনের পরিবর্তনের পরে (নতুন ম্যানেজার, নতুন টিম, নতুন ভেন্ডর) অ্যাক্সেস পর্যালোচনা করুন

আপনি যদি AppMaster (appmaster.io) এ তৈরি করেন, তাহলে রোলগুলোকে আপনার ডেটা মডেল ও ব্যবসায়িক লজিকের সাথে একসাথে পরিকল্পনা করা সুবিধাজনক—তবে একই নিয়ম ওয়েব অ্যাপ, মোবাইল অ্যাপ এবং API এ ধারাবাহিকভাবে প্রয়োগ হবে।

আজই প্রথম অ্যাক্সেস টেবিল লিখে একটি ওয়ার্কফ্লোতে প্রয়োগ করে দেখুন। এই এক পদক্ষেপই বেশিরভাগ দুর্ঘটনাজনিত ডেটা লিক প্রতিরোধ করে।