امنیت فروشگاه اینترنتی؛ چک‌لیست عملی محافظت از سایت و مشتری
امنیت فروشگاه اینترنتی با چند اقدام پیوسته بهتر می‌شود: به‌روزرسانی، رمز قوی و ورود دومرحله‌ای، پشتیبان آزمایش‌شده، پرداخت امن و پایش رخدادها. این چک‌لیست را اجرا کنید.
امنیت فروشگاه اینترنتی از کجا شروع می‌شود؟
امنیت فروشگاه اینترنتی یک تنظیم یک‌باره نیست؛ مجموعه‌ای از عادت‌های مدیریتی و فنی است که باید مرتب انجام شوند. فروشگاه شما اطلاعات حساب مشتری، نشانی ارسال، سفارش‌ها و وضعیت پرداخت را نگه می‌دارد. بنابراین حتی اگر فروشگاه کوچک باشد، باید جلوی دسترسی غیرمجاز، از دست رفتن اطلاعات و توقف طولانی کسب‌وکار را بگیرد. این راهنما یک چک‌لیست اجرایی برای مدیران فروشگاه است؛ از کارهایی که همین امروز می‌توانید انجام دهید تا برنامه‌ای برای پشتیبان‌گیری و پاسخ به حادثه.
هیچ چک‌لیستی تضمین نمی‌کند که یک سایت هرگز آسیب نبیند. هدف، کم‌کردن احتمال خطا، محدود کردن اثر آن و بازگشت سریع‌تر به وضعیت سالم است. اگر از وردپرس و ووکامرس استفاده می‌کنید، راهنمای امنیت وردپرس و توصیه‌های امنیت ووکامرس را هم متناسب با نسخه و زیرساخت خود دنبال کنید.
۱. به‌روزرسانی‌ها و افزونه‌ها را مدیریت کنید
هستهٔ سیستم مدیریت محتوا، قالب، افزونه‌ها و کتابخانه‌های سمت سرور باید به‌روز باشند. نسخه‌های قدیمی ممکن است آسیب‌پذیری شناخته‌شده داشته باشند؛ از طرف دیگر، نصب هر افزونهٔ اضافه سطح نگهداری و احتمال ناسازگاری را بیشتر می‌کند. فقط افزونه‌هایی را نگه دارید که واقعاً استفاده می‌شوند، آن‌ها را از منبع معتبر بگیرید و افزونهٔ رهاشده یا بدون پشتیبانی را جایگزین کنید.
- پیش از به‌روزرسانی اصلی، از پایگاه داده و فایل‌های سایت نسخهٔ پشتیبان بگیرید.
- ابتدا تغییر را در محیط آزمایشی یا زمان کم‌ترافیک بررسی کنید.
- بعد از به‌روزرسانی، ورود مدیر، صفحهٔ محصول، سبد خرید و مسیر پرداخت را با یک سفارش آزمایشی مجاز بررسی کنید؛ سفارش واقعی و پرداخت ناخواسته ایجاد نکنید.
- فهرست نسخه‌ها و تاریخ آخرین بررسی را نگه دارید تا مشخص باشد چه چیزی نیاز به اقدام دارد.
۲. حساب‌های کاربری و دسترسی مدیران را محدود کنید
برای هر فرد حساب جداگانه بسازید و دسترسی را به اندازهٔ وظیفهٔ او محدود کنید. استفادهٔ چند نفر از یک حساب مدیر، تشخیص این‌که چه کسی تنظیمی را تغییر داده دشوار می‌کند. حساب‌های قدیمی کارکنان یا پیمانکاران را پس از پایان همکاری غیرفعال کنید و دسترسی مدیر را فقط به افراد ضروری بدهید.
برای حساب مدیر و ایمیل بازیابی، رمز عبور یکتا و طولانی انتخاب کنید و آن را در سایت دیگری تکرار نکنید. اگر امکان ورود دومرحله‌ای دارید، آن را برای حساب‌های حساس فعال کنید. ورود دومرحله‌ای زمانی مفید است که رمز لو برود، چون مهاجم به عامل دوم هم نیاز دارد. راهنمای OWASP برای احراز هویت دربارهٔ سیاست ورود، خطاهای قابل مشاهده و حفاظت حساب توضیح می‌دهد.
- نام کاربری پیش‌فرض یا رمزهای ساده و قابل حدس را کنار بگذارید.
- برای بازیابی حساب، ایمیل و شمارهٔ امن و در دسترس ثبت کنید.
- پس از هشدار ورود مشکوک، نشست‌های فعال را لغو و رمز را عوض کنید.
- کلیدهای API و رمزهای سرویس را در مقاله، تیکت عمومی، کد سمت مرورگر یا تصویر صفحه منتشر نکنید.
۳. پرداخت را فقط از مسیر رسمی بررسی کنید
صفحهٔ بازگشت از درگاه به‌تنهایی مدرک پرداخت موفق نیست. سرور فروشگاه باید نتیجهٔ تراکنش را از مسیر تأیید رسمی درگاه بررسی کند و مبلغ، شناسهٔ سفارش و شناسهٔ تراکنش را با فاکتور خودش تطبیق دهد. وضعیت سفارش فقط پس از تأیید معتبر در سرور تغییر کند. پیام کاربر، پارامتر URL یا تصویر رسید نباید به‌تنهایی سفارش را پرداخت‌شده کند.
اطلاعات کامل کارت بانکی را در سایت ذخیره نکنید. ارتباط باید HTTPS باشد و کلیدهای پذیرنده و امضا در تنظیمات محرمانهٔ سرور نگهداری شوند. دسترسی به گزارش پرداخت را محدود کنید و هنگام پشتیبانی فقط شناسهٔ لازم را درخواست کنید. اگر پرداخت ناموفق یا مبهم است، از پنل رسمی درگاه و گزارش سرور برای تطبیق استفاده کنید؛ برای حل مشکل، دوباره‌پرداخت‌کردن خودکار را بدون بررسی فعال نکنید.
۴. نسخهٔ پشتیبان را واقعاً قابل بازیابی کنید
نسخهٔ پشتیبان وقتی ارزش دارد که بتوان آن را بازیابی کرد. زمان‌بندی را با حجم سفارش‌ها و میزان تغییر سایت هماهنگ کنید. برای فروشگاهی که هر روز سفارش جدید می‌گیرد، پشتیبان پایگاه داده ممکن است به دفعات بیشتری از فایل‌های ثابت نیاز داشته باشد. نسخه‌ها را فقط روی همان سروری که سایت قرار دارد نگه ندارید؛ خرابی دیسک یا دسترسی مهاجم می‌تواند هر دو را از بین ببرد.
- پشتیبان پایگاه داده و فایل‌ها را جداگانه یا با روش روشن و قابل آزمون تهیه کنید.
- نسخهٔ رمزگذاری‌شده را در محل امن و جدا از سرور اصلی نگه دارید.
- یک بازیابی آزمایشی را در محیط جداگانه انجام دهید و زمان آن را ثبت کنید.
- مدت نگهداری نسخه‌ها و مسئول بررسی موفقیت پشتیبان را مشخص کنید.
- پس از تعلیق سایت، حذف یا جابه‌جایی، از ادامهٔ کار زمان‌بندها و باقی‌ماندن فایل‌های قدیمی مطمئن شوید.
۵. بارگذاری فایل و فرم‌ها را با احتیاط طراحی کنید
فرم تماس، تصویر محصول، فایل‌های پیوست و ورودی‌های جست‌وجو می‌توانند نقطهٔ ورود دادهٔ نامعتبر باشند. نوع فایل را فقط از پسوند تشخیص ندهید؛ نوع واقعی محتوا و اندازه را هم کنترل کنید. فایل‌های ناشناس را با نام تصادفی ذخیره کنید و در صورت امکان آن‌ها را خارج از مسیر اجرای کد نگه دارید. برای بارگذاری، محدودیت اندازه و تعداد در نظر بگیرید و پیام خطا را طوری نمایش دهید که جزئیات داخلی سرور افشا نشود.
در فرم‌های ورود و تغییر اطلاعات، داده را در سرور اعتبارسنجی کنید. برای پرس‌وجوهای پایگاه داده از دستورهای پارامتری استفاده کنید و ورودی را به‌عنوان بخشی از دستور SQL نچسبانید. خروجی را متناسب با محل نمایش، امن کدگذاری کنید. اگر مسیرهای تغییردهندهٔ اطلاعات از مرورگر فراخوانی می‌شوند، کنترل مبدأ و سازوکار ضد درخواست جعلی را در نظر بگیرید؛ `SameSite` کوکی به‌تنهایی جای بررسی کامل این سناریو را نمی‌گیرد. راهنمای OWASP دربارهٔ CSRF جزئیات دفاع چندلایه را توضیح می‌دهد.
۶. دسترسی شبکه و تنظیمات سرور را بازبینی کنید
فقط سرویس‌هایی باید از اینترنت قابل دسترسی باشند که برای کار سایت لازم‌اند. پنل مدیریت سرور، پایگاه داده و سرویس‌های داخلی را بدون نیاز عمومی نکنید. اگر چند سایت مشتری روی یک سرور اجرا می‌شوند، جداسازی فرایندها و فایل‌ها، محدودیت منابع و مجوزهای هر سایت را بررسی کنید تا خطای یک سایت به سایت‌های دیگر سرایت نکند.
گواهی HTTPS، تمدید خودکار آن، تاریخ انقضا، نسخهٔ سیستم‌عامل و دسترسی SSH را دوره‌ای بررسی کنید. برای SSH از کلید امن و حساب محدود استفاده کنید و دسترسی‌های بلااستفاده را ببندید. فایروال باید با فهرست سرویس‌های واقعاً موردنیاز هماهنگ باشد؛ باز کردن یک بازهٔ بزرگ پورت فقط برای افزایش ظرفیت، جای معماری و کنترل دسترسی را نمی‌گیرد. اگر چند پورت برای سایت‌های مشتری لازم است، دسترسی آن‌ها را به محدودهٔ اجرای همان سرویس محدود و مالک هر پورت را ثبت کنید.
۷. رخدادها را ثبت کنید و از قبل برنامه داشته باشید
ثبت رویداد ورود مدیر، تغییر تنظیمات، خطاهای پرداخت و عملیات پشتیبان کمک می‌کند علت مشکل را پیدا کنید. گزارش‌ها را طوری تنظیم کنید که رمز، کد یک‌بارمصرف، شمارهٔ کامل کارت و توکن‌ها داخل آن ثبت نشوند. دسترسی و مدت نگهداری گزارش را محدود کنید؛ گزارش امنیتی هم خودش دادهٔ حساس دارد.
اگر نشانهٔ دسترسی غیرمجاز دیدید، ابتدا حساب‌های مدیریتی و کلیدهای سرویس را ایمن کنید، نشست‌ها را لغو کنید، نسخه‌های پشتیبان را حفظ کنید و زمان و شواهد را ثبت کنید. پیش از پاک‌کردن فایل یا بازگردانی نسخه، اثر آن را بررسی کنید تا شواهد از بین نرود. برای حادثهٔ جدی، از متخصص زیرساخت و درگاه پرداخت کمک بگیرید و وضعیت سفارش‌های درگیر را با گزارش معتبر تطبیق دهید.
چک‌لیست کوتاه مدیر فروشگاه
- [ ] حساب مدیر رمز یکتا دارد و ورود دومرحله‌ای در دسترس فعال است.
- [ ] کاربران قدیمی حذف یا غیرفعال شده‌اند و هر حساب دسترسی متناسب دارد.
- [ ] افزونه‌ها و قالب‌های غیرضروری حذف و نسخه‌های باقی‌مانده به‌روز هستند.
- [ ] HTTPS و تمدید گواهی فعال است.
- [ ] تأیید پرداخت در سمت سرور انجام می‌شود و مبلغ با فاکتور تطبیق دارد.
- [ ] پشتیبان خارج از سرور اصلی نگهداری و بازیابی آن آزمایش شده است.
- [ ] بارگذاری فایل محدودیت اندازه و نوع دارد و فایل به‌عنوان کد اجرا نمی‌شود.
- [ ] سرویس‌ها و پورت‌های عمومی با نیاز واقعی تطبیق دارند.
- [ ] گزارش‌ها برای رویدادهای مهم فعال‌اند و اطلاعات محرمانه را ثبت نمی‌کنند.
- [ ] مسئول پاسخ‌گویی و راه بازیابی در زمان اختلال مشخص است.
برای آماده‌سازی ساختار محتوای فروشگاه، چک‌لیست صفحهٔ محصول و راهنمای ساخت فروشگاه اینترنتی را هم ببینید. اگر هنوز در مرحلهٔ انتخاب راه‌حل هستید، امکانات سایت‌ساز فروشگاهی دیبیت و تعرفه‌ها را بررسی کنید. اجرای درست چک‌لیست، همراه با پشتیبان قابل‌بازیابی و دسترسی محدود، پایهٔ خوبی برای نگهداری امن‌تر فروشگاه است.