কে কোন কাজ করতে পারবেন? ব্যস্ত সোমবারেও কার্যকর Permission

সোমবার সকালে দোকানের মালিক দেখলেন, USD 184-এর refund একই account থেকে request ও approve হয়েছে। সপ্তাহান্তে দায়িত্ব সামলানোর জন্য cashier-কে shift-lead access দেওয়া হয়েছিল; expiry দেওয়া হয়নি। এটি বোঝানোর জন্য তৈরি দৃশ্য, কোনো গ্রাহকের ঘটনা নয়। Refund বৈধও হতে পারে। তবু control ব্যর্থ: স্বাধীন কেউ যাচাই করেননি।

দল বড় হলে প্রতিটি সাধারণ বিক্রিতে মালিকের অনুমতি নেওয়া সম্ভব নয়। Access-কে কাজের সঙ্গে চলতে হবে। একটি sensitive workflow নিন, নিয়ম সহজ ভাষায় লিখুন, তারপর দেখুন direct API call, background task ও shift পরিবর্তনেও তা কার্যকর থাকে কি না।

পদের নাম দিয়ে শুরু, সিদ্ধান্ত সেখানে শেষ নয়

Permission একটি action: order দেখা, refund request বা customer record export। Role হলো কাজ অনুযায়ী permission-এর গুচ্ছ। Assignment নির্দিষ্ট ব্যক্তিকে নির্দিষ্ট scope ও সময়ের জন্য সেই role দেয়। “শুক্রবার পর্যন্ত Outlet 2-এর shift lead” কথাটি শুধু “manager”-এর চেয়ে স্পষ্ট। Outlet 3-এ বদলি হলে আগের assignment সচেতনভাবে শেষ বা সংশোধন করতে হবে।

Role-based access control বা RBAC এই job bundle সাজায়। পাশাপাশি tenant, outlet, record, field, amount ও বর্তমান business state-এর নিয়ম লাগে। View, create, edit, approve, export ও administer আলাদা করুন। Sales দেখতে পারা সব customer address download করার অধিকার নয়। NIST AC-6 least privilege ব্যাখ্যা করে; সবার জন্য একই retail role template নির্ধারণ করে না।

Authentication sign-in identity প্রতিষ্ঠা করে; প্রতিটি request অনুমোদিত বা ব্যক্তি সৎ—এটি প্রমাণ করে না। আলাদা পরিচয়, উপযুক্ত শক্ত authentication ও সীমিত service account রাখুন। “Owner” নামের role দিয়ে আপনার ব্যবসার নিয়ন্ত্রণ নিঃশব্দে bypass হওয়া চলবে না।

Menu নয়, record-এর অধিকার যাচাই করুন

OWASP-এর authorisation guidance default deny ও প্রতিটি request-এ যাচাইয়ের কথা বলে। Button লুকানো interface সহজ করে; server-এ list, detail, search, export, download, API ও background work-ও সুরক্ষিত থাকতে হবে। আন্দাজ করা কঠিন ID নিজে permission নয়।

Outlet 2-এর refund-এ actor-এর বর্তমান action permission ওই tenant ও outlet-এ আছে কি না, order সেখানে পড়ে কি না এবং payment/refund state পরিবর্তনটি অনুমোদন করে কি না দেখুন। Browser পাঠানো outlet ID-কে অধিকার ধরে নেবেন না। Shared cache, report ও file link দিয়েও অন্য scope-এর data প্রকাশ হওয়া চলবে না।

Optional module বন্ধ হলে তার route ও integration দিয়ে কাজ বা data পাওয়া উচিত নয়। চালু করলেই সব manager-এর access আসে না। একই calendar/dashboard-এও প্রতিটি source-এর view/action rule লাগবে। Calendar দেখতে পারা payroll দেখা বা product reschedule করার অধিকার নয়। এগুলো যাচাই করার design requirement; কোনো product ইতিমধ্যে সব enforce করে—এমন দাবি নয়।

দুজন মানে দুই স্বাধীন দায়িত্বশীল ব্যক্তি

NIST static ও dynamic separation of duties আলাদা করে। Static rule একই ব্যক্তির conflicting assignment আটকায়। Dynamic rule manager-কে সাধারণভাবে refund request ও approve করতে দিতে পারে, কিন্তু নিজের request নিজে approve করতে দেয় না। মডেল লিখে রাখুন; একদিকে দুই permission সর্বত্র নিষিদ্ধ বলে অন্যদিকে owner-কে দুটোই দেওয়ার অসংগতি রাখবেন না।

এই শিক্ষামূলক policy-তে অনুমতিপ্রাপ্ত USD 50 পর্যন্ত refund-এ আলাদা approver লাগে না। USD 50-এর বেশি থেকে USD 300 পর্যন্ত একজন স্বাধীন approver। USD 300-এর বেশি হলে দুজন আলাদা approver, প্রত্যেকেই requester থেকে ভিন্ন। Currency ও limit উদাহরণ, আইনি threshold নয়। একই ব্যক্তির দ্বিতীয় login স্বাধীন review নয়।

Table-এ workflow-এর দায়িত্ব দেওয়া, software permission-এর প্রস্তুত তালিকা নয়। ছোট দলে প্রয়োজনমতো authorised external accountant স্বাধীন review দিতে পারেন। Approver না থাকলে hold করুন বা অনুমোদিত substitute-এ পাঠান। Emergency exception হলে সীমিত ক্ষমতা, expiry, alert ও স্বাধীন follow-up লাগবে; স্থায়ী bypass নয়।

Workflow	Request/প্রস্তুতি	স্বাধীন সিদ্ধান্ত	Scope ও শর্ত
Refund ≤USD 50	Assigned cashier	উদাহরণ policy-তে নেই	নিজ outlet; payment check বহাল
Refund >USD 50 থেকে USD 300	Assigned requester	একজন authorised ব্যক্তি	একই scope; নিজের request নয়
Refund >USD 300	Assigned requester	দুজন ভিন্ন authorised ব্যক্তি	কেউ requester নন; exact action
Supplier payment	Vendor maintainer / payment preparer	স্বাধীন payment release	নিজে vendor বানিয়ে একা payment নয়
Stock discrepancy	Assigned stock recorder	স্বাধীন adjustment approval	Inspection ও location evidence
Customer export	বিশেষভাবে permitted requester	Policy চাইলে approval	প্রয়োজনীয় field/scope; নিরাপদ delivery
Role change	সীমিত access administrator	Authorised role owner	Self-escalation নয়; change log

ঠিক কাজটি approve করুন, পরে ফল মিলান

আমাদের USD 184 request Outlet 2-এর অন্য authorised ব্যক্তির কাছে যাবে। তিনি order, captured payment, আগে ফেরত দেওয়া amount, reason, currency ও destination দেখবেন। USD 196 বা অন্য destination হলে নতুন approval চাই। ছোট ছোট request দিয়ে cumulative limit এড়ানো বা payment-এর refundable balance ছাড়ানো চলবে না।

OWASP transaction-authorisation guidance গুরুত্বপূর্ণ transaction detail-এর সঙ্গে approval বাঁধা ও execution-এর আগে authorised state যাচাই সমর্থন করে। Commit-এর সময় বর্তমান permission ও expiry আবার দেখুন। পুরোনো browser tab মানে চলমান অধিকার নয়। Concurrent request সামলান, যাতে দুই click বা approval একই অবশিষ্ট balance দুবার খরচ না করে।

Requested, approved, provider-এ পাঠানো ও confirmed refunded আলাদা state। Timeout হলে outcome unknown; failure প্রমাণিত নয়। Operation reference রেখে provider query করুন, তার documented idempotency/recovery নিয়মে সীমিত retry ও backoff ব্যবহার করুন। অমীমাংসিত হলে escalate করুন; নতুন refund অন্ধভাবে পাঠাবেন না। Refund হলেই damaged jacket saleable stock হয় না।

বিশ্বাসযোগ্য বাক্য নয়, evidence trail

Stable event/operation reference, timezone-সহ সময়, actor ও delegated service, action, target/scope, নিরাপদ reason code, প্রয়োজনীয় amount/currency, policy version, requester/স্বাধীন approver reference ও প্রকৃত outcome রাখুন। Request, approval, execution ও পরে reconciliation আলাদা linked event। সংশোধন নতুন event-এ লিখুন, ইতিহাস পাল্টে নয়।

09:41-এর entry refund completed বলতে পারে না, যদি approval হয় 09:42-এ আর provider তখনও নিশ্চিত না করে। Attempted, denied, pending, failed, unknown ও confirmed সঠিকভাবে চিহ্নিত করুন। App-এর “success” message bank settlement বা বাস্তবে stock receipt-এর স্বাধীন প্রমাণ নয়।

OWASP logging guidance security event ও sensitive data রক্ষার নির্দেশনা দেয়। গুরুত্বপূর্ণ denial, role change, export ও admin exception ধরুন; password, token, পুরো card detail বা অপ্রয়োজনীয় ব্যক্তিগত data log-এ তুলবেন না। Untrusted text sanitise, log reader সীমিত ও export সুরক্ষিত করুন। Collector outage ও storage exhaustion-এর ব্যবস্থা রাখুন। High-risk action-এ evidence unavailable হলে block হবে, নাকি অনুমোদিত durable fallback—আগেই policy ঠিক করুন।

Tamper evidence-এরও trust boundary আছে

App-এর append-only permission সাধারণ editing কমায়; database superuser বা infrastructure admin-কে storage বদলানো থেকে নিজে আটকায় না। Trusted evidence-এর সঙ্গে verify করলে hash-chain অসংগতি ধরতে পারে। কিন্তু chain ও reference দুটোই বদলানোর ক্ষমতা থাকলে attacker নতুন hash বানাতে বা শেষের অংশ মুছে ফেলতে পারে।

আলাদা নিয়ন্ত্রণে collection/retention boundary, প্রয়োজনমতো protected checkpoint/signature রাখুন। কে নতুন event লিখবেন, পড়বেন বা retention বদলাবেন নির্ধারণ করুন। Collector append করতে পারলেও retained event rewrite-এর অধিকার পাওয়ার প্রয়োজন নেই। শুধু পরিষ্কার sample নয়; deletion, gap, clock সমস্যা ও verification failure test করুন।

Risk, privacy ও contract অনুযায়ী retention, review frequency ও access নির্ধারণ করুন। PCI SSC-এর বর্তমান document library প্রযোজ্য payment environment-এর PCI DSS v 4.0.1 দেয়। সব retail log চিরকাল রাখতে হবে বা একই schedule-এ দেখতে হবে—এমন সার্বজনীন নিয়ম নয়। নিজের standard ও assessment scope নিশ্চিত করুন। এই workflow compliance certificate নয়।

কাজ বদলালে access-ও বদলায়

Joiner-এর job-based role/scope approve, identity verify, প্রয়োজনীয় authentication enrol এবং allowed/denied দুই action test করুন। পুরোনো কর্মীর সব exception copy করবেন না। Cover duty-তে স্পষ্ট end time দিন। Cached decision-সহ পরের protected request-এ expiry কার্যকর কি না দেখুন।

Mover-এর superseded access সরানো ও নতুন assignment চালু করা সমন্বিতভাবে করুন। Handover-এ overlap সত্যিই লাগলে স্বল্প expiry ও conflict review approve করুন। Leaver বা compromised identity-তে policy-র effective time-এ revoke, দ্রুত risk contain, session/token/delegated access বন্ধ ও pending কাজ reassign করুন। Quarterly review পর্যন্ত অপেক্ষা offboarding নয়।

Service credential-এর named business/technical owner ও কাজভিত্তিক সীমিত access লাগবে। Human password বদলালেও API token/integration চলতে পারে। ব্যক্তিটি ব্যবহার করতে পারতেন এমন shared secret প্রয়োজনমতো dependency test-সহ rotate করুন; unrelated encryption key নির্বিচারে rotate বা record ধ্বংস নয়। প্রয়োজনীয় audit identity রাখুন, পাশাপাশি বৈধ personal-data lifecycle মানুন।

সোমবারের review যেন কাজে লাগে

Refund দিয়ে শুরু করুন: assignment/exception তালিকা, দায়িত্বপ্রাপ্ত owner, wrong-outlet view ও direct self-approval test, তারপর denial-এর protected evidence দেখুন। Expired role, বন্ধ module, revoked API credential ও provider timeout-এ pending refund-ও test করুন। সুন্দর screen একা control-এর প্রমাণ নয়।

High-risk alert দ্রুত দেখুন; periodic review-এর বাস্তব সময় ঠিক করুন। এক দলের জন্য quarterly ভালো হতে পারে, কিন্তু কঠোর প্রযোজ্য নিয়ম বা event-based removal-এর বদলি নয়। Manager-এর সঙ্গে role, scope, temporary expiry ও service-account owner নিশ্চিত করুন। Dormant account policy অনুযায়ী তদন্ত করে disable করুন; service identity-তে interactive login না হওয়া স্বাভাবিকও হতে পারে।

ধরা যাক 60 assignment review করে 9 অপ্রয়োজনীয় grant সরালেন:9÷60=15% reviewed assignment। এটি 15% employee, fraud rate বা বাকিগুলো নিরাপদ—এমন প্রমাণ নয়। Unresolved conflict, expiry enforcement, revoke করার সময় ও log collection gap দেখুন। অস্বাভাবিক refund বিচার করার আগে workload ও বৈধ return মিলান।

Counter-এ লক্ষ্য সহজ: cashier গ্রাহককে সাহায্য করবেন, অন্য authorised ব্যক্তি USD 184 request দেখবেন, আর owner প্রকৃত outcome অনুসরণ করতে পারবেন। স্পষ্ট role দায়িত্ব দেওয়া সহজ করে; নির্ভুল check ও সৎ evidence সেই দায়িত্বের জবাবদিহি রাখে।

পর্যালোচনা 5 নভেম্বর 2026 । Anichur Rahaman StoreConsole-এর নির্মাতা। দৃশ্য, limit ও review সংখ্যা উদাহরণ; নিজের installation-এর control ও প্রযোজ্য দায়িত্ব যাচাই করুন।