تقریباً هر راهنمای امنیتِ فروشگاه با SSL شروع می‌شود و بیشترِ وزنش را هم به آن می‌دهد. این ترتیب امروز اشتباه است — و اشتباهی است که خواننده را در امنیتِ کاذب می‌گذارد:

SSL دیگر یک اقدامِ امنیتی نیست؛ یک پیش‌فرض است. بی آن، مرورگر هشدار می‌دهد و درگاهِ پرداخت وصل نمی‌شود — پس داشتنش اجباری است، ولی داشتنش هیچ چیزی را «امن» نمی‌کند.

و نکته‌ی مهم‌تر: SSL از چیزی محافظت می‌کند که تقریباً هیچ‌وقت مسئله‌ی فروشگاه‌های کوچک و متوسط نیست — شنودِ اطلاعات در مسیرِ شبکه. آنچه واقعاً اتفاق می‌افتد سه چیزِ دیگر است:

و از این سه، سومی شایع‌ترین است و هیچ ابزارِ امنیتی جلویش را نمی‌گیرد — فقط بکاپ می‌گیرد.

ستونِ آخرِ این جدول، کلِ حرفِ این مقاله را در یک نگاه نشان می‌دهد:

ریسکِ واقعینمونهچه چیزی جلویش را می‌گیردSSL کمک می‌کند؟
دسترسیِ لو‌رفتهرمزِ مشترک، دسترسیِ همکارِ سابقحسابِ جدا + احرازِ دومرحله‌ای + فهرستِ دسترسی❌ خیر
نرم‌افزارِ وصله‌نشدهقالب یا افزونه‌ی قدیمیبه‌روزرسانیِ منظم + حذفِ اجزای بی‌استفاده❌ خیر
خطای انسانیِ خودیپاک شدنِ داده، تغییرِ اشتباهبکاپِ چندنسخه‌ای و آزمایش‌شده❌ خیر
ازدست‌رفتنِ دامنهتمدیدنشدن، مالکیتِ نامشخصمالکیت به نامِ خودتان + تمدیدِ خودکار❌ خیر
شنودِ اطلاعات در مسیرِ شبکهSSL✅ بله

یعنی SSL دقیقاً یک ریسک را پوشش می‌دهد، و آن ریسک پایین‌ترین سطرِ فهرستِ نگرانی‌های یک فروشگاهِ کوچک است. پس این مقاله از سطرِ سومِ جدول شروع می‌کند — از شایع‌ترین.

«بکاپِ منظم بگیرید» توصیه‌ای است که همه می‌دانند و کمتر کسی واقعاً دارد. چون:

بکاپی که بازگردانی‌اش آزمایش نشده، بکاپ نیست — یک فرض است.

و آزمونش ساده است: یک بار بازگردانی کنید (روی یک نسخه‌ی آزمایشی) و ببینید چه چیزی جا افتاده. تقریباً همیشه چیزی جا می‌افتد. کنارِ این آزمون، سه سؤال که جواب‌هایشان معمولاً بد است:

و یک سؤالِ چهارم که کمتر پرسیده می‌شود: چه کسی می‌تواند بازگردانی کند؟ اگر جواب فقط یک نفرِ بیرونی است و او در دسترس نباشد، شما بکاپ دارید ولی دسترسی به بازگردانی ندارید.

در فروشگاه‌های کوچک و متوسط، آنچه «هک شدن» نامیده می‌شود در بیشترِ موارد چیزِ ساده‌تری است: لو رفتنِ یک دسترسی. و درمانش هم فنی نیست؛ سازمانی است:

و از این سه، یکی از بقیه مهم‌تر است:

⭐⭐ ایمیلِ اصلی، کلیدِ اصلیِ کسب‌وکارِ آنلاینِ شماست. چون بازیابیِ رمزِ همه‌چیزِ دیگر از آن می‌گذرد — دامنه، سرور، پنل، درگاه، شبکه‌های اجتماعی. کسی که به ایمیلِ شما دسترسی داشته باشد، به همه‌چیز دسترسی دارد، حتی اگر رمزِ هیچ‌کدام را نداند. پس اگر فقط یک جا را دومرحله‌ای می‌کنید، همان ایمیل باشد.

⚠️ و یک موردِ خاصِ پرتکرار: دسترسیِ طراح یا توسعه‌دهنده‌ی سابق. این را در روزِ پایانِ همکاری چک کنید، نه ماه‌ها بعد — و از ابتدا حساب‌ها را با ایمیلِ خودتان بسازید، نه با ایمیلِ او. منطقِ کاملش در مالکیت در پروژه‌های نرم‌افزاری آمده.

نکته

یک کارِ ده‌دقیقه‌ای که ارزشِ بیشتری از خیلی از اقدامات فنی دارد: یک فهرست بنویسید از همه‌ی حساب‌هایی که کسب‌وکارتان به آن‌ها وابسته است — دامنه، هاست، ایمیل، پنلِ سایت، درگاه، پیام‌رسان‌ها، شبکه‌های اجتماعی، سرویسِ پیامک — و کنارِ هرکدام بنویسید با کدام ایمیل ساخته شده و چه کسی به آن دسترسی دارد. بیشترِ فروشنده‌ها با نوشتنِ همین فهرست، دو یا سه موردِ نگران‌کننده پیدا می‌کنند که سال‌ها از آن‌ها بی‌خبر بودند.

بخشِ بزرگی از نفوذها از دلِ نرم‌افزارِ قدیمی و وصله‌نشده می‌آید — و این جمله برای همه‌ی فروشگاه‌ها یک معنا ندارد. هرچه اجزای بیرونیِ بیشتری در سایتتان باشد (قالب، افزونه، کتابخانه)، سطحِ چیزی که باید مراقبش باشید بزرگ‌تر است.

یعنی امنیت اینجا به یک تصمیمِ معماری وصل می‌شود، نه به یک اقدامِ جداگانه: بارِ نگه‌داریِ یک سایتِ مبتنی بر اجزای عمومی با یک سایتِ اختصاصیِ ساده یکی نیست (مقایسه‌ی عملی‌اش در ووکامرس یا سایت اختصاصی و سقف‌های ابزارهای آماده در اینجا).

و مستقل از انتخابتان، دو قاعده‌ی عملی:

مهم‌ترین تصمیمِ امنیتیِ یک فروشگاه، انتخابِ ابزار نیست — انتخابِ چیزهایی است که ذخیره نمی‌کند.

روشن‌ترین نمونه‌اش پرداخت است: اطلاعاتِ کارتِ مشتری هیچ‌وقت نزدِ شما نمی‌آید، چون پرداخت روی درگاهِ بانکیِ رسمی انجام می‌شود (مقایسه‌ی درگاه‌ها). این بزرگ‌ترین لطفی است که به خودتان می‌کنید: ریسکی که وجود ندارد، مدیریت هم نمی‌خواهد.

و همین منطق را تعمیم دهید:

از مشتری فقط چیزی بخواهید که واقعاً لازم دارید. کدِ ملی، تاریخِ تولد، نشانیِ دقیق برای کالای دیجیتال، یا هر فیلدِ «شاید به کار بیاید» — اگر لازم نیست، یک بدهیِ امنیتی است که هیچ سودی برایتان ندارد و در حادثه هزینه‌اش را می‌دهید. صفحاتِ اطلاعاتیِ الزامیِ فروشگاه و اینکه چه چیزی باید کجا نوشته شود، در قوانین فروش و حقوقِ مصرف‌کننده آمده.

اینجا یک تفکیکِ مهم لازم است که بیشترِ متن‌ها انجامش نمی‌دهند:

قفلِ کنارِ آدرس یک نشانه‌ی اعتماد است، نه یک تضمینِ امنیت.

و دلیلش ساده است: گواهیِ SSL امروز به‌سادگی و اغلب رایگان قابلِ دریافت است، پس سایتِ کلاهبردار هم آن قفل را دارد. نتیجه‌ی عملی برای شما:

به مشتری نگویید «سایتِ ما امن است چون https دارد» — این جمله دیگر چیزی اثبات نمی‌کند و خریدارِ باتجربه هم می‌داند. نبودش یک هشدارِ جدی است، ولی بودنش یک مزیت نیست.

آنچه واقعاً به مشتری سیگنالِ امنیت می‌دهد چیزهای دیگری است: هویتِ رسمی و قابلِ استعلام (نمادِ اعتمادانجامِ پرداخت روی درگاهِ بانکی، شرایطِ روشنِ بازگشت و تماس، و پاسخ‌دهیِ سریع — منطقِ کاملش در نشانه‌های اعتمادِ مشتری آمده.

این جمله ساده به‌نظر می‌رسد و پیامدِ بودجه‌ای مهمی دارد. امنیت سه کارِ تکرارشونده است: به‌روزرسانی، بکاپ و بازبینیِ دسترسی‌ها. هیچ‌کدام یک‌بار انجام نمی‌شوند.

پس پروژه‌ای که هزینه‌ی سالِ دومش در بودجه نیست، سالِ دوم ناامن می‌شود — نه چون کسی سهل‌انگاری کرده، بلکه چون کسی مسئولِ آن کارها نبوده. هنگامِ سفارشِ سایت، این را صریح مشخص کنید: چه کسی به‌روزرسانی می‌کند، چه کسی بکاپ را چک می‌کند، و در حادثه چه کسی جواب می‌دهد. ابهام در این سه سؤال، خودش یک ریسکِ امنیتی است.

حواستان باشد

و یک ریسکِ عملیاتی که به‌نظر امنیتی نمی‌آید ولی هست: از دست دادنِ دامنه. دامنه‌ای که تمدید نشود، در بدترین حالت به دستِ دیگری می‌افتد — و آن‌وقت همه‌ی ایمیل‌ها، بازیابی‌های رمز و اعتبارِ ساخته‌شده‌ی سالیانِ شما با آن می‌رود. سه کار: دامنه به نامِ خودتان، تمدیدِ چندساله یا خودکار، و ایمیلِ اطلاع‌رسانیِ دامنه به آدرسی که واقعاً خوانده می‌شود. این ساده‌ترین و پرهزینه‌ترین خطای این حوزه است.

در لحظه‌ی حادثه، ترتیب مهم‌تر از سرعت است. یک ترتیبِ آرام و منطقی:

و بعد از پایانِ ماجرا، یک کارِ آخر که بیشترین ارزش را دارد: بنویسید چه شد و چه چیزی جلویش را می‌گرفت. این یادداشتِ کوتاه، در حادثه‌ی بعدی وقتِ زیادی برایتان می‌خرد — و همان‌طور که در پشتیبانی مشتری هم دیدیم، حادثه‌ی ثبت‌نشده تکرار می‌شود.

و قبل از افتتاح، یک بار همه‌ی این‌ها را کنارِ بقیه‌ی موارد با چک‌لیستِ کاملِ افتتاح رد کنید. جای این بحث در تصویرِ کلیِ فناوری‌های فروشگاه هم در آینده‌ی تجارت الکترونیک آمده — آنجا امنیت جزوِ «بدهی‌ها» است، یعنی چیزی که قبل از هر فناوریِ تازه‌ای باید بسته شود. (و توجه کنید که سرعت و امنیت گاهی به هم گره می‌خورند: افزودنِ لایه‌های امنیتیِ سنگین می‌تواند سایت را کند کند — سرعتِ سایت.)

سه چیز را ببرید. اول: SSL یک پیش‌فرض است نه یک اقدامِ امنیتی — آنچه واقعاً اتفاق می‌افتد لو رفتنِ دسترسی، نرم‌افزارِ وصله‌نشده و خطای انسانیِ خودی است؛ و سومی شایع‌ترین است و فقط بکاپ جلویش را می‌گیرد. دوم: بکاپی که بازگردانی‌اش آزمایش نشده یک فرض است — چند نسخه، جای دیگر، شاملِ پایگاه داده؛ و ایمیلِ اصلیِ شما کلیدِ همه‌چیز است، پس اگر فقط یک جا را دومرحله‌ای می‌کنید همان باشد. سوم: قفلِ کنارِ آدرس یک نشانه‌ی اعتماد است نه تضمینِ امنیت، چون سایتِ کلاهبردار هم آن را دارد — آنچه به مشتری اطمینان می‌دهد هویتِ قابلِ استعلام و درگاهِ رسمی است.

و در نگاهِ بودجه: امنیت یک وضعیت نیست، یک هزینه‌ی جاری است — فروشگاهی که مسئولِ نگه‌داری‌اش مشخص نیست، دیر یا زود ناامن می‌شود.

بگویید بکاپتان کجا ذخیره می‌شود و چند نسخه نگه داشته می‌شود — اگر جوابش را نمی‌دانید، همان اولین چیزی است که باید چک شود.برآورد هزینه و زمان را در یک تماس کوتاه می‌گیرید.