মূল কন্টেন্টে যান

রসুইয়ের সিকিউরিটি

রেস্টুরেন্ট ডেটা ডিজাইন থেকেই আলাদা

রসুই একটি 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 করা যায়।

API key handling

Restaurant integration key একটি rsk_ secret, যা তৈরির সময় owner-কে দেখানো হয়। Central key table-এ raw key না রেখে lookup-এর জন্য SHA-256 hash রাখা হয়।

Tenant-scoped API

Verified restaurant API key tenant নির্ধারণ করে। Caller এমন tenant ID দেন না, যা বদলে অন্য restaurant-এর customer, staff, order বা report চাওয়া যায়।

Public AI endpoint

Public Agent API ও read-only MCP server product fact, feature, pricing ও FAQ দেয়। Restaurant order, customer, staff, inventory বা sales-এর public tool দেয় না।

Abuse control

Public Agent API, event collection ও MCP route-এ endpoint-specific rate limit আছে। Browser Origin দেওয়া হলে MCP request সেটিও validate করে।

রেস্টুরেন্ট মালিকের যা নিয়ন্ত্রণ করা উচিত

  • আলাদা password ব্যবহার করুন এবং shared login সীমিত রাখুন।
  • প্রতিটি role-কে শুধু প্রয়োজনীয় permission দিন।
  • শুধু trusted integration-এর জন্য API key তৈরি করুন এবং দরকার না হলে revoke করুন।
  • Payment-gateway credential private রাখুন এবং live-এর আগে sandbox mode ব্যবহার করুন।
  • অপ্রত্যাশিত access বা activity দ্রুত জানান।

নিরাপত্তা ও তথ্য নিয়ে ক্রেতার প্রশ্ন

এটি কোড ও প্রকাশিত নথির পর্যালোচনা; live recovery drill বা independent penetration test নয়।

রেস্টুরেন্টের তথ্য কীভাবে আলাদা থাকে?

সফটওয়্যারের বাস্তবায়নে প্রতিটি restaurant tenant-এর জন্য আলাদা MySQL database তৈরি হয়। পরিচয় যাচাই করা request ও integration key দিয়ে আগে সংশ্লিষ্ট রেস্টুরেন্ট নির্ধারণ করা হয়। এই নকশা থাকলেও access control পরীক্ষা করা দরকার।

Password ও API key কীভাবে রাখা হয়?

Password hash করে রাখা হয়। Restaurant integration key তৈরির সময় দেখানো হয়; কেন্দ্রীয় lookup-এ SHA-256 hash থাকে এবং key বাতিল করা যায়। সবার ব্যবহার করা নথিতে key রাখবেন না; দরকার শেষ হলে বাতিল করুন।

কোন encryption-এর তথ্য আছে?

Privacy policy-তে তথ্য আদান-প্রদানের সময় HTTPS/TLS ব্যবহারের কথা আছে। Password ও API key hashing আলাদা উদ্দেশ্যে ব্যবহৃত হয়। সব রেকর্ড, credential ও backup সংরক্ষণের সময় encrypted থাকে—এমন সামগ্রিক নিশ্চয়তা এই পর্যালোচনায় প্রতিষ্ঠিত হয়নি।

Backup কত দিন থাকে, restore-এর নিয়ম কী?

Repository পর্যালোচনায় অনুমোদিত automatic-backup সূচি, retention period, কত সময়ে বা কত পুরোনো তথ্য পর্যন্ত উদ্ধার হবে—এর লক্ষ্য, কিংবা সাম্প্রতিক restore-test ফল পাওয়া যায়নি। এসব প্রতিশ্রুতির ওপর নির্ভর করার আগে লিখিত শর্ত ও restore demonstration চান।

রেস্টুরেন্টের তথ্য কখন মুছে ফেলা হয়?

Privacy policy অনুযায়ী সক্রিয় অ্যাকাউন্টের তথ্য এবং আইন, কর, হিসাব বা বিরোধ নিষ্পত্তির প্রয়োজনে তথ্য রাখা হতে পারে। অ্যাকাউন্ট বন্ধের পরে ওই ব্যতিক্রম সাপেক্ষে তথ্য মুছতে বা পরিচয়হীন করতে পারে। নির্দিষ্ট deletion deadline বা backup থেকে মুছতে কত দিন লাগে, তা প্রতিষ্ঠিত নয়।

নিজের তথ্য export করা যাবে?

Report export প্ল্যাননির্ভর; এটি পুরো database backup নিজের সঙ্গে নিয়ে যাওয়ার প্রতিশ্রুতি নয়। কী তথ্য, কোন সময়ের এবং কোন file format দরকার তা জানান; কেনার আগে export পরীক্ষা ও account বন্ধের সময় সহায়তা নিশ্চিত করুন।

কোনো incident হলে কী করবেন?

সন্দেহজনক নিরাপত্তা সমস্যা support@rosuii.com-এ জানান। Password, payment credential বা অপ্রয়োজনীয় ব্যক্তিগত তথ্য পাঠাবেন না। এই পর্যালোচনায় অনুমোদিত প্রকাশ্য incident-history register, নিশ্চিত response time বা ২৪/৭ support schedule পাওয়া যায়নি। প্রকাশ্য নথি না থাকাকে কোনো incident ঘটেনি ধরে নেওয়া যাবে না।

স্বাধীন security review হয়েছে কি?

এই পেজের জন্য দেখা 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-এর আগে তদন্তের জন্য টিমকে যুক্তিসংগত সময় দিন।