একটি শেয়ার করা অ্যাডমিন লগইন আর ভুলে যাওয়া সপ্তাহান্তের পদোন্নতিতে রিটেইলারের হাজার হাজার ডলার যেতে পারে। জানুন কীভাবে রোল সাজাবেন, ঝুঁকির জোড়া আটকাবেন, পরিমাণ ধরে রিফান্ডে গেট বসাবেন আর এমন অডিট লগ রাখবেন যা কেউ চুপিসারে বদলাতে পারে না।
Author
Anichur Rahaman
তিন outlet-এর একটি রিটেইল ব্যবসার মালিককে কল্পনা করুন, সোমবার সকাল। refund report খুলে তিনি দেখলেন, রোববার outlet ২ থেকে ৪১টি refund হয়েছে, মোট ২,৮৭০ ডলার। এর ৩৮টিই ৫০ থেকে ৩০০ ডলারের মধ্যে, অর্থাৎ যে পরিসরে দ্বিতীয় একজনের অনুমোদন লাগার কথা। অথচ প্রতিটি refund দিয়েছে একই ক্যাশিয়ারের login, আর অনুমোদনও দিয়েছে সেই একই login।
কেউ system হ্যাক করেনি। দুই বছর আগে এক ব্যস্ত দিনে ওই ক্যাশিয়ারকে "শুধু সপ্তাহান্তের জন্য" শিফট লিডের রোল দেওয়া হয়েছিল, পরে আর ফেরত নেওয়া হয়নি। system ঠিক তা-ই করেছে, যা তাকে বলা হয়েছিল। দৃশ্যটি বোঝানোর জন্য সাজানো, কিন্তু ধরনটা খুব পরিচিত: অ্যাক্সেস দেওয়া হয় তাড়াহুড়োয়, যাচাই হয় না কখনো, আর যে লগ থাকে তা কেউ পড়ে না।
এই লেখা তিনটি ধারণা নিয়ে, যেগুলো এমন ঘটনা ঠেকায়: কাজের প্রয়োজনের মাপে বানানো রোল, টাকা বা stock নড়ে এমন প্রতিটি কাজে দুজন মানুষ, আর এমন audit লগ যা চুপিসারে বদলানো যায় না। সঙ্গে আছে তিন outlet-এর রিটেইলারের জন্য একটি রোল template এবং একটি refund রেকর্ডের ফিল্ডগুলো।
তিনজনের দলে সবাই সবাইকে চেনে, আর একটাই admin login ক্ষতিকর মনে হয় না। কিন্তু তিন outlet-এ পনেরোজন হলে সেই একই অভ্যাস ঝুঁকিতে পরিণত হয়। কারণগুলো একেবারে সাধারণ:
এখানকার বেশির ভাগ ক্ষতি নাটকীয় হামলা থেকে হয় না। হয় এমন একজনের ছোট ছোট, বারবার ঘটা, কারও চোখে না পড়া কাজ থেকে, যাঁর সেই কাজ করার অনুমতি ছিল। ক্ষতির যত রাস্তা আছে, তার মধ্যে ভেতরের রাস্তাটাই রিটেইলার সবচেয়ে ভালো সামলাতে পারে।
রোল-ভিত্তিক অ্যাক্সেস কন্ট্রোল শুনতে বিমূর্ত লাগে, যতক্ষণ না একে ভাগ করে দেখা হয়। permission হলো একটি বিষয়ের ওপর একটিমাত্র ক্রিয়া: refund.issue, refund.approve, stock.adjust, customer.export। রোল হলো কোনো কাজের সঙ্গে মেলানো permission-এর একটি নামধারী গুচ্ছ: ক্যাশিয়ার, শিফট লিড, অ্যাকাউন্ট্যান্ট। আর স্কোপ বলে দেয় রোলটি কোথায় খাটবে: একটি outlet-এ, একটি গুদামে, নাকি সর্বত্র।
আসল একক রোল নয়, অ্যাসাইনমেন্ট। "সানা outlet ২-এর শিফট লিড" মানে একটি সারি: ব্যবহারকারী, রোল, স্কোপ, শুরুর তারিখ, আর চাইলে শেষের তারিখ। সানাকে outlet ৩-এ পাঠালে সারিটি বদলে যায়; outlet ২-এর অ্যাক্সেস নিঃশব্দে তাঁর কাছে থেকে যায় না।
ন্যূনতম অধিকারের (least privilege) মানে, একজন মানুষের কাছে আজকের কাজ করার জন্য যতটুকু permission লাগে, ঠিক ততটুকুই থাকবে। NIST SP 800-53-এর AC-6 কন্ট্রোলে কথাটা এভাবে আছে: নির্দিষ্ট কাজের জন্য যতটুকু অধিকার দরকার, system ততটুকুর বেশি দেবে না। রিটেইল system-এ এটি তিনটি অভ্যাসে দাঁড়ায়।
ন্যূনতম অধিকার ঠিক করে একজন কী করতে পারবে। দায়িত্বের বিভাজন (segregation of duties) ঠিক করে একজন একা কী করতে পারবে। NIST AC-5 একে বর্ণনা করেছে এভাবে: কাজ আলাদা আলাদা মানুষের মধ্যে ভাগ হবে, যাতে ক্ষমতার অপব্যবহারে যোগসাজশ লাগে। পদ্ধতি সহজ: এমন দুটি কাজের জোড়া তালিকা করুন, যেগুলো একজনের হাতে থাকলে ক্ষতি তৈরি বা লুকানো যায়, তারপর system-কে দিয়ে সেই মিলন আটকে দিন।
এই চার নিষিদ্ধ জোড়া একটি কমার্স ব্যবসার প্রায় সব টাকা ঢেকে ফেলে। যে supplier তৈরি করতে পারে এবং সেই supplier-কে payment-ও দিতে পারে, সে ভুয়া vendor বানাতে পারে। যে refund দিতে এবং অনুমোদন করতে পারে, আমাদের সোমবারের ক্যাশিয়ারের মতো, সে নিজের কাজ নিজেই পাস করে। payroll সম্পাদনা আর payroll চালানোও একই ছাঁচ। আর stock অ্যাডজাস্ট করা এবং সেই অ্যাডজাস্টমেন্টের পক্ষের গণনা নিজেই অনুমোদন করা, এভাবেই ঘাটতি অদৃশ্য হয়ে যায়।
নিয়মটি খাটাতে হবে software-কে দিয়ে, কাজটি করার মুহূর্তে; শুধু নীতিমালার নথিতে লিখে রাখলে হবে না। "অনুমোদনকারী অবশ্যই অনুরোধকারী থেকে আলাদা ব্যবহারকারী হবেন", এই যাচাইয়ে লজিক লাগে এক লাইন, আর এতে একটা আস্ত শ্রেণির সমস্যাই শেষ।
login প্রমাণ করে আপনি কে। এই নির্দিষ্ট কাজটি যুক্তিসংগত কি না, তা প্রমাণ করে না। অল্প কয়েকটি কাজের জন্য, যেমন refund, দাম ওভাররাইড, সীমার ওপরের discount, stock অ্যাডজাস্টমেন্ট, গ্রাহকের data এক্সপোর্ট আর payroll রান, এমন একটি গেট যোগ করুন যা পরিমাণ দেখে সিদ্ধান্ত নেয়।
নিচের ফ্লোতে থ্রেশহোল্ডগুলো দৃষ্টান্ত হিসেবে নেওয়া। আপনারটা ঠিক করুন আপনার ব্যবসায় একটি ভুলের খরচ কত, তা দেখে।
ওই ফ্লোর তিনটি খুঁটিনাটি দেখতে যতটা ছোট, গুরুত্বে ততটা নয়।
সবচেয়ে ওপরের ধাপে, এখানে ৩০০ ডলারের বেশি হলে, দুজন অনুমোদনকারী রাখুন, যেমন outlet ম্যানেজার আর ফাইন্যান্সের একজন। ধাপ কম রাখুন। তিনটি ধাপ কাউন্টারে দাঁড়িয়েই বোঝানো যায়; সাতটি হলে মানুষ ঘুরপথ খোঁজে।
এই টেবিল শুরু করার জায়গা, কোনো স্ট্যান্ডার্ড নয়। "নিজের" মানে permission-টি শুধু ব্যবহারকারীর নির্ধারিত outlet-এ খাটে। "অনুরোধ" মানে কাজটি শুরু করা যায়, কিন্তু অনুমোদন দেবেন অন্য কেউ।
| permission | ক্যাশিয়ার | শিফট লিড | outlet ম্যানেজার | stock ক্লার্ক | অ্যাকাউন্ট্যান্ট | মালিক |
|---|---|---|---|---|---|---|
| কাউন্টারে বিক্রি | নিজের | নিজের | নিজের | না | না | সব |
| ৫০ ডলার পর্যন্ত refund দেওয়া | নিজের | নিজের | নিজের | না | না | সব |
| ৫০ থেকে ৩০০ ডলারের refund অনুমোদন | না | নিজের | নিজের | না | না | সব |
| ৩০০ ডলারের বেশি refund অনুমোদন | না | না | নিজের (দুজনের প্রথম জন) | না | দ্বিতীয় অনুমোদনকারী | সব |
| দাম ওভাররাইড | না | অনুরোধ | নিজের, নির্ধারিত শতাংশের মধ্যে | না | না | সব |
| stock অ্যাডজাস্ট | না | না | না | নিজের | না | সব |
| stock গণনা অনুমোদন | না | না | নিজের | না | হ্যাঁ | সব |
| supplier তৈরি | না | না | না | না | না | সব |
| supplier-কে payment | না | না | না | না | হ্যাঁ | না |
| গ্রাহকের তালিকা এক্সপোর্ট | না | না | না | না | না | সব |
| ব্যবহারকারী ও রোল ব্যবস্থাপনা | না | না | না | না | না | সব, দ্বিতীয় একজন মালিকের অনুমোদনসহ |
টেবিলের ফাঁকগুলো ইচ্ছে করেই রাখা, একটু খেয়াল করে দেখুন। অ্যাকাউন্ট্যান্ট supplier-কে payment দিতে পারেন, কিন্তু supplier তৈরি করতে পারেন না। মালিক supplier তৈরি করতে পারেন, কিন্তু payment দেওয়া তাঁর জন্য বন্ধ; একটু বিরক্তিকর, এবং ইচ্ছাকৃতভাবেই। মালিকের কলামে দেখা যাচ্ছে রোলটি কী কী করতে পারে, কিন্তু প্রতিটি লেনদেনে কনফ্লিক্ট যাচাই তবু চলে, তাই মালিকও নিজের দেওয়া refund নিজে অনুমোদন করতে পারেন না। payroll-এর রোল এই টেবিলে রাখা হয়নি, কারণ সেটি সাধারণত আলাদা একটি HR template-এ থাকে, নিয়ম একই: যিনি বেতন সম্পাদনা করেন, তিনি payroll চালান না।
audit লগ পরে একটি প্রশ্নের উত্তর দেয়: কে, কোন রেকর্ডে, কখন, কেন এবং কার অনুমতিতে কী করেছে। "refund প্রসেস হয়েছে" লেখা একটি লাইন সেই উত্তর দেয় না। ওপরের ফ্লোর ১৮৪ ডলারের refund-এর রেকর্ডটি এ রকম।
| ফিল্ড | উদাহরণ | কেন দরকার |
|---|---|---|
| রেকর্ড আইডি ও সময় | R-20931, 09:41:07 UTC | ক্রম আর খুঁজে পাওয়ার জন্য। সংরক্ষণ UTC-তে, দেখানো স্থানীয় সময়ে। |
| কর্তা | cashier-07 (নামধারী ব্যবহারকারী, কখনো "till" নয়) | দায়বদ্ধতা |
| কাজ ও লক্ষ্য | order 48211-এ refund.issue | কোন রেকর্ড বদলাল |
| কোথায় | outlet ২, রেজিস্টার ৩, ডিভাইস ও IP | স্কোপ আর অস্বাভাবিক লোকেশন যাচাই |
| পরিমাণ ও কারণ | $184.00, কারণ-কোড "damaged" | কারণ ধরে প্যাটার্ন বিশ্লেষণ |
| আগে ও পরে | payment ক্যাপচার হয়ে ফেরত; stock +১, return বিনে | প্রভাবের প্রমাণ |
| প্রযোজ্য নিয়ম | "৫০ থেকে ৩০০ ডলারের refund: একজন অনুমোদনকারী" | তখন কোন নীতি চালু ছিল তা দেখায় |
| অনুমোদনকারী ও সময় | lead-02, 09:42:31 UTC | দ্বিতীয় একজন যে ছিলেন তার প্রমাণ |
| ফলাফল | সম্পন্ন | সফল, প্রত্যাখ্যাত বা বাতিল |
| আগের হ্যাশ ও নিজের হ্যাশ | 7f3a…c91e | বদলানো হলে ধরা পড়ার ব্যবস্থা |
যে লগ admin সম্পাদনা করতে পারেন, তার প্রমাণমূল্য কম। দুটি সস্তা ব্যবস্থা কাজে লাগে। প্রথমত, টেবিলটিকে অ্যাপ্লিকেশনের জন্য append-only করুন: আপডেট বা ডিলিটের অনুমতি থাকবে না, সংশোধন লেখা হবে নতুন সারি হিসেবে। দ্বিতীয়ত, রেকর্ডগুলোকে শিকলে বাঁধুন। প্রতিটি সারি নিজের বিষয়বস্তু আর আগের সারির হ্যাশ মিলিয়ে একটি SHA-256 হ্যাশ রাখে, ফলে পুরোনো সারি বদলালে তার পরের সব হ্যাশ ভেঙে যায়। লগটি প্রতি রাতে এমন স্টোরেজে কপি করুন, যেখানে অ্যাপ্লিকেশন লিখতে পারে না।
সংরক্ষণের মেয়াদ নির্ভর করে আপনার প্রযোজ্য নিয়মের ওপর। একটি রেফারেন্স হিসেবে, PCI DSS v4.0.1-এর ১০.৫.১ চায় audit লগের ইতিহাস অন্তত ১২ মাস রাখতে, যার সাম্প্রতিক তিন মাস বিশ্লেষণের জন্য সঙ্গে সঙ্গে হাতের কাছে থাকবে। কর, payroll আর প্রাইভেসির নিয়মে এর ওপর আর কী লাগে তা দেখে নিন, এবং মেয়াদটি লিখে রাখুন।
শেষ প্রশ্ন: লগ পড়বে কে? যে লগ কেউ দেখে না, সেটা ডায়েরি। outlet-এর বাইরের একজনকে, যেমন ফাইন্যান্স লিড বা মালিককে, দায়িত্ব দিন, আর তাঁকে তিনটি সেভ করা ভিউ দিন: ব্যবহারকারী অনুযায়ী refund, হাতে করা stock অ্যাডজাস্টমেন্ট আর এক্সপোর্ট। সপ্তাহে দশ মিনিটই যথেষ্ট, সোমবার আসার আগেই সোমবারের ক্যাশিয়ারকে ধরে ফেলার জন্য।
অ্যাক্সেসের বেশির ভাগ সমস্যা শুরু হয় কাজ বদলের সময়ে, হামলায় নয়। তিনটি মুহূর্তকে একটি নির্দিষ্ট ক্রমের রুটিন হিসেবে দেখুন।
নতুন যোগদান: ম্যানেজার template থেকে একটি রোল চান, রোলের দায়িত্বে থাকা ব্যক্তি অনুমোদন দেন, আর ব্যক্তি প্রথম ব্যবহারের আগে দ্বিতীয় সাইন-ইন ফ্যাক্টর চালু করেন। বদলি: আগে পুরোনো রোল সরান, তারপর নতুনটি দিন। এই ক্রমই permission জমে ওঠা ঠেকায়। বিদায়: account বন্ধ করুন (মুছবেন না, ইতিহাস থাকতে হবে), সেশন শেষ করুন, শেয়ার করা কোড আর API key বদলান, আর পড়ে থাকা অনুমোদনগুলো অন্য কাউকে দিন।
অস্থায়ী অ্যাক্সেসের জন্য আলাদা নিয়ম দরকার। "শুক্রবার পর্যন্ত রিনার কাজ সামলাবে" হয়ে দাঁড়ায় শেষ তারিখসহ একটি রোল অ্যাসাইনমেন্ট, ফলে কারও মনে না রাখলেও সেটি নিজে থেকে ফুরোয়। এই একটি সুবিধা থাকলে আমাদের সোমবারের দৃশ্যের সেই সপ্তাহান্তের পদোন্নতি আটকে যেত।
প্রতিটি রোল অ্যাসাইনমেন্ট অন্তত নির্দিষ্ট বিরতিতে একজন মানুষকে দিয়ে নিশ্চিত করানো উচিত। PCI DSS ৭.২.৪ স্কোপের মধ্যে থাকা system-এর জন্য সর্বোচ্চ বিরতি ধরেছে ছয় মাস; কর্মী বদল বেশি হয় এমন রিটেইলারের জন্য প্রতি তিন মাস ভালো ছন্দ। ঠিকমতো প্রস্তুতি নিলে পর্যালোচনায় এক ঘণ্টা লাগে।
কয়েকটি সংখ্যা দেখায় নিয়ন্ত্রণগুলো কাজ করছে কি না, আর কোনোটার জন্যই dashboard প্রজেক্ট লাগে না।
এই নিয়ন্ত্রণগুলো বসিয়ে শুরুর দৃশ্যটি আবার চালান। ক্যাশিয়ারের রোলে আছে বিক্রি আর ৫০ ডলার পর্যন্ত refund। ১৮৪ ডলারের refund যায় একজন শিফট লিডের কাছে, যিনি অন্য মানুষ, আর system একই login দুবার গ্রহণ করে না। সপ্তাহান্তের পদোন্নতিতে শেষ তারিখ বসানো, তাই সোমবারেই তা ফুরিয়ে যায়।
৪১টি refund আগের মতো ঘটে না। কয়েকটি তবু সন্দেহজনক থাকলে মালিক সাপ্তাহিক দশ মিনিটের পর্যালোচনাতেই তা পেয়ে যান, কারণ প্রতিটির সঙ্গে আছে ব্যবহারকারী, নিয়ম, অনুমোদনকারী আর হ্যাশ। তিনি এখন ক্ষতি আবিষ্কার করেন না, একটি report পড়েন।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
