امنیت سایت‌سازها؛ چک‌لیست حساب، دامنه و افزونه‌ها

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

پاسخ کوتاه: امنیت سایت‌ساز SaaS یعنی کنترل هم‌زمان هویت و بازیابی حساب، نقش‌ها، دامنه و DNS، Appها و اسکریپت‌های ثالث، داده‌های مشتری، خروجی و بازیابی، پایش و پاسخ به رخداد. ادعای «زیرساخت امن است» فقط بخشی از زنجیره را پوشش می‌دهد.

امنیت سایت‌ساز چیست و چه چیزی نیست؟

سایت‌سازهایی که به‌صورت SaaS ارائه می‌شوند معمولاً سیستم‌عامل، شبکه، هسته محصول و بخشی از مقابله با حملات حجمی را مدیریت می‌کنند. مشتری نیز محتوا، کاربران، دامنه، تنظیمات، Appها، کلیدها، داده و فرایند کسب‌وکار را کنترل می‌کند. مرز دقیق بین این دو در هر سرویس و پلن متفاوت است؛ بنابراین صفحه امنیت، قرارداد، Help Center و قابلیت‌های واقعی حساب آزمایشی را مبنا قرار دهید، نه عبارت‌های تبلیغاتی.

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

نقشه تهدید: مهاجم از کجا وارد می‌شود؟

تهدید را بر اساس دارایی و مسیر اثر بنویسید. برای یک کسب‌وکار ایرانی، این دارایی‌ها معمولاً شامل حساب Owner، ایمیل بازیابی، دامنه، مشتریان، سفارش‌ها، درگاه پرداخت، فرم سرنخ، محتوای سئو و اعتبار برند است.

• تصاحب حساب: رمز تکراری، فیشینگ، Recovery ضعیف یا نشست باز روی دستگاه مشترک.
• ربایش دامنه: دسترسی به Registrar یا DNS و هدایت کاربر به صفحه جعلی.
• دسترسی بیش از نیاز: اکانت آژانس، فریلنسر یا همکار سابق با نقش Admin.
• زنجیره تأمین: App، Widget، Pixel یا JavaScript ثالث که تغییر می‌کند یا داده می‌خواند.
• نشت داده: فرم عمومی، فایل قابل حدس، Export بدون حفاظت یا ایمیل اشتباه.
• خطای پیکربندی: انتشار صفحه آزمایشی، Domain اشتباه، دسترسی عمومی یا Automation معیوب.
• قفل‌شدن کسب‌وکار: تعلیق حساب، مشکل پرداخت یا دسترسی، نبود Export و وابستگی کامل به قالب اختصاصی.

ریسک را با فرمول ساده «احتمال × اثر» اولویت‌بندی کنید. اختلال ۲۰ دقیقه‌ای وبلاگ و تغییر شماره شبا یا مقصد درگاه، اثر یکسان ندارند؛ پس کنترل‌های حیاتی را دور جریان پول، هویت و دامنه قرار دهید.

۱. حساب مالک را مثل کلید خزانه مدیریت کنید

Owner شخصی نباشد

حساب مالک را به ایمیل سازمانی پایدار متصل کنید؛ نه ایمیل شخصی یک کارمند یا پیمانکار. مالک حقوقی دامنه، مالک حساب سایت‌ساز و مسئول پرداخت باید در مستند داخلی مشخص باشند. حداقل دو فرد پاسخ‌گو برای Recovery تعریف کنید، اما ورود مشترک نسازید.

MFA کافی است؟

MFA مبتنی بر پیامک یا OTP از رمز تنها بهتر است، اما در برابر فیشینگ کامل نیست. هرجا پلتفرم پشتیبانی می‌کند، Passkey یا کلید امنیتی FIDO را برای Owner و Admin ترجیح دهید. NIST نیز ورودهای رمزنگاری‌شده مبتنی بر WebAuthn را نمونه مقاوم در برابر فیشینگ می‌داند. کدهای Recovery را آفلاین و کنترل‌شده نگه دارید و بازیابی را هر شش ماه تمرین کنید.

برای طراحی Recovery، سیاست نشست و Offboarding، از راهنمای MFA برای پنل مدیریت استفاده کنید. هدف فقط فعال‌کردن یک گزینه نیست؛ باید بدانید در فقدان تلفن، خروج همکار یا قفل‌شدن ایمیل چه می‌کنید.

بهداشت نشست و ایمیل

• رمز منحصربه‌فرد و طولانی را در Password Manager سازمانی نگه دارید.
• دستگاه‌ها و Sessionهای فعال را ماهانه بازبینی و موارد ناشناس را Revoke کنید.
• ایمیل بازیابی و حساب Registrar را با سطحی برابر یا بالاتر محافظت کنید.
• اعلان ورود، تغییر ایمیل، تغییر روش پرداخت و افزودن Admin را فعال و به بیش از یک نفر ارسال کنید.

۲. Role و دسترسی را بر اساس کار واقعی بدهید

اصل حداقل دسترسی یعنی نویسنده برای ویرایش متن به Billing، Domain یا App Management دسترسی نداشته باشد. به‌جای اشتراک رمز Owner، برای هر فرد حساب جدا بسازید تا هم ابطال ساده شود و هم ردپا بماند.

فرایند Joiner–Mover–Leaver داشته باشید: قبل از شروع، نقش تأیید شود؛ هنگام تغییر شغل، دسترسی اصلاح شود؛ و در روز پایان همکاری، Session، Token، API key و App connection لغو شود. حذف نام کاربری بدون ابطال Token کافی نیست.

۳. دامنه و DNS را خارج از نقطه شکست واحد نگه دارید

سایت‌ساز ممکن است اتصال دامنه را ساده کند، اما دامنه هویت مستقل کسب‌وکار است. اگر همان ایمیل، همان رمز و همان فرد هم سایت‌ساز و هم Registrar را کنترل کند، یک رخداد همه مسیرها را می‌گیرد.

• دامنه را به نام کسب‌وکار و با اطلاعات تماس قابل بازیابی ثبت کنید.
• برای Registrar، DNS Provider و ایمیل مالک MFA جدا فعال کنید.
• Registrar Lock یا Transfer Lock را فعال و اعلان تغییرات را بررسی کنید.
• Zone DNS و فهرست Recordهای حیاتی را مستند و دوره‌ای Export کنید.
• تاریخ انقضای دامنه، روش پرداخت و دو مسئول تمدید را در تقویم ثبت کنید.
• پس از هر تغییر DNS، وب‌سایت، ایمیل و رکوردهای احراز هویت ایمیل را تست کنید.

HTTPS را روی دامنه اصلی و زیردامنه‌های مورد استفاده پایش کنید؛ سبز بودن قفل در یک مرورگر تضمین تمدید آینده نیست. انتخاب و تمدید امن را در راهنمای گواهی SSL و TLS مرحله‌به‌مرحله توضیح داده‌ایم.

۴. App و Integration را قرارداد دسترسی بدانید

نصب App مثل افزودن یک همکار نرم‌افزاری است. لوگوی زیبا، امتیاز Marketplace یا نصب از فروشگاه رسمی به‌تنهایی ریسک را صفر نمی‌کند. پیش از نصب، Publisher، مجوزها، داده مقصد، سیاست نگهداری، روش حذف و پاسخ‌گویی امنیتی را بررسی کنید.

فرم ثبت App

• مالک تجاری و مالک فنی App چه کسانی‌اند؟
• به کدام Customer، Order، Content، Domain یا Billing دسترسی دارد؟
• آیا دسترسی Read کافی است یا Write واقعاً لازم است؟
• داده در کدام سرویس پردازش می‌شود و حذف آن چگونه تأیید می‌شود؟
• آخرین استفاده چه زمانی بوده و تاریخ بازبینی بعدی چیست؟
• پس از Uninstall آیا OAuth token، Webhook و داده کپی‌شده نیز حذف می‌شوند؟

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

۵. اسکریپت ثالث و Tag Manager را زیر حاکمیت بیاورید

Pixel تبلیغاتی، Chat Widget، Heatmap، فونت، فرم و Tag Manager در مرورگر کاربر اجرا می‌شوند. OWASP سه ریسک مهم JavaScript ثالث را از دست‌دادن کنترل تغییرات، اجرای کد و افشای داده می‌داند. در سایت‌سازها معمولاً دست شما برای CSP یا SRI کاملاً باز نیست؛ پس کنترل مدیریتی اهمیت بیشتری پیدا می‌کند.

• فهرست Scriptها، هدف، مالک، Domain مقصد و داده ارسالی را نگه دارید.
• حق Publish در Tag Manager را محدود و تغییرها را با Approval انجام دهید.
• هیچ Secret، Token خصوصی یا اطلاعات حساس را در کد سمت مرورگر قرار ندهید.
• اسکریپت را ابتدا روی نسخه آزمایشی و با سناریوی فرم، پرداخت و سرعت تست کنید.
• Tag بلااستفاده را Disable و سپس حذف کنید؛ فقط خاموش‌کردن Trigger بدهی را پنهان می‌کند.
• اگر پلتفرم CSP، SRI یا Sandbox ارائه می‌کند، ابتدا در حالت Report/Test ارزیابی کنید تا Checkout یا فرم نشکند.

۶. داده فرم‌ها را کم، محدود و زمان‌دار جمع کنید

امن‌ترین داده، داده‌ای است که بی‌دلیل جمع نشده. برای هر فیلد فرم بپرسید آیا برای ارائه خدمت لازم است، چه کسی آن را می‌بیند، کجا ارسال می‌شود و چه زمانی حذف خواهد شد. کپی‌شدن هر سرنخ در ایمیل، CRM، پیام‌رسان و Spreadsheet چند برابر سطح حمله می‌سازد.

• فیلدهای غیرضروری را حذف و فایل آپلودی را از نظر نوع، اندازه و دسترسی محدود کنید.
• گیرندگان ایمیل فرم و Forwardها را بازبینی کنید؛ آدرس قدیمی را حذف کنید.
• دسترسی Export مشتریان را فقط به نقش‌های نیازمند بدهید و فایل را رمزگذاری/زمان‌دار کنید.
• Retention مشخص برای سرنخ ناموفق، تیکت و داده سفارش تعیین کنید.
• فرم را با داده ساختگی تست کنید تا مقصد، اعلان خطا و نمایش عمومی اطلاعات روشن شود.

برای پیوند دادن نوع داده، اثر نشت و هزینه کنترل، راهنمای بودجه حریم خصوصی داده مبنای تصمیم خوبی است.

۷. پرداخت و فروشگاه را جداگانه Threat Model کنید

در فروشگاه، خطر فقط سرقت کارت نیست. تغییر مقصد پرداخت، دست‌کاری قیمت، Coupon نامحدود، Export سفارش، Refund غیرمجاز و دسترسی پشتیبانی نیز مهم‌اند. اگر Checkout روی درگاه میزبانی می‌شود، بخشی از پردازش به ارائه‌دهنده منتقل شده؛ اما امنیت حساب، محصول، Integration و تطبیق سفارش همچنان با شماست.

• تغییر درگاه، حساب تسویه و Refund را به Admin محدود و اعلان‌دار کنید.
• تراکنش پلتفرم، درگاه و حسابداری را روزانه Reconcile کنید.
• Order ساختگی با مبلغ کم برای مسیر کامل خرید، ایمیل و Callback اجرا کنید.
• کلیدهای Sandbox و Production را جدا و Rotation آن‌ها را مستند کنید.
• برای افت فروش، افزایش Refund یا تغییر ناگهانی مقصد هشدار بسازید.

۸. Backup را با Export و Restore اشتباه نگیرید

نسخه پشتیبان زیرساخت فروشنده لزوماً ابزار بازیابی مشتری نیست. History ممکن است فقط بعضی تنظیمات را برگرداند؛ Export ممکن است Media، SEO، Automation، Form submission یا Theme را کامل پوشش ندهد. قابلیت دقیق را روی پلن خودتان آزمایش کنید.

حداقل بسته خروج

محتوا، تصویر اصلی، محصول، سفارش، مشتری، Redirect، تنظیمات دامنه، Appها، Automation، Template، داده فرم و گزارش‌های مالی را بر اساس اهمیت فهرست کنید. برای هر مورد، Format خروجی، تناوب، محل امن، مسئول و زمان بازیابی هدف را بنویسید.

هر فصل یک «تمرین خروج» انجام دهید: یک نمونه محتوا، ده محصول یا مجموعه‌ای محدود از رکوردها را Export کنید، فایل را باز کنید و روی محیط جایگزین یا ابزار مستقل بخوانید. فایل خراب یا ناقص Backup نیست. طراحی RPO/RTO و Runbook را در راهنمای بازیابی فاجعه سایت تکمیل کنید.

۹. لاگ و پایش را پیش از حادثه آماده کنید

وقتی رخداد اتفاق افتاد، پرسش‌های اصلی این‌اند: چه کسی وارد شد، چه چیزی تغییر کرد، چه داده‌ای خوانده یا Export شد و اثر از چه زمانی شروع شد؟ پلتفرمی که Audit Log کافی ندارد، هزینه کشف و اثبات را بالا می‌برد.

Log را در صورت امکان بیرون از همان حساب نگه دارید تا مهاجم نتواند هم رخداد و هم ردپا را حذف کند. در ارزیابی فروشنده بپرسید Log چه رویدادهایی را پوشش می‌دهد، چند روز نگه داشته می‌شود، Export یا API دارد و آیا فقط در پلن گران‌تر قابل دسترس است. راهنمای Secure by Demand سازمان CISA نیز دسترسی مشتری به لاگ‌های امنیتی را معیار مهم خرید SaaS می‌داند.

۱۰. WAF و DDoS را متناسب با مرز پلتفرم انتخاب کنید

بخش عمده کنترل شبکه در اختیار سایت‌ساز است. افزودن Proxy یا CDN ثالث ممکن است مفید، غیرقابل پشتیبانی یا حتی مخل اتصال دامنه باشد. قبل از تغییر Nameserver، شرایط پلتفرم، مسیر TLS، Webhook، IP allowlist و پشتیبانی را بررسی کنید.

اگر فروشنده اجازه لایه بیرونی می‌دهد، Use case و مسئول عملیات را روشن کنید؛ صرف فعال‌سازی یک سرویس مساوی امنیت نیست. برای انتخاب، Ruleگذاری و سنجش False Positive به راهنمای WAF وب‌سایت رجوع کنید.

۱۱. Runbook پاسخ به رخداد سایت‌ساز بنویسید

در لحظه بحران، تکیه بر حافظه خطرناک است. Runbook باید شماره حساب، Domain، کانال رسمی پشتیبانی، افراد تصمیم‌گیر، نسخه قرارداد، محل Backup و متن‌های ارتباطی را داشته باشد.

1. تأیید: Screenshot، زمان، URL، اعلان و Log را حفظ کنید؛ بی‌هدف همه‌چیز را پاک نکنید.
2. مهار: Sessionها را Revoke، رمز و Recovery را اصلاح، Token مشکوک را لغو و دسترسی فرد/‌App را محدود کنید.
3. دامنه: Registrar و DNS را جداگانه بررسی کنید؛ اگر مسیر تغییر کرده، Record سالم را از نسخه مستند برگردانید.
4. اثر: صفحه، سفارش، پرداخت، فرم، داده و سئو را بررسی و بازه رخداد را تعیین کنید.
5. هماهنگی: Ticket رسمی با فروشنده و ارائه‌دهندگان درگیر باز کنید و شناسه پرونده را ثبت کنید.
6. بازیابی: نسخه سالم را برگردانید، تست مصنوعی اجرا کنید و سپس سرویس را باز کنید.
7. یادگیری: علت، زمان کشف، کنترل شکست‌خورده و اقدام مالک‌دار را در Post-incident review بنویسید.

اگر داده شخصی یا پول درگیر است، مسئول حقوقی و مالی را از ابتدا وارد تصمیم کنید. وعده قطعی درباره «عدم نشت» ندهید تا دامنه بررسی روشن شود.

چگونه یک سایت‌ساز امن‌تر انتخاب کنیم؟

نام برند را جایگزین ارزیابی نکنید. یک Proof of Concept دو هفته‌ای بسازید و قابلیت‌های امنیتی را روی همان پلنی که واقعاً می‌خرید امتحان کنید.

امتیاز ۰ تا ۳ بدهید: صفر یعنی قابلیت/مدرک ندارد؛ یک یعنی دستی و ناقص؛ دو یعنی قابل قبول؛ سه یعنی قابل آزمون و مستند. برای معیارهای حیاتی مانند Owner، Domain، Export و Payment حداقل اجباری تعیین کنید؛ میانگین بالا نباید یک نقص مرگبار را پنهان کند.

ملاحظات عملی برای کسب‌وکار ایرانی

در ایران علاوه بر کنترل‌های عمومی، تداوم دسترسی و عملیات را نیز بسنجید. این به معنای انتخاب خودکار سرویس داخلی یا خارجی نیست؛ باید سناریو را با مدل درآمد، تیم و حساسیت داده تطبیق دهید.

• پرداخت و تمدید: وابستگی به کارت یا واسطه واحد را ثبت و هشدار تمدید زودهنگام بسازید.
• دسترسی: مسیر قانونی و پایدار ورود تیم، Recovery و پشتیبانی را پیش از خرید امتحان کنید.
• دامنه: مالکیت و کنترل Registrar را از حساب پیمانکار جدا کنید.
• یکپارچه‌سازی: درگاه، پیامک، حسابداری و حمل را در محیط آزمایشی و پس از هر تغییر تست کنید.
• پشتیبانی: ساعت پاسخ، زبان، کانال اضطراری و توان بازیابی را با Ticket واقعی بسنجید.
• خروج: اگر Export ناقص است، هزینه مهاجرت و ورود دستی داده را از ابتدا در TCO منظور کنید.
• داده: محل پردازش، قرارداد پردازنده‌های فرعی و نیاز حقوقی کسب‌وکار را با مشاور متخصص تطبیق دهید.

اگر کنترل، لاگ یا سفارشی‌سازی مورد نیاز از سقف سایت‌ساز عبور کرده است، گزینه Self-hosted را با ریسک‌های خودش بسنجید. امنیت هاست اشتراکی و زمان مهاجرت نشان می‌دهد انتقال مسئولیت زیرساخت چگونه هزینه و کنترل را تغییر می‌دهد.

برنامه ۳۰ روزه امنیت سایت‌ساز

هفته اول: مالکیت و هویت

• Owner، Registrar، Billing و ایمیل Recovery را ثبت کنید.
• MFA/Passkey، کد Recovery و اعلان‌های حساس را فعال و آزمایش کنید.
• کاربران، Roleها، Sessionها و همکاران سابق را پاک‌سازی کنید.

هفته دوم: دامنه، App و داده

• Domain lock، تاریخ تمدید، DNS export و پایش TLS را برقرار کنید.
• App، Token، Webhook، Script و Tagها را با مالک و تاریخ بازبینی فهرست کنید.
• فرم‌ها، گیرندگان ایمیل، Export و Retention را کمینه کنید.

هفته سوم: کشف و بازیابی

• Audit Log، اعلان Admin و تست مصنوعی فرم/Checkout را فعال کنید.
• بسته خروج بسازید و حداقل یک Restore یا Import محدود انجام دهید.
• RPO/RTO را برای محتوا، سفارش و سرنخ جدا تعیین کنید.

هفته چهارم: رخداد و خرید

• Runbook، فهرست تماس و دسترسی اضطراری را روی یک سناریو تمرین کنید.
• امتیاز فروشنده را با مدرک و PoC تکمیل کنید.
• سه ریسک باقیمانده را به مالک، موعد و بودجه متصل کنید.

برای تبدیل این ممیزی به Roadmap متناسب با اندازه و ریسک کسب‌وکار، می‌توانید از درخواست مشاوره مایندیو شروع کنید.

چه زمانی سایت‌ساز دیگر انتخاب مناسبی نیست؟

مهاجرت زمانی منطقی می‌شود که محدودیت کنترل، نه صرفاً سلیقه فنی، مانع هدف کسب‌وکار باشد: نیاز به Log دقیق‌تر، RTO کوتاه‌تر، اتصال سفارشی، سیاست داده خاص، کنترل امنیتی اجباری، Export ناقص یا هزینه Appها از مزیت سادگی بیشتر شده است. پیش از تصمیم، هزینه ساخت، عملیات، Patch، Backup، مانیتورینگ و نیروی متخصص مقصد را نیز حساب کنید. SaaS ذاتاً امن یا ناامن نیست؛ شکل مسئولیت و قابلیت کنترل متفاوت است.

سوالات متداول امنیت سایت‌سازها

آیا سایت‌سازهای SaaS از وردپرس امن‌ترند؟

پاسخ مطلق ندارد. SaaS نگهداری زیرساخت و هسته را بیشتر به فروشنده می‌سپارد، اما حساب، دامنه، Role، App و داده همچنان ریسک مشتری‌اند. وردپرس کنترل بیشتری می‌دهد و در مقابل عملیات بیشتری می‌خواهد. تصمیم را بر توان تیم و کنترل‌های قابل آزمون بنا کنید.

مهم‌ترین اقدام امنیتی برای یک سایت‌ساز چیست؟

حفاظت از Owner و Registrar با ورود قوی، Recovery کنترل‌شده و حساب‌های جدا بیشترین اثر اولیه را دارد؛ سپس Role، App، Export و Monitoring را تکمیل کنید.

آیا Backup خودکار پلتفرم کافی است؟

فقط وقتی کافی است که دامنه پوشش، Retention و Restore آن را روی پلن خودتان آزموده باشید. برای داده حیاتی، Export مستقل و تمرین خواندن یا بازیابی فایل لازم است.

آیا نصب App از Marketplace بی‌خطر است؟

خیر. فروشگاه رسمی می‌تواند بخشی از غربال‌گری را انجام دهد، اما Scope دسترسی، داده ارسالی، Publisher، Token و رفتار پس از حذف باید توسط مشتری ارزیابی شود.

اگر حساب سایت‌ساز هک شد چه کنیم؟

شواهد را حفظ کنید، Session و Tokenها را لغو کنید، Recovery و Adminها را بررسی کنید، دامنه و پرداخت را جداگانه کنترل کنید، با کانال رسمی فروشنده پرونده باز کنید و پس از تعیین نسخه سالم بازیابی و تست انجام دهید.

جمع‌بندی

امنیت سایت‌ساز با خرید یک پلن یا روشن‌کردن SSL تمام نمی‌شود. حساب و Recovery، Domain، Role، App، Script، Data، Export، Log و Incident یک زنجیره‌اند. از Owner و دامنه شروع کنید، هر دسترسی را مالک‌دار کنید، خروج را تمرین کنید و ادعای فروشنده را با PoC بسنجید. این رویکرد، امنیت را از چک‌باکس تبلیغاتی به قابلیت عملی کسب‌وکار تبدیل می‌کند.

منابع مرجع: NIST SP ۸۰۰-63B درباره احراز هویت، NIST Cybersecurity Framework، OWASP درباره JavaScript ثالث و CISA Secure by Demand.