امنیت سفارش‌ها، نقش کارمندان، جداسازی کسب‌وکارها و ردپای تغییرات

اطلاعات سفارش ترکیبی از داده شخصی مشتری، قیمت قرارداد، وضعیت پرداخت، نشانی تحویل و سوابق خدمات است. دسترسی به همه آن‌ها برای تمام کارمندان ضرورت ندارد. در سورس آناما اقدامات سفارش با بررسی قابلیت sales/orders و رکوردهای منابع جانبی با سیاست مجوز مستقل انجام می‌شود. این کنترل‌ها بخشی از صحت مالی و انبار هم هستند؛ چون تأیید پرداخت یا ارسال توسط نقش نامناسب می‌تواند ضرر واقعی ایجاد کند.

نقش‌های عملیاتی پیشنهادی

مسئول فروش: دیدن سفارش و ثبت/هماهنگی اقلام، اما نه لزوماً تأیید پول بانک. مسئول مالی: بررسی فیش، تراکنش و بازپرداخت طبق اختیارات مصوب. انباردار: دسترسی به SKU و عملیات آماده‌سازی، بدون نیاز به تصویر مدارک بانکی. مسئول ارسال: نشانی، گیرنده و وضعیت مرسوله را می‌بیند. پشتیبان خدمات: پرونده‌های مرجوعی و گارانتی را پیگیری می‌کند. مدیر: نظارت بر تغییر حساس و رسیدگی استثناها. این تفکیک پیشنهاد عملیاتی است؛ نوع نقش‌های قابل تعریف بسته به تنظیمات آناما است.

تفاوت permission با Tenant

مجوز مشخص می‌کند کاربر چه اقدامی را در محدوده دسترسی خود می‌تواند انجام دهد؛ Tenant مشخص می‌کند داده متعلق به کدام کسب‌وکار است. یک مدیر با اجازه مشاهده سفارش نباید بتواند با حدس شناسه، اطلاعات فروشگاه دیگری را ببیند. مسیر object_for و queryset_for برای اعمال محدوده در منطق سفارش دیده می‌شود؛ ولی امنیت واقعی باید با تست‌های سرور و دیتابیس هم تأیید شود، نه صرف مخفی‌کردن دکمه در مرورگر.

چرا دکمه ثبت وجه برای من دیده نمی‌شود؟

سه علت محتمل است: سفارش در وضعیت نامناسب است؛ روش پرداخت اجازه این اقدام را ندارد؛ یا مجوز نقش کافی نیست. نبود دکمه الزاماً باگ استایل نیست. اگر قبلاً شخص دیگری پرداخت را تأیید کرده باشد، اقدام نباید دوباره فعال شود. برای رفع مشکل، وضعیت زنده سفارش، روش پرداخت، انقضا و دسترسی نقش را کنترل کنید.

چه داده‌هایی محرمانه‌اند؟

نشانی منزل، موبایل مشتری، تصویر فیش، شماره حساب، اطلاعات کارت، کد لایسنس و یادداشت‌های حساس. در پیام پشتیبانی شماره کارت کامل و CVV2 درخواست نکنید؛ رمز پویا را مطلقاً نخواهید. فایل خصوصی رسید یا جزئیات خام پاسخ provider را در گزارش قابل انتشار کپی نکنید. در اسکرین‌شات آموزشی از داده نمونه غیرواقعی استفاده کنید.

ثبت ردپا و بازیابی اختلاف

اقدام‌های سفارش از مسیر Audit مرکزی ثبت می‌شوند و در پنجره سوابق نیز تاریخچه فعالیت نمایش داده می‌شود. برای بررسی اختلاف، حداقل زمان، عامل، عملیات، شماره سفارش و مرجع غیرحساس پرداخت یا ارسال را کنار هم قرار دهید. ادیت مستقیم پایگاه داده برای حذف یک اشتباه، تاریخچه را از بین می‌برد. اقدامات حساس باید امکان پیگیری و تعیین مسئول داشته باشند.

آزمون‌های ضروری امنیت

کارمند فروشگاه A نباید سفارش یا فیش فروشگاه B را ببیند؛ کارمند صرفاً مشاهده‌گر نباید mark_manual_paid یا refund انجام دهد؛ مشاهده جزئیات مرسوله و گارانتی باید به مجوز منبع مربوط وابسته باشد؛ درخواست مستقیم API با شناسه حدسی باید سرور رد شود؛ داده‌های حساس نباید در log عمومی یا پاسخ خطای سمت مشتری برگردند. این آزمون‌ها معیار پذیرش نسخه‌اند، نه ادعای انجام‌شدن خودکارشان با انتشار مستندات.

مطالعه مرتبط: راهنمای نقش‌ها، جزئیات سفارش، کنترل‌های مالی.