টেন্যান্ট ডেটা আইসোলেশন
প্রতিটি রেস্টুরেন্ট আলাদা tenant database পায়। Authenticated application service বর্তমান restaurant resolve করার পর tenant data খোলে; public agent catalog endpoint কখনো restaurant database খোলে না।
রসুইয়ের সিকিউরিটি
রসুই একটি multi-tenant restaurant platform, তবে রেস্টুরেন্টের operational data এক shared tenant-row সেটে রাখা হয় না। প্রতিটি restaurant tenant-এর আলাদা MySQL database তৈরি হয় এবং application request সেই tenant context-এ resolve হয়।
Repository ও নথি পর্যালোচনা:
প্রতিটি রেস্টুরেন্ট আলাদা tenant database পায়। Authenticated application service বর্তমান restaurant resolve করার পর tenant data খোলে; public agent catalog endpoint কখনো restaurant database খোলে না।
Panel access authenticated session ব্যবহার করে। Restaurant role ও granular permission operational action নিয়ন্ত্রণ করে; access বন্ধ করতে account status disable করা যায়।
Restaurant integration key একটি rsk_ secret, যা তৈরির সময় owner-কে দেখানো হয়। Central key table-এ raw key না রেখে lookup-এর জন্য SHA-256 hash রাখা হয়।
Verified restaurant API key tenant নির্ধারণ করে। Caller এমন tenant ID দেন না, যা বদলে অন্য restaurant-এর customer, staff, order বা report চাওয়া যায়।
Public Agent API ও read-only MCP server product fact, feature, pricing ও FAQ দেয়। Restaurant order, customer, staff, inventory বা sales-এর public tool দেয় না।
Public Agent API, event collection ও MCP route-এ endpoint-specific rate limit আছে। Browser Origin দেওয়া হলে MCP request সেটিও validate করে।
এটি কোড ও প্রকাশিত নথির পর্যালোচনা; live recovery drill বা independent penetration test নয়।
সফটওয়্যারের বাস্তবায়নে প্রতিটি restaurant tenant-এর জন্য আলাদা MySQL database তৈরি হয়। পরিচয় যাচাই করা request ও integration key দিয়ে আগে সংশ্লিষ্ট রেস্টুরেন্ট নির্ধারণ করা হয়। এই নকশা থাকলেও access control পরীক্ষা করা দরকার।
Password hash করে রাখা হয়। Restaurant integration key তৈরির সময় দেখানো হয়; কেন্দ্রীয় lookup-এ SHA-256 hash থাকে এবং key বাতিল করা যায়। সবার ব্যবহার করা নথিতে key রাখবেন না; দরকার শেষ হলে বাতিল করুন।
Privacy policy-তে তথ্য আদান-প্রদানের সময় HTTPS/TLS ব্যবহারের কথা আছে। Password ও API key hashing আলাদা উদ্দেশ্যে ব্যবহৃত হয়। সব রেকর্ড, credential ও backup সংরক্ষণের সময় encrypted থাকে—এমন সামগ্রিক নিশ্চয়তা এই পর্যালোচনায় প্রতিষ্ঠিত হয়নি।
Repository পর্যালোচনায় অনুমোদিত automatic-backup সূচি, retention period, কত সময়ে বা কত পুরোনো তথ্য পর্যন্ত উদ্ধার হবে—এর লক্ষ্য, কিংবা সাম্প্রতিক restore-test ফল পাওয়া যায়নি। এসব প্রতিশ্রুতির ওপর নির্ভর করার আগে লিখিত শর্ত ও restore demonstration চান।
Privacy policy অনুযায়ী সক্রিয় অ্যাকাউন্টের তথ্য এবং আইন, কর, হিসাব বা বিরোধ নিষ্পত্তির প্রয়োজনে তথ্য রাখা হতে পারে। অ্যাকাউন্ট বন্ধের পরে ওই ব্যতিক্রম সাপেক্ষে তথ্য মুছতে বা পরিচয়হীন করতে পারে। নির্দিষ্ট deletion deadline বা backup থেকে মুছতে কত দিন লাগে, তা প্রতিষ্ঠিত নয়।
Report export প্ল্যাননির্ভর; এটি পুরো database backup নিজের সঙ্গে নিয়ে যাওয়ার প্রতিশ্রুতি নয়। কী তথ্য, কোন সময়ের এবং কোন file format দরকার তা জানান; কেনার আগে export পরীক্ষা ও account বন্ধের সময় সহায়তা নিশ্চিত করুন।
সন্দেহজনক নিরাপত্তা সমস্যা support@rosuii.com-এ জানান। Password, payment credential বা অপ্রয়োজনীয় ব্যক্তিগত তথ্য পাঠাবেন না। এই পর্যালোচনায় অনুমোদিত প্রকাশ্য incident-history register, নিশ্চিত response time বা ২৪/৭ support schedule পাওয়া যায়নি। প্রকাশ্য নথি না থাকাকে কোনো incident ঘটেনি ধরে নেওয়া যাবে না।
এই পেজের জন্য দেখা repository উৎসে প্রকাশযোগ্য independent review, penetration-test report বা certification প্রতিষ্ঠিত হয়নি। নকশার বিবরণ কোনো assurance report নয়। ভবিষ্যতের review-এ পরীক্ষক, পরিধি, তারিখ ও অমীমাংসিত সীমা থাকা দরকার।
support@rosuii.com-এ সংক্ষিপ্ত বিবরণ, affected URL বা account context এবং নিরাপদ reproduction step পাঠান। Password, live payment credential বা অপ্রয়োজনীয় customer data পাঠাবেন না। Public disclosure-এর আগে তদন্তের জন্য টিমকে যুক্তিসংগত সময় দিন।